Cisco Press Deploying IPv6 Networks Feb 2006 ISBN 1587052105
Deploying IPv6 Networks
By Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete ............................................... Publisher: Cisco Press Pub Date: February 10, 2006 Print ISBN-10: 1-58-705210-5 Print ISBN-13: 978-1-58705-210-1 Pages: 672
An essential guide to IPv6 concepts, service implementation, and interoperability in existing IPv4 environments.
Learn about IPv6 services and the relevant IPv6 features that make them possible
Plan, deploy, and manage IPv6 services at the production level in existent IPv4
networks Configure and troubleshoot IPv6 networksIPv6 scales up to support new services that require a very large addressing space; it is positioned to provide the infrastructure for a world where mobile devices, home
appliances, and phones will each have their own, unique IP address. In the United States,
major Enterprise customers interfacing with the Department of Defense, contractors such
as Boeing and Lockheed Martin, have expressed stronger interest in the technology due to
their customer requests. Microsoft considers IPv6 a strategic technology because it will free the networks of NATs opening the door to peer-to-peer applications. Deploying IPv6 Networks will present the service capabilities of IPv6, the features supporting these services, and the ways in which they can be implemented in a scalable, production-levelnetwork. The information will be presented in the context of the existing IPv4 operational
and design concepts, anchoring the discussion to familiar ground and the environmentsthat will be incorporating the IPv6 services. After completing Deploying IPv6 Networks the
reader will Understand the state of IPv6 technologies and services and the IPv6 features
as they are applied in service deployments. In addition they will know how to design and
implement an IPv6 production-level network, using the book's templates and examples. Have the ability to configure and troubleshoot IPv6 in production networks and know where IPv6 developments are moving in the future.Deploying IPv6 Networks
By Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete ............................................... Publisher: Cisco Press Pub Date: February 10, 2006 Print ISBN-10: 1-58-705210-5 Print ISBN-13: 978-1-58705-210-1 Pages: 672
Copyright Deploying IPv6 Networks
Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete Copyright © 2006 Cisco Systems, Inc.
Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.
Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing February 2006 Library of Congress Cataloging-in-Publication Number: 2004108530
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.
Warning and Disclaimer
This book is designed to provide information about the deployment of IPv6. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.
The information is provided on an "as is" basis. The author, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.
Corporate and Government Sales
Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and
Government Sales 1-800-382-3419
For sales outside the U.S. please contact: International Sales
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers' feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at
. Please make sure to include the book title and ISBN in your message.
We greatly appreciate your assistance.
Publisher John Wait Editor-in-Chief John Kane Cisco Representative Anthony Wolfenden Cisco Press Program Manager Jeff Brady Production Manager Patrick Kanouse Development Editor Deadline Driven Publishing Project/Copy Editor Interactive Composition Corporation Technical Editors Blair Buchanan, Gunter Van de Velde, Dan
Williston Team Coordinator Raina Han Book/Cover Designer Louisa Adair
Compositor Interactive Composition Corporation
Indexer Interactive Composition Corporation
Corporate Headquarters Cisco Systems, Inc.170 West Tasman Drive San Jose, CA 95134-1706 USA
Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
European Headquarters
Cisco Systems International BV Haarlerbergpark Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands
Tel: 31 0 20 357 1000 Fax: 31 0 20 357 1100
Americas Headquarters Cisco Systems, Inc.
170 West Tasman Drive San Jose, CA 95134-1706
Tel: 408 526-7660 Fax: 408 527-0883
Asia Pacific Headquarters Cisco Systems, Inc.
Capital Tower 168 Robinson Road #22-01 to #29-01 Singapore 068912
Tel: +65 6317 7777 Fax: +65 6317 7799 Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at
Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe Copyright © 2003 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems,
Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R) Printed in the USA
Dedications Ciprian dedicates this book to Nicole and Simon
Eric dedicates this book to Marine, Julie, and Quentin. Patrick dedicates this book to the next generation of Internet users. . .Elisa and Mikael.
About the Authors
Ciprian Popoviciu, CCIE No. 4499, is a technical leader at
Cisco Systems with more than eight years of experience designing, testing, and troubleshooting large IP networks. As part of the Cisco Network Solution Integration Test Engineering (NSITE) organization, he currently focuses on the architecture, design, and test of large IPv6 network deployments in direct collaboration with service providers worldwide. He contributed to various publications and the IETF. Ciprian holds a bachelor of science degree from Babes-Bolyai University, a master of science degree and a doctorate degree in physics from the University of Miami.
Eric Levy-Abegnoli is a technical leader in the IP Technologies
Engineering group at Cisco Systems, where he is the technical lead for IPv6 development in IOS. Eric has worked with the Cisco IPv6 implementation since 2001, and has been involved in some of the biggest IPv6 deployments. Before joining Cisco, Eric worked for IBM, where he successively led a development team in the Networking Hardware Division and a research team at the Thomas J. Watson Research Center, focusing on networking and content-delivery platforms. Eric received the
Diplome d'Ingenieur from the Ecole Centrale de Lyon, France.
Patrick Grossetete, manager of product management at Cisco
Systems, is responsible for a suite of Cisco IOS software technologies including IPv6 and IP Mobility. He is a member of the IPv6 Forum Technical Directorate and manages Cisco's participation in the forum. In June 2003, he received the "IPv6 Forum Internet Pioneer Award" at the San Diego summit. Patrick joined Cisco in 1994 as a consulting engineer. Before joining Cisco, Patrick worked for Digital Equipment Corporation as a consulting engineer and was involved with network design and deployment. He received a degree in computer technology from the Control Data Institute, Paris, France.
About the Contributor
Pascal Thubert has been with the Technology Center since
joining Cisco Systems in 2000. He leads a group that has been working on IPv6 networking mobility for the past five years. Pascal is the author of a number of Internet drafts and IETF working group documents, in particular RFC 3963 (NEMO). He wrote the initial implementation of IPv6 network mobility and experimented with a number of additional features for route optimization and MANET. Some of these experiments were conducted with automakers, and his team, together with the Renault Prospect & Research division, won the Jun MURAI award in 2003 for their IPv6 e-Vehicle project. Before Cisco, Pascal was a lead network architect at IBM.
About the Technical Reviewers
Blair Buchanan, CCIE No. 1427, is a senior technical architect
and convergence strategist with Sherwood Cameron Associates Limited, in Ottawa, Canada. He has 30 years experience in the communications business. He began his career as a software developer for real-time data communications in process-control applications. Blair has participated in ISO standards development and has taken lead roles in internetwork design for large enterprise and service provider businesses in Canada and the United States. He is currently involved in planning and designing internetworks for converged services over metro Ethernet and IP VPN infrastructures. Blair holds a bachelor degree in computer science and mathematics from the University of Western Ontario (1975). His involvement with Cisco began in 1992 as a Cisco instructor and in 1995 as a CCIE.
Gunter Van de Velde is a senior network consulting engineer
on the Cisco System's Advanced Services team, and has been working in the field of core network design, and the implementation of IPv6, since early 2001. Gunter received his master's degree in electronics in 1993. After graduating, his first professional activities were based on TDMs, modems, and L2 bridges. He joined Cisco Systems in 1997, initially providing reactive worldwide support as part of the Technical Assistance Center, specializing in IP routing protocol technologies. In 1999, he joined the Advanced Services organization as a network consulting engineer, where he has been active in designing large backbone ISP networks and services.
Since 2001, Gunter has been working as a design architect for the European Commissionsponsored 6NET IPv6 project, and this year has become involved with the IETF, for which he is authoring a number of drafts in the v6ops working group. speaker at IPv6 conferences and events.
Dan Williston is a technical leader at Cisco Systems in Ottawa.
He was a key member of the software development team responsible for IPv6 on the Cisco 12000 series router. Prior to joining Cisco, he worked at Nortel Networks as a senior software designer and team leader on inter-LAN switching on the Passport 6400. In the early 1990s, he worked at Norlite Technology, which developed PC-based computer integrated telephony applications and hardware. Dan has 17 years experience in telecommunications and data networking and holds a bachelor's degree in electrical engineering from McGill University.
Acknowledgments
This book benefited from the efforts of all Cisco engineers who share our enthusiasm for the next generation of IP and work tirelessly to implement, test, and deploy it. Among them, there are a few to whom we are particularly grateful: Ole Troan, for his encouragement and support of this work, along with his contribution to and
; Pascal Thubert, for his key
contribution to
their guidance and contribution to
. We also want to
acknowledge the support of Gunter Van De Velde, Jean-Marc Barozet, Faycal Hadj, Gilles Clugnac, Floris Granvarlet, Tim Gleeson, Stan Yates, Luc Revardel, Vincent Ribiere, Richard Gayraud, Francois Le Faucheur, Alun Evans, Tom Kiely, Kevin Miles, Tin Phan, and Min Li.
We want to thank our technical reviewersDan Williston, Gunter Van de Velde, and Blair Buchananfor their thorough review and their valuable suggestions.
Special thanks go to our extraordinary editorial team, particularly Grant Munroe, Raina Han, and John Kane. This project could not have been completed without the support of our families and friends.
Icons Used in This Book
Command Syntax Conventions
The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conventions as follows:
Boldface indicates commands and keywords that are entered literally as shown.
Italics indicate arguments for which you supply actual values.
Vertical bars (|) separate alternative, mutually exclusive elements.
Square brackets [ ] indicate optional elements. Braces { } indicate a required choice. Braces within brackets [{ }] indicate a required choice within an optional element.
Introduction
There is no doubt that information technologies have become a significant part of our lives, shaping in great measure the way people work, learn, and play. Their rise to prominence was accelerated over the past decade by computer communications. Networked computing devices have proven to be much more than their sum. This concept led to tremendous productivity increases and a plethora of new services that expanded its scope from research communities, to offices, to large corporations, and to the World Wide Web. Unprecedented engineering innovation rapidly improved networking technologies in lockstep with the fast adoption of computer communications (which naturally require larger, faster, and feature-rich infrastructures). On the other hand, the trend of converging all communications, data, voice, and video to a single networking protocol revealed a resource constraint to the further adoption of computer-communication-based services. IPv4's address space cannot meet the needs of an ever-increasing demand for globally reachable IP devices. New services make address preservation a futile pursuit, with mechanisms such as Network Address Translation becoming anachronisms that block further innovation.
With the looming exhaustion of the global IPv4 address space and with the private address space proving inadequate for today's networks, service providers, enterprises, IP appliances manufacturers, application developers, and governments are now looking at the evolution of IP: IPv6. The foreseen address exhaustion has been the trigger and the driver for moving into a new addressing dimension. IPv6, however, is more than just an extension of the address space. Significant reengineering efforts were applied to solving protocol, deployment, and operation issues. You should expect IPv6 to be a better protocol than IPv4. IPv6 is IPv4's future, happening now! The IPv6 protocol and its deployment represent the scope of this book.
Goals and Methods
The most important goal of this book is to show that IPv6 is a mature technology and it is ready for deployment. It goes beyond discussing the basics of the protocol while remaining accessible to those unfamiliar with IPv6. With this book in hand, you will not only understand IPv6 but, most important, will know how to plan, design, and deploy IPv6 services.
Countless books document and explain the vast set of protocols and features known under the name of IPv4. Although its evolutionary nature allows IPv6 to back reference many of its protocols and features, detailing all the changes and improvements made would require more than this book. On the other hand, IPv6 has yet to enter the mainstream and is outpacing many of the reference books on the market. This creates the risk of making any pure deployment case study discussion difficult to follow. These considerations shaped the methodology employed in this book.
The most important changes in the foundation of IP, such as addressing architecture, packet format, and layer 2-to-layer 3 address resolution, are reviewed in detail. All the other protocols and features are discussed in the context of a service such as unicast, multicast, virtual private networks, quality of service, and security. The goal is to provide the reader with the understanding and tools needed to deploy the respective services. This approach gives a practical dimension to the information presented. This knowledge is reinforced in the second part of the book, where the reader can see it applied to concrete, complete deployment case studies. Deployment planning, deployment costs, performance, and IPv4IPv6 coexistence topics are also covered to further anchor the discussion into real-life deployment challenges. examples as well as debug outputs wherever useful. The case studies start with a description of the existent IPv4 network environment. They go through planning and design considerations and present in the end configuration of key network elements. You can leverage this knowledge immediately in a real, Cisco IOS-based network infrastructure.
In summary, this book's goals are to: Provide relevant, advanced IPv6 information from a deployment perspective.
Help you plan IPv6 deployments by offering guidelines and references to relevant resources.
Provide you the opportunity to practice the acquired knowledge on complete case studies.
Offer deployment examples that can be used as a reference in designing IPv6 services.
Who Should Read This Book?
This book will be of interest to a rather large audience, potentially all people involved with IP communications in one way or another. Researchers, application developers, and IP appliance manufacturers can learn the protocol and possible ways to harness the IPv6 infrastructures of the future. However, this book primarily targets those who design, plan, deploy, and operate IP networks and services. Networking professionals will find this book taking them from minimal or no IPv6 familiarity to being able to plan, deploy, and operate IPv6 networks.
How This Book Is Organized
Although each chapter of this book can be used independently to learn a certain aspect of IPv6, the book's structure has a clear didactic dimension. It intends to build the knowledge layer by layer, or IP service by IP service, and in closing to offer a set of exercises in the form of case studies.
provides the technology tools needed to approach the
design and deployment of an IPv6 network. The knowledge is grouped around IP services, each mapped to a chapter. It starts with enabling unicast connectivity, the foundation of any network, and follows with QoS, multicast, VPNs, IP mobility, security, and network management. The second part of the book, ushered in by a discussion of deployment planning, covers three complete case studies that map to three distinct environments: MPLS-based service provider, IP-based service provider, and enterprise.
cover the following topics:
Part I "The Case for IPv6An Updated Perspective" This chapter builds the case for IPv6 from a
technical perspective. It summarizes the differences between IPv4 and IPv6, and in the process of drawing a parallel between the two versions of IP, this chapter reviews the major concepts and challenges that people manage in their current network. Thus, it provides a framework for the IPv6 discussion in the rest of the book. significant changes from IPv4. It covers the new addressing architecture, the new header format and structure, the enhanced functions of ICMP, and the layer 2 address- resolution mechanisms. These are concepts fundamental to understanding any IPv6-related topic. For this reason, they are presented in detail here.
"Delivering IPv6 Unicast Services" This
chapter discusses the elements necessary for establishing unicast IPv6 connectivity, the foundation of all other IPv6 services. It covers the relevant protocols at the access, edge, and core of the network. The mechanisms enabling the transition from IPv4 to IPv6 are discussed along with recommendations on what IPv6 deployment approach to follow in relation to the existent IPv4 infrastructure that will have to host the deployment.
"IPv6 Routing Protocols" This chapter covers
the routing protocols available in IPv6. It parallels their implementation and operation to their IPv4 counterparts.
"Implementing QoS" This chapter reviews,
from the perspective of IPv6, the concepts relevant to implementing quality of service in IP- and MPLS-based networks. It also discusses deployment considerations relevant to the coexistence of IPv4 and IPv6.
"Providing IPv6 Multicast Services" This
chapter reviews the IP multicast concepts and protocols. It draws a parallel between IPv4 and IPv6 features, it explains the new mechanisms available in IPv6, and it provides examples that capture the various deployment options. Multicast deployment in conjunction with the various transition mechanisms is also discussed.
"VPN IPv6 Architecture and Services" This chapter covers the topic of deploying VPN services in an
IPv6 network. It reviews the VPN-related concepts and the deployment models. In closing, the chapter shows several topology examples with relevant configuration examples.
"Advanced ServicesIPv6 Mobility" This
chapter covers the concepts of IP mobility and their implementation in IPv6. It discusses the improvements made, the remaining open issues, and various examples of applying the protocol to novel services.
"Securing IPv6 Networks" This chapter
starts with an analysis of the security threats faced by IPv6, the ones specific to the new protocol, and the ones shared with IPv4. The dual perspective is critical because the coexistence of the two protocols can provide new attack vectors on the IPv6-enabled network. The chapter also presents the tools and best practices available to secure
IPv6 networks.
"Managing IPv6 Networks" This chapter
discusses the challenges faced in managing IPv6 networks; some challenges are rooted in the protocol specifics, whereas others stem from the availability of tools. It covers the applications and management systems that can be leveraged today to operate IPv6 infrastructures and services.
relevant answers to the natural concern about the impact that IPv6 services will have on existing, revenue-generating
IPv4 services and infrastructures. It provides guidelines on how to evaluate the IPv6 performance of network elements, and reviews the areas where the coexistence of the two protocols could lead to resource contention.
Part II "Generic Deployment Planning Guidelines" This chapter is intended to assist the reader in
planning the deployment of IPv6 services. It provides guidelines on estimating the cost of deployment. It also provides references to resources relevant to planning the deployment, such as getting IPv6 address space. The chapter also discusses the important aspect of education and training.
"Deploying IPv6 in an MPLS Service Provider Network" This chapter covers the planning,
designing, and deployment of IPv6 in an MPLS service provider network. Internet access and VPN services are rolled out in stages, and configuration examples are provided for each one of them. The chapter closes with examples on troubleshooting the IPv6 network and the services supported.
"Deploying IPv6 in an IP Service Provider
Network" This chapter covers the planning, designing, anddeployment of IPv6 in an IP service provider network. The ensuing infrastructure is dual stack, end to end. The various services are built in stages, and configuration examples are provided for each one of them. The chapter closes with examples on troubleshooting the IPv6 network and the services supported.
"Deploying IPv6 in an Enterprise Network" This chapter starts by presenting the steps taken
by an enterprise to evaluate IPv6 at both network and host level. It shows the development of a few services addressing specific business needs. The planning, designing, and deployment of the IPv6 services are presented. The chapter closes with a section on network troubleshooting and its future evolution.
Part I: Implementing IPv6 Services Network Performance Considerations: Coexistence of IPv4 and IPv6
Chapter 1. The Case for IPv6An Updated Perspective It is not only accepted but almost expected that an IPv6 book
will try, often hard, to persuade the reader of IPv6's importance and benefits. Countless pages have been written describing business models that would financially justify the deployment of
IPv6. Sometimes innovative, other times controversial, the job of selling IPv6 has its role in challenging today's tactical approach to planning network-related capital expenditures. But despite all these efforts, it might just be that the accelerated depletion of the IPv4 address space will remain the trigger for a massive upgrade of existing networks to IPv6.
The authors decided to steer clear of selling IPv6, and to avoid providing business models for IPv6 services. Instead, we intend to present to the reader the IPv6's value through technical arguments. We intend to provide a realistic perspective of IPv6, revealing its positives and negatives. This exercise, however, cannot be performed in absolute terms. For this reason, "the case for IPv6" is presented relative to the familiar frame of reference called IPv4. This approach is not original. It is in fact the title of an Internet Architecture Board (IAB) document ( ). Some things have changed since that document was completed, so "an updated perspective" is seen as useful. A deployment perspective is maintained while discussing the various IPv6 topics throughout the book. The technology is presented in the context of each network service layer:
Unicast connectivity Quality of service
Multicast service Virtual private networks (VPNs) Security Mobility
This chapter follows the same structure. Each service is briefly reviewed in the context of the IPv4 world. The protocol limitations and deployment issues are singled out along with pointers to IPv6 solutions or improvements, with further pointers to the chapters of this book where these topics are detailed. This chapter prepares the reader for an IPv6 discussion with the help of this overview of today's IPv4 services.
Unicast Connectivity
The delivery of IP services relies on an infrastructure that provides unicast connectivity between IP hosts. The foundation of such an infrastructure consists of three elements: addressing, routing, and forwarding.
IP addresses represent a finite resource used in identifying hosts within private or global networks. The structure and allocation mechanisms of IP addresses are relevant in designing, deploying, and operating IP networks. A review of this topic is compelling; especially under the circumstances of a depleting IPv4 address space. After all, at the time of this writing, addressing is one of the main reasons for deploying IPv6.
Routing and forwarding provide the mechanisms to move traffic between IP hosts. Whereas forwarding's dependency on IP version is relatively straightforward, routing has multiple dependencies on addressing. For this reason, it is important to see whether any of the IPv4 routing challenges were resolved in IPv6.
Addressing
IP addressing is a vast topic that influences most of the protocol layers and most of the services. It also represents a critical resource. This section briefly discusses address architecture and address allocation. For a complete and detailed presentation, the following books are helpful references:
IP Routing Fundamentals by Mark A. Sportack
Internet Routing Architectures by Sam Halabi and Danny
McPherson
Routing in the Internet by Christian Huitema
IPv4 Address Architecture
A little bit of history is necessary to understand the debate around the IPv4 address space depletion. An address is used to uniquely identify hosts within the network. Even in a flat nonhierarchical simple world, some minimum requirements on the address structure enable network elements to operate efficiently. In IPv4, the address has a fixed size of 32 bits. That would allow in theory up to 232 addresses or somewhere around four billion. It is important to note that at the time of its specification, these four billion possible addresses appeared to be more than adequate for years if not centuries to come. As soon as early 1990s, however, the Internet community had to introduce a number of changes in the address architecture and the address-allocation scheme to accommodate growing address needs. IPv6, which is based on 128-bit-long addresses, appears to be safe for centuries to come, but who says that history cannot repeat itself? A considerable waste of IPv4 addresses was generated by two factors:
The unwise allocation of classful addresses; often entities with just a little over 255 hosts asked for a Class B, capable of accommodating 65,000 hosts. Users were not challenged to justify their address requests. When people started to foresee address exhaustion, only 3 percent of the allocated addresses were actually in use! The increasing number of hosts challenged the address space resources and led to the formalization of private addressing and Network Address Translation (NAT) as an address-conservation solution. The increase in the number of hosts is also matched by an increase in the number of networks and this leads to scalability problems for the routers. In 1994, the core routers had approximately 34,000 routes, doubling every year. By 2004, it was expected to reach millions routes. Variable-length subnet mask (VLSM), Classless Inter-Domain Routing (CIDR), and a new IP address-allocation strategy was the response to the routing table explosion.
Although the core routing table size was predicted to grow from 34,000 to 80,000 between 1994 and 1995, in fact it reached 76,000 routes only in 2000 and about 160,000 in mid 2004.
With IPv6 and its larger address space, one could fear that routing tables will further expand. Bigger addressing space might logically lead to more hosts followed by more networks. In reality, past experience has shown that the "number of hosts" and the "number of networks" are loosely related. With the proper aggregation mechanisms, partly driven by the right address-allocation strategy, the latter have been well under control. Assuming the same mechanisms are maintained and further enforced with IPv6, it is reasonable to believe that routing table size will remain within manageable limits.
Note
For more details on CIDR, and related topics, you can read the following RFCs: RFC 1517, RFC 1518, RFC 1519, and RFC 1520. Also, RFC 1887 provides some hints on the reasoning behind IPv6 address allocation, and architectural implications. The address-conservation mechanisms cannot stave off for long the need for global IP addresses. Past and current Internet growth rates (source BGP table statistics ) can be extrapolated to predict the time left before the complete exhaustion of all available
IPv4 address space. Conservative studies estimate the IPv4 address-space exhaustion by February 2041, and the exhaustion of the IPv4 unallocated address pool by April 2020. More aggressive models predict even earlier dates such as 2009. These predictions are based on the underlying assumption that the current growth models will remain applicable for years to come, which is not necessarily accurate.
IPv6 might change these assumptions. With the combination of the Internet as an attractive and accessible communications medium, and the emergence of communicating gadgets and devices of all kind (even the most unexpected ones such as phones, home appliances, cars, and so on) you must be ready to see them proliferate and stimulate a growth in Internet usage that cannot be extrapolated from past patterns.
Private Versus Public Addresses
Public addresses are registered, globally unique, and can be used to provide reachability over the Internet. By contrast, private addresses are meaningful only within a closed, physical or virtual domain. In IPv4, private addresses have been always associated with unregistered addresses, which in return have been associated with nonunique addresses.
There might be many reasons why an organization would want to use both public and private addresses. Public addresses are used to get connectivity across the Internet, to reach public resources. Private addresses are used to accomplish the following:
Increase the addressable space used internally Avoid address registration pains Decorrelate from public addressing changes (for instance, at peering points) to save the renumbering hassle Protect the internal network from the public domain by preventing private addressing/topology exposure
RFC 1918 identifies two categories of hosts that could deal with private addresses: Hosts that do not require access to hosts in other enterprises or the Internet Hosts that need access to a limited set of outside services (e-mail, FTP, and so on) that can be handled by intermediate gateways
For these two categories, RFC 1918 further defines three blocks of private addresses that should not be routed over the Internet, and therefore free to replicate.
10.0.0.0/8 A Class A block 172.16.0.0/12 A Class B block 192.168.0.0/16 A Class C block
In an ideal world, privately addressed hosts would be confined to the private network, whereas only hosts with public addresses would be able to access the public domain. In reality, some point. Usually, there are not enough public addresses for all hosts in the private network, so further mechanisms are necessary to interface them with the public domain. The
One of the benefits of the private address space is the large number of addresses available at the discretion of an enterprise. It was, however, only logical to expect that the private address space will face depletion similar to the overall
IPv4 address space. In 2005, multiple-systems operators (MSOs; or cable operators) reported the fact that they are running out of private address space. This is due to the proliferation of cable modems, Voice over IP (VoIP) phones, and set-top boxes they have to manage over IP. This realization accelerated their plans to deploy IPv6 if not to provide services at least to manage their devices.
Some of the reasons to use private addresses become obsolete with IPv6 (there are now plenty of public addresses for everyone) although others will remain. VPN solutions exist for
IPv6, too, and that could be sufficient to safeguard the privacy of addressing used within a network. The plethora of IPv6 addresses had suggested some different paradigms for private addressing, in particular the concept of unique yet private address. These concepts are presented in
the boundary between private and public domains are presented in
Chapter 7 , "VPN IPv6 Architecture and Services." Static Versus Dynamic Addresses Addresses can be assigned to IP nodes either statically or
dynamically. The static addresses are allocated "indefinitely" or until explicitly removed. Dynamic Host Configuration Protocol (DHCP) allows a computer to have a different IP address each time it connects to a network. This process enables multiple users to overload the use of a pool of dynamically assigned addresses. DHCP also enables mobile hosts to attach to visited subnets without requiring manual reconfiguration. In reality, dynamically allocated addresses might not change often either. In large networks, DHCP servers tend to allocate the same address to the same host over time, unless there is some shortage. For the home environment, there are two categories of users:
Users with dialup connections will change their address often. Most Internet service providers (ISPs) make use of DHCP to assign an IP address to each user for the length of time they are connected, and reuse it for another customer after the dialup connection from the previous customer has been terminated.
Users with long-life connections such as Digital Subscriber Line (DSL), Integrated Services Digital Network (ISDN), or cable will tend to keep their address for a longer period of time.
There are now advantages and disadvantages with the trend to use more stable source addresses than there were in the past. From a network operation perspective, one could find useful that the same user stays behind the same IP address; it is easier to manage, bill, filter, authenticate, and so on. However, this operational model eliminates address reuse, which conserves the IPv4 address space. For this reason, broadband services are a significant catalyst in the acceleration of IPv4 address consumption. When the address-shortage concerns are eliminated with the adoption of IPv6, there could be a tendency to allocate static addresses, or allocate dynamically the same address to the same user all the time. The advantages of having the IP address uniquely and permanently identify the device are counterbalanced by possible privacy issues. The same address used in multiple contexts (for instance, web surfing, gaming, and so on) can be used to correlate seemingly unrelated activities. Note that with IPv6, which offers the possibility of using addresses that embed topological information such as link identifier, the concern will grow. The mechanisms to allocate IPv6 addresses dynamically are reviewed in
Chapter 3 , "Delivering IPv6 Unicast Services." Renumbering Want to know a network administrator's worst nightmare? It is
renumbering. Renumbering is the process of replacing existing network prefixes and host addresses considered as deprecated throughout the network with new ones. There can be a large variety of reasons for renumbering:
The topology outside the network has changed (for instance, because the ISP providing Internet access has changed). The network is expanding, hence the internal topology is changing; more subnets need to interconnect; a reorganization of the existing ones; more hosts to address; and so on. Renumbering, although not always required in these cases, could potentially improve aggregation and is sometimes highly recommended.
The network is merging with another one (for instance, in the case of two companies merging).
The network was private and disconnected from the public network, and now wants to provide public access to its hosts and servers. The complexity of the renumbering process comes from the fact that addresses are used in many different places within a network and for many different reasons. A single address or a set of addresses may have been configured statically or dynamically in various places such as the following:
BOOTP or DHCP servers Applications servers of all kinds (HTTP, FTP, mail, and so on) Routers (interfaces, routing, and access lists configuration, and so on) Firewalls (access list) DNS servers
Sometimes, simply changing the old address can make the new one operational; in many cases, however, the old address has been leaked in caches of all kinds (DNS caches, applications caches, routing caches, web caches, Address Resolution Protocol [ARP] caches). Many of these caches have expiration timers, which will make them invalidate the "old" addresses, but some do not. In most cases, changing the address and network prefix requires rebooting the host. When addresses are cached throughout the network, delays (mostly "uncontrolled") will occur before the new addresses are operational.
Although some believe that renumbering issues have been entirely taken care of in IPv6, others believe that renumbering remains a problem without any good solution. The truth lies somewhere in between. The renumbering issue is multidimensional, and IPv6 brings some innovative solutions in some areas, although it does not solve the entire problem. mechanisms such as link-local addresses, autoconfiguration, and support for multiple addresses on the same interface that can ease aspects of network renumbering.
Network Address Translation
Network Address Translation (NAT) has brought the best and the worst to IP deployments. Per NAT RFC authors, NAT was a short-term solution to enable address reuse and solve the address-depletion issue the IP Internet community was anticipating in 1993. That worked out well indeed, and what seemed to be a critical issue in 1993 is less critical more than 10 years later. NAT has enabled private addressing in all sorts of corporate networks, eliminating the need for publicly registered chunks of addresses. Nevertheless, NAT is a controversial subject in the networking community, and for that reason we dedicate this section to it. For technical background and more details on NAT principles and operations, refer to RFC 1631 and books such as the Cisco Press book Routing TCP/IP, Volume II (CCIE Professional Development) by Jeff Doyle. Over the years, NAT has been deployed widely throughout the Internet. During this time, its use was given justifications beyond address conservation: from security to privacy, from preventing renumbering to providing high-availability mechanisms, from deployment of virtual clusters to providing Internet access over VPNs. Each of these justifications was prompted by some deployment scenario and was meant to solve deployment issues.
Although some of these reasons will become irrelevant after
IPv6 is deployed, not all of them will. Although NAT has hurt the deployment of many applications, and many people would be happy to see this so-called "short-term" solution go away with