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
Table of Contents | Index
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 networks
IPv6 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
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
Table of Contents | Index
Copyright
About the Authors
About the Contributor
About the Technical Reviewers
Acknowledgments
Icons Used in This Book
Command Syntax Conventions
IPv6 Packet Format
Internet Control Message Protocol for IPv6
Neighbor Discovery Protocol
IPv6 Multicast Deployment Examples
Chapter 7. VPN IPv6 Architecture and Services
Security Threats and Best Practices to Protect Against Them
Summary of Best Practices for Securing IPv6 Deployments
Chapter 10. Managing IPv6 Networks
IPv6 Network Management: The Challenges
Network-Management Architecture
Retrieving Information from Routers and Switches
Fault Management
Performance Management
Configuration and Provisioning Management
Management Platforms
IPv6 Network Management Services and Tools at a Glance
IPv6 Chapter 11. Network Performance Considerations: Coexistence of IPv4 and Aspects of Router IPv6 Performance
Measuring Forwarding Performance
The Right Router for the Job
IPv6 Router Performance Evaluation Checklist
Part II: Deployment Case Studies
Chapter 12. Generic Deployment Planning Guidelines
Cost Analysis
Address Policies and Registration Process
Education
Chapter 13. Deploying IPv6 in an MPLS Service Provider Network
Network Environment
Network Design Objectives
Network Design
Basic Services Design and Implementation
Quality of Service Design
Operating and Troubleshooting the Network
Design Lessons
Chapter 14. Deploying IPv6 in an IP Service Provider Network
Network Environment and IPv4 Services
IPv6 Deployment Plans
Basic Services Design and Implementation
Advanced Services Design and Implementation
Operating and Troubleshooting the Network
Deployment Lessons
Chapter 15. Deploying IPv6 in an Enterprise Network
AC Network Environment
Business Drivers to Integrate IPv6 on the AC Network
Learning the Technology Moving IPv6 to Production
Design and Setup
Troubleshooting
Future Evolutions
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
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
corpsales@pearsontechgroup.com
For sales outside the U.S. please contact: International Sales international@pearsoned.com
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
feedback@ciscopress.com. 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
Compositor Interactive Composition Corporation
Indexer Interactive Composition Corporation
Corporate Headquarters
Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
www.cisco.com
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
www-europe.cisco.com
Tel: 31 0 20 357 1000 Fax: 31 0 20 357 1100
Americas Headquarters
www.cisco.com
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
www.cisco.com/go/offices.
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
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.
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.
About the Contributor
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
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
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 Chapters 3 and 7; Pascal Thubert, for his key contribution to Chapter 8; Sean Convery and Darrin Miller, for their guidance and contribution to Chapter 9; and Benoit
Lourdelet, for his contribution to Chapter 11. 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.
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.
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
than IPv4. IPv6 is IPv4's future, happening now!
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.
Who Should Read This Book?
This book will be of interest to a rather large audience,
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.
Part I 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.
Chapters 1 through 15 cover the following topics:
Part I
Chapter 1, "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.
Chapter 3, "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.
Chapter 4, "IPv6 Routing Protocols" This chapter covers the routing protocols available in IPv6. It parallels their
implementation and operation to their IPv4 counterparts.
Chapter 5, "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.
Chapter 6, "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.
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.
Chapter 8, "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.
Chapter 9, "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.
Chapter 10, "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.
Part II
Chapter 12, "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.
Chapter 13, "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.
Chapter 14, "Deploying IPv6 in an IP Service Provider Network" This chapter covers the planning, designing, and deployment 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.
Chapter 15, "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
Part I: Implementing IPv6 Services
Chapter 1 The Case for IPv6An Updated Perspective
Chapter 2 An IPv6 Refresher
Chapter 3 Delivering IPv6 Unicast Services
Chapter 4 IPv6 Routing Protocols
Chapter 5 Implementing QoS
Chapter 6 Providing IPv6 Multicast Services
Chapter 7 VPN IPv6 Architecture and Services
Chapter 8 Advanced ServicesIPv6 Mobility
Chapter 9 Securing IPv6 Networks
Chapter 10 Managing IPv6 Networks
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 (http://www.6bone.net/misc/case-for-ipv6.html). 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
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
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:
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.
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
The address-conservation mechanisms cannot stave off for long the need for global IP addresses. Past and current Internet
growth rates (source BGP table
statisticshttp://bgp.potaroo.net/) 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.
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
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
simplest one is NAT, discussed in the section "Network Address Translation."
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 Chapter 2, "An IPv6 Refresher." The concepts and issues that arose when crossing 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
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
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 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.
want to rid the world of the evil NAT, we must make sure IPv6 offers solutions for all problems NAT resolved.
NAT comes with a number of issues, out of which the most significant is the connection model that it implies. NAT is asymmetrical. Because of the way NAT works, it is mainly
usable for client/server sessions where clients within the private network initiate the session with servers sitting in the public network. The client will typically issue a Domain Name System (DNS) query for some public server name, and get the public server address. On the way back, the server will see only the public NAT address, expectantly a globally reachable one. Going the reverse direction is more troublesome. Anybody sitting
outside the private network (either on the public network or on a different private network) would have difficulties reaching a host behind NAT.
Some proxy servers can be used as "middlemen": They can handle all necessary application signaling and enable hosts to use each others NAT addresses as the reachable public address. Session Initiation Protocol (SIP) is a good example of such a solution. However, twisting every single peer-to-peer application to make it fit the client/server model appears to be a great
limiting factor to the adoption and deployment of new applications.
Another issue with NAT is that it does not look at any
information above IP/TCP/UDP/ICMP layers. Some applications have endpoint source addresses buried within their messages, which do not get translated by NAT at the same time as the IP header addresses. This typically happens with applications such as H.323 that tend to establish multiple connections within a single session. To solve those issues, application layer gateways (ALGs) may need to perform complex application-level
translations. When an application that required an ALG is deployed, NAT devices must support this particular ALG.
based on signing or verifying part of the packet, whether header or payload including IP addresses, will have trouble when addresses are overwritten. For instance, with IPsec, both Authentication Header (AH) and Encapsulating Security Payload (ESP) have issues with NAT, although at a different order of magnitude.
Can IPv6 Eliminate NAT?
NAT is used in the networks of 70 percent of Fortune 1000 companies, for better and worse. So, either NAT is not
necessary anymore after IPv6 is deployed, and the worst is gone. Or, IPv6 does not have a proper solution for all
deployment scenarios where NAT is in use and these networks will not transition. Although the large IPv6 address space
eliminates the need for NAT, it is important to explain how IPv6 also provides similar capabilities as the "perceived" benefits of NAT. This is the main purpose of Network Architecture
Protection (NAP), an Internet Draft addressing each NAT benefit (real or perceived) and matching it with an IPv6 solution. Table 1-1 lists NAT features, and for each, it provides pointers to IPv6 documentation (RFC, Internet Drafts, and so on) and refers to chapters of this book where solutions are reviewed.
Table 1-1. IPv4 NAT vs. IPv6 NAP
NAT Feature IPv6 Reference More Details In
Address
depletion IPv6 AddressingArchitecture, RFC 3513 Chapter 2Address Architecture, section "IPv6"
Address
management Preferred lifetime per prefix& multiple addresses per interface (ID)
Chapter 2, section "IPv6 Address Architecture"
IPv6 Unique Local
IPv6 auto-configuration:
RFC 2462 Chapter 3Provisioning, section "" IPv6
Procedure for Renumbering an IPv6 Network without a flag day: RFC 4192
Chapter 3, section "IPv6 Address Renumbering"
IPv6 VPNs (ID) Chapter 7 "VPN IPv6 Architecture and Services"
Site
multihoming[1]
Goals for IPv6 Site-Multi-homing Architectures: RFC 3582
IPv6 Multihoming Support at Site Exit Routers: RFC 3178
Architectural Approaches to Multi-homing for IPv6: RFC 4177
Chapter 4, section "Site Multihoming"
Server load
balancing[2] Chapter 8Load Balancing, section "" Server
Failover[3] Chapter 15, section
"Enabling Cisco HSRP for IPv6"
End-system
privacy Privacy Extensions forStateless Address Auto-configuration in IPv6: RFC 3041
Chapter 2, section "IPv6 Addressing"
Topology
hiding IPv6 Network ArchitectureProtection (NAP) (ID) Chapter 2Addressing, section "" IPv6
MIPv6 tunnels: NAP (ID)
and RFC 3575 Chapter 8"Topology Hiding, section"
VPN Internet
access[4] IPv6 Unique LocalAddresses: RFC 4193 Chapter 2Addressing, section "" IPv6
Recommendations on IPv6 Address Allocations to Sites: RFC 3177
Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network"
Simple
gateway DHCP-PD Customer prefixupstream: NAP (ID) Chapter 3Provisioning, section "" IPv6
SLACC via RA downstream: NAP (ID)
Simple
security Context Based AccessControl (ID) Chapter 9Networks" "Securing IPv6
Local usage
tracking Address Uniqueness3513 : RFC Chapter 2Addressing, section "" IPv6
[1] A multihomed site can use NAT to translate the various provider addresses into a single set of private-use addresses.
[2] NAT can be used to load balance traffic over a set of servers by hiding their individual addresses behind a single NAT address. Other techniques can be used for the same purpose, which do not rely on NAT, and can work with IPv6.
[3] NAT is used in some high-availability scenarios by hiding active and standby hosts or routers addresses behind the same virtual address. Other techniques can be used for the same purpose, which do not rely on NAT, and can work with IPv6, such as HSRP (Hot Standby Router Protocol), VRRP (Virtual Router Redundancy Protocol), and GLBP (Gateway Load Balancing Protocol).
[4] Sites or individual hosts configured with private addresses use NAT to expose a public address (rather than their private address) when connecting to a public resource.
In addition to verifying that IPv6 deployments do not create issues in areas where NAT has a specific purpose, you will also have to examine coexistence issues. Because IPv4 and IPv6 are likely to cohabit for a significant period of time, you need to know whether there are any IPv6 deployment issues with regard to traversing IPv4 NATs. Indeed, many of the
transitioning mechanisms that Chapter 3 describes involve
NAT, and being able to properly traverse them is critical to IPv6 deployment.
Routing
The engineering community has not really touched the routing foundations of unicast services in the context of IPv6. Of
course, whenever an IPv4 routing protocol had some
dependencies on IPv4 addresses, work was done to produce an IPv6 version of it. This is the case, for instance, with OSPFv3.
Chapter 4 "IPv6 Routing Protocols," reviews these changes in the routing protocols. But besides "cosmetic differences," all IPv4 routing protocols are closely matched in IPv6, sharing the same design, often the same implementation, with the same area of applicability and the same issues. In IPv6, you will find the familiar Routing Information Protocol (RIP), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and Border Gateway Protocol (BGP).
QoS Services
Packet-switched technologies are well suited for data
communications, which, at first, did not care as much about timely delivery or resource reservation. With packet-switched technologies, the faith of packets is entrusted entirely to the best efforts and good will of the network. Although not
reassuring, the approach is more flexible and allowed these technologies to develop faster than the circuit-switched ones. Besides being capable of multiplexing the user traffic, they offer features that could easily enable new, revenue-generating
services on existing networks. The success of packet switching led to an ever-expanding set of applications leveraging IP. It was not long before time-sensitive applications were IP enabled, and they required special handling of their packets, especially under congestion conditions.
Because not all applications have the same requirements, the IP infrastructure must be enabled to offer different levels of
service for their traffic. Services can be grouped in several types depending on packet drop, delay, and delay-variation
constraints. These constraints are driven by applications such as interactive voice communications, audio, and video that are
sensitive to delay and delay variations (jitter), but they can afford to lose randomly a small percentage of the traffic. At the other end of the spectrum is the mission-critical application that needs reliable, no-loss data transfers while placing a lower
emphasis on timing requirements. The service level is an end-to-end concept that qualifies a mode of handling traffic based on its various characteristics such as type, content, source, and destination. Deploying QoS in a network enables it to support various levels of service. For some, the well-being of their
IPv4 QoS is implemented through two architectures. Integrated Services (IntServ, as in RFC 1633, was modeled based on the concept of circuit). In this case, the user, with the help of a signaling protocol called Resource Reservation Protocol (RSVP; RFC 2208), reserves the resources end to end before sending the data. Differentiated Services (DiffServ), described in RFC 2475 and RFC 3260, is the second architecture, and it relies on the information carried within each packet to make resource-allocation decisions at each network node. This approach is simpler and more dynamic; however, it requires a good understanding of the traffic profiles in the network and a
consistent end-to-end implementation of policies. DiffServ is a widely adopted QoS deployment architecture. Although the QoS concepts are reviewed in Chapter 5 "Implementing QoS," in-depth information on them and their deployment strategies can be found in various specialized books such as IP Quality of
Service, a Cisco Press book by Srinivas Vegesna.
With the dramatic increase of traffic transported over packet networks and the demands of the various services and
applications supported, it is difficult to understate the value of QoS in today's IPv4 networks. The same holds true for IPv6. Some hoped for an improved QoS in the next generation of the IP protocol, and some still believe that IPv6 is better than IPv4 in this respect. The reality is that neither evolutionary nor
revolutionary changes were made to IPv6 versus IPv4. Some claim radical QoS improvements in IPv6. These are but a myth at the time of this writing. The same concepts and architectures apply to the new protocol with few and insignificant differences that are discussed in Chapter 5 of this book. An additional
packet header field (Flow Label) is believed to hold the potential for improving the QoS mechanisms, but the means to use it are still being evaluated.
for IP transport will most definitely change the current
approaches on deploying QoS. IPv6 networks hold the potential to implement true end-to-end service level policies. But for now, IPv6 is content to follow in the footsteps of its
Multicast Services
Simply stated, the problem solved by multicast is this: allow one host to talk to several others without bothering everyone else. In a world with limitless resources, the solution is not difficultthe source would replicate the data stream into multiple unicast streams destined for all interested parties. In the real world, this obviously is not a scalable approach. On one hand, it would overburden the source, and on the other, it would have a tremendous impact on the network whenever
bandwidth-intensive traffic such as video is transmitted. A scalable
alternative is to let the network replicate the data as needed. In a "multicast-aware" network, the data stream is replicated
along the way, by the network elements, at points where paths to various destinations converge. A set of dedicated protocols ensures that this data is delivered with optimal utilization of the underlying IP infrastructure, while selecting shortest paths with minimal delay between the source and the destinations.
The demand for multicast services is on the rise, driven by the need for collaborative, real-time information sharing. A wide range of multicast-based applications made their way into both enterprise and service provider types of networks:
Enterprise networks Distribution of financial information (such as stock quotes), distribution of news,
videoconferencing, and delivering content to employees (for example, software updates or facilitate distance learning)
Despite the interest it generates, multicast took a long time and a lot of creative thinking to be developed to the level of a
reliable, manageable, and high-performance service offering. Multicast is deployed on top of an existent IP unicast
infrastructure and conceptually it deals with the same issues of addressing, routing, and forwarding, but sometimes from a radically different perspective. You can find a detailed
presentation of the IPv4 multicast operation and its deployment guidelines in Developing IP Multicast Networks, Volume 1 by Beau Williamson.
Multicast came as an afterthought in IPv4 and it had to deal with many of the limitations built in to the protocol up to that point. Some of these intrinsic constraints become more evident as productivity-enhancing applications and customer
requirements drive up the number of networks that deploy multicast services. By contrast, IPv6 multicast gained a
prominent role from the start and it was developed alongside unicast. This offers the unique opportunity to make it a
ubiquitous service from day one. The operation and benefits of IPv6 multicast are discussed in Chapter 6 "Providing IPv6
Multicast Services."
However, no dramatic changes should be expected; both implementations are built on the same principles. IPv6 took advantage of the larger addresses and larger addressing space while following a more practical approach with respect to
multicast routing protocols selection based on the lessons learned with the IPv4 multicast services. The following are some of the issues that IPv4 multicast faces:
Limited availability of MAC address for layer 2 multicast address mapping. IPv6 is facing a similar problem.
Rendezvous Point (RP) scalability problems in large
multicast domains. IPv6 provides additional mechanisms that facilitate RP to multicast group mapping.
Complex mechanisms used to contain multicast control and data traffic within multicast domains. Through address
scoping, IPv6 offers elegant new ways to mange the multicast traffic.
RP source registration information synchronization is done through the MSDP protocol, a protocol that was meant to be a temporary solution for this function. No further
development was done on the protocol for a couple of years. No mechanism is yet available in IPv6 to perform these functions.
The adoption of MPLS by most service providers and deployment of MPLS/VPN services are a challenge for multicast. Currently there is no mechanism available to support label switching of multicast. At best, multicast traffic is forwarded without leveraging the MPLS
infrastructure. An additional control mechanism is needed in order to isolate the multicast traffic within each VPN. A
stop-gap solution called Multicast VPN (MVPN) is currently offered in Cisco IOS. Nevertheless, with MPLS commonly deployed in Service Provider networks and making its way into the large Enterprise ones, a comprehensive solution to the "multicast over MPLS" problem is important not only for IPv4 but equally important for IPv6.
Note
multicast control plane within each multicast VPN routing and forwarding table (VRF). From a
forwarding perspective, the multicast traffic is
Generic Routing Encapsulation (GRE) encapsulated and IP forwarded. With MVPN, the multicast traffic is not MPLS labeled even though it might be deployed with MPLS based VPNs.
IPv6 multicast continues to evolve and develop. It adapts to practical market requirements such as Triple Play services and collaborative applications. Chapter 6 discusses the IPv6
multicast protocol set. It also covers the deployment options and improvements with respect to IPv4 multicast,
Virtual Private Networks
The Internet has become for most corporations, campuses, and other isolated networks a shared infrastructure to provide
connectivity for their mobile workers or to interconnect distributed locations. Private networks over a shared
infrastructure have been deployed since the infancy of the Internet and even before with proprietary protocols or
standards such as X.25. After all, 20 years ago, one could dial from home in to his corporate network and upload or download data. What has changed is the virtualization of the links
providing the connectivity. Furthermore, the method used for sharing these logical links has moved up from layer 1 (using Time Division Multiplexing, TDM) to layer 2 (X.25, Frame Relay, or ATM Virtual Circuits) to layer 3 (PPP IP tunnels).
While so many corporate networks started to use this shared infrastructure, they inevitably started to worry about security. Their sensitive data is being exposed to others on the shared links. Their hosts and servers, connected to a public shared network, can be reached from anywhere by anybody, including malicious hackers.
The VPN technology enables telecommuters to connect to their office network (and enterprises to connect their sites together) over a public infrastructure. It has mechanisms that offer
security and quality of service.
For a complete and detailed presentation on this topic, refer to
VPN Applications Guide by David McDysan, and MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard.
Cost savings The Internet has become so ubiquitous, almost everybody can plug into it, potentially enabling connectivity with everybody else. Because it is
geographically spread everywhere, corporate users do not need anymore to dial long distance to reach remote
corporate resources.
Extended connectivity This is the concept of distributed and dynamic "closed user groups," where the VPN includes various networks with different privileges and excludes others. In a controlled way, this can include telecommuters and temporary users such as customers, partners, and so on.
Easy address-allocation process Addresses can be allocated from the IPv4 private address range. There is no need to coordinate the allocation through a control
organism as long as the communications stay in the VPN.
Simplification of the renumbering process Private addresses are less sensitive to external events, such as public addressing changes.
Services VPN can be used to deploy services not offered by the public network on a general scale.
Security VPNs have some built-in mechanisms to provide secure communications over the public infrastructure. One could argue that the deployment of VPNs is creating the problem that it then claims to solve. A bit of a sophism here!
Privacy The internal addresses are private to some extent because they are not published outside the private
Growth options Using small roads to interconnect remote sites makes it difficult to transport a lot of traffic when needed. Using shared highways provides opportunities to grow and to handle peaks as needed.
Address-depletion protection Some big organization might need more addresses than the IANA is ready to give up. VPNs enable it to use private address space and not worry about exposing these addresses over the public network.
Out of these benefits provided by VPN, some are perceived
benefits, in the sense that they are not directly provided by VPN technologies. The protection against address depletion, for
instance, is in fact achieved through NAT. Nodes in a private site are likely to require public resources access and will need public addresses to do so. To limit the number of these public
addresses required, some other technology is needed, to
expose a public address on these nodes behalf (one for many). This can be NAT or an application proxy.
So, are VPNs still useful with IPv6? The question is worth asking. Why would IPv6 customers ever need to deploy VPNs when they can get all the addresses they want? Why split the global address space into smaller chunks, if it is guaranteed that none of these addresses will ever overlap? In an ideal world full of honest people, that is probably true. This is precisely what VPN technology does not assume. It does not deal with issues of overlapping address space, but rather intends to isolate address spaces, and communications, to protect against malicious users. With IPv4, address-space overlapping simply becomes a by-product of VPN and NAT.
requirements that lead to similar solutions. VPNs are still useful in IPv6 networks.
However, IPv6 differs from IPv4 for two reasons that have
consequences on IPv6 VPN deployments. First, the IPv6 address space is large enough to allow address uniqueness, even across private networks. Second, by design, IPv6 does not support NAT. These differences do not drive fundamental requirement or technology divergence. But, they do have some consequences in various deployment scenarios. Chapter 7, "VPN IPv6
Architecture and Services," reviews IPv6 VPN technologies in detail and addresses the differences with IPv4. Chapter 13,
Security
Software applications and network infrastructures are mission-critical elements in today's economy. Those who use these resources as well as those who intend to abuse them
understand their value. Security is a broad term that
encompasses all the steps taken to evaluate the risks these resources are exposed to and implement the measures to counter them. Examples of threats and countermeasures include the following:
Software application attacks, denial-of-service (DoS) attacks, virus distribution, and data security breaches
Network infrastructure attacks, attacks on the network elements
Interception of data exchanged across public domains
IP security is not only a concern for enterprise networks; it is a concern even at the smaller scale of home networks. Internet access is becoming part of our daily lives whether we use it for online banking, VoIP, or information gathering. Attackers take this window to the larger world to be their door into the privacy of our own lives.
In some contexts, security takes a network management and operational perspective, although in others it becomes a
Sean Convery's Network Security Architectures.
Cisco SAFE Blueprint is a comprehensive set of references and design guides on securing various types of IPv4 networks and the services they deploy.
One of the most common misconceptions with respect to IPv6 is that it is more secure than IPv4. It is believed that when you eliminate NATs, IPv6 enables fully secured traffic to
transparently cross the boundary between public and private domains. The peer-to-peer communications model reinstated by IPv6 enables the endpoints to secure their information
exchange. This is a good idea if implemented by all endpoints. Otherwise, it could instill a false sense of security. Without having everyone participate in this new security paradigm, some RFC-obeying users might be left with a false sense of
security. It all started with the good intentions of RFC 2401 that mandated the use of IP Security (IPsec) with IPv6. Although the mandated observance would bring without a doubt a higher level of security, its success would depend on a consistent and proper implementation of IPsec on all applications and
networked devices. Until then, IPv6 is equally secure or
insecure as its counterpart is. In fact, most IPv6 deployments to date do not leverage any encryption, and that makes them
more vulnerable. The operational lessons learned from securing IPv4 networks and applications have yet to be all applied to IPv6, and this offers attackers extra opportunities during this transitional phase.
Overestimating how secure IPv6 is could be dangerous.
However, it would be unfair not to mention the committed effort made by the networking community to anticipate and provision for protocol security holes in IPv6. For new protocols that could be built with embedded security from the start, the topic was deemed so important that it blocked the standardization
the binding-update process. For protocols already built on the structure of their IPv4 counterparts, dramatic changes were avoided for practical reasons, and only limited tweaks were implemented. An example in this category is OSPFv3, which replaced the Message Digest 5 (MD5) authentication with IPsec AH and ESP headers to provide integrity, authentication,
confidentiality, and anti-replay protection of routing information exchanges.
Because of their similarities, IPv6 inherits the vulnerabilities of IPv4. For the common threats, the same countermeasures are applied. There are, of course, security improvements as well as new threats that stem from IPv6's idiosyncrasies, and these are discussed in Chapter 9, "Securing IPv6 Networks."
It is also important to address the entire area of IPv6 transition mechanisms. In this case, the various tunnel types open the door for IPv6 attacks, but more important, they provide
opportunities to circumvent the security measures protecting the underlying IPv4 infrastructure. In addition, changes made to IPv4 security measures and devices to accommodate IPv6 migration mechanisms can weaken an IPv4's network defense. Standardization work is being done to address these security risks, but for the time being they remain a concern.
IP Mobility
The Internet has become so pervasive that no matter where you are, you can plug your computer into a wall, or attach to a wireless LAN, and, after a while, you will be able to
communicate. Is not this mobility? Well, not quite.
That type of "mobility" is achieved by getting a new IP address within the network of attachment and losing all sessions bound to the previous IP address. This might be acceptable for
corporate users moving from work to home, but can be much more cumbersome for road warriors, and it can be a
showstopper for IP telephony.
Mobile IP provides a network layer for hosts that enables them to maintain the same IP address no matter where they are in the Internet, and keep receiving traffic as they move.
In Chapter 8, "Advanced ServicesIPv6 Mobility," MIPv6 is compared to MIPv4. Even though MIPv4 is a mature and
deployable technology, it faces limitations because of the nature of IPv4. At the same time, IPv6 mobility is considered as one potential enabler for IPv6. The number of IP-enabled devices and the need for any-to-any communications among them is driving requirements that IPv4 cannot easily satisfy, and it is opening opportunities for IPv6. By integrating functionalities designed for Mobile IPv4 into standard IPv6 protocols, and by leveraging existing IPv6 capabilities, MIPv6 has built up a MIP model that is much more compelling than its IPv4 counterpart.
It must be noted that enhancements to mobility are largely taking place in IPv6 related working groups, even though a
