abstract - personliga hemsidor på kthe94_cen/exjobb/ipv6_report.doc · web viewabstract. the...
TRANSCRIPT
Department of Teleinformatics Network ServicesRoyal Institute of Technology Telia Research AB
IPv6@homeA study on using IPv6 in home networks
A master thesis byChrister Engman ([email protected])
Stockholm, Sweden1999
IPv6@home
ABSTRACTThe Internet has expanded enormously over the last few years. The development of new services and the discovery of new application areas continue as the Internet gains inter-est. Today, broadband Internet connections are spreading and connecting increasingly more people at their homes. However, this expansion may require a prominent upgrade of today’s Internet.
This thesis explores how the next generation Internet protocol, IPv6, may be introduced in a home network environment. IPv6 is expected to eventually replace the current proto-col, IPv4, since it provides many enhancements and new features of which many are ideal for using in a home network.
The report includes a description of the home networking concept and a brief description of IPv6 followed by a study that shows that home networking really could benefit from the new features provided by the new protocol. Also described are the various transition mechanisms required for IPv4 and IPv6 to coexist side by side during the introduction.
Finally, experiments conducted in a fictive home network is documented and analyzed to show how some of the IPv6 features work in practice and how they are configured. The experiments also revealed the current shortage of IPv6 implementations, which was quite surprising.
iii
IPv6@home
TABLE OF CONTENTS1 INTRODUCTION....................................................................................................................1
1.1 BACKGROUND.....................................................................................................................11.2 REPORT STRUCTURE...........................................................................................................1
2 HOME NETWORKING.........................................................................................................3
2.1 VISION.................................................................................................................................32.2 EXAMPLES...........................................................................................................................4
2.2.1 Residential Gateway (Telia).......................................................................................42.2.2 E-box (Ericsson).........................................................................................................4
2.3 LIMITATIONS TODAY..........................................................................................................5
3 IPV6 OVERVIEW...................................................................................................................7
3.1 IPV6 HEADER FORMAT.......................................................................................................73.2 ICMPV6..............................................................................................................................83.3 ADDRESSING.......................................................................................................................8
3.3.1 Address Notation........................................................................................................83.3.2 Address Assignment..................................................................................................103.3.3 The IPv6 Address Space...........................................................................................103.3.4 Unicast Addresses....................................................................................................113.3.5 Multicast Addresses..................................................................................................123.3.6 Anycast Addresses....................................................................................................133.3.7 Domain Name System (DNSv6)................................................................................14
3.4 AUTOCONFIGURATION......................................................................................................143.4.1 Mechanisms..............................................................................................................143.4.2 Procedure.................................................................................................................14
3.5 REAL-TIME SUPPORT.........................................................................................................153.5.1 Flows........................................................................................................................153.5.2 Traffic Class.............................................................................................................153.5.3 Jumbograms.............................................................................................................15
3.6 MOBILITY..........................................................................................................................163.7 SECURITY..........................................................................................................................16
4 USING IPV6 AT HOME.......................................................................................................19
4.1 ADDRESSING.....................................................................................................................194.1.1 Node Naming............................................................................................................194.1.2 Eliminating the NAT.................................................................................................204.1.3 Choice of Service Provider.......................................................................................20
4.2 PLUG AND PLAY...............................................................................................................214.2.1 Installing Devices.....................................................................................................214.2.2 Mobile Devices.........................................................................................................21
4.3 MULTIMEDIA.....................................................................................................................224.3.1 Convergence.............................................................................................................224.3.2 Quality of Service.....................................................................................................224.3.3 Broadcasting Media.................................................................................................224.3.4 Hierarchical Transmission.......................................................................................23
4.4 SECURITY..........................................................................................................................24
5 INTRODUCING IPV6 TODAY...........................................................................................25
5.1 TRANSITION STRATEGY....................................................................................................255.2 TRANSITION ISSUES..........................................................................................................26
IPv6 Addressing.......................................................................................................................275.2.2 IPv4 Connectivity.....................................................................................................275.2.3 IPv6 Connectivity.....................................................................................................305.2.4 Old Applications.......................................................................................................30
5.3 IMPLEMENTATION STATUS................................................................................................31
6 EXPERIMENTAL SETUP...................................................................................................33
v
IPv6@home
6.1 GOAL.................................................................................................................................336.2 SCENARIO..........................................................................................................................336.3 EXPERIMENTS....................................................................................................................33
6.3.1 Hardware and OS.....................................................................................................336.3.2 IPv6 Support.............................................................................................................346.3.3 Connectivity check....................................................................................................356.3.4 DNS..........................................................................................................................356.3.5 Router Advertisements..............................................................................................366.3.6 IPv6 connectivity......................................................................................................376.3.7 Transition mechanisms.............................................................................................37
7 RELATED INITIATIVES.....................................................................................................41
7.1 JINI...................................................................................................................................417.2 UNIVERSAL PNP................................................................................................................41
8 CONCLUSIONS.....................................................................................................................43
9 FUTURE WORK...................................................................................................................45
10 REFERENCES...................................................................................................................47
APPENDIX A AUTOCONFIGURATION PROCESS............................................................49
APPENDIX B IPV6 IMPLEMENTATION STATUS.............................................................50
COMPANIES SUPPORTING IPV6.....................................................................................................50IPV6 STACKS................................................................................................................................50APPLICATIONS...............................................................................................................................50TRANSITION MECHANISMS...........................................................................................................50
APPENDIX C EXPERIMENTAL SETUP DETAILS.............................................................51
NODE DETAILS..............................................................................................................................51INTERFACE DUMPS........................................................................................................................51
Linux.........................................................................................................................................51Windows 2000..........................................................................................................................52
APPENDIX D ACRONYMS......................................................................................................53
vi
IPv6@home
1 INTRODUCTION
1.1 BackgroundThe Internet was originally used as a minor message handling system restricted to small research labs or campuses. Today, the Internet is the fastest growing media for distribut-ing information and has already become a potential alternative to traditional information channels such as magazines, television, radio and telephony. The Internet has also be-come a vital part of many companies’ business strategies, which depends, partly or en-tirely, on their Internet customers.
Geographically, the Internet already spans across the globe and interconnects the majority of all countries with high capacity fibers. However, when investigating the “leaf nodes” of the network topology we find that the facilities with high-speed connections are lim-ited to research labs, universities and bigger companies. Users sitting at home may also connect to a nearby server, but that connection is often a low-speed dial-up connection using a modem. These connections are also made on a temporary basis, as they tend to last no more than a couple of hours at a time. Now the Internet continues to grow with broadband Internet access to the homes through alternative techniques such as the cable TV network. When this phase is completed, the Internet will reach far more people than today, and the usage of the net is expected to literally explode. New applications and habits will be developed and the Internet will be part of everyone’s life, just as TV and ra-dio are today.
However, the Internet expansion will not stop there. Future homes will contain many electronic devices and appliances, of which a substantial part will feature network con-nectivity. The “home LAN” is born where an in-house network is used to interconnect all of these devices and appliances, and finally connect them to the Internet. The market of “home networking” is predicted to be enormous. Just think of the endless kinds of de-vices and applications, which will be suitable for, or completely dedicated to, the home network market. Surveillance, home automation, resource sharing and information re-trieval are just a few examples.
This change in Internetworking was impossible to predict when the original Internet was built in the early 70’s. The protocol used for transporting the information through the net-work 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 re-quires 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 applica-tions 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 StructureThe 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 net-working and IPv6 is analyzed by matching demands with features. The grouping in this chapter is based on the demands present in a home network rather than the features pro -vided by IPv6 to emphasize the focus on home networking. Real world examples and terms are used to make the discussion concrete help the reader to get a greater under-standing.
Chapter 5 is dedicated to the transition from IPv4 towards IPv6. The introduction of IPv6 will meet many obstacles since it is not compatible with IPv4 and therefore requires up-grade of both hosts and routers. Several transition mechanisms are covered and compared side by side to clarify the difference between them regarding availability, requirements and features.
Next, Chapter 6 presents the results I gained from my practical experiments conducted in a fictive home network environment. Features and mechanisms described earlier in the report are verified and visually presented in the form of “packet dumps”.
Finally, the Chapters 7, 8 and 9 include a short description of research topics related to the report together with conclusions and suggestions to further investigate the possibili-ties with IPv6.
2
IPv6@home
2 HOME NETWORKING
2.1 VisionWith today’s cheap PCs, it has become increasingly common to find multiple computers within a single household. Maybe there is one in the home office connected to the corpo-rate LAN through a modem and to a printer. Another computer may reside in the 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 every-one want to be able to access the Internet through the modem connection in the home of-fice?
The solution to these problems is to interconnect the three computers making a local area network in the home – a home LAN or home network. This enables resource sharing, which will become even more important in a near future with increasing varieties of net-work aware products and appliances. Probably future home electronics will be intercon-nected enabling new interesting possibilities of accessing everything wherever you are, whenever you are there. For example, one could pop in a CD in the player located in the living room and then continue listening to it through the speakers in the kitchen while preparing dinner.
Access Network
Home Server
Home Network
Figure 2.1 A typical home network scenario.
Besides communicating locally on the home network, users probably want to be able to access common networks such as the Internet, as stated earlier. In the 1960s, the Internet was only accessible to a few academic scientists in their labs. The Internet grew beyond the lab boundaries and soon universities and commercial companies could get access. The next natural step in this evolution is to get the broadband Internet access into the house-holds and make it as common as today’s telephone and TV distribution mediums. A fast connection to the Internet is believed to be one of the driving forces to establish the home networking concept.
Another important aspect of home networks is home automation. This concept will give you the ability to control and monitor your house, even if you are not at home by connect-ing 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 advan-
3
IPv6@home
tage of sensors distributed over the house, and use them to adjust parameters such as heat, light and humidity.
With hundreds of millions of households in the world, the home network market is enor-mous and will definitely involve many companies in the future. Both hardware and soft-ware vendors will have lucrative possibilities. Many experts believe that the home net-work market will explode in the next couple of years, which drives the development of the architecture faster than ever before.
The possibilities and applications for home LANs seems endless but are beyond the scope of this report. More information about home networking can be found in any of the nu-merous reports or articles written in this topic.
2.2 Examples
2.2.1 Residential Gateway (Telia)At Telia Research AB, home networks are a hot topic in research projects. The develop-ment has brought the concept with a home server called Residential Gateway (RG). An RG is placed between the access network and the home LAN in each home and acts as a border gateway to the home LAN. It also acts as a communications central featuring mul-tiple connectivity interfaces such as Ethernet or IEEE 1394 (Firewire) for Internet access, POTS for analog telephony and LonWorks for home automation.
A user may access the RG through a web interface which lets the user configure its home, both from inside the home LAN and remotely. Besides web server software, the RG con-tains firewall and routing software to provide Internet access.
2.2.2 E-box (Ericsson)Ericsson also wants to take part in the home network market. Their contribution is a home server similar to the RG called the e-box. The e-box provides much the same functional-ity as the RG, except for the POTS connectivity. It is however equipped with two I/O-slots, which can be fitted with various interface cards to expand connection possibilities.
Today, the e-box is already available as a prototype to the market. Despite the lack of IP enabled appliances, this is an important step to show the customers where the develop-ment is leading.
Figure 2.2 Telia’s RG and Ericsson’s e-box
4
IPv6@home
2.3 Limitations TodayHome networking is still a vision. Many companies and research labs are involved in the development and have already presented working prototypes and solutions suitable for home LANs. However, there are limitations with today’s technologies which delays fur-ther development in several areas.
Price. A home server must be cheap to be appealing to customers. This is a major problem with the prototypes of both the RG and the e-box. However, the price will eventually decrease when mass production begins.
Bandwidth. To be able to serve a household’s demands on bandwidth through the connection to Internet, new technologies such as xDSL or cable modems have to be commercially available in a large scale. For a complete home LAN solution, it should be possible to distribute high-quality audio and video over the network.
Wiring. To connect the future devices and appliances in your home you will need some sort of medium in between, which is able to transmit data. Today most of-fices are equipped with Ethernet LAN cabling or some other link-level architecture. This is not the case with regular residences, which therefore may need rewiring. There are, however, multiple solutions for this already. For example, different tech-niques for communicating over the existing telephone wiring such as the Home-PNA 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 lim-ited 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 limi-tations of the Internet protocol, which is responsible for all data transfers over the Inter-net. The current version of the Internet protocol (IPv4) was simply not designed with home networking in mind. It lacks desired functionality such as security, bandwidth allo-cation (QoS) and easy administration and configuration.
In the following, the new Internet Protocol version 6 (IPv6) will be studied as an alterna-tive to today’s IPv4. After an overview of the protocol, the scenario of using it in a home network environment will be covered.
5
IPv6@home
3 IPV6 OVERVIEWThe Internet Protocol version 6 (IPv6) has been developed to replace today’s Internet Protocol version 4 (IPv4). IPv4 has its roots in the early 1970s when the Internet con-sisted only of limited research networks. The new protocol has been in development since 1992 when network experts realized that the nature of the Internet had changed and was in the need of a prominent upgrade.
The new protocol brings new functionality and higher performance into internetworking in several aspects. When designing IPv6, much research was made to assure that IPv6 would handle the expected growth of the Internet and all the new services that will follow with it.
In this chapter, IPv6 features related to home networking will be briefly described. For further information, please refer to the referenced sources. For application examples and usage, refer to Chapter .
3.1 IPv6 Header FormatIPv6 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.3. Although the IPv6 header is bigger measured in bytes, the slimmed structure with only eight fields together with the fixed size provides for easier implementations and higher performance in hosts and routers.
Figure 3.3 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 perfor-mance boost for routers and firewalls since they don’t have to recalculate a check-sum when something in the header is changed (such as TTL or the source/destina-tion address).
7
Options
Ver IHL ToS Total Length
Identification Flags Fragment Offset
TTL Protocol Header Checksum
Source Address
Destination Address
Ver Traffic Class Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
3116150 3116150
IPv6@home
Fragmentation Offset and the Options fields have been completely removed from the IPv6 header. Instead, this information is put into separate extension headers in-serted between the IPv6 header and the payload in a daisy-chain fashion as shown in Figure 3.4. Each extension header has a next header field, which specifies the type of the following header. The technique makes the handling of extra options and special delivery cases more slimmed, and provides for easy future expansions with new headers types.
Figure 3.4 Daisy-chaining of extension headers in IPv6.
3.2 ICMPv6IPv6 uses the Internet Control Message Protocol version 6 (ICMPv6) defined in [12], which is a further development of the ICMP, available in IPv4. The changes include re-moval of seldom-used messages and the introduction of Internet Group Management Pro-tocol (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 Message1 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 AddressingIPv6 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 NotationPlain old IPv4 addresses are written in “four dotted decimal” form as in
192.168.0.1
8
IPv6 Header
Fragmentation Header
TCP Header
Payload Fragment…
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 avail-able. By removing leading zeros in the words and thereby replacing words like 0200 with 200, the address is shortened. Furthermore, words consisting entirely of zeros (0000) may be replaced by a double colon (::). A double colon can represent one or more adja-cent words of this kind and can therefore simplify the notation further. The second ad-dress above in compressed form now reads
FE80::200:F8FF:FE22:26C8
This is the common way of writing IPv6 address and will be used in the rest of this re-port. To expand the compressed address you only need to align whatever is left to the colons to the left, the rest to right and then pad with zeros. It is not possible to use multi -ple double colons to replace zeros since that makes the expansion ambiguous.
There is also a convenient form of writing IPv6 addresses derived from an IPv4 address. Such addresses may be expressed as a six hexadecimal groups followed by the plain old “four dotted decimal” form:
0:0:0:0:0:0:192.168.0.1
In compressed form, the address becomes very easy to handle:
::192.168.0.1
Besides addresses assigned to individual hosts, IPv6 introduces address prefixes. An ad-dress prefix is similar to the network prefix used in IPv4 and is used in the same way (for more information, please refer to Section 3.3.3). The address prefix is denoted as an IPv6 address followed by a slash and the prefix length in bits. The following examples show the same prefix written in three different ways:
3FFE:0000:0A12:1200:0000:0000:0000:0000/603FFE::A12:1200:0:0:0:0/603FFE: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
3FFE:0:A12:120::/60 3FFE:0000:0A12:0120:0000:0000:0000:0000/60 =
9
60 bits
IPv6@home
3FFE:0:A12:0120::/60
3.3.2 Address AssignmentIPv6 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 SpaceThe IPv6 address space is gigantic! Going from 32 to 128 bits wide addresses means a drastic increase in addresses available. Moreover, the 128 bits not only makes it possible to assign billions of billions of hosts, but also provides for a greater hierarchical structure than the network, subnetwork and host layers defined in IPv4.
In the top level of hierarchy in the IPv6 address space, different address types are defined. Each type has its own address subspace identified by an address prefix similar to those used in Classless Inter-domain Routing (CIDR). Table 3.2 below shows the initial alloca-tion defined in [17]. The table shows the named allocation together with its corresponding prefix followed by the fraction of the address space it allocates.
Table 3.2 Initial allocation of address prefixes.
Allocation Prefix(binary)
Prefix(hex)
Fraction ofaddress space
Reserved 0000 0000 ::/8 1/256 (0.4%)
Unassigned 0000 0001 100::/8 1/256
NSAP Allocation 0000 001 200::/7 1/128 (0.8%)
IPX Allocation 0000 010 400::/7 1/128
Unassigned 0000 011 600::/7 1/128
Unassigned 0000 1 800::/5 1/32 (3.1%)
Unassigned 0001 1000:/4 1/16 (6.3%)
Aggregatable Global Unicast Addresses 001 2000::/3 1/8 (12.5%)
Unassigned 010 4000::/3 1/8
Unassigned 011 6000::/3 1/8
Unassigned 100 8000::/3 1/8
Unassigned 101 A000::/3 1/8
Unassigned 110 C000::/3 1/8
Unassigned 1110 E000::/4 1/16 (6.3%)
Unassigned 1111 0 F000::/5 1/32 (3.1%)
Unassigned 1111 10 F800::/6 1/64 (1.6%)
Unassigned 1111 110 FC00::/7 1/128 (0.8%)
Unassigned 1111 1110 0 FE00::/9 1/512 (0.2%)
Link-Local Unicast Addresses 1111 1110 10 FE80::/10 1/1024 (0.1%)
Site-Local Unicast Addresses 1111 1110 11 FEC0::/10 1/1024
Multicast Addresses 1111 1111 FF::/8 1/256 (0.4%)
10
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 AddressesA 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 AddressesAggregatable Global Unicast Addresses is a hierarchically structured addressing scheme intended to be the initially used assignment plan for IPv6 nodes [18]. This address format is designed to optimize high-speed routing in the core networks of the Internet by intro-ducing a multi-level address topology divided into Public, Site and Interface topologies. The address format is as follows:
The address format consists of four ID fields for a four level hierarchical structure:
Top-Level Aggregation Identifiers (TLA ID) used in the top level in the routing hier-archy.
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 addressesIPv6 defines three types of addresses for local use only – that is IP packets containing lo -cal 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 di-rectly 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 assign-ment is done depends on the underlying media (i.e. Ethernet, ATM, IEEE 1394 etc.).
11
Site Topology
Interface ID001 TLA ID
64 bits3
RES NLA ID SLA ID
13 8 24 16
Public Topology Interface Topology
IPv6@home
A link-local address is constructed by the prefix FE80::/10 and a 64-bit interface ID padded with 54 bits of zeros in between:
Link-local addresses are heavily used in IPv6’s autoconfiguration procedures as will be shown in Section 3.4.
Site-local addresses are designed to let sites with multiple links or segments communicate locally without the need for a global prefix. This could be the case for an isolated corpo -rate network or residential area without the need of global communication.
The structure of the site-local address is similar to the link-local, except for the new pre -fix FEC0::/10 and a new field for subnet ID.
3.3.5 Multicast AddressesA multicast address is used to send packets from one source to multiple destinations. IPv6 will make multicasting a more common way of communicating since every IPv6 router is required to handle multicast routing.
An IPv6 multicast address consists of the address prefix 11111111 (FF::/8) followed by some flags, the scope of the multicast and finally an identifier for the multicast group:
In the flags field, the fourth bit indicates if the multicast address is transient or not. Tran-sient addresses are constructed for temporary multicasting sessions such as a videoconfer-ence while a non-transient address is reserved for special pre-registered services. For ex-ample, 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 bound-aries. 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
Interface ID1111111010 0
64 bits54 bits10 bits
Interface ID1111111011 Subnet ID
64 bits38 bits10 bits
0
16 bits
11111111
112 bits4 bits8 bits
Flags Scope
4 bits
Group ID
IPv6@home
Table 3.3 Multicast scopes
Value Definition Scope0 Reserved
1 Node-local scope
2 Link-local scope
5 Site-local scope
8 Organization-local scope
E Global scope
F Reserved
The “missing” values are currently unassigned and are available to network administra-tors to define themselves. In the concept of home networking, these could represent addi-tional geographical hierarchies, e.g. “National scope”, “Continental scope” and so on.
Finally, the group identifier in the address distinguishes a multicast session within the current scope. In IPv6, multicast is considered as a common type of communication, which is not the case with IPv4. This can be easily conceived by looking at the 112-bit wide group identifier in IPv6 compared to the 28 bits available in the IPv4 class D ad-dresses. For example, multicasts in IPv6 replace broadcasts in IPv4.
3.3.6 Anycast AddressesAnycasting 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.5 shows a simple example with two hosts (A and C) both specifying B as their destination address. The ac-tual server requested depends on the network topology since the shortest route is chosen.
Figure 3.5 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 AutoconfigurationIPv6 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 MechanismsIPv6 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 topol-ogy and router parameters set by the network administrator as described in the next sec-tion.
3.4.2 ProcedureThe automatic configuration of a node is a multi-step process. A flow chart illustrating the steps involved can be found in Appendix A. The complete process is as follows:
1) The interface is activated.
2) A link-local address is generated (but not assigned to the interface) by concatenat-ing the predefined prefix FE80::/10 with a 64-bit interface identifier as described in Section 3.3.4. The interface identifier can typically be the IEEE-802 address of the interface card (e.g. Ethernet, FDDI) or another unique number taken from other parts in the node (e.g. the main board serial number).
3) Neighbor discovery is then used to check if the newly constructed address is unique (on the link). This is done by sending ND solicitation messages with the destina-tion address set to the address being tested, and source address set to the unspeci-
14
IPv6@home
fied address (::). If a ND advertisement message is received, the address is not unique and has to be recreated either manually or randomly.
4) Once the link-local address is known to be unique, the address is assigned to the in-terface being configured.
5) Using the new link-local address as a source address, a ND router solicitation mes-sage is sent to the all-routers multicast group (FF02::2).
6) In response to the ND router solicitations, routers send a unicast ND router adver-tisement message back to the node. The advertisement specifies if the node should use stateless or stateful autoconfiguration by setting the managed configuration flag accordingly. If stateless autoconfiguration is to be used, a site-local or global address is constructed using an address prefix included in the advertisement and the current link-local address. The new address is then assigned to the interface (which now has two addresses). The host is now configured for communication in-side the site or even on the Internet at large.
7) If there is no response from a router, or the advertisement specifies managed ad-dressing, stateful autoconfiguration should be used. This is handled by DHCPv6, which defines message types for configuring all necessary parameters.
3.5 Real-time SupportTo 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 FlowsIn the IPv6 header, there is a 20-bit Flow Label field defined. A flow is implicitly defined as a set of packets that come from the same source to the same (unicast or multicast) des-tination bearing the same flow label. New flow labels are generated randomly in the range 1 to FFFFF hex. Packets are however not forced to use flow labels and then use a value of zero as flow label. In fact, most packets will probably have this unspecified flow label.
Flows may be used to indicate that some packets require special handling by the IPv6 routers in the network such as low delay or high bandwidth. Then may also be used in conjunction with the router header [15] to restrain all packets to the same path through the network. To provide resource allocation, a protocol such as the Resource Reservation Protocol (RSVP) [9] could be used. RSVP is based on the use of flows and is therefore well suited for IPv6 as described in [6].
The usage of the flow label is still experimental, and a final decision on the usage will be made when the needs come clearer.
3.5.2 Traffic ClassThe 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 JumbogramsTo 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 re-quires the underlying link layer having a link MTU of at least 65,575 bytes (65,535 + 40 for the IPv6 header).
When using the Jumbo Payload options, the Payload length field in the IPv6 header must be set to zero. The Next header field in the header is also set to zero, indicating the fol -lowing hop-by-hop extension header where the actual payload length can be retrieved as illustrated in Figure 3.6.
Figure 3.6: The Jumbo Payload option
3.6 MobilityIPv6 has to support mobile nodes since they are expected to be very common in the fu-ture. A method for accomplish this is defined in [20] as Mobile IPv6 and is currently un-der study. Mobile IPv6 has much in common with Mobile IP for IPv4. Some improve-ments should however be mentioned:
The care-of address is used as source instead of the home address.
Route Optimization is built-in eliminating “triangle routing”.
Simplified routing of multicast packets with the care-of address as source.
Foreign agents defined in Mobile IPv4 are no longer needed since the autoconfigura-tion 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 SecurityWith IPv6 comes security. Every IPv6 node is required to handle encryption and authenti-cation according to the specification. Although IP security is available for IPv4, it is far from commonly used. The security is made possible by introducing two extension head-ers.
The Authentication Header (AH) [22] makes it possible for a receiving host to guarantee whether the sender is authentic or not, and that the received packet has not been altered on its way. Introducing authentication in a network prevents spoofing attacks from hack-ers where packets are sent from a hackers computer while using a trusted computers ad-dress as a source address. Authentication is also important since the autoconfiguration mechanisms introduced in IPv6 otherwise would let any computer join the network, get a valid IPv6 address, and thereby access to the network.
16
IPv6 Header
Hop-by-Hop Options
Payload…
Next Header Hdr Ext Len Option Type(0xC2)
Option Length(0x04)
Jumbo Payload Length(0x00000000 – 0xFFFFFFFF)
IPv6@home
The Encapsulated Security Payload (ESP) header [23] is used to encrypt packets. This as-sures that only legitimate receivers will be able to read the contents. Intervening users try-ing 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.7.
Figure 3.7 Network and header configuration for a steel pipe
17
IPv6@home
4 USING IPV6 AT HOMEHome 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 every-thing may be transmitted using it, anytime and everywhere.
In the following, the enhancement areas will be covered and discussed from a home net-working perspective using real-world examples and applications.
4.1 AddressingThe 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 NamingWith 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 in the home server (e.g. Residential Gateway or e-box). This would make it possible for
19
IPv6@home
the end users to assign names to all connected devices within the residence. However, in-cluding 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 NATTo 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 to-day 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 ad-dress space. These is done by placing the NAT machine between the Internet and the lo-cal 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 con-nection 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.
Figure 4.8: Eliminating the IPv4 NAT
4.1.3 Choice of Service ProviderWith a modem and dial-up connectivity, the customer can easily choose which service provider to use simply by dialing the appropriate telephone number. With a broadband connection directly to your house always connecting you to the Internet, the choice will no longer be so obvious.
The Global Aggregatable Unicast addressing scheme described in Section 3.2 was previ-ously known as provider based addressing. The reason for this is that the address hierar-chy defined in the scheme permits a site, or residence, to change service provider easily. It is also possible to have multiple providers at the same time since each IPv6 interface may be assigned multiple addresses with different prefixes. The user may then choose the source address for outgoing packets depending on the application.
The renumbering of sites involved with changing provider is taken care of by the IPv6 autoconfiguration mechanism. A new prefix caused by the renumbering propagates throughout the network as the old addresses and routes on the hosts eventually time out when no router advertisements for that address/route are received. This will help providers and network administrators when introducing new network topologies. With to-
20
IPv4NAT
Local addressesGlobal addresses
IPv6Router
Home LAN
Global addresses
Internet Home LAN
Global address
Internet
IPv6@home
day’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 DevicesWhen 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 pro-tocol 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 plug-ging 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 In-ternet access presuming the security policies admits it. If the network medium also is ca-pable of acting power supply (e.g. IEEE 1394/Firewire, mains) plug-and-play is really the true word!
4.2.2 Mobile DevicesFuture homes will most certainly contain numerous mobile devices connected to the In-ternet. 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 ad-dress wherever the device may be located. This brings up an interesting topic about the addressing in IPv6. Since the IPv6 address space easily can provide every person with a personal IPv6 address, why not give everyone a static address? The address should be based on a unique number such as birth date together with codes for place of birth etc, or maybe the SSN. With the mobility support, this address would then serve as a direct line to that person wherever he or she is, much like the number to the persons cellular tele-phone or pager. Incoming messages may then be rerouted to any device by assigning it with the appropriate address. Of course, this requires tight security as described in Sec-tion 4.4.
21
IPv6@home
4.3 Multimedia
4.3.1 ConvergenceThe world of communication is about to change. Today, multiple separate services for transporting real-time information such as speech or video are used in parallel (e.g. TV, radio, and telephone). Each service typically requires its own specific medium, billing and end-user devices. This “redundancy”, with multiple services serving the same pur-pose of delivering information, will probably end with the introduction of home network-ing. 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.9).
Figure 4.9 The world of media is converging
4.3.2 Quality of ServiceToday there are already many examples of real-time applications for internetworking available. These includes tools for listening to streaming music, watching streaming video on demand and Internet telephony (Voice over IP, VoIP). However, today’s Inter-net makes it hard for real-time applications to deliver the quality needed, especially all the way to the homes. The most limiting factor for home users today is probably the lack of bandwidth. Watching a movie in broadcast quality requires several megabits per sec-ond. 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 compet-ing 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 transmis-sion, could also be limited by using the flow label. This would cause intermediate routers to serve all packets belonging to the same flow in the same way. Additionally, using the flow label in conjunction with a resource reservation protocol such as RSVP as described in Section 3.5.1 and the draft written by S. Berson [6], would also take care of the re-source reservation issue.
4.3.3 Broadcasting MediaIf 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 broad-casting media. Every IPv6 capable router is required to handle multicast routing accord-ing to the specifications. An IPv6 node also has full multicast management support through the group management messages included in ICMPv6.
When sending a TV broadcast, it would also be important to specify where the broadcast should be available. The multicast scope features in IPv6 multicasting make this selection an easy task. A regional news agency could choose to broadcast only to customers within the local neighborhood or the city. In the same way, national broadcasting companies could choose to limit their broadcasts to the country border as listed in Table 4.4. This re-quires however that the conceptual borders are known by the routers and that all assigned scope values are commonly known.
Table 4.4: Example of home networking multicast scopes
Value Definition Scope Home Networking Scope Example0 Reserved
1 Node-local scope Appliance scope “The fridge”
2 Link-local scope Apartment scope “Floor 2, apartment 214”
5 Site-local scope Building scope “4020 Long Street”
8 Organization-local scope Residential area scope “North docks”
A City scope “Stockholm”
C Country scope “Sweden”
E Global scope “Earth”
F Reserved “Universe?”
In home networking, the more common usage of broadcasting would be in-house distri-bution of audio and video. As a source, any IPv6 enabled TV receiver, DVD player or hi-fi equipment would do. The receivers would typically be video monitors and speakers used to present the streaming data. These kinds of transmissions would often use more lo-cal 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 au-thorities and persons such as hotels, tenants’ associations and employees for internal communication.
4.3.4 Hierarchical TransmissionWhen broadcasting real-time multimedia to a vast number of customers, not all of those will use the Internet under equal conditions. While some may have the luck to access the Internet through the cable TV network featuring several megabits per second of band-width, others may have to be content with a simpler connection. The broadcast has to be accessible to all those customers, but the users using a high-speed connection will surely not settle with only getting the poor quality limited by the low-speed connections. One solution is of course to split the stream into multiple ones with well-defined bit rates. However, this method wastes bandwidth since the same content will have to be made available in parallel.
A better solution is to use hierarchical transmission. By separating the source stream into incremental parts that together make up the original stream, a receiver may choose how much quality that should be received. For example, a videoconference with audio sam-pled at 22 kHz and video with a resolution of 640 by 480 pixels may be split up into four streams, or layers as illustrated in Figure 4.10.
23
IPv6@home
Figure 4.10: Hierarchical transmission
The low-capacity customer may now choose to receive only the first layer with low-qual-ity audio, while the high-speed user may be able to combine them all and thereby getting a higher quality stream.
By using the Traffic Class field provided by IPv6 and assigning the streams with incre-mental priority accordingly, the filtering can be made automatically at the network layer. The highest prioritized stream (in this case the low-quality audio) will always be re-ceived, while the additional streams will be used only if the bandwidth admits it.
4.4 SecurityWhen 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 authen-tication 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.11 where a “access server” is in-troduced in the network and acts as a firewall to the home networks connected to it. While limiting the traffic to and from the Internet, it also takes care of traffic between in-ner home networks if all traffic is set up to go through the access server. This would help non-experienced users to secure their home network, while more advanced users could be given an “open” connection without security limitations.
Figure 4.11 The access server limits both external and internal traffic
24
11 kHz audio
320 x 200 video
Additional audio
Additional video
+
+
+
Prio
rity
Full quality
High quality
Medium quality
Low quality
IPv6@home
5 INTRODUCING IPV6 TODAYToday the Internet is based on IPv4 as the main network protocol. Introducing IPv6 in this world is far from trivial when considering everything that has to be upgraded: both hardware and software implementations of the IP stack in every host or router together with additional protocols etc. The transition may well take several decades to complete, and during that period, IPv4 and IPv6 will have to work side by side.
The transition issue has been given high priority in the Internet Engineering Task Force (IETF) where a special working group called NGTRANS (Next Generation Transition Working Group) has been working on tools and mechanisms for the transition since De-cember 1994. The group has published many Internet-drafts and RFCs describing the transition tools and mechanisms in various scenarios where IPv6 is to be introduced.
5.1 Transition StrategyTransforming 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 net-work, the border between IPv6 and IPv4 moves further into the network as illus-trated in Figure 5.12.
The first strategy is beyond the scope of this report. Instead, the transition of home net -works, and the affects of it appearing to the end users, will be covered. A typical transi -tion of a home network connected to the Internet may be divided into four phases as shown in Figure 5.13. In each step, IPv6 is gradually replacing IPv4 as the default proto-col.
Figure 5.12 Transition from the edges and in
25
IPv6@home
Figure 5.13 Four phases in an IPv4 to IPv6 transition
1. IPv4 Only. The situation for almost everyone of today’s households already con-nected to the Internet. As illustrated in Figure 5.13(a), IPv4 is used throughout the network all the way from the end users into the core. All communications are car-ried over IPv4 and no IPv6 nodes have been introduced.
2. IPv6 in the homes. IPv6 is introduced as a secondary protocol in the home net-works. IPv4 is still used as the only protocol in the access network. In the home network, IPv4 is used as a complementary protocol to enable IPv4-only nodes to communicate or dual stack IPv4/IPv6 nodes to access IPv4 resources. By tunneling IPv6 packets inside IPv4 packets, IPv6 connectivity may also be achieved.
3. IPv6 in the access network. To let the IPv6 enabled nodes take advantage of all the new features provided, IPv6 has to be implemented in the access network to in-terconnect 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 de-ployed as the only protocol and thereby provide everyone with the new features it brings.
The early transition phase has already begun in many research labs and institutions, which together creates a global IPv6 network called the 6bone [1]. The 6bone uses tun-nels for transporting IPv6 inside IPv4 packets and spans across many countries.
5.2 Transition IssuesAs mentioned earlier, the IETF NGTRANS working group has presented various mecha-nisms for the transition from IPv4 to IPv6. The choice of appropriate mechanisms to use
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 AddressingEach 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.14. These addresses are gener-ated by the hosts themselves as described in Section 3.3.4 and therefore no stateful server such as DHCP is needed for the address assignment.
Figure 5.14 Addressing scheme for home networks
In areas with multiple households, such as a block with many flats or a complete residen-tial area, it would also be necessary to use site local addresses since link local packets must not be routed. To employ site local addressing, a border router has to be configured to send router advertisements with a desired site local prefix, which then will propagate throughout the network and configure all hosts with additional site local addresses. The complete addressing solution is presented in Figure 5.14.
5.2.2 IPv4 ConnectivityAfter an introduction of IPv6 in the homes, many servers on the Internet will still be lim-ited to only use IPv4. Therefore, an IPv6 enabled node inside the home network should be able to access these servers. Currently, there are several transition mechanisms for overcoming this problem.
NAT-PT/NAPT-PTTo 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 us-ing 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.15.
27
IPv6@home
Figure 5.15 The NAT-PT/NAPT-PT transition mechanism
When a new session starts, a new IPv4 addresses is acquired dynamically from a prede-fined pool of IPv4 addresses, which then is used throughout the session. When the session ends, the address is returned to the pool ready to be assigned to another host.
A limitation of NAT-PT is that the maximum number of simultaneously connected hosts is limited by the number of IPv4 addresses in the address pool. To overcome that limita -tion, the NAT-PT mechanism was extended to NAPT-PT, where the extra P stands for Port [35]. With NAPT, a single IPv4 address can be used to communicate with external resources. This is made possible by using different TCP or UDP ports for each host. This means a maximum of about 63K hosts per IPv4 address.
A limitation of both NAT-PT and NAPT-PT is that the connectivity is limited to TCP and UDP traffic (ICMP queries are also supported since the ICMP header includes identifier that can match incoming replies with the outgoing queries). Another limitation is that pro-tocols, 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 anal-ysis and translation of the corresponding packets.
DSTM Another way of providing IPv4 connectivity in the IPv6 home network is to equip the hosts with dual IP stacks as proposed in the Dual Stack Transition Mechanism (DSTM) [34]. With dual stacks, an IPv6 stack is used for internal (and future external) communi-cation, and an IPv4 stack provides true IPv4 connectivity. A problem with using dual stacks might seem to be the need for two IP addresses – one for each stack. Of course, the simplest way would be to assign each host both an IPv4 address and an IPv6 address. However, this approach would not benefit from the huge address space available in IPv6 since the IPv4 address assignment would limit the number of hosts. Instead, DSTM uti -lizes a dynamic address allocation mechanism called Assignment of IPv4 Global Ad-dresses to IPv6 hosts (AIIH). Previously, AIIH was the name of a whole transition mech-anism 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 inter-nal 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.16(a). The dynamic assignment also works in the opposite direction, which is illustrated in Fig-ure 5.16(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
Figure 5.16 Internally (a) and externally (b) initiated IPv4 session using AIIH
SOCKS/Application proxiesAnother solution based on SOCKS version 5 has also been proposed in [25]. By combin-ing an ordinary socks server with a protocol translator, a transparent solution can be cre-ated. A downside with using SOCKS has always been the need for the special configura-tion on the hosts to “socksify” the application sessions. This would also cause a promi-nent need for support from home users if introduced into the home networks.
Similar to the SOCKS solution, application layer proxies can be used to translate be-tween IPv4 and IPv6. For example, a web proxy server can easily be fitted with a proto -col translator and thereby accept incoming IPv6 requests on one interface and send them out another one using IPv4 and vice versa. The implementations of such proxies are quite simple, but they still share the problem with limited application support and the need for special host configuration.
SummaryIt is hard to tell which of these mechanisms is most suitable depending on the various de -mands 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 pro-vides true IPv4 and IPv6 connectivity in parallel. The requirement of dual stack may however be a problem for embedded systems that today only have IPv4 stacks. The NAT and SOCKS solutions both have limited IPv4 connectivity since applications that embed IP addresses in higher protocol layers won’t work without special configuration. Another big disadvantage for using SOCKS in a home network environment is that the client ap-plication has to be “socksified” to work. This can easily lead to a massive demand for support since not everyone has the knowledge of a network administrator. Table 5.5 sum-marizes the features of the mentioned mechanisms for a quick overview.
29
IPv6@home
Table 5.5 Overview of transition mechanisms for IPv4 connectivity
NAT-PT, NAPT-PT DSTM SOCKS 5/Application proxies
IPv4 address re-quirements
1 per site1 1 per site1 1 per site1
Host Requirements IPv6 stack Dual IP stacks + DHCPv6 Application configuration
Advantages Very low IPv4 address requirements (NAPT)
Implementations avail-able
True IPv4 connectivity
Low IPv4 address re-quirements
Very low IPv4 address requirements
Implementations avail-able
Simple configuration
Disadvantages Limited IPv4 applica-tion support
No implementations available
IPv4 stack required
DHCP client required
Hosts need socks con-figuration
Limited IPv4 applica-tion support
Specification Status Internet draft Internet draft Internet draft
Implementation Sta-tus
Versions for NetBSD and Windows 2000 available
Expected for Linux and NetBSD in 4 months
Available for various sys-tems
1 A site may range from a single household to a residential area depending on the transition phase
5.2.3 IPv6 ConnectivityShort after the introduction of IPv6 in the homes, home users will most likely want to be able to communicate with other IPv6 resources on the Internet. This IPv6 connectivity can be achieved even before the access or core networks have been upgraded by tunnel-ing IPv6 packets in IPv4. It is already possible for anyone with an IPv6 enabled host to connect to the 6bone, which interconnects isolated IPv6 island all over the world using tunnels [1]. However, the methods developed for this scenario is beyond the scope for this report.
5.2.4 Old ApplicationsToday there are thousands and thousands of Internet applications based on IPv4. This in-cludes 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 re -quired, to be able to use these existing applications without any fuss. Without this possi-bility, 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.17(a), a transparent so-lution can be achieved.
The first addition to the IPv4 stack is the Extension Name Resolver. It translates the IPv4 application’s single DNS request to a request for both ‘A’ and ‘AAAA’ records (the drafts have not been updated with the ‘A6’ record type yet). If an ‘A’ record could be found, traditionally IPv4 communication can continue using the IPv4 stack. If only an IPv6 entry (‘AAAA’ or ‘A6’) could be found, the Address Mapper maps the returned IPv6 address to an IPv4 address taken from a local address pool. The address pool may contain private address such as 192.168.0.0 or 10.0.0.1 since the scope is limited to the host. When an IPv4 address corresponding to the IPv6 host is available, the communica-tion can be set up through the Translator and the IPv6 stack. The translator uses SIIT [29] for the translation, and the IPv6 stack is a fully featured stack with features such as Neighbor Discovery and security.
30
IPv6@home
A diagram of a typical communication scenario between an IPv4 application and an IPv6 host is shown in Figure 5.17(b). Communication initiated by the IPv6 host is established in a similar way:
The IPv6 packet reaches the translator
The address mapper resolves the IPv6 address into a corresponding IPv4 address
The new IPv4 packet is sent to the IPv4 application with the IPv4 address as the source address.
Figure 5.17 The Bump-in-the-Stack architecture
Using this technique, compatibility with old IPv4 application is not a problem for the in-troduction of IPv6.
5.3 Implementation StatusTo introduce a new protocol such as IPv6, only writing Internet-drafts and specifications are not enough. At some stage implementations of the specifications has to begin to real -ize the visions and to let people experiment with the new protocol. Implementation of IPv6 stacks and IPv6 adaptation of applications has been underway since 1994, and today there are IPv6 stacks available for almost every platform such as MS Windows, UNIX, SUN OS among others. However, these stacks often lack some functionality such as se -curity, mobility or DHCP. In fact, the DHCP extensions for IPv6 has not yet been fully standardized, thus there are no DHCP implementations available.
IPv6 enabled applications have also become available. These applications include the standard net tools such as ping, traceroute and tcpdump. Also more useful applications for using telnet, ftp and http are available.
All of the transition mechanisms except for AIIH have also reached implementation. However, the work is still in progress and many implementations still suffer from bugs or other cavities.
More details on the implementation status together with where to find IPv6 software can be found in Appendix B.
31
IPv6@home
6 EXPERIMENTAL SETUP
6.1 GoalDuring 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 implemen-tations was also a topic of interest.
6.2 ScenarioThe network which I set up was a very simple “home network” consisting of one home server and two clients as illustrated in Figure 6.18. The home network was connected to the local Intranet of Telia Research, which only supported IPv4 and therefore simulated the IPv4-only access network.
Figure 6.18 Experimental network setup
6.3 Experiments
6.3.1 Hardware and OSAs a first step in the experiments, I acquired the necessary hardware and installed the op-erating systems. On the ‘rg’, I decided to install Linux as it provides good network sup-port and free server software such as DNS and web servers. I also had previous experi-ence with Linux, which made the final choice the Red Hat Linux 6.0 distribution.
The clients were to simulate common home-user environments, so I chose to install Win-dows 2000 and Windows 98 SE on those machines with default installation options. Until Microsoft’s new OS called Millenium is released, Windows 98 will probably be the num-ber one OS in homes followed by Windows NT or Windows 2000 for distance working people.
33
IPv6@home
6.3.2 IPv6 SupportThe 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.19(a). The rest was automatically configured. In fact, the “Proper-ties…” button was grayed out since there is nothing to configure in IPv6 – everything is based on autoconfiguration.
(a) (b)
Figure 6.19 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 re-lease –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.19 (b).
After the installation of IPv6 stacks on all hosts, I verified that all hosts had been assigned with a link local IPv6 address. On ‘rg’ I used the standard (but IPv6 enabled) command ifconfig to extract the interface information. The output of this command can be found in Appendix C together with the output from the ipv6 program on ‘win2k’ provided with Microsoft’s IPv6 stack. On ‘win98’, Trumpet Winsock’s configuration window pro-vided the necessary information as shown in Figure 6.19 (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 checkThe next step was to test the IPv6 connectivity between the newly installed IPv6 stacks. To do this, I used the “ping” tool available on all hosts. On ‘rg’, the original ping appli-cation was replaced during installation by a new IPv6 enabled version. I first tried to ping ‘win2k’ from ‘rg’:
[root@rg ~]# ping fe80::290:27ff:fe72:93b5PING fe80::290:27ff:fe72:93b5 (fe80::290:27ff:fe72:93b5): 56 data bytes64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=2.263 ms64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64 time=2.471 ms64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=2 ttl=64 time=1.568 ms64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=3 ttl=64 time=2.443 ms
--- fe80::290:27ff:fe72:93b5 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-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 eth0tcpdump: listening on eth0fe80::200:f8ff:fe32:5fc > ff02::1:ff72:93b5 icmpv6: neighsolfe80::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 requestfe80::290:27ff:fe72:93b5 > fe80::200:f8ff:fe32:5fc icmpv6: echo replyfe80::200:f8ff:fe32:5fc > fe80::290:27ff:fe72:93b5 icmpv6: echo requestfe80::290:27ff:fe72:93b5 > fe80::200:f8ff:fe32:5fc icmpv6: echo reply...
As one can see, not only the echo request and reply messages was sent. The session be-gins with a neighbor discovery process where ‘rg’ learns the MAC address of ‘win2k’. Compare the behavior of a plain IPv4 ping where ARP is used instead:
arp who-has 10.0.0.3 tell 10.0.0.1arp reply 10.0.0.3 is-at 0:90:27:72:93:b510.0.0.1 > 10.0.0.3: icmp: echo request10.0.0.3 > 10.0.0.1: icmp: echo reply10.0.0.1 > 10.0.0.3: icmp: echo request10.0.0.3 > 10.0.0.1: icmp: echo reply...
The neighbor solicitation message is sent to the special multicast address ff02::1:ff72:93b5 destined to ‘win2k’ instead of a broadcast message as with ARP. The solicitation message carries the MAC address of ‘rg’, which makes it possible for ‘win2k’ to reply. In response to the solicitation, ‘win2k’ sends a neighbor advertisement back to ‘rg’ with its MAC address embedded inside the message. The flags in the tcpdump out-put indicate that the advertisement was in response to a solicitation (S), and that the newly acquired MAC address should override any old records in the cache (O).
To verify that all nodes where able to communicate with each other, I repeated the “ping test” between all machines. Microsoft included a new application, ping6, with their IPv6 stack to ping IPv6 hosts, which I used on ‘win2k’. Trumpet Winsock on ‘win98’ also in -cluded a ping tool in its configuration program.
6.3.4 DNSIPv6 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 10.0.0.1 AAAA fe80:0:0:0:200:f8ff:fe32:5fcrg CNAME ns
win98 A 10.0.0.2 AAAA fe80:0:0:0:210:4bff:fe71:3e2
win2k A 10.0.0.3 AAAA fe80:0:0:0:290:27ff:fe72:93b5
In the future of home networking this will most probably be automatically configured so that a connected device automatically registers its name in the DNS. In fact, dynamic DNS updates have already been covered in RFC2136 [32], and Microsoft has imple-mented the functionality in Windows 2000.
After the DNS server was started, and all nodes’ (IPv4) DNS servers where set to ‘rg’ (10.0.0.1), I could successfully ping the hosts by name such as
[root@rg ~]# ping win2kPING win2k (fe80::290:27ff:fe72:93b5): 56 data bytes64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=2.365 ms64 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 win2kPING win2k (10.0.0.3): 56 data bytes64 bytes from 10.0.0.3: icmp_seq=0 ttl=128 time=2.253 ms64 bytes from 10.0.0.3: icmp_seq=1 ttl=128 time=2.39 ms...
[root@rg ~]# ping -a inet6 win2kPING win2k (fe80::290:27ff:fe72:93b5): 56 data bytes64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=3.438 ms64 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 AdvertisementsTo 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 con -tent 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 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad14:13:34.909032 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad14:23:00.909021 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad14:31:44.909017 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad14:40:19.909023 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad14:49:38.909020 fe80::200:f8ff:fe32:5fc > ff02::1 icmpv6: router ad
Apparently, the router advertisement is sent to the all-nodes multicast group FF02::1 in intervals of between approximately 4 and 10 minutes. According to the specification of neighbor (and router) discovery [27], the interval should be chosen randomly between 3 and 10 minutes which thus has been verified.
On the client side, the router advertisements are received used to configure the interfaces on link with additional addresses and routes. For example, after the first advertisement had reached ‘win2k’, its Ethernet interface was assigned the new site local address fec0::1:290:27ff:fe72:93b5 constructed by concatenating the advertised prefix with the IPv6 suffix of ‘win98’. The routing tables where also updated accordingly with new routes for the prefix and the address.
6.3.6 IPv6 connectivityTo further test the IPv6 connectivity, I decided to try connecting my experimental net -work to the 6bone. The Linux IPv6 stack could handle the IPv6-in-IPv4 tunneling re-quired, so setting up a static tunnel to a site already connected to the 6bone seemed like a minor problem. However, my network was connected to Intranet protected by a very re-stricted firewall. IPv6 packets encapsulated in IPv4 packets use the IP protocol number 41 as an identifier while the firewall appeared to allow only TCP and UDP packets.
Despite several tries to have the firewall opened, I finally gave up since global IPv6 con-nectivity wasn’t really part of the scenario with an IPv4-only Internet provider.
6.3.7 Transition mechanismsAt 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 5. 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-PTThrough 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 ([email protected]) 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 StackIn this experiment, I wanted to test the dual stack functionality through an IPv4 applica -tion using the bump-in-the-stack mechanism described in Section 5.2.4. Luckily, the mechanism is included in the Winsock 5.0 stack installed on host ‘win98’, so no further configuration was needed.
Since I did not have access to the 6bone for accessing IPv6 resources, I installed an IPv6 enabled version of the web server Apache on ‘rg’. To be able to choose between IPv4 and IPv6, I also updated the DNS with additional records for separating IPv4 and IPv6 inter-faces. In the database file the following lines where added:
rg-4 A 10.0.0.1rg-6 AAAA fec0:0:0:1:200:f8ff:fe32:5fc
The DNS server was restarted, and the new configuration verified by pinging the “new” hosts.
On the client ‘win98’ I now started up a plain old IPv4 Netscape. I typed in “rg-4” as the URL, and instantly I reached the homepage on ‘rg’. The page had been transferred using IPv4, which also could be verified using tcpdump.
Now I tried the IPv6 reference “rg-6” as the URL, and again the home page was in-stantly visible! Using tcpdump again, I could verify that this time the page had been transferred using IPv6. That is, first Winsock had translated the IPv4 ‘A’ request for “rg-6” from Netscape to a both a ‘A’ and a ‘AAAA’ request. When only the IPv6 ‘AAAA’ response was returned, the protocol translation was used between Netscape and the IPv6 stack. Apparently the bump-in-the-stack mechanism works!
SOCKSFor the SOCKS server, NEC provides a publicly available SOCKS5 server-client solu-tion. The server was easy to install on the ‘rg’ and by using an enclosed patch the stan-dard SOCKS server extended with a protocol translator. The server needed no configura-tion as long as I was confident with web access.
On the client side, NEC provides their ‘SOCKSCAP’ software which “socksifies” the ap-plication 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 ProxyIt 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 follow-ing 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 INITIATIVESAs 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 JINIJini 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, self-diagnose, 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 dedi-cated to the Jini technology at http://www.sun.com/jini.
7.2 Universal PnPUniversal 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 CONCLUSIONSIt 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 net-working. 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 network-ing 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 pro-vide IPv4 will not be different from using private IPv4 addresses. Only when IPv6 is in-troduced 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 addi -tional 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. Person-ally, I was quite surprised over the incompleteness of IPv6. There is currently not one sin-gle 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 develop-ment 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 WORKIPv6 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 suit-ability 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/IPv6-HOWTO>
[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-rsvp-ipv6-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)”, draft-ietf-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 Tun-nels”, RFC 2529, March 1999.
[12] A. Conta, S. Deering, “Internet Control Message Protocol (ICMPv6) for the Internet Pro-tocol Version 6 (IPv6) Specification”, RFC 2463, December 1998.
[13] M. Crawford, “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, De-cember 1998
[14] M. Crawford, C. Huitema, S. Thomson, “DNS Extensions to Support IPv6 Address Aggre-gation 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”, draft-ietf-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 For-mat”, 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 Mecha-nism”, 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, Decem-ber 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, Decem-ber 1998.
[34] L. Toutain, J. Bound, “Dual Stack Transition Mechanism”, draft-toutain-ngtrans-dstm-00.txt (work in progress)
[35] G. Tsirtsis, P. Srishuresh, “Network Address Translation - Protocol Translation (NAT-PT)”, 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 PROCESSThe autoconfiguration process described in Section 3.4.2 can also be visualized in a flow-chart describing the steps involved – from activation of the interface to the final address assignment:
49
Create Link-local address
Unique?Manual/Random
addressNo
Yes
Assign to
interface
Router present?
Yes
Create address from given prefix
Site-local or global address assigned
Neighbor discovery
Stateless AC
Stateful AC
Interface activated
NoManaged flag set?
Yes
No
DHCP server
available?
Use Link-local address
No
Yes
Get configuration parameters
Site-local or global address assigned
IPv6@home
APPENDIX B IPV6 IMPLEMENTATION STATUS
Companies supporting IPv6Numerous 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 StacksThere are many IPv6 stacks available today ranging from limited 1000 byte stacks in-tended for embedded systems to fully featured stacks for use in an ordinary operating sys-tem. Below, some of the available IPv6 stacks possibly suited for the future market of home networks are listed.
Stack Platform More informationLinux 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
ApplicationsThere 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 com-mon resources for IPv6 software are listed together with their targeted stack.
Target Stack Resource URLLinux http://www.inner.net/pub/ipv6/
KAME ftp://ftp.kame.net/pub/kame/misc/
MSR IPv6 ftp://ftp.research.microsoft.com/users/msripv6/
Transition MechanismsImplementation of various transition mechanisms are available or underway. The status of some selected implementations are shown below:
Transition Mechanism Implementation status More informationNAPT-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 es-timated for Linux and BSD in Q1 2000
Jim Bound, [email protected]
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 detailsrg 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 Profes-sional RC2 (build 2128)
Windows 98 SE Windows 2000 Profes-sional 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
net-tools-1.53_v6-1.rpm
radvd-0.5.0-2
bind-8.2-6.rpm
apache-1.3.9-1_v6.rpm
SOCKS 5 server
MSR NAPT-PT Trumpet Winsock 5.0
Netscape 4.5
MSR IPv6 kit:ipv6.exe, ping6.exe, tracert6.exe
Interface dumps
Linuxroot@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 2000Interface 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 1Interface 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 1Interface 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 0Interface 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 ACRONYMS
AIIH Assignment of IPv4 addresses to IPv6 hostsALG Application Level GatewayBIS Bump in the StackCIDR Classless Inter-Domain RoutingDHCP Dynamic Host Configuration SystemDNS Domain Name SystemDS Differentiated ServicesDSTM Dual Stack Transition MechanismDSTM Dual Stack Transition MechanismFTP File Transfer ProtocolIANA Internet Assigned Numbers AuthorityICMP Internet Control Message ProtocolIETF Internet Engineering Task ForceIGMP Internet Group Management ProtocolIP Internet ProtocolIPv4 Internet Protocol version 4IPv6 Internet Protocol version 6ISP Internet Service ProviderLAN Local Area NetworkMTU Maximum Transmission UnitNAPT Network Address Port TranslatorNAT Network Address TranslatorND Neighbor DiscoveryNGTRANS Next Generation Transition Working GroupNIC Network Interface CardOS Operation SystemQoS Quality of ServiceRFC Request for CommentsRG Residential GatewayRPM Redhat Package ManagerSIIT Stateless IP/ICMP translatorSSN Social Security NumberTOS Type of ServiceTTL Time to LiveUPnP Universal Plug and Play
53