6bone home page - Pilot IPv6 backbone.

IPng home page - Includes specs and implemenations for various platforms.

IETF RFCs:

IPng White Paper Solicitation

Technical Criteria for IPng

Recommendation for IPng

Security Architecture

Authentication Header

Encapsulating Security Payload

IPv6 Address Allocation

IPv6 Specification

IPv6 Addressing Architecture

ICMPv6 for IPv6

DNS Extensions

Unicast Address Allocation

Testing Address Allocation Transition Mechanisms

Neighbor Discovery

Address Autoconfiguration

IPv6 over Ethernet

Path MTU Discovery

IPv6 over FDDI

IPv6 over PPP

Contributing Editor Mark Miller is president of DigiNet Corp., a Denver-based data communications engineering firm. He has written 11 books on internetwork design and analysis and this fall led a Network World Technical Seminar on IPv6. Miller can be reached via the Internet at mark@diginet.com.

It has vendors scrambling in their labs, madly revising code for routers and hosts. It has developers furiously churning out requests for comment, trying to keep up with all the changes. And soon, it will have you scouring the road maps others are now drawing that show how best to implement it in your organization.

''It'' is IP Version 6, the next-generation Internet Protocol. You've likely heard about the vastly expanded addressing field it brings, and that is certainly an important aspect, but there's lots more you need to understand about IPv6 before you begin to implement it. There are new and expanded formats and fields you'll need to explore, security and configuration features you'll want to understand, even additional traffic types supported, which could change how you think about carrying voice and video.

Most products aren't due out the door until next year, but IPv6 differs so much from its predecessor that you'd be wise to begin boning up now. This feature, and one that will follow next month on migration strategies, will get you started.

So why do we need a new IP anyway? Since its inception - the original IP specification, RFC 791, was published in 1981, but its roots date back to the early 1970s with the development of ARPAnet - IP has been implemented on every conceivable type of platform and operating system, all pretty successfully.

In many ways, this success, and the explosive growth of the Internet, exposed several weaknesses in the original design. The 32-bit address field, which can identify more than 4 billion systems, would have been adequate were it not for the address field's class-based structure that reduced the efficiencies of that field. (For more on the existing IP address structure, see NW, Aug. 19, page 45.)

Other key issues not anticipated by the original developers include the need for greater security and support for real-time traffic flows, such as voice over the Internet.

Design criteria

Among these criteria are:

• Scale. IPng must scale to allow the identification and addressing of at least 10x12th end systems and 10x9th individual networks.
• Topological flexibility. The routing architecture and protocols of IPng must allow for many different network topologies. Stating up front that no single topology, such as a tree topology, is assumed provides for future Internet expansion, growth and technologies.
• Transition. The protocol must have a straightforward transition plan from the current IPv4.
• Media independence. The protocol must work across an internetwork of many different LAN, MAN and WAN media. These media may operate at speeds from a few bits per second to hundreds of gigabits per second. Again, the idea is that IPng must not be tied to any one type of technology.
• Automatic configuration for hosts and routers.
• Secure operation. IPng must provide a secure network layer.
• Mobility. The protocol must support mobile hosts, networks and internetworks.
• Extensibility. The protocol must be able to evolve to meet the Internet's future service needs.

Meeting all of the above criteria was a tall order. The Internet Engineering Task Force's (IETF's) IPng Working Group researched the issues over a two-year period and evaluated a number of proposals.

No single proposal met all the requirements. So, the IPng Working Group took elements from the three most significant proposals - the Common Architecture for Next Generation Internet Protocol (CATNIP), TCP and UDP with Bigger Addresses (TUBA) and the Simple Internet Protocol Plus (SIPP) - synthesized the best features of each and put them into the protocol that we now call IPv6.

Comparing IPv4 and IPv6 Packets

The objectives of the IPv6 design are accomplished with a number of constructs. There's the revamped addressing scheme that uses 128 bits instead of the current 32, and a streamlined IPv6 packet format that allows options to be placed in extension headers. This provides for streamlined packet processing within routers, as each host or router just looks at headers relevant to its packet-forwarding functions.

Other functions support the notion of plug and play, where new nodes on the network can obtain their addresses and parameters without requiring server involvement in every case. Support for real-time traffic flows, such as voice and video, is also available, so that the Internet or intranet of the future could also be your telephone or cable provider.

The IPv6 header is 320 bits - or 40 octets - in length, and is broken into eight fields (An octet is an 8-bit quantity of information. The term is preferred over byte in international data communications standards because while in the U.S. a byte is 8 bits, that is not always the case in other countries). The Version field is 4 bits in length and identifies the version of the protocol (6 for IPv6). The Priority field is also 4 bits long and enables a source to assign a delivery priority to its packets. For example, network management or routing protocol updates might be assigned a higher priority than news or E-mail traffic and would be indicated as such. This way the most important traffic would have the best chance of getting through a congested network.

The 24-bit Flow Label field is used to identify data transmissions that need special handling. This concept is currently in the experimental stages of development, but might be used to support real-time data transfers over the Internet.

The Payload Length field is a 16-bit number, which measures the length, given in octets, of the payload, or the balance of the IPv6 packet. Payloads range from 576 to 65,535 bytes, or octets. If larger amounts of data must be sent, the Jumbo Payload Option may be implemented. This is an improvement over IPv4, which is limited by the 65,535 value.

The Next Header field is 8 bits in length and identifies the header immediately following the IPv6 header, such as TCP or one of the IPv6 extension headers.

Next comes the Hop Limit field, which is 8 bits in length. The Source and Destination Addresses are 128-bit fields that identify the originator and intended recipient of the packet, respectively.

When you compare the IPv6 header with the existing IPv4 header, you'll find that the IPv6 Priority field functions similarly to the IPv4 Precedence field, the IPv6 Next Header field functions similarly to the IPv4 Protocol field, and the IPv6 Hop Limit field functions similarly to the IPv4 Time to Live field.

Future-proofing: optional extension headers

For example, if a function such as fragmentation is required, its overhead is placed in a special extension header. In that way, you reduce overhead by using only the fields you need, depending on what you are trying to do. The originating host determines the optional extension headers required, and they are examined as necessary by the intervening routers.

The IPv6 packet may thus consist of zero, one or more extension headers arranged in a daisy-chain format. The value of the Next Header field identifies the header that comes next.

Six optional extension headers have been defined:

• Hop-by-Hop Optionsstet - carries information that must be examined and processed by every node along a packet's delivery path, including the destination node.
• Destination Options - carries information that need be examined only by a packet's destination. (There are as yet no specific uses defined for the Destination Options. This is an example of how IPv6 allows for future, unanticipated requirements.)
• Routing Header - specifies the intermediate nodes comprising the path from the source to the destination.
• Fragment Header - used by the source to divide large messages into fragments that can be processed by the intervening routers.
• Authentication - provides data integrity and authentication, using schemes such as Message Digest 5 (MD5).
• Encapsulating Security Payload - provides data confidentiality, using schemes such as the Data Encryption Standard.

Structuring the IPv6 packet into a base header followed by optional extension headers will simplify adding features and functions to the protocol in the future. IPv6 address types

IPv6 solves the IP address depletion problem in a dramatic way: increasing the address space from 32 to 128 bits. RFC 1884, IPv6 Addressing Architecture, defines three different types of IPv6 addresses:

• Unicast - for point-to-point communication.
• Anycast - to communicate with the closest member of a group of devices.
• Multicast - to communicate with multiple members of a group of devices.

The anycast address is a new type that lets you, for example, communicate with the closest router. That router would then propagate the information to the other group members. In this way, a host could send an update to one router, which would then take responsibility to re-transmit that information to all group members.

In the case of multicast addresses, a field limits the packet's scope; that is, how far they can travel. For example, if you use a multicast address for a teleconference within your organization, you can ensure that the packets from your local network do not sneak past a router and get to the global Internet.

Each address consists of a defined prefix, plus an address. Currently, approximately one-eighth of this address space has been defined, leaving plenty of room for growth.

The prefix, which is the first 3 to 11 bits of the 128-bit address, determines the format of the address. So, some prefixes identify unicast addresses, and others identify multicast addresses. Still other prefixes identify special cases, such as addresses used on a particular communication link, or those used within a particular site or organization.

For example, there is a provider-based unicast address format, which would be assigned by an Internet Service Provider to an organization. Some fields, such as a subnet ID, within that address would then be assigned by the local network administrator.

Address representation

With dotted decimal, the 32-bit address is divided into four sections that are each 8 bits long. Each 8-bit binary number is then represented in decimal format by a single number between 0 and 255.

For example, the binary address:

11000000 00011000 00000000 00000000

would be represented as 192.24.0.0 in dotted decimal.

Since IPv6 addresses are 128 bits long, either your memory must dramatically improve, or a different method of representation is required. RFC 1884 suggests the format x:x:x:x:x:x:x:x, where each x represents a group of 16 bits. Since the address is 128 bits long, the address will therefore be represented as eight groups of 16 bits each. In this case, however, each 16-bit section is represented by four hexadecimal numbers. (Hexadecimal, or base 16 arithmetic, uses numerals for numbers 0 through 9, then the letters A through F to represent numbers 10 through 15.)

For example, an IPv6 address could be of the form:

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

Since much of the IPv6 address space is yet to be assigned, lots of zeros will appear in the addresses. Two shorthand notations help simplify matters.

The first method eliminates leading zeros within one of the 16-bit fields. For example, instead of writing four zeros, you can just write a single zero. So:

1080:0000:0000:0000:0008:0800:200C:417A

may be simplified to:

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

The second method allows the simplification of long strings of zeros that appear within an address. In this case, a double colon may be used to indicate that multiple groups of zeros have been omitted, which further simplifies the example shown above. In this case:

1080:0000:0000:0000:0008:0800:200C:417A

was simplified to:

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

and may be further simplified to:

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

To avoid ambiguity, the double colon may appear only once in an address. To expand this simplified address, you would go to the double colon and start adding zeros until the address was again 128 bits long.

A support system required

Another is the Stateless Autoconfiguration Protocol, which enables many of the plug-and-play capabilities required of IPv6.

For example, let's suppose you take your notebook computer on a trip and want to join a colleague's IPv6-based network. The Autoconfiguration Protocol provides a way for your notebook to assign itself an IPv6 address, which is based, in part, on its LAN adapter address. Since the LAN adapter address is unique, the self-assigned IPv6 address will be unique as well, thus preventing a duplicate address. If all works as planned, the manual intervention of the local network administrator is no longer required.

Other changes are also required, such as updates to the Routing Information Protocol and Open Shortest Path First protocol to handle the larger addresses, and changes to Domain Naming System servers to handle larger address records.

End-user applications and operating systems may likewise need revision, so they can access the features available in IPv6. One example is the extensions to the Berkeley Unix operating system currently under development.

The Berkeley application program interface, generally known as the socket interface, is used by a number of TCP/IP-based applications. This API must be revised in order to support the new features that come with IPv6, such as the priority and flow label fields within the base header.

In other words, for the new features to be useful, an upper layer protocol application must have a way to access the enhanced capabilities of a lower layer. Enhancements to other operating systems, such as Digital Equipment Corp.'s Unix, IBM's AIX, Novell, Inc.'s NetWare, and SunSoft, Inc.'s Solaris are also under way.

How do we sign up?

Most vendors and industry analysts expect IPv6 upgrades to be widely available by mid-1997, allowing you to position your networks to take advantage of these enhancements later next year.

But you must plan a clear path for the transition. Strategies to handle those issues will be the topic of the next installment in the IPv6 series, which will appear next month.