This month, MC Mag Online focuses on the Internet--what's old and what's new. There's a lot to be excited about (and almost too much to keep up with) with many new technologies being created on what seems like a daily basis. There is one technology, however, that has been in development for over a decade and will eventually affect all of the others. It isn't new, really. It's the evolution of the technology on which the Internet is currently based. What is it? It's called "IPng," and in this article, we'll take an introductory look at what is also known as "Internet Protocol: Next Generation."

The current Internet Protocol (IP Version 4, or simply IPv4) is roughly 20 years old. Twenty computer years compared to 20 human years is an even bigger contrast than that of 20 dog years to 20 human years (which seems to be the de facto comparison of aging).

Consider that when IPv4 was designed there was but a fraction of the number of networks and networked devices that exist today. Streaming video, streaming audio, and the other bandwidth pigs that now comprise modern network traffic weren't present then (when virtually everything was text-based), so network segments weren't so stressed. To top it all off, denizens of the Internet's early years were more civilized and trustworthy, so security wasn't such a high priority. Twenty years later, we have devices connecting to our networks that were unimagined back then. Multimedia sites are consuming huge amounts of network resources (to the chagrin of IT departments everywhere), and you can't open a trade journal (or The Wall Street Journal) without reading about some miscreant's deeds.

It is a testament to the IPv4 designers that the protocol is still holding up so well under the strain. However, IPv4 does show some signs of buckling under the load. Let's investigate the changes that are morphing IPv4 into IPng, also known as IPv6.

More Addresses

Arguably the biggest problem associated with IPv4 is unique IP addresses. When IPv4 was designed, 32-bit addressing may have seemed sufficient. The truth is that we're rapidly running out. While there are some clever hacks created to ameliorate this problem (private networks and network address translation being the most obvious), they are simply delaying the inevitable.

IPv6 uses a 128-bit addressing scheme, four times that of IPv4. To put that in perspective, that's 4 billion x 4 billion x 4 billion ( 2^96) times the number of bits in IPv4 (2^32). Christian Huitema, author of the book IPv6: The New Internet Protocol, calculated that an address space of that size would allow for between 8x10^17 and 2x10^33 nodes (assuming efficiency in the same range as the American and French phone systems and the current IPv4 standard), which would yield approximately 1,524 addresses per square meter of the earth's surface. That was his pessimistic estimate. His optimistic estimate would allow for 3,911,873,538,269,506 addresses per square meter. The huge disparity between the two estimates is because the final addressing scheme to be used wasn't decided at the time he did his calculations. But even his pessimistic calculation seems to indicate that IPv6 will provide a virtually inexhaustible supply of addresses. Being a pessimist myself (a pessimist is an optimist with practical experience), I envision a ton of email arriving in my box 20 years from now, chiding me for that last statement. But I can't imagine how we can shove 1,524 networked devices into a square meter of space. We'll have to wait and see.

What does a fit-for-human-consumption IPv6 address look like? Addresses that have the potential to be up to 39 digits long (decimal) would be inconvenient for humans to handle, so hexidecimal notation is used instead. This reduces IPv6 addresses to a maximum of 32 characters. The designers then chose to break these into eight groups of four characters each, separated by colons. Thus, the highest address would be shown as ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. This form isn't as bad as a 39 digit number, but it still isn't great either. Further reductions can be performed to make the addresses more user-friendly.

The first reduction allows for leading zeros within a group to be omitted. Thus, the address 3ffe:ffff:0100:f101:0210:a4ff:f334:9566 can be reduced to 3ffe:ffff:100:f101:210:a4ff:f334:9566. No great shakes there.

The second reduction is more effective in that it allows the first instance of contiguous zero-groups to be omitted. So an address like 3ffe:ffff:0100:f101:0000:0000:0000:0005 can be reduced to: 3ffe:ffff:0100:f101::5. The most pronounced example of this is the IPv6 localhost address 0000:0000:0000:0000:0000:0000:0000:0001, which reduces simply to ::1.

As you may well have guessed, these addresses aren't pulled out of thin air. There is a scheme to IPv6 just like there was with IPv4. With IPv4, the now-broken standard defined Class A, B, and C networks, which grouped address ranges by which part of the address defined the network address and which part defined the host address. IPv6 does the same thing, allocating the upper 64 bits for the network part of the address and the lower 64 bits for the host part. Unlike v4, IPv6 codifies some special prefixes to embed some intelligence into the address. I won't discuss these in this article because of space considerations, but later I will point you to some reference material that you can read if you really want to know what's going on.

More Security

Another obvious flaw with the current IPv4 implementation is that of security. There's nothing built into the protocol that enables any kind of privacy or authentication, so it's easy to fall victim to attacks such as IP spoofing. As a result, all means of securing your networks and communications must be done at the application level.

IPv6 remedies this deficiency by adding two header extensions to the protocol. The first is called the "IPng Authentication Header," which can be used to guarantee the authenticity (you know where it came from) and integrity (you know that it is unadulterated) of an IP datagram. The second, called the "IPng Encapsulating Security Header," provides for confidentiality (encryption) of the packet. These additions to the protocols will allow security to happen below the application level, where it will be more effective.

As an analogy, consider the difference between trying to enforce security via your RPG programs (the application layer) versus enforcing security using the features of OS/400 (i5/OS), and you'll get an idea as to the magnitude of improvement that IPv6 provides over its older brethren.

More Features

A larger address space isn't the only improvement. Anyone who has tried Voice over IP (VoIP) knows that IPv4 leaves a lot to be desired, since packet delivery delays can cause unnatural-sounding audio. If you haven't experienced VoIP, you've probably at least experienced the same sort of problems with streaming audio or video applications. And if not that, then I'm sure that you have experienced the delays in surfing the Web that come when your users start large downloads.

The solution to these problems is called Quality of Service (QoS), which basically manipulates and orders packets so that services that require priority get it. Until v6, QoS has been implemented in routers with much manual configuration. Now, additional v6 packet headers are available that can be used to identify packets that require special handling. Routers can use this information to dynamically adjust their behavior, relieving the administrators from a lot of tedious tuning and tweaking of router configurations.

Along the same line, a priority field is included in the header that allows priority to be given to specific packets over others. So when your users decide to start a huge download during peak times of the day, your other users won't notice a performance hit. The FTP downloads can be given a lower priority, and routers will automatically adjust the packet flow.

Other improvements to the protocol include support for provider selection (your packets can be set up to choose their path from source to destination), auto-configuration and auto-reconfiguration (which currently is attempted on IPv4 with zeroconf), and host mobility (so your computer never gets lost changing IP addresses as it goes from your home to your car, from your car to your office, from your office to the coffee shop, etc.).

Investigation Through Linux

I don't currently use IPv6 for anything more than some experimentation. On Linux, it is relatively easy to get started. Most modern distributions of Linux are IPv6-aware. I use Fedora Core 1 on my laptop, and getting IPv6 running was as simple as typing this:

As a quick check, I added an IP address to my Ethernet card:

Then, I checked to ensure that the address was active:

Finally, I did my first IPv6 test:

I was up and running! The official Linux IPv6 HOWTO contains a wealth of information about the current state of the IPv6 Linux implementation. Those who are curious can go there for further information. It's nice to know that in Linux you have the tools to get a leg up on this new protocol.

When Will We Make the Switch?

So the big question on your mind must be, "When will we have to cut over to IPv4?" One of the best features of IPv6 is that it's designed to interoperate with IPv4. So the answer to the question is, "Whenever you want." Actually, IPv6 is still a work in progress, and the standard continues to evolve. So you may not want to switch completely right now, even if you can. If you want to start experimenting with the protocol, point your browser to 6bone.net and check out the documentation there. If your interest in IPv6 is purely academic, then check out this document at Laynetworks. It is an excellent (and relatively short) introduction to IPv6.

That's all for this month. I hope all of you have an enjoyable holiday season, and I'll "see you" next year!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 21 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

s on the Internet--what's old and what's new. There's a lot to be excited about (and almost too much to keep up with) with many new technologies being created on what seems like a daily basis. There is one technology, however, that has been in development for over a decade and will eventually affect all of the others. It isn't new, really. It's the evolution of the technology on which the Internet is currently based. What is it? It's called "IPng," and in this article, we'll take an introductory look at what is also known as "Internet Protocol: Next Generation."

The current Internet Protocol (IP Version 4, or simply IPv4) is roughly 20 years old. Twenty computer years compared to 20 human years is an even bigger contrast than that of 20 dog years to 20 human years (which seems to be the de facto comparison of aging).

Consider that when IPv4 was designed there was but a fraction of the number of networks and networked devices that exist today. Streaming video, streaming audio, and the other bandwidth pigs that now comprise modern network traffic weren't present then (when virtually everything was text-based), so network segments weren't so stressed. To top it all off, denizens of the Internet's early years were more civilized and trustworthy, so security wasn't such a high priority. Twenty years later, we have devices connecting to our networks that were unimagined back then. Multimedia sites are consuming huge amounts of network resources (to the chagrin of IT departments everywhere), and you can't open a trade journal (or The Wall Street Journal) without reading about some miscreant's deeds.

It is a testament to the IPv4 designers that the protocol is still holding up so well under the strain. However, IPv4 does show some signs of buckling under the load. Let's investigate the changes that are morphing IPv4 into IPng, also known as IPv6.

More Addresses

Arguably the biggest problem associated with IPv4 is unique IP addresses. When IPv4 was designed, 32-bit addressing may have seemed sufficient. The truth is that we're rapidly running out. While there are some clever hacks created to ameliorate this problem (private networks and network address translation being the most obvious), they are simply delaying the inevitable.

IPv6 uses a 128-bit addressing scheme, four times that of IPv4. To put that in perspective, that's 4 billion x 4 billion x 4 billion ( 2^96) times the number of bits in IPv4 (2^32). Christian Huitema, author of the book IPv6: The New Internet Protocol, calculated that an address space of that size would allow for between 8x10^17 and 2x10^33 nodes (assuming efficiency in the same range as the American and French phone systems and the current IPv4 standard), which would yield approximately 1,524 addresses per square meter of the earth's surface. That was his pessimistic estimate. His optimistic estimate would allow for 3,911,873,538,269,506 addresses per square meter. The huge disparity between the two estimates is because the final addressing scheme to be used wasn't decided at the time he did his calculations. But even his pessimistic calculation seems to indicate that IPv6 will provide a virtually inexhaustible supply of addresses. Being a pessimist myself (a pessimist is an optimist with practical experience), I envision a ton of email arriving in my box 20 years from now, chiding me for that last statement. But I can't imagine how we can shove 1,524 networked devices into a square meter of space. We'll have to wait and see.

What does a fit-for-human-consumption IPv6 address look like? Addresses that have the potential to be up to 39 digits long (decimal) would be inconvenient for humans to handle, so hexidecimal notation is used instead. This reduces IPv6 addresses to a maximum of 32 characters. The designers then chose to break these into eight groups of four characters each, separated by colons. Thus, the highest address would be shown as ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. This form isn't as bad as a 39 digit number, but it still isn't great either. Further reductions can be performed to make the addresses more user-friendly.

The first reduction allows for leading zeros within a group to be omitted. Thus, the address 3ffe:ffff:0100:f101:0210:a4ff:f334:9566 can be reduced to 3ffe:ffff:100:f101:210:a4ff:f334:9566. No great shakes there.

The second reduction is more effective in that it allows the first instance of contiguous zero-groups to be omitted. So an address like 3ffe:ffff:0100:f101:0000:0000:0000:0005 can be reduced to: 3ffe:ffff:0100:f101::5. The most pronounced example of this is the IPv6 localhost address 0000:0000:0000:0000:0000:0000:0000:0001, which reduces simply to ::1.

As you may well have guessed, these addresses aren't pulled out of thin air. There is a scheme to IPv6 just like there was with IPv4. With IPv4, the now-broken standard defined Class A, B, and C networks, which grouped address ranges by which part of the address defined the network address and which part defined the host address. IPv6 does the same thing, allocating the upper 64 bits for the network part of the address and the lower 64 bits for the host part. Unlike v4, IPv6 codifies some special prefixes to embed some intelligence into the address. I won't discuss these in this article because of space considerations, but later I will point you to some reference material that you can read if you really want to know what's going on.

More Security

Another obvious flaw with the current IPv4 implementation is that of security. There's nothing built into the protocol that enables any kind of privacy or authentication, so it's easy to fall victim to attacks such as IP spoofing. As a result, all means of securing your networks and communications must be done at the application level.

IPv6 remedies this deficiency by adding two header extensions to the protocol. The first is called the "IPng Authentication Header," which can be used to guarantee the authenticity (you know where it came from) and integrity (you know that it is unadulterated) of an IP datagram. The second, called the "IPng Encapsulating Security Header," provides for confidentiality (encryption) of the packet. These additions to the protocols will allow security to happen below the application level, where it will be more effective.

As an analogy, consider the difference between trying to enforce security via your RPG programs (the application layer) versus enforcing security using the features of OS/400 (i5/OS), and you'll get an idea as to the magnitude of improvement that IPv6 provides over its older brethren.

More Features

A larger address space isn't the only improvement. Anyone who has tried Voice over IP (VoIP) knows that IPv4 leaves a lot to be desired, since packet delivery delays can cause unnatural-sounding audio. If you haven't experienced VoIP, you've probably at least experienced the same sort of problems with streaming audio or video applications. And if not that, then I'm sure that you have experienced the delays in surfing the Web that come when your users start large downloads.

The solution to these problems is called Quality of Service (QoS), which basically manipulates and orders packets so that services that require priority get it. Until v6, QoS has been implemented in routers with much manual configuration. Now, additional v6 packet headers are available that can be used to identify packets that require special handling. Routers can use this information to dynamically adjust their behavior, relieving the administrators from a lot of tedious tuning and tweaking of router configurations.

Along the same line, a priority field is included in the header that allows priority to be given to specific packets over others. So when your users decide to start a huge download during peak times of the day, your other users won't notice a performance hit. The FTP downloads can be given a lower priority, and routers will automatically adjust the packet flow.

Other improvements to the protocol include support for provider selection (your packets can be set up to choose their path from source to destination), auto-configuration and auto-reconfiguration (which currently is attempted on IPv4 with zeroconf), and host mobility (so your computer never gets lost changing IP addresses as it goes from your home to your car, from your car to your office, from your office to the coffee shop, etc.).

Investigation Through Linux

I don't currently use IPv6 for anything more than some experimentation. On Linux, it is relatively easy to get started. Most modern distributions of Linux are IPv6-aware. I use Fedora Core 1 on my laptop, and getting IPv6 running was as simple as typing this:

As a quick check, I added an IP address to my Ethernet card:

Then, I checked to ensure that the address was active:

Finally, I did my first IPv6 test:

I was up and running! The official Linux IPv6 HOWTO contains a wealth of information about the current state of the IPv6 Linux implementation. Those who are curious can go there for further information. It's nice to know that in Linux you have the tools to get a leg up on this new protocol.

When Will We Make the Switch?

So the big question on your mind must be, "When will we have to cut over to IPv4?" One of the best features of IPv6 is that it's designed to interoperate with IPv4. So the answer to the question is, "Whenever you want." Actually, IPv6 is still a work in progress, and the standard continues to evolve. So you may not want to switch completely right now, even if you can. If you want to start experimenting with the protocol, point your browser to 6bone.net and check out the documentation there. If your interest in IPv6 is purely academic, then check out this document at Laynetworks. It is an excellent (and relatively short) introduction to IPv6.

That's all for this month. I hope all of you have an enjoyable holiday season, and I'll "see you" next year!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 21 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..