The Internet Protocol is the foundation of the
TCP/IP protocol suite and the Internet, and thus somewhat comparable to the
foundation of a house in terms of its structural importance. Given this,
changing IP is somewhat analogous to making a substantial modification to the
foundation of your house. Since IP is used to connect together many devices, it
is in fact, like changing not just your house, but every house in the
world!
How do you change the foundation of a house? Very
carefully. The same caution is required with the implementation of IPv6. While
to most people IPv6 is something “new”, the reality is that the planning and
development of IPv6 has been underway for nearly a full decade, and if we were
starting from scratch the protocol would have been ready for action years ago.
However, there is a truly enormous installed base of IPv4 hardware and software.
This means the folks who develop TCP/IP could not just “flip a switch” and have
everyone move over to using IPv6. Instead, a transition from IPv4 to IPv6
had to be planned.
IPv4-IPv6 Transition: Differences of
Opinion
The transition is already underway, though most
people don't know about it. As I said, development of IPv6 itself is pretty much
complete, though work continues on refining the protocol and also on development
of IPv6-compatible versions of other protocols. The implementation of IPv6 began
with the creation of development networks to test IPv6's operation. These were
connected together to form an experimental IPv6 internetwork called the
6BONE (which is a contraction of the phrase “IPv6 backbone”.) This
internetwork has been in operation for several years.
Experimental networks are well and good, but of
course the big issue is transitioning the “real” Internet to IPv6—and here,
opinion diverges rather quickly. In one camp are the corporations, organizations
and individuals who are quite eager to transition to IPv6 quickly, to gain the
many benefits it promises in the areas of addressing, routing and security.
Others are taking a much more cautious approach, noting that the dire
predictions in the mid-1990s of IPv4's imminent doom have not come to pass, and
arguing that we should take our time to make sure IPv6 is going to work on a
large scale.
These two groups will continue to play tug-of-war
for the next few years, but it seems that the tide is now turning towards those
who want to speed up the now-years-long transition. The move towards adoption of
IPv6 as a production protocol is being spearheaded by a number of groups
and organizations. IPv6 has a lot of support in areas outside the United States,
many of which are running short of IPv4 addresses due to small allocations
relative to their size. One such area is Asia, a region with billions of people,
rapidly-growing Internet use and a shortage of IPv4 addresses.
Within the United States, which has the lion's
share of IPv4 addresses (due to the Internet having been developed in the
U.S.A.), there seems to be a bit less enthusiasm for rapid IPv6 deployment. Even
here, however, IPv6 got a major “shot in the arm” in July 2003 when the United
States Department of Defense (DoD) announced that starting in October of that
year, it would only purchase networking products that included compatibility
with IPv6. The DoD—which of course was responsible
for the development of the Internet in the first place—hopes to be fully transitioned to IPv6 by 2008. This will likely
have a big impact on the plans of other governmental and private organizations
in the United States.
Of course, the creators of IPv6 knew from the
start that transition was going to be an important issue with the new protocol.
IPv6 is not compatible with IPv4 because the addressing system and datagram
format are different. Yet the IPv6 designers knew that since the transition
would take many years, it was necessary that they provide a way for IPv4 and
IPv6 hosts to interoperate. Consider that in any transition there are always
“stragglers”. Like the old Windows 3.11 PC in the corner that you still need to
use once in a while, even when most of the Internet is IPv6 there will still
likely be some devices that are still on IPv4 because they were never
upgraded.
IPv4-IPv6 Transition
Methods
Due to the time that change takes, IETF has been
working on specific provisions to allow a smooth transition from version 4 to
version 6, and hardware and software interoperability solutions to let newer
IPv6 devices access IPv4 hosts. A technique was included in IPv6 to allow
administrators to embed IPv4 addresses within IPv6
addresses. Special methods are defined to handle
interoperability, including:
- “Dual Stack” Devices: Routers and some other devices
may be programmed with both IPv4 and IPv6 implementations to allow them to
communicate with both types of hosts.
- IPv4/IPv6 Translation: “Dual stack” devices may be
designed to accept requests from IPv6 hosts, convert them to IPv4 datagrams,
send the datagrams to the IPv4 destination and then process the return datagrams
similarly.
- IPv4 Tunneling of IPv6: IPv6 devices that don't have a path between them consisting entirely of IPv6-capable routers may be able to communicate by encapsulating IPv6 datagrams within IPv4. In essence, they would be using IPv6 on top of IPv4; two network layers. The encapsulated IPv4 datagrams would travel across conventional IPv4 routers.
Bear in mind that these solutions generally only
address backward compatibility, to allow IPv6 devices to talk to IPv4 hardware.
Forward compatibility between IPv4 and IPv6 is not possible because IPv4 hosts
cannot communicate with IPv6 hosts—they lack the knowledge of how IPv6 works. It
is possible that certain special adaptations might be created to allow IPv4
hosts to access IPv6 hosts. But eventually, all IPv4 devices of any importance
will want to migrate to IPv6.
The IETF has done such a good job in the past
with introducing new technologies, and so much effort has been put into the IPv6
transition, that I am quite confident that the transition to IPv6 will come off
with few, if any, problems. One good thing about the transition is that IPv4 is,
at the present time, still getting the job done, so there is no big hurry to
make the move to version 6. While technologies such as CIDR and NAT are
“band-aids” on IPv4, they have been very successful ones in extending the useful
life of the aging protocol.
IPv6 Addressing
The primary motivation for creating IPv6 was to
rectify the addressing problems in IPv4. More addresses were required, but more than this, the IPv6
designers desired a way of interpreting, assigning and using them that was more
consonant with modern internetworking. Based on this, it's no surprise that many
of the changes in IPv6 are associated with IP addressing. The IPv6 addressing
scheme is similar in general concept to IPv4 addressing, but has been completely
overhauled to create an addressing system capable of supporting continued
Internet expansion and new applications for the foreseeable future.
This section describes the concepts and methods
associated with addressing under IPv6. I begin with a look at some addressing
generalities in version 6, including the addressing model, address types size
and address space. I discuss the unique and sometimes confusing representations
and notations used for IPv6 addresses and prefixes. Then I look at how addresses
are arranged and allocated into types, beginning with an overall look at address
space composition and then the global unicast address format. I describe the new
methods used for mapping IP addresses to underlying physical network addresses.
I then describe special IPv6 addressing issues, including reserved and private
addresses, IPv4 address embedding, anycast and multicast addresses, and
autoconfiguration and renumbering of addresses.
Addressing under IPv6 is outlined in the main
IPv6 RFC, RFC 2460 (Internet Protocol, Version 6 (IPv6)
Specification). However, most of the details of IPv6 addressing are
contained in two other standards: RFC 3513 (Internet Protocol Version 6
(IPv6) Addressing Architecture) and RFC 3587 (IPv6 Global Unicast
Address Format). These replaced the 1998 standards RFC 2373 (IP
Version 6 Addressing Architecture) and RFC 2374 (An IPv6
Aggregatable Global Unicast Address Format).
IPv6 Addressing Model and Address Types
In the IPv6
overview section I explained that IPv6 represents a
significant update to the Internet Protocol, but that its modifications and
additions are made without changing the core nature of how IP works. Addressing
is the place where most of the differences between IPv4 and IPv6 are seen, but
the changes are mostly in how addresses are implemented and used. The overall
model used for IP addressing in IPv6 is pretty much the same as it was in IPv4;
some aspects have not changed at all, while others have changed only
slightly.
Some of the general characteristics of the IPv6
addressing model that are basically the same as in IPv4:
- Core Functions of Addressing: The two main functions
of addressing are still network interface identification and routing. Routing is facilitated through the structure of addresses on the
internetwork.
- Network Layer Addressing: IPv6 addresses are still
the ones associated with the network layer in TCP/IP networks, and are distinct
from data link layer (also sometimes called physical) addresses.
- Number of IP Addresses Per Device: Addresses are still assigned to network interfaces, so a regular host like a PC will usually have one (unicast)
address, and routers will have more than one, for each of the physical networks
to which it connects.
- Address Interpretation and Prefix Representation:
IPv6 addresses are like classless IPv4 addresses in that they are interpreted as
having a network identifier part and a host identifier part, but that the
delineation is not encoded into the address itself. A prefix length number,
using CIDR-like notation, is used to
indicate the length of the network ID (prefix length).
- Private and Public Addresses: Both types of addresses exist in IPv6, though they are defined and used somewhat differently.
Of all the changes introduced in IPv6, easily the
most “celebrated” is the increase in the size of IP addresses, and as a result,
the increase in the size of the address space as well. It's not surprising that
these sizes were increased compared to IPv4—everyone has known for years that
the IPv4 address space was too small to support the future of the Internet.
What's remarkable is just how much the increase is, and what the implications
are for how Internet addresses are used.
In IPv4, IP addresses are 32 bits long; these are
usually grouped into four octets of eight bits each. The theoretical IPv4 address space is 232,
or 4,294,967,296 addresses. To increase this address space we simply increase
the size of addresses; each extra bit we give to the address size doubles the
address space. Based on this, some folks expected the IPv6 address size to
increase from 32 to 48 bits, or perhaps 64 bits. Either of these numbers would
have given a rather large number of addresses.
However, IPv6 addressing doesn't use either of
these figures; instead, the IP address size jumps all the way to 128 bits, or
sixteen 8-bit octets/bytes. This represents a truly remarkable increase in the
address size, which surprised a lot of people.
IPv6 Address Space
The 128 bits of IPv6 addresses mean the size of
the IPv6 address space is, quite literally, astronomical; like the numbers that
describe the number of stars in a galaxy or the distance to the furthest
pulsars, the number of addresses that can be supported in IPv6 is mind-boggling.
See Figure for an idea of
what I mean by “astronomical”.
 |
Since IPv6 addresses are 128 bits long, the
theoretical address space if all addresses were used is 2128
addresses. This number, when expanded out, is
340,282,366,920,938,463,463,374,607,431,768,211,456, which is normally expressed
in scientific notation as about 3.4*1038 addresses. That's about 340
trillion, trillion, trillion addresses. As I said, it's
pretty hard to grasp just how large this number is. Consider:
- It's enough addresses for many trillions of addresses to be
assigned to every human being on the planet.
- The earth is about 4.5 billion years old. If we had been
assigning IPv6 addresses at a rate of 1 billion per second since the earth was
formed, we would have by now used up less than one trillionth of
the address space.
- The earth's surface area is about 510 trillion square meters. If a typical computer has a footprint of about a tenth of a square meter, we would have to stack computers 10 billion high blanketing the entire surface of the earth to use up that same trillionth of the address space.
Okay, I think you get the idea. It's clear that
one goal of the decision to go to 128-bit addresses is to make sure that we will
never run out of address space again, and it seems quite likely that this will
be the case.
Why Were IPv6 Addresses Made So
Large?
However, there are drawbacks to having such a
huge address space too. Consider that even with a 64-bit address, we'd have a
very large address space: 264 is 18,446,744,073,709,551,616 or about
18 million trillion, still probably more addresses than we will ever need.
However, by going instead to 128 bits we have made dealing with IP addresses
unruly (as we'll see in the next topic) and we have also increased overhead,
since every datagram header or other place where IP addresses are referenced
must use 16 bytes for each address instead of the 4 that were needed in IPv4, or
the 8 that might have been required with a 64-bit address.
So why the “overkill” of going to 128 bits? The
main reason is flexibility. Even though we can have a couple
zillion addresses if we allocate them one at a time, that makes assignment
difficult. We got rid of class-oriented addressing in IPv4 due to the fact that
it wasted address space, which is true. The reality, though, is that being able
to “waste” address space is a useful luxury.
Having 128 bits allows us to divide the address
space and assign various purposes to different bit ranges while still not having
to worry about running out of space. In
the topic describing the IPv6 global unicast address format we'll see one way that those 128 bits are put to good use; it allows
us to create a hierarchy of networks while still saving 64 bits for host IDs,
which has its own advantages.
