IPng

The Next Generation Internet Protocol

A Simple Overview

Perhaps one of the most interesting things about the state of the Internet as we know it is that it is a constantly changing media. This is a reflection of the computer industry in general, however the Internet’s evolution seems even more fluid than other areas of the industry. Web sites spring up overnight and disappear as quickly, newsgroups get restructured and email addresses constantly change. One of the most exciting changes to the fundamental core of the Internet as we know it is imminent. The very Internet Protocol, the underlying mechanism by which the various protocols, such as HTTP, FTP etc. communicate, is going to change.

The current version of the Internet Protocol, IPv4 (Internet Protocol Version 4) - is slowly coming to the end of its usefulness in many areas for instance, inefficient address allocation scheme, the lack of intrinsic security measures and the inability assign priority values to messages.

IPv6 (Internet Protocol Version 6), or IPng (Internet Protocol the next generation) as it is commonly known, will remedy these limitations. It is a rethinking of the needs of the Internet community, fixing the problems of the current version of IP and extending its capabilities.

Address Space

One of the major limitations to the current version of IP is that the actual address space, the number of available addresses, is diminishing. As I mentioned in a previous article, IPv4 uses a 32 bit address. In total this is over 4 billion addresses, which would seem enough. However the problem is in the class structure of these addresses. You may recall that these billions of addresses are essentially split into 3 usable classes, each class made up of so many networks, each network containing so many possible connections. Depending on how many computers were required for a network, a different class of address was allocated. What happened was that any organisation with over 256 computers would obtain a class B address, which is intended for 64 thousand connections. Most of these potential connections would be wasted. Similarly, small networks (10 to 20 computers) would waste a class C address (256 possible connections), and very large organisations would waste most of the millions of possible connections a class A address would allow.

IPng handles this by increasing the total address space tremendously - by a factor of 4 billion times 4 billion. Currently addresses are 32 bits long. Under IPng they will be 128 bits long. The total number of available addresses will be roughly 3 with 38 zeros following; enough for billions of addresses per square metre of the earth's surface.

Textually these addresses are written as:

	    x:x:x:x:x:x:x:x 
      

	    FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
      

	    1080:0:0:0:8:800:200C:417A
      

There are some conventions for simplifying these long addresses. When an address contains sequences of zeros, this may be written as two colons "::". For example:

	    1080:0:0:0:8:800:200C:417A = 1080::8:800:200C:417A
    

Some years ago it was predicted that the current IPv4 addressing scheme would run out of available addresses sometime in 1995. This has obviously not happened. In 1993 the introduction of Classless Interdomain Routing (CIDR) provided a stopgap measure, and the current estimate of address exhaustion is sometime between 2000 and 2020.

CIDR is a method of allocating addresses based on the topology of the Internet and is the basis for the IPv6 address allocation scheme. If each ISP (Internet Service Provider) is allocated a block of addresses, and each organisation using that ISP is then allocated a set of addresses from this block, then these organisations can be referenced by a common address prefix. For example, several organisations are connected via an ISP. This ISP has already been allocated a some address space, say 8 class C networks (2048 possible connections). If the connected organisations are allocated addresses from the address space of the ISP, then there need only be a single common prefix address referencing all these organisations.

	    +-----------+
	    | company 1 |-----( 155.27.201.9   - ) 211 addresses
	    +-----------+     ( 155.27.201.220   )
	    +-----------+
	    | company 2 |-----( 155.27.201.221 - ) 300 addresses
	    +-----------+     ( 155.27.203.19    )
	    +-----------+
	    | company 3 |-----( 155.27.203.20  - ) 45 addresses
	    +-----------+     ( 155.27.203.65    )
    

There are 2 major benefits to this. The first is that less addresses are wasted. If one of the companies above needs 300 connections, then it does not need to be allocated an entire class B address but could simply be allocated lots from the ISP. This can be seen in the diagram above. The second benefit, which is a major win, is that routing tables, the in-memory map of where messages should be physically sent next on their way to their destination, can be a lot smaller. For all possible 2048 connections associated with the ISP above, there need only be one routing table entry in global Internet with the prefix of the address block. This can be seen in the diagram below.

	    +-----------+
	    | company 1 |--( 155.27.201.9   - )
	    +-----------+  ( 155.27.201.220   )-----+
            |
            |
	    +-----------+                           |   +-----+
	    | company 2 |--( 155.27.201.221 - ) ----+---+ ISP | <- 155.27.20x
	    +-----------+  ( 155.27.203.19    )     |   +-----+ 
            |
	    +-----------+                           |
	    | company 3 |--( 155.27.203.20  - ) ----+
	    +-----------+  ( 155.27.203.65    )
    

As you can see, the ISP can field all messages to the address range pprefixed by 155.27.20x. All 3 organisations above can be represented by a single global routing table entry pointing to the ISP that will do any further distributing of messages.

Although I have used IPv4 addresses in the above example, it is the same concept that is behind the IPv6 addressing allocation scheme. The other advantage of this method of address allocation is that it will, to some extent, describe the geography of the Internet. It is planned that sets of addresses will be allocated to each continent and then perhaps further divisions will be made by country, city etc. In theory all addresses bound for Australia will have the same prefix - the whole of Australia could be represented in the rest of the worlds routing tables with a single entry. Consequently the load on routers will drop considerably which means faster processing time which means a quicker Internet.

Address Types

There are to be 3 types of IPng addresses.

• unicast addresses - this is simply the address of a computer on the network
• multicast address - this identifies a group of computers, a message sent to a multicast address will be received by all the computers in that group
• anycast address - this is a new type of address, it also identifies a group of computers but a message sent to an anycast address will only be received by one of the computers in the group; the one that is deemed to be the nearest one to the originator.

Note that there is no broadcast address. The functionality of a broadcast can be achieved using the multicast address.

There are to be 3 kinds of unicast addresses as well:

• Provider based unicast addresses - this is similar to the address allocation scheme described above (CIDR). The address is allocated from the block belonging to the ISP. The format of this address is:

	      +---+-----------+-----------+-------------+---------+----------------+
	      | 3 |  n bits   |  m bits   |  o bits     |  p bits | 125 - (n+m+o+p)|
	      +---+-----------+-----------+-------------+---------+----------------+
	      |010|registry id|provider id|subscriber id|subnet id|  interface id  |
	      +---+-----------+-----------+-------------+---------+----------------+
      

• The first field (the first 3 bits) identify this address as a provider based unicast address.
• Registry Id identifies the internet address registry that assigns the provider identifiers (next field).
• Provider Id is the identifier of the ISP.
• Subscriber Id is the unique id of the subscriber using this provider (it is only unique to this ISP).
• Subnet Id identifies a specific physical link to the subscriber.
• Interface Id is one interface on the physical link. There can be more than one interface per link.
• Site local unicast addresses - an address that only has scope within a local network. This address is unique within a site. Organisations that use site local addresses before they connect to the Internet can then ensure that they have an easy transition to global connection when they do. The site local address is appended to a global prefix, made up of the registry id, provider id and subscriber id (described above) to form a unique Internet address. System administrators no longer have to go to each computer in the organisation and change addresses.

	      +----------+---------+-----------+------------------+
	      | 10 bits  |  n bits |  m bits   | 118 - (n+m) bits |
	      +----------+---------+-----------+------------------+
	      |1111111011|    0    | subnet id |   interface id   |
	      +----------+---------+-----------+------------------+
	      The format of a site local IPng address.
      

• Link local unicast addresses - designed to be used for addressing on a single link.

	    +----------+---------+-----------------+
	    | 10 bits  |  n bits |    118 - n bits |
	    +----------+---------+-----------------+
	    |1111111010|    0    |  interface id   |
	    +----------+---------+-----------------+
	    The format of a link local IPng address
    

Note that in the above unicast address cases the interface id is usually made up containing the hardware devices (such as ethernet card) 48 bit address.

The IPng Packet Header

The IPng packet header format is as follows:

	    +---------+----------+-------------------------+
	    | version | priority |      flow   label       |
	    +---------+----------+-------------+-----------+
	    |   payload length   | next header | hop limit |
	    +--------------------+-------------+-----------+
	    |                  source address              |
	    +----------------------------------------------+
	    |                destination address           |
	    +----------------------------------------------+
    

The fields of this header are:

• version: Internet Protocol Version Number (6 for IPng), length is 4 bits.
• priority: the priority value of this packet, see quality of service below, length is 4 bits.
• flow label: this is a 24 bit field, see quality of service below.
• payload length: the length of the message following the headers, in octets, length is 16 bits.
• next header: identifies the type of header immediately following the IPng packet header length is 8 bits.
• hop limit: 8 bit field which is decremented by 1 by each router that forwards the packet. If this value reaches zero the packet is discarded.
• source address: 128 bit address of the original sender of this packet.
• destination address: 128 bit address of the destination of this packet.

IPng Extensions

IPng provides a mechanism for various extensions to be encoded into the transmitted packets. The way this is done is by adding a separate header to the packet for each extension. These headers are added immediately after the IPng packet header (described above).

Some of the possible types of extensions that are currently defined are:

• Routing: Defining a route that the packet should take as opposed to letting routers decide where the packet should be sent next.
• Authentication: A method of enhancing security capability of network traffic (see "Security", below).
• Encapsulation: A method of encapsulating messages by encrypting them (see "Security", below).
• Hop-by-Hop: Special options that are to be processed by each router through which the packet passes.

Security

There is no intrinsic security in IPv4. As mentioned above, IPng provides two levels of security. The first is the Authentication Header. This provides authentication and integrity of packets across the network essentially via some complex checksum mechanism. The second is the Encapsulation Header which provides a method of encrypting IPng messages.

Neither of these levels of security are actually defined by IPng. Rather it is left to the various implementations of IPng. This is because different implementations will have different security requirements and also because security techniques and algorithms may change.

Furthermore, the two levels of security are separate so that either, or both may be implemented. For example, certain encryption algorithms may not be exported from the United States and therefore cannot be defined as part of a global Internet protocol.

Quality of Service - Real Time Applications

One of the problems of IPv4 is that it has no support for real time communications. Packets across the network have no guarantee of consistency of travel. That is, they may travel at different speeds depending on traffic situations. A real time application such as video is not smooth when being shown because of this. IPng incorporates 2 methods to aid real time messaging across the Internet.

The first method is an optional priority extension header. Packets may be assigned a priority value, a number from 0 to 15. There are two types of priority values.

The first type of priority value is for congestion controlled packets. These are packets that may be deferred until later when faced with congestion (values 0 to 7).

For congestion controlled traffic the following priority values are recommended:

• 0 uncharacteristic traffic
• 1 filler traffic, say news
• 2 non interactive data transfer, for example email
• 3 reserved
• 4 attended bulk transfer, for example HTTP, FTP
• 5 reserved
• 6 interactive traffic, for example X, telnet
• 7 internet control traffic, for example routing protocols

The priority values from 8 to 15 apply to non congestion controlled traffic - those packets that are not to be deferred. Things like real time audio and video will fall into this category.

The second method of supporting real time communication is by the flow label field in the IPng header. Essentially, a flow is a sequence of packets from a particular source to a particular destination probably associated with a particular instance of some application. Flow labels are assigned by the source. When a router receives a packet with a flow label that it hasn’t encountered before it can remember any information it worked out about processing that packet, say routing information or priority information. When subsequent packets with the same flow label arrive this saved information can be used rather than recalculating it thereby saving time in processing that packet.

Rollout Strategy

One of the most important aspects of IPng is the question of how will it be deployed. IPng may be the most advanced whiz bang thing in the world that will do everything for the cause of computer connectivity and communication. However, if IPng needs a lot of money to be spent on new hardware and software, if millions of users need to be re-trained, if it is complicated to setup, then no one will use it.

IPng is designed so that it will be able to operate in parallel with IPv4. It is envisaged that IPng and IPv4 will have to coexist for many years. There is no way that every network on the Internet can be upgraded overnight or even in any sort of order. There are schemes such that IPng packets can be tunnelled across IPv4 routers and, conversely, IPng routers will understand IPv4 packets.

How IPng Affects You

It is important to remember that IPng does not simply fix the addressing problems of IPv4. IPng provides many additional features to IPv4, such as the real time capability and the security. It is envisaged that eventually all networked devices will run IPng - an entire household will be able to run IPng down to the electrical system. It is designed to be flexible and to meet the needs of the ever expanding Internet. It is designed to be used by people on the move with laptops and personal digital assistants. Hopefully it will satisfy the needs of a globally networked community for decades to come.

Further Reading

To find out more about the topics associated with IPng you should read the various RFCs associated with IPng. In particular the following RFCs should be read:

Byline

Copyright © 1997, 1998 Robi Karp. Robi is a software consultant specialising in the areas of Unix application software, software development environments and The Internet. He is technical director of Fluffy Spider Technologies Pty. Ltd. and is currently on contract. He can be contacted via email: robi@fluffyspider.com.au