If you have heard of "IPv6", you are probably asking what it
is and you are not alone. The curiosity surrounding IPv6 is growing now
that it is being discussed more often and more publicly. I'm here to shed
some light on to what "IPv6" is and how it will affect your future
internet experiences both positively and negatively; hopefully, more
positively than anything else. First, to understand how we got to IPv6, we
have to understand where things started. In the years between the late
1960's and early 1970's, UCLA and a group of other colleges got together
and came up with a way to link their computers together over what became
the archetype of the internet, later known as Arpanet. The theoretical
foundation of this early incarnation was laid upon several memos written
by an MIT employee named J.C.R. Licklider. Seeing its potential, the US
Government began expanding and developing Arpanet to provide the military
with an effective, redundant, scalable, and durable communication medium
during wartime. But as time went on and the early internet grew, the
framework and protocol system of ArpaNet just did not cut it anymore,
hence TCP/IP was born and with it IPv1. Obviously, they weren't born at
the same time, but one led to the other and eventually even these were
outgrown.
Why are we changing to IPv6?
The simple answer is that it is due to the very poor planning in
the creation and implementation of IPv4 coupled with the unexpected
explosive expansion of the internet. This has caused the world to rapidly
run short of available IPv4 addresses. Based off of RFC 791, the document
from which the standards for IPv4 were first dictated, first published in
1981, IPv4 has proven to be a very robust, easily scalable and implemented
protocol for standard networking uses and needs. However, the designers of
IPv4 never foresaw many of the uses and problems that have appeared as the
internet and computer networking in general has expanded and grown; tools
and services like VPN's, IpSec, and much more. Even with 4,294,967,296
potential addresses, current practices limit the number of available
addresses to a few hundred million. Certainly nowhere near as many as is
needed. Hence why the use of NAT (Network Address Translation) is promoted
so heavily these days as a way to conserve the ever shrinking pool of
remaining IP addresses available to the world. One positive outgrowth of
IPv6 is that DHCP will no longer be needed or, at the least, its need will
be greatly reduced making administration of network IP space much easier
for administrators without having to deal with the sometimes complicated
administration of a DHCP infrastructure.
Another positive outcome of IPv6 will be better internet routing
using QoS, Quality of Service, which routes packets based on priority. So
for example, if one person is pinging a server and another is downloading
a file, the one pinging will have less priority in their data transmission
than the one downloading a file because the user who is downloading a file
from has created a data stream which will automatically gain more priority
over the simple ICMP data packets. Lastly, routing will be simplified
because the IPv6 information header on each packet is far more flexible
and can contain more detailed information than an IPv4 header thus
allowing for faster routing of data across a network or the internet.
Currently, most routers need to maintain as many as 48,000 different
routes in their routing tables just to effectively route data that passes
through them. IPv6 reduces this number by at least 75%. Nats will also no
longer need to be used as there will no longer be a need for IP address
conservation since there will now be enough IPv6 addresses available for
each person on the planet to have 10 of their very own.
Also, if you're worried about IPv6 requiring you to change all
of your software, learn new protocols, new methods of connecting, new ways
of sending and receiving data or anything like that, fear not. The only
thing really changing with IPv6 over what was in IPv4 is that you now have
a larger address space which allows for more network addressable IP
addresses, a more flexible header and packet system, and faster routing.
As far as protocols are concerned, most will still remain the same so you
can still ping, traceroute, or telnet to your heart's content. Security
will now be native in IPv6, not an additional feature such as it appears
in IPv4. Ports still work the same as well and UDP, TCP and other
protocols are still present and accounted for.
IPv6 Addressing
To properly understand the addressing scheme of IPv6, we first
have to understand the syntax of the actual address. With a standard IPv4
address, it consists of 32 bits broken into 8 bit segments separated by
periods.
For example:
11111111. 11111111. 11111111. 11111111 (binary)
255.255.255.255 (decimal)
With IPv6, you have a 128 bit address broken down into strings of
16 bits separated by colons.
For example:
1111111111111111: 1111111111111111: 1111111111111111: 1111111111111111:
1111111111111111: 1111111111111111: 1111111111111111: 1111111111111111
(binary)
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF (aka Colon Hexadecimal)
So for example, a 16 bit string such as "0010000111011010" would
convert to 21DA in hexadecimal. Hexadecimal is a binary addressing system
that takes 4 bits of data and converts it into an alphanumeric value from
0 to F. This chart should give you a little better idea of how the binary
numbers, decimal numbers, and hexadecimal values all compare to each
other.
Binary |
Hexadecimal |
Decimal |
0000 |
0 |
0 |
0001 |
1 |
1 |
0010 |
2 |
2 |
0011 |
3 |
3 |
0100 |
4 |
4 |
0101 |
5 |
5 |
0110 |
6 |
6 |
0111 |
7 |
7 |
1000 |
8 |
8 |
1001 |
9 |
9 |
1010 |
A |
10 |
1011 |
B |
11 |
1100 |
C |
12 |
1101 |
D |
13 |
1110 |
E |
14 |
1111 |
F |
15 |
As you notice, the binary digits are always 4 characters, aka
4 bits. The hexadecimal numbers are all 1 character, and the decimal
numbers range from 1-2 characters in size. Since a hexadecimal number
can't take up more than 1 space, any number greater than 9 has to be
represented with a letter ranging from A-F. The decimal column lists the
decimal values of each binary number. Therefore, a 16 bit string of data
would need to be represented by 4 characters of hexadecimal data, or as we
listed before in our example, something like this: 21DA
Simplifying the IPv6 address
For those of us too lazy to write out an entire 39 character IP
address (32 bytes plus 7 colons) the wonderful people who wrote out the
specs for IPv6 in RFC 2373, the informational document that dictates the
standards for IPv6 decided to be nice to us. Since IPv6 addresses are
designed to be computer friendly rather than human friendly (IPv4
addresses are designed to be human friendly) the designers of IPv6 were
nice and gave us a way to simply each address. Take for example the
following IPv6 address: 43FB:0000:0000:0000:0000:BB3F:A0A0:0000 This could
be shortened to 43FB::BB3F:A0A0:0 instead. Now you might ask: "What's up
with the double colon?" If you thought that, good for you. You've seen
something many people would not have seen on their first try. The double
colon (aka "::") signifies that we have removed a series of hexadecimal
blocks from the address. These will always be contiguous zeros. AKA
"0000:0000:0000:0000" can be shortened to just "::". Therefore when you
see the double colon in an IPv6 address, it can be automatically assumed
that they are all zeros. You can't however do this same shortening trick
with any other combination of numbers that you can with a string of zeros.
For the purpose of example, we will assume our address has numerous zeros
in it in several groups. Let's also look at our abbreviated IP address
again. Notice at the end there is a single zero after the last colon. If
you already noticed this too, good for you. That is another simplification
system for IPv6.
With IPv6 you can drop all the leading zeros off a 16 bit
hexadecimal block leaving at least one character in each 4 character
block. So in other words "0000" would become simply "0", and "0026" would
simply become "26". In IPv4 this is done in much the same way by
converting a number such as "035" into the much simpler number "35". Now,
even though you can shorten an address using the double colon technique,
you can only do it once in an address. Here's the reason why. If you take
an address like "43FB:0000:0000:0000:0000:BB3F:0000:A0A0" and reduce both
strings of zeros to the double colon like this: "43FB::BB3F::A0A0" how are
you going to know how many blocks of 4 zeros are contained between the
double colons? You can't know. Therefore,
"43FB:0000:0000:0000:0000:BB3F:0000:A0A0" can only be reduced to
"43FB::BB3F:0:A0A0" leaving one zero in the 7th block and a double colon
for the 2nd through 5th blocks. That same set of 4 blocks can be reduced
to simply "0:0:0:0" instead of the double colons as stripping the leading
zeros off the number leaving a single zero in each block is permitted.
Finally, when simplifying a number, you cannot throw out zeros at random.
For example, "A0A0" can't be reduced to "AA". Once again you'd create a
paradox for the computer as it wouldn't know where to replace the missing
zeros. Now, if the block of 4 characters was "0A0A", you could drop the
leading zero to make "A0A" instead.
Types of IPv6 Addresses
Just like in a normal IPv4 topology, there are 3 types of
addresses in IPv6. Unicast, Multicast, and Anycast.
Unicast is standard point A to point B data traffic. This would
be nothing more than me sending data from my computer, across the
internet, to your computer and back again. That's the basic elements of
Unicast addressing. So instead of needing to setup a special machine to
dictate which server gets a given incoming connection first, IPv6 controls
this automatically. Multicast is exactly how it sounds. Sending to one
address on a subnet broadcasts to everyone on the subnet. This works the
same as the broadcast address in IPv4.
Anycast identifies multiple network interfaces. In the simplest
terms, the anycast address system is a "First man wins" system. Basically,
if you have three network interfaces identified as part of a given anycast
address and a request is sent to the anycast address, it is then forwarded
to the first interface in the anycast group. Since that interface is not
busy, the packet is then delivered to that interface. Say a second
connection comes in and the first interface is busy. The connection is
immediately routed over to the second interface. Then a third connection
request comes in but now the first interface is not busy anymore so the
data is routed to the first interface. This is a simple load balancing
system built directly into IPv6.
Unicast IPv6 Addresses
Ok, let's further try to break down each of the addresses and
look at just the Unicast address to start with. Since this will constitute
about 90% of all traffic on the internet, and probably 99% of all traffic
on your private network, we'll focus on this one type of IPv6 address
specifically. With IPv6, subnets are done away with, in a manor of
speaking. Instead of having to specify the subnet at the host level, it's
specified at the address level. What this basically means is that only
half of an actual IPv6 address deals with a specific host on the internet.
This is the part that will probably baffle you to no end, the first 64
bits deal with the subnet. You're probably thinking to yourself, "Why
would you attach the subnet to the IP address if the only thing that's
going to use it is the actual host?" That's because unlike typical IPv4
subnets, with IPv6 you can do what is called hierarchical subnetting. In
short, each part of the address dictates three basic things: the primary
internet provider, such as Uunet, MCI, or one of the big backbone
providers; the ISP; and the customer. Here is an example of how all 128
bits of an IPv6 address are broken down.
3 bits |
13 bits |
8 bits |
24 bits |
16 bits |
64 bits |
001 |
TLA ID |
Res |
NLA ID |
SLA ID |
Interface ID |
Ok, now let's look at each of those segments.
001 - This is what is known as the "Aggregatable Global Unicast Address"
or, in short, a "global address". IPv6 global addresses are equivalent to
IPv4 global addresses. They are globally routable and can be reached on
the IPv6 portion of the internet.
TLA ID - This is a Top Level Aggregation Identifier. The size of this
field is 13 bits and identifies the highest levels of routing hierarchy.
In short, these would be the major backbone providers like MCI, AT&T,
UUnet, and others who provide the largest data channels on the internet.
The TLA ID is used to simplify routing at these higher levels thus
speeding up data routing and transfer times.
Res - This is a set of 8 bits that has been set aside for future use in
case that either the TLA or NLA ID fields need to be expanded or a feature
needs to be added.
NLA ID - This is the Next Level Aggregation Identifier. This field is 24
bits in size and would apply to your ISP. This both identifies your ISP,
and allows them to create multiple levels of routing and addressing
hierarchy within their organization to aid them in simplifying routing on
their own network.
SLA ID - This is the Site Level Aggregation Identifier. In short, this set
of 16 bits would apply to you, the end customer. It is used by an
individual organization to identify the subnets within its own
organization. This is the part that was previously referred to as
subnetting. Once the basic routing is done and completed, it's down to
nothing more than the simple internal subnets to determine where the
packets go before reaching your machine.
Interface ID - This is your actual machine. Although 64 bits are set aside
for your actual machine to uniquely identify it on the network, only 24
are truly needed and the rest can be set aside for additional subnetting
and routing levels.
Local use Addresses
While many things in IPv6 are new and unique, there are many
things that are much the same as they are in IPv4, if not done in a
slightly different way. One example of this is local use addresses. These
consist of Link Local and Site Local addresses. Link local addresses are
more or less the IPv6 equivalent to the mac address already used on every
network out there to identify individual pieces of networking hardware
attached to the network. A link local address is automatically configured
by the computer and is used for neighbor discovery and for querying of the
DHCP server for an IP address and other information necessary on the
network. These addresses are not world routable and are only used locally.
Site local addressing would be equivalent to the private network
addresses used in Nat under IPv4. These addresses are not world routable
and are used for data traffic within your local network itself.
Compatibility is also a big factor with IPv6. Built into the specs for the
protocol is a complete system by which IPv6 can interact with legacy IPv4
and vice versa. We won't go into the specifics of this, but if you had any
worries about making the transition to IPv6 with many legacy clients,
routers, and other elements of your network that are IPv4 aware only, you
don't have to anymore, because this was already foreseen as being a big
stumbling block to acceptance and has been implemented directly into the
protocol.
On top of Link Local and Site local addressing, IPv6 also
includes two of our old IPv4 favorites. The loopback and unspecified
address's. Aside from some formatting changes, both work exactly the same
as before.
Subnetting IPv6
Now that we've discussed some of the basic elements of IPv6, I'm
sure you're probably saying to yourself "That's great, but how do we
subnet under IPv6?" Well, that's both a simple, and a somewhat complicated
answer. If you remember earlier in this article we discussed the breakdown
of the IPv6 address and how the first half of the IP address was separated
into TLA, NLA and SLA ID's. It's through those three separate ID's that
subnetting takes place. When subnetting under IPv6, the average person
will not need to be concerned with the TLA or the NLA sections of the IP
address. Those are taken care of by the Internet Backbone Provider (ie
MCI, Uunet, AT&T, Sprint, etc) and your ISP respectively.
Initially a pool of IP addresses will be assigned to an Internet
Backbone provider who in turn parts out those IP blocks and assigns them
to individual ISP's and customers giving each their own unique NLA number.
At this point your ISP will then part out your IP address and assign you a
unique block of IP's with your own block of SLA ID's. Most likely they
will give you a block of 8 ID's, each of which can become a subnet if you
so choose to use each of these ID's separately on your network as a unique
subnet. What you do after this is entirely up to you. You can give every
single device in your house its own ip address if you wanted to. With the
current IPv6 subnetting standard the way it is, you could technically have
millions of devices with hundreds of their own individual ip's assigned to
them. But who needs that many? Although per the latest RFC the size of the
interface ID has not changed, I suspect that at some point in the future
this will be shrunk down to a more realistic number or made flexible to
allow for subnets ranging from 2 ip's in size all the way up to the full
64 bits assigned to the Interface ID section of the IP address.
The challenges ahead for IPv6
In reality, with the current rate of usage of IPv4 addresses,
it's not unrealistic to expect IP's to only be handed out on a per need
basis. In other words, instead of a single ISP getting billions of
potential addresses, they'd get several hundred thousand, possibly a
million at most while the next segment of that IP block would be assigned
to another ISP. I personally don't see IPv6 in full use worldwide for many
years to come, but with China and several other Asian nations switching
their entire nation to IPv6 in 2006, we may see it appear here and around
the world even faster than the planned 2009 initial deployment of IPv6
setup by Icann. The only bad thing about switching to IPv6 is it isn't
fully tested in a real world environment. We honestly don't know what will
happen once the entire internet begins talking in IPv6. It may make the
transition seamlessly, or it may fall flat on its face. There is also the
other problem of legacy support.
IPv6 has native legacy support built into it that will allow
it to communicate directly with the current IPv4 addressing system already
in use on the internet. But that's not the big problem. Where things get
sticky is all of the machines that are too old to know how to talk with an
IPv6 network. Almost any machine with an operating system that was
released in 2000 or after has an almost 100% chance of their operating
system being IPv6 compatible. (If you're unsure, it's best to check with
the organization responsible for the particular operating system you are
using to see if it is compatible. IE Windows users would go to Microsoft,
MacOS users would go to Apple, and so on.) The big problem lies with all
the older mainframe computers that are scattered all over the world. Many
of these are running operating systems that are 10, 20, and in some cases
as much as 30 years old. These would most definitely not be compatible and
therefore I expect that IPv4 won't be phased out as quickly as Icann and
many other internet organizations responsible for the change to IPv6 would
like. I suspect that IPv4 will be used in some form or fashion for at
least the next 10 to 20 years.
Conclusion
It is true that IPv6 is not human friendly; however, in the long
run, it will help solve a lot of issues with the current shortage of
available IPv4 addresses on the internet. It will also address the rapidly
growing size of the internet, newer "net-aware" appliances, and other
growing difficulties with routing and much more. Although IPv6 is not
scheduled to be implemented before 2008, expect to begin to seeing slow
changes in the direction of IPv6 implementation shortly thereafter because
2008 is when the initial changeover to IPv6 is tentatively scheduled for.
With 2010 being the year that all current IPv4 addresses are expected to
be exhausted, the proliferation of IPv6 into everyday networking will
become more and more common.
References:
Understanding IPv6 by Microsoft Press
RFC 791
RFC 2373 |