IPv6 Network Administration (Niall Richard Murphy, David Malone) (Z-Library)

IPv6 Network Administration

Other resources from O’Reilly Related titles 802.11 Wireless Networks: The Definitive Guide BGP Cisco Cookbook Cisco IOS in a Nutshell DNS and BIND, Fourth Edition Ethernet: The Definitive Guide Internet Core Protocols: The Definitive Guide IP Routing IPv6 Essentials SSH, The Secure Shell: The Definitive Guide TCP/IP Network Administration oreilly.com oreilly.com is more than a complete catalog of O’Reilly books. You’ll also find links to news, events, articles, weblogs, sample chapters, and code examples. oreillynet.com is the essential portal for developers interested in open and emerging technologies, including new platforms, pro- gramming languages, and operating systems. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit con- ferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today with a free trial.

IPv6 Network Administration Niall Richard Murphy and David Malone Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo

IPv6 Network Administration by Niall Richard Murphy and David Malone Copyright © 2005 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/insti- tutional sales department: (800) 998-9938 or corporate@oreilly.com. Editor: Mike Loukides Production Editor: Colleen Gorman Cover Designer: Ellie Volckhausen Interior Designer: David Futato Printing History: March 2005: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. IPv6 Network Administration, the image of a softshell turtle, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. This book uses RepKover™, a durable and flexible lay-flat binding. ISBN: 0-596-00934-8 [M]

This book is dedicated to the late John Lewis, mathematician and academic, who enriched the lives of the many people he touched with his ability, humility, and good humor. Rest in peace.

vii Table of Contents Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Part I. The Character of IPv6 1. The Unforeseen Limitations of IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Addressing Model 3 NAT 5 Security 7 MAC Layer Address Resolution 9 Broadcast Versus Multicast 10 Quality of Service 10 Routing 11 Summary 13 2. The (Un)foreseen Successes of IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Simplicity 14 Resiliency 15 Scalability 15 Flexibility 16 Autoconfiguration 16 Extensibility 17 In Short… 17

viii | Table of Contents 3. Describing IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Designed for Today and Tomorrow 18 Packets and Structures 20 Address Architecture 28 ICMPv6 34 Address Selection 45 More About Headers 47 Introduction to Mobile IPv6 50 Routing 53 Security 57 Quality of Service 58 The Promise of IPv6 59 Part II. Deploying IPv6 4. Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Transition Mechanisms 64 Obtaining IPv6 Address Space and Connectivity 78 Network Design 84 Managing IPv4 and IPv6 Coexistence 90 Deploying IPv6 92 Inputs to Deployment Plans 93 Worked Examples 101 Summary 106 5. Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Workstations and Servers 107 Routers 116 Enabling, Testing, and Troubleshooting 119 Static Routing 131 Configuring Transition Mechanisms 133 Applications 139 Gotchas 142 Summary 143 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 DNS 144 IPsec 158

Table of Contents | ix Routing 162 Firewalls 175 Management 182 Providing Transition Mechanisms 184 Summary 196 7. Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 General Notes 197 Inetd/TCP Wrappers 198 HTTP 199 SMTP 211 POP/IMAP 213 NNTP 214 NTP 215 Syslog 216 Printing 216 FTP 217 Remote Login Services 218 If All Else Fails… 219 Summary 220 8. Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Relevant Functions 222 Some Simple Examples 226 Case Study: MMDF 236 Other Considerations for Developers 239 Summary 244 9. The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Unresolved Issues 246 Up and Coming Subject Areas 253 Summary 258 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. xi Foreword IPv6 has evolved during the last dozen years or so, and the road has not been easy. The process has been driven primarily by the shortage of address space under IPv4, but also by the desire for new applications that don’t fit within the older protocol’s limitations. The address space crisis has been delayed by several new approaches to IP addressing, the most important of them being CIDR, NAT, and RFC1918 private address space. At the same time, it was clear that these solutions only postponed the inevitable, so efforts began to redesign the IP protocol. These efforts led to IPv6. Although CIDR, NAT, and private address spaces have been successful, they didn’t solve the problem—they only put it off. Today, the Regional Internet Registries have IPv4 address allocation policies that scare away those who would like to get public address space. IPv4 address space has become a scarce resource, and getting a public address block requires too much paperwork and bureaucracy. We can stretch out the IPv4 address space for 5, 10, or 50 years, but if the result is that only a privileged few can get public address space, what’s the point? Enter IPv6. IPv6 provides a clean fix to the fundamental problem: too few bits in the IP address. The increased length of IPv6 addresses means that they can be assigned freely and used comfortably; they’re not a scarce resource that needs to be con- served. IPv6 also makes it possible to deploy new types of applications that rely on public address space, or that encode information in the IP address itself, such as mul- tihoming and verifiably secure local networking. The IPv6 specifications are now reasonably stable. Dozens of implementations have been deployed and used for years; if you want to use IPv6, you no longer need spe- cial software or patches. Most operating systems include IPv6 support, and some vendors even turn it on by default. IPv6 has arrived at a state where almost everyone can use it. The problem is now that they don’t know how. Therefore, the most important work at the moment is enabling IPv6 deployment, and creating an atmosphere where IPv6 applications can be created and flourish. That’s where we’ll really see the benefit of IPv6: in new applications that go beyond

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. xii | Foreword the client-server paradigm, and take advantage of IPv6’s end-to-end addressing and connectivity features. That’s where this book comes in: it gathers knowledge scat- tered across the Internet about deployment and applications. There are many ways to deploy IPv6, and the more complex the network you have, the more possibilities you have. This book helps you to understand those possibilities and deploy IPv6 on your network. Have the Internet users, application developers, and vendors grown too comfortable with short-term patches to counter the problem caused by NATs and address space shortage, instead of choosing the longer-term solution, IPv6? We’ll see. IPv6 is ready for deployment. For you to deploy, use, and write applications for. This book shows you how; don’t let inertia hold you back. Have fun doing that! —Pekka Savola IETF IPv6 Operations (v6ops) working group co-chair

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. xiii Preface 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 frac- tion 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* 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† 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. * Pun intended. † The 3rd Generation Partnership Project, a group set up to work on standards for third generation mobile telecomunications.

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. xiv | Preface 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 prais- ing 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 net- work 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.* Installed bases are relative things, espe- cially 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 eventu- ally 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. What This Book Is … and Is Not 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 funda- mentally 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 * To find out who, see the archived copy of Tim Berners-Lee’s list of W3 servers from November 1993, avail- able at http://jmason.org/WWW-servers.txt.

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. Preface | xv you to turn IPv6 into something real, something that can be useful to you, and some- thing you feel comfortable with. In detail, we begin in Chapter 1 and Chapter 2 by describing IPv4 in terms of its suc- cesses 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 ele- ments 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 refer- ences 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 ven- dor 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 net- work. The main subjects in this chapter are DNS, IPsec, firewalling and routing; net- work 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. History and Background 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),

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. xvi | Preface or, alternatively, IPng Internet Protocol Next Generation, edited by Bradner and Man- kin (Addison-Wesley). To properly understand how IPv6 came into being requires more than a passing famil- iarity 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 and friends The IETF (Internet Engineering Task Force) are the ultimate networking geeks. Responsible for the standards on which the Internet is based, the “members”* of the IETF engage in protocol design, protracted discussions and incessant, mostly cyni- cal, 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.† 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, gener- ally 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 dis- cussions on mailing lists which are categorized by Working Group. A Working Group is a collection of people and technical resources aimed at consid- ering (usually) a quite specific topic. Working Groups are themselves sorted by sub- ject 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 com- monly, 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 suc- cessful decentralized organizations permitting public participation in the world.) Work generally happens on documents known as Internet Drafts. These are basi- cally documents that present information in a standard way. Internet Drafts are passed between the members of a group for comment, feedback, and analysis. Some * Members is in quotes since the only current pre-requisite of membership is a desire to be one. † 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.

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. Preface | xvii 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).* 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 defin- itive statements on how certain kinds of network communication must happen; sometimes, they describe operational constraints or other peripherally related top- ics. 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 (some- thing people are trying out), BCP (a codification of Best Current Practice), and His- toric (obsolete or superseded). RFC 2026 contains more details about the standardization process.† 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 hap- pens, the body giving the most momentum to the IPv6 effort is the IETF. Chronological overview 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 * It’s interesting to note in passing that, officially, every finished RFC is simply asking for people to review itself! † 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.

This is the Title of the Book, eMatter Edition Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved. xviii | Preface academic sites had been joined by commercial efforts, as well as an expanding num- ber of countries. The phenomenal growth that was occurring, coupled with the inef- ficiency of the then-current class-based address allocation method was already starting to arouse concern in the technical community.* The earliest records of a formalized search for a replacement for IPv4† 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 prob- lems 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‡ 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§ 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 grav- itated 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 imme- diately, without extensive exploration and development of options. The Internet Engi- neering 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 cate- gory. 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 estab- lish 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. * 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. † IPv4 was itself was a replacement for a protocol called NCP. ‡ Classless interdomain routing, or CIDR for short, is explained in more detail in the “CIDR” section of Chapter 1. § Author of RFC 822 on email headers, amongst many other things.