A Second Chance to a Fair Share of IP – IPv6

~Deployment Considerations~

The new version of the Internet Protocol (IP) has been the talk of networking professionals and researchers for some time now yet it never seemed to pick up steam, to materialize into actual deployments. Network and Business planners have listened to those cheering for IPv6 and to those who eloquently ignore it but they could not pick up a trend, they could not see a new wave rising, at least not yet. And so, year after year the IPv6 thoughts were set aside to make room for those that deal with stretching capital expense budgets to fit increasing demands for network services. Year after year IPv4 seemed enough. Were those predicting its demise wrong all along? Is IPv4 good enough after all?

Consider this simple metric: From a market analysis perspective, a technology sees mass adoption when 20% of the population is using it [1]. The United Nations reported that only 36 of the 208 countries have reached this level of adoption and they represent only 15% of Earth’s population. At the same time the use and adoption of IP based services is on an aggressive rise due to a true e-revolution. With a surge in the number of devices that require addresses, IPv4 lacks the resources to bring the technologies it supports to mass adoption status worldwide. This reveals a clear mismatch between the demand for the protocol and what it is capable to offer. There are of course band aids but they come at a cost and they can only be temporary solutions. When all the projected consumer devices such as mobile phones, home and Internet appliances, cars and cameras are IP enabled, it will not be on IPv4, it will most likely be on IPv6.

This paper’s structure reflects its two goals. The first part of the paper provides a measure of the current worldwide interest in IPv6, a review of its major realistic benefits and a review of the available transition mechanisms. The second part discusses several deployment scenarios for the Service Provider and Enterprise Networks.

Part I -IPv6 is a Strategic Choice

The limited IPv4 address space is in itself a constraint but that is not the whole story, the addresses are disproportionately distributed in the world. The United States is the birth place of the protocol and most of its uses including the killer app called “The Internet”. It was natural that the United States took the lion’s share of the address space in the process and this is why Stanford University has more IPv4 addresses than entire China.

The power of network infrastructures, of digital resources and applications, of the Internet is impossible to ignore in this day and age. Regardless of scale, be it home, business or country, networks become essential resources for more and more processes and services. They enhance productivity and provide new business opportunities leveling the playing field for a global economy. They provide knowledge and entertainment thus changing the way we live and learn. To take advantage of all these benefits, larger infrastructures have to be built and most importantly more devices need to be interconnected. For these reasons users, businesses and economies are growing hungry of IP addresses.

The little, useable pieces left of the IPv4 address space will not be sufficient on the long run for the new comers to the Internet revolution. While the US feels comfortable with the addresses it has, other countries such as Japan, China and the European Union block acknowledge that their economic growth will be stifled by the limited IPv4 address space. This is why IPv6 is seeing a significant larger interest in Asia Pacific and Europe then it does in North America. IPv6 is seen by the world as a second chance to take a fair share of this vital and critical resource.

Recognizing the importance of adopting IPv6, governments started to drive and support a flurry of initiatives to promote it. Official statements of intent such as e-Japan [2], e-China [3] or eEurope-2002 [4] led to significant nationwide research projects on IPv6 such as SuperSINET in Japan [5], CERN in China [6] and 6NET in Europe [7]. Tax incentives and encouraging legislation was the follow up step that spurred commercial deployments. Service Providers are now building entire state of the art infrastructures for IPv6. Consumer devices are also being readied for the new protocol. SONY plans to have all its products enabled for IPv6 by 2005 [8]. These business commitments to IPv6 mark a new phase in its adoption. Governments helped make it happen by recognizing IPv6 as a matter of national interest, a strategic choice that had to be made.

One might still ask where is US standing in this race. It clearly is behind and that is due in part to inertia and in part to the comfortable amount of IPv4 addresses at its disposal. Nevertheless the IPv6 stakes were raised in US as well and that in great measure due to the government. The Department of Defense (DoD) announcement of intent to migrate its entire infrastructure to IPv6 by 2008 [9] drew everyone’s attention to the new protocol. All its suppliers, all its Service Providers and all the allied departments of defense worldwide quickly followed suite and announced their interest in IPv6. As it happened in the past with the work done by DARPA, DoD might just be the catalyst for IPv6’s adoption process in the US.

What do all these examples have in common? Someone, somewhere took the long term view on the subject. Whether it is for millions of IP enabled cell phones or for digital sensors on each soldier and piece of military equipment, the need for addresses is acute and IPv6 represents the long term solution.

An IP Evolution not an IP Revolution

In an attempt to raise awareness for IPv6, its features are sometimes overemphasized leading to misunderstandings. It is thus important to state up front that IPv6 represents and evolutionary phase of IP. No revolutionary changes were made to the protocol besides the increase in the addressing space and a modified header structure. There are of course tweaks and improvements that were proposed based on the experience gained operating IPv4 but overall the differences are not dramatic. Before discussing deployment aspects of IPv6 it is worth reviewing some of its properties in a parallel to IPv4. This will help dispel some of the common myths regarding IPv6 and provide arguments for supporting certain deployment choices.

Addressing

The most important feature of IPv6 is its addressing structure [10]. There are several major aspects of the changes that were made in IPv6:

a) A four fold increase in the number of bits provides a significant increase in the size of the address space. IPv6 supports 340,282,366,920,938,463,463,374,607,431,770,000,000 addresses thus making it feasible to assign multiple unique prefixes to every human being. While generally speaking more is better, one has to consider the impact of a larger address on the existing infrastructures. Routing systems that use 64 bit CPUs, busses or memory structures would now need, in principle at least, 4 cycles to process both the Source Address (SA) and the Destination Address (DA) of a packet while in the case of IPv4 they could do the same in a single cycle. The larger number of prefixes can generate larger routing tables and lead to higher memory requirements and longer lookup times. Many of these issues have been tackled already and optimizations have been implemented in the networking equipment.

b) There is no concept of broadcast addresses in IPv6, only: Unicast, Anycast and Multicast addresses. The functions of broadcast are now implemented through multicast. This has a positive impact on the utilization of network resources.

c) The address structure enforces scoping, a very powerful tool for the control plane as well as forwarding plane of network elements.

d) Interfaces have multiple addresses of various types and scopes such as: Global Unicast Addresses (for off-net communication), Unique Local Unicast Addresses (for on-net communication, it replaced the original Site-Local), Link-Local Unicast Addresses (for link communication with high emphasis on control plane) and then a set of Multicast addresses. Anycast addresses could also be present.

More bits means more addresses for unicast connectivity, more addresses for multicast services and plenty of bits to get creative with managing a network’s addresses. Despite its abundance, the distribution of this resource is still very well regulated by the registries in order to avoid a chaotic growth of the IPv6 Internet routing tables. Currently prefixes are assigned from the 2001::/16, 2002::/16 (for 6to4 tunneling) and 2003::/16 (recently started) pools while the experimental 6BONE network uses addresses from the 3FFE:/16 pool.

Ultimately there is no stronger case for deploying IPv6 then its address resources.

Packet Header Format

The IPv6 packet header has seen several changes that are driven mainly by the lessons learned from the IPv4 operation:

a) The header is fixed in length at 40 bytes. A fixed sized header improves the performance of the lookup processes in packet switching devices. It also removes the need for a “header length” field in the packet header.

b) Routers are not allowed to fragment packets, only the source can fragment its packets based on the discovered path MTU. This constraint is also beneficial to the packet switching network elements because fragmentation impacts the forwarding performance and uses additional device resources. This constraint eliminates the need for a “Fragment Offset” field.

c) It is thought that the header checksum was not that useful in IPv4 networks so the field was eliminated and the function enforced at higher layers.

d) IPv6 has a new field, the Flow Label. Despite being a powerful tool to carry packet information important for making switching decisions, information that might be hidden in the packet load (which could be encrypted) , this field’s usage has yet to be defined.

e) The Header Options used in IPv4 were moved into specialized headers that are piggybacked to the main header. These headers are called Extension Headers and they can offer more flexibility in implementing new features or feature improvements.

Most of the changes made to the packet format are intended to optimize it compared to its IPv4 counterpart. The changes are not dramatic but they do reflect certain new operational principles introduced in IPv6.

Control Protocol (ICMPv6)

The Internet Control Message Protocol (ICMP) deserves particular mention in the case of IPv6. ICMP gained more prominence in the new version of IP as it was employed to perform more functions. It performs the functions traditional in ICMPv4 along with additional control messages, the functions of IGMP and those of ARP. Moving ARP functions at layer three makes sense, it simplifies the protocol stack. Neighbor Discovery, Router Discovery and Host Autoconfiguration all rely on ICMPv6.

ICMPv6 was re-engineered into a more complete protocol that is an integral part of IPv6. It is a critical part of the proper operation of IPv6.

Routing Protocols

All IPv4 routing protocols are implemented in IPv6 and, in general they are similarly implemented. RIPng, EIGRPv6 and OSPFv3 are new protocols while IS-IS and BGP have IPv6 extensions. Some differences exist with respect to their IPv4 counterparts such as IPSEC authentication and encryption for OSPFv3 instead of MD5 but very few significant innovations were made for their implementation.

Routing Protocols have not changed significantly from IPv4 to IPv6.

Multicast

New powerful applications make multicast a critical part of network’s service offering. Its deployment in IPv4 experiences the constraints imposed by the limited number of multicast addresses available along with some of the implementation idiosyncrasies. Unlike its predecessor, IPv6 was mindful of multicast from the beginning and was integrated seamlessly into the protocol thus leading to cleaner implementations. Multicast is also a critical part of the IPv6 Control plane.

The larger address space automatically helps multicast. Powerful scoping is also particularly useful in containing traffic in the targeted domain. IPv6 kept only the multicast routing protocols proven most useful with IPv4: PIM-SM, PIM-SSM and PIM-Bidirectional. Their implementation is similar to the IPv4 implementation. The large addresses also allowed for a new Rendezvous Point (RP) discovery mechanism where its unicast address is embedded in the multicast group address [11]. One notable protocol missing is Multicast Source Discovery Protocol (MSDP) which was supposed to be a temporary solution in IPv4 Inter-Domain multicast architectures but ended up settling in. Standardization groups refuse to adopt MSDP for IPv6 and its absence changes the design of Inter-domain deployments.

With its larger address space and scoped addressing architecture, IPv6 makes multicast deployments significantly easier. IPv6 relies on multicast for its basic operation.

Quality of Service (QoS)

Very little differentiates IPv6 from IPv4 as far as QoS is concerned. The Differentiated Services (DiffServ) and Integrated Services (IntServ) architectures and implementations are the same. IPv6 can claim a few extra fields in the header than could be used for classification purposes but with no particular value. It is often said however that IPv6 offers better QoS and that is due to its “Flow Label”. While it is true that this header field can be a very versatile tool for both classification and for RSVP its use still has to be defined.

At this point in time IPv6 QoS capabilities are practically identical to those of IPv4 QoS.

Mobile IP

Mobile IP enjoyed a lot of attention in the process of developing IPv6. IPv6 is considered by the 3GPP2 and 4G telephony standards with MIPv6 being a very important feature to be leveraged in mobile networks. Some of IPv6’s features such as the Routing extension headers could be creatively used in solving some of the problems faced by MIPv4. This led to a better implementation compared to IPv4. MIPv6 standardized a route optimization that allows hosts to exchange packets directly with the mobile node at its new location instead of going through the home agent. Security was introduced for the rerouted traffic and for the binding processes.

Mobile IPv6 has a more robust implementation then IPv4, it is imbedded in the protocol.

Security

IPv6 holds the promise of returning the internet to a peer-to-peer communication model. This explains the interest that applications developers have in it. In that light the mandated [12] use of IPSec seems natural. It provides the means to authenticate traffic sources and secure their traffic. If and when all IPv6 hosts will consistently implement IPSec and a reliable key distribution protocol is available, the IPv6 protocol would probably be more secure then IPv4. Until that happens however, it is premature to claim significant security improvements for the new version of IP. One might even be concerned that some of the safeguards developed for IPv4 did not get a chance to be implemented in IPv6 thus making it less secure. Some intrinsic features of IPv6 make it less prone to some threats. As an example, it is unreasonable to scan for active addresses because the address space is so large. This eliminates some reconnaissance threats and some virus’s ability to spread. Lack of broadcast reduces the smurf-like attack options. While minimizing the exposure to some threats, IPv6 also opens the door for new types of attacks. The Routing Extension Header, a header that must be processed by all hosts, can be abused. The IPv6 tunneling mechanisms offer new means to penetrate perimeter security measures. For the most part however, IPv6 faces most of the threats common in IPv4.

Overall, IPv6 is not more or less secured then IPv4 at this time. For now IPv6 relies mostly on the same perimeter and host security best practices used in IPv4 deployments.

Few IPv6 characteristics were briefly highlighted here with the intent to eliminate some common misperceptions about the protocol. Table 1 summarizes the conclusions reached during this overview.

Table 1. Brief Summary of IPv6/IPv4 features comparison.

In the end this exercise narrows down the arguments in support of an IPv6 deployment but they paint a more realistic picture of the protocol. For more information on the concepts discussed in this review, the reader is advised to consult the IPv6 references that present the details of the protocol [13].

Transitioning Tools

Another prerequisite to a discussion on deploying IPv6 is an understanding of the tools that can be used in the transitioning process. There is of course the option of building new infrastructures exclusively for IPv6. Several Service Providers choose this path today however, it is expected that most deployments will see a gradual migration process from IPv4 to IPv6. For these reasons a lot of effort went into identifying and implementing several migration technologies [14].

Dedicated physical or virtual circuits

One obviously simple way of interconnecting islands of IPv6 without impacting the IPv4 services is to enable the protocol on dedicated links or physical circuits. This approach ensures the separation of traffic types and a better control of the resources dedicated to each. The traffic separation can of course be achieved virtually with the help of virtual circuits: Dedicated DLCIs over Frame Relay, PVCs over ATM or VLANs over Ethernet. The virtual circuit option might mean a better use of resources because it is multiplexing IPv4 and IPv6 however the traffic has to be prioritized accordingly.

This approach requires only that the network elements at the two ends of the circuit support IPv6 alongside IPv4 in a dual stack.

Tunneling

The idea to place a certain type of traffic into an envelope and send it over a network with the network having no idea of the envelope’s content is widely used. It is an obvious candidate to transporting IPv6 over an IPv4 network. Traditional encapsulating mechanisms such as GRE or L2TPv3 (over IPv4) can be used but new ones were developed specifically for IPv6. Also IPv6 PPP sessions can be piped through L2TP tunnels established over IPv4. Table 2 summarizes the various tunneling mechanisms that can be leveraged in deploying IPv6.

Table 2 Tunneling Mechanisms for Transporting IPv6 [14]

Each mechanism has its benefits and is best suited for certain parts of a network. Tunneling is very valuable in initial phases of deployment and in cases where portions of a network that is not IPv6 capable need to be avoided. As operators commit to large, high-performance deployments tunneling will be less prominent.

IPv6 over MPLS Infrastructure

Most Service Providers (SP) and Internet Service Providers (ISP) of all sizes leverage MPLS in the core of their network in order to benefit from the many advantages it offers. There is even talk of some large Enterprises considering MPLS cores. For this reason it is rather important to consider IPv6 migration options over such infrastructures. They of course can use all mechanisms available for IP switched packets however, label switching provides additional options. For most part, label switching does not need to know what type of packets are transported and their IP version. The migration options available in an MPLS based environment are summarized in Table 3.

Table 3 Migration Mechanisms Available in MPLS Environments [14].

The control plane for MPLS remains IPv4 based. The forwarding performance is independent of the packet being transported so it is expected that it will match the label switching performance, most often line rate for the Core platforms. At the same time the impact on existent IPv4 services is minimal making these solutions very enticing for large, scalable IPv6 deployments. They also offer the possibility to deploy IPv6 Virtual Private Network without implementing an IPv6 based (control plane) MPLS network.

Translation

Translation technologies can be used in two different ways. On one hand IPv6 traffic can be translated into IPv4 and then translated back to IPv6 thus providing a means of communication between two isolated IP6 hosts. On the other hand it provides the means for an IPv6 only host to communicate with an IPv4 only host. The translation mechanisms available for IPv6 are summarized in Table 4.

Table 4 Translation Mechanisms [14]

Since translation mechanisms typically rely on process switching the packets, they experience significant performance constraints. Most of these mechanisms have scalability limitations and exhibit single points of failure. These factors should be taken into account when integrating these mechanisms in a planned IPv6 deployment.

The review of IPv6’s true benefits and that of the tools available to transport it over IPv4 sets the stage for a discussion of deployment scenarios in various network environments. Service Provider and Enterprise Networks have different requirements and goals that shape the design of any IPv6 services. The leading deployment options for both of these network types will be presented in Part II of this paper.

Ciprian Popoviciu PhD, CCIE
Cisco Systems

References

[1] Tony Hain, et al. "e-Nations, The Internet for all" North American IPv6 Task Force

[2] http://www.kantei.go.jp/foreign/souri/mori/2000/0921policy.html

[3] http://www.chinaipv6council.com/index.jsp

[4] http://europa.eu.int/information_society/eeurope/2005/index_en.htm

[5] http://www.sinet.ad.jp/english/

[6] http://www.technewsworld.com/story/news/39233.html

[7] http://www.6net.org

[8] http://www.ipv6style.jp/en/interviews/20030212/index.shtml

[9] http://money.cnn.com/services/tickerheadlines/mw/054991.htm

[10] R. Hinden, S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture”, RFC3513, April 2003

[11] P. Savola, B. Haberman "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address" <draft-ietf-mboned-embeddedrp-06.txt>, June 2004

[12] S. Kent, R. Atkinson "Security Architecture for the Internet Protocol", RFC2401, November 1998

[13] R. Desmeules, “Cisco Self-Study: Implementing Cisco IPv6 Networks (IPv6)”, Cisco Press, May 2003

[14] Mallik Tatipamula, Patrick Grossetete, Hiroshi Esaki "IPv6 Integration and Coexistence Strategies for Next-Generation Networks", IEEE Communications Magazine, January 2004