IPv4 or IPv6—Myths and Realities

This chapter is from the book

Global IPv6 Strategies: From Business Analysis to Operational Planning

Learn More Buy

This chapter is from the book

This chapter is from the book 

Global IPv6 Strategies: From Business Analysis to Operational Planning

Learn More Buy

IP: Today's Constraints and Tomorrow's Solutions

Despite 15 years' worth of efforts to develop, implement, and deploy a new version of IP, "IPv6 lovers" and "IPv6 haters" still argue about what IPv6 can do and cannot do. This debate has resulted in many myths and rumors, which often are contradicted by facts and papers, such as "The Case for IPv6," which was published as a draft RFC in 1999 (draft-ietf-iab-case-for-ipv6-06.txt). To offer a realistic and honest perspective on the benefits and challenges of the new protocol, this section addresses some of the common questions related to IPv6's capabilities. The IPv6 myths must be debunked and its true strengths must be reiterated. This is a necessary step in understanding where the strengths and weaknesses of the technology stand.

Is IPv4 Running Out of Addresses?

One of the most intense debates related to IPv6 focuses on the prediction of the Internet's doomsday, the day when we run out of IPv4 addresses. For the most part, the networking community is in agreement that the IPv4 address space will be depleted. The question left unanswered is: When will this event occur?

Much has been written about this question, but forecasts are not easy to make. By 2006, the two main predictions that emerged rely exclusively on different approaches to extrapolating historical IPv4 address allocation data:

• Exhaustion of addresses by 2010: This prediction is based on an analysis by Tony Hain.¹¹
• Exhaustion of addresses by 2012: This prediction is based on an analysis by Geoff Huston.¹²

If the situation is dire, why aren't people more concerned? This is likely the result of three factors. First, the value of an IP address is not market driven. If the value of an IP address were to grow with demand, people would take notice and would be able to calculate the cost versus the benefit of migrating to IPv6. Second, the Internet community "cried wolf" before and it turned out not to be an unsolvable problem. Third, because the Internet, like water and electricity, has become a utility service managed by others, users do not feel the need for strategic planning.

As discussed in the previous section, "Looking at the Numbers," the IPv4 address space cannot sustain the Internet's growth. For any long-term perspective, IPv6 becomes a natural choice. As with any limited resource, the IPv4 address space will be exhausted one day. IPv6 will pick up where IPv4 left off and it will plumb the Internet for a long period of time, accommodating a very large number of devices.

At the beginning of 2008, of the 255 possible /8 prefixes, more than 80 percent /8 IPv4 subnets were allocated to RIRs by IANA.¹³ In turn, each RIR allocates address space to its members, service providers, government agencies, and enterprises. Each organization uses a certain percentage of the full address space assigned to it.

Answer: Yes, IPv4 represents a finite resource that will get exhausted. In the context of the current allocation policies, predictions are converging to an IPv4 address space exhaustion date between 2010 and 2015. Whether it is 2010 or 2015, the date is rather near. Would you postpone an IP upgrade to find out which prediction is correct?

Are NAT Benefits Lost by Moving to IPv6?

Network Address Translation (NAT) use is a worldwide reality. It is the front end to enterprise and home networks. NAT was developed to conserve IPv4 addresses. Without its widespread use, the Internet would certainly have already exhausted its address space.

The private address space definition (RFC 1918, Address Allocation for Private Internets) and its usage (RFC 3022, Traditional IP Network Address Translator [Traditional NAT]) have been documented in several papers. The NAT operation is simple and effective—one globally known IPv4 address on the Internet with millions of "private" IPv4 addresses available for internal use. The process obscures or hides the actual IP addresses of host computers in the NAT environment. It also makes communication with them more complicated when it is initiated from outside the NAT domain. This is one of the reasons why IPv6 supporters regularly denounce the "dark side" of NAT, referencing IETF documents such as RFC 2993, Architectural Implications of NAT, and RFC 3027, Protocol Complications with the IP Network Address Translator.

The acceptance of NAT in the '90s as a solution to IPv4 address exhaustion, far before the availability of any IPv6 product, has pushed Internet users to ignore the increased level of complexity, its trade-offs (and potential costs), and the impact on applications and connectivity. Users became comfortable with NAT, to the point where they assigned it more functionality than it actually provides. A common NAT-related misconception is that it enhances security. This is an important factor to consider when developing an IPv6 transition strategy, as nobody wants to loose NAT's perceived benefits. To address all user concerns related to networks without NAT, the IETF developed RFC 4846, Local Network Protection for IPv6, which provides guidelines and explanations of IPv6 features and configurations that match the perceived benefits of NAT.

Answer: Although NAT breaks the fundamental end-to-end model of the original Internet, it is not the goal of this book to argue about the pros and cons of NAT. It is far more important for organizations that are using NAT in their environments to understand that none of the real and perceived benefits of NAT are lost in IPv6.

Is IPv6 Improving Routing?

The evolutionary and not revolutionary nature of the new protocol is probably best exemplified in the case of its routing protocols. No new, dramatic concepts were introduced. The IPv4 routing protocols were, however, rebuilt in a cleaner way. RIPv2 led to RIPng, OSPFv2 led to a similar but improved OSPFv3, and EIGRP, IS-IS, and BGP were extended to support IPv6.

The IPv6 routing protocols have no tricks to help alleviate the concerns about the size of the Internet routing tables. Considering the size of the Internet routing tables in Q1 2008 (+250,000 entries) and the lack of routing enhancements, some people argue that IPv6 is not good enough for a nest generation protocol.

Answer: Although the scalability of the Internet is indeed a pressing problem and the subject of many research efforts, we need to remember that during its inception and development, IPv6 was built to solve the addressing problems and not the routing problems. These goals were set in IETF with the agreement of the engineering community. Although the plentiful address resources could lead to a cleaner Internet, IPv6 is not better or worse than IPv4 in terms of dealing with the Internet's scalability.

A new generation of routers, including edge routers such as Cisco ASR 1000 series, is designed for both IPv4 and IPv6 and can support gigabytes of memory, amounting to millions of routes. This means these routers can comfortably cope with the growth of the Internet routing tables. The real challenges, however, relate to the speed of convergence and the stability of the Internet. All of these are areas for future innovation.

Does IPv6 Support Multihomed Sites?

It is often stated that multihoming of sites is an IPv6 problem. Multihoming is not a protocol problem. In the case of IPv6, the challenges are due to a set of prefix allocation policies enforced by the RIRs.

Multihoming is widely used by enterprises for the following reasons:

• Connect sites of a network with global reach: Organizations with multinational infrastructures will connect to multiple service providers in different countries.
• Backup for the link to the SP: An enterprise can have several links into the same provider that protect each other in the event of a failure.
• Backup SP: An enterprise can connect to several SPs in order to protect against SP failure.

Multihoming is a problem for IP in general and not for IPv6 alone. IPv4 faces the same issues with multihoming as IPv6. Current multihoming techniques impact the size of the Internet routing table. In February 2008, there were more than 250,000 entries in the IPv4 backbone BGP routing table.¹⁴ The root cause of the problem is a lack of a good framework for prefix aggregation. IPv6 routing is based on the same protocols as IPv4, so all multihoming mechanisms available in IPv4 can be used in IPv6. The size of the IPv6 prefixes—which, within the Internet routing tables, is driven through prefix allocation policies—facilitates better address management and good aggregation.

Figure 2-4 is a summary of the IPv6 prefix allocation policies. The address space is managed by IANA, which allocates prefixes to the RIRs, which in turn allocate prefixes to ISPs on the provider dependent track or directly to organizations (enterprises, educational institutions, and so forth) on the Provider Independent track.

Figure 2-4 IPv6 Address Allocation Policies

A 2006 analysis of the IPv6 global routing tables, "Have We Reached 1000 Prefixes Yet? A Snapshot of the Global IPv6 Routing Table," presents the effectiveness of the policy approach at that stage in the deployment of IPv6.¹⁵ Geoff Huston's well-respected BGP Update site tracks and analyzes historic IPv4 and IPv6 BGP routing information, a valuable resource for up-to-date information.

These policies enforced by Registries preempt the use of multihoming as done in IPv4. In the absence of a multihoming mechanism that would work in the context of IPv6, enterprises are faced with significant operational challenges when integrating IPv6. Whenever an enterprise is dissatisfied with its provider and wants to switch to another one, it would have to renumber its network; and this is an expensive proposition. The provider-dependent allocation policies are not acceptable to enterprises.

To avoid a slowdown in IPv6 adoption due to these concerns, new policies were adopted by the RIRs and they provision for Provider Independent (PI) address space,¹⁶ which could be acquired directly from the RIR. These policies will help keep the IPv6 deployment momentum, but they do not solve the real problems of backbone routing table growth and organizations multihomed to several service providers. With a significantly larger address space, IPv6 can make the routing table problem considerably worse than it is in IPv4. The importance of this topic in the networking community mind is reflected in the support provided by IETF to research in this area. The list of suggestions and initiatives to solve the multihoming challenges was reported at the 53^rd RIPE meeting and are

• CIDR boundary: The community decides on the longer prefix boundary that can be handled on the Internet.
• Metro/regional: IP address space is assigned to regions instead of organizations.
• Community codes: Prefixes are tagged with a BGP community attribute.
• Published list of IPv6 blocks: A list of prefixes approved for multihoming will be published, and filters will be opened for them.
• Policy: RIRs would implement policies that offer provider-independent address space. As of early 2008, all RIRs adopted a PI address space policy with the exception of RIPE (http://www.arin.net/policy/archive/2005_1_orig.html, http://www.afrinic.net/docs/policies/afpol-v6200701.htm, http://lacnic.net/documentos/lacnicx/LAC-2006-08-en.pdf, http://www.apnic.net/meetings/12/docs/proposal-ipv6-ixp.html).
• IETF Multi6 WG: This is the IETF working group that works on IPv6 multihoming solutions (http://ops.ietf.org/multi6/).
• IETF Shim6 WG: A shim layer that enables the decoupling between the IP address could be used by the application and used by transport (http://tools.ietf.org/wg/shim6/).
• Global, Site, End-system (GSE): Protocols that separate the user identifier from its locator.
• Maximum prefix: Each origin AS can advertise a limited number of prefixes.

Answer: The IPv6 protocol itself provides the same level of support for multihoming as IPv4 supports. Perceived challenges are just a reflection of address allocation policies implemented to enforce aggregation of prefixes in the Internet backbone routing table. IPv6 can leverage the same multihoming techniques as IPv4, and alternative mechanisms are being investigated in IETF.

Does IPv6 Deliver Plug-and-Play Autoconfiguration?

When mainframes and mini computers were the only devices running IP, autoconfiguration was not really an important feature, because devices were statically configured. With the proliferation of personal computers (PC), for scalable device management and reuse of resources, some dynamic autoconfiguration mechanisms became necessary. In IPv4, autoconfiguration relies on the Dynamic Host Configuration Protocol (DHCP) (see RFC 4776), which is today extensively used in both enterprises and service provider environments.

In RFC 1752, IPng specifically defined an acceptance technical criterion for the new protocol that focused on "configuration ease – The protocol must permit easy and largely distributed configuration and operation. Automatic configuration of hosts and routers is required." Not only is automatic configuration seen as mandatory, but the need for simple configuration mechanisms is also highlighted. The need for simplicity becomes more and more important when considering the simpler devices that are now using IP. These devices might operate in environments where dependencies on a server may not be acceptable.

IPv6 took on the challenge posed by IPng. It offers plug-and-play autoconfiguration beyond the capabilities offered by IPv4 in the sense that a stateless (or serverless) address autoconfiguration mechanism was defined as part of the Neighbor Discovery protocol (RFC 2461, updated by RFC 4681). This capability is available in addition to DHCPv6 (RFC 4776), the stateful address autoconfiguration that is similar to IPv4 DHCP.

Nevertheless, real plug-and-play is more than just acquiring an IP address to access the network. For full operation, an IP device might need information the server addresses for applications such as Domain Name System (DNS), Network Time Protocol (NTP), and so forth. This is currently delivered with the help of "stateless" DHCPv6, a process similar to IPv4. Nevertheless, although servers might not be fully eliminated, IPv6 devices can fully provision themselves in a stateless manner. Microsoft has capitalized on IPv6 autoconfiguration with Windows Vista. The operating system supports a Peer Name Resolution Protocol (PNRP) for identifying and securely communicating with other "peer" computers on the network. Windows Meeting Space is a built-in Vista application for information sharing and conferencing.

In addition to these specific provisioning mechanisms, DHCPv6 has also been expanded to deliver entire IPv6 prefixes to a device rather than deliver just a host address. This protocol extension, called DHCPv6 prefix delegation (RFC 3633), enables routers to autoconfigure their interfaces, a powerful tool that can be leveraged in broadband access networks to dynamically provision customer gateways.

Answer: It is true, IPv6 offers an enhanced plug-and-play autoconfiguration suite of protocols.

Does IPv6 Offer Better QoS?

Quality of service (QoS) in IP networks is delivered in the context of two architectures:

• Differentiated Services (DiffServ): Relies on each network element allocating resources to the forwarding of a packet based on a 6-bit classifier (differentiated code point) carried in the packet header
• Integrated Services (IntServ): Relies on the RSVP signaling protocol to set up resources along the path of packets with given transport requirements
• These architectural models are defined for both IPv4 and IPv6. IPv4 and IPv6 main headers include the same 8-bit field used for DiffServ, although they are named differently: Type of Service (ToS) in IPv4 versus Traffic Class in IPv6. IntServ for IPv6 requires an IPv6 implementation of RSVP.

Conceptually, QoS relates to applications. For example, to guarantee high quality for phone calls established over IP, VoIP packets get higher priority compared to other traffic types. This means that QoS policies should be independent of IP version and should depend exclusively on application types. Thus, in a dual-stack network, the same priority is assigned to the packets of a given application independent of the IP version it runs over. However, for those very specific conditions that require one IP version to be privileged over the other, it is possible to assign different priorities based on IP version.

Why do we read in some publication that IPv6 offers better QoS than IPv4? This is mainly driven by the presence of a 20-bit field named Flow Label in the main IPv6 header, a field that does not exist in IPv4. The Flow Label field, as specified in RFC 2460 and RFC 3697, is used by a source to label packets of the same flow. Its definition guarantees that the information carried has an end-to-end meaning; its value cannot be modified by intermediate systems. Although some interesting proposals do exist for the use of the Flow Label field, the field is currently unused and may not have practical value in the overall Internet where no definition of Flow Label value has been published or agreed upon by service providers. Nevertheless, these 20 bits in the main IP header are very precious real estate, so forms of Flow Label usage will surely be developed in the future.

Answer: IPv6 QoS is neither better nor worse than IPv4 QoS. It follows the same architectural models and faces the same inherent challenges. At this point in time, the presence of the 20-bit Flow Label field in the IPv6 header is not enough to justify the claim of better QoS.

Is IPv6 Required for Mobility?

Before addressing the topic, it is important to clarify what "mobility" really means for a given environment. Over the past few years, mobility became a "fashionable" term used in many marketing presentations. Nevertheless, it is not always related to IP. So, let's start with a few definitions:

• Mobile client: A mobile client is a device such as a laptop, PDA, smartphone, iPod, or sensor that regularly changes location but does not necessarily have its own network interface. For example, an Apple iPod will connect through a PC to download contents.
• Mobile application: An application that runs on a mobile device is a mobile application. Popular audio or video contents (for example, podcasts) consist of files that are downloaded to mobile devices and used later with no need for Internet connectivity. (By contrast, VoIP is an example of an application that requires the mobile client to be always connected.)
• Wireless technologies: They enable mobile devices and applications to be used in any covered location. There are licensed-band (3G/GPRS/Edge/EVDO/WiMAX/LTE) and unlicensed-band (Wi-Fi) technologies.
• Layer 2 mobility: A device moving within a single Layer 2 domain, such as the area covered by a single Wi-FI access point, has Layer 2 mobility.
• Layer 3 mobility: Also called IP Mobility, Layer 3 mobility addresses the case of a mobile device moving between multiple Layer 3 domains while keeping the same IP address. This capability supports persistency and transparency at the application level.
• Layer 7 mobility: A specific application with Layer 7 mobility may survive network reconfigurations and potentially address changes but with service interruption. An example of such an application is the Instant Messaging.
• Mobile networks: In a mobile network, mobility is provided simultaneously to a group of devices. The router providing network access to the devices moves across Layer 3 domains. The changes in the point of attachment for the router uplink have no effect on the interfaces that provide access to devices connected to the router.
• Ad hoc networking: This Layer 3 mobility feature set developed in the IETF under the MANET and Mobility EXTensions for IPv6 (MEXT) working groups enables mobile routers to self-organize their ad hoc connections with peers.

The mobility features relevant to an IP discussion are: Layer 3 mobility, mobile networks, and ad hoc networking. IP Mobility is generally synonymous with the IETF protocol suite called Mobile IP (MIP) that has been standardized for both IPv4 and IPv6. When considering the potential scope of deployment for MIP—for example, handheld devices compliant with standards from 3rd Generation Partnership Project (3GPP) and 3GPP2—it becomes evident that we are dealing with millions of mobile devices. This type of environment requires the large address space provided by IPv6. 3GPP has also addressed the delivery of converged voice, data, and video to mobile devices through the IP Multimedia Subsystem (IMS) standard. IMS requires IPv6 support, to ensure that each mobile phone is individually addressable with a persistent address for full bidirectional services.

There is more to MIPv6 than just the support of large-scale deployments. Mobile IPv6 leverages the IPv6 extension headers that are inherent to the protocol. This makes IP mobility an integrated feature of the IPv6 protocol as required by RFC 1752 and enables it to easily add capabilities such as path optimization between mobile nodes and their communication peer.

Answer: No, IPv6 is not required for mobility. However, Layer 3 mobility, also named IP mobility, is integrated in the protocol rather than being an add-on, as in the case of IPv4. The market is developing new business models, new communities of interest, and new products based on standardized protocols like Mobile IPv6 (MIPv6) and Networks Mobility (NEMO).This will make mobility easier to deploy and capable of supporting a much larger number of more full-featured handsets and other new devices supporting multi-mode wireless radio, video, and VoIP. The use of IMS and other higher-level standards requiring IPv6 support will offer a platform for new marketable products and services not possible with IPv4.

Does IPv6 Provide Increased Security?

Today, security is certainly one of the biggest challenges faced by network managers. Any enhancement to security is always welcomed by operational teams. When reading that "IPv6 is more secure than IPv4," it is natural to become more interested in the new protocol. In fact, several past business cases have had as a supporting argument the increased security of IPv6. So, is IPv6 more secure than IPv4 or is it just a misunderstanding turned into an IPv6 marketing pitch?

The source of the enhanced IPv6 security claims can be traced back to the original version of the IPv6 specifications (RFC 1883), which states under "Security Considerations": "This document specifies that the IP Authentication Header [RFC-1826] and the IP Encapsulating Security Payload [RFC-1827] be used with IPv6, in conformance with the Security Architecture for the Internet Protocol [RFC-1825]."¹⁷

In an environment that eliminates the NAT gateway that manipulates a packet's payload, the use of AH and ESP headers might be perceived as a new security paradigm. End-to-end security is implemented based on IPsec with no intermediate devices manipulating the data. IPsec is becoming the de facto mechanism to protect IPv6 routing protocols such as OSPFv3.

In reality, IPv6 IPsec is not different from IPv4 IPsec. It offers the same level of protection and requires a key distribution infrastructure to be in place for full operation. With no universal key distribution mechanism available Internet wide, this architecture has no practical value for the overall Internet but it could meet the requirements for networks under a single management entity. It is also important to note that some devices might not be capable of doing encryption in a cost-effective way. Also, some features used in IPv4 (for example, WAN optimization) will not be possible if packet manipulation is not allowed. These devices and services would have to be excluded from an environment where end-to-end IPsec between nodes is the rule.

More importantly, communications security must be viewed holistically, at all layers of the OSI model. Different mechanisms and tools are deployed to secure each layer. For example, IEEE 802.1X is configured to protect an IEEE 802.11 infrastructure providing authentication mechanisms at Layer 2. At the same time, antivirus and antispam software protects the application layer.

Based on the accumulated experience securing IPv4 networks, it would be extremely dangerous to narrow network security to IP and IPsec only. Such a strategy would lead to a world in which hosts exchange viruses in a very secure manner. When looking at Layer 3, however, it is true that IPv6 brings along new perspectives. IPv6 makes some things better but has the potential to make other things worse. We cannot state that the net sum makes IPv6 a more or a less secure protocol:

• Better: In IPv6, automated scanning and worm propagation is harder due to huge subnets. With a uniform and non-obvious distribution of host IDs, it is practically impossible for an attacker to perform successful reconnaissance.
• Challenging: New concepts in addressing and configuration and lack of familiarity with the technology can lead to incomplete or incorrectly applied security policies. When managing a dual-stack environment, potential vulnerabilities exist because both IPv4 and IPv6 need to be properly secured. Extension headers might open the door to new types of threats.
• Different: IPv4 Address Resolution Protocol (ARP) is replaced by IPv6 Neighbor Discovery (ND), both of which are unsecured by default. Unlike IPv4, IPv6 has a Secure Neighbor Discovery (SEND) protocol (RFC 3971), which improves security for ND.

Answer: No, IPv6 is not more secure than IPv4 as a protocol set. Most of the security challenges faced by IPv4 remain in IPv6 environments. Network managers must control the IPv6 traffic as they do for IPv4. IPsec can be leveraged to secure IPv6 environments when possible but a global network of IPsec peer-to-peer communication is far from becoming reality, if such a reality is ever possible or desired.

Is Renumbering Easier with IPv6?

Renumbering a network, assigning it a new addressing scheme, is a task dreaded by network managers. Renumbering, however, is a fact of life in the evolution of a business and is triggered by factors such as:

• Growth
• Acquisitions
• Large mergers
• Site transition

Although it is true that IPv6 autoconfiguration mechanisms help in the renumbering process, it is incorrect to state that IPv6 solved the renumbering problem. The actual change of IP addresses on the interfaces of hosts, routers, switches, and appliances represents only one step of the renumbering process. Other updates are generally required in order to restore full network operation:

• IP address–dependent feature configuration: Examples of such features are access control list (ACL) and addressing of resources such as AAA servers and network management servers.
• Naming server: All DNS entries must be updated to reflect the new address corresponding to a given name.
• Network management applications: All tools used to monitor the network must be updated.

To fully appreciate the implications of renumbering an IPv6 network, refer to RFC 4192, Procedures for Renumbering an IPv6 Network Without a Flag Day,¹⁸ which documents a study done over the life of the European Commission–funded 6NET project in collaboration with Cisco Systems on this topic.

Answer: Renumbering is somewhat easier in IPv6; however, not all its aspects are simplified. The best recommendation is for organizations to use naming services, such as DNS, to the extent practical to minimize the impact of renumbering both in IPv4 and IPv6.