ICSA750 Paper 3

May 1996

Sean Butler

---

Contents

Introduction

Background IPv4 Problems The Transition from IPv4 to IPng Key New Aspects of IPng Summary References

---

Introduction

The current version of the TCP/IP protocol suite that dominates the Internet is IP version 4, which was developed in the early 1980’s (2). At that point in time, even the most aggressive estimates on the size of the Internet did not come close to what is happening today. The rapid, tremendous growth of the Internet over the last several years has necessitated the development of a new version of IP that will resolve IPv4’s problem with the actual size of the network. Besides the growth factor, there are several other key problems involved with IPv4. This paper reviews the background of IPng (why it was developed and by whom) the problems of IPv4 it solves, the transition from IPv4 to IPng, and the key features that are new to IP.

Background

The actual development of a successor to IPv4 started on several parallel paths in about 1990 (2); in other words, several groups began working on different IP protocols to solve IPv4’s problems. In late 1993, the IPng Area Directors group was formed to review many of the proposals and form the real IPng. All of the proposals were lacking in certain areas, so the group pulled the good features out of the various proposals to create IPng.

IPng was recommended by IPng Area Directors at Internet Engineering Task force during the IETF meeting on 7/25/95, and documented in RFC1752. It was approved by the Internet Engineering Steering Group on 11/17/1994.

IPv4 Problems

The current addressing scheme used in IPv4 has 32 bit addresses, which can identify over 4 billion Internet devices. The current growth of the Internet is tremendous, and could not have been predicted 10 years ago, yet it is mostly limited to the computer market. However, future growth will consist of new markets outside the computer arena. Although these markets are not predictable, they may include devices including but not limited to the following: cellular phones, pagers, Personal Communication Services devices, televisions, control for lighting, heating, cooling, motors, etc. (3) Because of this growth, and the fact that IPv4 can only support 4 billion hosts, a new IP protocol had to be developed.

Another problem related to the size of the Internet is the fact that the actual maximum number of hosts IPv4 supports is really much less than 32 billion. This is because address assignment is not nearly as efficient as the ideal. The reason for this is the Class structure of address assignments, and the fact that if one site is given a class C subnet, but can not fill all of those addresses, the empty slots go unused, and can not be used by other sites, due to how routing occurs. Routers on the Internet route based on subnets, so all addresses for a given subnet must be routed through the same path.

 

Although the address space and routing limitations are the main reasons a new IP had to be developed, there are several other significant reasons also involved:

• IPv4 does not support prioritization of packets. Once data is put into an IP packet, it is treated just like all other IP packets, even if it may be more important.
• IPv4 has several options in the packet header that are often not used, but still must be present in the header, so bandwidth is effectively wasted.
• IPv4 has no security below the application layer, and network layer security is necessary at this point in time.

The Transition from IPv4 to IPng

The transition to IPng from IPv4 must happen before IPv4 ‘breaks,’ which may be in as little as 3-7 years (3), due to the routing and addressing problems discussed above. There are several requirements for the transition which will be discussed here.

The transition must be a practical solution to current IPv4 problems, or no one will begin to use it. If the Internet doesn’t migrate to an Internetworking protocol that solves the issues of limited address space and routing problems caused by non-hierarchical use of the address space, the Internet will soon not operate properly. The protocol that we migrate to must practically solve the current problems, and the implementation of IPng, as it now stands, does so(3).

The transition must be allowed to happen gradually. Only the smallest sites could have a ‘flag’ day, where they migrate all of their devices at once. Most larger sites will need to slowly transition, and that may take years. IPv4 routers, hosts, and applications must be able to interoperate with IPng devices and applications, with no changes. This means that IPng devices will need to pad their address space when the address is for an IPv4 device. This backwards compatibility is a must, as the Internet is too big and too far advanced to have a ‘flag’ day. It is the same situation as when Microsoft deployed Windows ’95. If Windows ’95 did not run Windows 3.1x applications, noone would have upgraded to it.

Since the transition will be allowed happen over time, there must be cost effective reasons for sites to change, or they will procrastinate again and again, and the transition may never fully complete. The benefits associated with the migration must outweigh the costs of the change, so clients, routers, applications, etc., of IPng must make use of the improvements of the new protocol wisely.

Here is an overview of the guidelines recommended for the transition, which includes the major issues discussed above, along with a few other important issues:

• It can not be stressed enough that the deployment of the new protocol must be incremental, that there can be no flag day where every device has to be switched due to the shear size of the Internet.
• The dependencies involved in the transition must be limited. There is no way to have no dependencies, but the number should be small. For instance, the Domain Name Servers (DNSs) must be 1st, as they will have to be able to return both IPv4 and IPng addresses based on the version of the host that sends in a request for a name to address translation (1).
• The issues of addressing must be simple. The main point is that old IPv4 devices must not have to change their addresses until they upgrade to IPng. This will eliminate the need for network administrators to develop new addressing plans until they are ready to migrate.
• The costs to transition, both monetary and preparation wise, must be limited. Noone will make the transition in a reasonable amount of time if it costs too much money or takes too much time.
• Many devices will have to be ‘dual-capable’ at the start of the transition. This just means that they will have to be able to handle both IPv4 and IPng protocols until the transition is complete or nearly complete. An example of this is the example of the DNS’s above, where they must be able to return IPv4 or IPng addresses based on the version of the host making the request. Another example is that routers will have to be able to route packets for both IPv4 and IPng hosts until there are no IPv4 hosts left.

Key New Aspects of IPng

IPng introduces many new key features versus IPv4. Some were discussed briefly above, as to why a new version was needed for the Internet to survive, but there are other new aspects that will make the protocol even better. Here is a summary of the most important new features:

• AddressingAs discussed above, IPv4 only has 32 bits for addressing, which is the equivalent of about 4 billion hosts. IPng will have 128 bits of addressing space, which is the equivalent of 2^96=340,282,366,920,938,463,463,374,607,431,768,211,456 hosts.
  

  This is an extremely large address space. In a theoretical sense this is approximately 665,570,793,348,866,943,898,599 addresses per square meter of the surface of the planet Earth (assuming the earth surface is 511,263,971,197,990 square meters) (3).

  However, as we noted earlier, the actual number of addresses that really can be used is much less than the theoretical maximum. When assigning addresses, to improve efficiency for routing, hierarchies are developed, which reduces the actual number of addresses that can be used. Hinden (3) reports worst-case values after such a reduction for IPng as 1,564 addresses per square meter, and best case as 3,911,873,538,269,506,102 address per square meter. In either case, it is significantly higher than IPv4, and will support the growth of the Internet for the foreseeable future.

  This large number of addresses will allow for more address hierarchy which will greatly reduce the size of the route tables in the backbone of the Internet. This is because with more hierarchy, fewer number of routes are stored. The large number will also simplify auto-configuration of addresses for devices, as not as much pain-staking detail will be needed when assigning addresses. This will enable ‘plug-and-play’ devices, where as soon as a device is connected to the network, the local router can assign the device an IP address, instead of the administrator having to configure it manually.

  IPng also introduces several new types of addressing schemes, which are summarized here:

  • Unicast AddressingAddressing for IP specifies actual interfaces on a device, and not the device itself. For instance, a router that has 3 interfaces to other routers has 3 separate addresses for each of those interface. Unicast addressing specifies a single interface.
  • Anycast addressingThis type of addressing identifies sets of nodes such that a packet sent to an anycast address is delivered to 1 of the nodes in the anycast set. This allows nodes to control the path over which their traffic flows.
  • Multicast AddressingThis type of addressing identifies a group of interfaces such that a packet sent to a multicast address will be sent to all interfaces in that multicast group. IPv4 broadcast addresses will no longer exist, as they will be handled by multicast addresses in IPng.
• IPng RoutingThe only significant difference is address size, and with simple, straightforward extensions, IPng will be able to support most common IPv4 algorithms, such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), etc.

  New routing capabilities in IPng include:

  • Source routingWith source routing, the source device that creates an IP packet to send to a destination embeds a sequence of IPng addresses to follow in the route the packet takes as it traverses the network. This is useful when network traffic from one subnet to another subnet may sometimes need to take different routes. With out source routing, all traffic follows the path the routers decide, but with source routing, the packets traverse the route the originating host decides. Based on this scheme, the originator can choose the provider the data should flow over based on various attributes such as price, performance, availability, etc.
  • Host Mobility and Auto ReaddressingHost mobility implies that a host can change locations, yet IPng will still be able to route to the current location. Auto readdressing means that IPng can route to a new address for a given host. These are useful for devices that are on the go, such as notebook PCs. Addressing changes are based on the service provider, so dynamically changing addresses for that host are needed. These two features go hand in hand.
• IPng Quality of ServiceWith IPv4, once data is in an IP packet, routers treated all packets the same. This will not be the case with IPng, which will be able to support non-default quality services (i.e. ‘real-time’ services, which have the need for consistent throughput and delay, such as multimedia).

  In order to do this, IPng introduces a 4 bit priority field in the IP packet header. Numbers 0 through 7 are used to specify priority of traffic for which the source is providing congestion control (i.e. packets that can be backed off during congestion). Numbers 8-15 are used to specify the priority for traffic that can’t be backed off during periods of high traffic (i.e. real-time/ multimedia packets).

  This field further breaks down as follows:

   

  Congestion control traffic will be:
  • 0 – Uncharacterized traffic
  • 1 – “Filler” traffic (e.g., netnews)
  • 2 – Unattended data transfer (e.g., email)
  • 3 – (Reserved)
  • 4 – Attended bulk transfer (e.g., FTP, HTTP, NFS)
  • 5 – (Reserved)
  • 6 – Interactive traffic (e.g., telnet, X)
  • 7 – Internet control traffic (e.g., routing protocols, SNMP)

  And for non-congestion control, a range is defined with the low end (8) being for packets that the sender is most willing to have discarded under conditions of congestion, and the high end (15) is for those packets the sender is least willing to have discarded under congested conditions.

• Header Format SimplificationIn order to reduce bandwidth an IPng environment, some IPv4 header fields have been dropped, or made optional. This is especially important considering the size of the addresses in IPng are four times larger than IPv4 addresses. With the header format simplification, though, the header for IPng is only twice the size of an IPv4 header.
• IPng ExtensionsAlong with the header simplifications, IPng adds extensions, so that additional information can still be sent in the IP packet, but does not have to be placed in the IP header. IPng options are placed in separate extension headers between the IP header and the transport-layer header. With this addition, most routers don’t have to examine each packet they see, as was the case with IPv4 when any options were present. This will give IPng routers better performance. IPng headers, therefore, are not of fixed length. The main header in the packet is, but the optional headers can be of various lengths.

  IPng extension headers include the following: extended routing, fragmentation and reassembly, authentication, encapsulation, hop-by-hop and destination options. Also, the architecture is such that additional extensions are simple to add in the future.

• IPng SecurityIpv4 has no security below the application layer of the OSI reference model. Programmers must do all the security they deem necessary for their applications. However, IPng introduces two security fields, which can be used singularly, or combined:
  • IPng Authentication HeaderThis is an extension header that provides authentication and integrity (with no confidentiality) to IPng datagrams (2). The lack of confidentiality is important, as it means this scheme can be exported to countries that do not allow encryption. The feature is algorithm independent, though MD5 is the proposed standard.

    The header has several fields, but only a few are important to security. One of these is the security associated ID, which is combined with the IPng source address to identify to the receiver of the packet the pre-established authentication of the packet to that receiver. The second field important to security is the authentication data, which is algorithm specific information required to authenticate the source of the packet and assure its integrity.

  • IPng Encapsulating Security HeaderThis header is also known as the Privacy Header, and provides integrity and confidentiality to IPng datagrams. It uses DES CBC as the standard algorithm to encrypt the data and provide privacy. This header works between hosts, a host and a security gateway, or between two security gateways. It allows trustworthy networks to communicate, without the costs associated with application layer security, and provides security for traffic that traverses non-trustworthy portions of the network, since it is encrypted.

Summary

The Internet is growing too fast for the current protocol, IPv4, to last much longer. A new protocol had to be developed, which addresses many of the immediate problems of IPv4, and addresses less immediate problems of IPv4 that will make the Internet Protocol even better. The new protocol, IPng, was created and documented in RFC1752, from which the following quotation is taken:

This protocol recommendation includes a simplified header with a hierarchical address structure that permits rigorous route aggregation and is also large enough to meet the needs of the Internet for the foreseeable future. The protocol also includes packet-level authentication and encryption along with plug and play autoconfiguration. The design changes the way IP header options are encoded to increase the flexibility of introducing new options in the future while improving performance. It also includes the ability to label traffic flows. (2)

All of these changes and new features will allow IPng to be the next, evolutionary step for IP, and allow the Global Information Highway to continue to expand.

References

• (1) RFC 1671: IPng White Paper on Transition and Other Considerations
• (2) RFC 1752: The Recommendation for the IP Next Generation Protocol
• NOTE: The following reference is a collection of several separate papers, most of which were used in research for this paper. The main link is all that is included here in the interests of simplicity.

  (3) Hinden, Robert. IP Next Generation (IPng). Universal Resource Locator. Available at URL http://playground.sun.com/pub/ipng/html/ ipng-main.html.