Department of Teleinformatics Network Services Royal Institute of Technology

5.1Transition Strategy

• 
  Upgrade the core IPv4 routers to support IPv6 first, and then propagate throughout the network until all access networks and nodes are IPv6 enabled.
  
• 
  Reverse the path and start with the edges of the network topology, i.e. local Intranets or home LANs. As the upgrade extends into the core net through the access network, the border between IPv6 and IPv4 moves further into the network as illustrated in Figure 5 .12.
  

The first strategy is beyond the scope of this report. Instead, the transition of home networks, and the affects of it appearing to the end users, will be covered. A typical transition of a home network connected to the Internet may be divided into four phases as shown in Figure 5 .13. In each step, IPv6 is gradually replacing IPv4 as the default protocol.

F
igure 5.12 Transition from the edges and in

Figure 5.13 Four phases in an IPv4 to IPv6 transition

1. 
   IPv4 Only. The situation for almost everyone of today’s households already connected to the Internet. As illustrated in Figure 5 .13(a), IPv4 is used throughout the network all the way from the end users into the core. All communications are carried over IPv4 and no IPv6 nodes have been introduced.
   

2. 
   IPv6 in the homes. IPv6 is introduced as a secondary protocol in the home networks. IPv4 is still used as the only protocol in the access network. In the home network, IPv4 is used as a complementary protocol to enable IPv4-only nodes to communicate or dual stack IPv4/IPv6 nodes to access IPv4 resources. By tunneling IPv6 packets inside IPv4 packets, IPv6 connectivity may also be achieved.
   

3. 
   IPv6 in the access network. To let the IPv6 enabled nodes take advantage of all the new features provided, IPv6 has to be implemented in the access network to interconnect the IPv6 islands contrived in the homes. At this stage, IPv6-only nodes will also become increasingly common while IPv4-only nodes will be limited to small old systems. Additionally, it will probably be more common to encapsulate IPv4 packets in IPv6 than the other way around.
   

4. 
   IPv6 Only. At this stage, there are no longer any IPv4-only nodes since they have been replaced with a newer generation product line. When all IPv4-only nodes has been eliminated, and thereby the need for IPv4 communication, IPv4 capable nodes can be completely transformed into pure IPv6 nodes. IPv6 can now be fully deployed as the only protocol and thereby provide everyone with the new features it brings.
   

The early transition phase has already begun in many research labs and institutions, which together creates a global IPv6 network called the 6bone [1]. The 6bone uses tunnels for transporting IPv6 inside IPv4 packets and spans across many countries.

5.2Transition Issues

As mentioned earlier, the IETF NGTRANS working group has presented various mechanisms for the transition from IPv4 to IPv6. The choice of appropriate mechanisms to use 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.1I
Pv6 Addressing

Each IPv6 network needs its own address space. A home network inside a house will most likely be limited to a single network segment, such as an Ethernet LAN with hubs. In this case, the IPv6 link local addresses (prefix fe80::/10) are sufficient to allow the nodes to communicate internally as illustrated in Figure 5 .14. These addresses are generated by the hosts themselves as described in Section 3.3.4 and therefore no stateful server such as DHCP is needed for the address assignment.

Figure 5.14 Addressing scheme for home networks

In areas with multiple households, such as a block with many flats or a complete residential area, it would also be necessary to use site local addresses since link local packets must not be routed. To employ site local addressing, a border router has to be configured to send router advertisements with a desired site local prefix, which then will propagate throughout the network and configure all hosts with additional site local addresses. The complete addressing solution is presented in Figure 5 .14.

5.2.2IPv4 Connectivity

After an introduction of IPv6 in the homes, many servers on the Internet will still be limited to only use IPv4. Therefore, an IPv6 enabled node inside the home network should be able to access these servers. Currently, there are several transition mechanisms for overcoming this problem.

NAT-PT/NAPT-PT

To enable IPv6-only hosts to communicate with IPv4-only hosts, the NAT-PT (Network Address Translation – Protocol Translation) was defined [35]. The NAT-PT works much like a plain IPv4 NAT where one IPv4 address is translated into another. In the NAT-PT however, the translation is made between IPv6 and IPv4 addresses. Additionally, the PT part of the NAT-PT makes a stateless translation between the IPv6 and IPv4 protocols using the Stateless IP/ICMP Translation (SIIT) method defined in [29]. A typical setup and the main function blocks in the NAT-PT are shown in Figure 5 .15.

F
igure 5.15 The NAT-PT/NAPT-PT transition mechanism

When a new session starts, a new IPv4 addresses is acquired dynamically from a predefined pool of IPv4 addresses, which then is used throughout the session. When the session ends, the address is returned to the pool ready to be assigned to another host.
A limitation of NAT-PT is that the maximum number of simultaneously connected hosts is limited by the number of IPv4 addresses in the address pool. To overcome that limitation, the NAT-PT mechanism was extended to NAPT-PT, where the extra P stands for Port [35]. With NAPT, a single IPv4 address can be used to communicate with external resources. This is made possible by using different TCP or UDP ports for each host. This means a maximum of about 63K hosts per IPv4 address.
A limitation of both NAT-PT and NAPT-PT is that the connectivity is limited to TCP and UDP traffic (ICMP queries are also supported since the ICMP header includes identifier that can match incoming replies with the outgoing queries). Another limitation is that protocols, which embed the network addresses in the higher application layers such as DNS, FTP and H.323, are not supported without further help. This can however be solved by using so-called Application Level Gateways (ALGs), which performs more in-depth analysis and translation of the corresponding packets.

DSTM

Another way of providing IPv4 connectivity in the IPv6 home network is to equip the hosts with dual IP stacks as proposed in the Dual Stack Transition Mechanism (DSTM) [34]. With dual stacks, an IPv6 stack is used for internal (and future external) communication, and an IPv4 stack provides true IPv4 connectivity. A problem with using dual stacks might seem to be the need for two IP addresses – one for each stack. Of course, the simplest way would be to assign each host both an IPv4 address and an IPv6 address. However, this approach would not benefit from the huge address space available in IPv6 since the IPv4 address assignment would limit the number of hosts. Instead, DSTM utilizes a dynamic address allocation mechanism called Assignment of IPv4 Global Addresses to IPv6 hosts (AIIH). Previously, AIIH was the name of a whole transition mechanism defined in the draft [34], but recently, the name changed to DSTM to emphasize the dual stack design model.
The AIIH mechanism is handled by an AIIH server – a combined DNS and DHCP server. The DNS part is used as a cache for assigned IPv4 addresses. For example, when an internal IPv4/IPv6 host requests communication with an IPv4 host, a temporary IPv4 address is assigned to the host and the binding is stored in the DNS as shown in Figure 5 .16(a). The dynamic assignment also works in the opposite direction, which is illustrated in Figure 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.

Figure 5.16 Internally (a) and externally (b) initiated IPv4 session using AIIH

SOCKS/Application proxies

Another solution based on SOCKS version 5 has also been proposed in [25]. By combining an ordinary socks server with a protocol translator, a transparent solution can be created. A downside with using SOCKS has always been the need for the special configuration on the hosts to “socksify” the application sessions. This would also cause a prominent need for support from home users if introduced into the home networks.
Similar to the SOCKS solution, application layer proxies can be used to translate between IPv4 and IPv6. For example, a web proxy server can easily be fitted with a protocol translator and thereby accept incoming IPv6 requests on one interface and send them out another one using IPv4 and vice versa. The implementations of such proxies are quite simple, but they still share the problem with limited application support and the need for special host configuration.

Summary

It is hard to tell which of these mechanisms is most suitable depending on the various demands of both the customers and the network administrators in different scenarios. The most promising solution for the initial transition steps seems to be the DSTM since it provides true IPv4 and IPv6 connectivity in parallel. The requirement of dual stack may however be a problem for embedded systems that today only have IPv4 stacks. The NAT and SOCKS solutions both have limited IPv4 connectivity since applications that embed IP addresses in higher protocol layers won’t work without special configuration. Another big disadvantage for using SOCKS in a home network environment is that the client application has to be “socksified” to work. This can easily lead to a massive demand for support since not everyone has the knowledge of a network administrator. Table 5 .5 summarizes the features of the mentioned mechanisms for a quick overview.
Table 5.5 Overview of transition mechanisms for IPv4 connectivity

	NAT-PT, NAPT-PT	DSTM	SOCKS 5/ Application proxies
IPv4 address requirements	1 per site1	1 per site1	1 per site1
Host Requirements	IPv6 stack	Dual IP stacks + DHCPv6	Application configuration
Advantages	Very low IPv4 address requirements (NAPT) Implementations available	True IPv4 connectivity Low IPv4 address requirements	Very low IPv4 address requirements Implementations available Simple configuration
Disadvantages	Limited IPv4 application support	No implementations available IPv4 stack required DHCP client required	Hosts need socks configuration Limited IPv4 application support
Specification Status	Internet draft	Internet draft	Internet draft
Implementation Status	Versions for NetBSD and Windows 2000 available	Expected for Linux and NetBSD in 4 months	Available for various systems

¹ A site may range from a single household to a residential area depending on the transition phase

5.2.3IPv6 Connectivity

Short after the introduction of IPv6 in the homes, home users will most likely want to be able to communicate with other IPv6 resources on the Internet. This IPv6 connectivity can be achieved even before the access or core networks have been upgraded by tunneling IPv6 packets in IPv4. It is already possible for anyone with an IPv6 enabled host to connect to the 6bone, which interconnects isolated IPv6 island all over the world using tunnels [1]. However, the methods developed for this scenario is beyond the scope for this report.

5.2.4Old Applications

Today there are thousands and thousands of Internet applications based on IPv4. This includes all kinds of applications such as simple diagnostic tools, games, web browsers, and mail clients. If a home network would be upgraded to IPv6, it would be feasible, or required, to be able to use these existing applications without any fuss. Without this possibility, users would have to wait until their applications were upgraded to handle IPv6, where a time schedule is hard to estimate.
The NGTRANS working group has announced a mechanism for solving this problem called the Bump-in-the-Stack Technique [36]. By extending an ordinary IPv4 stack with extra functionality for IPv6 connectivity as illustrated in Figure 5 .17(a), a transparent solution can be achieved.
The first addition to the IPv4 stack is the Extension Name Resolver. It translates the IPv4 application’s single DNS request to a request for both ‘A’ and ‘AAAA’ records (the drafts have not been updated with the ‘A6’ record type yet). If an ‘A’ record could be found, traditionally IPv4 communication can continue using the IPv4 stack. If only an IPv6 entry (‘AAAA’ or ‘A6’) could be found, the Address Mapper maps the returned IPv6 address to an IPv4 address taken from a local address pool. The address pool may contain private address such as 192.168.0.0 or 10.0.0.1 since the scope is limited to the host. When an IPv4 address corresponding to the IPv6 host is available, the communication can be set up through the Translator and the IPv6 stack. The translator uses SIIT [29] for the translation, and the IPv6 stack is a fully featured stack with features such as Neighbor Discovery and security.
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
  
• 
  T
  he 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 introduction of IPv6.

Download 290.3 Kb.

Share with your friends: