IPv6 Network Administration

Content preview·Buy reprint rights for this chapter

Those who cannot remember the past are condemned to repeat it.

George Santayana

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 0.0.0.0 to 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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 0.0.0.0 to 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
Class	Range	Netmask/Comment
A	`0.0.0.0` - `127.255.255.255`	`255.0.0.0`
B	`128.0.0.0` - `191.255.255.255`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Network Address Translation (NAT) is a technique that has arisen in response to the shortage of globally routable IPv4 addresses. It allows a single IP address to provide connectivity for a large number of hosts. The usual deployment of NAT involves a network of hosts using one of the private address ranges mentioned in the Section 1.1 earlier in this chapter, routing traffic to a gateway or proxy with a private IP address on the inside of the network, and a real IP address on the outside facing the Internet. For outgoing traffic, this gateway replaces the private IP address with its public IP address and uses port numbers to remember the private IP address to which replies should be directed.

For incoming traffic, the gateway looks up the port numbers in a table, the original private IP address is determined and the packet is forwarded to the host in the private network. The details of traditional NAT are discussed in RFC 3022.

Because of the economics of IPv4 addresses, NAT has proven extremely popular with small businesses and home users. While one cannot strictly speaking sell IP addresses, ISPs commonly attach a charge for routing and other services to make these addresses useful. This cost is often prohibitive for many users of the SOHO persuasion. NAT has provided a way to connect an entire office to the Internet using a single, cheap dialup connection - it might even be cheerful if you're lucky.

NAT has also been used by some organizations as a form of protection against having to change the addresses of their network. This renumbering of a network might be required because of a change of ISP, or because the organization was using IP addresses unsuitable for use on the general Internet. Renumbering in the IPv4 world is quite a tricky process and the use of private addresses has actually made renumbering more common, as distinct groups can, and often will be using the same private address range, creating problems if they merge. As we will see later, IPv6 goes to some effort to make renumbering less painful.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

IPv4 was designed with a network of relatively trusted users in mind where the network infrastructure was likely to be relatively secure and the information that was being transmitted was relatively public. Consequently, it did not seem important at the time to include security features, like non-repudiation or authentication, directly into the protocol.

But over its lifetime, the way the IPv4 Internet has been used has changed radically. The huge number of users of the Internet mean that trusting them all is simply not an option. The network infrastructure itself now involves cooperation between a large number of public and private organizations, with wildly differing agendas. Most significantly, the data that is being transmitted on the Internet now is often commercially, financially or personally sensitive. From a security perspective, IPv4 is way out of its depth.

As a consequence of its origin, security in the IPv4 world has not been provided by the basic, underlying transport protocol. Instead, as the need has arisen, application level security (one time passwords, SSH, TSIG, etc.) or manipulation of the protocols (packet filters and firewalls) have been introduced to provide security. These solutions have often had an ad-hoc character, and have suffered the attendant limitations: different management schemes, different levels of security provided, and duplicated effort. SSL, the most successful of these compromises, has been designed in such a way that it can be applied in situations other than HTTP, for which it was originally devised.

We'll briefly consider the implications of security not being provided by IPv4 itself—particularly in the case of DNS—but the same issues apply to most IP-based protocols, and protocols underlying IP, such as ARP (see the Section 1.4 later in this chapter).

From a security perspective, the gods have not smiled on DNS over IPv4. Most queries are conducted over UDP. The UDP protocol, while being lightweight and kind to small CPUs, is easily tampered with. The protocol fields can be guessed in many cases, and where they can't, it's possible to use a flooding technique to populate the wire with candidate packets, one of which may be mistaken for the real one. DNS itself has a few additional protections, but they do not amount to much. To fake a response to a DNS request you must correctly guess an ephemeral port number and a query-ID. In the case of DNS the port numbers are often easy to determine and some DNS implementations produce guessable query-IDs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

IPv4 Ethernet networks require a mechanism for nodes to find out which link-layer addresses correspond to which layer three addresses. In other words, how does a machine locate the link-layer address for a given IP address that is on your network? In the vast majority of conventional networks today, this is done using a protocol called ARP, defined in RFC 826.

The protocol works as follows: hosts maintain a table of the link-layer addresses corresponding to IPv4 addresses. When a packet needs to be transmitted, the host checks this table and uses the link-layer address, if it is present. If not, the host broadcasts an ARP request message saying, "Here are my IP and link-layer addresses, who knows the link-layer address for X?" The target host is expected to construct a reply and send it to the requester. Note that the ARP request is a broadcast and contains the information needed to form a table entry for the requesting host. Crucially, this allows the reply to be sent without issuing any further ARP requests.

Although ARP works very well when no-one is fiddling with it, it has a number of key deficiencies when it comes to security. First, when you receive an ARP reply, there is no guarantee that it has actually come from the correct system. Anyone who is on the same medium can fake this reply if desired, and there is nothing that can easily prevent this. Sophisticated attackers, having targeted a key machine, can perform a DoS attack or otherwise disrupt the network interface of that machine. They then can bring up a virtual address or alias on another machine, and ARP will take care of the rest, redirecting new connections to the replacement machine. (This kind of attack is often referred to as ARP poisoning.) If the attackers have replaced key infrastructure servers like DNS or proxy servers it's entirely possible they can begin to use this foothold to obtain more authentication "tokens," whether they be usernames, passwords or off-site accounts.

Second, on most systems, it is possible to specify the mapping from IP address to MAC address in a configuration file, allowing you to hardwire addresses in the ARP table. Although this allows you to mitigate the effects of ARP poisoning, this is a very inflexible configuration, and will eventually cause problems when someone forgets that the old MAC address has been hardcoded into many arbitrary systems within their network. We can't recommend it as a technique in large networks.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Another feature of ARP is that it is a broadcast protocol, which means its transactions are heard network-wide. Every time a host receives a broadcast, it must process the packet, even if, as must be the case in sufficiently large networks, the packet has nothing to do with the host. This can add up to phenomenal amounts of traffic on (badly-designed) flat networks. (There are urban legends floating around of a network on which it is impossible to plug in machines of below a certain specification, because they do not have the processing power to deal with the volume of ARP and other broadcast packets. If you find such a network, let us know.)

Multicast is an entirely more sensible way to hold multiway conversations. Multicast allows you to address a group of hosts interested in a particular type of network traffic without disturbing uninterested bystanders. The Section 3.3.4 talks more about IPv6 multicast.

Unfortunately multicast never really took off on IPv4 networks. There are a variety of likely reasons for this: it's not enabled by default, it takes significant work to configure and most of the target applications for multicast involve cooperation across multiple administrations. This is a pity, as multicast is useful and well-designed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Quality of service (QoS) refers to the ability to give guarantees that the network traffic you send gets there on time (there's a longer discussion of QoS in the section Section 3.10). One of the earliest approaches to guaranteeing a certain level of QoS in IPv4 networks was a field called "Type of Service" in the IP header. This field is included in the RFC 791 definition of IP, and clarified further in RFC 1349. In this model, the IPv4 header itself contains fields that are set to particular values depending on what kind of treatment the packets "want" from routers; the idea being that packets proclaiming themselves to be worthy of immediate forwarding will be plucked out of queues by routers and preferentially dealt with. Unfortunately this was a rather crude approach, not widely implemented, and in its first revision died a death. Perhaps the two biggest problems with it were that it provided no mechanism for authenticating the request for a particular QoS, and that there was no flexible way to assign priorities within a particular set of flows, such that certain ones could be designated lower priority. In essence, we have the rather contradictory result that a mechanism introduced to allow for more appropriate and fairer treatment of packets leads to unfairness!

There have been various efforts to retrofit more complete QoS features to IPv4, especially now that some people consider IP networks `mission critical' and others want to run their telephones over their IP infrastructure. There has been a significant amount of work designing frameworks such as DiffServ (RFC 2475, ...) and IntServ (RFC 1633, ...), and protocols such as RSVP (RFC 2205, ...) to deal with QoS. It's unclear whether we will ever see wide ranging public deployment of these mechanisms, as they require significant cooperation between networks. Some potential adopters discover that, rather than invest time and equipment into deciding which packets to drop, it is cheaper to buy more bandwidth so that all the traffic gets through! There is no question, however, that a well-implemented mechanism to offer QoS guarantees would be of immense value to IP users in the future. This is what IPv6 attempts to provide the infrastructure for; only time will tell if it succeeds.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Of all the sections we cover here, this is probably the one where IPv4 has survived best. It is certainly true to say that the routing infrastructure of the Internet has scaled beyond anyone's original expectations, and it continues to work quite well, with only the occasional continent-sized hiccup.

Dynamic routing, after all, is what sets IP apart from its circuit-switched cousins in the telco world. Within an administrative domain (an organization, campus, or any entity that has control over a "single" network) there are a few options available when the time comes to deploy a routing protocol.

Until the mid-1990s, the no-brain choice for internal routing was RIP. Its main attraction? It was, and it remains, extremely easy to configure. It's still out there, and not just in legacy installations, but the list of factors that make it less than optimal for use on the Internet at large has grown over time. For one, RIP was designed for a classful world. This is the reason most frequently trotted out by rabid anti-RIP fanatics like, well, us, but it's also the least convincing—classless routing was retrofitted, along with a bunch of other stuff, into RIPv2.

Much as we would like to dispense with it, RIP is still around in the IPv6 world, and we deal with it in more detail in Section 1.7 in Chapter 3 and the Section 6.3.3 in Chapter 6. Thankfully, there are much better internal routing protocols available these days—ones which do not limit the growth or management capabilities of your network quite so much. Apart from mentioning that IPv6 has been defined for these protocols also, we don't need to talk about it in any more detail until Chapter 3. As much as we might wish them to, however, neither RIP nor its link-state cousins will scale to encompass the wider Internet.

BGP is the protocol that is used to route between large networks on the Internet. It works (for complex values of works) by communicating information about who can reach which CIDR prefixes (in essence, which addresses) via which networks.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

IPv4 has problems. Some of them can be worked around, some not; but as time goes on, new applications will pile increasing amounts of cruft on top of the venerable protocol, making a new start even more attractive. We've outlined some of the ways in which IPv4 has been overstretched, primarily in the security and traffic management arenas, and next we will cover the things that IPv4 has done well.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If we want things to stay as they are, things will have to change.

Il Gattopardo, Giuseppe Tomasi di Lampedusa

Before we talk about how well-designed IPv6 (and how it fixes all the broken things in IPv4, honest!) it's worth pausing for a little bit to understand exactly what we can learn from the more successful elements of IPv4. These elements have informed and guided the design of IPv6, so it's worth examining in detail both the principles behind the design decisions, and the results of them. In many ways, the design of IPv6 can be said to have started when IPv4 was first created; so it, and we, will be beneficiaries of the hard work done and the lessons learned from over 20 years of deployment.

This first element is the most important consideration, and also quite a strange one. Initially you might think that simplicity was quite a philosophical or aesthetic principle, with no practical implications. Perhaps surprisingly, the opposite is actually the case; the desire for simplicity springs not solely from the human desire to create the elegant or the beautiful, but rather from sound engineering principles. The simpler a thing is, the easier it is to understand, the easier to control, the faster to operate, and the simpler to build upon. Put this way, simplicity in protocol design seems like such an obvious criterion, it's difficult to see who could argue for the opposite.

IPv4 itself was substantially simpler than its competition when it was created—that primarily being the somewhat top-heavy OSI protocols—although it did use some of the more abstract concepts behind OSI to advantage, in particular the notions of layering protocols, and abstracting transport from the particular way in which it happened to be implemented (say, connectionless or connection based communication, for example.) There were also attempts to deal with anticipated problems like QoS with the ToS field; in this case, perhaps a case of being too simple for the job at hand.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This first element is the most important consideration, and also quite a strange one. Initially you might think that simplicity was quite a philosophical or aesthetic principle, with no practical implications. Perhaps surprisingly, the opposite is actually the case; the desire for simplicity springs not solely from the human desire to create the elegant or the beautiful, but rather from sound engineering principles. The simpler a thing is, the easier it is to understand, the easier to control, the faster to operate, and the simpler to build upon. Put this way, simplicity in protocol design seems like such an obvious criterion, it's difficult to see who could argue for the opposite.

IPv4 itself was substantially simpler than its competition when it was created—that primarily being the somewhat top-heavy OSI protocols—although it did use some of the more abstract concepts behind OSI to advantage, in particular the notions of layering protocols, and abstracting transport from the particular way in which it happened to be implemented (say, connectionless or connection based communication, for example.) There were also attempts to deal with anticipated problems like QoS with the ToS field; in this case, perhaps a case of being too simple for the job at hand.

IPv6 has a similarly simple basic design. It has dropped some features that were seldom used in IPv4 and added some simplifying features, such as stateless address autoconfiguration. In some areas IPv6 has retained complexity though, such as mobile IP and IPsec. This complexity is probably unavoidable if we want to actually do something about the problems of mobility and security.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

By resiliency, we mean two things.

First, consider an average network. At any given time, there may be various adverse conditions present. These conditions may be environmental, inherent or of some other form. Regardless of these, IPv4 can often continue to work. For example, network congestion, error-prone lines, memory overload, and so on, are all problems IPv4 has proven able to cope with.

Second, the specification for IPv4 is written in such a manner that it admits of "reasonably" coherent definition, and can be implemented in a finite amount of time, by a finite number of people, for a finite amount of money. Not all networking standards have had such felicitous specifications. It's a real testimony to the robustness of IPv4 that the stack has made it into an incredible array of computing equipment, and particularly into embedded systems, tiny machines with barely a single kilobyte to spare that somehow squeeze in a full IPv4 stack. Indeed, if IPv4 had an overly vague specification, the economics of embedded systems would have made it impossible to produce embedded devices supporting IPv4.

Accordingly, in IPv6, we would like for the specification to be coherent, complete, and not contain any hidden "gotchas" that only emerge under unusual circumstances, such as heavy load or limited memory availability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

IPv4 has scaled to support the whole Internet—surprising or self-evident as that statement may be, it is still a useful observation. IPv4 has definitely had growing pains, but the Internet operates remarkably well for a global network run by hundreds of thousands of organizations in cooperation. There are few things that work as well internationally.

Why might this be? The reasons for this are partially administrative and partially technical. From a technical perspective, we would have to highlight the distributed nature of DNS, the CIDR addressing architecture, followed by independence of the underlying hardware as important features that allowed the Internet to grow to its current size using IPv4.

Administratively, the fact that IPv4 networks can be run independently by organizations, with cooperation along the network's borders, means that the problem of a central administration becoming the bottleneck for growth is reduced. In fact, this has resulted in the Internet being divided into many distinct routing domains, called Autonomous Systems, and using BGP means that each network can avoid having to know the internal details of every other network.

Given the above, IPv6 should scale at least as well as IPv4—and in fact, there's every reason to believe it can do much better than IPv4.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

One final point to note is that IPv4 has proved to be flexible, allowing it to accommodate solutions to problems as they arise. CIDR increased the yield of a given portion of address space, NAT reduced the demand on address space, and BGP evolved to accommodate the needs of the routing community. In one respect this is bad, as you could view these as hacks fixing problems in the original IPv4 design. On the other hand, future-proofing is almost impossible without flexibility, and this is something the design and deployment of IPv6 needs to account for.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In the early days of IPv4, host (re)configuration was something that required the intervention of a skilled operator. Even in the early days of the Internet boom, end-users were required to enter IP addresses and other configuration details manually. However acceptable this might have been to early adopters at the time, automatic configuration was absolutely necessary in getting less technically savvy people on-line. Even today, reconfiguration of a host can be tricky if it has the same IP address for a long time, as an address can gradually appear in more and more configuration files, forgotten about until that crucial moment.

The two main protocols that perform this configuration, DHCP for corporate networks, and PPP for dialup, have played large parts in getting us to the Internet penetration levels we see today. DHCP helps to centralize IP configuration details for networks, making it possible for end-users to "plug-and-play" without having to ring the hapless network administrator to find out their DNS settings. PPP, and its cousins PPPoE and PPPoA, have relieved the consumer ISP's end users of almost any configuration work beyond typing a username and password.

This is a particularly key element for deploying large networks and IPv6 aims to improve autoconfiguration even further—providing large networks with limited support staff should be possible with IPv6.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

It is fair to say that the uses to which the Internet is put today were not foremost in the minds of the designers of IPv4. The open and simple nature of IPv4's design means that it has been possible to build applications such as remote-login, the Web and peer-to-peer file sharing without repeatedly returning to the drawing board. We mentioned before the notion of networking "layers," originating with the OSI 7-layer model described in Chapter 1, which is partially responsible for this, but it's a testimony to good engineering that there are so few hidden dependencies between levels. IPv6 also preserves this decoupling.

The simplicity of IPv4, discussed in Section 2.1 of this chapter, is almost certainly another reason why it has been extended and pushed in unusual directions. It works on the principle of giving people simple building blocks, which can be assembled in weird and wonderful ways.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

IPv4 is simple enough that people can understand and implement it. It is flexible and robust enough that it has been possible to apply it in areas it was not originally intended for, and change it without breaking everything. It has even become relatively easy for nontechnical users to configure. Hopefully, IPv6 has picked up these good qualities of its older sibling.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Perfection, of a kind, was what he was after.

Epitaph on a Tyrant, W.H. Auden

In this chapter we'll cover the features of IPv6 and the basics of its design. This will be a quick tour, addressing the topics of immediate relevance to those using or about to use IPv6. Our intention is to present the information in an easy-to-understand overview format first, and then to get down to the juicy details later in Chapter 4 and Chapter 6.

When we talk about networking protocols in general it's important to understand the difference between specification and implementation. Specifications are written in IETF RFCs and are hotly debated. Implementations are prepared to those specifications, generally by coders or systems people. If you had to choose which one of these to get right, it should of course be the specifications. Broken implementations that misbehave or don't interoperate can always be rewritten, or even gradually refined; but if your design is inherently broken, you might as well throw away all your work and start again. Since (at the time of writing) we are in a relatively early stage of adoption, we expect that implementation quality will vary across different stacks, but the design is definitely right. Lessons learned during the last few decades of networking have been incorporated into the architecture of the protocol, and so the existing problems with IPv4 have been addressed. In fact, some of the problems with IPv4 will only grow worse over time, and if IPv6 didn't take them into account, it might flounder even before IPv4 reaches the end of its life.

Perhaps the biggest and most important problem facing IPv4, which will only grow over time, is address space exhaustion.

Address space is, with both IPv4 and IPv6, a finite resource. There are only so many addresses that can be allocated from any fixed range. Furthermore it's a hard limit, pending a change in the meaning of addresses as they are currently understood; one day, you will reach into your "address bag" to assign some new addresses, and there won't be any more there. Perhaps this won't be a problem for you immediately—who can say when you might need to grow your network—but it will certainly be a problem for the people you need to communicate with, so it thereby becomes everybody's problem.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When we talk about networking protocols in general it's important to understand the difference between specification and implementation. Specifications are written in IETF RFCs and are hotly debated. Implementations are prepared to those specifications, generally by coders or systems people. If you had to choose which one of these to get right, it should of course be the specifications. Broken implementations that misbehave or don't interoperate can always be rewritten, or even gradually refined; but if your design is inherently broken, you might as well throw away all your work and start again. Since (at the time of writing) we are in a relatively early stage of adoption, we expect that implementation quality will vary across different stacks, but the design is definitely right. Lessons learned during the last few decades of networking have been incorporated into the architecture of the protocol, and so the existing problems with IPv4 have been addressed. In fact, some of the problems with IPv4 will only grow worse over time, and if IPv6 didn't take them into account, it might flounder even before IPv4 reaches the end of its life.

Perhaps the biggest and most important problem facing IPv4, which will only grow over time, is address space exhaustion.

Address space is, with both IPv4 and IPv6, a finite resource. There are only so many addresses that can be allocated from any fixed range. Furthermore it's a hard limit, pending a change in the meaning of addresses as they are currently understood; one day, you will reach into your "address bag" to assign some new addresses, and there won't be any more there. Perhaps this won't be a problem for you immediately—who can say when you might need to grow your network—but it will certainly be a problem for the people you need to communicate with, so it thereby becomes everybody's problem.

So what's the scale of this risk? Well, prior to CIDR, IPv4 address allocation, based on class A, B and C addresses, had been over-generous to some users, and address space allocation was running out of control. Today, allocation policies are much stricter, and address space is assigned more frugally. So, the end has not been deferred indefinitely, but the process is definitely under much better control. However, time is inevitably running out: only 36% of the total IPv4 address space remained in 2002, and, depending on whose extrapolations you believe, the remaining space runs out some time between 2005 and 2035. Recent measurements by Geoff Huston suggest that stricter policies have helped considerably, and we may be looking at the upper end of that range. However, even if IPv4 addresses remain available for the next 200 years, but obtaining them requires you to write longer and increasingly baroque essays on why you deserve them, that's little good to anyone.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The IPv6 packet structure is, in most ways, very similar to the IPv4 packet structure. Some fields have been removed and some have been added, but the most obvious change is the size of the addresses. While the IPv4 source and destination addresses are 32 bits each, IPv6 addresses are 128 bits each. The reason for 128 bits is discussed in the following sidebar,

People who remember the second law of thermodynamics (or who have worked in large organizations) know that it is impossible to have a perfectly efficient system. As it is with heat exchangers, so it is with network protocols.

In particular, when addressing endpoints in a real network, from any limited pool, there is a certain amount of the addresses that will be "lost," or inefficiently allocated. This is not simply due to factors in the protocol itself (for example, wasting addresses on the broadcast address in point to point links) but is also due to real world concerns like administrative error, customer churn, aggregation, and so on. It turns out that this error is actually measurable, and we do it using a metric called the host density ratio, or HD ratio. This is a number that increases from zero to one as the address space fills. For reference, it's defined as:

Empirical calculations for telephone number allocation and network address assignment show that a HD value of 0.8 is reasonable but a HD value of 0.85 is overcrowded. RFC 3194 goes into more detail.

Having examined common real-world ratios, let's ask how well can IPv6 do by comparison. One might think that although the size of the address is so much larger, perhaps the inefficiency is larger too, and we might well be back in an IPv4-type address crunch in 10 years time.

Well, let's look at the numbers. For IPv4 a HD ratio of 0.8 corresponds to 2^{32
* 0.8}, or about 50 million hosts. The Internet Domain Survey,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Those of you who are familiar with IPv4 networks may have encountered the notion of private versus public address space. Private address space is address space used within an organization's network, and in theory it cannot be reached from the outside world (often people like to pretend that this gives them additional security, see "NAT" in Chapter 1). These addresses are an example of address spaces with special properties—and often (but not always) these types of address space can be inferred by glancing at the address.

Examples of special addresses from the IPv4 world include the private class A space 10.0.0.0/8, which is discussed in the "Addressing Model" section in Chapter 1, and would be familiar to those building enterprise networks. Similarly 127.0.0.0/8 is the "localhost" space, which hosts use to contact themselves.

One interesting IPv4 special address is the "broadcast" address in IPv4, 255.255.255.255, because it has no direct equivalent in IPv6. Broadcasts no longer exist in IPv6, and multicast is used as the transport for contacting multiple hosts simultaneously.

Similarly in IPv6 there are a number of address spaces, usually expressed as a prefix with CIDR network length. The official breakup of this space is documented on the IANA web site http://www.iana.org/, but we summarize the allocations in Table 3-1.

Table 3-1: The breakup of the IPv6 address space
Prefix	Intended use
`::0/96`	Unspecified/loopback/compatible-IPv4 address
`::ffff:0.0.0.0/96`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

TCP and UDP have both remained unchanged from IPv4 to IPv6. ICMP is a very different story, as ICMPv6 encompasses the roles filled by ICMP, IGMP and ARP in the IPv4 world. Some aspects of ICPMv6 will be familiar to those who have worked with their IPv4 equivalents: ICMP Echoes and Errors, for example. However, the most important changes are in the area of neighbor discovery, which will be unfamiliar to IPv6 newcomers. We discuss this in the Section 3.4.2 section later in this chapter.

RFC 2463 covers the part of ICMPv6 that is most similar to the familiar parts of ICMPv4. It covers ICMP Echo Requests and Replies, which are used to implement the well-known ping program. It also covers ICMP errors, which are returned when there is a problem with a packet: Destination Unreachable (because of routing, packet filtering or other unavailability), Packet Too Big, Time Exceeded (when the packet has travelled too many hops) and Parameter Problem (unknown or bad headers).

The original Time to Live field in IPv4 was supposed to be the maximum number of seconds a packet could live in the network before being discarded. In practice, this field was decremented by one by every router that forwarded the packet, regardless of how long the router had held the packet for. Thus, Time to Live is really the largest number of hops a packet can travel.

This has been recognized in IPv6, and the field is now called Hop Limit. However, the ICMPv6 message generated when a packet is discarded as a result of the Hop Limit being overrun is still called "Time Exceeded." Plus ça change.

ICMP messages have often been filtered out in the IPv4 world, which usually results in the failure of tools such as ping and traceroute or delays while waiting for the arrival of discarded "destination unreachable" messages. IPv6 will be even less forgiving in this respect, as correctly operating ICMP is absolutely essential to the protocol. In particular, Packet Too Big messages are now necessary for the valid operation of TCP and UDP because IPv6 routers are not permitted to fragment packets. Nodes need to be told to reduce the size of a packet if it will not fit within the MTU of a link. The process of figuring out the largest packet that can be sent to a particular destination is called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

At this stage, it's clear the typical IPv6 node can, and very probably will, have many addresses. Some may be manually configured, others may be automatically configured via router announcements; some may be link-local and others may be global; some may be permanent and others temporary. From this plethora of addresses, a node must make a choice of which address to use. Depending on the criteria used, the choice could change many times over the course of the uptime of a host. In some cases addresses will be explicitly chosen by users or applications, say where a user types telnet ::1, or where a server is bound to a single IP address. For other situations, there needs to be some predictable mechanism for guiding the selection of addresses by a host; these are the default address selection rules, dealt with in RFC 3484.

In any given two-ended communication, there are obviously two addresses that would potentially have to be decided on; the source, and the destination. Source address selection determines which of a node's addresses will be used to originate a connection to a given destination address. Destination address selection would be typically applied to a list of addresses returned by DNS, sorting them in order of preference.

The selection process is given in terms of a sequence of rules that compare two addresses. You start with rule 1, and if it doesn't tell you which address to prefer then you move on to rule 2, and so on. The rules for source address selection are shown in Table 3-5 and the rules for destination address selection are shown in Table 3-6. Curiously, the rules for destination address selection depend on the source address selection rules, because they involve calculating what the preferred source address would be, given that a particular destination address was chosen! Once a destination address has been chosen, a suitable source address can be selected.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Let's consider some of the implications of the design of the IPv6 header. There is no field equivalent to the IPv4 options field, so the equivalent facilities are now provided by extension headers. These headers, and the fact that the IPv6 header has no checksum, have some influence on how upper level checksums are calculated. Also, the larger addresses used mean that more of a packet is taken up with headers, so header compression is correspondingly more important.

In Section 3.2.1 earlier in this chapter, we observed that the IPv4 notion of including options directly within the main header had been abandoned. However, IP options did serve a purpose, and that purpose is now achieved in IPv6 using extension headers. These headers are chained together. Within the IPv6 header the Next Header field tells you the type of the next extension header, which in turn has a Next Header and so on. The basic types of header discussed in RFC 2460 are the Hop-by-Hop Options header (type 0), the Routing header (type 43), the Fragment header (type 44), and the Destination Options header (type 60).

To make sure this process of chaining headers together terminates, there are a few special types of Next Header that do not themselves have a Next Header field. These include 6 = TCP, 17 = UDP, 58 = ICMPv6 and the rather odd 59, which means "there is no next header."

For example, Figure 3-5 shows an IPv6 packet containing an IPv6 header, followed by a routing header, followed by TCP header and data.

Figure 3-5: Use of the Next Header field

Aside from the Hop-by-Hop header, none of these headers are processed by a node simply forwarding a packet. If there is a Hop-by-Hop Options header, it must be immediately after the IPv6 header. This means that in the usual case a router won't have to look beyond the IPv6 header and doesn't have to go far to analyze the Hop-by-Hop header.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In these days of cellphones and wireless networking of all kinds, mobility for equipment now carries the expectation that you can take your laptop and use it for email, web, and so on more or less anywhere. By default, full mobility is not catered for—in other words, you cannot be on a wireless LAN in one office, put a machine to sleep, take it to another office, and wake it, and expect all existing connections to be preserved and everything to "just work." Furthermore, there are roaming issues with multiple points of access to a given network, address assignment issues and so on. The mobility problems that Mobile IPv6 attempts to solve are a very well-defined subset of these, and have to do specifically with your layer 3 point of attachment to the network, and hence to your address, routing table, and other network infrastructure resources.

So how do we solve the problem of using a laptop in another person's network but still being able to get to your usual, within-home-network resources, as well as maintaining existing connections? The usual mechanisms invoked by the IPv6 stack on a link change, like stateless autoconfiguration, effectively kill existing TCP connections because TCP connections have a fixed address at either end of the connection. Furthermore, RAs in managed networks will have the same effect, and it would be inappropriate to suppress these mechanisms simply for this purpose.

The approach that Mobile IPv6 takes is as follows. Nodes are said to have a home network, which is the network to which they belong to in a logical or organizational sense. This could be a corporate network, in the case of a business laptop, a residential network, in the case of a personal laptop or a particular mobile phone network, in the case of a phone/PDA.

On this home network you will have a home address. While attached directly to the home network, you use this address normally. However, with Mobile IPv6 you can continue to use this address if you move to another network. This requires some infrastructural support.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Routing protocols are clearly very important to the operation of the Internet, but in a sense they are a separate issue from the problems of how low-level IP should operate.

So, how has IPv6 changed routing protocols? Well, the most obvious change you need to make is to allow IPv6 prefixes to be included, rather than IPv4 addresses. In fact, this is generally the only significant change between the IPv4 and IPv6 versions of well-known routing protocols.

Perhaps the most interesting changes in routing caused by IPv6 are in routing policy—in other words, not affecting the prefix processing per se, but affecting the administrative acquisition and control of prefixes. The routes that can be advertised into the IPv6 Internet's global routing table are to be much more strictly controlled than in IPv4. For example, it is hoped that people will not advertise individual /48 prefixes, because (remember!) these should be aggregated into a bigger block advertised by their ISP. We'll talk more about the impact of this in Chapter 4.

For now, let's have a quick look at the routing protocols you're likely to encounter. First we'll deal with IGPs (Interior Gateway Protocols). An IGP is used to route within an organization. IGPs include protocols such as RIP, OSPF, and IS-IS. After IGPs we'll take a look at BGP, which is the main Exterior Gateway Protocol currently in use on the IPv6 Internet.

RIPng is defined in RFC 2080 and is very similar to its IPv4 forebear. It is designed for use in small to medium organizations that don't have a complicated routing setup. How does it work?

Well, each router sends messages (in UDP packets, port 521) that tell its neighbors what prefixes it knows how to reach and the metric associated with each prefix. A router may see a prefix advertised with several different metrics, so to choose the best one it adds a link related cost to each and then chooses the smallest. The cost assigned to each link is usually 1, so that the metric is actually a count of the number of links you must cross to reach that prefix.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

IPv6 enhances network security considerably. Probably the most important contribution it makes is not a technical contribution, but rather a matter of policy—the standard mandates that an IPv6 stack must not be implemented without supporting some form of encryption. It's important to note that this encryption is not at an application layer; that is, it's not a separate ad-hoc mechanism which is differently configured in mail programs than in web browsers than in video streaming applets—it is at a lower layer and can also secure things like neighbor discovery.

This was quite an achievement by the IETF. There are certainly very many jurisdictions in the world that use computers; many of them have severe anti-encryption laws; some of them prohibit its use entirely.

The form of security, IPsec, is already familiar to many as it is the basis of many VPN (virtual private network) systems that are already deployed. IPsec is quite a complicated architecture; see RFC 2401 for more details. In IPv6 it is implemented using extension headers that say that the remainder of the packer is encrypted (the ESP header of RFC 2406) or cryptographically signed (the AH header of RFC 2402). These are basically the same techniques as used in IPv4.

IPsec does, however, come with some downsides. For example, if traffic is regularly encrypted within your network, then debugging or security-related packet-content sniffing is impossible, unless you have the key. For that reason alone, some network administrators insist on configuring a static key for intra-site communication between machines, for ease of debugging. There have been efforts made, however, to ensure that header encryption (as opposed to content encryption) is not mandatory under all circumstances.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Quality of service, henceforth referred to as QoS, is a complicated area. The core concept is quite simple: we, both as network administrators and as users, want to ensure that a certain application can have guaranteed performance on a certain network. When desired by a user, this often translates to statements such as "I wish I could download that ISO before I've got to catch my bus..." and, when desired by a network administrator, generally translates as "How can I stop those ISO downloaders killing the rest of the network?"

Generally, the kind of application we want to guarantee performance for is a multimedia application, not the standard HTTP or SMTP transactions that take place billions of times a day (although in some cases we may want to guarantee that a certain portion of the network will be set aside for critical services). This is because multimedia applications are amongst the most sensitive to packet loss and jitter, given the necessity to have data arrive at the right time for reassembly and display. There are various theories regarding how this should be done:

Smart network, stupid end hosts
Stupid network, smart end hosts
Overdimensioning

The first two schemes differ over where to place the intelligence involved in making QoS decisions, while the last attempts to avoid the problem entirely. Exactly what scheme will provide the best QoS under all circumstances is unclear. Different schemes require different facilities to be available. Rather than make a call on how QoS should work, IPv6 provides some generic facilities that should help QoS designers. These include some fields in the IPv6 header and, of course, extension headers.

There are two ways in which the IPv6 header provides for manipulable QoS. One is the traffic class field, the other is the 20 bit flow label in the IPv6 header. Note, that these fields are available in the base IPv6 header, and so are immediately available to routers, regardless of the Extension Headers that may follow.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Let's finish off this chapter with a quick review of what the features offered by the design of IPv6 are.

IPv6's scalability, the darling of many press releases, is perhaps best broken into two capabilities. First, the capability of the protocol to rise to the task of addressing and routing both the existing and the future Internet. We think everyone can agree that IPv6 has been engineered with this in mind, by allowing lots of address space for hosts and countering the routing problems with a more hierarchical address space, while being flexible enough for future developments. Second, the ability of the protocol to be extended naturally to meet future, as yet unknown, requirements. A very important component of this is the Extension Headers facility.

IPv6 offers significant mobility and security features which, unfortunately, by their nature, are not as simple as might be desired. While support for IPsec is widely available, configuring for interoperability can be tricky. Mobility is at an earlier stage of development, and while implementations are available, full implementations are not yet widely shipped.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When in trouble or in doubt
Run in circles, scream and shout.

Anonymous

At this stage, we've already looked at a good deal of the theory behind IPv6. It's now a good time to start thinking about the i

Table of Contents