Those who cannot remember the past are condemned to repeat it.
So—if you were sitting down to design what was to become the most popular networking protocol in the world, what would you do?
Well, if you're anything like us, you probably still feel a chill on cold nights when you remember the more exciting times you've had debugging weird problems with IPv4. Consequently, we'd guess you'd try to create a protocol that, whatever other deficiencies it had, definitely didn't have the problems that kept you up until 3 a.m. last Saturday. The designers of IPv6 have done their best to address the well-known limitations of IPv4, while avoiding introducing new ways to keep you awake at night.
That's what this chapter is: an attempt to distill some of the more notable (some might say, broken) characteristics of IPv4, pointing out the motivations thereby deriving that drove the design of IPv6. Some of you might find this material familiar enough to skip; we don't mind. Others might find a refresher useful, or would like to know what tack we take on their favorite issue. For those and others, please read on.
An IPv4 address is 32 bits long. They are usually written
in dotted quad form,
a.b.c.d where each of a, b, c and d are
decimal numbers in the range 0-255. So the addresses range from
255.255.255.255. This means that there is an
upper limit of 4,294,967,296, or about 4 billion, addresses. Since the
address is, in truth, just a number, people sometimes refer to IPv4
addresses as IP numbers.
The whole space was originally split into fixed chunks, called classes, that had particular meanings. Class A, B and C networks are the best known divisions of the range. A single class A address had 8 bits of network and 24 bits of host addresses, a class B address had 16 bits of network and 16 bits of host address and a class C address had 24 bits of network address. You knew what class of network you were looking at by what range that address fell into. (Table 1-1 shows these ranges.) As it turned out, doing classful allocation was horribly inefficient, and led to the development of a better way of doing network boundaries, called CIDR, which we discuss below.
Table 1-1. IPv4 traditional address ranges
As can be seen from Table 1-1, a range of addresses was later set aside for multicast. For a variety of reasons, multicast in the IPv4 world has remained a rather fringe activity, as we discuss in Section 1.5 later in this chapter.
In each of the A, B, and C ranges, a certain address space was
set aside as "private" address space, to be used by those who wanted
to use IP networking but wouldn't need their hosts to be publicly
addressable by the Internet. These are the well-known ranges
192.168.255.255, currently described in
RFC 1918. Note that these aren't the only ranges of
IPv4 addresses reserved for special purposes; RFC
3330 gives a summary of the special use blocks.
IPv4 allows for broadcasts, and there was initially some confusion about what address within a range should be used to symbolize the broadcast address. Some implementors used the first address (all 0s for the host part) and others used the last address (all 1s). The standard practice is now to use the all ones address, and the all zeros address is considered to be reserved as the network's address.
Classless Inter-Domain Routing (CIDR) was a break from the notion that you could determine the network size by knowing it was class A, B or C. It's central idea was to do away with separating network and host parts of an address on byte (8-bit) boundaries only.
With CIDR, the boundary between network and hosts can fall on
any of the bits of the address, and networks can be described by the
all-zeros network address followed by the number of bits in the host
part. For example, the old
10.0.0.0 class A network would be written
8 refers to the number of bits in the network
part of the address. The class C network
192.168.1.0, which previously was the
smallest network that could be allocated, could be now be
subdivided. For example, it could be split into 4 networks:
192.168.1.192/26. The number on the right
can range from 32, meaning a single host, to 0, meaning every
possible host, or "match everything." The important thing to note is
that every decrement of this number doubles the size of the relevant
network. For example,
is twice as big as
and contains it! This is an important idea. It means that a
collection of multiple networks can often be represented by a single
CIDR block instead of an explicit list of candidate networks. This
means multiple adjacent networks can be
aggregated into a single CIDR block, allowing
more efficient description in routing protocols, access lists and
With CIDR the smallest normal network that can be allocated is
/30, because the all zeros and
all ones addresses are reserved and you need to have space for at
least one host. This means that for the network associated with a
point-to-point link, 4 IPv4 addresses are usually consumed.
(RFC 3021 discusses how
/31 networks work, but this requires that
the devices at both ends of link support it.)
CIDR addressed several problems. First, it allowed smaller allocations of IP addresses, slowing the rate at which IPv4 addresses were consumed. Second, it allowed routing tables to be more compact as routes to several adjacently numbered networks could be merged into a single representation. Aggregation, as this is called, is an extremely powerful technique for making routing more efficient. Indeed, on backbone networks where default routes are not available, it is aggregation that makes routing possible at all.
CIDR has been quite successful in preventing classful IPv4 from exploding at the seams, but isn't perfectly efficient, and is in essence a delaying tactic. Its guiding principle, assignment of network and host boundaries within an address, is accommodated within IPv6 already.
We'll see that in IPv6 there are different ways to address "all hosts on a subnet." Consequently, there's no necessity to waste space in every allocation on addresses with special meanings, as is done in IPv4.