Chapter 3: IPv4 Versus IPv6: the Basic Grounds

IPv4 was developed in 1975 and provides for approximately 4.2 billion possible combinations. Although this sounds like more than enough addresses, the truth is that every machine as well as every interface on every machine requires a unique address. We therefore find ourselves in our current position, lacking enough capacity in addresses to cover the impending supply of users.

By the beginning of the new century, the Internet community will need enough IP addresses for the billions upon billions of new customers that it attracts as well as the possible new host being setup and connected to the Internet. IPv4, does have the capability for more than 4 billion addresses, but still, it is not adequate to handle the demand, not much for the number of addresses it can handle, but the way it groups bits for its network/host numbering system. The problem here is that IPv4’s numbering system wastes address assignments and suffers from excessive routing overhead.

Let’s take a look at how IPv4 assigns addresses and how that affects IP routing tables so that you can understand the limitations IPv4 imposes to Internet’s current demands.

This chapter discusses:

• The IPv4 limitations and constraint.
• Address management issues of IPv4.
• Some of major IPv6 enhancements.

A Brief Overview of IPv4’s Limitations

IPv4 supports a fixed 32-bit field for addressing, which is no longer sufficient for the number of users on the Internet. Routing tables are growing exponentially and this has been causing a great deal of difficulty for many organizations as well. In addition to these items, auto-configuration and scaleable multicast are in need. Furthermore, there is a need to develop real-time flow for video conferencing. These remain the key issues associated with the move toward a new protocol format.

IPv4 addresses are categorized according to the size of a network (number of IP addresses used). These categories are known as address classes. The first three categories are those that we are concerned with and they maintain a different amount of bits for the networkID portion of their addresses. Class B for example, has 14 bits for the networkID and 16 for the hostID combining to form 16,384 outcomes and each of these outcomes can accommodate 65,534 hosts.

The major problem with this scheme is that the networks that are most numerous in number are those in the middle of this class structure. The number of addresses has remained static and the distribution of networks has been evolving to lump around the intermediate networks. Subnettting and supernetting has been developed in part to help fix this problem.

The Addressing System of IPv4

IP addressing is based on network number assignment and host number assignment. In IPv4, these numbers are organized as 32-bit addresses, with host numbers and network numbers embedded in the addresses. These numbers identify the network or host connection and not the actual network or computer. IPv4 divides its address assignment into three main classes: A, B, and C.

• Class A addresses assign the first 7 bits (or 1 byte) to a network and the last 24 bits (or 3 bytes) to a host. These addresses are reserved for organizations that have up to 16 777 216 hosts, and there can be at most 128 of these networks.
• Class B addresses assigns the first 14 bits (or 2 bytes) to a network and the last 16 bits (or 2 bytes) to a host. These addresses are reserved for organizations that have up to 65 536 hosts, and there can be at most 16 384 networks.
• Class C addresses assign the first 21 bits (or 3 bytes) to a network and the last 7 bits (or 1 byte) to a host. These addresses are reserved for organizations that have less than 256 hosts, and there can be at most 2 097 152 networks.

The address class determines the network mask of the address. A network mask is a 32-bit Internet address that has all the bits in the network number set to one and all the bits in the host number set to zero. Hosts and routers use the network mask to route Internet packets.

The Address Management Issues

Although the amount of possible addresses seem enough to suit the world needs for IP address, the way IPv4 handles the addresses within each of these classes prevents from it. Take for example an organization seeking 300 host addresses. The amount of IP addresses the organization seeks puts them into the Class B category. However, if the company is assigned a Class B address, then they would have 65 536 hosts, which is significantly more than what is needed, which waists about 65 000 addresses!

To avoid this type of situation, the Classless Inter-Domain Routing scheme (CIDR) was introduced a few years ago. CIDR essentially eliminates the class structure of addressing and, instead, allows the assignment of network numbers at any bit boundary. In this way network numbers can be created, for example, by aggregating several contiguous class C addresses. CIDR requires that network masks be explicitly specified when needed, rather than allowing them to be implicitly derived from the address (as in the class system).

Another problem attributed to IPv4’s address classes is the Internet backbone router table size explosion. CIDR also addresses this by allowing for address aggregation. Furthermore, a negative aspect to CIDR is that with an arbitrary address, you cannot determine the network and host numbers unless you know the network mask. But the limitations of IPv4 have quickly been realized and measures, such as CIDR, have extended its life slightly. Worldwide network demand, however, is making the need for IPv6 immediate.

IPv6 Address Enhancements

It is important to note the intent behind the IPv6 design. It was not designed to be a huge leap away from what has worked in IPv4. This would be catastrophic, as backward compatibility would not be assured. This version of the protocol is designed to be growths move out of something that works but no longer fits the requirements of the user community.

With this in mind, things that work well in the older version of the protocol are integrated into the new version of the protocol. Along the same lines, things that did not work so well in IPv4 were intentionally left out of the new version. Below is a summary list of the main changes that have been implemented on IPv6:

• Expanded Routing and Addressing Capabilities,
• IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes, and simpler auto-configuration of addresses,
• The scalability of multicast routing is improved by adding a "scope" field to multicast addresses,
• A new type of address called a "anycast address" is defined, to identify sets of nodes where a packet sent to an anycast address is delivered to one of the nodes. The use of anycast addresses in the IPv6 source route allows nodes to control the path which their traffic flows,
• Header Format Simplification,
• Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to keep the bandwidth cost of the IPv6 header as low as possible despite the increased size of the addresses. Even though the IPv6 addresses are four time longer than the IPv4 addresses, the IPv6 header is only twice the size of the IPv4 header,
• Improved Support for Options,
• Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future,
• Quality-of-Service Capabilities,
• A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real- time" service,
• Authentication and Privacy Capabilities, and
• IPv6 includes the definition of extensions, which provide support for authentication, data integrity, and confidentiality. This is included as a basic element of IPv6 and will be included in all implementations.

Auto-configuration

Auto-configuration, or plug and play, has been introduced as a concept in IPv6. Under this concept, a host who has been established as a resource on the Internet will be not be required to re-establish itself as a host again. This host will be able to connect as a node on the network with a minimal amount of configuration. This will reduce a great deal the time LAN administrators spend configuring and maintaining IP addresses lease. In a broader context, individuals who travel will not be required to reconfigure in order to gain connectivity to the Internet.

This aspect of IPv6 has an added benefit in that it does not require DHCP. It is interesting to note the way in which this has been proposed. A ‘local link IP address’ will be developed upon the initialization of a physical layer device such as a NIC. As part of the Ethernet standard for example, such addresses are unique from one another. Building on these addresses and creating a unique IP address as a derivation of the Ethernet address will ensure successful addressing of the NIC. This is the IP address that can be established in auto-configuration. This approach is similar to that of IPX, which has been quite successful.

IPv6 Header

The IPv6 header, as shown on figure 3.1, consists of eight discreet items, many of them being quite innovative and obviously directly targeted at some of the shortcomings of IPv4. These items are:

• Version,
• Prior(ity) Flow Label,
• Payload Length,
• Next Header,
• Hop Limit,
• Source Address and
• Destination Address.

IPv6 header, broken down in eight discreet items.

IPv6 Extensions

IPv6 includes an improved option mechanism over IPv4. IPv6 options are placed in separate extension headers that are located between the IPv6 header and the transport-layer header in a packet. All IPv6 extension headers are not examined or processed by any router along a packet's delivery path until it arrives at its final destination. This facilitates a major improvement in router performance for packets containing options. In IPv4 the presence of any options requires the router to examine all options.

The other improvement is that unlike IPv4 options, IPv6 extension headers can be of arbitrary length and the total amount of options carried in a packet is not limited to 40 bytes. This feature plus the manner in which they are processed, permits IPv6 options to be used for functions which were not practical in IPv4. A good example of this is the IPv6 Authentication and Security Encapsulation options.

In order to improve the performance when handling subsequent option headers and the transport protocol which follows, IPv6 options are always an integer multiple of 8 octets long, in order to retain this alignment for subsequent headers. The IPv6 extension headers, which are currently defined, are:

• Routing - Extended Routing (like IPv4 loose source route),
• Fragmentation - Fragmentation and Reassembly,
• Authentication - Integrity and Authentication,
• Security Encapsulation - Confidentiality,
• Hop-by-Hop Option - Special options which require hop by hop processing, and
• Destination Options - Optional information to be examined by the destination node.

Security Enhancements

IPv4 has a number of security problems and lacks effective privacy and authentication mechanisms below the application layer. IPv6 remedies these shortcomings by having two integrated options that provide security services. These two options may be used singly or together to provide differing levels of security to different users. This is very important because different user communities have different security needs.

The first mechanism, called the "IPv6 Authentication Header", is an extension header which provides authentication and integrity (without confidentiality) to IPv6 datagrams. While the extension is algorithm- independent and will support many different authentication techniques, the use of keyed MD5 is specified as the default algorithm to help ensure interoperability within the worldwide Internet. This can be used to eliminate a significant class of network attacks, including host masquerading attacks.

The use of the IPv6 Authentication Header is particularly important when source routing is used with IPv6 because of the known risks in IP source routing. Its placement at the Internet layer can help provide host origin authentication to those upper layer protocols and services that currently lack meaningful protections. This mechanism should be exportable by vendors in the United States and other countries with similar export restrictions because it only provides authentication and integrity, and specifically does not provide confidentiality. The exportability of the IPv6 Authentication Header encourages its widespread deployment and use.

The second security extension header provided with IPv6 is the "IPv6 Encapsulating Security Header". This mechanism provides integrity and confidentiality to IPv6 datagrams. It is simpler than some similar security protocols (e.g., SP3D, ISO NLSP) but remains flexible and algorithm-independent. To achieve interoperability within the global Internet, the use of DES CBC is being used as the standard default algorithm for use with the IPv6 Encapsulating Security Header.

Transitioning to IPv6

The key transition objective is to allow IPv6 and IPv4 hosts to interoperate. A second objective is to allow IPv6 hosts and routers to be deployed in the Internet in a highly diffuse and incremental fashion, with few interdependencies. A third objective is that the transition should be as easy as possible for end-users, system administrators and network operators to understand and carry out.

The IPv6 transition mechanisms are a set of protocol mechanisms implemented in hosts and routers, along with some operational guidelines for addressing and deployment, designed to make transition the Internet to IPv6 work with as little disruption as possible. The IPv6 transition mechanisms provides a number of features, including:

• Incremental upgrade and deployment. Individual IPv4 hosts and routers may be upgraded to IPv6 one at a time without requiring any other hosts or routers to be upgraded at the same time. New IPv6 hosts and routers can be installed one by one,
• Minimal upgrade dependencies. The only prerequisite to upgrading hosts to IPv6 is that the DNS server must first be upgraded to handle IPv6 address records. There are no pre-requisites to upgrading routers,
• Easy Addressing. When existing installed IPv4 hosts or routers are upgraded to IPv6, they may continue to use their existing address. They do not need to be assigned new addresses. Administrators do not need to draft new addressing plans, and
• Low start-up costs. Little or no preparation work is needed in order to upgrade existing IPv4 systems to IPv6, or to deploy new IPv6 systems. The mechanisms employed by the IPv6 transition mechanisms include:
• An IPv6 addressing structure that embeds IPv4 addresses within IPv6 addresses, and encodes other information used by the transition mechanisms,
• A model of deployment where all hosts and routers upgraded to IPv6 in the early transition phase are "dual" capable (i.e. implement complete IPv4 and IPv6 protocol stacks),
• The technique of encapsulating IPv6 packets within IPv4 headers to carry them over segments of the end-to-end path where the routers have not yet been upgraded to IPv6,
• The header translation technique to allow the eventual introduction of routing topologies that route only IPv6 traffic, and the deployment of hosts that support only IPv6. Use of this technique is optional, and would be used in the later phase of transition if it is used at all.

The IPv6 transition mechanisms ensures that IPv6 hosts can interoperate with IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts within a limited scope to interoperate indefinitely after that. This feature protects the huge investment users have made in IPv4 and ensures that IPv6 does not render IPv4 obsolete. Hosts that need only a limited connectivity range (e.g., printers) need never be upgraded to IPv6.

The 6bone initiative

This project is actually much more important than one would think from its name, however. It is essentially a practice ground to learn more about the use of IPv6 as well as the foster the implementation of the new standard.

The project is a close relative of the IETF and currently spans three continents. One of the main purposes of the project is to develop and implement a backbone (thus the name, we suppose) that is able to support IPv6. A new protocol is not worth much if support is unavailable. The eventual thinking is that the backbone will mimic the structure that exists today in that it will consist of ISPs as well as other networks combined to provide a great deal more functionality and power to the Internet.

The problem that 6bone is answering is an important one: how can we test new functionality without placing the existing functionality at risk? The answer is that this project involves placing a virtual network layer that exists on top of physical IPv4 network layers. The particulars of this setup can be found at the 6bone Web site below as they are beyond the scope of this book. It is important to note however, that as IPv6 is readily adopted and implemented, 6bone would be eventually phased out.

6bone is interested in developing policy and procedures for the next stage of IP integration. It is not designed to develop new network architectures or infringe upon the way in which networking is accomplished by major players in the Internet. The project is attempting to include as many large players as possible in order to develop policies and procedures that can be adopted by many organizations.

It is logical to move from the RAS section to a more detailed discussion of TCP/IP. As we have learned, there are a number of changes in store for the protocol suite that are important to understand and be prepared for as well. These changes are not designed to make a huge lead away from what has worked to-date. Rather these enhancements are designed to build upon the aspects of IP that have worked and move away from those that have not.

IPv4 is a solid, routable protocol. In order for larger network environments to use this product, they require some sort of connectivity that is usually filled by a DHCP and DNS server. IPv6 has the potential to circumvent many of these requirements and provides the opportunity to create a more efficient, secure networking environment.

IPv6 has been designed to enable high-performance, scalable internetworks to remain viable well into the next century, and for that, many inadequacies of IPv4 were corrected (see figure 3.2 for an IPv6 sample of its packet). But in order to fully take advantage of IPv6 improvements you must be ready to dive into its full spectrum of benefits. Some of the qualities of IPv6 are found in obviously enhanced features, others are less tangible and relate to the fresh start that IPv6 provides to LAN and Internet administrators.

Addressing and Routing

IPv6 provides a framework for solving some critical problems that currently exist inside and between enterprises, as shown on figure 3.3. IPv6 will allow Internet backbone designers to create a highly flexible and open-ended global routing hierarchy. At the level of the Internet backbone where major enterprises and Internet Service Provider (ISP) networks come together, it is necessary to maintain a hierarchical addressing system, much like that of the national and international telephone systems. Large central-office phone switches, for instance, only need a three-digit national area code prefix to route a long-distance telephone call to the correct local exchange. Likewise, the current IPv4 system uses a (somewhat haphazard) form of address hierarchy to move traffic between networks attached to the Internet backbone.

IPv6 addressing enhancements

Without an address hierarchy, backbone routers would be forced to store routing table information on the reachability of every network in the world. Given the current number of IP subnets in the world and the growth of the Internet, this is not feasible. With a hierarchy, backbone routers can use IP address prefixes to determine how traffic should be routed through the backbone. IPv4 uses a technique called Classless InterDomain Routing (CIDR), which allows flexible use of variable-length network prefixes. With this flexible use of prefixes, CIDR permits considerable "route aggregation" at various levels of the Internet hierarchy, which means backbone routers can store a single routing table entry that provides reachability to many lower-level networks.

IPv6 addressing routing features

Gateways and network address translators typically limit users in private address spaces with non-unique addresses in their connectivity to the outside world. NAT services are meant to allow an enterprise to have whatever internal address structure it desires, without concern for integrating internal addresses with the global Internet. The NAT device sits on the border between the enterprise and the Internet, converting private internal addresses to a smaller pool of globally unique addresses that are passed to the backbone and vice.

NAT allows interoperation with IPv4

A NAT may keep up with address conversion in a small network, but as Internet accesses increases, the NAT's performance must increase in a parallel fashion. The bottleneck effect is exacerbated by the difficulty of integrating and synchronizing multiple NAT devices within a single enterprise. It is highly unlikely that an enterprise will achieve the reliable high-performance Internet connectivity with NAT that is common today with multiple routers attached to an ISP backbone in an arbitrary mesh fashion.

Another limitation of IPv4 relates to the ongoing need in many organizations to renumber stations. When an enterprise change ISPs, it may have to either renumber all addresses to match the new ISP-assigned prefix, or implement address translation devices. Renumbering is also a reality for many corporations that undergo a merger or an acquisition that entails network consolidation. Also, address shortages and routing hierarchy problems increasingly are a threat to the network operations of larger (and to some extend small) enterprises. Smaller networks can be completely dropped from Internet backbone routing tables if they do not adhere to the address hierarchy. In the current system, ISPs with individual dial-in clients cannot allocate IP numbers as freely as they wish. Consequently, many dial-in users must use an address allocated from a pool on a temporary basis. In other cases, small dial-in sites are forced to share a single IP address among multiple end systems.

Dynamic Host Configuration Protocol

RFC 1752, called for IPv6 support for autoconfiguration. IPv6 supports multiple forms of autoconfiguration, including full-featured facilities offered by DHCP. Together with IPv6 system discovery features, the address autoconfiguration protocol provides the minimal bootstrapping information necessary to enable hosts to acquire further configuration information, such as that provided by DHCP in IPv4. Thus, IPv6 does support improved support for autoconfiguration through multiple forms of autoconfiguration, from plug and play configuration of node addresses on an isolated network to the full-featured facilities offered by DHCP.

Note that, as per IETF design goals, DHCP, as well as many routing protocol specifications in IPv4, such DNS, etc. only require straightforward extensions to support IPv6 and not complete respecifications.

Also IPv6/IPv4 nodes may acquire their addresses using appropriate IPv4 and IPv6 methods depending on how they are configured. Further, IPv6 addresses, which doesn’t include no IPv4-compatible IPv6 addresses, may be acquired using DHCP for IPv6 or stateless IPv6 address configuration mechanism. The IPv4 addresses may be acquired using standard IPv4 mechanism such as DHCP, BOOTP, and RARP.

There is a draft, developed by Bay Networks and Bob Fink, of LBNL (draft-ietf-iab-case-for-ipv6-00.txt>) that looks at the fact that IPv4 networks often employ DHCP to reduce the efforts of managing and administrating IP addresses assignments. Since DHCP is "stateful" address configuration tool, for it maintains static tables to determine which addresses are assigned to which nodes, the new DHCP version for IPv6 will provide similar stateful address assignment, but a new dimension to autoconfiguration. It introduces a "stateless" address autoconfiguration service, which will not require a manually configured server. Stateless autoconfiguration makes it possible for stations to configure their own addresses with the help of a local IPv6 router by combining its 48-bit MAC address with a network prefix learned from a neighboring router.

The robust autoconfiguration capabilities of IPv6 will be a boon to internetwork users at many levels. When an enterprise is forced to renumber because of an ISP change, IPv6 autoconfiguration will allow hosts to be given new prefixes without manual reconfiguration of workstation or DHCP addressing. Further, as the industry moves to IPv6, DHCP, and DNS, servers are being modified to accommodate 128-bit addresses, but in terms of basic functionality, there will be little change.

DHCP Options for Novell Directory Services

Don Provan, from Novell, is the author of RFC 2241 (Standards Track), dated November 1997. This RFC addresses the DHCP Options for Novell Directory Services by defining three new DHCP options for delivering configuration information to clients of the Novell Directory Services, which provide an NDS client with enough information to connect to an NDS tree without manual configuration of the client. The options are:

• List of NDS servers
• Name of the client's NDS tree
• Initial NDS context.

Novell Directory Services is a distributed, replicated, hierarchical database of objects representing network resources such as nodes, services, users, and applications. An NDS client must be able to locate an NDS server in order to authenticate itself to the network and gain access to the database. In addition, the node's user is better served if the NDS client's attention is focused on the area of the NDS database likely to be of the most interest to the user. The NDS Tree Name Option and the NDS Context Option carry 16-bit

Unicode text encoded into an octet stream using UTF-8. A complete DHCP implementation can represent of the entire Unicode character set supported by NDS. At the same time, 7-bit ASCII text is unchanged by the UTF-8 transformation. In environments where the NDS tree name and context are restricted to the range of 7-bit ASCII characters, ASCII-only DHCP clients and servers can support these options by using the ASCII text as the UTF-8 encoded data. Provan uses the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" as described in RFC 2119.

The NDS Servers option specifies one or more NDS servers for the client to contact for access to the NDS database. Servers SHOULD be listed in order of preference. The code for this option is 85. The minimum length of this option is 4 octets, and the length MUST be a multiple of 4, as shown on figure 3.7.

NDS Server option, code 85, minimum of 4 octets with multiple of 4 length.

The NDS Tree Name Option specifies the name of the NDS tree the client will be contacting. NDS tree names are 16-bit Unicode strings. For transmission in the NDS Tree Name Option, an NDS tree name is transformed into octets using UTF-8. The string should NOT be zero terminated. The code for this option is 86. The maximum possible length for this option is 255 bytes, as shown on figure 3.8.

NDS Tree name option, code 86, maximum length is 255 bytes.

The NDS Context Option specifies the initial NDS context the client should use. NDS contexts are 16-bit Unicode strings. For transmission in the NDS Context Option, an NDS context is transformed into octets using UTF-8. The string should NOT be zero terminated.

A single DHCP option can only contain 255 octets. Since an NDS context name can be longer than that, this option can appear more than once in the DHCP packet. The contents of all NDS Context options in the packet should be concatenated as suggested in the DHCP specification to get the complete NDS context. A single encoded character could be split between two NDS Context Options.

The code for this option is 87. The maximum length for each instance of this option is 255, but as just described above, the option may appear more than once if the desired NDS context takes up more than 255 octets. Implementations are discouraged from enforcing any specific maximum to the final concatenated NDS context.

NDS Context option, code 87, maximum length is 255 bytes, but can appear more times.

A Word about Security

DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [3]. In particular, these DHCP options allow an unauthorized DHCP server to misdirect an NDS client to a nonexistent NDS server or even a spoof NDS server. These threats are similar to what NDS faces during normal operations in its native IPX environment.

NOTE: For further information about DHCP options for Novell directory services you can contact Don Provan at Novell, Inc., 2180 Fortune Drive - San Jose, California, 95131 - Phone: +1 408 577 8440 or via e-mail at donp@Novell.Com

From Here

This chapter discussed some of the main limitations of IPv4 as well as a brief comparison between IPv4 and IPv6 addressing. Next chapter, "IPv6 Development and Features," deepen the discussion about IPv6 features, outlining its main features and what to expect of it in the near future.