The chief thing is not to study, but to do.
Sayings of the Fathers, 1:17
IPv6 has been overhyped, undersold, rubbished, acclaimed, scuppered, and resurrectedâoften several times a day by the same person in different conversations. It's been talked up and talked down, misunderstood, ignored and defended; but it is overcoming barriers and finding growing acceptance and support within the Internet community. For an obscure networking protocol of current interest to a small fraction of the population of our planet, this combination of passion and ignorance seems remarkable. You might ask, `So why all the fuss?' The motivation behind IPv6 is the need to fix the most difficult problems that the Internet faces today: address exhaustion, network management, scalability issues, and multi-homing. It is the promise of addressing[1] these issues that has sparked the interest it has aroused, and that same promise is and will drive its adoption and eventual deployment. In fact, about the only thing that IPv6 hasn't been is widely deployed enough to justify this attention! We hope to do our small part to change that by providing this book to help you make your own judgement, ignoring the gain-sayers and the hype, and focusing on what IPv6 can do for you.
We of course know that technical merit or promise alone is not enough to make something successful, so besides an excellent design and good intentions, what else does IPv6 have going for it? Well, it's been adopted as a standard by organizations such as the 3GPP[2] and well-known industry players such as Cisco, Microsoft, and Sun, it's seen an increasing amount of commercial deployment from organizations such as Microsoft and NTT, and confidence is increasing that the rightful successor to IPv4, the most popular internetworking protocol in the world, has arrived just when we need it the most.
No authors come without bias, this we accept, but in this book we hope to show you what is good, what is bad, and what is practical, acknowledging the faults and praising the innovations. Rather than presenting a protocol design manual or reference work (an endeavour tackled by many others previously) we will present a distillation of what IPv6 means in practice, directly relating it to the hands-on experience of network administrators. We take this approach both when describing IPv6 itself and when discussing how to use itâthis means we don't hesitate to leave things out if they are of marginal utility, but do try to cover processes and procedures in detail.
You might be surprised to know that you get IPv6 functionality for free in a growing number of operating systems; pains have been taken by the designers of IPv6 to make it easy to experiment and work with, and some early adopters are now using it for their day-to-day business.
There are, of course, those who doubt that a serious transition will ever happen, who think that "the devil you know" is better than risking instability of their network. We confess a certain sympathy with that view. However, there are so many precedents for rapid changeâand necessary changeâin this industry. We think it is foolish to ignore what is the only candidate for the future IP protocol of choice. After all, not many people were running a HTTP in 1993.[3] Installed bases are relative things, especially in an industry that can change radically in a year.
Finally, a word on the ultimate success of the IPv6 process. There's no question that of the time of writing, it is mainly the adventurous who are deploying commercial production services over this protocol. Is there room for a sober, conservative approach? Predicting the future of technology is always a risky business. However, it is our contention that the slow growth of frustration with IPv4, the unavoidable issue of address exhaustion, together with the benefits of IPv6 outlined above will eventually cause a critical mass of deployment to accumulate. One point to keep in mind is that the projected IPv4 addressing requirements of China are larger than the total amount of free address space now! Eventually something will have to be done about the crises IPv4 facesâit's just a question of when, and IPv6 is the best shot we've got.
This book tries to take IPv6 into the real world. It is not about understanding dry analysis of header formats and new protocolsâalthough those are obviously fundamentally importantâit is about understanding what those header formats mean for a real organization today; it is about trying to use those headers on your network, and warning you of the dangers and opportunities you will face. It is about helping you to turn IPv6 into something real, something that can be useful to you, and something you feel comfortable with.
In detail, we begin in Chapter 1 and Chapter 2 by describing IPv4 in terms of its successes and failures, as these have influenced much of the motivation for and design of IPv6. Chapter 3 discusses the eventual results of the design process: the core elements of IPv6. Of course, most of us who operate IPv4 networks don't have the full details of IPv4 to hand, so we work with a simplified picture of IPv4 for day-to-day purposes. Consequently, we avoid some of the fine details covered in other IPv6 texts. For those who want to find out more of the details, we have included references allowing you to find out more when you need to.
Chapter 4 deals with planning IPv6 deployment. This includes thinking about how to get connectivity, address space, and how to make your IPv6 infrastructure fit well within your existing network.
The basics of how to configure IPv6 are covered in Chapter 5. We review a selection of popular operating systems, explaining the extent of their support for IPv6 and their basic commands and configuration procedures. We include references to vendor documentation where the detail is distracting.
The later chapters deal with making IPv6 do useful things in your network. Chapter 6 deals with typical operations you might perform on an IPv6-enabled network. The main subjects in this chapter are DNS, IPsec, firewalling and routing; network infrastructure and support services can be found here. Chapter 7 deals with providing services that end-users and customers are actually interested in. Naturally, the main focus here is HTTP and SMTP. Chapter 8 deals with the modifications to the sockets API to deal with IPv6, and should provide a starting point for those who want to port their local network applications to IPv6.
As we've said above, we hope to provide you with the general principles first and specific details later, when their consequences can be properly appreciated. This has translated into the structure of the book as separate sections for operating system and application specific detail, so they can be used more as reference material than as narrative.
For material where the current status of the feature in question is unclear, we've highlighted this. We've also included our guesses as to how things may eventually turn out in Chapter 9.
No major change to the core protocols of the Internet could be introduced without its share of controversy, and IPv6 has had history controversial enough to fill a book on its own. We'll only cover the crudest outline here; for more detail, we suggest you consult Christian Huitema's book IPv6, The New Internet Protocol (Prentice Hall), or, alternatively, IPng Internet Protocol Next Generation, edited by Bradner and Mankin (Addison-Wesley).
To properly understand how IPv6 came into being requires more than a passing familiarity with the organizations that are behind the technical and administrative existence of the Internet. Readers who are already familiar with these can skip ahead; others please continue, for though the acronyms are fast and furious, they are all relevant.
The IETF (Internet Engineering Task Force) are the ultimate networking geeks. Responsible for the standards on which the Internet is based, the "members"[4] of the IETF engage in protocol design, protracted discussions and incessant, mostly cynical, joking. Their guiding principle as engineers is to create protocol standards that work: "rough consensus and running code" is mentioned as the IETF's credo in RFC 2031.[5] There is an interesting Ph.D waiting to be written on IETF culture, but we shall confine ourselves to commenting on its methodology. IETF standards, generally arising from motivations like "This protocol is broken because X is really hard to doâwe need to fix it," or "Hey, wouldn't it be nice if we could do Y?" start as discussions on mailing lists which are categorized by Working Group.
A Working Group is a collection of people and technical resources aimed at considering (usually) a quite specific topic. Working Groups are themselves sorted by subject Area. So, for example, the effort around getting IPv6 up and running is conducted in several working groups, including IPv6 WG, v6ops WG, and multi6 WG. The IPv6 WG is under the Internet Area in the IETF (dealing with design), and v6ops and multi6 is under the Operations and Management Area (making protocols operable).
Working Groups and Areas have people who are responsible for their upkeep. Areas have Area Directors making decisions about items of concern to the Area. Most commonly, they decide whether a working group be created or disbanded. In turn, Working Groups have chairs. These chairs, in co-operation with Area Directors and the members of the Working Group (WG for short), decide what work items the group will adopt. (If all of this sounds bureaucratic, we apologize for misleading you, for although its structure has been well established, the IETF is one of the most successful decentralized organizations permitting public participation in the world.)
Work generally happens on documents known as Internet Drafts. These are basically documents that present information in a standard way. Internet Drafts are passed between the members of a group for comment, feedback, and analysis. Some drafts, if they meet the "rough consensus and running code" benchmark, then work their way up to the hallowed status of RFC (Request For Comments).[6] An RFC is a document that encapsulates the thinking of the Working Group on a particular topic. RFCs are the official "documents of record" of the IETF. Often, they are definitive statements on how certain kinds of network communication must happen; sometimes, they describe operational constraints or other peripherally related topics. You would expect them to have some connection to networking, but apart from that, they could be about literally anything.
RFCs themselves can have different statuses: an RFC on the standards track can work its way from Proposed Standard to Draft Standard to Standard as its maturity grows and its volatility decreases. RFCs that are not intended as standards can be classified as Informational (contains something worth noting), Experimental (something people are trying out), BCP (a codification of Best Current Practice), and Historic (obsolete or superseded). RFC 2026 contains more details about the standardization process.[7]
The IESG (Internet Engineering Steering Group) is a group consisting of all the Area Directors. It has a steering function in terms of setting strategy, but also in terms of resolving disputes arising in the course of IETF work. We may have given you the impression above that all is happy-go-lucky in Internet-land; not so, of course, and when disputes arise, there are procedures for dealing with that too.
The IAB (Internet Architecture Board) is where geeks go when they grow up. The IAB's main job is to oversee the development of standards by the IETF. They can suggest the setup of new Working groups and even propose the creation of longer running research projects. They also appoint the IESG from a list provided by the IETF. (This is a purely formal, rubber-stamping exercise; they perform no selection themselves.)
More details about how the IETF fits together are available in RFC 3160. As it happens, the body giving the most momentum to the IPv6 effort is the IETF.
IPv6 is the culmination of over a decade's worth of work, initially inspired by one of the biggest problems still facing the Internet today: address exhaustion.
It was clear from early on in the development of the Internet that IP addresses, although finite, were perhaps rather more finite than desired. Way back then, it only took approximately two years to go from 10,000 to 100,000 hosts (from the end of 1987 to 1989). At around the same time, the original constituency of military and academic sites had been joined by commercial efforts, as well as an expanding number of countries. The phenomenal growth that was occurring, coupled with the inefficiency of the then-current class-based address allocation method was already starting to arouse concern in the technical community.[8]
The earliest records of a formalized search for a replacement for IPv4[9] are found in the proposal to create an IETF Working Group called "ROAD," in November of 1991. ROAD's brief was to investigate the possible solutions to the near-term scaling problems identified above. ROAD was not a standard IETF Working Groupâit existed for a short time only, and membership was not open; this was done because of the urgency of the scaling problems and the necessity of a quick practical response to it. In March of 1992 ROAD made its final set of recommendations, documented in RFC 1380, that classless interdomain routing [10] should be used to get around the immediate problems of class B address exhaustion and routing scalability, but that more research was needed into future routing and addressing models for the Internet. In other words, the mid- to long-term problems could not be solved within the context of the group.
Dave Crocker[11] of Brandenburg Consulting summarized the situation nicely with this paragraph from his 1992 paper on "The ROAD to a new IP:"
Concern about IP address exhaustion and routing table size explosion has created a sense of crisis within the IETF community. Almost 2 years ago, a special effort, called the ROAD (ROuting and ADdressing) group was formed to consider solutions. It gravitated towards one option, but did not see quick adoption of its recommendation. But time had passed and urgency grew. There has been pressure to select a solution immediately, without extensive exploration and development of options. The Internet Engineering Steering Group (IESG) divided the concerns into short-term, mid-term and long-term. Class-B exhaustion and routing table size explosion fall into the first category. IP address space exhaustion falls into the mid-term timeframe. The IESG feels that other issues of general enhancement to IP, such as quality of service, security/authentication, mobility, resource allocation, accounting, and high packet rates can be deferred for "long term" consideration.
After the delivery of the ROAD recommendations, another Working Group was formed in 1993, called ALE (Address Lifetime Expectation), whose job was to establish the probable lifetime of IPv4 address space given current policies and practices. ALE decided that there was indeed a very short lifetime for the remaining space: one year! Efforts were redoubled to get CIDR out in the real worldâin this case, getting it into CIDR-capable backbone routersâand in administration of address allocation policies.
While this work was highly urgent and necessary, it did not escape the IAB's and the IESG's notice that the larger problem of a future replacement for IPv4 still needed attention. Thankfully, the resounding success of CIDR bought enough time for the establishment of a "next-generation" directorate in the IETF. Oddly enough, the IAB recommended that work should begin as soon as possible on integrating OSI CLNP[12] type addresses into the next version of IP, then called IP version 7.[13] Although this was neither the first nor the last time the integration of aspects of OSI with IP was proposed, it met with as approximately the same amount of success as all the other effortsânone.
In retrospect, it seems the crisis had pushed the IAB into recommending a path, any path, rather than not reacting at all. However, the IAB made it clear that this was not supposed to shortcut the normal IETF process of evaluating and discussing as many proposals as could be found; accordingly, RFC 1550 in December 1993 solicited white papers from the community about what they felt IPng, the next generation of IP, should look like. This was an active attempt to engage all the possible stakeholders, from electricity companies to national research agencies. The Call For Papers wasn't a carte blanche to send in your favorite research protocol though; the reviewers of this process were looking for genuine contenders to the throne, and as such were going to examine proposals for such intangible but nonetheless vital qualities as vision and longevity as well as practical assurances of functionality.
Based on this work, the IPng Working Group very quickly assembled a list of proposals for IPv4 replacements, some of which we examine in more detail below. At the "IPDecide BOF" meeting held at the Amsterdam IETF meeting in July 1993, it was clear that direction from a higher body was necessary in order to help focus and direct efforts because so many complicated issues were involved. The decision was made that the IPng Area Directors should recommend a candidate to the IESG, who would henceforth ratify the decision. There was a retreat by the IESG to discuss the proposals with the IPng Area Director in May 1994; the process as a whole was documented in RFC 1752, "The Recommendation for the IP Next Generation Protocol." Eventually this was approved, consensus was achieved, and it was made a Proposed Standard in November 1994, to be followed by finalized versions in 1995.
Let's now take a quick look at some of the contestants paraded during the selection process. It is often said that the thing the IETF does best is devising acronyms, and the contenders for IPng were no exception.
- TUBA (TCP, UDP with Bigger Addresses or TCP/UDP over CLNP Addressed Networks)
TUBA left the transport layer (TCP and UDP) essentially unchanged, but replaced IP with CLNP. The transition strategies planned to allow the move from IPv4 to TUBA were very similar to the strategies used in IPv6 today: dual-stack, no flag day, et cetera. Initially, the protocol was attractive because of the notion that there could be a final convergence between the OSI networking holdouts and the Internet. However, there wasn't any attention paid to correcting the deficiencies of CLNP, or in particular, the right of the IETF to correct these deficiencies within the context of the IPng effort.
- CATNIP (Common Architecture for the Internet)
An interesting attempt to merge the three most important networking protocols of the day, namely IP, the OSI ISO protocols, and the Novell networking stack (IPX and friends). It decoupled the transport from the other layers such that it was theoretically possible for an end host using IPv4 to communicate transparently via TCP (or other arbitrary transport protocol) to an end host using IPX.
The unification of these protocols was CATNIP's central aim. It was a relevant idea for the time, but in view of the almost complete domination of IP everywhere today, it is much less relevant now. Other aspects, such as transition mechanisms and mobility, were not so well specified, so CATNIP ultimately floundered on too much complexity.
- SIPP (Simple Internet Protocol Plus)
SIPP was the merging of two earlier suggested protocols: Steve Deering's SIP and Paul Francis's PIP, with 64 bits for addresses by default. It had also adopted parts of other proposed protocols, such as IP-in-IP.
SIPP was well documented, but the transition plan had problems and the addresses were thought to be too small. Routing was also felt to be insufficiently reworked, a concern that still persists today.
In the end the decision was to use SIPP as the basis of the next version of IP, but with some changes, including widening the address space to 128 bits.
We'll stop for a moment to mention some of the people you may hear mentioned in relation to IPv6. Naturally, if we were to mention every name this would be a very long section.
Probably the most influential person in the IPv6 community, although he would probably be the first to engage in self-deprecation, is Steve Deering, a Cisco fellow. He, together with Bob Hinden and Margaret Wasserman were co-chairs at the time we started working on this book. However, in October 2002 Steve took sabbatical leave. The v6ops Working Group has been chaired by Jun-ichiro itojun Hagino, Bob Fink, Margaret Wasserman, Jonne Soininen, and Pekka Savola, to name a few. Some of these characters, such as Itojun[14] and Margaret have been members of the IESG and/or IAB.
Christian Huitema is a former member of the IAB and has worked in an impressive variety of places (e.g., INRIA, Bellcore, and Microsoft). We've already mentioned his book on the IPv6 protocol. He's not the only member of the IAB to have taken a special interest in IPv6 though, others include Tony Hain, Robert Elz, Jun Murai, Brian Carpenter, and so on.
Many others have also contributedâjust look at the names of RFC authors for a small, small subset of those engaged in the overall IPv6 project.
Adoption of any new protocol is a multiple stage process. First, it has to be designed! This in itself is often a protracted process,[15] requiring standards committees or IETF standardization efforts to converge on a stable definition. Then the entire specification, or enough of it to usefully implement, has to be written down and expressed clearly enough that the various manufacturers can write the code they need to and put it in their hardware. In the case of IPv6, the policies and addressing models also have to be defined and be operating before adoption can commence. Finally, of course, people have to begin using it.
IPv6 has only recently emerged into the final stage of the process described above, so, unsurprisingly, in comparison to IPv4, adoption is currently low, but it is growing and accelerating. Let's look at some of the reasons for this growth.
The adoption of IPv6 was given a major boost in May 2000 with the acceptance by the 3GPP of a Nokia proposal to use it within certain portions of 3G networks. Specifically, it is required to be used within the IMS portion of the core networkâessentially the component that provides applications and higher-level infrastructural services for handsets. (You can read more about this in Chapter 9.) This, combined with a re-engineering of IPv6 address allocation policies worldwide[16] has fixed two of the most problematic issues preventing adoption. First, the issue of having no confidence in a new protocol, easily solved when a major body steps up to endorse it. Second, the old, Byzantine and unfriendly address request process. Thankfully, since these impediments have been removed, things have been growing rapidly, fuelled by (for example) the announcement of Japanese government, as part of the "e-Japan" project, setting a deadline of 2005 to have Internet infrastructure and technology running on IPv6, a mandate which is expected to further stimulate network upgrades and application development, already making steady progress in Japan. There is even tax relief available for IPv6 deployment in Japan! We can only hope this progressive attitude will be repeated elsewhere.
Even more recently, the US Department of Defence announced that it would only buy IPv6 capable technology from October 2003, aiming for full IPv6 implementation by 2008. Their reasoning is simple: to be ready for IPv6 in 2008 they need to make sure that equipment and projects that start now and operate for several years will be IPv6 capable when they come to fruition. The huge spending power available to the US DoD can only further help IPv6.
You know that a technology is becoming viable when someone tries to make money out of it. Accordingly, we'd like to highlight some of the companies out there who are attempting to sell this bundle of joy. This is of course a non-exhaustive list, and you might be surprised to find your favorite ISP is already in a position to offer you paid service!
- NTT/Verio
NTT launched their commercial IPv6 service in Japan in April 2001, in Europe in February 2003 and in the U.S. around the end of 2003. They offer services to ISPs and also provide web hosting.
- XS4all.nl
The well-known Dutch ISP XS4all has been offering its DSL customers IPv6 tunnels for some time.
- IXPs
IXPs (Internet Exchange Points) worldwide are offering IPv6 services including AMS-IX, LINX, and LAIIX. There are also some IPv6 specific exchange points, such as UK6x.
- Hexago
Hexago is a French-Canadian company specializing in IPv6 migration.
- Abilene
Abilene, the research-only network in the United States, exchanges native IPv6 traffic with research networks worldwide, including KREOnet2 in Korea, SURFnet in The Netherlands and HEAnet in Ireland.
- GÃANT
The pan-European research network has essentially completed the rolling out of native IPv6 support.
- Microsoft
Microsoft's three degrees is a piece of groupware allowing friends and family to share files, music, photos and so on. As three degrees is a peer-to-peer technology, Microsoft have decided that it is best to base it on IPv6. While it is a free piece of software available from http://www.threedegrees.com/, it is easy to see the value in the software.
[1] Pun intended.
[2] The 3rd Generation Partnership Project, a group set up to work on standards for third generation mobile telecomunications.
[3] To find out who, see the archived copy of Tim Berners-Lee's list of W3 servers from November 1993, available at http://jmason.org/WWW-servers.txt.
[4] Members is in quotes since the only current pre-requisite of membership is a desire to be one.
[5] This phrase seems to have originated with Dave Clark, a founding figure of the Internet. We'll explain what an RFC is in a moment.
[6] It's interesting to note in passing that, officially, every finished RFC is simply asking for people to review itself!
[7] The section A Note on RFCs and Internet Drafts, later in this chapter, tells you how to find RFC documentsâthey are available free on the web.
[8] For example, Vint Cerf's comments in various discussions in the TCP/IP list at the end of 1988. See http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0144.html for more detail.
[9] IPv4 was itself was a replacement for a protocol called NCP.
[10] Classless interdomain routing, or CIDR for short, is explained in more detail in the Section 1.1.1 section of Chapter 1.
[11] Author of RFC 822 on email headers, amongst many other things.
[12] CLNP, or the ConnectionLess Network Protocol is the approximate equivalent of IP in the ISO networking stack.
[13] RFC 1347 describes how it was envisaged this would operate.
[14] Itojun is also part of the KAME development team.
[15] Though hopefully not infinitely prolonged...
[16] Up until recently, one of the most badly crafted bits of IPv6.
Get IPv6 Network Administration now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
