Transitioning Networks from IPv4 to IPv6 Andrew Schaumberg

Syed (Shawon) M. Rahman, Ph.D.

B.S. Software Engineering Undergraduate

Assistant Professor

Dept. of Computer Science & Software Engineering University of Wisconsin ­ Platteville 1 University Plaza, Platteville, WI 53818, USA Phone: (608) 342 1625, Fax: (608) 342­1965 Email: {schaumba, rahmans}@uwplatt.edu

Abstract Due   to   addressing,   routing,   and   security   limitations   of   Internet   Protocol,   version   4   [IPv4],   networks   are  anticipated   to  transition from IPv4 to IPv6. The probability of instantly transitioning all networks is low, thus a number of mechanisms have  been proposed and successfully applied to transition one network at a time. We have surveyed different transition mechanisms  with   emphases   on   their   respective   complexities,   alternatives,   and   deployment.  We  focus   on   dual­stack   and   single­stack  transition strategies while avoiding the complexity of wireless and mobile technologies.

1 Introduction While IPv6 is neither a low­cost nor disruptive technology, IPv6 does offer many improvements over its IPv4 predecessor,  including a vast address space, improved Internet Protocol Security (IPsec), simplified router responsibilities, and greater  network throughput over high maximum transmission unit (MTU) data links [12]. We present IPv6 transition mechanisms as  slow and incremental improvements for large and small networks alike.

1.1 IPv6 Transition Mechanisms IPv6 transition mechanisms have been designed with slow, incremental progress in mind. Dual­Stack Transition Mechanisms  [DSTM] support the broadest number of IPv4 and IPv6 applications by requiring hosts to simultaneously run both IPv4 and  IPv6 stacks. This approach is expensive, but guarantees that all network applications will work during the transition. When  the host no longer uses IPv4 applications, the IPv4 stack can safely be removed. When the entire intranet has converted to IPv6, yet the internet remains IPv4, Single­Stack Transition Mechanisms [SSTM]  become attractive. SSTM resembles typical IPv4 Network Address Translation [NAT] with an IPv6 twist: intranet hosts are  IPv6­only, the internet is IPv4­only, and the border router between them translates packets between IPv4 and IPv6 networks.  SSTM makes communication between IPv4 and IPv6 possible at the expense of heavy possible border router workloads.

1.2 Technology Overview To conserve the scarce supply of public IPv4 addresses, a number of technologies have been developed, including NAT,  Dynamic Host Configuration Protocol [DHCP], and Classless Inter­Domain Routing [CIDR]. However, as IPv6 affords over  79 billion billion billion times more addresses than IPv4, it is possible for IPv6 to obsolete such fine­grained address control. Realm­Specific IP [RSIP] is a new attempt to not only obsolete the use of Application Layer Gateways [ALG] in intranets  using NAT, but also restore the end­to­end nature of communication between hosts, which reduces router burden and better  supports IPsec. Modern NATs use ALGs to translate packets from the intranet to a form that makes sense to the internet.  Certain applications, such as FTP, require complex ALGs in order to function, which burdens the NAT router. Having a NAT  router use an ALG to tamper with packets also renders some communication encryption methods impossible or useless [19].

1.3 Regional IPv4 Address Need and IPv6 Policy It may be argued that the current distribution of IPv4 addresses is inequitable. Table 1 on the following page provides some  insight into the IPv4 situation of a handful of nations as of March 2004 [15].  At the time of IPv4 address supply exhaustion,  countries such as the United States may expect a large buffer of IPv4 addresses to use, while countries such as China may not.  From 2001 to 2006 inclusive, China has seen a 36% average annual growth rate in Internet population [8], while the United  States saw a 10% growth rate from 2001 to 2002 [10] and negligible growth from 2004 to 2005 [19]. Considering both the  different online population growth rates and current IPv4 address assignments, we may find the demand for IPv4 addresses  higher in China than the United States,  and a lower demand  the demand for IPv6 in the United States than China. Indeed, a   policy of slowly replacing old IPv4 equipment with IPv6­compatible equipment to minimize total cost is strongly advocated  in the United States: simply let the markets dictate the rate of replacement [12][7]. Determining the most correct or cost­effective transition strategy is well beyond the scope of this paper, but it is worth noting  different countries may have radically different transition deployment strategies for IPv6. Our research is intended to make the  IPv6 transition easier by distilling DSTM, SSTM, IP, NAT, and RSIP concepts into a form easily applied to most situations.

Internet  Additional addresses needed  Internet users  % Internet  IPv4 addresses  users per  to reach 38.8478% Internet  (2002) penetration assigned IPv4 address  penetration with a 1 person  assigned to 1 address ratio

Nation

Population  (2003)

World Bangladesh Canada China France Germany India Israel Japan Mexico Russia United Kingdom United States

6,321,688,311 146,736,000 31,510,000 1,304,196,000 60,144,000 82,476,000 1,065,462,000 6,433,000 127,654,000 103,457,000 143,246,000 59,521,000 294,043,000

613,040,319 150,000 16,840,000 56,600,000 16,970,000 32,100,000 7,000,000 1,940,000 56,000,000 3,500,000 18,000,000 34,300,000 165,750,000

9.70% 0.10% 53.44% 4.34% 28.22% 38.92% 0.66% 30.16% 43.87% 3.38% 12.57% 57.63% 56.37%

2,455,834,135 128,000 63,520,256 44,007,936 32,495,744 46,155,601 2,804,480 1,987,584 111,919,872 6,311,936 7,638,944 58,461,080 1,265,443,840

0.250 1.172 0.265 1.286 0.522 0.695 2.496 0.976 0.500 0.555 2.356 0.587 0.131

2,697 56,875,708 ­51,279,314 462,643,518 ­9,131,123 ­14,115,489 411,104,067 511,495 ­62,329,101 33,878,832 48,008,976 ­35,338,481 ­1,151,214,603

Table 1: IPv4 addresses by region, March 2004 [15]

2 Background 2.1 What Are IP, IPv4, and IPv6? IPv4 and IPv6 are versions 4 and 6, respectively, of the Internet Protocol, a network layer protocol whose primary service  supports cross­network identification and communication among uniquely identified hosts connected by a packet­switched  network. Thus, IP allows communication between hosts that need not be on the same physical bus/medium. A data link layer  underlying   IP   provides   a   unique   identifier   for   a   host,   while   a   transport   layer   atop   IP   provides   communication   service  guarantees if desired. For   instance,   provided   a   globally   unique   MAC   address   from   the   Ethernet   data   link,   IP   allows   a   host   in   Germany   to  communicate with a host in Canada, while the overlaying TCP guarantees no packets will be lost. To reach the Canadian host,  the   German   host   must   know   the   Canadian   host's   IP   address.   Where   the   data   link   address   allows   hosts   on   the   same  bus/medium to be differentiated, the IP address allows hosts on the same packet­switched network to be differentiated. IPv4 and IPv6 must then be similar solutions to the same problem of communicating between remote hosts, but how do IP  packets support this? IP packets consist of header and data fields, where the header contains information such as IP address  and the data is usually an embedded packet from the transport level. The structure of IPv4 and IPv6 packets are given in Table  2. Clearly, both similarities and differences exist. IPv4 Bits Name

IPv6 Bits Name

4

Version

4

Header length

8

DiffServ and ECN flags

20

Flow label

16

Header + payload length

16

Payload length

16

Identification

3 13

Fragmentation flags

4

Version

8

Traffic class

8

Next header

8

Hop limit

Fragment offset

128 Source address

8

Hop limit

128 Destination address

8

Protocol number

16

Header checksum

32

Source address

32

Destination address

32

Options (optional)

*

*

Payload data

Payload data

Table 2: IPv4 and IPv6 packet structure

2.1.1 What Are the Differences Between IPv4 and IPv6? IPv4 tries to provide several services using twelve or thirteen fields of four to thirty­two bits in length. IPv4 packets support  unicast,   multicast,   and   broadcast   addressing1,   variable   packet   fragmentation   and   header   length,   quality   of   service  (Differentiated Services [DiffServ] flags), congestion avoidance (Explicit Congestion Notification [ECN] flags), hop limiting  (originally Time To Live [TTL), and an optional but rarely used 'options' field for extra header data. Also included is a  protocol number indicating what kind of transport layer packet is embedded within the IPv4 payload, and a header checksum  for error checking on the IP header. Such fields  could  be reasonably and optionally handled by the transport layer packet  header, but this is not the case with IPv4. Interestingly, the bits now used by DiffServ and ECN were originally allocated for  “type of service [ToS]” [14]. From a software engineering perspective, IPv4 seems to be suffering from feature creep, poor  decomposition, high coupling, and a little bit of hacking. Let's refactor. IPv6 tries to provide few services using eight fields of four to 128 bits in length. IPv6 packets explicitly support unicast,  multicast, broadcast [1], and anycast [9] host addressing, ToS (via traffic class), QoS (via flow label), and hop limiting.  Notice IPv6 omits many of IPv4's fields, including flags, options, and checksum, leading to a more regular packet structure.  Interestingly, IPv6 routers are not responsible for handling fragmentation, like their IPv4 counterparts. Instead, the IPv6  sender  is  responsible  for  discovering  the  PMTU  and  sending  appropriately  sized  packets.   Fragmentation   is  not   needed.  Further, IPv6 supports payload lengths greater than 216 bits, called jumbograms [4], though both the underlying data link layer  and overlaying transport must also support this.

2.2 Why Transition from IPv4 to IPv6? The IPv4 address shortage is the most compelling reason to transition from IPv4 to IPv6. IPv4 addresses are 32 bits long,  whereas IPv6 addresses are 128 bits long. There are 2 32 (~4.295e+9) possible IPv4 addresses compared to 2128 (~3.403e+38)  possible IPv6 addresses. For each of the 6.671 billion people alive as of January 1, 2007, there are 0.6439 IPv4 addresses and  5.101e+28 IPv6  addresses. The projected date of IPv4  address supply exhaustion  is  controversial. Some sources predict  exhaustion on the year 2010 [16]; others 2012 [11]. The IPv4 address shortage has been aggravated by wasteful wholesale reservation of large blocks of IP addresses, but eased  by use of NAT, DHCP, and CIDR. Using NAT, a router may expose an entire inner network of hosts as a single host to the  outer network, greatly conserving IP addresses. DHCP may be used to automatically allocate and reuse a small number of IP  addresses among a large number of hosts, most of which are inactive at any given time. CIDR may be used to finely control  the reservation of IP address blocks. Before CIDR, IP addresses were reserved in chunks of 256, ~65 thousand, or ~16  million. Using CIDR, IP addresses may be assigned in chunks of any power of two, which is both more flexible and less  wasteful. To further reduce IP address waste, some propose renumbering IP networks to reclaim large chunks of unused IP  addresses. Indeed, large US organizations including Apple Computer, Boeing, IBM, MIT, and Stanford each have ~16 million  IP addresses reserved for their private use, while China holds a steadily growing pool of IP addresses now equivalent to more  than six of these ~16 million IP address blocks [18].

2.2.1 Why not Transition from IPv4 to IPv6? The majority of hosts on the Internet use IPv4, and aside from IPv6, IPv4 is the only network protocol used on the Internet.  For an full IPv4 to IPv6 transition, the underlying routing backbone of the Internet must be changed as IPv4 and IPv6 have  different header format, provide some different services, require slightly different data link and transport layers, and support  different maximum payload sizes. IPv6 must at least be supported at the firmware or software level, and could additionally  require changes at the hardware level. However, a significant number of IPv4 hosts are embedded devices, many of which simply cannot be upgraded, therefore the  cost of replacing such a large number of hosts is prohibitive [12]. When considering whether or not to support IPv6 in your  networks, we recommend considering the cost of purchasing, installing, and testing IPv6 equipment; the cost of training  technical support in the use of IPv6 equipment; and the cost of not using IPv6 at all.

3 Considering NAT in the Transition NAT is especially popular with home users who prefer to not purchase more than one public IP address and with  countries  having limited public IP supplies. NAT complicates the transition process, but the transition remains possible.

1. IPv4 multicast addresses must be in 224.0.0.0/4 and broadcast addresses end with 255, e.g. 137.104.255.255

3.1 NAT and ALG Hardest to transition from IPv4 to IPv6 are network applications which embed IP addresses or ports as part of their packet  payloads, such as FTP. In the FTP control stream, the client embeds the IP address and port to which the server should  connect. If this FTP is layered over IPv4 on a network using NAT, the NAT router must use an ALG to minimally inspect the  payload  of each  FTP  control packet,  determine  where the  IP  address and port  are contained,  and translate  these  fields  appropriately. Even worse, the ALG may have to alter IP packet length, TCP sequence number, TCP header checksum, and  maintain a running delta of the TCP sequence number for the connection lifetime [19]. If the NAT router joins IPv4 and IPv6  networks, the ALG workload is increased even further. Network administrators should be aware of IPv4, IPv6, and ALG  support in their NAT deployments. New network applications are being developed at a record pace, however, some of which  cryptographically prevent NATs from modifying packets, thus preventing some types of VPN and end­to­end IPsec [19].

3.1.1 RSIP as ALG Alternative RSIP eliminates the need to ALGs by granting each sender a lease on a public IP address [2]. Let us consider hosts “Alice”  and “Bob” to be connected through a RSIP border router. For Alice to talk to Bob, Alice first asks her RSIP gateway for a  public IP address. Her RSIP gateway maps Alice's private IP address to her newly granted public IP address, then informs  Alice of her public IP address and mapping. For Alice to talk to Bob, she must include a small RSIP header in each of her  packets destined to Bob, and Alice's RSIP gateway need only strip this header and forward packets between Alice and Bob.  Alice and Bob now share an end­to­end connection, and the RSIP gateway has no need of ALGs. Eliminating ALGs improves  both  IPsec between Alice and Bob, since the RSIP gateway does not need to tamper with their packet payloads, as well as  application support, since RSIP is a network layer protocol and should not impact the use of higher transport and application  layers [2]. The mappings established by the RSIP gateway may also include port numbers, which then allows multiple intranet hosts to  simultaneously use the same public IP address, provided no two intranet hosts simultaneously use the same port as well [2].

3.2 Multi­homed Networks under NAT Articles   sourced   both   in   proposing   DSTM   and   6to4   (discussed   later),   have   argued   that   NAT­based   IPv6   transition  mechanisms   suffer   from   a   lack   of   multi­homing   support:   it   is   the   NAT   router   that   maintains   the   state   tables   of   all  communication sessions and thus each session is limited to crossing a single NAT router. Robust firewall packages, such as  OpenBSD's Packet Filter2, overcomes this limitation by allowing border routers to synchronize their state tables. All border  routers are consistent. Further, scalability issues are often a concern of NAT­based solutions: it is the NAT router than must do the translation work  for all intranet hosts, so as the intranet grows, the NAT router becomes a bottleneck. Many protocols exist to introduce  redundancy in NAT systems, such as VRRP, HSRP, and OpenBSD's CARP. Such protocols allow a group of hosts to share a  common IP address with one host being 'master' and the rest as 'backups'. Work is not only shared among  master and  backups, but backups may become master if needed. As the intranet grows, a redundant group of border routers may also  grow. Thus,  we  do not   support   these  aforementioned  arguments,   which do  more  to  indicate  the  inflexibility  of  most   firewall  packages rather than a fundamental weakness of NAT.

2.   Information   regarding   Packet   Filter's   multi­homing    pfsync  mechanism   and   CARP   protocol   can   be   found   here:  http://www.openbsd.org/faq/pf/carp.html

Figure 1: A multi­homed intranet under NAT.

4 Dual­Stack IPv4­IPv6 Communication  DSTM is not a protocol itself, but simply a set of conventions and protocols to support communication between IPv4 and  IPv6 during the transition phase. The identifying characteristic of all DSTMs is the requirement that hosts simultaneously  support both IPv4 and IPv6 protocol suites, called stacks. By supporting both stacks, packets of one stack may be embedded  in packets of another stack, called tunneling.

4.1 6over4 and 4over6 Tunneling Given IPv6 hosts on the network edges and dual­stack routers to connect the hosts to a IPv4 core network, IPv6 hosts may  communicate with each other across the IPv4 core by embedding IPv6 packets in the data payload field of IPv4 packets. This  is called 6over4 tunneling [16], and is commonly used with 6to4, discussed in section 5.3. Using RSIP, multiple intranet hosts  may use the same public IP address. IPv4 hosts can communicate through an IPv6 network by embedding IPv4 packets in IPv6 packets. Such 4over6 tunneling  may be encountered [for example] in home networks recently converted to IPv6 but still connected to a IPv4 ISP. 

Figure 2: 4over6 tunneling supports communication with both IPv4 and IPv6 hosts.

4.1.1 Legacy IPv4 hosts in Transitioning IPv6 Networks Due to the cost of buying additional public IP addresses, NAT is particularly common in home networks. Home networks  may also need to support some legacy IPv4 hosts, like NAS devices or IP phones. Rather than using 4over6 tunneling, a 

feature that may require a costly firmware upgrade or more, legacy IPv4 hosts may be able to communicate directly with the  home network's dual­stack NAT router, or use an intermediary router within the intranet. Offloading work onto a router is a  particularly attractive solution for legacy hosts which may be impractical to upgrade to IPv6 or may be unable to afford the  additional work of 4over6 tunneling. Having need of both end­to­end IPsec and legacy IPv4  hosts, system administrators of  home networks may find either RSIP or traditional NAT more useful on a per­host basis. At this time, RSIP servers support   such dynamic use of traditional NAT or RSIP via a SLP template. The IETF is working on adding an option to  DHCP servers  to advertise RSIP services [19], as DHCP use is more widespread than SLP.

Figure 3: Support of legacy IPv4 hosts behind an intermediary router within an IPv6 intranet.

4.2 DSTM for Transparent Tunneling In the situation where a dual­stack host's local area network is native IPv6, the dual­stack host wants to communicate with an  external host connected by a IPv4 network, and there exists a dual­stack router at the IPv4 and IPv6 border, DSTM [5] may be  used as a means of communication between said hosts. DSTM is not a new protocol, but only defines behaviors of networks  hosts,     routers,   and  address   translation  mechanism.  DSTM  is   transparent  to  both  IPv4   applications  (whose  packets  are  bundled in IPv6 packets) and IPv6 networks (which carry IPv6 packets as usual). This transparency guarantees all IPv4  applications will work without modification under DSTM. IPv4 applications tunneled according to DSTM benefit from  IPv6's IPsec and other features within the IPv6 intranet as well. A DSTM server on the intranet provides all IPv6 intranet  hosts a temporary IPv4 address and optionally, a port range. IPv6 hosts then use a 4over6 tunnel to reach the router at the  IPv4 and IPv6 network border, at which point the border router decapsulates the IPv4 packet and sends it to the IPv4 internet. The greatest number of private IPv6 hosts  that may communicate to the external IPv4 network at any given time is equal to  the number of available IPv4 addresses in the DSTM pool. DSTM may also be extended to track transport protocol and port  numbers as well. Using extended DSTM, a large number of private IPv6 hosts may communicate via a single globally unique  IPv4 address, provided no two IPv6 hosts simultaneously require the same port number and transport protocol. For instance, a  maximum of 65,536 (216 available port numbers) TCP and 65,536 UDP concurrent IPv4 sessions per public IPv4 address are  supported. Extended  DSTM  allows  IPv6  networks  fuller  use of each IPv4  address  in  its  external IPv4  address  pool  in  exchange for added border router complexity. IPv4 applications are guaranteed to work in the IPv6 DSTM intranet at the cost of requiring every intranet host to be dual­ stack for DSTM's 4over6 tunnel. DSTM separates the IPv4 address allocation server from the IPv4 to IPv6 border router, so  traffic between IPv6 and IPv4 hosts can cross multiple border routers for any given session without problem. 

5 IPv6 Single­Stack IPv4­IPv6 Communication Like DSTM, SSTM is a set of conventions and protocols for to support communication between IPv4 and IPv6 during the  transition phase. The identifying characteristic of all SSTMs is the requirement that hosts simultaneously support only IPv6,  leaving only border routers to handle IPv4. By supporting only the IPv6 stack, SSTM requires fewer host resources.

5.1 IPv4­Mapped Routers Supporting dual­stacks may be considered wasteful as two sets of sockets, one for IPv4 and one for IPv6, must concurrently  listen for connections. As a workaround, a mapping scheme was proposed to map IPv4 addresses into a special class of IPv6  address space, e.g.  137.104.128.1 would map to ::ffff:137.104.128.1. However, due to differences between IPv4 and  IPv6 network layers (and hence ALGs), some applications, such as FTP, will not work. Many common IPv6 stacks do not  support this mapping mechanism for architectural or security reasons. Indeed, the mapping was soon regarded as harmful and  its use was recommended to be forbidden [13].

5.2 NAT­PT and NAPT­PT Routers Regarded as a last resort option when a dual­stack router should be avoided over all other alternatives, NAT­PT [17] used in  conjunction with the appropriate ALGs was proposed to be a complete single­stack solution supporting communication  between IPv6­only and IPv4­only hosts. NAT­PT may be used to dynamically allocate a small pool of globally unique IPv4  addresses among a large number of private native IPv6 hosts. Like simple DSTM, NAT­PT supports at most one IPv6 intranet  host per available IPv4 internet address. NAPT­PT is a set of extensions to NAT­PT to track protocol and port numbers like  extended DSTM, with identical IPv4 address reuse benefits. NAT­PT and NAPT­PT work via a IPv6 prefixing scheme. Suppose host Alice, having address a:1:1:c:e::1, in the private  IPv6 network wishes to speak to host Bob, having address  120.83.12.7, in the public IPv4 network. Alice sends a packet  with SA of a:1:1:c:e::1 and DA of beef::120.83.12.7. Note, the beef:: prefix has been [almost] arbitrarily chosen  by   Alice's   network   administrator.   As   a   CIDR   block,   we   may   define   prefix   as  PREFIX::/96.   So,   instead   of  beef::,  1:2:3:4:: could have been chosen as prefix. Continuing with our example, the NAT­PT router, which maintains a pool of public IPv4 addresses in the  66.103.48/24 block,   receives   Alice's   packet,   translates   it   to   IPv4,   and   sends   the   packet   into   the   IPv4   public   network   with   SA   of  66.103.48.4  and DA of  120.83.12.7. Per traditional NAT, when incoming packets are received by the NAT­PT router  with SA of  120.83.12.7  and  DA of  66.103.48.4, the  NAT­PT router  knows  to translate and  forward the packet to  a:1:1:c:e::1, host Alice. Unlike the  previous   1:1  IPv4   to IPv6   mapping attempt   of  ::ffff:137.104.128.1,  NAT­PT dynamically reuses  IPv4  addresses for the private IPv6 network, NAT­PT uses ALGs designed to translate between IPv4 and IPv6 protocols, and NAT­ PT has been extended by NAPT­PT to reuse IPv4 addresses even further. Unlike DSTM that requires dual­stack intranet hosts,  NAT­PT and NAPT­PT require all intranet hosts to be IPv6­only and single­stack. Using NAT­PT or NAPT­PT, intranet hosts  can not use IPv4 applications. Only the border router is IPv4­aware.

Figure 4: 6to4 and 6over4 tunneling over IPv4 internet for communication between  IPv6 hosts, and NAT­PT for communication between IPv6 and IPv4 hosts.

5.3 6to4 Routers 6to4 [6] defines a mechanism having strengths of both the straightforward IPv6 to IPv4 addressing of simple IPv4 mapping  and the dynamic reusable IPv4 address pool of NAT­PT. In 6to4 IPv6 intranets, an IPv6 host is assigned an address in the  format  2002:V4ADDR::/48  where  2002::/16  is the reserved 6to4 prefix and  V4ADDR  is the globally unique public IPv4  address that the IPv6 host will have on the IPv4 internet.  A notable limitation of 6to4 is that both sender and receiver can not have the same 6to4 address, which would result in a  collision. A router encountering such a situation would drop the packet, thinking no properly formed packet should ever be  addressed to its sender. 6to4 appears to be unaffected by the presence of a border router firewall, and 6to4 can coexist with  either IPv4 NAT or RSIP. By itself, 6to4 supports at most one IPv6 intranet host per public IPv4 address. However, a 6to4  border router with either IPv4 NAT or IPv6 RSIP may reuse the public IPv4 address for many of its intranet hosts based on  port number. Using IPv4 NAT, the 6to4 border router requires ALGs, and using IPv6 RSIP, the intranet hosts and border  router must all support the RSIP network layer. A combination of IPv4 NAT and RSIP may be used concurrently by the 6to4  border router to support the widest range of hosts. In these ways, 6to4 affords network administrators a degree of choice, but  it should be noted that 6to4 does not provide end hosts an end­to­end connection (even with RSIP), as the border router is  required to translate packets between IPv4 and IPv6 formats.

Conclusion There exist a number of mechanisms for network administrators to transition their networks from IPv4 to IPv6. The transition  technologies we have presented are robust to slowly and incrementally transitioning groups of networks, as well as mixed  protocol support of hosts within individual networks. We recommend using RSIP as much as possible  to reduce expensive ALG usage on border routers. RSIP need not  be  supported by every intranet host. NAT or other mechanisms may be used as a fallback on a per­host basis. We recommend using 6to4 as much as possible to simplify communications between IPv6 hosts. 6to4 only becomes useful  after a critical mass of IPv6 hosts exist, though again, NAT­PT or other fallbacks exist for use on a per­host basis. We  recommend  first   using   DSTM and  tunneling   to support  both  IPv4  and  IPv6  applications,  then  slowly transitioning  intranets to SSTM. We believe this gradual process will support legacy systems until they are totally replaced, and this will  ready the intranet for an IPv6 internet by the time of IPv4 address exhaustion. If while transitioning the intranet, the border  routers become a network bottleneck, we recommend making a redundant border router cluster to share workload, as shown  in Figure 6.

Figure 6: Redundant border router clustering to share workload of NAT's ALG operations

Acknowledgements We thank Dr. Syed Rahman for his support and helpful comments prior and during the writing of this article. We thank Daniel Stevens for his critiques of this research and years of knowledgeable guidance.

References [1] Barlow, J. IPv6 Hands­On. 2003. Retrieved December 2006 from  www.aarnet.edu.au/engineering/wgs/ipv6/presentations/IPv6%20101%20hands­on.pdf [2] Borella, M.; Grabelsky, D.; Lo, J.; Taniguchi, K. Realm Specific IP: Protocol Specification. In Internet Draft, October  2001. Retrieved March 2007 from http://tools.ietf.org/html/rfc3103

[19] Borella, M.; Montenegro, G. RSIP: Address Sharing with End­to­End Security. In the Proceedings of the Special  Workshop on Intelligence at the Network Edge, March 20, 2000. Retrieved December 2006 from  https://www.usenix.org/publications/library/proceedings/ine2000/full_papers/borella/borella_html/rsipusenix.html [4] Borman, D.; Deering, S.; Hinden, R. IPv6 Jumbograms. In Internet­Draft, August 1999. Retrieved December 2006 from  http://tools.ietf.org/html/rfc2675 [5] Bound, Toutain, Medina and al. Dual Stack Transition Mechanism (DSTM). In Internet­Draft, July 2002. Retrieved  December 2006 from http://tools.ietf.org/html/draft­ietf­ngtrans­dstm­08 [6] Carpenter, B.; Moore, K. Connection of IPv6 Domains via IPv4 Clouds. In Internet­Draft, February 2001. Retrieved  Decemeber 2006 from http://tools.ietf.org/html/rfc3056 [7] Charny, B. U.S. Shrugs Off World's Address Shortage. July 28, 2003. Retrieved March 2007 from  http://news.com.com/2100­1033_3­5055803.html [8] China Internet Information Center. Statistical Survey Report on the Internet Development in China. January 2007.  Retrieved March 2007 from http://www.cnnic.net.cn/uploadfiles/pdf/2007/2/14/200607.pdf [9] Ettikan, K. An Analysis of Anycast Architecture and Transport Layer Problems. 2000.  Retrieved December 2006 from  http://www.securitytechnet.com/resource/rsc­ center/presentation/APRICOT01/D2T3S1_Ettikan_Kandasamy_Karuppiah.pdf [10] Hupprich, L.; Bumatay, M. Global Internet Population Grows an Average of Four Percent Year­Over­Year.  Nielsen//NetRatings. February 2003. Retrieved March 2007 from http://phx.corporate­ ir.net/phoenix.zhtml?c=82037&p=irol­newsArticle&ID=538993&highlight= [11] IPv4 Address Report. March 2007. Retrieved March 2007 from http://www.potaroo.net/tools/ipv4/index.html [12] IPv6 Task Force, U.S. Department of Commerce: National Institute of Standards and Technology, National  Telecommunications and Information Administration. Technical and Economic Assessment of Internet Protocol Version  6 (IPv6). January 2006. Retrieved March 2007 from  http://www.ntia.doc.gov/ntiahome/ntiageneral/ipv6/final/ipv6final.pdf [13] Metz, C.; Hagino, J. IPv4­Mapped Addresses on the Wire Considered Harmful. In Internet­Draft, October 21, 2003.  Retrieved December 2006 from http://tools.ietf.org/html/draft­itojun­v6ops­v4mapped­harmful­02 [14] Postel, J. Internet Protocol: DARPA Internet Program Protocol Specification. In Standard, September 1981. Retrieved  December 2006 from http://tools.ietf.org/html/rfc791 [15] RIR of Worldwide. March 15, 2004. Retrieved March 2007 from http://www.nav6tf.org/documents/e­Nations­data.pdf [16] Sawant, A.  IPv6 Features and Migration from IPv4. In Bechtel Telecommunications Technical Journal, January 2004.  Retrieved December 2006 from http://www.bechteltelecoms.com/docs/bttj_v2/Article8.pdf [17] Tsirtsis, G.; Srisuresh, P. Network Address Translation ­ Protocol Translation (NAT­PT). In Internet­Draft, February  2000. Retrieved December 2006 from http://tools.ietf.org/html/rfc2766 [18] Wilson, P.; Buckridge, C. IP Adressing in China. In Apster issue 12, December 2004. Retrieved December 2006 from  http://www.apnic.net/news/hot­topics/internet­gov/ip­china.html [19] Wright, A. Internet Adoption Slowing ­ But Dependence on It Continues to Grow. March 29, 2006. Retrieved March  2007 from http://www.ipsos­na.com/news/pressrelease.cfm?id=3030