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 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-level network. The information will be presented in the context of the existing IPv4 operational and design concepts, anchoring the discussion to familiar ground and the environments that 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 Table of Contents | Index Copyright About the Authors 1 1
Transcript
Deploying IPv6 NetworksBy Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete...............................................Publisher: Cisco PressPub Date: February 10, 2006Print ISBN-10: 1-58-705210-5Print ISBN-13: 978-1-58705-210-1Pages: 672
Table of Contents | Index
An essential guide to IPv6 concepts, service implementation, and interoperability in existing IPv4environments.
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 providethe 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 ofDefense, contractors such as Boeing and Lockheed Martin, have expressed stronger interest in thetechnology due to their customer requests. Microsoft considers IPv6 a strategic technology because it willfree the networks of NATs opening the door to peer-to-peer applications. Deploying IPv6 Networks willpresent the service capabilities of IPv6, the features supporting these services, and the ways in which theycan be implemented in a scalable, production-level network. The information will be presented in the contextof the existing IPv4 operational and design concepts, anchoring the discussion to familiar ground and theenvironments that will be incorporating the IPv6 services. After completing Deploying IPv6 Networks thereader will Understand the state of IPv6 technologies and services and the IPv6 features as they are appliedin service deployments. In addition they will know how to design and implement an IPv6 production-levelnetwork, using the book's templates and examples. Have the ability to configure and troubleshoot IPv6 inproduction networks and know where IPv6 developments are moving in the future.
Deploying IPv6 NetworksBy Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete...............................................Publisher: Cisco PressPub Date: February 10, 2006Print ISBN-10: 1-58-705210-5Print ISBN-13: 978-1-58705-210-1Pages: 672
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 retrievalsystem, 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 appropriatelycapitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a termin 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 tomake 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 haveneither liability nor responsibility to any person or entity with respect to any loss or damages arising from theinformation 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 specialsales.
10
10
For more information please contact: U.S. Corporate and Government Sales [email protected]
For sales outside the U.S. please contact: International Sales [email protected]
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book iscrafted with care and precision, undergoing rigorous development that involves the unique expertise ofmembers from the professional technical community.
Readers' feedback is a natural continuation of this process. If you have any comments regarding how we couldimprove the quality of this book, or otherwise alter it to better suit your needs, you can contact us throughe-mail at [email protected]. Please make sure to include the book title and ISBN in your message.
European HeadquartersCisco Systems International BVHaarlerbergparkHaarlerbergweg 13-191101 CH AmsterdamThe Netherlandswww-europe.cisco.comTel: 31 0 20 357 1000Fax: 31 0 20 357 1100
Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAwww.cisco.comTel: 408 526-7660Fax: 408 527-0883
Asia Pacific HeadquartersCisco Systems, Inc.Capital Tower168 Robinson Road#22-01 to #29-01Singapore 068912www.cisco.comTel: +65 6317 7777Fax: +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
All other trademarks mentioned in this document or Web site are the property of their respective owners. Theuse 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 ofexperience designing, testing, and troubleshooting large IP networks. As part of the Cisco Network SolutionIntegration Test Engineering (NSITE) organization, he currently focuses on the architecture, design, and testof large IPv6 network deployments in direct collaboration with service providers worldwide. He contributedto various publications and the IETF. Ciprian holds a bachelor of science degree from Babes-BolyaiUniversity, 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, wherehe is the technical lead for IPv6 development in IOS. Eric has worked with the Cisco IPv6 implementationsince 2001, and has been involved in some of the biggest IPv6 deployments. Before joining Cisco, Ericworked for IBM, where he successively led a development team in the Networking Hardware Division and aresearch team at the Thomas J. Watson Research Center, focusing on networking and content-deliveryplatforms. 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 IOSsoftware technologies including IPv6 and IP Mobility. He is a member of the IPv6 Forum TechnicalDirectorate and manages Cisco's participation in the forum. In June 2003, he received the "IPv6 ForumInternet 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 wasinvolved with network design and deployment. He received a degree in computer technology from the ControlData Institute, Paris, France.
About the Contributor
Pascal Thubert has been with the Technology Center since joining Cisco Systems in 2000. He leads a groupthat has been working on IPv6 networking mobility for the past five years. Pascal is the author of a number ofInternet drafts and IETF working group documents, in particular RFC 3963 (NEMO). He wrote the initialimplementation of IPv6 network mobility and experimented with a number of additional features for routeoptimization 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 IPv6e-Vehicle project. Before Cisco, Pascal was a lead network architect at IBM.
13
13
About the Technical Reviewers
Blair Buchanan, CCIE No. 1427, is a senior technical architect and convergence strategist with SherwoodCameron 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-controlapplications. Blair has participated in ISO standards development and has taken lead roles in internetworkdesign for large enterprise and service provider businesses in Canada and the United States. He is currentlyinvolved in planning and designing internetworks for converged services over metro Ethernet and IP VPNinfrastructures. Blair holds a bachelor degree in computer science and mathematics from the University ofWestern Ontario (1975). His involvement with Cisco began in 1992 as a Cisco instructor and in 1995 as aCCIE.
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 activitieswere based on TDMs, modems, and L2 bridges. He joined Cisco Systems in 1997, initially providing reactiveworldwide support as part of the Technical Assistance Center, specializing in IP routing protocoltechnologies. In 1999, he joined the Advanced Services organization as a network consulting engineer, wherehe 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 6NETIPv6 project, and this year has become involved with the IETF, for which he is authoring a number of drafts inthe v6ops working group. Gunter is a member of the IPv6 Task Force, and is a regular speaker at IPv6conferences and events.
Dan Williston is a technical leader at Cisco Systems in Ottawa. He was a key member of the softwaredevelopment team responsible for IPv6 on the Cisco 12000 series router. Prior to joining Cisco, he worked atNortel 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 integratedtelephony applications and hardware. Dan has 17 years experience in telecommunications and datanetworking 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 generationof IP and work tirelessly to implement, test, and deploy it. Among them, there are a few to whom we areparticularly grateful: Ole Troan, for his encouragement and support of this work, along with his contributionto 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. Wealso want to acknowledge the support of Gunter Van De Velde, Jean-Marc Barozet, Faycal Hadj, GillesClugnac, 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 theirthorough 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.
14
14
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 IOSCommand 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.•
15
15
Introduction
There is no doubt that information technologies have become a significant part of our lives, shaping in greatmeasure the way people work, learn, and play. Their rise to prominence was accelerated over the past decadeby 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 scopefrom research communities, to offices, to large corporations, and to the World Wide Web.
Unprecedented engineering innovation rapidly improved networking technologies in lockstep with the fastadoption 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 networkingprotocol 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 AddressTranslation becoming anachronisms that block further innovation.
With the looming exhaustion of the global IPv4 address space and with the private address space provinginadequate for today's networks, service providers, enterprises, IP appliances manufacturers, applicationdevelopers, and governments are now looking at the evolution of IP: IPv6. The foreseen address exhaustionhas been the trigger and the driver for moving into a new addressing dimension. IPv6, however, is more thanjust 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'sfuture, 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 fordeployment. It goes beyond discussing the basics of the protocol while remaining accessible to thoseunfamiliar with IPv6. With this book in hand, you will not only understand IPv6 but, most important, willknow 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 allthe changes and improvements made would require more than this book. On the other hand, IPv6 has yet toenter the mainstream and is outpacing many of the reference books on the market. This creates the risk ofmaking any pure deployment case study discussion difficult to follow. These considerations shaped themethodology employed in this book.
The most important changes in the foundation of IP, such as addressing architecture, packet format, and layer2-to-layer 3 address resolution, are reviewed in detail. All the other protocols and features are discussed in thecontext of a service such as unicast, multicast, virtual private networks, quality of service, and security. Thegoal is to provide the reader with the understanding and tools needed to deploy the respective services. Thisapproach gives a practical dimension to the information presented. This knowledge is reinforced in the secondpart 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 tofurther anchor the discussion into real-life deployment challenges.
All covered topics are complemented with configuration 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
16
16
and design considerations and present in the end configuration of key network elements. You can leveragethis 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 IPcommunications in one way or another. Researchers, application developers, and IP appliance manufacturerscan learn the protocol and possible ways to harness the IPv6 infrastructures of the future. However, this bookprimarily targets those who design, plan, deploy, and operate IP networks and services. Networkingprofessionals 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'sstructure has a clear didactic dimension. It intends to build the knowledge layer by layer, or IP service by IPservice, 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. Theknowledge is grouped around IP services, each mapped to a chapter. It starts with enabling unicastconnectivity, 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 atechnical perspective. It summarizes the differences between IPv4 and IPv6, and in the process ofdrawing a parallel between the two versions of IP, this chapter reviews the major concepts andchallenges that people manage in their current network. Thus, it provides a framework for the IPv6discussion in the rest of the book.
•
Chapter 2, "An IPv6 Refresher" This chapter discusses the fundamentals of IPv6 and some of theareas that saw significant changes from IPv4. It covers the new addressing architecture, the newheader format and structure, the enhanced functions of ICMP, and the layer 2 address-resolutionmechanisms. These are concepts fundamental to understanding any IPv6-related topic. For thisreason, they are presented in detail here.
•
Chapter 3, "Delivering IPv6 Unicast Services" This chapter discusses the elements necessary forestablishing unicast IPv6 connectivity, the foundation of all other IPv6 services. It covers the relevantprotocols at the access, edge, and core of the network. The mechanisms enabling the transition from
•
17
17
IPv4 to IPv6 are discussed along with recommendations on what IPv6 deployment approach to followin 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. Itparallels their implementation and operation to their IPv4 counterparts.
•
Chapter 5, "Implementing QoS" This chapter reviews, from the perspective of IPv6, the conceptsrelevant to implementing quality of service in IP- and MPLS-based networks. It also discussesdeployment considerations relevant to the coexistence of IPv4 and IPv6.
•
Chapter 6, "Providing IPv6 Multicast Services" This chapter reviews the IP multicast concepts andprotocols. It draws a parallel between IPv4 and IPv6 features, it explains the new mechanismsavailable in IPv6, and it provides examples that capture the various deployment options. Multicastdeployment in conjunction with the various transition mechanisms is also discussed.
•
Chapter 7, "VPN IPv6 Architecture and Services" This chapter covers the topic of deploying VPNservices in an IPv6 network. It reviews the VPN-related concepts and the deployment models. Inclosing, the chapter shows several topology examples with relevant configuration examples.
•
Chapter 8, "Advanced ServicesIPv6 Mobility" This chapter covers the concepts of IP mobility andtheir implementation in IPv6. It discusses the improvements made, the remaining open issues, andvarious examples of applying the protocol to novel services.
•
Chapter 9, "Securing IPv6 Networks" This chapter starts with an analysis of the security threats facedby IPv6, the ones specific to the new protocol, and the ones shared with IPv4. The dual perspective iscritical because the coexistence of the two protocols can provide new attack vectors on theIPv6-enabled network. The chapter also presents the tools and best practices available to secure IPv6networks.
•
Chapter 10, "Managing IPv6 Networks" This chapter discusses the challenges faced in managing IPv6networks; some challenges are rooted in the protocol specifics, whereas others stem from theavailability of tools. It covers the applications and management systems that can be leveraged today tooperate IPv6 infrastructures and services.
•
Chapter 11, "Network Performance Consideration: Coexistence of IPv4 and IPv6" This chapterprovides relevant answers to the natural concern about the impact that IPv6 services will have onexisting, revenue-generating IPv4 services and infrastructures. It provides guidelines on how toevaluate the IPv6 performance of network elements, and reviews the areas where the coexistence ofthe two protocols could lead to resource contention.
•
Part II
Chapter 12, "Generic Deployment Planning Guidelines" This chapter is intended to assist the readerin planning the deployment of IPv6 services. It provides guidelines on estimating the cost ofdeployment. It also provides references to resources relevant to planning the deployment, such asgetting 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 theplanning, designing, and deployment of IPv6 in an MPLS service provider network. Internet accessand VPN services are rolled out in stages, and configuration examples are provided for each one ofthem. The chapter closes with examples on troubleshooting the IPv6 network and the servicessupported.
•
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 isdual stack, end to end. The various services are built in stages, and configuration examples areprovided for each one of them. The chapter closes with examples on troubleshooting the IPv6 networkand the services supported.
•
Chapter 15, "Deploying IPv6 in an Enterprise Network" This chapter starts by presenting the stepstaken by an enterprise to evaluate IPv6 at both network and host level. It shows the development of afew services addressing specific business needs. The planning, designing, and deployment of the IPv6services are presented. The chapter closes with a section on network troubleshooting and its futureevolution.
•
18
18
Part I: Implementing IPv6 ServicesChapter 1 The Case for IPv6An Updated PerspectiveChapter 2 An IPv6 RefresherChapter 3 Delivering IPv6 Unicast ServicesChapter 4 IPv6 Routing ProtocolsChapter 5 Implementing QoSChapter 6 Providing IPv6 Multicast ServicesChapter 7 VPN IPv6 Architecture and ServicesChapter 8 Advanced ServicesIPv6 MobilityChapter 9 Securing IPv6 NetworksChapter 10 Managing IPv6 NetworksChapter 11 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 ofIPv6's importance and benefits. Countless pages have been written describing business models that wouldfinancially justify the deployment of IPv6. Sometimes innovative, other times controversial, the job of sellingIPv6 has its role in challenging today's tactical approach to planning network-related capital expenditures. Butdespite all these efforts, it might just be that the accelerated depletion of the IPv4 address space will remainthe 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 providea realistic perspective of IPv6, revealing its positives and negatives. This exercise, however, cannot beperformed in absolute terms. For this reason, "the case for IPv6" is presented relative to the familiar frame ofreference 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 thatdocument was completed, so "an updated perspective" is seen as useful.
A deployment perspective is maintained while discussing the various IPv6 topics throughout the book. Thetechnology is presented in the context of each network service layer:
This chapter follows the same structure. Each service is briefly reviewed in the context of the IPv4 world. Theprotocol limitations and deployment issues are singled out along with pointers to IPv6 solutions orimprovements, with further pointers to the chapters of this book where these topics are detailed. This chapterprepares the reader for an IPv6 discussion with the help of this overview of today's IPv4 services.
The delivery of IP services relies on an infrastructure that providesunicast connectivity between IP hosts. The foundation of such aninfrastructure consists of three elements: addressing, routing, andforwarding.
IP addresses represent a finite resource used in identifying hostswithin private or global networks. The structure and allocationmechanisms 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 addressspace. After all, at the time of this writing, addressing is one of themain reasons for deploying IPv6.
Routing and forwarding provide the mechanisms to move trafficbetween IP hosts. Whereas forwarding's dependency on IP version isrelatively straightforward, routing has multiple dependencies onaddressing. For this reason, it is important to see whether any of theIPv4 routing challenges were resolved in IPv6.
Addressing
IP addressing is a vast topic that influences most of the protocollayers and most of the services. It also represents a critical resource.This section briefly discusses address architecture and addressallocation. For a complete and detailed presentation, the followingbooks are helpful references:
IP Routing Fundamentals by Mark A. Sportack• Internet Routing Architectures by Sam Halabi and DannyMcPherson
•
Routing in the Internet by Christian Huitema•
IPv4 Address Architecture
A little bit of history is necessary to understand the debate aroundthe IPv4 address space depletion. An address is used to uniquelyidentify hosts within the network. Even in a flat nonhierarchicalsimple world, some minimum requirements on the address structureenable network elements to operate efficiently. In IPv4, the addresshas a fixed size of 32 bits. That would allow in theory up to 232
addresses or somewhere around four billion. It is important to notethat at the time of its specification, these four billion possibleaddresses appeared to be more than adequate for years if notcenturies to come. As soon as early 1990s, however, the Internetcommunity had to introduce a number of changes in the addressarchitecture and the address-allocation scheme to accommodategrowing address needs. IPv6, which is based on 128-bit-longaddresses, appears to be safe for centuries to come, but who says
20 Part I: Implementing IPv6 Services
20 Part I: Implementing IPv6 Services
that history cannot repeat itself?
A considerable waste of IPv4 addresses was generated by twofactors:
The unwise allocation of classful addresses; often entitieswith just a little over 255 hosts asked for a Class B, capableof accommodating 65,000 hosts.
•
Users were not challenged to justify their address requests.When people started to foresee address exhaustion, only 3percent of the allocated addresses were actually in use!
•
The increasing number of hosts challenged the address spaceresources and led to the formalization of private addressing andNetwork Address Translation (NAT) as an address-conservationsolution. The increase in the number of hosts is also matched by anincrease in the number of networks and this leads to scalabilityproblems for the routers. In 1994, the core routers hadapproximately 34,000 routes, doubling every year. By 2004, it wasexpected to reach millions routes. Variable-length subnet mask(VLSM), Classless Inter-Domain Routing (CIDR), and a new IPaddress-allocation strategy was the response to the routing tableexplosion.
Although the core routing table size was predicted to grow from34,000 to 80,000 between 1994 and 1995, in fact it reached 76,000routes only in 2000 and about 160,000 in mid 2004.
With IPv6 and its larger address space, one could fear that routingtables will further expand. Bigger addressing space might logicallylead to more hosts followed by more networks. In reality, pastexperience has shown that the "number of hosts" and the "number ofnetworks" are loosely related. With the proper aggregationmechanisms, partly driven by the right address-allocation strategy,the latter have been well under control. Assuming the samemechanisms are maintained and further enforced with IPv6, it isreasonable to believe that routing table size will remain withinmanageable limits.
Note
For more details on CIDR, and related topics, you can read thefollowing RFCs: RFC 1517, RFC 1518, RFC 1519, and RFC 1520.Also, RFC 1887 provides some hints on the reasoning behind IPv6address allocation, and architectural implications.
The address-conservation mechanisms cannot stave off for long theneed for global IP addresses. Past and current Internet growth rates(source BGP table statisticshttp://bgp.potaroo.net/) can beextrapolated to predict the time left before the complete exhaustionof all available IPv4 address space. Conservative studies estimate
the IPv4 address-space exhaustion by February 2041, and theexhaustion 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 thecurrent growth models will remain applicable for years to come,which is not necessarily accurate.
IPv6 might change these assumptions. With the combination of theInternet as an attractive and accessible communications medium,and the emergence of communicating gadgets and devices of allkind (even the most unexpected ones such as phones, homeappliances, cars, and so on) you must be ready to see themproliferate and stimulate a growth in Internet usage that cannot beextrapolated from past patterns.
Private Versus Public Addresses
Public addresses are registered, globally unique, and can be used toprovide reachability over the Internet. By contrast, private addressesare meaningful only within a closed, physical or virtual domain. InIPv4, private addresses have been always associated withunregistered addresses, which in return have been associated withnonunique addresses.
There might be many reasons why an organization would want touse both public and private addresses. Public addresses are used toget 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, atpeering points) to save the renumbering hassle
•
Protect the internal network from the public domain bypreventing private addressing/topology exposure
•
RFC 1918 identifies two categories of hosts that could deal withprivate addresses:
Hosts that do not require access to hosts in other enterprisesor the Internet
•
Hosts that need access to a limited set of outside services(e-mail, FTP, and so on) that can be handled by intermediategateways
•
For these two categories, RFC 1918 further defines three blocks ofprivate addresses that should not be routed over the Internet, andtherefore 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•
22 Part I: Implementing IPv6 Services
22 Part I: Implementing IPv6 Services
In an ideal world, privately addressed hosts would be confined to theprivate network, whereas only hosts with public addresses would beable to access the public domain. In reality, most hosts need to leavethe private network boundaries at some point. Usually, there are notenough public addresses for all hosts in the private network, sofurther mechanisms are necessary to interface them with the publicdomain. The simplest one is NAT, discussed in the section "NetworkAddress Translation."
One of the benefits of the private address space is the large numberof addresses available at the discretion of an enterprise. It was,however, only logical to expect that the private address space willface depletion similar to the overall IPv4 address space. In 2005,multiple-systems operators (MSOs; or cable operators) reported thefact that they are running out of private address space. This is due tothe proliferation of cable modems, Voice over IP (VoIP) phones,and set-top boxes they have to manage over IP. This realizationaccelerated their plans to deploy IPv6 if not to provide services atleast to manage their devices.
Some of the reasons to use private addresses become obsolete withIPv6 (there are now plenty of public addresses for everyone)although others will remain. VPN solutions exist for IPv6, too, andthat could be sufficient to safeguard the privacy of addressing usedwithin a network. The plethora of IPv6 addresses had suggestedsome different paradigms for private addressing, in particular theconcept of unique yet private address. These concepts are presentedin Chapter 2, "An IPv6 Refresher." The concepts and issues thatarose when crossing the boundary between private and publicdomains are presented in Chapter 7, "VPN IPv6 Architecture andServices."
Static Versus Dynamic Addresses
Addresses can be assigned to IP nodes either statically ordynamically. The static addresses are allocated "indefinitely" or untilexplicitly removed. Dynamic Host Configuration Protocol (DHCP)allows a computer to have a different IP address each time itconnects to a network. This process enables multiple users tooverload the use of a pool of dynamically assigned addresses. DHCPalso enables mobile hosts to attach to visited subnets withoutrequiring manual reconfiguration. In reality, dynamically allocatedaddresses might not change often either. In large networks, DHCPservers tend to allocate the same address to the same host over time,unless there is some shortage. For the home environment, there aretwo categories of users:
Users with dialup connections will change their addressoften. Most Internet service providers (ISPs) make use ofDHCP to assign an IP address to each user for the length oftime they are connected, and reuse it for another customerafter the dialup connection from the previous customer hasbeen terminated.
•
Part I: Implementing IPv6 Services 23
Part I: Implementing IPv6 Services 23
Users with long-life connections such as Digital SubscriberLine (DSL), Integrated Services Digital Network (ISDN), orcable will tend to keep their address for a longer period oftime.
•
There are now advantages and disadvantages with the trend to usemore stable source addresses than there were in the past. From anetwork operation perspective, one could find useful that the sameuser stays behind the same IP address; it is easier to manage, bill,filter, authenticate, and so on. However, this operational modeleliminates address reuse, which conserves the IPv4 address space.For this reason, broadband services are a significant catalyst in theacceleration of IPv4 address consumption. When theaddress-shortage concerns are eliminated with the adoption of IPv6,there could be a tendency to allocate static addresses, or allocatedynamically the same address to the same user all the time. Theadvantages of having the IP address uniquely and permanentlyidentify the device are counterbalanced by possible privacy issues.The same address used in multiple contexts (for instance, websurfing, gaming, and so on) can be used to correlate seeminglyunrelated activities. Note that with IPv6, which offers the possibilityof using addresses that embed topological information such as linkidentifier, the concern will grow. The mechanisms to allocate IPv6addresses dynamically are reviewed in Chapter 3, "Delivering IPv6Unicast Services."
Renumbering
Want to know a network administrator's worst nightmare? It isrenumbering. Renumbering is the process of replacing existingnetwork prefixes and host addresses considered as deprecatedthroughout 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 ischanging; more subnets need to interconnect; areorganization of the existing ones; more hosts to address;and so on. Renumbering, although not always required inthese cases, could potentially improve aggregation and issometimes highly recommended.
•
The network is merging with another one (for instance, inthe case of two companies merging).
•
The network was private and disconnected from the publicnetwork, and now wants to provide public access to its hostsand servers.
•
The complexity of the renumbering process comes from the fact thataddresses are used in many different places within a network and formany different reasons. A single address or a set of addresses mayhave been configured statically or dynamically in various placessuch as the following:
24 Part I: Implementing IPv6 Services
24 Part I: Implementing IPv6 Services
BOOTP or DHCP servers• Applications servers of all kinds (HTTP, FTP, mail, and soon)
•
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 oneoperational; in many cases, however, the old address has beenleaked 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 willmake them invalidate the "old" addresses, but some do not. In mostcases, changing the address and network prefix requires rebootingthe host. When addresses are cached throughout the network, delays(mostly "uncontrolled") will occur before the new addresses areoperational.
Although some believe that renumbering issues have been entirelytaken care of in IPv6, others believe that renumbering remains aproblem without any good solution. The truth lies somewhere inbetween. The renumbering issue is multidimensional, and IPv6brings some innovative solutions in some areas, although it does notsolve the entire problem.
Chapter 2 and Chapter 3 describe some built-in IPv6 mechanismssuch as link-local addresses, autoconfiguration, and support formultiple addresses on the same interface that can ease aspects ofnetwork renumbering.
Network Address Translation
Network Address Translation (NAT) has brought the best and theworst to IP deployments. Per NAT RFC authors, NAT was ashort-term solution to enable address reuse and solve theaddress-depletion issue the IP Internet community was anticipatingin 1993. That worked out well indeed, and what seemed to be acritical issue in 1993 is less critical more than 10 years later. NAThas 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 networkingcommunity, and for that reason we dedicate this section to it.
For technical background and more details on NAT principles andoperations, refer to RFC 1631 and books such as the Cisco Pressbook Routing TCP/IP, Volume II (CCIE Professional Development)by Jeff Doyle. Over the years, NAT has been deployed widelythroughout the Internet. During this time, its use was givenjustifications beyond address conservation: from security to privacy,from preventing renumbering to providing high-availabilitymechanisms, from deployment of virtual clusters to providingInternet access over VPNs. Each of these justifications wasprompted by some deployment scenario and was meant to solve
Part I: Implementing IPv6 Services 25
Part I: Implementing IPv6 Services 25
deployment issues.
Although some of these reasons will become irrelevant after IPv6 isdeployed, not all of them will. Although NAT has hurt thedeployment of many applications, and many people would be happyto see this so-called "short-term" solution go away with IPv6, it willbe interesting to understand and analyze NAT's place in today'snetworks and the problems it addresses. If we want to rid the worldof the evil NAT, we must make sure IPv6 offers solutions for allproblems NAT resolved.
NAT comes with a number of issues, out of which the mostsignificant is the connection model that it implies. NAT isasymmetrical. Because of the way NAT works, it is mainly usablefor client/server sessions where clients within the private networkinitiate the session with servers sitting in the public network. Theclient will typically issue a Domain Name System (DNS) query forsome public server name, and get the public server address. On theway back, the server will see only the public NAT address,expectantly a globally reachable one. Going the reverse direction ismore 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 handleall necessary application signaling and enable hosts to use eachothers NAT addresses as the reachable public address. SessionInitiation Protocol (SIP) is a good example of such a solution.However, twisting every single peer-to-peer application to make itfit the client/server model appears to be a great limiting factor to theadoption and deployment of new applications.
Another issue with NAT is that it does not look at any informationabove IP/TCP/UDP/ICMP layers. Some applications have endpointsource addresses buried within their messages, which do not gettranslated by NAT at the same time as the IP header addresses. Thistypically happens with applications such as H.323 that tend toestablish multiple connections within a single session. To solvethose issues, application layer gateways (ALGs) may need toperform complex application-level translations. When an applicationthat required an ALG is deployed, NAT devices must support thisparticular ALG.
NAT has some security issues, too. Any security mechanism basedon signing or verifying part of the packet, whether header or payloadincluding IP addresses, will have trouble when addresses areoverwritten. For instance, with IPsec, both Authentication Header(AH) and Encapsulating Security Payload (ESP) have issues withNAT, although at a different order of magnitude.
26 Part I: Implementing IPv6 Services
26 Part I: Implementing IPv6 Services
Can IPv6 Eliminate NAT?
NAT is used in the networks of 70 percent of Fortune 1000companies, for better and worse. So, either NAT is not necessaryanymore after IPv6 is deployed, and the worst is gone. Or, IPv6 doesnot have a proper solution for all deployment scenarios where NATis in use and these networks will not transition. Although the largeIPv6 address space eliminates the need for NAT, it is important toexplain how IPv6 also provides similar capabilities as the"perceived" benefits of NAT. This is the main purpose of NetworkArchitecture Protection (NAP), an Internet Draft addressing eachNAT benefit (real or perceived) and matching it with an IPv6solution. Table 1-1 lists NAT features, and for each, it providespointers 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 NAPNAT Feature IPv6 Reference More Details InAddress depletion IPv6 Addressing
[1] A multihomed site can use NAT to translate the various provider addresses into a single setof private-use addresses.
[2] NAT can be used to load balance traffic over a set of servers by hiding their individualaddresses 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 orrouters addresses behind the same virtual address. Other techniques can be used for the samepurpose, which do not rely on NAT, and can work with IPv6, such as HSRP (Hot StandbyRouter Protocol), VRRP (Virtual Router Redundancy Protocol), and GLBP (Gateway LoadBalancing Protocol).
[4] Sites or individual hosts configured with private addresses use NAT to expose a publicaddress (rather than their private address) when connecting to a public resource.
28 Part I: Implementing IPv6 Services
28 Part I: Implementing IPv6 Services
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 significantperiod of time, you need to know whether there are any IPv6 deployment issues with regard to traversing IPv4NATs. Indeed, many of the transitioning mechanisms that Chapter 3 describes involve tunneling IPv6 trafficover IPv4. These IPv4 networks are full of NAT, and being able to properly traverse them is critical to IPv6deployment.
Routing
The engineering community has not really touched the routing foundations of unicast services in the contextof IPv6. Of course, whenever an IPv4 routing protocol had some dependencies on IPv4 addresses, work wasdone to produce an IPv6 version of it. This is the case, for instance, with OSPFv3. Chapter 4 "IPv6 RoutingProtocols," reviews these changes in the routing protocols. But besides "cosmetic differences," all IPv4routing protocols are closely matched in IPv6, sharing the same design, often the same implementation, withthe same area of applicability and the same issues. In IPv6, you will find the familiar Routing InformationProtocol (RIP), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway RoutingProtocol (EIGRP), Open Shortest Path First (OSPF), and Border Gateway Protocol (BGP).
Are you disappointed? You might have expected the IPv6 designers to take advantage of the new addressstructure to enhance the way routers handle network prefixes to achieve better aggregation. This would haveindirectly led to new or significantly modified routing protocols. The opportunity was offered in the way theIPv6 address was structured. RFC 1887 describes some early attempts to form a hierarchical routing system,and RFC 3513 structures the IPv6 unicast address to enable efficient routing aggregation. So far, theseattempts have not materialized into an innovative routing protocol. CIDR with BGP aggregation andallocation policies remain the solution for optimizing aggregation in IPv6, too.
QoS Services
Packet-switched technologies are well suited for data communications, which, at first, did not care as muchabout timely delivery or resource reservation. With packet-switched technologies, the faith of packets isentrusted entirely to the best efforts and good will of the network. Although not reassuring, the approach ismore flexible and allowed these technologies to develop faster than the circuit-switched ones. Besides beingcapable of multiplexing the user traffic, they offer features that could easily enable new, revenue-generatingservices on existing networks. The success of packet switching led to an ever-expanding set of applicationsleveraging IP. It was not long before time-sensitive applications were IP enabled, and they required specialhandling of their packets, especially under congestion conditions.
Because not all applications have the same requirements, the IP infrastructure must be enabled to offerdifferent 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 voicecommunications, audio, and video that are sensitive to delay and delay variations (jitter), but they can affordto lose randomly a small percentage of the traffic. At the other end of the spectrum is the mission-criticalapplication 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 variouscharacteristics such as type, content, source, and destination. Deploying QoS in a network enables it tosupport various levels of service. For some, the well-being of their network and proper support of deployedapplications depend on it. For others, QoS is a revenue source based on contractual agreements called servicelevel agreements.
Part I: Implementing IPv6 Services 29
Part I: Implementing IPv6 Services 29
IPv4 QoS is implemented through two architectures. Integrated Services (IntServ, as in RFC 1633, wasmodeled based on the concept of circuit). In this case, the user, with the help of a signaling protocol calledResource 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 itrelies on the information carried within each packet to make resource-allocation decisions at each networknode. This approach is simpler and more dynamic; however, it requires a good understanding of the trafficprofiles in the network and a consistent end-to-end implementation of policies. DiffServ is a widely adoptedQoS 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 suchas 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 servicesand applications supported, it is difficult to understate the value of QoS in today's IPv4 networks. The sameholds true for IPv6. Some hoped for an improved QoS in the next generation of the IP protocol, and some stillbelieve that IPv6 is better than IPv4 in this respect. The reality is that neither evolutionary nor revolutionarychanges were made to IPv6 versus IPv4. Some claim radical QoS improvements in IPv6. These are but a mythat the time of this writing. The same concepts and architectures apply to the new protocol with few andinsignificant differences that are discussed in Chapter 5 of this book. An additional packet header field (FlowLabel) is believed to hold the potential for improving the QoS mechanisms, but the means to use it are stillbeing evaluated.
Although there appears to be no significant differences between IPv4 and IPv6 QoS today, things might shapeup differently going forward. IPv6's aim to reestablish a peer-to-peer model for IP transport will mostdefinitely change the current approaches on deploying QoS. IPv6 networks hold the potential to implementtrue end-to-end service level policies. But for now, IPv6 is content to follow in the footsteps of itspredecessor.
Multicast Services
Simply stated, the problem solved by multicast is this: allow one host to talk to several others withoutbothering everyone else. In a world with limitless resources, the solution is not difficultthe source wouldreplicate the data stream into multiple unicast streams destined for all interested parties. In the real world, thisobviously is not a scalable approach. On one hand, it would overburden the source, and on the other, it wouldhave 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, thedata stream is replicated along the way, by the network elements, at points where paths to various destinationsconverge. A set of dedicated protocols ensures that this data is delivered with optimal utilization of theunderlying IP infrastructure, while selecting shortest paths with minimal delay between the source and thedestinations.
The demand for multicast services is on the rise, driven by the need for collaborative, real-time informationsharing. A wide range of multicast-based applications made their way into both enterprise and serviceprovider 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 facilitatedistance learning)
•
Service provider Content delivery such as video and audio streaming, collaborative applications suchas conferencing for enterprise customers or multiplayer gaming and chat for residential customers
•
30 Part I: Implementing IPv6 Services
30 Part I: Implementing IPv6 Services
Despite the interest it generates, multicast took a long time and a lot of creative thinking to be developed tothe level of a reliable, manageable, and high-performance service offering. Multicast is deployed on top of anexistent IP unicast infrastructure and conceptually it deals with the same issues of addressing, routing, andforwarding, but sometimes from a radically different perspective. You can find a detailed presentation of theIPv4 multicast operation and its deployment guidelines in Developing IP Multicast Networks, Volume 1 byBeau Williamson.
Multicast came as an afterthought in IPv4 and it had to deal with many of the limitations built in to theprotocol up to that point. Some of these intrinsic constraints become more evident as productivity-enhancingapplications and customer requirements drive up the number of networks that deploy multicast services. Bycontrast, IPv6 multicast gained a prominent role from the start and it was developed alongside unicast. Thisoffers the unique opportunity to make it a ubiquitous service from day one. The operation and benefits of IPv6multicast 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 practicalapproach with respect to multicast routing protocols selection based on the lessons learned with the IPv4multicast services. The following are some of the issues that IPv4 multicast faces:
Limited availability of globally unique group addresses. This is an expected problem generated by thelimited allocation of IPv4 addresses for multicast purposes. IPv6 provides plenty multicast addressesto facilitate the deployment of the service.
•
Limited availability of MAC address for layer 2 multicast address mapping. IPv6 is facing a similarproblem.
•
Rendezvous Point (RP) scalability problems in large multicast domains. IPv6 provides additionalmechanisms 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 protocolthat was meant to be a temporary solution for this function. No further development was done on theprotocol 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 achallenge for multicast. Currently there is no mechanism available to support label switching ofmulticast. At best, multicast traffic is forwarded without leveraging the MPLS infrastructure. Anadditional control mechanism is needed in order to isolate the multicast traffic within each VPN. Astop-gap solution called Multicast VPN (MVPN) is currently offered in Cisco IOS. Nevertheless, withMPLS commonly deployed in Service Provider networks and making its way into the large Enterpriseones, a comprehensive solution to the "multicast over MPLS" problem is important not only for IPv4but equally important for IPv6.
•
Note
It is important to point out that MVPN isolates the multicast control plane within each multicast VPN routingand forwarding table (VRF). From a forwarding perspective, the multicast traffic is Generic RoutingEncapsulation (GRE) encapsulated and IP forwarded. With MVPN, the multicast traffic is not MPLS labeledeven 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 Playservices and collaborative applications. Chapter 6 discusses the IPv6 multicast protocol set. It also covers thedeployment options and improvements with respect to IPv4 multicast, demonstrating that IPv6 is wellinstrumented to deploy and support multicast services.
Part I: Implementing IPv6 Services 31
Part I: Implementing IPv6 Services 31
Virtual Private Networks
The Internet has become for most corporations, campuses, and other isolated networks a shared infrastructureto provide connectivity for their mobile workers or to interconnect distributed locations. Private networks overa shared infrastructure have been deployed since the infancy of the Internet and even before with proprietaryprotocols or standards such as X.25. After all, 20 years ago, one could dial from home in to his corporatenetwork and upload or download data. What has changed is the virtualization of the links providing theconnectivity. Furthermore, the method used for sharing these logical links has moved up from layer 1 (usingTime Division Multiplexing, TDM) to layer 2 (X.25, Frame Relay, or ATM Virtual Circuits) to layer 3 (PPPIP tunnels).
While so many corporate networks started to use this shared infrastructure, they inevitably started to worryabout 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 malicioushackers.
The VPN technology enables telecommuters to connect to their office network (and enterprises to connecttheir 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.
A review of the reasons for deploying IPv4 VPNs is a useful step toward analyzing whether the concept ofVPN applies to IPv6 networks. Here is a nonexhaustive list of some of the VPN benefits, whether real orperceived as such:
Cost savings The Internet has become so ubiquitous, almost everybody can plug into it, potentiallyenabling connectivity with everybody else. Because it is geographically spread everywhere, corporateusers 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 theVPN includes various networks with different privileges and excludes others. In a controlled way, thiscan 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 thecommunications stay in the VPN.
•
Simplification of the renumbering process Private addresses are less sensitive to external events, suchas 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 publicinfrastructure. One could argue that the deployment of VPNs is creating the problem that it thenclaims to solve. A bit of a sophism here!
•
Privacy The internal addresses are private to some extent because they are not published outside theprivate infrastructure.
•
Growth options Using small roads to interconnect remote sites makes it difficult to transport a lot oftraffic when needed. Using shared highways provides opportunities to grow and to handle peaks asneeded.
•
Address-depletion protection Some big organization might need more addresses than the IANA isready to give up. VPNs enable it to use private address space and not worry about exposing theseaddresses over the public network.
•
32 Part I: Implementing IPv6 Services
32 Part I: Implementing IPv6 Services
Out of these benefits provided by VPN, some are perceived benefits, in the sense that they are not directlyprovided by VPN technologies. The protection against address depletion, for instance, is in fact achievedthrough NAT. Nodes in a private site are likely to require public resources access and will need publicaddresses 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 todeploy VPNs when they can get all the addresses they want? Why split the global address space into smallerchunks, if it is guaranteed that none of these addresses will ever overlap? In an ideal world full of honestpeople, that is probably true. This is precisely what VPN technology does not assume. It does not deal withissues of overlapping address space, but rather intends to isolate address spaces, and communications, toprotect against malicious users. With IPv4, address-space overlapping simply becomes a by-product of VPNand NAT.
VPN is not about addressing. It is about security and policing: security of data, achieved through encryption,and policing of routing, achieved by routing domain isolation. From these perspectives, IPv6 and IPv4 are thesame: identical 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, bydesign, IPv6 does not support NAT. These differences do not drive fundamental requirement or technologydivergence. But, they do have some consequences in various deployment scenarios. Chapter 7, "VPN IPv6Architecture and Services," reviews IPv6 VPN technologies in detail and addresses the differences with IPv4.Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network," provides in-depth VPN deploymenthints.
Security
Software applications and network infrastructures are mission-critical elements in today's economy. Thosewho use these resources as well as those who intend to abuse them understand their value. Security is a broadterm that encompasses all the steps taken to evaluate the risks these resources are exposed to and implementthe measures to counter them. Examples of threats and countermeasures include the following:
Software application attacks, denial-of-service (DoS) attacks, virus distribution, and data securitybreaches
•
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 homenetworks. Internet access is becoming part of our daily lives whether we use it for online banking, VoIP, orinformation gathering. Attackers take this window to the larger world to be their door into the privacy of ourown lives.
In some contexts, security takes a network management and operational perspective, although in others itbecomes a service. Both aspects are interesting, but in the end security has to be looked at and implemented ina holistic and consistent manner. For this reason, the topic is rather vast, and it grew to be this way throughthe relentless efforts of creative attackers. The reader can get a complete and detailed picture of the IPv4network security challenges and solutions from books such as Sean Convery's Network SecurityArchitectures.
Part I: Implementing IPv6 Services 33
Part I: Implementing IPv6 Services 33
Cisco SAFE Blueprint is a comprehensive set of references and design guides on securing various types ofIPv4 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 believedthat when you eliminate NATs, IPv6 enables fully secured traffic to transparently cross the boundary betweenpublic and private domains. The peer-to-peer communications model reinstated by IPv6 enables the endpointsto secure their information exchange. This is a good idea if implemented by all endpoints. Otherwise, it couldinstill a false sense of security. Without having everyone participate in this new security paradigm, someRFC-obeying users might be left with a false sense of security. It all started with the good intentions of RFC2401 that mandated the use of IP Security (IPsec) with IPv6. Although the mandated observance would bringwithout a doubt a higher level of security, its success would depend on a consistent and properimplementation of IPsec on all applications and networked devices. Until then, IPv6 is equally secure orinsecure as its counterpart is. In fact, most IPv6 deployments to date do not leverage any encryption, and thatmakes them more vulnerable. The operational lessons learned from securing IPv4 networks and applicationshave 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 thecommitted effort made by the networking community to anticipate and provision for protocol security holes inIPv6. For new protocols that could be built with embedded security from the start, the topic was deemed soimportant that it blocked the standardization process until it was properly addressed. A good example isMobile IPv6 (MIPv6), which embedded security in the route-optimization process and provisioned for controlsteps to secure the binding-update process. For protocols already built on the structure of their IPv4counterparts, dramatic changes were avoided for practical reasons, and only limited tweaks wereimplemented. 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, andanti-replay protection of routing information exchanges.
Because of their similarities, IPv6 inherits the vulnerabilities of IPv4. For the common threats, the samecountermeasures are applied. There are, of course, security improvements as well as new threats that stemfrom 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 tunneltypes open the door for IPv6 attacks, but more important, they provide opportunities to circumvent thesecurity measures protecting the underlying IPv4 infrastructure. In addition, changes made to IPv4 securitymeasures 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 aconcern.
These topics are further discussed in Chapter 9. The final word in security risk assessment and best-practicesrecommendations will come from the operational experience that will be gained while managing large IPv6deployments.
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 losingall sessions bound to the previous IP address. This might be acceptable for corporate users moving from workto home, but can be much more cumbersome for road warriors, and it can be a showstopper for IP telephony.
34 Part I: Implementing IPv6 Services
34 Part I: Implementing IPv6 Services
Mobile IP provides a network layer for hosts that enables them to maintain the same IP address no matterwhere 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 amature and deployable technology, it faces limitations because of the nature of IPv4. At the same time, IPv6mobility is considered as one potential enabler for IPv6. The number of IP-enabled devices and the need forany-to-any communications among them is driving requirements that IPv4 cannot easily satisfy, and it isopening opportunities for IPv6. By integrating functionalities designed for Mobile IPv4 into standard IPv6protocols, and by leveraging existing IPv6 capabilities, MIPv6 has built up a MIP model that is much morecompelling than its IPv4 counterpart.
It must be noted that enhancements to mobility are largely taking place in IPv6 related working groups, eventhough a fraction gets retrofitted into the IPv4 standards. Although MIPv6 has benefited greatly from itsMIPv4 parent, it is now the driver of the evolution of IP mobility, and it is widely expected to be a foremoststeering force for IPv6 deployments.
In terms of deployment, it must be considered that IP mobility enables new flows, which impact the wirelessinfrastructure: Telephony over IP demands a higher level of coverage, latency, and QoS enforcement, whereaspeer to peer imposes always-on reachability and multimedia capabilities.
The application of the MIP and NEtwork MObility (NEMO) standards is not limited to hosts and routers thatactually roam around the Internet as a usual behavior. Sales of consumer routers are plummeting. At themoment, they are related to IPv4 NAT operations. With IPv6, it can be expected that people will deployunmanaged yet globally addressable networks at home. NEMO support by the home gateways would enable aservice provider to deploy preprovisioned devices, and could save hundreds of thousands ofnetwork-renumbering operations per year as customers move from one home to the next.
At the core, MIP builds dynamic tunnels, and NEMO exchanges routes over those tunnels. In a way, this is arevamping of the traditional model of the core where BGP routers exchange the bulk of the Internet routesover peering tunnels. But whereas the model of the Internet is designed for fixed, aggregated routes that arelocally injected and slowly distributed throughout its fabric, MIP and NEMO techniques enable a new modelwhere routes are projected where and when they are needed, on-demand; this opens to a new level ofhierarchy for the fine-grained mobile routes, and a new order of scalability for the Internet.
But the Internet of today is not fully ready for IP mobility. Even if IPv6 can exist over an IPv4 fabric as atransitional method, a significant number of improvements must be made to cope with the latency of theprotocol and enable multimedia interactive applications such as voice calls and video.
See Chapter 8 for an in-depth review of IPv6 mobility.
IPv6 Is an Evolutionary Step
This brief overview of IPv4 services was intended to remind the reader of the challenges and joys of designingand operating today's networks. It is not meant to be the background of an IPv6 sale pitch, but rather a frameof reference for the IPv6 discussion in this book. The overview offered us the opportunity to highlight, from apractical perspective, the differences between the two versions of IP and forward reference the chaptersaddressing these differences. If you remember only one thing from this chapter, remember that IPv6 is anevolutionary step in the development of IP communications. It is rooted in the fundamental concepts of IPv4,and it draws from IPv4's operational experiences. After years of dealing with IP networks, the addressingshortage gave us a chance to take another look at how things can be improved. Now that we know what toexpect from the new protocol, we are ready to talk about its implementation and deployment.
Part I: Implementing IPv6 Services 35
Part I: Implementing IPv6 Services 35
Chapter 2. An IPv6 Refresher
IPv6 represents an evolutionary step for IP. Despite building upon IPv4 and the experience gained operatingIPv4 networks, IPv6 has its own idiosyncrasies and unique functionality implementations. For this reason, youshould familiarize yourself with the fundamentals of the protocol prior to looking into deploying it. Thischapter ushers you into the scope of this book by providing a brief refresher of key IPv6 concepts.
Many aspects of IPv6 set it apart from its predecessor. Some of these aspects are discussed in subsequentchapters from a deployment perspective. This chapter, however, focuses on a subset of IPv6 protocolcharacteristics that represent the foundation of its operation, as follows:
This chapter particularly emphasizes addressing for a simple reason: It represents one of the most importantbenefits of IPv6 today. Neighbor Discovery is also discussed at length to clarify the link operation of IPv6.
Rather than repeating the information readily available in many books dedicated to describing the IPv6protocols, this book focuses on reviewing the deltas from IPv4 and their impact on deployment. The followingbooks are recommended for technology overviews: Cisco Self-Study: Implementing Cisco IPv6 Networks(IPv6) by R. Desmeules, and IPv6: The New Internet Protocol by C. Huitema.
IPv6 Addressing
Addressing is a fundamental aspect of the communication process between two or more entities. Itprovides the means to identify information sources and destinations while enabling dedicated resourcesto appropriately link the two groups together. This holds true whether we talk about the United StatesPostal Service or an IP network. The previous chapter briefly overviewed the IPv4 addressing structureand the challenges generated by a limited address space and its unwise use. The previous chapter alsoshowed that the most compelling reason to adopt IPv6 is its addressing capabilities. It is natural,therefore, to make this topic a centerpiece of this IPv6 refresher.
IPv6 Address Representation
If we set aside the troubles that result from unplanned address assignments, we still face the inevitableexhaustion of the IPv4 addressing space. The 32-bit long IPv4 address offers roughly 2 billionpractically usable IDs. This set will not be able to withstand much longer the growing needs of arapidly increasing number of users who require unique, globally reachable IP addresses. The naturalsolution is to increase the address space. The 128-bit long addresses were selected despite moreaggressive proposals put forward during the development of IPv6. One might find 2128 or340,282,366,920,938,463,463,374,607,431,770,000,000 addresses to be excessive. However, there wasa time, not many years ago, when the same was thought of the IPv4 address space. On the other hand,one could argue that "the bigger the better." However, that line of reasoning should take intoconsideration the impact longer addresses have on system performance. A system using a 64-bit CPU,bus, or memory structure can process both the source address (SA) and destination address (DA) IPv4addresses in one pass; whereas for IPv6 addresses, the same requires four passes.
36 Part I: Implementing IPv6 Services
36 Part I: Implementing IPv6 Services
The IPv6 address can be represented as a string of 0s and 1s. This representation is a rather long string,but it is the way favored by computers. A hexadecimal representation shortens the 128-bit string to 32characters, and it appeals to programmers. This representation is still long enough to make it hard toremember, so the string of 32 hexadecimal characters was given some structure and segmented into 8groups of 4 characters (or 16 bits) separated by a colon (:). The decimal representation, like the oneused by IPv4 that everyone is familiar with, was not adopted by IPv6.
Two additional rules were introduced to further optimize the IPv6 address representation:
The elimination of leading 0s Within each group of 16 bits between two colons, the leading 0scan be eliminated. This means that you can write :00A1: as :A1: (see Figure 2-1).
Figure 2-1. IPv6 Address Representation
[View full size image]
•
The elimination of consecutive 0s You can collapse consecutive all-0 groups of 16 bits betweenconsecutive colons. In this case, :0000:0000:0000: becomes :: (see Figure 2-1).
•
These rules must lead to a unique compressed representation of an address. For this reason, theconsecutive-0s rule can be applied only once. It is incorrect to compress the address in the Figure 2-1example to 2001::A1::1E2A. Someone looking at this address would not know whether the first ::stands for 2 or 3 groups of 16 zero bits.
It is important to mention that : is a meaningful character in the Uniform Resource Locator (URL),where it separates the port number from the address. To avoid confusion, RFC 2732 suggests to enclosethe IPv6 address in a URL in brackets, as shown in Example 2-1.
Note that the preceding address is shown with an optional port ID of 7878.
Part I: Implementing IPv6 Services 37
Part I: Implementing IPv6 Services 37
IPv6 Address Architecture
Understanding the IPv6 address representation enables us to discuss the IPv6 addressing architecturedefined in RFC 3513. Three types of IPv6 addresses have been defined:
Unicast Identifies a single node, and traffic destined to a unicast address is forwarded to asingle node.
•
Multicast Identifies a group of nodes, and traffic destined to a multicast address is forwarded toall the nodes in the group.
•
Anycast Identifies a group of nodes, and traffic destined to an anycast address is forwarded tothe nearest node in the group.
•
All of these address types were present in IPv4, along with broadcast addresses. Broadcast traffic wasshown to be too resource intensive (during regular operation as well as during broadcast storms), soIPv6 ignores it and uses multicast addresses instead.
IPv6 Unicast Address
The fundamental function of a network is to provide unicast reachability for the hosts connected to it.All other services it provides rely on this unicast infrastructure. For these reasons, regardless of the IPversion, unicast addresses play a critical role in any network.
A flat, structureless address space would require routers to keep track of every single host's location,leading to scalability issues. This problem can be resolved through address aggregation, groupingmultiple addresses under a common representation. To facilitate this process, IP addresses aresegmented in a network portion that identifies a logical group of hosts and a host portion that identifiesthe host within the group. Hosts are aggregated under the same network or prefix. IPv4 demonstratedthe constraints of a class-based addressing architecture, so IPv6 allows variable lengths for the networkportion of its addresses. This approach requires the length of the prefix to be identified by adding/(number of bits) to the address.
To maintain some parallelism between the addressing structure of the two IP versions, we used theIPv4 terminology host portion up to this point in the context of IPv6 addresses. IPv6, however, prefersto identify the interface of a host within a prefix rather than the host itself, which could have multipleinterfaces. For this reason, the IPv6 addresses are segmented into a prefix or network portion and theinterface identifier.
Example 2-2 shows the network and interface identifier of an IPv6 address.
Example 2-2. Identifying the Network and Interface ID of an IPv6 Address
Address: 2001:0:0:A1::1E2A/64Network portion: 2001:0:0:A1Interface identifier in non-compressed format: :0:0:0:1E2AInterface Identifier in compressed format: ::1E2A
RFC 3513 leaves no room for doubt about what the interface ID should be: "For all unicast addresses,except those that start with binary value 000, interface IDs are required to be 64 bits long and to beconstructed in Modified EUI-64 format." The rule reveals the intent to maintain a globally uniquecharacter for the interface ID whenever possible. You can generate an interface ID in many differentways:
38 Part I: Implementing IPv6 Services
38 Part I: Implementing IPv6 Services
Build one from the layer 2 address in the modified EUI-64 format. For the interface ID portionof the network, the seventh high-order bit of the EUI-64 format defines a local scope when setto 0 and a global scope (globally unique) when set to 1. Different mechanisms are defined foreach media type to build the complete interface ID in the modified EUI-64 format (see thereferences in the section "IPv6 and Data-Link Technologies" later in this chapter).
•
Autogenerate a random address as defined in RFC 3041. This assignment mechanism wasdeveloped mainly to limit the exposure of a globally reachable address and to increase privacy(see Chapter 9, "Securing IPv6 Networks").
•
Acquire the interface ID via DHCPv6.• Manual configuration.• Cryptographically generated addresses (CGAs) based on RFC 3972 through a hash thatincludes a public key. This method of generating an interface ID provides added security andenables address authentication. The Neighbor Discovery process described later in this chapteris secured with the help of CGAs.
•
The network portion of the address is further refined in the case of IPv6 to integrate the concept ofscope.
The scope identifies a network domain, be it physical or logical. Being able to easily recognize thescope of an IP stream enables a network to better manage its resources by containing the traffic withinthe relevant domain and by applying policies relevant to that scope. The IP address is an essentialelement in making layer 3 forwarding decisions, so it should reflect the scope. Hosts would use theappropriate IP SA and DA for the scope of their communication.
In IPv6, the unicast address format reflects three predefined scopes, as follows:
The link-local scope Identifies all hosts within a single layer 2 domain. The unicast addressesused within this scope are called link-local addresses.
•
The unique-local scope Identifies all devices reachable within an administrative site or domainthat typically contains multiple distinct links. The unicast addresses used within this scope arecalled unique-local addresses (ULAs).
•
The global scope Identifies all devices reachable across the Internet. The unicast addresses usedwithin this scope are called global unicast addresses (GUAs).
•
These scopes are hierarchical, as shown in Figure 2-2. The global scope is larger than the local (site)scope, which in turn includes the link scope.
Figure 2-2. Unicast Address Scoping
Part I: Implementing IPv6 Services 39
Part I: Implementing IPv6 Services 39
The link and global scopes represent the two extreme cases, the smallest and the largest scopes. Thisdistinction makes it easier to define them. RFC 3513 identifies a site-local scope that fits logicallybetween the link and global scopes, although its definition is open for interpretation. A site can meandifferent things to different people. It can be a corporate network, a geographically constrained portionof a corporate network, or simply an administered domain within a corporate network. Because IPv6addresses are structured based on scope, the ambiguity in site definition increases the complexity ofIPv6 features and implementations. The original definition of the site scope also left the door open forthe use of nonunique site-local addresses with their drawbacks (discussed later in the section). For thesereasons, on March 20, 2003, the IETF IPv6 working group deprecated the site-local scope and thecorresponding IPv6 address type. Figure 2-2 emphasizes this point.
With habits being hard to break, especially when they prove to be operationally effective, the site-localscope and the site-local addresses did not go away quietly. Enterprises are accustomed to the safety andthe advantages of a site-relevant, private addressing schemethe good old 10.x.y.z networkso theypressed for the development of an alternate solution to the site-local address. To meet these demands,the IETF IPv6 working group defined a new scope and address type called unique-local, preserving theconcept of a site scope by using local in its name while emphasizing the "nearly" uniqueness of theaddressing used within the site.
Depending on an IPv6 node's complexity, it may or may not be aware of the scope information carriedwithin the structure of a unicast address. Routers, however, must be aware of scoping to a certaindegree because they have to keep traffic within the scope of its destination or source address. Becausehosts typically communicate within more than one scope, interfaces have an address for each of thescopes used.
Embedding the scope information into the network portion of the IPv6 address adds to its complexity.The subsequent sections discuss the details of the actual implementation of scopes in unicast addresses.
Link-Local Addresses
When an IPv6-enabled node comes online, each interface is provided by default with a layer 3 addressthat can be used for communication exclusively with other hosts on the same link. The local linkdefines the scope of these addresses, so packets that have them as SA or DA should never be routed toother links. These addresses are called link-local. They are used for on-link communication as well aslink operation processes such as finding neighbors or routers.
Figure 2-3 shows the structure of link-local addresses. A link-local address is made of a networkportion of fixed format FE80::/10, where the high-level 10 bits are 1111 1110 10, and the subsequent54 bits are 0.
Figure 2-3. Link-Local Address Structure
[View full size image]
40 Part I: Implementing IPv6 Services
40 Part I: Implementing IPv6 Services
As mentioned earlier, in IPv6 the interface identifier terminology is used instead of the host portion ofthe address, as shown in Figure 2-3. Example 2-3 shows the link-local address of an Ethernet interfacewith the interface ID generated based on the layer 2 MAC address.
Example 2-3. Link-Local Address of an Ethernet Interface
Layer 2 MAC Address: 0004.6d7f.7c1aEUI-64 Interface Identifier generated from the MAC Address (using the process shown in Figure 2-13 later in this chapter): 204:6DFF:FE7F:7C1ALink-Local Address: FE80::204:6DFF:FE7F:7C1A
Note
From a layer 3 standpoint, the link is the elemental domain, implying it does not have an internalhierarchy. This explains the flat structure of the link-local addresses.
It is important to note the fact that the link-local address, by its nature and format, is independent of theoverall addressing scheme used in a network. This is consistent with its scope; the link-local address isnot meaningful outside the link. For this reason, link local communication is not impacted duringnetwork renumbering. Its perennial property is leveraged by various protocols. Routers advertise theirlink-local address to all nodes on the link (see the "Neighbor Discovery" section later in this chapter),thus enabling them to communicate with a gateway regardless of the global unicast addressing scheme.This property of the link-local address is also actively leveraged in network design. Link-localaddresses are used to identify a next hop whenever possible (a Border Gateway Protocol [BGP]neighbor, for example).
Unique Local Unicast Address
The concept of site scope can easily be mapped to that of a private administrative domain whereaddressing does not have to obey any global rules. The IPv6 addresses assigned to this scope as definedin RFC 3513 were called site-local, and they did not have to be unique. Their resemblance to the IPv4private address space was a reminder of the drawbacks of such an approach (see RFC 3879). Some ofthe arguments against the use of site-local addresses are as follows:
Application issues Applications have problems when the site-local addresses are carried inpayload outside the site. A good example of this is the case of a client/server application thatrelies on the addresses of each side, which are on different sites. The address overlap betweensites can confuse the server with respect to the location of the client. Attempts to deal with
•
Part I: Implementing IPv6 Services 41
Part I: Implementing IPv6 Services 41
address overlap by adding a site identifier to the site-local addresses led to compleximplementations. It is difficult for network nodes to keep track of all site identifiers, especiallyin the case of nodes multihomed over multiple sites.
Applications generally do not have a sense of scope, and they often leak private addresses, suchas site-local, outside the private network. Leaks between sites with the same addressing canlead to routing or DNS problems.Routing and Forwarding Issues The nonunique character of site-local addresses would forcerouters to have to track the prefix of an interface and the site it belongs to.
Nonunique site-local addresses make it difficult to interconnect discontiguous elements of asite over intermediate networks. Tunneling becomes necessary in such circumstances.
Multi-sited routers have to base their forwarding decision not only on the destination addressbut on the incoming interface as well to contain the traffic within the proper site.
•
In its drive to reestablish the original uniform and global structure of the Internet, IPv6 couldtheoretically live without the concept of a site. However, practical considerations dictate the need toidentify scopes smaller than the global one. Enterprises in particular have an understandable fondnessfor identifying the boundaries of their networks. For these reasons, the deprecated site-local scope andaddresses had to be replaced by a better-defined concept that could handle the concerns mentioned. Thenew concept is that of a unique-local scope and the corresponding unique-local addresses.
Figure 2-4 shows the format of these addresses. The unique-local unicast addresses are fullystandardized in RFC 4193.
Figure 2-4. Unique-Local Unicast Address Format
[View full size image]
The portion of the unicast address space reserved for unique-local addresses (ULAs) is FC00::/7.Figure 2-4 shows the structure of a ULA with the following elements:
L identifies the assignment policy. Only value 1 (FD00::/8) is currently in use designating alocal assignment.
•
Global ID is a 40-bit identifier that ensures the global uniqueness of the address. It is generatedpseudo-randomly and must not be sequential. Because ULAs should not be globally routed,they do not need to be aggregated, so sequential global IDs are not necessary.
•
Subnet ID gives the administrator of the local domain a resource that can be used to define ahierarchical addressing plan within the site.
•
Interface ID has the same meaning for all unicast addresses, and it is 64 bits long in themodified EUI-64 format.
•
42 Part I: Implementing IPv6 Services
42 Part I: Implementing IPv6 Services
ULAs have to be used within the confines of a predefined domain that represents the local scope ofthese particular addresses. Traffic using ULAs as either SA or DA should not be allowed to cross theboundaries of the domain. ULAs make it easy to interconnect distinct local domains because there areno address collisions. Discontiguous site topologies are easier to manage. Routers connected tomultiple sites can distinguish between them solely based on the address, thus avoiding the need foradditional labels. These examples underline the benefits of the unique-local addressing versus thesite-local addressing.
Global Unicast Address
The global unicast addresses are defined for use across the IPv6 Internet. They are globally unique andglobally routable. The IPv6 addresses reserved for global scoped communication are identified by theirhigh-level 3 bits set to 001 (2000::/3), as described in RFC 3587.
IPv6's primary goal to provide plenty of globally accessible addresses is accomplished with the use ofmore address bits. The additional length could come at a cost by impacting routing processes throughlonger lookups, significantly larger routing tables, and larger routing updates (because many morenetworks are possible than with IPv4). Add to this the likely possibility that IPv6 networks are expectedto have two or more coexistent addressing schemes and it becomes clear that IPv6 routers will needsome help. One way to provide the needed relief is to implement and enforce strong rules on prefixaggregation. Such rules and policies would reduce the size of the routing table and the length of most ofthe prefixes populating them.
A lot of effort has been placed on developing a flexible structure for the GUAs that facilitates easyaggregation. Several attempts were made, starting with RFC 2373, to enforce a granular addressstructure reflecting various levels of aggregation. In the end, it was decided to enforce properaggregation through rigorous allocation policies and settle for a simpler address structure, as specifiedin RFC 3587 and shown in Figure 2-5.
Figure 2-5. Global Unicast Address Structure
[View full size image]
The components of the global unicast address are as follows:
Global routing prefix A service provider is assigned a portion of this prefix by the InternetAssigned Numbers Authority (IANA), and it then allocates a subspace to its customers. Itslength is 48 bits or shorter based on the RFC 3177 recommendations.
•
Subnet ID An organization receives a prefix from its service provider where the global routingprefix identifies the service provider (SP) and the organization inside the SP, and the subnet IDidentifies the organizational structure of its network.
•
Interface ID The low-order 64 bits of the address are used to identify the interfaces of nodes ona link.
•
Part I: Implementing IPv6 Services 43
Part I: Implementing IPv6 Services 43
Note
Global unicast addresses are likely to coexist with other types of unicast addresses on a given interface.For example, users within an enterprise need to exchange information within the private intranet andwith resources on the Internet. This means that a host's interface within a private network could beassigned two addresses, one to be used to communicate with other hosts and resources within theprivate network (possibly a unique-local) and another to be used to communicate with hosts andresources outside the private network (global unicast). For operational and management purposes, acorrelation between the elements of the various address types on an interface might make sense. In thisexample, the GUA and the ULA might use the same interface ID or even the same subnet ID.
Address allocation policies define the globally unique IPv6 address hierarchy. For this reason, it isimportant to briefly review them at this time.
IPv6 Unicast Address Allocation
IANA is in charge of managing the IPv6 address space. Table 2-1 summarizes the assignments, at thetime of this writing, from the global unicast address pool.
Table 2-1. Assigned IPv6 Unicast Addresses
Prefix (Hex)Prefix(Binary) Description
2001::/16 0010000000000001
IPv6InternetARIN,APNIC, RIPENCC, LACNIC
2002::/16 0010000000000010
6 to 4 transitionmechanisms
2003::/16 0010000000000011
IPv6InternetRIPENCC
2400:0000::/19
2400:2000::/19
2400:4000::/21
0010010000000000
IPv6InternetAPNIC
2600:0000::/22
2604:0000::/22
2608:0000::/22
260C:0000::/22
0010011000000000
0010011000000100
00100110
IPv6InternetARIN
44 Part I: Implementing IPv6 Services
44 Part I: Implementing IPv6 Services
00001000
0010011000001100
2A00:0000::/21
2A01:0000::/23
0010101000000000
0010101000000001
IPv6InternetRIPENCC
3FFE::/16 0011111111111110
6 Bone
IANA is currently allocating unicast addresses from all the IPv6 Internet domains identified in Table 2-1.
After IPv4's transition from class-based to classless addresses, registries started to implement a hierarchicalapproach to address allocation. Larger address space is assigned to organizations (ISPs, governments, researchnetworks, and so on), who in turn assign smaller pieces to their customers. This approach allowed forhierarchical routing, which is credited with a significant reduction in the size of the routing tables in corerouters. A similar yet better-defined and stricter approach was adopted for IPv6. Earlier complex structuringof the IPv6 prefix in fields such as Top Level Aggregation and Next Level Aggregation has been replaced bythe simpler format described in this section. IPv6 global unicast address hierarchy is enforced through IANA'sallocation policy rather than fitting a predefined address format. Figure 2-6 exemplifies the address-allocationprocess for the 2001::/16 pool. IANA provides a prefix no longer than 32 bits to the Regional InternetRegistries (RIRs). The current RIRs are as follows:
African Network Information Center (AfriNIC)• Asia Pacific Network Information Center (APNIC)• American Registry for Internet Numbers (ARIN)• Regional Latin-American and Caribbean IP Address Registry (LACNIC)• Réseaux IP Européens (RIPE NCC)•
Figure 2-6. IPv6 Prefix-Allocation Process
Part I: Implementing IPv6 Services 45
Part I: Implementing IPv6 Services 45
The RIR allocates pieces of the prefix it received from IANA to National Internet Registries (NIRs; wherepresent), to Local Internet Registries (LIRs), or Internet service providers (ISPs). These allocations arecurrently in the range of 32 to 35 bits in length.
ISPs allocate prefixes to their customers (enterprises or residential users).
As shown in Figure 2-6, each organization is assigned a prefix by the one above it and in turn is assigningprefixes to the one below it. Thus, each organization (IANA, RIR, NIR, LIR, and ISP) represents anaggregation boundary.
ISPs and LIRs keep track of the usage of their allocations with the help of the same metric used for IPv4, thehost density (HD) ratio (defined in RFC 3194). ISPs/LIRs have to allocate prefixes in a way that preventssegmentation and allows for optimal use of aggregation. Such best practices enable them to make the most outof their address space. When justified, ISPs/LIRs can go back to the RIRs to request more allocations.
You can find a list of allocated prefixes from both the 2001:: and 3FFE:: space athttp://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/networks/#hier. Figure 2-7 presents a snapshot of this informationfor the sole purpose of exemplifying the allocation policies described in this section. NTT/VERIO is a serviceprovider with global coverage, so it acquires prefixes from various RIRs. This example shows its2001:218::/32 allocation received from APNIC. One of its customers is the University of Leipzig, which wasassigned the 2001:218:A20::/48 prefix. The university allocated a subnet, 2001:218:A20:FFFD::/64, to one ofits departments. It is interesting to note that a more practical allocation could be for NTT/VERIO to assignthis European university a prefix from its RIPE NCC allocation 2001:728::/32.
IPv6's method of implementing address hierarchy through allocation policies leads to a subtle but importantdeparture from the traditional IPv4 address-management concepts. At the time of this writing, in the case ofIPv6, an enterprise no longer owns its global address space. The address space it is using is a subset of theirISP's allocation. This means that an enterprise will have to go through network renumbering every time itchanges ISPs. Despite IPv6's features that make renumbering easier, this process would carry an operationalimpact.
Because IPv6 interfaces can support multiple unicast addresses, the migration from one ISP to another onecan be done through a transient period where the prefixes from both old and new ISPs coexist on the customernetwork. Operational experience for this type of situation still needs to be developed to evaluate the impact onmedium- and large-size enterprises when switching between IPv6 ISPs. Nevertheless, as enterprises becomeinterested in IPv6, this aspect of address management is often listed as a major concern. For this reason, large,multinational enterprises started to get involved in policy meetings of the Internet registries, lobbying forchanges to the allocation mechanisms.
Special-Use Addresses
At last, a small set of unicast addresses have been defined for special use. They do not carry a scope, so theyare discussed independently of the other unicast addresses.
Two basic addresses carry IPv6 operational significance:
The unspecified address is not assigned to any interfaces. However, it is used as an SA by devices thatdo not have an IPv6 address or their IPv6 address has not been yet proven to be unique within thelocal link. The unspecified IPv6 address has all 128 bits set to 0. It can be represented as0:0:0:0:0:0:0:0, or as :: in compressed form.
•
The loopback address is used by every node to refer to itself, and it is similar to the 127.0.0.1 addressin IPv4. In IPv6, the loopback address has all the 127 leading bits set to 0, and the last bit is 1. It canbe represented as 0:0:0:0:0:0:0:1, or as ::1 in compressed form.
•
The other two special address types relate to the coexistence of IPv4 and IPv6. Linking the two address spacesis important to support various aspects of this coexistence. Two mechanisms were developed to map IPv4addresses into IPv6 addresses:
The IPv4-compatible IPv6 address was defined to be used for dynamic tunneling and is built byadding the IPv4 address to 96 bits set to 0. This address type was deprecated and it is no longer used.
•
The IPv4-mapped IPv6 address is used to represent the address of an IPv4 node in an IPv6 format.The IPv4-mapped IPv6 address is built by adding the IPv4 address to 80 bits set to 0 followed by 16bits set to 1.
•
Example 2-4 shows the IPv4-compatible and the IPv4-mapped IPv6 addresses corresponding to the IPv4address 192.100.10.1.
Example 2-4. Examples of IPv4-Compatible and IPv4-Mapped IPv6 Addresses
IPv4 Address: 192.100.10.1IPv4-compatible IPv6 address: 0:0:0:0:0:0:192.100.10.1 or in compressed form: ::192.100.10.1 or in full Hex form: ::C064:0A01IPv4-mapped IPv6 address: 0:0:0:0:0:FFFF:192.100.10.1 or in compressed form ::FFFF:192.100.10.1 or in full Hex form: ::FFFF:C064:0A01
Table 2-2 summarizes the representation of these special addresses.
Table 2-2. Special-Use Addresses
Address Type
IPv6 Address
Compressed Format
Unspecified address
0:0:0:0:0:0:0:0
::
Loopback address
0:0:0:0:0:0:0:1
::1
IPv4-compatible IPv6 address
0:0:0:0:0:0:IPv4
::IPv4
IPv4-mapped IPv6 address
0:0:0:0:0:FFFF:IPv4
::FFFF:IPv4
48 Part I: Implementing IPv6 Services
48 Part I: Implementing IPv6 Services
IPv6 Anycast Addresses
When the same unicast address is assigned to multiple interfaces, typically belonging to different nodes, itbecomes an anycast address as specified in RFC 3513. Because anycast addresses are structurallyindistinguishable from unicast addresses, a node has to be configured to understand that an address assignedto its interface is an anycast address. A packet with an anycast DA is routed to the nearest interface configuredwith it. An anycast address cannot be used as the SA of a packet. Anycast is often used to virtually replicateimportant network resources, such as Domain Name System (DNS) root servers, web servers, and multicastrendezvous points (RPs), thus providing a level of redundancy and load sharing. IPv6 went beyond thisconcept that is currently used by IPv4 in that it defined a set of reserved addresses for each unicast prefix tofacilitate the future use of anycast.
The subnet-router anycast address is defined by RFC 3513 for every prefix as the address with the interfaceID set to 0. A router has to support the subnet-router anycast addresses for all the prefixes configured on itsinterfaces. A packet destined to such an address will be delivered to the nearest router that has an interfacewith that prefix.
RFC 2526 defines an additional set of anycast addresses reserved for a given prefix. Figure 2-8 shows thestructure of these anycast addresses.
Figure 2-8. IPv6 Reserved Anycast Address Format
[View full size image]
The address format makes clear the intent of reserving the high-order addresses of a subnet for anycast use.This approach was motivated by the need to avoid conflicts with other reserved addresses. Considering thegroup scope of the anycast address, it also makes sense that the high-order bit, which would represent theindividual/group bit of a mapped MAC address, is set to 1 (group). In the case of unicast prefixes with EUI-64interface IDs, the universal/local bit is set to 0 to indicate that the interface ID for the anycast address is notglobally unique. The Anycast ID field shown in Figure 2-8 can take the following values: 0 through 125,127(00-7D, 7F) are reserved; ID 126 (7E) is the only one currently in use for the Mobile IPv6 (MIPv6) homeagent's anycast addresses.
Note
MIPv6 provides a host with a mechanism to discover the address of one of his home agents (HAs). The hostcan attempt to register to the home agent's anycast address (described in this section) hosting its home prefix.
Part I: Implementing IPv6 Services 49
Part I: Implementing IPv6 Services 49
One of the HAs will receive the request, reject the registration, and instead reply to the host with a list of theactual addresses of the HAs it can use.
The anycast addresses are allocated from the unicast address space. There is little operational experience withthis address type, although a few usage examples are provided in RFC 3513.
IPv6 Multicast Addresses
Multicast received its well-deserved attention during the development of IPv6. It replaced broadcast addressesin the control-plane messages, thus becoming a critical part of IPv6 network operation. The larger addressspace provides plenty of globally unique multicast group addresses to facilitate the deployment of multicastservices.
A multicast address identifies a group of interfaces. A packet with a multicast destination address is deliveredto all the group members. It is important to remember that multicast addresses should not be used as SAs. TheIPv6 multicast addresses have their top 8 high-order bits set to 1 (FF00::/8) and the format shown in Figure2-9.
Figure 2-9. IPv6 Multicast Address Format
[View full size image]
Three of the four bits in the flag are currently in use:
The low-order bit T defined in RFC 3513 is set to 0 for permanently assigned multicast addresses thatare assigned by IANA. The T bit is set to 1 for nonpermanently assigned multicast addresses.
•
The P bit is defined in RFC 3306, and it indicates whether the multicast address is built based on aunicast prefix (set to 1) or not (set to 0).
•
The R bit defined in RFC 3956, if set to 1, indicates that the multicast group address contains theunicast address of the RP servicing that group.
•
The remaining fourth flag bit is reserved for future use and currently is set to 0.
50 Part I: Implementing IPv6 Services
50 Part I: Implementing IPv6 Services
Note
The P bit set to 1 indicates that the multicast address is built from a unicast address. Because the unicastaddress is considered to have a limited lifetime, the resulting multicast address cannot be permanentlyassigned. This means that a P bit set to 1 requires the T bit to be set to 1, too.
Scoping is a powerful feature built in the IPv6 multicast address architecture. It provides routers with theinformation needed to contain the multicast traffic within the appropriate domain. Table 2-3 lists the valuesthat are currently defined for the 4-bit Scope field shown in Figure 2-9.
Table 2-3. Defined IPv6 Multicast Scopes
Scope (Hex)
Scope (Binary)
Description
1
0001
Interface-local scope
2
0010
Link-local scope
3
0011
Subnet-local scope
4
0100
Admin-local scope
5
0101
Site-local scope
8
1000
Part I: Implementing IPv6 Services 51
Part I: Implementing IPv6 Services 51
Organization-local scope
E
1110
Global-local scope
Similar to the unicast addresses, the multicast address space has its own elements of special interest, asdescribed next.
Unicast-Prefix-Based Multicast Addresses
GLOP addresses were introduced in IPv4 to provide globally unique IPv4 multicast group addresses toorganizations that own autonomous system numbers (ASNs). The addresses are built based on globally uniqueASNs. RFC 3306 extends this concept and defines a mechanism that generates globally unique IPv6 multicastaddresses based on a unicast prefix, as shown in Figure 2-10.
Figure 2-10. Unicast-Prefix-Based Multicast Address Format
[View full size image]
The reserved bits must be set to 0. The 64 bits provided for the Unicast Prefix field are sufficient based on thestructure of the IPv6 unicast addresses (64 bits are used by the interface ID). The format presented in Figure2-10 suggests that any given IPv6 unicast prefix comes with 232 multicast addresses.
Example 2-5 shows the unicast-prefix-based multicast address generated from the unicast prefix2001:100:abc:1::/64.
Example 2-5. Unicast-Prefix-Based Multicast Address Generated from an IPv6 Unicast Prefix
The scope of the unicast-prefix-based multicast address should not exceed that of the embedded unicastprefix.
Note
The group addresses used in Source Specific Multicast (SSM) deployment models (see Chapter 6, "ProvidingIPv6 Multicast Services") were defined as a subset of the unicast-prefix-based multicast addresses, where thePrefix Length and the Network Prefix fields are set to 0 (see Figure 2-11).
Figure 2-11. PIM-SSM Multicast Group Addresses
[View full size image]
Solicited-Node Multicast Addresses
The solicited-node multicast address provides a mechanism to contact a host on the local-link when knowingonly its layer 3 unicast address. This address type is generated for each unicast and anycast prefix assigned toan interface. The address format is FF02::1:FF00:0000/104, where the low-order 24 bits are the same as theunicast or anycast address that generated it. It represents a deterministic way to identify a local-link multicastgroup to which a host with a given IPv6 unicast address is listening. If not all the information needed toestablish unicast connectivity to the host (the MAC address) is available, the destination can still be reachedvia multicast sent to its solicited-node multicast address.
Fundamental IPv6 control-plane processes, such as layer 2-to-layer 3 address mapping and Duplicate AddressDetection (DAD) use this type of addresses (see the "Neighbor Discovery" section later in this chapter).Example 2-6 builds a solicited-node multicast address based on the format shown in Figure 2-12.
Figure 2-12. Solicited-Node Multicast Address Format
[View full size image]
Part I: Implementing IPv6 Services 53
Part I: Implementing IPv6 Services 53
Example 2-6. Generating a Solicited-Node Multicast Address
The solicited-node multicast address has a link-local scope. It is used for control-plane functions only withinthe local link.
Note
Based on the structure of the solicited-node multicast address, it is clear that the same solicited-node multicastaddress represents multiple IPv6 unicast addresses. Considering the large addressing space and assuming thatthere is no address assignment policy that favors the 40 high-order bits of the interface ID, thisoversubscription of the solicited-node multicast address should not be significant.
IPv6 Multicast Address Allocation
IPv6 multicast addresses are allocated by IANA based on the rules documented on its website:
IANA identifies two multicast address types in its allocation policy:
Variable-scope multicast addresses These addresses are similar across all scopes, but they representdistinct groups. They are reserved for certain types of services or applications. A good example isNTP (Network Time Protocol), which has a multicast address of FF0X:0:0:0:0:0:0:101, where Xmasks the address scope.
•
Fixed-scope multicast addresses These addresses have a certain meaning only within the scope theyare defined in. This type of addresses is important in the basic operation of IPv6. For this reason, afew common ones are listed in Table 2-4.
•
Table 2-4. Example of Fixed-Scope IPv6 Multicast Addresses
One part of the multicast address was not talked about too much in this section, the group ID. In theory, thegroup ID can take any value as long as the rest of the address fits the structure described in the earliersections. The larger multicast address space raises the concern of significant oversubscription of layer 2addresses (which are much smaller in size) mapped to the IPv6 multicast groups. To minimize thisover-subscription, group ID allocation guidelines were defined in RFC 3307, and they are shown in Table 2-5.
Table 2-5. Group ID Allocation Rules
Multicast Address Type
Range
Allocation Determined By
Permanent multicast addresses
0x000000010x3FFFFFFF
Expert review
Permanent multicast group ID
0x400000000x7FFFFFFF
Expert review
Dynamic multicast addressesserver allocation
0x800000000xFFFFFFFF
Server allocation
Protocol
Dynamic multicast addresseshost allocation
0x800000000xFFFFFFFF
RFC 1750 or 32 bit
56 Part I: Implementing IPv6 Services
56 Part I: Implementing IPv6 Services
Pseudo-random
The low end of the group ID value is reserved for the permanent multicast addresses under IANAmanagement. This is consistent with the examples shown earlier in Table 2-4. Permanent multicast group IDis used as a globally unique identifier of a service (such as NTP). The high-end range of group ID values isreserved for dynamically allocated addresses, regardless of mechanism. However, having distinct ranges forthe server and host allocations does make it easier to identify the multicast addresses obtained through amanaged service.
Some of these allocation rules might become irrelevant in the future if other mechanisms are implemented tomitigate this oversubscription.
IPv6 and Layer 2 Addressing
IPv6 addresses correlate with layer 2 addresses in two ways of interest to this discussion. The first way is IPv6specific and provides the mechanism of building an interface ID from layer 2 addresses. The second way iscommon for both IPv4 and IPv6 and provides the mechanism for mapping an IP multicast address to a layer 2multicast address.
EUI-64 Interface Identifiers
IEEE specifies the format of the EUI-64 identifiers. To make such an identifier an IPv6 interface ID, the onlything that has to be done is to flip the sixth bit in Internet standard order (universal/local bit).
The IEEE specification also provides a mechanism for generating a 64-bit EUI-64 identifier from a 48-bitlayer 2 address. With such a mechanism in place, a correlation can be established between the MAC addressof an interface and the interface ID portion of IPv6 addresses. This type of ID is used, for example, by defaultby the link-local addresses on Cisco routers.
Figure 2-13 shows the two-step process of generating an IPv6 interface ID from a MAC address. The first stepis to create an EUI-64 identifier; the second step is to modify it to make it an IPv6 interface ID.
Figure 2-13. Generating an Interface ID from a MAC Address in the Modified EUI-64 Format
Part I: Implementing IPv6 Services 57
Part I: Implementing IPv6 Services 57
Layer 2 Multicast Addresses
Similar to IPv4, IPv6 is currently mapping layer 3 multicast addresses into layer 2 addresses. For multicastIPv6 traffic, the first 16 high-order bits of the MAC address identify the layer 2 multicast address:3333.XXXX.XXXX. The low-order 32 bits of the IPv6 multicast address are copied into the remainingportion of the MAC address. Figure 2-14 shows an example of this mapping mechanism in the case of asolicited-node multicast IPv6 address.
Figure 2-14. Mapping an IPv6 Multicast Address into a MAC Address
These two address correlation mechanisms are often used in operational networks and are often mentionedthroughout this book.
IPv6 Addresses Required for an Interface
To ensure proper operation of the IPv6 protocol, each IPv6-enabled host must support the following set ofaddresses:
Loopback address• Link-local address• Unicast or anycast addresses if configured• Subscribe to the all-nodes multicast address• Multicast address of all the groups it subscribes to• Subscribe to its own solicited-node multicast address•
Depending on the node type, configuration, and supported protocols, other addresses might be present ormulticast groups might be joined.
A router must support the addresses listed for hosts, as well as the following:
Subnet-router anycast address• All configured anycast addresses• The all routers multicast address•
These addresses are used for both control- and data-plane-relevant traffic.
58 Part I: Implementing IPv6 Services
58 Part I: Implementing IPv6 Services
Configuring IPv6 Addresses in Cisco IOS Routers
This section presents the Cisco IOS router-specific configuration steps that are needed to provision a Ciscorouter interface for IPv6. Example 2-7 presents the process of enabling IPv6 on a router interface andunderlines some of the concepts reviewed in this section.
Example 2-7. Enabling IPv6 on a Router Interface
Router#show interface Gigabit2/0GigabitEthernet2/0 is up, line protocol is up Hardware is WISEMAN, address is 00b0.4a5c.f038 (bia 00b0.4a5c.f038)! Interface MAC address is bolded MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255...Router#configure terminal! Enters configuration modeEnter configuration commands, one per line. End with CNTL/Z.Router(config)#interface Gigabit2/0Router(config-if)#ipv6 enable! Enables IPv6 on Gigabit2/0Router(config-if)#^ZRouter#*Jul 22 22:14:17.833: %SYS-5-CONFIG_I: Configured from console by consoleRouter#show ipv6 interface Gigabit2/0! Displays the IPv6 Properties of Interface Gigabit2/0GigabitEthernet2/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2B0:4AFF:FE5C:F038! The bolded Link-Local address was generated as described in the EUI-64 InterfaceIdentifiers.! MAC = 00b0.4a5c.f038! EUI-64 = 02B0:4AFF:FE5C:F038! Link-Local Address: FE80:: 2B0:4AFF:FE5C:F038 No global unicast address is configured Joined group address(es):
FF02::1! Link-Local All Nodes
FF02::2! Link-Local All Routers
FF02::1:FF5C:F038! The Solicited-Node Multicast address was generated as described earlier in the chapter! MAC = 00b0.4a5c.f038! Last 24 bits = 5C:F038! Solicited-Node Multicast: FF02::1:FF5C:F038 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses.
Note
In Example 2-7, the router was already enabled to run IPv6 with the global command ipv6 unicast-routing. Arouter that is not configured for IPv6 routing will act as a host on each of its interfaces configured for IPv6.Despite not being shown in the example, for optimal forwarding of IPv6 traffic it is important to explicitly
Part I: Implementing IPv6 Services 59
Part I: Implementing IPv6 Services 59
enable Cisco Express Forwarding (CEF) on Cisco routers with the global configuration command ipv6 cef.
Note
The link-local address was automatically generated from the 48-bit MAC address of the interface. This is thedefault behavior of a Cisco router. Cisco IOS commands also enable you to manually configure the link-localaddress.
Example 2-8 presents the process of configuring various types of addresses on the router interface. The resultsof these configuration steps are shown in the output of show ipv6 interface, which displays the IPv6 propertiesof the interface.
Example 2-8. Configuring IPv6 Addresses on a Router Interface
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)#interface Gigabit2/0Router(config-if)#ipv6 address 2001:100:10:1::1/64! IPv6 Global Unicast with configured Interface ID: 2001:100:10:1::1/64Router(config-if)#ipv6 add 2001:100:10:2::/64 eui-64! IPv6 Global Unicast enabled to use the EUI-64, MAC generated Interface IDRouter(config-if)#ipv6 add 2001:100:10:3::1/64 anycast! IPv6 Unicast defined to be Anycast Address: 2001:100:10:3::1/64Router(config-if)#^ZRouter#show ipv6 interface Gigabit2/0GigabitEthernet2/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2B0:4AFF:FE5C:F038 Global unicast address(es): 2001:100:10:1::1, subnet is 2001:100:10:1::/64! IPv6 Global Unicast Address #1 2001:100:10:2:2B0:4AFF:FE5C:F038, subnet is 2001:100:10:2::/64 [EUI]! IPv6 Global Unicast Address with the Interface ID generated in the modified EUI- 6e format based on the Interface MAC. 2001:100:10:3::1, subnet is 2001:100:10:3::/64 [ANY]! IPv6 Anycast Address Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:1! The Solicited-Node Multicast address corresponding to IPv6 address #1 FF02::1:FF5C:F038! The Solicited-Node Multicast address corresponding to IPv6 address #2 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses.
Note
60 Part I: Implementing IPv6 Services
60 Part I: Implementing IPv6 Services
Any number of global IPv6 unicast addresses can be configured on an interface. Remember: Unlike IPv4,where the latest configured address overwrites the existing one, in IPv6 the new address is just added to theexisting one. If the intent is to remove the current address, you must do so explicitly.
IPv6 Addressing Architecture at a Glance
The IPv6 addressing architecture is, for the most part, settled in its final structure. Some of its aspects are stillbeing worked on (for example, the unique-local unicast address). Despite these ongoing tweaks, at its currentlevel of development and standardization, IPv6 addressing is mature enough for the deployment of large IPv6networks. Table 2-6 summarizes the information presented in this section for quick reference.
Table 2-6. IPv6 Addressing Summary and Significant Address Allocations
Prefix (Hex)
Prefix (Binary)
Description
Unicast Special Use
::
All 0s
Unspecified
::1
::0000 0000 0000 0001
Loopback
::A.B.C.D
::[IPv4 address in binary]
IPv4-compatible IPv6 address (deprecated)
::FFFF:A.B.C.D
::1111 1111 1111
1111:[IPv4]
IPv4-mapped IPv6 address
Unicast Link-Local [1111 1110 1000 0000]
FE80::/10
Part I: Implementing IPv6 Services 61
Part I: Implementing IPv6 Services 61
1111 1110 1000 0000::
Link-local
Unicast Unique-Local [1111 110]
FC00::/7
1111 1100 0000 0000::
Unique-local
FD00::/8
1111 1101 0000 0000::
Unique-local, locally assign
Unicast Global [001]
2001::/16
0010 0000 0000 0001
IPv6 InternetARIN, APNIC, RIPE NCC, LACNIC
2002::/16
0010 0000 0000 0010
6 to 4 transition mechanisms
2003::/16
0010 0000 0000 0011
IPv6 InternetRIPE NCC
2400:0000::/19
2400:2000::/19
2400:4000::/21
0010 0100 0000 0000
IPv6 InternetAPNIC
2600:0000::/22
2604:0000::/22
2608:0000::/22
62 Part I: Implementing IPv6 Services
62 Part I: Implementing IPv6 Services
260C:0000::/22
0010 0110 0000 0000
0010 0110 0000 0100
0010 0110 0000 1000
0010 0110 0000 1100
IPv6 InternetARIN
2A00:0000::/21
2A01:0000::/23
0010 1010 0000 0000
0010 1010 0000 0001
IPv6 InternetRIPE NCC
Anycast
Any unicast address configured on multiple interfaces and identified as anycast
Multicast [1111 1111]
Node-Local Scope
1111 1111 0000 0001
FF01::1
1111 1111 0000 0001::1
All-nodes address
FF01::2
1111 1111 0000 0001::2
All-routers address
Link-Local Scope
1111 1111 0000 0010
FF02::1
1111 1111 0000 0010::1
All-nodes address
Part I: Implementing IPv6 Services 63
Part I: Implementing IPv6 Services 63
FF02::2
1111 1111 0000 0010::2
All-routers address
FF02::5
1111 1111 0000 0010::5
OSPF IGP
FF02::6
1111 1111 0000 0010::6
OSPF IGP DR
FF02::B
1111 1111 0000 0010::B
Mobile agents
FF02::D
1111 1111 0000 0010::D
All PIM routers
FF02::16
1111 1111 0000 0010::16
All MLDv2-capable routers
FF02::1:2
1111 1111 0000 0010::1:2
All DHCP servers
FF02::1:3
1111 1111 0000 0010::1:3
Link-local multicast name resolution
Solicited-Node
1111 1111 0000 0010::1:FFXX:XXXX
FF02::1:FFXX:XXXX
64 Part I: Implementing IPv6 Services
64 Part I: Implementing IPv6 Services
Solicited-node address
Site-Local
1111 1111 0000 1001
FF05::2
1111 1111 0000 1001::2
All-routers address
FF05::1:3
1111 1111 0000 1001::1:3
All DHCP servers
Unicast-Prefix Based
1111 1111 0011
FF3X:0Y [64-bit prefix]:[32-bit group ID]
Xscope; Yprefix length
PIM-SSM Group Addresses
1111 1111 0011
FF3X::[32-bit group ID]
Xscope
Embedded RP Group Addresses
1111 1111 0111
FF3X:0YZZ[64-bit prefix]:[32-bit group ID]
Xscope; Yinterface ID; ZZprefix length
IPv6 Packet Format
The structure of the IP packet header was modified in IPv6. These changes reflect someof the lessons learned from years of operating IPv4, and they have a significant impacton the protocol operation. For these reasons, the IPv6 packet format is briefly reviewedin the next section.
Part I: Implementing IPv6 Services 65
Part I: Implementing IPv6 Services 65
IPv6 Versus IPv4 Basic Header Format
To understand what motivated the choices made with respect to the IPv6 packet headerstructure, it is important to review the structure of its predecessor.
A packet has two components: the header that contains the layer 3 information, and thepayload that carries the data and the upper-layer protocol information. RFC 791 definesthe following fields for the IPv4 packet header:
Version (4 bits) Represents the version of the IP protocol. In this case, the fieldis set to 4.
•
Header Length (4 bits) The length in octets of the packet header.• Type of Service (ToS) (8 bits) This field carries information that enables routersto classify and forward packet in a differentiated manner. It is an importantservice identifier used in implementing quality of service (QoS).
•
Total Length (16 bits) The length in octets of the entire packet, header pluspayload. With 16 bits available in this field, the maximum length of an IPv4packet is 65,535 octets.
•
Identification (16 bits), Flags (3 bits), Fragment Offset (13 bits) These threefields enable IPv4 networks to support packet fragmentation to negotiateforwarding over links supporting various maximum transmission units (MTUs).Fragmentation is done as needed by the routers along the path of the packet.
•
Time To Live (8 bits) It is important to protect a network's resources frompackets that loop due to routing problems. This field is used to count down thenumber of routers that switched the packet. The packet is discarded when thevalue of this field is 0.
•
Protocol Number (8 bits) The Protocol Number lists the upper-layer protocol(TCP, UDP, ICMP, and so on) that is present in the packet payload. Thenumbers that represent these protocols are assigned by IANA(http://www.iana.org/assignments/protocol-numbers).
•
Header Checksum (16 bits) The integrity of the packet header is verified bycomparing the computed checksum with the value listed in this field.
•
Source IPv4 Address (32 bits) The IPv4 address of the node that sourced thepacket.
•
Destination IPv4 Address (32 bits) The IPv4 address of the packet destinationnode.
•
Options (variable length) This field is meant as a placeholder for the informationrelevant to proper handling of the data carried by the packet, information that isnot represented in the other fields of the header. Because of this field, the IPv4header has a variable length, justifying the need for the Header Length field.
•
Padding (variable length) Is used to align the variable-length Options field to the32-bit boundary.
•
Figure 2-15 shows the IPv4 packet header structure.
Figure 2-15. IPv4 and IPv6 Packet Header Structure
The relevancy of the highlighted fields has been re-evaluated in the process ofdeveloping IPv6. The structure of the new header observes several new rules:
Fixed length for the basic header The Options field leads to an IPv4 header ofvariable length (minimum 20 bytes). By contrast, IPv6 has the main headerlength fixed at 40 bytes, a benefit to fast header processing because routers donot have to implement lookup processes that account for variable-lengthheaders. The fixed length makes the Header Length field obsolete. Thefunctionality provided by the options is delivered through extension headers, aconcept described later in the section. The options and padding are also removedfrom the main packet header.
•
Fragmentation is done only by the traffic source Before sending IPv6 traffic, thesource does Path MTU (PMTU) Discovery. It then sends packets at thediscovered PMTU, thus freeing the routers from having to fragment them. Forthis reason, the three IPv4 header fields related to fragmentation (Identification,Flags, and Fragment Offset) become irrelevant in IPv6.
Note
The PTMU Discovery can be processing intensive. It is important to remember,however, that in IPv6 the MTU on any link should not be smaller than 1280bytes, as specified in RFC 2460.
•
Part I: Implementing IPv6 Services 67
Part I: Implementing IPv6 Services 67
Header checksums are eliminated The IP header checksum has to berecalculated by every node switching the packet due to changing Time To Live(TTL) values, thus taxing router resources. Improvements on data-linktechnologies and their 32-bit cyclic redundancy check (CRC) support since theintroduction of IPv4 combined with layer 4 checksums provides sufficientprotection to make the layer 3 header checksum unnecessary. For this reason,the packet Header Checksum was eliminated in IPv6 and is in turn enforced atupper layers. It is important to note the fact that both UDP and TCP willcalculate the checksum on a pseudo-header that contains critical informationfrom the IPv6 header such as SA and DA.
•
Based on these rules, RFC 2460 defines the following IPv6 header fields:
Version (4 bits) IP protocol version, the value is set to 6.• Traffic Class (8 bits) It performs the same function as the Type of Service fieldin the IPv4 header.
•
Flow Label (20 bits) This field identifies a flow and it is intended to enable therouter to identify packets that should be treated in a similar way without theneed for deep lookups within those packets. The specification for this headerfield is presented in RFC 3697. The field is set by the source and should not bechanged by routers along the path to destination.
Note
The Flow Label together with the SA and DA can uniquely identify IPv6 flows.This ID can map in the main header traffic characteristics that are deeper in thepacket, providing routers with the capability to appropriately handle packetswithout the need to look deep into them. The Flow Label can also provide therouter with relevant information (such as TCP/UDP port and so on) that wouldnot be otherwise available because the packet payload is encrypted. This wouldbe a valuable feature when peer-to-peer security is used.
The Flow Label field is unique to IPv6, but it is recognized to be a powerful tooland similar extensions are being proposed for IPv4. Applications are envisionedwhere the field is used just as a tag as well as more complex ones that maintainlabel state on the nodes using a signaling protocol. The Flow Label can be usedwith differentiated services (DiffServ) as well as integrated services (IntServ)and Resource ReSerVation Protocol (RSVP2).
•
Payload Length (16 bits) With the header length fixed at 40 bytes, it is enough toindicate the length of the payload to determine the length of the entire packet.
Note
Note that the extension headers are considered part of the packet payload.
•
Next Header (8 bits) This field expands the functionality of the Protocol Numberin the IPv4 header. It prefaces the information type immediately following thebasic header. This can be an extension header or the upper-layer protocol in the
•
68 Part I: Implementing IPv6 Services
68 Part I: Implementing IPv6 Services
payload.Hop Limit (8 bits) In IPv6, the IPv4 TTL was appropriately renamed Hop Limitbecause it is a variable that is decremented at each hop, and it does not have atemporal dimension.
•
Source IPv6 Address (128 bits) The IPv6 address of the node that sourced thepacket.
•
Destination IPv6 Address (128 bits) The IPv6 address of the packet destinationnode.
•
Figure 2-15 shows the IPv6 header next to the IPv4 header to underline their differencesand similarities. The Flow Label is highlighted because it represents a new functionalityintroduced by IPv6.
IPv6 Extension Headers
The basic IPv6 header is sufficient to perform the functions of simple packet forwardingand ToS-or Flow Labelbased QoS. There is, however, more to end-to-end IPcommunication than what is covered by the basic header capabilities. With the basicheader at a fixed size, IPv6 had to find another way to implement the functionalityoffered by the Options field in IPv4. It does that through the concept of extensionheaders.
Note
In fact, IPv6 offers, through extension headers, more space for option-like information.The IPv4 options are limited to 40 bytes, whereas the IPv6 extension headers are limitedonly by the packet size.
Predefined placeholders for additional information that relates to the packet payload orthe packet handling, the extension headers provide the means to complement in amodular way the functionality of the basic packet header. The format of each extensionheader type supports certain functions. All extension headers, however, are aligned on8-byte boundaries to maintain 8-octet alignment.
Extension headers are chained together as needed. The Next Header field of each headerstarting with the basic one is a pointer to the type of the following header in the chain.The Next Header field of the last extension header in the chain contains the code for theupper-layer protocol in the payload. Figure 2-16 shows an IPv6 packet without extensionheaders and one with extension headers. There is a specific code for each extensionheader type as well as for the upper-layer (UL) protocols.
Figure 2-16. Chaining Extension Headers to the Basic IPv6 Packet Header
[View full size image]
Part I: Implementing IPv6 Services 69
Part I: Implementing IPv6 Services 69
RFC 2460 defines the IPv6 extension headers. You can find detailed descriptions of theextension headers, their format, and functionality in most introductory IPv6 books. Thissection provides just a brief review of this topic.
Hop-by-Hop Options Header
The Hop-by-Hop header (identified by a Next Header field value of 0) is the onlyextension header that has to be processed by all the nodes on the path of the packet otherthan the destination. For this reason, this extension header, when present, always followsthe basic IPv6 header. It is used, for example, to facilitate forwarding of Jumbograms, asdescribed later in this section, or to provide routers with forwarding instructions.
The Hop-by-Hop header may carry multiple options containing other parameters thatshould be used in processing the packet. The options are encoded in Type-Length-Value(TLV) format, as shown in Figure 2-17.
Figure 2-17. TLV-Encoded Options Format
[View full size image]
70 Part I: Implementing IPv6 Services
70 Part I: Implementing IPv6 Services
Every node that receives an IPv6 packet with a Hop-by-Hop extension header willprocess the options. If an option is not understood, an Internet Control Message Protocol(ICMP) error message might be sent to the source.
Note
There is no restriction on how many times an option type shows up in a Hop-by-Hopheader. Not all option types generate ICMP error messages. These characteristics of theoptions can potentially be used in low-bandwidth denial-of-service attacks.
It is important to consider the performance impact of the hop-by-hop processing on therouters.
One use of the Hop-by-Hop extension header is to support the use of large packets. The16-bit-long Payload Length field in the basic header can represent payload lengths nolarger than 65,536 (216) octets.
The Hop-by-Hop extension header contains a 32-bit-long field that can represent largerpackets called Jumbograms. The Payload Length field is set to 0 when the hop-by-hopoptions are used to identify a Jumbogram.
RFC 2711 defines the Router Alert option of the Hop-by-Hop extension header that isused to provide intermediate routers with forwarding instructions. This feature could beused, for example, for resource reservation with RSVP. It is also used in MulticastListener Discovery packets to alert routers that they have to process these packets (seeChapter 6).
Destination Options Header
As the name indicates, the information carried in the Destination Options extensionheader is intended for the packet's destination only. The Destination Options header isused, for example, with MIPv6. Besides the Hop-by-Hop header, the Destination Headeris the only one that also carries options in the same format presented in Figure 2-17. TheDestination Options header is identified by a Next Header field value of 60.
Routing Header
The Routing extension header (identified by a Next Header field value of 43) is used toenforce a certain path for the packet. This path is defined by the source, and is mostlikely different from the one computed by the routing protocols operating in the network.The functionality implemented through the Routing extension header is similar to IPv4's
Part I: Implementing IPv6 Services 71
Part I: Implementing IPv6 Services 71
Loose Source and Record Route option.
The Routing header contains a Type field that defines the precise functionality of theextension header. At the time of this writing, two types have been defined:
Type 0, specified in RFC 2460, identifies a Routing header that contains anordered list of router addresses that must be visited by the packet on the way todestination. Note that each visited router modifies the DA in the basic header tothat of the next router in the list. This way the routers that are not on the Routingextension header list do not need to process the extension header. This providesthe source-routing capability to IPv6.
•
Type 2, specified in RFC 3775, identifies a Routing header used with MIPv6. Itcontains a single unicast address, the address of the home address, and enablesthe corresponding node to forward traffic directly to the mobile node, aforwarding option called route optimization and available only with IPv6 (seeChapter 8, "Advanced ServicesIPv6 Mobility").
•
This is a developing topic, and other types are being proposed (but those have not yetreached RFC status).
Fragment Header
Fragmentation is processing intensive, and it could be taxing on the resources of networkelements. To protect the network infrastructure resources, it was decided that routers inthe path of an IPv6 packet should not perform fragmentation. Before sending the packet,the source must go through the PMTU Discovery process, as described later in thechapter in the section "Internet Control Message Protocol for IPv6." It determines thelargest packet that it can use without fragmentation along the way. Although the routersare saved the fragmentation trouble, the destination still needs to know how toreassemble the received fragments. It will receive these instructions from the source viathe Fragment Options header. The first packet exchanged, however, must contain all theinformation used in forwarding it between the two endpoints: IPv6 basic header and anyextension headers that need to be processed along the way. This is called theunfragmentable part of the original packet.
Note
Two new rules in IPv6 relate to MTU handling: The MTU of a link should not besmaller than 1280 bytes, and routers do not do packet fragmentation. In today'snetworks, these two requirements are not as stringent as they might seem. Links withsmall MTUs are becoming less common, so the MTU of a typical Ethernet host is likelyto be close to the PMTU it will use for most of its communication.
Authentication Header
This header is similar to the IPv4 IPsec Authentication Header defined in RFC 2402. Itprovides packet source authentication and data integrity protection. The AH header isidentified by a Next Header field value of 51.
72 Part I: Implementing IPv6 Services
72 Part I: Implementing IPv6 Services
Encapsulating Security Payload Header
This header is similar to the IPv4 IPsec Encapsulating Security Payload (ESP) headerdefined in RFC 2406. It is identified by a Next Header field value of 50. The ESP andAH extension headers are used the same way as in IPv4.
Mobility Header
RFC 3775 describes this extension header and its use in the communication between themobile nodes, correspondent nodes, and home agents in establishing and managingbindings (for more details, see Chapter 8). It is identified by a Next Header field value of135.
Linking Multiple Extension Headers
The various extension headers are chained based on the information that needs to beprovided to the destination or intermediary hops along with the payload data. Thefollowing set of extension headers Hop-by-Hop, Destination, Routing, Fragmentationcanfollow, for example, a basic IPv6 header. The sequence in which these extension headersare added to the basic header is not random. There is a recommended order in whichextension headers should be chained in an IPv6 packet, but the only strict requirement isfor the Hop-by-Hop (if present) to be ahead of any other extension header type. Table2-7 lists the extension header in the recommended chaining order along with the NextHeader codes that identify them and the codes for three common layer 4 protocols.
Table 2-7. Order in Which Headers Can Be Chained and Their Next Header IDs
Extension headers are an important aspect of IPv6, and their capabilities will be leveraged more and more inoptimizing the operation of production deployments. They make IPv6 easily extensible compared to itspredecessor, and that could prove to be one of its most significant benefits besides the larger address space.The modular concept of the extension headers represents a scalable and improved alternative to thevariable-length Options field in the IPv4 header. At the same time, note that extension headers can posesecurity risks (see Chapter 9, "Securing IPv6 Networks"). The presence of extension headers could alsoimpact packet-forwarding performance the same way options had in the case of IPv4. Routers have to processupper-layer information that now is moved deeper into the packet and would require the processing of theentire extension header chain.
IPv6 and Data-Link Technologies
In conjunction with the analysis of a layer 3 protocol, it is important to analyze its mapping at layer 2 of theOSI model. IPv6 operates over various data-link technologies, as specified in the following RFCs:
Ethernet (RFC 2464), also used on IPv6 over WiFi (802.11).• FDDI (RFC 2467).• Token Ring (RFC 2470).• PPP (RFC 2472).• Generic Packet Tunneling (RFC 2473).• Non Brodcast Multiple Access (NBMA) (RFC 2491).• ATM (RFC 2492).• Frame Relay (RFC 2590).• Dynamic Packet Transport (DPT) and Spatial Reuse Protocol (SRP), defined in RFC 2982, supportIPv6 even though this is not standardized as it is for the other technologies listed.
•
These RFCs (except for DPT/SRP which uses mechanisms similar to Ethernet) also define mechanisms forbuilding the IPv6 Interface ID for each of these media transport types.
The layer 2 PDU format is independent of the transported upper-layer protocol. However, the Protocol IDfield of the layer 2 header indicates the type of layer 3 protocol it carries in the payload. For example, Table2-8 shows the value of this field for several commonly used data-link technologies.
Table 2-8. Example of Frame Header Protocol ID Field Values for IPv6
Data-Link Technology
IPv4 Protocol ID
IPv6 Protocol ID
Ethernet
0x0800 (Ethertype)
0x86DD (Ethertype)
74 Part I: Implementing IPv6 Services
74 Part I: Implementing IPv6 Services
ATM
0x0800
0x86DD
PPP (IPCP)
0x8021
0x8057
Cisco HDLC
0x0800
0x86DD
The frame format, in particular the Protocol ID, is important when layer 2 filtering is used to differentiatebetween IPv4 and IPv6 traffic.
A good understanding of the IPv6 packet structure and the structure of the corresponding layer 2 framing isimportant not only for a better understanding of the protocol operation but also in developing IPv6troubleshooting expertise.
The rest of the chapter presents several important IPv6-specific control-plane mechanisms. To facilitate theirclear description, the subsequent sections are prefaced at this point with a list of relevant terms usedhenceforth:
Node A device running IP.• Neighbors Nodes attached to the same link.• Host a node that is not a router.• Router A node that routes (forward received packets) packets not addressed to itself.• Link-layer address The identifier for an interface at layer 2.• On-link address An IP address that is within the same layer 2 domain or link.• Off-link address An IP address that is on a different layer 2 domain or link.• Next hop IP address of the gateway used to reach the destination. The next hop computed by a nodefor a given destination is one of its neighbor.
•
Internet Control Message Protocol for IPv6
ICMPv6 is an integral part of the IPv6 architecture and must be completelysupported by all IPv6 implementations. It combines functionalities supported in IPv4under different protocols: ICMP (Internet Control Message Protocol version 4),IGMP (Internet Group Membership Protocol), and ARP (Address ResolutionProtocol). ICMPv6 runs over IPv6, unicast, and multicast. As such, it is nonreliable,and cannot be used for features that require reliability. ICMPv6 is described in RFC2463. Table 2-9, lists the RFCs that define ICMPv6 functionalities and the codes
Part I: Implementing IPv6 Services 75
Part I: Implementing IPv6 Services 75
identifying the ICMPv6 types used for these functionalities.
Table 2-9. Comparison Between ICMPv4 and ICMPv6
Namev6Type
v4Type
IPv4RFC
IPv6RFC
Destination Unreachable 1 3 RFC792
RFC2463
Packet Too Big 2 NA RFC2463
Time Exceeded 3 11 RFC792
RFC2463
Parameter Problem 4 12 RFC792
RFC2463
Source Quench NC 4 RFC792
Alternate Host Address NC 6 RFC792
Timestamp NC 13 RFC792
Timestamp Reply NC 14 RFC792
Information Request NC 15 RFC792
Information Reply NC 16 RFC792
Address Mask Request NC 17 RFC950
Address Mask Reply NC 18 RFC950
Traceroute NC 30 RFC1393
Datagram Conversion Error NC 31 RFC1475
Mobile Host Redirect NC 32 RFC3775
Where-Are-You NC 33 RFC1788
I-Am-Here NC 34 RFC1788
Mobile Registration Request NC 35 RFC1788
Mobile Registration Reply NC 36 RFC1788
Domain Name Request NC 37 RFC1788
Domain Name Reply NC 38 RFC1788
Photuris NC 40 RFC2521
Echo Request 128 8 RFC792
RFC2463
Echo Reply 129 0 RFC792
RFC2463
Multicast Listener Query 130 NA
76 Part I: Implementing IPv6 Services
76 Part I: Implementing IPv6 Services
RFC2710
Multicast Listener Report 131 NA RFC2710
Multicast Listener Done 132 NA RFC2710
Router Solicitation 133 10 RFC1256
RFC2461
Router Advertisement 134 9 RFC1256
RFC2461
Neighbor Solicitation 135 NA RFC2461
Neighbor Advertisement 136 NA RFC2461
Redirect Message 137 5 RFC792
RFC2461
Router Renumbering 138 NA RFC2894
ICMP Node Information Query 139 NA RFC2894
ICMP Node Information Response 140 NA RFC2894
Inverse Neighbor Discovery Solicitation Message 141 NA RFC3122
Inverse Neighbor Discovery Advertisement 142 NA RFC3122
Version 2 Multicast Listener Report 143 NA RFC3810
Home Agent Address Discovery Request Message 144 NA RFC3775
Home Agent Address Discovery Reply Message 145 NA RFC3775
Mobile Prefix Solicitation 146 NA RFC3775
Mobile Prefix Advertisement 147 NA RFC3775
Similar to ICMPv4, ICMPv6 enables IPv6 nodes to report errors and performs various control-planefunctions. Many of the existing ICMPv4 functionalities have been carried over to ICMPv6, although somewere simplified and many more added. This reengineering of ICMP could have been driven independently ofthe protocol version. However, the IPv4 legacy made that approach unrealistic, so a new protocol type (NextHeader) was defined specifically for ICMPv6 (protocol type 58 for ICMPv6, instead of 1 for ICMPv4). In thiscontext, ICMPv6 ended up being a different protocol than ICMPv4. Some features are similar to their IPv4counterpart (some of the error messages such as Destination Unreachable). Some features are not carried over,mostly because they never became popular (traceroute as defined in RFC 1393, for instance). New features(such as link-layer address resolution, or packet too big) were introduced, leading to some fundamental designdifferences from IPv4.
Table 2-9 presents a comparison between ICMPv6 and ICMPv4. In the ICMPv6 column, the ICMPv4messages that are not considered in IPv6 are marked NC. In the ICMPv4 column, the ICMPv6 messages thatwere not adopted are marked NA.
The ICMPv6 types 1 to 127 are reserved for errors, and values starting at 128 are for control and information
Part I: Implementing IPv6 Services 77
Part I: Implementing IPv6 Services 77
reporting.
Regardless of message type, all ICMPv6 messages share the same message header format as shown in Figure2-18.
Figure 2-18. ICMPv6 Packet Format
[View full size image]
The IPv6 header has a value of 58 in the Next Header field if the upper-layer protocol of the payload data isICMPv6.
If the message is a response to an ICMPv6 messages sent to one of the node's unicast addresses, the SA is thesame address. Otherwise, the SA is calculated using the source address selection algorithm (see the "SASAlgorithm" section later in this chapter).
The Type field, shown in Figure 2-18, can take one of the values enumerated in Table 2-9, and the codedepends on each message.
The Checksum, unlike ICMPv4, includes the pseudo-header, a set of important fields from the IPv6 header, inaddition to the ICMPv6 entire message. The inclusion of the pseudo-header enables ICMPv6 to check theintegrity of essential elements of the IPv6 header in the absence of a layer 3 header checksum (see the "IPv6Packet Format" section earlier in the chapter).
ICMPv6 Error Messages
One of ICMP's functions is to deliver error messages that help the operation of a network. Currently, ICMPv6uses four error messages:
Destination Unreachable• Packet Too Big• Time Exceeded• Parameter Problem•
The scope, use, and format of these messages are discussed in the following subsections.
Destination Unreachable
IPv6 is as unreliable as IPv4 is, in the sense that sometimes packets get dropped on the path to theirdestination. In many cases, this is a transient problem due to network congestion or transient connectivity loss
78 Part I: Implementing IPv6 Services
78 Part I: Implementing IPv6 Services
and can be recovered by higher-level protocols, such as TCP. In some cases, however, a feedback mechanismis required. For example, the destination specified in the packet can be wrong, or the routing protocol may befailing to distribute routing information to it. ICMP Destination Unreachable provides such feedbackmechanism, in the same way as in IPv4. The ICMP Unreachable message provides a reason code to help thesource troubleshoot the problem and take appropriate action. Table 2-10 lists the ICMP code values.
Table 2-10. ICMP Codes for the "Destination Unreachable" Message
Code
Short Description
Explanation
0
No route to destination
The packet was dropped because no route was matching the destination.
1
Communication with destination administratively prohibited
Filters blocked the packet.
3
Address unreachable
The link-layer address could not be resolved.
4
Port unreachable
The destination port specified in the UDP or TCP header was invalid or does not exist on the destination host.
Note that ICMPv6 has fewer codes than ICMPv4, mainly because some IPv4 messages are not applicable toIPv6. For instance, "Fragmentation Needed and DF Set" cannot apply to IPv6 because fragmentation does notoccur on intermediate routers. In addition to the reason code, the message also includes the original datagramportion that fit into the 1280-byte packet.
Time Exceeded
As in IPv4, an IPv6 datagram might loop in the network (because of improper routing configuration, ortransient routing states in large networks). The ICMPv6 Time Exceeded was carried over from ICMPv4,designed to prevent packets from looping indefinitely in the network. A Hop Count field in the IPv6 header isdecremented by each hop until it eventually reaches 0, in which case the datagram is dropped and the ICMPv6Time Exceeded is sent back to the source.
Part I: Implementing IPv6 Services 79
Part I: Implementing IPv6 Services 79
Note
As in ICMPv4, the Time Exceeded message was diverted from its original goal, to provide a fairly inefficientbut useful way to trace paths in the network (namely, traceroute). A UDP packet is sent to destination manytimes, by increasing the Hop Count field from 1 to "whatever it takes to reach the destination." Each node onthe path will successively send back an ICMPv6 Time Exceeded message, enabling the source to identify eachrouter on the path.
Packet Too Big
One of the numerous changes brought by IPv6 relates to the packet-fragmentation process. Unlike IPv4, inwhich any router on the path to the destination could fragment a packet, should it not fit the MTU of theoutgoing link, IPv6 does not provision for this functionality. Although it was convenient for hosts to rely onfragmentation performed by routers, wherever needed, this was also concentrating a lot of processing burdenon the routers. Routers have to keep state and use additional memory for the fragmentation process. Thisbeing said, it cannot be sufficient to not support the fragmentation feature in the middle of the network. Somefeedback mechanism becomes required so that a router on the path to the destination can signal to theoriginating host that packets need to be fragmented. The Packet Too Big ICMPv6 message is used for thatpurpose. It contains the MTU for the failing link and the original datagram portion that fit into the 1280-bytepacket.
The ICMPv6 message is primarily an error message. However, it was slightly diverted from its originalpurpose, to enable hosts to discover the minimum MTU on a path to a particular destination. This is thePMTU Discovery functionality, described in RFC 1981. In short, the idea is that a host assumes the path MTU(PMTU) is the MTU of the first hop in the path. Upon receiving Packet Too Big ICMPv6 messages, it reducesthe PMTU and fragments packets accordingly. It keeps going until it stops receiving the Packet Too Bigmessages.
The PMTU process on a Cisco router is shown in Example 2-9 through the output of the IPv6 ICMP debug.
Example 2-9. PMTU Discovery Performed by a Cisco Router
Router#pingProtocol [ip]: ipv6Target IPv6 address: 9009::72eRepeat count [5]: 2Datagram size [100]: 1400!note that the MTU on one of the routers(biot) on the path has been set to 130000:03:21: ICMPv6: Received ICMPv6 packet from FE80::A8BB:CCFF:FE01:F600, type 134Type escape sequence to abort.Sending 5, 1400-byte ICMP Echos to 9009::72E, timeout is 2 seconds:B!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 16/20/28 msRouter#00:03:23: ICMPv6: Sending echo request to 9009::72E00:03:23: ICMPv6: Received ICMPv6 packet from 9009::72D, type 200:03:23: ICMPv6: Received ICMP too big from 9009::72D about 9009::72E, MTU=130000:03:23: ICMPv6: Sending echo request to 9009::72E00:03:23: ICMPv6: Received ICMPv6 packet from 9009::72E, type 12900:03:23: ICMPv6: Received echo reply from 9009::72E!The « Packet Too Big » message has enabled the caching of a Path MTU for that!destination, that can be displayed using the command belowRouter#show ipv6 mtu MTU Since Destination Address1300 00:00:07 9009::72E
80 Part I: Implementing IPv6 Services
80 Part I: Implementing IPv6 Services
Parameter Problem
As in ICPMv4, the Parameter Problem messages provide a way for routers to report more generic issues notcovered by the first three messages described previously. The ICMPv6 message can point out (by signalingthe offset of that field) any field anomaly in the IPv6 header that prevented the datagram from being processedfurther. The following code values enable the complaining node to provide additional indications.
Table 2-11. ICMP Codes for the "Parameter Problem" Message
Code
Short Description
Explanation
0
Erroneous header field encountered
The field pointed by the Pointer field is in error.
1
Unrecognized next header type encountered
The next header is not recognized.
2
Unrecognized IPv6 option encountered
The IPv6 option is not recognized.
ICMPv6 Informational Messages
The Echo Request and Echo Reply found in ICMPv4 have been carried over to ICMPv6. As in ICMPv4, thesetwo messages are widely used to perform simple connectivity diagnostics, via the ping command. The formatof the messages is pretty much unchanged. Besides a type (1) and a code (1), the messages contain anidentifier and a sequence number, plus some optional data, copied back from the Request into the Reply.
Many more informational messages have been specified in various RFCs for the benefit of a large variety ofprotocols, such as Neighbor Discovery, MIPv6, and multicast. Those are covered in detail in thecorresponding sections.
Part I: Implementing IPv6 Services 81
Part I: Implementing IPv6 Services 81
Source Address Selection Algorithm
One of the specificities of IPv6 is that a node can commonly have multiple addresses to choose from whenselecting the source or destination of a packet. Multiple unicast addresses can be assigned to the sameinterface, and they may have different reachability scopes (link-local or global). Dual-stack nodes might evenhave a choice between IPv4 and IPv6 addresses, in particular if the DNS server has provided both of them fora given name. Multihoming is likely to enable multiple addresses per node, and MIPv6 introduces homeaddress and care-of address in the same node.
Two algorithms have been specified in RFC 3484, one for source address selection (SAS) and one fordestination address selection (DAS). This section details the former (SAS), because it is commonly used byICMPv6 to select the SA to use before generating an error or informational message. Many other aspects ofIPv6 operation, besides ICMP, are required to deal with SAS, or have ramifications for SAS, and in somecases, encounter issues with SAS. MIPv6 and VPNv6 represent two examples, so the SAS topic will bebrought up again in the respective sections.
The algorithm presented here describes the current state of SAS. The SAS algorithm does not take precedenceover the application or upper-layer choice. For instance, in the ICMP case, a response to a query just uses theSA that is the DA of the corresponding request. When used, the algorithm is provided with a list of candidateaddresses, and applies to this list a set of rules to select the candidate that matches the maximum number ofthese rules. If a rule has no matching candidates, a candidate address from the list before the rule was appliedis chosen.
Figure 2-19 provides a logic diagram of the SAS algorithm.
Figure 2-19. Source Address Selection Algorithm
[View full size image]
82 Part I: Implementing IPv6 Services
82 Part I: Implementing IPv6 Services
As mentioned in the "IPv6 Addressing" section of this chapter, the addresses of site-local scope have beendeprecated and replaced by unique-local addresses, with global scope. These addresses have not yet explicitlyfound their way into SAS, but they should be considered in the context of the scope rule.
Conclusion on ICMPv6
ICMPv6 has not fundamentally diverged from ICMPv4. It is still a messaging protocol, connectionless, andused for many different purposes (from error reporting to diagnostic and network operations). Messages arestructured the same way as in ICMPv4, with a type, code, and body; some message types have been carriedover from ICMPv4, and some new ones have been defined.
Part I: Implementing IPv6 Services 83
Part I: Implementing IPv6 Services 83
However, the uses of ICMPv6, in particular by the Neighbor Discovery Protocol (NDP), are greater thanICMPv4 uses. Whether this is the right approach and the right protocol to perform things as diverse as addressresolution, error reporting, autoconfiguration, MIPv6 tasks, and so forth remains to be seen on the deploymentside.
Neighbor Discovery Protocol
IPv6 Neighbor Discovery (ND) was first designed and published almost 10years ago, as RFC 1970. It has been revised since then as RFC 2461, and anew version, focusing on fixes rather than revisions, is underway as RFC2461bis. Some extensions have been described in Inverse NeighborDiscovery (RFC 3122), Default Router Selection (RFC4191), andAutoconfiguration (RFC 2462).
In these 10 years, the focus of the Internet community has shiftedsignificantly, and areas that did not get much attention, such as security andmobility, are now the focus of most of the efforts. This change of focus hasled to a number of extensions, clarifications, and interactions described invarious RFCs and Internet Drafts: Extension for Mobility in MIPv6 (RFC3775), Security Features in Secure Neighbor Discovery (SEND) (RFC3971), Detecting Network Attachment (DNA) (RFC 4135), Protocol forCarrying Authentication for Network Access (PANA) (RFC 4058), andOptimistic DAD (draft-ietf-ipv6-optimistic-dad).
The IPv6 NDP provides a number of integrated key features for router andhost operations, when attached to the same link. Some of these features,such as address resolution and redirect, are seen in IPv4, under specificdistinct protocols such as ARP and ICMP Redirect, respectively. Otherfeaturesfor instance, prefix discovery and neighbor unreachabilitydetectionare new, although some could be achieved by other means withIPv4, too. Table 2-12 lists these features and their correspondence in IPv4.
Table 2-12. IPv6 NDP Feature Counterpart in IPv4IPv6 ND Feature Short Description IPv4Router discovery Enables hosts to
Redirect Enables routers toinform hosts of abetter next hop onthe link for aparticulardestination
ICMPRedirect
Default router and more specific route selection Enables routers toinform multihomedhosts of betterdefault routers andmore specificroutes
Proxying nodes Accepts packets onbehalf of othernodes
Proxy-ARP
NDP applies to both hosts and routers in different ways. Table 2-13 attempts to separate hosts and routerroles, with regard to the preceding list of features.
Table 2-13. Host and Router Roles with Regard to NDP
Host Algorithms
Host-Host Communication
Host-Router Communication
Node-Node Communication
Default router selection
Part I: Implementing IPv6 Services 85
Part I: Implementing IPv6 Services 85
Neighbor unreachability detection
Router discovery
Address resolution
Default router selection
Next-hop determination
Duplicate address detection
Prefix discovery
Redirect
Parameter discovery
More-specific route
One of the fundamental differences between IPv6 ND and its IPv4 counterpart suite of protocols (ARP, IPCP,and so on) is the positioning in the IP protocol stack. Although IPv4 same-link-related protocols are splitbetween ARP/RARP, right above the link layer, and ICMP, running above IP, IPv6 ND is implementedentirely within ICMPv6. Figure 2-20 highlights differences between the protocol stacks.
Figure 2-20. IPv4 and IPv6 Protocol Stack Comparison
[View full size image]
The reasons for the ND positioning within the stack are numerous, but if only one should be mentioned, it issimplicity. Why make address resolution (ARP and RARP in IPv4) a special case if this can be avoided?When within ICMP rather than next to IP, this feature can benefit from any service provided by IP, including
86 Part I: Implementing IPv6 Services
86 Part I: Implementing IPv6 Services
security (Authentication Header), multicast, and so on.
To secure the various functions in NDP, Secure Neighbor Discovery has introduced a set of specific NDoptions. They are used to protect NDP messages. Although this IPv6 refresher does not go into more detailabout these options, you can refer to RFC 3971 for more information about SEND.
Protocol Operations Summary
The NDP enables each node on the link to perform ND, to build the knowledge necessary to make properdecisions when sending IPv6 packets to a neighbor. This knowledge represents a compilation ofadvertisements received from routers and nodes. These advertisements can be solicited or unsolicited. Thisinformation is stored on the following lists maintained by nodes:
List of on-link IPv6 addresses and corresponding link-layer addresses• Neighbors status (reachable, unreachable)• For hosts in particular:
- List of on-link prefixes- List of on-link routers- List of default routers (on-link routers willing to be default routers)
•
To obtain the above information, the following messages are used in the NDP:
The positioning of NDP above IPv6/ICMP raises a couple of questions that deserve clarification.
When the link-layer address matching a given destination address is not known, a node seeking thatassociation has to send its query to a wider audience. In IPv4, this is done using MAC-level broadcasts. InIPv6, the node uses multicasts for this query. The multicast group used is the solicited-node (with link-localscope), as described in the "IPv6 Addressing" section.
Note
Note that after the link-layer address is known for a prefix, the neighbor query might be sent again, to confirmthe association (IP address, link-layer address). In that case, the query is directly unicasted to the destination.
Another issue arises when a node is using NDP to acquire its own address (see the section"Autoconfiguration"). It needs a source address to use for its query but has none yet. In such cases, it can usethe IPv6 unspecified address (::) for the packet SA.
Whereas address resolution messages are sent to the solicited-node multicast address (with link-local scope),other NDP messages are expected to reach all nodes or all routers. At the same time, the SA can be either aglobal or the link-local address of the sender: The latter is always preferred, to minimize the node's
Part I: Implementing IPv6 Services 87
Part I: Implementing IPv6 Services 87
dependency on renumbering. Here is a list of all special addresses, sources, and destinations that a node canuse in NDP exchanges:
IPv6 NDP provides a number of improvements over the corresponding IPv4 protocols, as follows:
Router discovery becomes an integrated part of the protocol, enabling hosts to identify their defaultrouter.
•
Additional information, such as MTU or link-layer address, has been inserted in the ND messages,reducing the number of required exchanges on the link to achieve the same result as in IPv4. Here area few examples:
- The link-layer address of the router is carried in RA message. So all nodes on the link,without any further message flow, know it.- The target link-layer address, inserted in the redirect message, saves the receiver (beingredirected) any extra address-resolution exchange.- The MTU, carried in the RA, enables all nodes on a link to use a consistent MTU.
•
The address resolution uses multicast groups (solicited-node multicast address), embedding part of thetarget address. Most likely, therefore, only a few (most of the time only the target address owner)nodes will get interrupted with such address-resolution queries. Compare this with IPv4 ARP, whichhas no other choice than broadcasting (link-layer broadcast) the address-resolution requests (becauseARP sits directly above the link layer). One hopes that the IPv6 way of resolving link-layer addresseswill make subnets with a much larger number of hosts more manageable by drastically limitinglink-layer broadcasts that host software layers have to handle.
•
Some new features such as address autoconfiguration and neighbor unreachability detection are partof the base protocol, simplifying configurations and improving robustness of packet delivery.
•
Router advertisements and Redirect messages carry router addresses in the form of link-localaddresses, which makes the router association in the host more robust to renumbering (of globalprefixes). In IPv4, the default gateway information has to be modified on the host every time thenetwork changes its addressing scheme.
•
The positioning of address resolution above ICMP makes it possible to use standard IP authenticationand security mechanisms for ND messages. Such mechanisms are not available in ARP for IPv4.
•
Router and Prefix Discovery
Router discovery enables hosts to locate neighboring (on-link) routers and learn prefixes and parametersrelated to address configuration.
Two messages have been defined for router and prefix discovery: the router solicitation (RS) message and therouter advertisement (RA) message.
88 Part I: Implementing IPv6 Services
88 Part I: Implementing IPv6 Services
Routers advertise themselves periodically (with a slight randomization to avoid synchronization, which couldleave some time intervals with no routers being advertised) out of each interface by sending RAs. Theseunsolicited RAs are sent to the all-nodes "link-local scope multicast address" (FF02::1). In addition toproviding the router address, RAs can contain useful information for hosts to perform next-hop determination,such as the following:
List of candidate routers for default router (see the algorithm described in the "Default RouterSelection" section)
•
Parameters that should be used for autoconfiguration (see the "Autoconfiguration" section)• List of on-link prefixes (see the "Next-Hop Determination" section later in this chapter). Thisinformation makes the router discovery messages useful in the prefix discovery process.
•
The RA messages can also be sent as a response to a query (RS) from a host. This option proves particularlyuseful in mobility, to accelerate autoconfiguration. These solicited RAs are sent either to the all-nodes addressor to the unicast address of the host, which issued the RS. As the RS is soliciting a response from on-linkrouters, it is typically sent to the all-routers multicast group. Figure 2-21 shows the flow for a solicited and foran unsolicited RA exchange.
Figure 2-21. Router Advertisement Flow
[View full size image]
Note
In the case of a solicited RA, when the RS does not provide any IPv6 SA (typical for hosts that rely on RAs toautoconfigure themselves), the RA response is sent to all nodes.
Figure 2-22 shows a simple example of a Cisco router (Valbonne) sending a periodic RA to a host (host1).The interface configuration is grayed, the NDP debugging is enabled, and the debug output is shown belowthe RA flow.
Part I: Implementing IPv6 Services 89
Part I: Implementing IPv6 Services 89
Figure 2-22. Router Advertisement Example
[View full size image]
Figure 2-22 shows a debug trace interleaved with the RA flow.
The show ipv6 routers command is used on a Cisco router to display RA information received from otheron-link routers. Only the router sends RAs, and only the hosts install them in their database. So in theconfiguration in Figure 2-22, this command applies only to host1 (a Cisco router in host mode). Example 2-10shows the output of this command.
Example 2-10. Host Perspective of Advertised Routers.
host1#show ipv6 routersRouter FE80::A8BB:CCFF:FE01:F600 on Ethernet0/0, last update 2 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 Reachable time 0 msec, Retransmit time 0 msec Prefix 2001:100::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 Prefix 2001:200::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800
Address Resolution
The neighbor solicitation and neighbor advertisement packets are used to perform several critical nodeoperations:
DAD and NUD are described in next sections. ND link-layer resolution provides a similar service to ARP inIPv4, although using a slightly different method.
Two ICMPv6 messages have been defined for IPv6 address resolution: the neighbor solicitation (NS) messageand the neighbor advertisement (NA) message. The NS is the query and contains the target (queried) IPv6address. The NA is the response and contains the link-layer address of the matching interface.
90 Part I: Implementing IPv6 Services
90 Part I: Implementing IPv6 Services
When a node has concluded that a particular next hop or destination IPv6 address is on-link (see the section"Next-Hop Determination" later in this chapter), it sends out an NS on the identified link, to obtain thelink-layer address matching the IPv6 address. The expected response is an NA.
The NS is a multicast to the solicited-node multicast group, embedding the rightmost 24 bits of the queriedIPv6 address. There are potentially multiple nodes subscribed to the same solicited-node multicast address,with the "owner" of that address being one of them. The owner will get the NS along with the other membersof the multicast group, and answer with an NA.
Note
NDP is a nonreliable protocol. On most link types, this is fine, because the probability of "losing" a message,such as an NS or NA, is low. On wireless links, however, this may become an issue. In particular, DAD couldconclude that an address is free to use, whereas in fact, the NA was lost.
A host can also send an unsolicited NA. This could happen when the node wishes to inform the other nodeson the link about a change in their link-layer address. The unsolicited NA is sent to all-nodes multicastaddress.
After the node has received the NA, the neighbor from whom it has been received is considered "reachable."Monitoring the reachability is the purpose of NUD. See the sections "Neighbor Unreachability Detection" and"The State Machine for Reachability" for details. Figure 2-23 shows the flow for the address-resolutionprocess.
Figure 2-23. Address-Resolution Flow
[View full size image]
On Cisco routers, the association (layer 3 address, link-layer address) is stored in the neighbor cache. Thecommand show ipv6 neighbor executed on each router lists the neighbor cache content. In Example 2-11, thebiot neighbor cache has two entries that relate to router valbonne: 2001:200::72b and
Part I: Implementing IPv6 Services 91
Part I: Implementing IPv6 Services 91
FE80::A8BB:CCFF:FE01:F600. They are listed in "reachable" state along with the corresponding link-layeraddress.
Routers send redirect messages to inform hosts of a better next hop, whether another router or the finaldestination itself, should it be on-link. The IPv6 redirect mechanism is similar to the IPv4 redirect mechanism.Only one message, the redirect message, is necessary to achieve the redirect functionality. It contains the IPaddress that is a better next hop and the IP address of the destination that is redirected. If the link-layeraddress of the better next hop (R2) is known, it can be inserted in the redirect packet sent by the router (R1)issuing the redirect message.
Note
In theory, the previously described process could save an address-resolution exchange between the host andthe router R2. In practice, the benefit may be limited. The router R2 is likely, at some point, to route sometraffic back to the host. To do so, it will need to initiate an NS/NA exchange to determine the host link-layeraddress. This flow would have been unnecessary had the host initiated an address-resolution flow to find R2'slink-layer address. The link-layer address of the initiator of the NS can indeed also be inserted, as an option, inthe NS packet.
Figure 2-24 shows the flow for the redirect message.
Figure 2-24. Redirect Flow
[View full size image]
92 Part I: Implementing IPv6 Services
92 Part I: Implementing IPv6 Services
Inverse Neighbor Discovery
As mentioned earlier, ND fulfills, for IPv6, the same functionality as ARP does for IPv4. In this context,similar reasons that drove an inverse-ARP protocol led to extensions to IPv6 ND called IPv6 InverseNeighbor Discovery (IND). The details of this extension are specified in RFC 3122.
The IPv6 IND enables a node to learn IPv6 addresses for which it knows the link-layer address. To achievethis, it sends solicitations and receives advertisements. The IND was originally developed for Frame Relaynetworks, but may also apply to other data-link technologies with similar behavior. Two messagesthe inverseneighbor discovery solicitation (INS) and the inverse neighbor discovery advertisement (INA)have beendefined. The INS contains the source link-layer address and the target link-layer address (for which the senderexpect to get an IPv6 address). The response (INA) contains the source link-layer address, the target link-layeraddress, and a target address list. It contains the list of one or more IPv6 addresses of the interface identifiedby the target link-layer address in the INS message that prompted the INA.
Note that at the time of this writing, RFC 3122 is not supported on Cisco routers.
Proxy Neighbor Discovery
An IPv4 node has the capability to proxy subnets for hosts that do not understand subnet (or aremisconfigured) or default routers. This function is sometimes referred to as proxy-ARP and is specified inRFC 1027. IPv6 does not carry over that concept; instead, it requires IPv6 hosts to process RAs and to comeup with a default router to which nonlocal traffic can be sent. Furthermore, proxying an entire subnet mightbe, for many systems, impractical. They could set the interface in promiscuous mode, or all-multicast mode,to receive all NSs, but, besides performance issues this potentially raises, not all systems support these modes.
In some cases, however, it might prove useful for a router to act on behalf of nodes that are away from the linkbut want neighbors to believe they are not. A classical example is a mobile node that has moved off-link. Toachieve this limited proxy address-resolution function, the router just has to register to the solicited-nodemulticast addresses it wants to proxy and answer NSs on their behalf.
Part I: Implementing IPv6 Services 93
Part I: Implementing IPv6 Services 93
Neighbor Discovery Algorithms
A number of ND algorithms have been defined to describe the expected behavior of both hosts and routers ina variety of operational situations. The following subsections discuss these algorithms:
Next-Hop Determination
As in IPv4, a node that needs to forward a packet must find out whether the destination is on-link or off-link.In the latter case, it must subsequently find an on-link neighbor (next hop) that can forward the packet to thedestination. Finally, it has to resolve the on-link destination address, or the on-link next hop, into a link-layeraddress.
Unlike IPv4, a destination (or next hop) can be on-link, without the forwarding node having a prefix matchingthe destination address. An address will be considered on-link by a node if
It is covered by one of its link's prefixes.• It received an NA for that address.• It received any ND message from that address.• It received an RA with this prefix in the prefix information option.• It received a redirect message with a target equal to that address.•
The algorithm used to forward a packet is set fairly differently on hosts or routers. A router has a routing tableand a neighbor cache (same as ARP cache for IPv4). The first one (the Routing Information Base, or RIB)contains next hops for a given destination match (longest match); the latter contains link-layer addresses foron-link nodes, either final destination or next hops. Cisco routers also have a forwarding table (ForwardingInformation Base, or FIB), which takes the RIB one step further by pre-resolving recursive entries toaccelerate the forwarding process. In routers, regular routing mechanisms take precedence over informationobtained from neighboring routers via prefix discovery or router discovery mechanisms. Then NS/NAmessages enable link-layer resolution.
Example 2-12 shows the routing tables and the neighbors of a router in Figure 2-24.
Example 2-12. Routing and Neighbor Information on an IPv6 Router
valbonne#show ipv6 routeIPv6 Routing Table - default - 7 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2C 2001:100::/64 [0/0] via Ethernet0/0, directly connectedL 2001:100::72B/128 [0/0] via Ethernet0/0, receiveC 2001:200::/64 [0/0] via Ethernet0/0, directly connectedL 2001:200::72B/128 [0/0] via Ethernet0/0, receiveL FF00::/8 [0/0] via Null0, receivevalbonne#show ipv6 neighborsIPv6 Address Age Link-layer Addr State Interface2001:200::72A 1 aabb.cc01.f400 STALE Et0/0FE80::A8BB:CCFF:FE01:F400 1 aabb.cc01.f400 STALE Et0/0
94 Part I: Implementing IPv6 Services
94 Part I: Implementing IPv6 Services
On hosts, on the other hand, no such thing as a routing table or routing protocols should be necessary.
RFC 2461 describes a set of conceptual data structures to enable next-hop determination in hosts:
Destination cache Contains destinations to which traffic has been forwarded recently, with the nexthop (neighbor) that was chosen providing linkage into the neighbor cache. This cache is updated withinformation obtained from redirect messages.
•
Prefix list Contains the list of prefixes that match the on-link addresses. This list is built from RAmessages.
•
Default router list Contains the list of on-link routers to which packets can be sent.•
Figure 2-25 shows a host model of the next-hop determination algorithm, based on RFC 2461.
Figure 2-25. Next-Hop Determination Algorithm
[View full size image]
The host first does a lookup into the destination cache, in case the destination of the packet has been seenrecently. If so, the destination cache provides the next hop that was used (may be the destination itself), and asubsequent lookup into the neighbor cache is likely to provide the link-layer address. This path, shown inbold, will be the most exercised on an established flow. If the destination is not in the destination cache, it issearched in the prefix list (maintained from information received in RAs). As a last resort, a default router isselected, from among all on-link routers (known by sending RAs), via default router selection.
Default Router Selection
Again, this is a host-specific algorithm. Routers just rely on routing protocols (and routing tables) to makeproper next-hop determinations.
Part I: Implementing IPv6 Services 95
Part I: Implementing IPv6 Services 95
Unlike IPv4, a default gateway does not have to be defined on an IPv6 host. The procedure for a host to selecta router as the next hop for its traffic is described in the "Default Router Preference and More-SpecificRoutes" Internet Draft. It identifies three distinct types of hosts:
Type A Hosts that ignore default router preference, as well as more specific routes listed in the RAoption Route Information. (See the section "Router and Prefix Discovery" for details.) These hostssimply run the router selection algorithm as described in RFC 2461. Basically, a type A host selects adefault router from its default router list (built from RAs received from routers sharing a link with thehost). It should prefer a reachable router if any are available (known as reachable, according to thestate machine; see the section "The State Machine for Reachability") or any other router on the list, ifavailable. If the selected router is not known as reachable, it should be selected in a round-robinfashion from among all the routers on the list (thus ensuring that all routers on the list are probed bythe neighbor unreachability detection algorithm).
•
Type B Same as type A hosts, where the default router list is augmented by the preference (Low,Medium, High) received in the RAs. The default router selection can be based on this preferencerather than being round robin.
•
Type C Hosts that implement a routing table. When they receive an RA with a number of occurrencesof the Route Information option, they install a default route, ::/0, pointing to the router that issued theRA; they also install (or remove if the lifetime is 0) one route to the prefix found in the RouteInformation option, per occurrence. When a type C host does next-hop determination and consults itsrouting table for an off-link destination, it first prefers reachable routers over nonreachable routers;then it uses the longest-matching prefix; after that, it uses route-preference values.
•
Note that hosts of different types, receiving the same RA packets (multicast on the link), might end up makingdifferent decisions when selecting a default router.
Note
As mentioned previously, each router on the link may advertise a list of prefixes as well as offer itself as thedefault router. A dual-homed host could potentially receive disjoint prefix lists from two or more routers, andpick up one prefix from one list for autoconfiguration, forming an SA. It could then use this address (selectedusing SAS) to leave the subnet, via the router (selected as the default router) that did not advertise the prefixused to form this address.
Duplicate Address Detection
The NS and NA messages are also used to perform duplicate address detection (DAD), as described in RFC2462. DAD is performed on all unicast addresses prior to assigning them to an interface. The basic principle isthat a node sends an NS to query about an IPv6 address ownership, and assigns the address to one of its owninterfaces only if no NA was received for it.
Optimistic DAD is proposing a modification of the existing IPv6 ND (RFC 2461) and stateless addressautoconfiguration (RFC 2462) algorithms. The intention is to minimize address configuration delays in thesuccessful case (the address chosen by the node is unique), and to reduce disruption as far as possible in thefailure case. Optimistic DAD is only performed on automatically configured addresses. It is a usefuloptimization because DAD is far more likely to succeed than fail for a well-distributed random address or foran interface IDbased address constructed in the modified EUI-64 format from the unique MAC.
Note
96 Part I: Implementing IPv6 Services
96 Part I: Implementing IPv6 Services
DAD must not be performed on anycast addresses because by definition an anycast address can belong tomultiple nodes.
Neighbor Unreachability Detection
Communication with a neighbor may fail for a number of reasons. If the path (on the link) to the destinationhas failed, recovery may be possible. The recovery mechanism to invoke when a failure has been detecteddiffers depending on whether the neighbor is also the final destination. If it is, the address resolution should bere-initiated. Otherwise, a different next hop should be selected. This falls under the next-hop determinationalgorithm (explained in "Next-Hop Determination" section), where two mechanisms can be used. Routerstypically use their routing table, whereas hosts run the router selection algorithm (see the "Default RouterSelection" section).
The neighbor unreachability detection (NUD), however, deals with detecting the failure. Reachability of aneighbor is obtained in two possible ways. The first method is a confirmation from an upper layer thatcommunication is happening with this neighbor (for instance, received TCP packets acknowledgingpreviously sent packets). The second method is the receipt of an NA as a response to an NS sent by the nodelooking for reachability confirmation. Any other methods, such as RAs, cannot be used to confirmreachability of a neighbor. A neighbor then remains reachable for a limited amount of time, unless newconfirmations come in. If the confirmation is not received in a timely manner, the neighbor is consideredunreachable, and recovery mechanisms take place. The complete state diagram for neighbor entries in the NDcache is detailed in the next section.
The State Machine for Reachability
The neighbor cache maintains a list of neighbors to which traffic has been sent recently. Figure 2-26 shows astate diagram of the neighbor cache.
Figure 2-26. ND Cache Entry State Diagram
Part I: Implementing IPv6 Services 97
Part I: Implementing IPv6 Services 97
In Figure 2-26, the following events will generate transition from one of the five states (INCOMPLETE,REACHABLE, DELAY, STALE, and PROBE):
NA1 Receiving an NA with Solicited=0• NA2 Receiving an NA with Solicited=1• NA3 Receiving an NA with Solicited=1 and
- Override=1 or- Override=0 and link-layer same as cached
•
NA4 Receiving an NA with Solicited=1, Override=0, and link-layer different from cached• NA5 Receiving an NA with Solicited=0, Override=1, and link-layer different from cached• O Receiving other ND packets, such as NS, RS, RA, redirect, with link-layer different from cached• S Sending packet• T Timeout (Note that each state has a timer, started when entering the state.)• Te Timeout with retries exhausted• U Upper-layer reachability confirmation•
The typical life of an entry is shown (in bold) in the state diagram of Figure 2-26. An entry is a mappingbetween an IPv6 address and a link-layer address. The entry is created INCOMPLETE (link-layer unknown),and an NS is sent to obtain the link-layer address. As soon as the response (NA) is received, the entry movesto REACHABLE state, and traffic can be forwarded. If the router sees no traffic for that neighbor for a certainperiod of time (typically 30 seconds), the entry moves to the STALE state. From there, it can either moveback directly to REACHABLE (typically upon upper-layer reachability confirmation) or to DELAY (if apacket is to be sent to this neighbor), where a new NS is issued, or it can be deleted (in our example) after acertain amount of time in STALE (typically hours).
98 Part I: Implementing IPv6 Services
98 Part I: Implementing IPv6 Services
Autoconfiguration
The address autoconfiguration is used to automatically assign addresses to a host. Address autoconfigurationis specified in RFC 2462. It uses the NDP (specifically RAs) to obtain the prefix to build an address on, andagain ND (specifically NS and NA messages) to test that the built address is not already in use. The defaultmechanism for autoconfiguration is stateless. Another mechanism, stateful, can be used and is specified inRFC 3315. Both mechanisms are described in Chapter 3, "Delivering IPv6 Unicast Services," in the section"Host IPv6 Address Provisioning."
Neighbor Discovery at a Glance
Table 2-14 summarizes ND information for quick reference.
Table 2-14. NDP at a Glance
Message Name
Goal
ICMP Code
Sender
Target
Options
Router solicitation (RS)
Prompt routers to send RA quickly
133
Nodes
All routers
SLLA[1]
Router Advertisement (RA)
Advertise:
Default router
On-link prefixes
Reachable prefixes
Oeration parameters
134
Part I: Implementing IPv6 Services 99
Part I: Implementing IPv6 Services 99
Routers
Sender of the RS
or
All nodes
SLLA
MTU
Prefix information
Route information
Advertisement interval
Home agent information
Neighbor solicitation (NS)
Request the link-layer address of a target node
135
Nodes
Solicited node
or
Target node
SLLA
Neighbor advertisement (NA)
Respond to NA
Advertise link-layer address changes
136
Nodes
Sender of the NS
or
All nodes
TLLA[2]
100 Part I: Implementing IPv6 Services
100 Part I: Implementing IPv6 Services
Redirect
Inform hosts of a better first hop
137
Routers
Host that triggered the redirect
TLLA
Redirected header
Inverse neighbor solicitation (INS)
Request an IPv6 address corresponding to a link-layer address
141
Nodes
All nodes
SLLA[3]
TLLA[3]
MTU
Source address list
Inverse neighbor advertisement (INA)
Respond to an INA
142
Nodes
Sender of the INS
SLLA[3]
TLLA[3]
Target address list[3]
MTU
[1] SLLA: Source link-layer address
Part I: Implementing IPv6 Services 101
Part I: Implementing IPv6 Services 101
[2] TLLA: Target link-layer address
[3] Option required
IPv6 is not limited, in the least, to the protocols reviewed in this chapter. However, this chapter covered thefundamental elements, to provide you with the tools to understand the most relevant differences between IPv6and IPv4. With these tools in mind, the next chapters review IPv6 network services, all built "on top of" IPv6addressing, ICMPv6, and the Neighbor Discovery Protocol.
Chapter 3. Delivering IPv6 Unicast Services
Overview
IPv6 Provisioning
IPv6 Network Access
IPv6 over the Backbone
Translation Mechanisms (NAT-PT)
Overview
This chapter covers IPv6unicast connectivitywithin an enterprise orservice provider network,and discusses availableoptions, implementationscenarios, anddeploymentrecommendations. Theintent is to present thisinformation as it appliesto different parts of thenetwork:
Hosts orCustomer Edge(CE) routers
•
Access andbackboneinfrastructures
•
The concepts that arerelevant in making a hostoperational in an IPv6
102 Part I: Implementing IPv6 Services
102 Part I: Implementing IPv6 Services
network are presentedfirst. This section of thechapter reviews themechanisms for providinghosts and CE routers withan IPv6 address, andintroduces new conceptsuch as prefix delegation,for providingname-resolution supportand for some AAA(authentication,authorization andaccounting) management.
Subsequent sectionsdiscuss the delivery ofIPv6 unicast connectivityfrom a networkperspective. The servicedeployment will mostlikely interact at somepoint with or over somesegments with existingIPv4 infrastructures. Inthis interaction, there arethree deploymentapproaches:
IPv6 only IPv6 isthe only protocolrunning over agiven link(physical orvirtual).
•
Dual stack IPv4and IPv6 runtogether over thesame link(physical orvirtual).
•
IPv6 at the edgeonly IPv6 isconfined to siteslocated at theedges of anexisting IPv4 coreinfrastructure thatit has to traverse.
•
These three approachesdefine a framework forthe service deploymentstrategy. The
Part I: Implementing IPv6 Services 103
Part I: Implementing IPv6 Services 103
technological means toimplement them arepresented in the contextof the two relevant layersof the network: accessand backbone.
Table 3-1 summarizes thedeployment mechanismspresented in this chapter.Along with the scope andsignificant features, thetable lists the areas of thenetwork where themechanism would fit best.
Table 3-1. IPv6 UnicastDeployment Mechanisms
Mechanism Scope Where Used Key Features LimitationsNative IPv6 Routed Host/Inter-siteAccess/BackboneSimplest method in
terms of setup.Support on allnetwork elementsin the path.
6 to 4 Inter-site Access/BackboneAutomatic tunnel.Reserved addressspace 2002::/16.
Return pathselection notoptimized.
Security issue ifnot securedthrough IPsec.
These mechanisms are presented in this chapter along with more in-depth discussions on deploymentrecommendations. The recommendations are made only from the perspective of providing IPv6 unicastconnectivity. Other selection criteria are presented in the chapters dedicated to other services, such asmulticast, virtual private networking (VPN), quality of service (QoS), and security.
Overall, a deployment strategy choice depends on technical considerations (best way to leverage existent IPv4infrastructure and to circumvent constraints such as Network Address Translation [NAT], for example) aswell as cost-effectiveness considerations (for instance, return on the investment of upgrading existentresources or adding new ones). Nevertheless, when possible, it is recommended to begin with native IPv6noIPv6 tunnelsbecause this represents the ultimate goal of the IPv6 integration.
IPv6 Provisioning
To gain IPv6 access and to benefit from IPv6 services, a node needs to be provided with thefollowing information:
Acquire the IPv6 address information for the node.• To be able to perform name-to-address mapping, the node needs to know theaddresses of Domain Name System (DNS) recursive name servers.
•
Finally, the node might have to keep accurate time for security purposes, whichrequires the addresses of Network Time Protocol (NTP) servers.
•
Part I: Implementing IPv6 Services 105
Part I: Implementing IPv6 Services 105
These three provisioning aspects are independent of whether the "IPv6 node" is a host or acustomer router. The information, other than the IPv6 address, mentioned in the bulleted listand necessary for the proper operation of the node is commonly referred to as otherconfiguration information.
Host IPv6 Address Provisioning
Providing IP addresses to hosts is an important aspect of deploying IP-based services. Manualconfiguration is always an option; however, it is not scalable and it is not easily adaptable toaddressing changes. For this reason, IPv4 most often relies on Dynamic Host ConfigurationProtocol (DHCP) for address provisioning. The same mechanism is available for IPv6; it iscalled stateful DHCP, and it is discussed later in this section.
As more and more devices and appliances become IP enabled, it is likely that many of themwill not have the resources to support complicated provisioning mechanisms. At the sametime, the nature of some of these devices and appliances would require them to haveplug-and-play capabilities. As a promoter of wider adoption of IP, IPv6 took this provisioningscenario into consideration and developed a simple autoconfiguration mechanism commonlyreferred to as stateless autoconfiguration.
Stateless Autoconfiguration
Stateless autoconfiguration operation is described in RFC 2462, and it relies on the NeighborDiscovery Protocol (NDP) reviewed in Chapter 2, "An Ipv6 Refresher" It is a simple IPv6address provisioning mechanism that can be used with any type of hosts.
Stateless Autoconfiguration Operation
In the context of this provisioning mechanism, IPv6-capable hosts rely on RouterAdvertisement (RA) messages to obtain the information needed for autoconfiguration. Toacquire an IPv6 address, a host will follow three steps:
Discover a prefix used on the link. This step is explained in detail in the "Router andPrefix Discovery" section of Chapter 2. The host can listen to periodic RAs sent byrouters on the link or it can poll for routers with the help of Router Solicitationmessages. The prefixes information is extracted from the RA messages.
•
Generate an interface ID. To have a full IPv6 address, the host must add an interfaceidentifier to a prefix learned from the routers on the link. The various optionsavailable for creating an interface ID are reviewed in the addressing section ofchapter 2. Examples of those options are build a EUI-64 ID based on the MACaddress, or randomly generate the address.
•
Verify the uniqueness of the generated IPv6 address. The IPv6 address that resultedfrom the previous two steps must be unique on the link. The Duplicate AddressDetection (DAD) mechanism described in the section with the same name in Chapter2 is used by the host before starting to use its new IPv6 address.
•
By default, Cisco routers are sending RAs that can be used by hosts for statelessautoconfiguration. This functionality can be turned off for each router interface with the IOS
106 Part I: Implementing IPv6 Services
106 Part I: Implementing IPv6 Services
command ipv6 nd suppress-ra. Other parameters relevant to this provisioning mechanism canbe modified with the option available for the ipv6 nd command.
IPv6 Address Renumbering
Address renumbering is a fact of life in any network. For various reasonssuch as networkchanges, user-distribution changes, and network mergersthe IP addressing scheme must bechanged. This process can consume significant resources of the network operations team. Forthis reason, any mechanism that simplifies renumbering would prove valuable. In the case ofIPv6, stateless autoconfiguration provides the means to advertise the deprecation of a prefixat a certain day and time and to advertise a new prefix from that moment onward. This isdone through the interface configuration command ipv6 nd prefix <ipv6-prefix/prefix-length>at <valid-date-time> <preferred-date-time>.
Note
A router must have the means to track dates and time if it is using this renumberingmechanisms. Date and time can be set on the router or learned via NTP. At the time of thiswriting, NTP over IPv6 is not supported by Cisco products. On the other hand, if the routersare dual stack, they can leverage the IPv4 infrastructure to communicate with a clock source.
The router advertises shorter and shorter lifetimes for the prefix as the date configured for itsremoval is approaching. Hosts on that link deprecate the prefix because of its lifetimeexpiration and learn a new prefix from the new router RAs.
In the context of today's IPv6 address-allocation rules, an enterprise might have to performrenumbering every time it changes ISPs. Updating the IPv6 addresses is just one aspect of thecomplex process of renumbering. Network administrators also have to modify, for example,QoS policies, access control lists (ACLs), DNS entries, and so on. This explains the interestshown by the Internet Engineering Task Force (IETF) in evaluating the renumbering optionsof IPv6. An example of such work is "Procedures for Renumbering an IPv6 Network withouta Flag Day," a draft in the IETF RFC editor's queue at the time of this writing.
Stateful DHCP
Stateful DHCP is a client/server-based mechanism that provides managed provisioning ofhosts. Its operation for IPv6 is described in RFC 3315. The value provided by DHCP consistsin the fact that provisioning is done through a centralized resource. This resource is easier tomanage than having to make changes on all customer-facing router interfaces in the case ofstateless autoconfiguration. DHCP can offer a host not only the IPv6 prefix, but also otherrelevant information as well over the same message exchange. The disadvantage of using thisprovisioning mechanism is that it requires a more complex host implementation.
Note
At the time of this writing, stateful DHCP is not commonly available on IPv6 stacks. For thisreason deployments favor the stateless autoconfiguration (for IPv6 prefix information) incombination with stateless DHCP (for other configuration information) rather than statefulDHCP.
Part I: Implementing IPv6 Services 107
Part I: Implementing IPv6 Services 107
Cisco routers do not act as DHCP servers for IPv6 stateful autoconfiguration; however, theCisco Network Registrar (CNR) can currently perform that function.
Although conceptually similar, there are several differences between IPv4 DHCP and IPv6DHCP:
Some message types, such as DHCP-DISCOVER and DHCP-OFFER, are not used inIPv6 anymore. Instead, a host discovers the DHCP server with the help of a DHCPSOLICIT, message and the server replies with a DHCP-ADVERTISE message.
•
In IPv6 DHCP, addresses are provided through message options.• An IPv6 host can request multiple addresses from the IPv6 DHCP server at the sametime.
•
Figure 3-1 shows the message exchange between a client and the DHCP server for bothprovisioning and renewal. The SOLICIT message sent by the client has the role ofdiscovering a DHCP server. It is sent to the reserved, link-local scope multicast addressFF02::1:2. In this example, the client requests a nontemporary address (IA-NA). The clientselects a server from all the ones that replied with an ADVERTISE message, and it requeststhe information of interest (nontemporary address, DNS server address, and domain list). Theserver provides the information in a REPLY message.
Figure 3-1. DHCPv6 Client-Server Message Exchange
[View full size image]
108 Part I: Implementing IPv6 Services
108 Part I: Implementing IPv6 Services
Note
For each IPv6 address received from the DHCPv6 server, the client performs DuplicateAddress Detection.
As far as the client is considered, the DHCPv6 server is located on the same link (this is thereason why it sends the SOLICIT message to a link-local scope multicast destinationaddress). However, this is most often not the case. DHCP-based provisioning is done for alllinks from a centralized location, which means that the DHCP server is not on the same linkas most hosts.
When the DHCPv6 server is not on the same link with the client, the routers on the link mustbe configured to relay the client SOLICIT messages to the DHCP server. The interfaceconfiguration command for enabling this functionality is ipv6 dhcp relay destination<ipv6-address> <interface-type interface number>. If the unicast address of the DHCP serveris known, the router is configured to forward the client messages directly to the server.Multiple DHCPv6 server addresses can be configured at the same time, in which case therouter unicasts the client messages to each server. The router can also be configured toforward the client DHCPv6 messages to another DHCP relay router. If the address of theDHCP server is not known, the relay router can be configured, with the help of the interfacecommand mentioned previously, to forward the client messages to the All-DHCP-Serversreserved multicast address FF05::1:3.
By default, the Cisco router interface advertises the information necessary for statelessautoconfiguration. To make sure that attached hosts use only stateful DHCP for provisioning,you must configure the router interface with ipv6 nd managed-config-flag. In this case, theRAs inform hosts that they must use DHCPv6 to acquire provisioning information, includingthe IPv6 address.
Note
Stopping the router from transmitting RAs is not a practical option for forcing hosts to usestateful DHCP. On one hand, the host protocol stacks might not switch to stateful DHCP ifthey do not receive a reply to their router solicitations. On the other, this approach impacts theoperation of other link-local functions such as router discovery.
Prefix delegation (PD) is a mechanism developed to provide automated delegation of IPaddress blocks. The delegation is done from an ISP to its customer. The ISP does not requireany knowledge of the customer's internal network topology.
In the IPv4 world, it is typical that the ISP only assigns a single address to the customer.Customers with more than one device are forced to use NAT. Static or long-lived addressblocks are typically delegated manually. That is, when the service is ordered, the ISP informsthe customer via e-mail or snail mail what the address block is. The customer then has tomanually configure the network with the given network prefix.
Part I: Implementing IPv6 Services 109
Part I: Implementing IPv6 Services 109
Not only is this approach error prone, it is also expensive. Because there is little reason to tryto conserve address space for IPv6, it is expected that all users will be allocated a long-livedaddress block. Therefore, a scalable way of delegating address blocks is needed. Therequirements for prefix delegation can be found in RFC 3769.
Various PD proposals were made in the IETF. An initial proposal was made for a protocolbased on Internet Control Message Protocol (ICMP). It soon became clear that therequirements and mechanisms suggested for prefix delegation would best be implementedbased on DHCP. Address assignment does not, after all, differ greatly from PD. The existingDHCP messages and the DHCP address options were used as a template to createDHCP-based prefix delegation, described in RFC 3633.
Protocol Description
The PD protocol runs between a Customer Edge (CE) and a Provider Edge (PE) router. In PDterminology, the CE is called a Requesting Router (RR) and the PE router a DelegatingRouter (DR). The RR acts as the DHCP client, and requests prefixes from the DR (DHCPserver). The DR verifies the authenticity and the profile of the RR with a AAA server, andthat server provides the prefix. The DR injects a route into the provider's routing system forthe delegated prefix on behalf of the RR. That way, a dynamic routing protocol between theRR and the DR is not needed; however, the RR and the DR must be directly connected. Thisrestriction is comparable to DHCP, as described in RFC 3315, which allows DHCP relays inthe path between the DHCP client and the DHCP server. Figure 3-2 shows this PD process.
Figure 3-2. DHCP-PD Architecture
[View full size image]
For a nondirectly connected CE-PE configuration, a DHCP relay option has been proposed. Itprovides enough information to the PE so that it can inject the route for the delegated prefix.Another alternative is to use a routing protocol between the CE and the PE. That is not asstraightforward as it might first seem. One would need a mechanism to negotiate which of the
110 Part I: Implementing IPv6 Services
110 Part I: Implementing IPv6 Services
many dynamic routing protocols to use (manual configuration isn't acceptable because itwould defeat the purpose of a fully automated solution). Making the CE responsible forinjecting routing information into the provider routing system might not be a good idea. It notonly requires the customer to be able to configure their routers correctly, it also requires theprovider to trust the customer not to be tempted to inject routes for prefixes not belonging toit. The latter case can be solved by applying route filters on the PE. Because that also requiresexplicit knowledge of the delegated prefix on the PE, it might as well also inject the route onbehalf of the CE. The PE can also apply source-address validation on incoming traffic.
A requesting router is identified by its DHCP Unique Identifier (DUID). This is an identifiercreated by the RR itself, or it can be manually configured based on information from the ISP.The DUID must be stored in stable storage so that is does not change (for example, after areboot).
DHCP-PD protocol message exchanges work just as DHCP address assignment. The RR(DHCP client) sends a SOLICIT message including PD options, and the DR (or DRs) on thelink replies with an ADVERTISE message. The RR then sends a REQUEST, again with thePD option included, and the DR delegates the prefix and includes it in a REPLY message.Similar to DHCP, an Identity Association Prefix Delegation (IA-PD) is used by the client toindicate the scope of its request. The association is labeled with an identifier (IAID) that isused throughout the message exchange. Figure 3-3 shows the PD process.
Figure 3-3. DHCP-PD Message Exchange
[View full size image]
The SOLICIT and ADVERTISE messages represent the process of the RR discoveringDHCP-PD servers (DR). In cases where an RR can have access to at most one DR (as is thecase of point-to-point uplinks), the discovery process can be eliminated and the four steps ofnegotiation can be shortened to two messages. This shortened process is called DHCP-PDRapid Commit and it can be used only if the DR supports the DHCP Rapid Commit feature.
Part I: Implementing IPv6 Services 111
Part I: Implementing IPv6 Services 111
In the case of Rapid Commit, the router provides the prefix in response to the SOLICIT.
Each delegated prefix has an associated valid and preferred lifetime, which constitutes anagreement about the length of time over which the RR is allowed to use the prefix. An RRcan request an extension of the lifetimes on a delegated prefix and is required to terminate theuse of a delegated prefix if the valid lifetime of the prefix expires.
When a prefix is about to expire, the RR sends a RENEW message. The delegating routerreplies with a REPLY message containing the prefix option with new lifetimes. During anetwork renumbering, the DR includes both the old and the new prefixes in the message. Theold one has shorter lifetimes, and after some time, typically a few weeks, the old prefixexpires, and only the new prefix is used.
Other DHCP options might, of course, also be included in these messages. For example, DNSconfiguration options or Simple Network Time Protocol (SNTP) configuration options can besent to the CE device. The CE device can run a stateless DHCP server on its downstreaminterfaces and relay these options to hosts on downstream links.
Requesting Router
The RR has to be configured to run DHCP-PD on its upstream interface (the interface facingthe provider). The RR assigns a slice of the acquired prefix to each of its IPv6-enableddownstream links. The mechanism used for assigning the prefixes is called general prefixes.
Example 3-1 shows an RR configuration. The CE has one upstream interface, Serial2/0, andtwo downstream interfaces, Ethernet0/0 and Ethernet1/0.
No manual configuration of the delegated prefix is required. The upstream interface isconfigured as a DHCP-PD client. The prefix (or prefixes) received via the PD protocol isgiven a name, genpfx-foo. The ipv6 address commands on the downstream interfaces refer tothis named prefix when configuring their own addresses. The general prefix gives the firstpart of the prefix, and the address command provides the last part of the address. Let's assumea /48 prefix. The address specified in the address command is 0:0:0:1::1. The first 48 bits arebeing replaced by the prefix or prefixes received by DHCP. The next 16 bits are 0001, and thelast 64 bits, the interface identifier, are set to ::1.
112 Part I: Implementing IPv6 Services
112 Part I: Implementing IPv6 Services
It might be easier to see how this works with the following example.
Example 3-2. General Prefix Acquired by a Router via DHCP-PD
As you can see, the prefix acquired with DHCP-PD is 2001:DB8:FF01::/48. The lifetimevalues of the prefix (valid, the amount of time the prefix is valid; preferred, the amount oftime the valid prefix is preferred) are provided by the DR in the reply, as shown in Figure 3-3.Two /64 prefixes from the delegated /48 are assigned by the CE to its interfaces Ethernet0/0and Ethernet1/0, as shown in Example 3-3.
Example 3-3. Using the General Prefix to Provision Router Interfaces
CE#show ipv6 interface Ethernet0/0Ethernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE02:8A00 Global unicast address(es):2001:DB8:FF01:1::1, subnet is 2001:DB8:FF01:1::/64 [PRE]
valid lifetime 2591041 preferred lifetime 603841CE#show ipv6 interface Ethernet1/0Ethernet1/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE02:8A01 Global unicast address(es):2001:DB8:FF01:2::1, subnet is 2001:DB8:FF01:2::/64 [PRE]
valid lifetime 2591005 preferred lifetime 603805
Note that if two prefixes were delegated, that would result in two addresses on every Ethernetinterface, each generated from the general prefix command based on the prefixes, and theinformation given in the address command. Both prefixes will be advertised in RAs sent outon the interface.
The ipv6 address autoconfig default command on the upstream Serial2/0 interface usesstateless address autoconfiguration to configure a global address on the interface. The defaultkeyword in this command leads to a default route being installed. The default route points outthe configured interface and the next hop is the delegating router. Example 3-4 shows theresult of this autoconfiguration process and the details of the routing table.
Example 3-4. Stateless Autoconfiguration Process on Upstream Interface of CE Router
CE#show ipv6 interface Serial2/0Serial2/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE02:8A00 Global unicast address(es): 2001:DB8::A8BB:CCFF:FE02:8A00, subnet is 2001:DB8::/64 [PRE] valid lifetime 2591995 preferred lifetime 604795CE#show ipv6 routeIPv6 Routing Table - 10 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
C 2001:DB8::/64 [0/0] via ::, Serial2/0L 2001:DB8::A8BB:CCFF:FE02:8A00/128 [0/0] via ::, Serial2/0S 2001:DB8:FF01::/48 [1/0] via ::, Null0C 2001:DB8:FF01:1::/64 [0/0] via ::, Ethernet0/0L 2001:DB8:FF01:1::1/128 [0/0] via ::, Ethernet0/0C 2001:DB8:FF01:2::/64 [0/0] via ::, Ethernet1/0L 2001:DB8:FF01:2::1/128 [0/0] via ::, Ethernet1/0
The output shows that a default route has been installed pointing to the DR. A /48 routetoward the Null0 interface has been installed for the delegated prefix. This so-called blackhole route makes sure that the RR has routing information for the entire delegated addressblock. Otherwise, it would forward traffic along the default route for parts of the /48 that arenot configured on the CE yet. The DR has a routing entry for the /48 toward the CE, sowithout the black hole route, you would have a routing loop. The output of the show ipv6dhcp interface command provides the information relevant to the DHCP client, as shown inExample 3-5.
Example 3-5. DHCP-PD Client-Relevant Information on the Upstream Interface
CE#show ipv6 dhcp interface Serial2/0Serial2/0 is in client mode State is OPEN Renew will be sent in 3d11h List of known servers: Reachable via address: FE80::A8BB:CCFF:FE02:8B00DUID: 00030001AABBCC028B00 Preference: 0 Configuration parameters:IA PD: IA ID 0x00040001, T1 302400, T2 483840Prefix: 2001:DB8:FF01::/48preferred lifetime 604800, valid lifetime 2592000expires at Nov 26 2004 12:03 AM (2590299 seconds)
DNS server: 2001:DB8:100::1Prefix name: genpfx-fooRapid-Commit: disabled
The preceding output lists all the options received and the state of the DHCP protocolmachine. If this output does not give enough information for troubleshooting, you can use theoutput of debug ipv6 dhcp to capture the dynamics of the delegating process.
Delegating Router
How does the DR get the larger address block from which it can delegate prefixes? There areseveral options:
114 Part I: Implementing IPv6 Services
114 Part I: Implementing IPv6 Services
Manual configuration with static binding The DUID and associated prefix areconfigured on the delegated router for each customer.
•
Using a prefix pool A pool of prefixes is configured on the DR. A new prefix isallocated from the pool dynamically. To store the state of the pool on a remote server,use the ipv6 dhcp database <URI> command.
•
Interaction with AAA The DUID or the PPP username (for link types such as PPP,which already does authentication) can be used to do a lookup from a RADIUSserver. This way no customer-specific configuration is needed on the delegatingrouter.
•
DHCP As an alternative to the above, the delegating router functionality could berunning on a central DHCP server. The PE router acts as a DHCP relay. Note that thePE router still needs to inject a route for the prefix into the provider routing system. APD-specific relay option is under development to solve this problem.
•
Example 3-6 shows the configuration of a DR using a prefix pool.
Example 3-6. Configuration of DHCP-PD Delegating Router Using Pool of Addresses
ipv6 unicast-routing!ipv6 dhcp pool pd-poolprefix-delegation pool pfx-pooldns-server 2001:DB8:100::1
!ipv6 local pool pfx-pool 2001:DB8:FF00::/40 48!interface Serial2/0 description Yet another customer ipv6 address 2001:DB8::1/64 no ipv6 nd suppress-raipv6 dhcp server pd-pool
The configured DHCP pool is called pd-pool. Prefixes should be delegated from a local prefixpool named pfx-pool, and you should include the DNS attribute with the DNS server at2001:DB8:100::1.
A /40 prefix is reserved for the pfx-pool pool, and /48-sized chunks are delegated, as shownin the Example 3-7.
Example 3-7. Prefix Assignment Form for the pfx-pool of a DHCP-PD DR
PE#show ipv6 local pool pfx-poolPrefix is 2001:DB8:FF00::/40 assign /48 prefix1 entries in use, 255 available, 0 rejected0 entries cached, 1000 maximumUser Prefix Interface00030001AABBCC028A0 2001:DB8:FF01::/48 Se2/0PE#show ipv6 routeC 2001:DB8::/64 [0/0] via ::, Serial2/0L 2001:DB8::1/128 [0/0] via ::, Serial2/0S 2001:DB8:FF01::/48 [1/0] via FE80::A8BB:CCFF:FE02:8A00, Serial2/0
Part I: Implementing IPv6 Services 115
Part I: Implementing IPv6 Services 115
In the DR's Routing Information Base (RIB), the delegated prefix is inserted as a static routewith a next hop being the RR's link-local address out Serial2/0 (as shown in the precedingexample).
The delegating server keeps state for each RR. This state is kept in a binding database that isshown in Example 3-8.
Example 3-8. Binding Database of a DHCP-PD Server Router
PE#show ipv6 dhcp bindingClient: FE80::A8BB:CCFF:FE02:8A00 (Serial2/0) DUID: 00030001AABBCC028A00 IA PD: IA ID 0x00040001, T1 302400, T2 483840 Prefix: 2001:DB8:FF01::/48 preferred lifetime 604800, valid lifetime 2592000 expires at Nov 26 2004 12:03 AM (2589457 seconds)
What DHCP-PD Does Not Do
DHCP-PD is designed to solve the simple case of delegating a prefix across theadministrative boundary between a provider and a customer. It does not solve the problem ofhow the prefix information should be propagated within the site. Router autoconfiguration hasbeen worked on in the IETF, but no solution has been agreed upon yet.
Other Configuration Information
The IETF spent a significant amount of time trying to reach a consensus on a mechanism forhosts to discover DNS servers without relying on "third-party" servers. The idea was that aslong as the on-link router worked, and the DNS server worked, no further "configurationservers" should be needed. Because DHCP is one such third-party server, it was initially ruledout as a part of the solution.
Many proposals where evaluated, among them was using the Service Location Protocol orDNS options in RAs or well-known site-local DNS addresses. As a reminder, this function ishandled by DHCP for IPv4.
Note
Note that in an environment running both IPv4 and IPv6, also called a dual-stackenvironment, the configuration information acquired from IPv4 can also be used by IPv6.That is, the IPv6 stack can use recursive name servers with an IPv4 address to resolve namesto IPv6 addresses.
116 Part I: Implementing IPv6 Services
116 Part I: Implementing IPv6 Services
Stateless DHCP
Stateless DHCP, specified in RFC 3315, is the term used to describe a simplified DHCPmessage exchange where no state is required to be kept in the DHCP server. The DHCPserver simply passes other configuration information on to the host.
Note
Network managers can configure routers to leverage the ICMPv6/Neighbor Discoveryoptions, called M bit and O bit in RAs, to signal to a host that it should use a stateful (reallymeaning DHCP) service to configure addresses and acquire other configuration information.
Nodes that use DHCP for address assignment will also obtain the other configurationinformation through the normal DHCP message exchange. Stateless DHCP is for nodes thatdo not use DHCP for address assignment (for example, stateless autoconfiguration or manualconfiguration). It is important to note that the options and messages used in stateless DHCPare the same as in "stateful" DHCP. There is no need for any special support for the statelessmode in the DHCP server or client.
The simplified message exchange between the DHCP client and server goes as follows. Theclient sends an Information-REQUEST message to request configuration parameters, and theserver replies with a REPLY message containing the configuration information.
The interface configuration command ipv6 nd other-config-flag enables the router to indicate,through RAs, to attached hosts that they should use stateful DHCP to acquire provisioninginformation other than the IPv6 prefix. A router configured this way sets the OtherFlag fieldto 1 in its RAs, as shown in the output of show ipv6 routers on a neighboring router (Example3-9).
Example 3-9. Output of show ipv6 routers on a Neighbor to a Router Advertising an OtherFlagValue of 1
Router#show ipv6 routersRouter FE80::20D:29FF:FEE1:4DC0 on TenGigabitEthernet9/1, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 0 msec Prefix 2001:A:A:A::/64 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800Router FE80::200:FF:FE01:F on GE-WAN1/4, last update 1 minHops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=1, MTU=1500
HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 0 msec Prefix 2001:B:B:B::/64 onlink autoconfigValid lifetime 2592000, preferred lifetime 604800
DNS Services
The Domain Name System (DNS) represents a resource and a mechanism that facilitatescalable deployments of IP services. It is a distributed database that stores name-to-IP addressmapping information. This information helps users to identify the IP address of other hosts or
Part I: Implementing IPv6 Services 117
Part I: Implementing IPv6 Services 117
network resources based solely on the name of their destination or vice versa.
Name servers store the DNS data records, called Resource Records (RRs). There are ofseveral types RRs):
Start of Authority (SOA) Marks the beginning of a DNS zone, typically the firstrecord for that domain in that Name Server.
•
Name Server (NS) Provides the domain name of a server in a DNS zone.• Canonical Names (CNAMEs) These are aliases for fully qualified DNS names.• Address (A) Matches domain names to IP addresses.• Pointer (PTR) Is an alias for another location in the domain name space. The mostcommon use of the PTR RR is to construct the in-addr.arpa.com domain that providesthe name corresponding to a given IPv4 address.
•
The IP address-to-name mapping is resolved by hosts, also called resolvers, through queriessent to the NSs for the necessary RRs (see RFC 1035). To expand the DNS functionality toIPv6, three aspects of the process had to be considered):
Define a new record that would store the 128-bit IPv6 address.• Define the IPv6 equivalent for the in-addr.arpa.com domain for the IPv4 PTR.• Define the changes to the query messages and the method of transporting thembetween the Resolvers and the NS.
•
AAAA Records
Two solutions were proposed for the first aspect of the DNS process: the AAAA recordspecified in RFC 3596; and the A6 record specified in RFC 2874, which is a super set ofAAAA. The A6 could store records where the prefix portion of the address can be modifiedwith no action from the administrators of the DNS zone. This could prove helpful whenperforming a network renumbering. On the other hand, the AAAA records are similar to theA records used in IPv4, and that makes them more palatable to network and service operators.The AAAA records are also optimal to be read by the Resolver, and they store the completeaddress (see RFC 3364). The IETF DNSEXT working group decided that the AAAA recordsare preferable for production deployments, whereas the A6 ones were moved to anexperimental status. For more information on the AAAA versus A6 discussion, refer to RFC3363 and RFC 3364.
IP6.ARPA Domain
Similar to IPv4, a special domain is defined to find the host names that match an IPv6address. In the case of IPv6, the root of this domain is IP6.ARPA; it was formerly IP6.INT.The record representing an IPv6 address is built by listing it as a set of dot-separated nibbleslisted in reverse order terminated by .IP6.ARPA. Such a record is exemplified in Table 3-2alongside an AAAA record.
Table 3-2. IPv6 vs. IPv4 DNS Resource RecordsIPv4 IPv6
Name to IP Address A Resource Record:
www.example.com A172.18.140.154
AAAA Resource Record:
www.example.com AAAA 2001:1:F:1:F:1:F:1
IP Address to Name PTR Resource Record: PTR Resource Record:
To work in a dual-stack environment, the NS, Location of Services, and Mail Exchange query types have beenmodified. A DNS server replies to queries with both IPv4 and IPv6 information it holds (RFC 3596). In otherwords, when a dual-stack host queries an NS for the IP address corresponding to a given name, the replycontains an IPv4 and IPv6 address if both are in the RR. The node then selects the one it is interested in.
All query messages can be transported in UDP or TCP on top of either IPv4 or IPv6, regardless of the IPversion used in the request. IPv6-specific records can be transported over IPv4 and vice versa.
Note
The choices available in transporting the DNS queries can lead to problems under certain circumstances. If thelocal DNS server is IPv6 only and the root NS for the domain is IPv4, the name resolution is not possiblebecause the host cannot reach the NS.
Another example is that of a recursive search for the NS with a name's longest-match RR. The local DNSserver resides in an IPv4-only network and climbs up the tree starting with the root NS. The queries areexchanged over IPv4. If the targeted NS is IPv6 only, the name resolution cannot take place.
Deployment consistency and dual-stack DNS servers would avoid the problems described in this note.
With the exception of the changes mentioned and described previously, the DNS functionality for IPv6 issimilar to that of IPv4. The similarity resides in both implementation and in operation. For this reason, thefunctionality can be managed based on the experience gained with running IPv4 networks.
IPv6 Network Access
The access layer (AL) can be defined as the set of network elements that accommodates the media types andthe protocols used to transport the user traffic into and out of the network. It is made of layer 2 devices such asEthernet switches, digital subscriber line access multiplexers (DSLAMs), wireless access points, as well aslayer 3 devices and routers. All of them are part of the same network management domain as the rest of thenetwork (distribution and core layers). Depending on the design and service offering, the user traffic can exitthe AL at layer 2, in which case the IP version might not matter, or it can exit at layer 3.
The AL enables users to connect to the network, via an enterprise intranet or a service provider, and theservices provided by it. Figure 3-4 depicts a few of the many types of users accessing a network:
Employee's PC on corporate network• Home or mobile users connecting to their service provider• Small offices/home offices (SOHOs) accessing a service provider• Large businesses accessing a service provider that interconnects their campuses•
A user can mean a simple device such as a PC or appliance or it can mean an entire private network.
This section covers how to enable IPv6 unicast connectivity across the AL.
Media Types
The IPv6 AL supports the same media types as the IPv4 AL, but IPv6 implementations might not supportsome types because of market obsolescence:
Dialup (PSTN), Integrate Services Digital Network (ISDN)• Digital subscriber line (DSL) with all its variants: symmetrical, asymmetrical, and very high data rateDSL
Data Over Cable Service Interface Specification (DOCSIS 3.0 for native IPv6 support)•
120 Part I: Implementing IPv6 Services
120 Part I: Implementing IPv6 Services
Leased line service: E1, T1, SDH/SONET, and so on• Non-Broadcast Multiple Access (NBMA), such as ATM or Frame Relay•
Note
Cisco IOS software does not support IPv6 over obsolete media types such as ARCNET, FDDI, or TokenRing. Cisco IOS software does not offer an implementation of Switched Virtual Circuits (SVCs) for ATM.
Note
Even though IPv6 supports the same media types as IPv4, some IPv6-specific details must be considered. Theway each media type handles multicast is important, because of its use in basic protocols such as NeighborDiscovery. Examples:
Turning on a multicast snooping feature on Ethernet switches might isolate users from criticalmulticast traffic. (See Chapter 6, "Providing IPv6 Multicast Services," for more details.)
•
In the case of NBMA, handling of multicast traffic is critical to the proper operation of NeighborDiscovery. This topic is discussed in RFC 2491.
•
With the exception of cable networks, in all these cases IPv6 can be deployed natively. With cable access, thenetwork elements, their functionality, and their operation are standardized in the DOCSIS specifications. In itslatest version (DOCSIS 2.0) and in the versions used in today's cable networks, IPv6 is not explicitlysupported. Missing pieces include the following:
Explicit support of IPv6 on the cable modems (CM) and cable modem terminating systems (CMTSs).• Starting with DOCSIS 1.1, the CM is not allowed to forward multicast traffic from the cable to theEthernet interface unless it snooped an Internet Group Management Protocol (IGMP) join message onthat user interface. In IPv6, multicast is a critical part of basic operation, such as Neighbor Discovery.In the framework of the current DOCSIS specifications, Multicast Listener Discovery (MLD)snooping must be implemented on the CM to support a native IPv6 deployment.
•
QoS is implemented in cable networks independent of the layer 3 QoS functionality. For this reason,the CM and the CMTS have to be capable of classifying IPv6 traffic. Until such capabilities areavailable, all IPv6 traffic would be forwarded Best Effort with impact on time-sensitive applications.
•
Several proposals were made to address these gaps in the DOCSIS specifications. Until implemented, cableoperators have to tunnel the IPv6 traffic across the cable networks.
Native IPv6 Access
The simplest way to provide IPv6 connectivity to the network users is to do it nativelythat is, by encapsulatingthe IPv6 packet in layer 2 header and trailer, no tunneling over IPv4. Depending on the network design, youshould consider three scenarios:
Routed access The user-facing interface of the access router is not bridged. In this case, the IPv6packets are encapsulated in an Ethernet frame on the output interface, as defined in RFC 2684.
•
Bridged access The user-facing interface of the access router is bridged, as in the case of an RFC2684 bridged Permanent Virtual Circuit (PVC).
•
Part I: Implementing IPv6 Services 121
Part I: Implementing IPv6 Services 121
Point-to-Point Protocol (PPP)-encapsulated IPv6 The user traffic is sent over a PPP session set upbetween a customer device and the AL.
•
Routed Access
If the infrastructure permits it, the simplest way to provide IPv6 access over any media type with theexception of cable networks is to terminate each layer 2 domain (PVC, VLAN, WLAN) on a routed accessaggregator interface. In this case, the customer premises equipment (CPE) has to be enabled for IPv6. ForEthernet and wireless access, the configuration is straightforward: global prefix under the main or thedot1Q/ISL-encapsulated subinterfaces. In the case of DSL and ATM PVCs, in general, the routed RFC 2684encapsulation is used with a different IPv6 prefix defined for each one of the PVCs.
Bridged Access
In IPv4, service providers prefer to bridge their DSL customers in a single IP subnet to save address space.The user traffic reaches the access router over an RFC 2684 bridged PVC. The traffic can be picked up fromthe bridge through a virtual interface, as in the case of Cisco IOS Integrated Routing and Bridging (IRB), orthrough the use the Cisco IOS Routed Bridged Encapsulation (RBE) feature. The latter solution is the mostcommonly used in today's IPv4 DSL deployments.
IPv6 RBE is a feature that allows the router to pick up the IPv6 traffic from the bridged encapsulation androute it. Figure 3-5 presents the typical topology in which the IPv6 RBE feature is used. The figure depicts theunderlying technologies over which the IPv6 packet is transported.
Figure 3-5. IPv6 RBE
[View full size image]
When a bridged ATM PVC has the IPv6 RBE feature enabled on the access concentrator (Figure 3-5), it canbe configured with an IPv6 address allowing it to terminate the layer 2 domain and route the IPv6 trafficthrough the rest of the network. Example 3-10 shows this configuration, with the IPv6 address and the RBEconfiguration highlighted.
The interface configuration line no ipv6 nd suppress-ra explicitly re-enables the router to send RAs over thatPVC. In this case, the CPE is bridging the traffic, and because it is IPv6 unaware, it does not have to beupgraded. All the nodes in the customer site are part of the 2001:1:1:1::/64 network.
Note
Note that IPv6 RBE is different from IPv4 RBE. With the latter, all subscribers connecting to the same accessrouter are part of the same IPv4 subnet. With IPv6 RBE, each PVC has its own IPv6 subnet.
PPP-Encapsulated IPv6 Access
PPP is used on point-to-point media such as leased lines, dialup, and DSL. Service providers also use it toemulate a point-to-point link over Ethernet, as in the case of Point-to-Point Protocol over Ethernet (PPPoE).This enables an ISP to better manage its customers or a network access provider (NAP) to hand over customermanagement to an ISP.
When the ISP controls the AL, it can terminate the PPP sessions at the network access server (NAS), part ofthe AL. With DSL, the access media chosen for these examples, there are two ways in which the PPPencapsulation can be done, as follows:
PPP over ATM (PPPoA)• PPP over Ethernet (PPPoE)•
PPP over ATM
In this scenario (Figure 3-6), the user IPv6 traffic is natively forwarded to a CPE that has an ATM PVCestablished over DSL to the access concentrator (NAS). The user traffic is encapsulated and transported via aPPP over ATM AL 5 (AAL5) established between the CPE and the NAS.
Figure 3-6. IPv6 over PPPoA
[View full size image]
Part I: Implementing IPv6 Services 123
Part I: Implementing IPv6 Services 123
The CPE has to route the IPv6 user traffic, and that means it will have to be upgraded to be a dual-stackrouter. A RADIUS server is used to authenticate and authorize the CPE-initiated PPP session. It also performsaccounting functions.
The configuration of a PPPoA setup is similar for IPv4 and IPv6. On the CPE, the PVC to the service provideris associated with dialer 1. This is shown in the following example:
The dialer interface is configured for PPP, to use Challenge Handshake Authentication Protocol (CHAP) forauthentication and to accept and autoconfigure an address for itself, as highlighted in Example 3-11.
Example 3-11. CPE PPP Configuration with CHAP Authentication
interface Dialer1encapsulation ppp dialer pool 1 dialer-group 1ipv6 address autoconfigppp authentication chap dsl ppp chap hostname [email protected] ppp chap password PASSWORDppp ipcp address accept
The dialer interface is also configured with the host name and password that it will use to identify itself whenopening the PPP session. When the PPP session is up and the dialer interface has an IPv6 address assigned bythe provider, the CPE has to know where to route the user traffic. For this, a default IPv6 route points alltraffic out the dialer interface, as shown here:
ipv6 route ::/0 Dialer1
124 Part I: Implementing IPv6 Services
124 Part I: Implementing IPv6 Services
The NAS has to be configured to terminate the 1/32 PVC and associate it with a virtual template:
The virtual template is instantiated every time a user attempts to open a session. The authentication protocol(CHAP) is defined along with the pool from which a prefix is assigned to the PPP session. Because of theadditional headers introduced by PPP, an adjustment is made to the maximum transmission unit (MTU) sizeused over this PPP 0session. Example 3-12 shows the key configuration elements.
Example 3-12. NAS PPP Configuration with CHAP Authentication
interface Virtual-Template1 ipv6 enableipv6 mtu 1480
no ipv6 nd suppress-rappp authentication chappeer default ipv6 pool dsl
The dsl pool assigns /64 prefixes from a /56 prefix:
ipv6 local pool dsl 2001:1:1::/56 64 cache-size 1000
User authentication/authorization can be performed locally on the NAS or with the help of a RADIUS server.In the latter case, the following has to be globally configured on the NAS (Example 3-13).
Example 3-13. Relevant Configuration for Using RADIUS Authentication
aaa new-modelaaa authentication login default noneaaa authentication ppp default group radiusaaa authorization network default group radiusaaa accounting network default wait-start group radius!radius-server host 172.18.139.17 auth-port 1645 acct-port 1646radius-server key radius-password
Although IPv6-specific RADIUS attributes are used in this implementation, the NAS is communicating withthe RADIUS server over IPv4. It is expected that the RADIUS connection to the NAS will be in place fromthe operating IPv4 service.
When the CPE establishes the PPP session to the NAS, an instance of the virtual interface is created from thetemplate, and the first prefix from the pool is assigned to the session, as shown in Example 3-14.
Part I: Implementing IPv6 Services 125
Part I: Implementing IPv6 Services 125
Example 3-14. Output Example Showing Information Relevant to an Established PPP Connection
NAS#show ipv6 interface Virtual-Template1 prefixIPv6 Prefix Advertisements Virtual-Access1Codes: A - Address, P - Prefix-Advertisement, O - Pool X - Proxy RA, U - Per-user prefix, D - Default N - Not advertised, C - Calendar
O 2001:1:1::/64 [LA] valid lifetime 2592000 preferred lifetime 604800NAS#show ipv6 local pool dslPrefix is 2001:1:1::/56 assign /64 prefix1 entries in use, 255 available, 0 rejected0 entries cached, 1000 maximum
User Prefix Interfacedsl 2001:1:1::/64 Vi1
You can use the troubleshooting steps used for IPv4 PPP deployments to troubleshoot IPv6 PPP, too.
PPP over Ethernet
With PPPoE (specified in RFC 2516), the PPP session is established over bridged AAL5 protocol data units(PDUs). Its operation is similar to that of PPPoA, as shown in Figure 3-7; but with PPPoE, you have twodeployment options:
The CPE initiates the PPPoE session (similar to PPPoA). In this case, the CPE has to be upgraded todual stack.
•
The user's host initiates the PPPoE session. In this case, the CPE just has to bridge the traffic to theNAS.
•
Figure 3-7. IPv6 over PPPoE
[View full size image]
126 Part I: Implementing IPv6 Services
126 Part I: Implementing IPv6 Services
Note
The advantage of having the user initiate the PPPoE session is that the CPE is IPv6 unaware, so it does nothave to be upgraded to deploy IPv6.
The disadvantage with this model is that each of the customer's nodes needs a separate PPP session to the ISP.Communication between the user's hosts will go via the ISP.
In the case where the PPPoE session is initiated from the hosts, the CPE is simply configured to bridgebetween its Ethernet interface and the ATM PVC to the NAS. When the CPE is initiating the PPPoE session,its configuration is similar to that of a PPPoA CPE. In this case, dialer and default route configurations are thesame, whereas the PPPoE-specific portion is as follows:
The NAS configuration is the same in both cases. The RADIUS, virtual template, and pool configuration isidentical to the example presented in the PPPoA section. The PPPoE-specific elements are as follows:
In addition to the PPP-relevant show commands and debugs, you can use PPPoE-specific commands such asshow vpdn and debug vpdn pppoe-events.
Note
Although this configuration example was given for a DSL access type, the same applies if the access isEthernet for a Fibre To The Home (FTTH) user.
Virtualized Access Layer
A wholesale network access provider (NAP) is not interested in handling subscribers at layer 3. Afterproviding broadband access, the NAP tunnels the subscribers to an ISP for address assignment and IP trafficforwarding. In other words, the NAP provides the ISP with a virtual AL. Figure 3-8 shows a conceptualrepresentation of a NAP's operation.
Figure 3-8. Virtualized Access Layer Using L2TP
[View full size image]
128 Part I: Implementing IPv6 Services
128 Part I: Implementing IPv6 Services
In today's IPv4 wholesale service provider networks, the most commonly used aggregation method is that oftunneling the PPP-encapsulated user traffic over a Layer 2 Transport Protocol version 2 (L2TPv2) tunnel tothe ISP. However, L2TPv2 can be used only if the user is accessing the network via PPP. Otherwise, theoption is to bridge the user traffic to the ISP over an L2TPv3 tunnel (Figure 3-8).
L2TPv2 Access Aggregation
In this scenario, the NAP collects the PPP sessions at the L2TP access concentrator (LAC) that is part of theAL and sends them over an L2TPv2 tunnel to the L2TP network server (LNS), where the PPP sessions areterminated (see Figure 3-9).
Figure 3-9. L2TPv2 Aggregation
[View full size image]
Part I: Implementing IPv6 Services 129
Part I: Implementing IPv6 Services 129
Example 3-15 shows the key configuration items of the LAC.
Example 3-15. LAC Configuration in an L2TPv2 Aggregation Deployment Model
vpdn-group 1 request-dialin protocol l2tp domain domain.net initiate-to ip 172.18.141.121 source-ip 172.18.140.1 local name lac-example!interface Loopback0ip address 172.18.140.1 255.255.255.255!interface FastEthernet0ipv6 address 2001:100:100:100::1/64
The virtual template interface borrows the IPv6 address of FastEthernet0. The L2TP tunnel is set up over IPv4between the LAC (172.18.140.1 and identifying itself as lac-example when setting up the tunnel) and the LNS(172.18.141.121), which has the configuration shown in Example 3-16.
Example 3-16. LNS Configuration in an L2TPv2 Aggregation Deployment Model
vpdn enable!vpdn-group 1accept-dialin
130 Part I: Implementing IPv6 Services
130 Part I: Implementing IPv6 Services
protocol l2tpvirtual-template 2terminate-from hostname lac-examplelocal name lns-example
!interface Virtual-Template1ipv6 mtu 1480ppp authentication chap defaultpeer default ipv6 pool dsl
!ipv6 local pool dsl 2001:1:1::/56 64
The AAA configuration on both LAC and LNS is similar to that of the NAS in the PPP section of this chapter.The prefixes are assigned from the same pool (dsl) but in this case by the LNS.
Note
Note that the L2TPv2 tunnel is set up over the IPv4 network. This is a reasonable approach, because it wouldmost likely leverage existing L2TP infrastructure used for IPv4 traffic.
L2TP over IPv6 is also available for SPs that plan to parity between IPv4 and IPv6 in terms of servicedeployment.
The status of the PPP and L2TP sessions can be viewed on the LAC, as shown in Example 3-17. The tunnel tolns-example with IP address 172.18.141.121 is shown in established (est) state.
Example 3-17. Status of PPP and L2TP Sessions on a LAC Router
LAC#show vpdn%No active L2F tunnelsL2TP Tunnel and Session Information Total tunnels 1 sessions 1LocID RemID Remote Name State Remote Address Port Sessions L2TP Class/ VPDN Group28361 58155 lns-example est 172.18.141.121 1701 1 1LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit24189 24189 28361 [email protected], - est 11w4d 1655
The LNS de-encapsulates the IPv6 traffic from L2TP and PPP and then routes it across the ISP network.
L2TPv3 Access Aggregation
L2TPv3 offers SPs a mechanism to create a pseudowire between the user-facing interfaces of two distinctaccess routers (when interconnecting two customer sites together) or the interface toward the ISP (whenproviding access to an ISP). The two endpoints are part of the same layer 2 domain, and there is no need forPPP encapsulation. This tunneling mechanism can be applied to Ethernet and Frame Relay interfaces. Similarto the L2TPv2 case, the tunnel is set up over IPv4 (Figure 3-10).
Part I: Implementing IPv6 Services 131
Part I: Implementing IPv6 Services 131
Figure 3-10. L2TPv3 Aggregation
[View full size image]
When applied to the interface, the protocol can be instructed to match only the IPv6 traffic based on its0x86DD Ethertype and send it over the tunnel. The IPv4 traffic will be routed as usual by the router.
In Figure 3-10, the L2TPv3 tunnel is set up over IPv4 between routers AC1 (172.18.140.1) and ISP1(172.18.141.121). An IPv6-user pseudowire class was defined on each router. Example 3-18 shows therelevant configuration of the routers in Figure 3-10.
Example 3-18. Configuration of Routers in an L2TPv3 Aggregation Deployment Model
The L2TPv3 approach proves useful in offering SOHO or other businesses a native IPv6 link betweencampuses or to an IPv6 ISP. For broadband users, however, the L2TPv2 would probably scale better.
132 Part I: Implementing IPv6 Services
132 Part I: Implementing IPv6 Services
Access over Tunnels
IPv6 over IPv4 tunnels can be used over various segments of a network, and the reasons for using them fallinto one or more of the following categories:
They represent a quick and inexpensive way to provide IPv6 connectivity. Although the endpointshave to be upgraded to dual stack, the rest of the traversed network is unaffected.
•
They offer a solution to transporting IPv6 traffic across network domains that are not managed by thesame entities.
•
They offer the means to transport the IPv6 traffic over portions of the network where the deploymentof native IPv6 is not yet technically possible. Either the underlying layer does not fully support IPv6(as mentioned in the case of cable networks) or the network elements do not support the new protocol.
•
At the AL, all these reasons can justify the use of tunnels. In particular, tunneling is sometimes a viable optionin this portion of the network because its interface with devices of various types and capabilities, devices thatcannot be easily upgraded to support IPv6 natively. For a service provider, it might be cost-ineffective toreplace or upgrade all CPE used in providing broadband access to home users.
Various tunneling mechanisms were developed to deal with deployment challenges such as traversing IPv4NATs or scaling to a large number of sites. Table 3-1 in the "Overview" section of this chapter summarizesthe IPv6 over IPv4 tunneling types currently in use along with their key features. Some of these tunnelingmechanisms are intended to provide IPv6 connectivity to hosts only so they are used specifically in the ALportion of the network. These tunnels are discussed in more detail in this section. The others can be used tointerconnect sites as well as hosts and thus can be used in any part of the network. To show them applied invarious contexts, some of them are presented in this section; the others are presented in the "IPv6 over theBackbone" section of this chapter.
Manually Configured Tunnel
The manually configured tunnel (MCT) was one of the first transition mechanisms developed for IPv6. Forthis reason, MCT is supported by most IPv6 implementations, making it a safe choice when different vendorsmake the tunnel-termination devices. MCT is a static, point-to-point tunnel. It terminates on dual-stackrouters. The tunnel endpoint's IPv4 addresses have to be routable in the transitioned domain. A fixed IPv6prefix has to be configured on the tunnel interfaces. Figure 3-11 shows the relevant router configuration forthe MCT.
Figure 3-11. Configured Tunnel
[View full size image]
Part I: Implementing IPv6 Services 133
Part I: Implementing IPv6 Services 133
In the case of the network AL, the tunnel is typically set up between a CPE or the user's host and a routerwithin the AL. Figure 3-11 shows an example of a configured tunnel between a CPE with IPv4 address200.15.15.1 and the provider access router with IPv4 address 200.13.13.1.
Note
In Cisco IOS systems, the RA feature is turned off by default on tunnel interfaces. If the RAs need to beexchanged over the tunnel interface, the feature should be re-enabled, as shown in the configuration exampleof no ipv6 nd suppress-ra.
The static, manually configured nature of the tunnel makes it difficult to scale and manage. It is not suitablefor providing access to home users where significant provisioning and scalability issues would impact thedeployment. MCT is better used in linking a few customer (enterprise or ISP) sites in a fixed, long-termtopology.
Tunnel Broker and Tunnel Server
The MCT is suitable for the static setup of interconnecting IPv6 locations. If used for connectivity of a largenumber of isolated hosts, static management of the MCT would not scale. The tunnel broker is a resource(outside of the routers terminating the MCT) that can automatically configure on a router the endpoint of thetunnel requested by a host. The host communicates with the tunnel broker over IPv4.
The tunnel server is an additional feature of the tunnel broker where the broker functionality is performed bythe same device that terminates the tunnel. Both these mechanisms are attempting to provide means to scalethe MCT solution when delivering IPv6 unicast service to a large number of isolated hosts.
Note
Neither tunnel broker nor tunnel server is supported in Cisco IOS software. Tunnel broker functionality can beachieved with an interoperating third-party device that acts as the broker.
134 Part I: Implementing IPv6 Services
134 Part I: Implementing IPv6 Services
Teredo
NATs are a pervasive fact in today's IPv4 networks. Most IPv6 over IPv4 tunneling mechanisms cannottransit NAT because of the protocol number used (41 for configured tunnel, for example). This means that if auser's NAT router cannot be upgraded to support tunneling mechanisms, no tunnels can be sourced from thecustomer site. Teredo, or the shipworm, was developed to solve this problem. It provides address assignmentand host-to-host, automatic tunneling for unicast IPv6 connectivity when hosts are located behind IPv4NAT(s). Teredo tunnels carry the IPv6 data encapsulated in IPv4 UDP datagrams (port 3544).
A Teredo client, located behind NAT, knows the IPv4 globally unique address of a Teredo server. The clientinitiates the tunnel by contacting the server, which in turn signals the setup process to a Teredo Relay routerconnected to the IPv6 domain that has to be reached. The server is a stateless device and just proxies thetunnel setup process. The operation of the Teredo tunnel is described in detail in the latest revision of InternetDraft draft-huitema-v6ops-teredo.
Note
In a Teredo-based deployment, a router can perform the function of a server or a relay. However, thistunneling mechanism is not supported in Cisco IOS software.
Teredo is a last-resort transition mechanism for providing IPv6 connectivity. It is limited to host-to-host typesof tunnels (as opposed to edge to edge or host to edges), and it is not a practical solution for providers to use itfor the deployment of a paid service. If the infrastructure (CPEs and access routers) supports it or if/whenIPv4 NAT handles protocol translation 41, the deployment should focus on native IPv6, 6 to 4, or ISATAPconnectivity, as discussed in the next sections.
ISATAP
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specified in RFC 4214 was designed toprovide a scalable tunneling mechanism within a privately addressed or globally addressed IPv4 site. Similarto other tunneling mechanisms, ISATAP encapsulates IPv6 in IPv4 using ip-protocol 41, so it does not workthrough NAT. ISATAP treats the underlying IPv4 infrastructure as an NBMA link layer. This mechanism isautomatic; after the router has been configured, any client or other router within the site that is aware of itsexistence can establish a tunnel to it. It is standardized in the latest version of draft-ietf-ngtrans-isatap.
Note
Note that because of the automatic nature of the tunnel, access control has to be implemented to make surethat not all nodes that learn about an ISATAP router establish a tunnel with it.
The key concept of ISATAP operation is that of the ISATAP format interface ID. Chapter 2 showed how tobuild an EUI-64 format interface ID from the layer 2 address. You can use a similar concept if considering theIPv4 infrastructure as the link layer on which IPv6 is running. In the case of ISATAP, the first 32 bits of theinterface ID are 0000:5EFE; the other 32 are the IPv4 address of the interface, as shown in Example 3-19.
Part I: Implementing IPv6 Services 135
Part I: Implementing IPv6 Services 135
Example 3-19. Building an ISATAP Format Interface ID
IPv4 Address 200.15.15.1IPv4 Address in hexadecimal format C80F:0F01ISATAP-format Interface ID 0000:5EFE:C80F:0F01
This interface ID can be appended to a link-local, a unique-local, or a global unicast prefix.
Hosts configured with an IPv4 address and then enabled for ISATAP automatically build a link-local addressbased on the mechanism described in the preceding example. They can then do a name service lookup for thewell-known service ISATAP and download the list of IPv4 addresses of the ISATAP operating routers in thatdomain. This enables the hosts to establish an ISATAP tunnel to one of these routers. The client sends aRouter Solicitation and, with the suppression of RAs being explicitly disabled on the tunnel interface of therouter, it will receive the necessary information to autoconfigure. Figure 3-12 shows a configuration examplefor an access router terminating ISATAP tunnels of users.
Figure 3-12. ISATAP Tunnel
[View full size image]
A look at the IPv6 properties of the tunnel interface reveals the concepts of this tunneling mechanism (seeExample 3-20).
Example 3-20. Status of ISATAP Tunnel Interface
Access-Router#show ipv6 interface tunnel 100Tunnel100 is up, line protocol is up IPv6 is enabled, link-local address is FE80::5EFE:C80D:0D01 Global unicast address(es): 2001:300:1:F:0:5EFE:C80D:0D01, subnet is 2001:300:1:F::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF0D:0D01
136 Part I: Implementing IPv6 Services
136 Part I: Implementing IPv6 Services
The interface ID used for the link-local, unique local and/or the global IPv6 addresses is generated from theIPv4 address.
The ISATAP tunnels can be used between the routers within a site. The router configuration will be the sameas the one presented in Figure 3-12.
Considering the fact that within an enterprise or inside a provider's network it is unlikely to have to deal withNAT, ISATAP represents a practical way to provide IPv6 access to hosts and to interconnect IPv6 locations.In the case of broadband users, this tunneling mechanism might not be usable because of NAT. ISATAPcould still be used in such scenarios if the tunnels are set up from the CPEs that have an IP address routablewithin the provider's network.
ISATAP is particularly suited for providing IPv6 access to individual, isolated dual-stack nodes within anIPv4 site. Its mode of operation also lends itself well to ad-hoc networking, and this proves useful for 3GPPnetworks.
IPv6 over the Backbone
The backbone network can be defined as the network portion of the communicationsystem that provides aggregation, interconnection, and transfer between networkaccesses defined in the "IPv6 Network Access" section.
In a simple case, the backbone network is a single ISP infrastructure. Considering thecomplexity of the Internet, the backbone network is a combination of enterprises and ISPnetworks. In a typical topology, the backbone starts at the enterprise and spreads overseveral ISPs.
Note that although some of the methods for transporting IPv6 customer traffic over thebackbone assume that the backbone itself supports IPv6, others envision the case whereit does not. In that context, the transitioning and coexistence mechanisms are of primaryimportance.
There are basically three different approaches for deploying IPv6 over the backbone:
Dual-stack routers and links IPv4 and IPv6 share the same link layer, and corerouters run both IPv4 and IPv6 stacks.
•
IPv6 (and IPv4) uses a separate link layer Some service provider backbones aresimply using a layer 2 technology such as Frame Relay, ATM or Packet overSONET (PoS) to transport IPv4 traffic between edge routers. To establish IPv6connectivity, routers attached to the ISP WAN or MANs can use the same layer2 infrastructure as IPv4, but over separate ATM or Frame Relay PVCs, or overdifferent optical lambda. Layer 2 links are terminated at the Internet exchangepoint or on the autonomous system boundaries where IPv6 (or dual-stack)routers handle layer 3 connectivity to the Internet or other ISPs.
•
IPv6 on the edges, and tunnels to traverse the backbone•
The long-term objectivesfor instance, deploy some IPv6 service (for an enterprise), offeran IPv6 access (for the ISP), transition from IPv4 to IPv6should drive tactical as wellstrategic choices. In the most likely scenarios, where IPv4-based networks are dominantin the backbone, tactical choices will typically deal with tunnel deployments, whereasdual-stack backbones will be seen as the long-term strategy. Tunnels tend to be initially
Part I: Implementing IPv6 Services 137
Part I: Implementing IPv6 Services 137
cheaper to deploy because they deal with a subset of the backbone nodes. On the darkside, they deliver suboptimal paths in most cases while causing packet overhead (in theform of an extra header). Tunnels also carry some configuration and managementoverhead, which grows with the number of tunnels, getting to a crossing point where itbecomes more cost-effective to migrate to dual-stack backbone.
When tunnel mechanisms are used to transport IPv6 traffic over the backbone, tunnelendpoints can always be set up between edge-router pairs (PE) or betweencustomer-router pairs (CE).
Networks where a layer 2 transport technology or MPLS have been already deployedmay keep IPv6 on the edge for a long time.
IPv6 connectivity across the backbone can be set up with multiple segments managedindependently, using a variety of IPv6 transport mechanisms. For instance, the enterprisecould decide to deploy a dual-stack network, and be attached to an MPLS ISP providingnative IPv6 access through 6PE, itself connected to a second ISP providing IPv6 overIPv4 tunnels. The IPv6 traffic across the backbone will follow these network segments,so the mechanisms reviewed hereafter become building blocks assembled to enable IPv6connectivity end to end. Although a particular enterprise or ISP will make its ownchoices and set up its own strategy for transporting IPv6 traffic, it will also have to dealwith choices and strategies of other networks with which it is peering.
Native IPv6
The backbone network can provide the IPv6 connectivity by enabling IPv6 on all routersand the links interconnecting them. In theory, nothing prevents the backbone from beingIPv6 only, but it remains likely that an existing IPv4 network will coexist with the IPv6network. You have several strategies to choose from when deploying the IPv6 network:
Upgrade all existing routers to dual stack, and set up the network to provideIPv6 connectivity.
•
Upgrade a subset of the existing routers to dual stack, establish IPv6 dedicatedcircuits between them, and set up the IPv6 network as an overlay network on topof the IPv4 network. The circuits can be ATM or Frame Relay, using PVCs orSVCs.
•
Build an IPv6 network as a parallel network to the existing IPv4 network. Thisscenario includes the case where an IPv6 network is built from scratch, withoutconsiderations on transition or coexistence.
•
In all of these cases, the IPv6 topology is likely to be different from the IPv4 topology.The IPv6 routers need to be configured with routing protocols, interface addresses,ACLs, QoS, and so on. Chapter 4, "IPv6 Routing Protocols," discusses routingprotocols, but the extra configuration and operation costs of running two sets of routingprotocols in the backbone are worth mentioning in the dual-stack approach.
Although the dual-stack approach carries twice the complexity of single stack, it appearsto be the natural choice in the long run. It is the only one that allows separating at thefinest level IPv4 and IPv6 topologies and services in the core. It is also the onlyapproach that does not have to worry about traversing NATs (when leaving theenterprise boundaries), and it can support IPv6 multicast properly.
However, before investing in a dual-stack deployment throughout the backbone,
138 Part I: Implementing IPv6 Services
138 Part I: Implementing IPv6 Services
remember that tunneling mechanisms offer a reasonable intermediary step. Manytunneling mechanisms exist, and they are covered throughout the remainder of thischapter. You should see, however, that dual-stack deployments do not compete withtunneling; instead, they complement each other during the transitioning period.
IPv6 over IPv4 Tunnels
When the backbone network does not support IPv6, some tunneling mechanism isrequired. IPv6 over IPv4 tunnels encapsulates IPv6 traffic into IPv4 packets to traversethe IPv4 backbone. Many tunneling mechanisms are available for deploying IPv6: Theydiffer by the location of the tunnel endpoints and the way these endpoints aredetermined. All of them, however, require the tunnel endpoints to be dual stack. Twotunnel mechanisms have started to emerge in the context of an IPv4-only backbone:MCTs, among which IPv6 over IPv4 GRE tunnel is one; and automatic tunnels, inparticular 6 to 4 tunnels. Other tunneling mechanisms, typically deployed on hosts, arediscussed in the "IPv6 Network Access" section.
IPv6 over GRE
IPv6 over Generic Routing Encapsulation (GRE) tunnels represent another type ofMCT; the first example of such was introduced in the "IPv6 Network Access" section. Itenables IPv6 traffic forwarding over an existing IPv4 infrastructure, with minimumchanges. Tunnel endpoints can be set up between provider edges. The tunnel endpointsare dual-stack routers, which encapsulate IPv6 traffic into IPv4, with both tunnel sourceand destination configured manually for GRE. Tunnels over GRE, specified in RFC2473 and RFC 1701, have an extra encapsulation header (GRE header), with theprotocol type of the encapsulated protocol (0x86DD for IPv6). This enables protocolsother than IP to share the same tunnel (for instance, IS-IS) running over a layer 2 datalink.
Figure 3-13 shows an example of an IPv6 over GRE tunnel.
Figure 3-13. GRE Tunnel
[View full size image]
Part I: Implementing IPv6 Services 139
Part I: Implementing IPv6 Services 139
GRE tunnels are point-to-point tunnels. The number of tunnels needed for the servicegrows with the number of endpoints, making them difficult to scale. This is a typicalproblem with manual tunneling mechanisms, and for this reason they are usually usedjust to interconnect a few sites.
6to4
6to4 is an automatic tunneling mechanism, specified in RFC 3056. It enables isolatedIPv6 islands, using the 6to4 addressing plan, to interconnect over an IPv4-only backboneat minimum configuration costs. In particular, the tunnel destination is not explicitlyconfigured as in other tunneling mechanisms, but obtained dynamically from the IPv4address embedded in the destination IPv6 address of the packet. Figure 3-14 shows a6to4 configuration.
Figure 3-14. 6to4 Tunnel
[View full size image]
Two deployment scenarios are possible. In the simple case, two or more IPv6 sites needto interconnect over an IPv4 backbone. Each site is configured with a2002:V4ADDR::/48 prefix, where V4ADDR is a unique IPv4 address for the site.
For instance, in Figure 3-14, Site1 is allocated the prefix 2002:C80F:F01::/48, and Site2
140 Part I: Implementing IPv6 Services
140 Part I: Implementing IPv6 Services
has 2002:C80B:B01::/48. The embedded IPv4 address C80F:F01 (200.15.15.1) is theIPv4 address for Site1. IPv4 prefixes (200.15.15/24, for instance) are distributed by anIPv4 routing protocol running in the IPv4 backbone. When HostA sends traffic to HostB(destination 2002:C80B:B01:100::1), it is routed via the 6to4 Router1. This router has a6to4 tunnel configured, with a tunnel source (200.15.15.1) but no tunnel destination. Thetunnel destination is computed on-the-fly by extracting the embedded IPV4ADDR fromthe destination address (2002:C80B:B01:100::1/64, and used to encapsulate the IPv6packet into IPv4 (source 200.15.15.1, destination 200.11.11.1). The reverse path issymmetrical. Example 3-21 highlights the relevant configuration for Router1 andRouter2.
Example 3-21. Configuration of 6to4 Routers in Figure 3-14
!interface Ethernet0/0 ip address 200.11.11.1 255.255.255.0!interface Ethernet1/0 ipv6 address 2002:C80B:B01:100::2/64!ipv6 route 2002::/16 Tunnel2002!route to native IPv6 serviceipv6 route ::/0 2002:C058:6301::1
The second possible scenario is that of a 6to4 site that needs to access global, nativeIPv6 resources (2001::/16 Internet resources or 3FFE::/16 6bone resources, for instance).On the way out (from Site1 to the IPv6 backbone), traffic is routed into the 6to4 tunnel(for instance, using a default route ipv6 route ::/0 2002:C058:6301::1). This routeprovides the IPv4 tunnel destination (192.88.99.1). A dual-stack router on the boundarybetween the IPv4 network and the native IPv6 domain, namely a 6to4 relay, removes theIPv4 header and forwards the IPv6 packet natively. In the other direction, the 6to4 relayuses the destination (HostA 2002:C80F:F01:100::1, for instance) to determine the tunnelendpoint and impose the IPv4 header.
The configuration of the 6to4 Relay router in Figure 3-14 contains no specific elementsfor the 6to4 routers, as shown in Example 3-22.
Part I: Implementing IPv6 Services 141
Part I: Implementing IPv6 Services 141
Example 3-22. Configuration of 6to4 Relay Router
6to4-relayinterface Tunnel2002 no ip addressipv6 address 2002:C80A:A01::1/128tunnel source Loopback0tunnel mode ipv6ip 6to4
Therefore, a 6to4 router willing to access a service hosted in an IPv6 native networkbehind the 6to4 relay will not require any configuration upgrade from the 6to4 relay.
Instead of using a default route to the 6to4 relay, the 6to4 router could peer with it usingexternal Border Gateway Protocol (eBGP), address family IPv6 (see Chapter 4). TheBGP configuration of eBGP peering with the 6to4 relay in Figure 3-14 is shown inExample 3-23.
Example 3-23. BGP Configuration for Peering with the 6to4 Relay
Although this model allows for a more granular routing policy, it requires the BGPconfiguration of the 6to4 relay to be modified for each 6to4 peer. This would not be ascalable deployment approach. BGP peering should be reserved for 6to4 routersproviding access to large sites.
With the promulgation of RFC 3068, 6to4 routers can use the anycast address2002:C058:6301:: for their default 6to4 router to get to the nearest (in BGP terms) 6to4relay router. This assumes that BGP (address family IPv4) is advertising 192.88.99/24,and it saves for each 6to4 router the need to find out by itself the address of the nearest6to4 relay router.
The 6to4 transition mechanism has some advantages over manual tunnels. IPv4 tunnelendpoints do not have to be advertised: The IPv6 sites can get the address of theendpoints through a name-to-address lookup performed by a Domain Name Server(DNS). The tunnels are stateless, not consuming resources like manual tunnels do.Finally, after the 6to4 relays have been set up, no extra configuration is required toprovide 6to4 sites with connectivity to a wide-area IPv6 routing infrastructure, such asthe 6bone. They also have some disadvantages:
The underlying IPv4 address determines the enterprise 6to4 IPv6 address prefix,so the migration to native IPv6 requires renumbering the network.
•
When hosts within the 6to4 site have multiple addresses (6to4 and native) toselect from, they must select their 6to4 address; otherwise, the 6to4 relay cannotdynamically figure out the endpoint of the tunnel.
Note
•
142 Part I: Implementing IPv6 Services
142 Part I: Implementing IPv6 Services
Rule 8 in RFC 3484, "Use longest matching prefix," seems to suggest otherwise.
They are limited to static or BGP4+ routing.•
IPv6 over MPLS
MPLS is an infrastructure technology deployed by ISPs and large enterprises toimplement services such as virtual private networks (VPN), traffic engineering (TE),quality of service (QoS), and fast convergence. ISPs and enterprises that have selectedthe technology may view the integration of IPv6 services over an MPLS infrastructure asa normal evolution. For those unfamiliar with MPLS terminology, a PE is a provideredge router, and a CE is a customer edge router. A packet enters the MPLS backbone atthe ingress PE and is label switched up to the egress PE. This mechanism uses what isknown as a label switch path (LSP), set up by control-plane protocols such as LabelDistribution Protocol (LDP) or Resource Reservation Protocol (RSVP). Refer to thebook MPLS and VPN Architectures, by Ivan Pepelnjak and Jim Guichard, for detailedinformation on MPLS.
A motivation for deploying IPv6 transport capability over an MPLS backbone relates tothe transitioning paradigm. MPLS stands for Multiprotocol Label Switching, and onewould expect MPLS to be capable of transporting IPv4 or IPv6 datagrams seamlessly.Therefore, none or few changes would be expected to enhance an existing MPLSbackbone, initially providing IPv4 connectivity, to transport IPv6 traffic: an attractivetransitioning path for customers who have deployed an MPLS backbone, and want toenhance it to offer IPv6 connectivity at the edge.
In reality, this is partly true; although the label switch path is independent from thetransported payload, two areas of the control plane are not, as noted here:
The setting of the LSP requires an interior gateway protocol (IGP) such asIntermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First(OSPF), which do depend on the protocol version (for instance OSPFv2 forIPv4, OSPFv3 for IPv6). The label distribution protocol falls into the samecategory: both LDP and RSVP depend on the IGP being run among routers inthe core, and they both need to be separately enabled and set up for IPv4 andIPv6 (for instance, LDP runs over TCP).
1.
An exterior routing protocol (BGP) is needed to exchange IPv6 routes betweenedge routers. There must be separate address families enabled for IPv4 (orVPNv4) and IPv6 (or VPNv6), even though they could share the same BGPsession.
2.
Several approaches are possible to offer IPv6 connectivity over the MPLS backbone.They differ from many standpoints: transitioning strategy, scalability, data overhead, andconfiguration. Table 3-3 below compares the different solutions.
Table 3-3. IPv6 over MPLS Mechanisms
MechanismPrimaryUse Benefits Limitations
IPv6 over a circuit transport over MPLS Serviceproviderwithcircuit to
Transparentto the serviceprovider
Scalability
Part I: Implementing IPv6 Services 143
Part I: Implementing IPv6 Services 143
the CE(ATM,Ethernet,and so on)
IPv6 over IPv4 tunnels over MPLS Serviceproviderwilling tooffer IPv6service ontop of anexistingIPv4MPLSservice
Impactlimited to PE
Tunneloverhead
Configuration
IPv6 MPLS with IPv4-based core (6PE) Serviceproviderwilling tooffer IPv6service ontop of anexistingIPv4MPLSservice
IPv6 MPLS with IPv6-based core Serviceproviderwilling toofferMPLSservices inanIPv6-onlycontext
FullMPLS-IPv6functionality
Impact on entireMPLSinfrastructure
Complexity ifcoexistencewith anIPv4-MPLSservice
IPv6 over a Layer 2 Circuit
While layer 3 mechanisms have a lot of advantages for connecting IPv6 over MPLS, they require minglingcustomer and service provider routing. However, some customers may just want connectivity (particularly atcommodity pricing for connectivity without additional services). Using a layer 2 circuit to transport IPv6traffic is an alternative solution to address this simple requirement, with no routing or any additional MPLSservice.
Although layer 2 tunnels between CEs do not scale well in terms of number of tunnels (N2/2, where N is thenumber of CEs), they consume few resources at PEs and even less on Provider routers (P routers). Whenscaling is an issue because of the number of peers involved, you can implement a partial mesh of tunnelsusing hubs. However, doing so potentially leads to suboptimal routing, with traffic transiting the backbonetwice or more. The layer 2 circuit can use Any Transport over MPLS (ATOM) or Ethernet over MPLS(EoMPLS). One advantage of this approach is that it has no configuration impact on any of the backboneboxes (including PE and P). The link between CEs is seen as a layer 2 link, running IPv6 Neighbor Discoveryand any IPv6 routing protocol. The IPv6 traffic is tunneled over the MPLS backbone, as shown in Figure3-15.
144 Part I: Implementing IPv6 Services
144 Part I: Implementing IPv6 Services
Figure 3-15. Ethernet over MPLS
[View full size image]
The relevant configuration of the routers in Figure 3-15 is shown in Example 3-24.
Example 3-24. Configuration of Routers in Figure 3-15
Note that this method may work well for a limited IPv6 deployment over a single ISP network. However, it isunlikely that two ISPs will interconnect using layer 2 links, making the approach unsuitable in environmentswhere several ISPs have to be crossed by the IPv6 traffic. In an environment where the service provideralready provides a layer 2 over MPLS service to transport IPv4 traffic, extending the service to IPv6 is lowcost and straightforward.
Part I: Implementing IPv6 Services 145
Part I: Implementing IPv6 Services 145
IPv6 over an IPv4 Tunnel over MPLS
IPv6 over IPv4 over MPLS is one of these tunnel-in-tunnel methods that is quite easy to implement. AfterIPv4 connectivity between two PEs has been established, and an LSP set up between the PEs' IPv4 endpoints(using LDP combined with IS-IS, for instance), you can manually configure an IPv6 over IPv4 tunnel betweenthese PEs using the same IPv4 endpoints. A routing protocol, such as MP-iBGP can then run over the tunnelto distribute IPv6 routes. From a transitioning or coexistence perspective, this solution has the advantage ofrequiring only the PEs to be dual stack. It has no impact on core MPLS routers.
In the forwarding plane, IPv6 traffic is encapsulated twicefirst into an IPv4 packet, and second into an MPLSframe. This double encapsulation, together with the extra configuration of the IPv6 over IPv4 tunnel, is themain drawback of the approach. Figure 3-16 illustrates a simple topology and relevant configuration to set upan IPv6 over IPv4 over MPLS LSP tunnel. Crossing SP boundaries with this approach is no different fromdoing it for VPNv4. The tunnel endpoints (IPv4 addresses) can be leaked between PEs, either by the IGP, orusing MP-eBGP with label, which leads to an extra label in the label stack imposed at the ingress router (asdescribed in RFC 2547bis, section 11, case c).
Figure 3-16. IPv6 over IPv4 over MPLS
[View full size image]
The relevant configuration of the PE routers in Figure 3-16 is shown in Example 3-25.
Example 3-25. Configuration of PE Routers in Figure 3-16
An IPv6 Provider Edge router (or 6PE) is an alternative solution to IPv6 over an IPv4 tunnel over MPLS. Thegoal of 6PE is to get the benefits of the IPv6 over IPv4 tunnel (no impact on core routers) while avoiding thetunnel overhead and the tunnel configuration.
6PE encompasses the following mechanisms:
The setting of a LSP, which involves an IGP and a label distribution protocol• The exchange of IPv6 routes between edge routers, which is generally performed by MP-BGP, andrequires enabling of an IPv6 address family
•
The MPLS forwarding mechanisms, based on label swapping and is independent of the payload•
The key for leaving the core routers untouched (whether configuration wise, or software version wise) is toenable IPv6 traffic to be tunneled in LSPs set up with IPv4-based protocols. The LSP between edge routerscan be used to transport any type of packets, including IPv6, providing that there exists some mechanism toassociate the IPv6 path through the MPLS backbone with this LSP.
In the case of IPv6 over IPv4 over MPLS, this association is done via the tunnel endpoints, configuredexplicitly. In the case of 6PE, the association is controlled directly by MP-BGP, which correlates the next hopadvertised with a given prefix with the LSP. The next hop is the IPv4-mapped IPv6 address (see the section"Special-Use Addresses" in Chapter 2 for details) built from the IPv4 address of the LSP tunnel endpoint.Figure 3-17 shows a simple 6PE topology.
Figure 3-17. 6PE Basic Topology
[View full size image]
Part I: Implementing IPv6 Services 147
Part I: Implementing IPv6 Services 147
The configuration in Example 3-26 illustrates how the LSP is associated with IPv6 paths.
Example 3-26. BGP Configuration for LSP-to-IPv6 Path Association
An LSP is set up between 200.10.10.1 and 200.11.11.1, as shown in the forwarding entry details at PE1 (seeExample 3-27).
Example 3-27. Forwarding Information on Router PE1 from Figure 3-17
PE1#show ip cef 200.10.10.1/32 det200.10.10.1/32, epoch 0 local label info: global/17 nexthop 40.1.1.3 Ethernet1/0 label 17
Prefixes advertised by PE2 over MP-iBGP are reachable via the next hop 200.10.10.1, as shown in Example3-28.
Example 3-28. Unicast Prefixes Learned by PE1 via MP-iBGP
PE1#show bgp ipv6 unicast Network Next Hop Metric LocPrf Weight Path*>i2001:200::/64 ::FFFF:200.10.10.1 0 100 0 300
148 Part I: Implementing IPv6 Services
148 Part I: Implementing IPv6 Services
The next hop (::FFFF:200.10.10.1) is the IPv4-mapped IPv6 address built from the IPv4 address of the LSPtunnel endpoint. It identifies the LSP to be used to reach the receive prefix (2001:200::/64), as shown in theforwarding table (Example 3-29).
Example 3-29. CEF Forwarding Table of Router PE1 in Figure 3-17
The exchange of IPv6 routes is performed with MP-iBGP, address family IPv6, using TCPv4 transport.(MP-BGP can operate indistinctly over an IPv6 or IPv4 transport.)
A careful reader may have noticed that a second label (label 25) appears in the forwarding entry for reaching av6 prefix (2001:200::/64) over the LSP. In fact, the MPLS forwarding plane is not entirely independent fromthe payload. Here are the exceptions:
At the penultimate hop, when penultimate hop popping (PHP) is enabled, and the label stack on thereceived packet is only one label, the MPLS forwarder is forwarding an IP packet.
•
When multiple paths are available, the MPLS forwarder may hash the IP header to pick up one ofthose paths in a deterministic way and provide consistent load balancing.
•
When an MPLS packet is undeliverable (for instance, because the label TTL [Time To Live] expired),the MPLS forwarder may need to send back an ICMP message to the source, which requires it to beIP-aware.
•
In these three cases, the MPLS forwarder requires some IP knowledge (and therefore some IPv6 knowledgewhen the payload is IPv6).
For the PHP, two options are possible. The first option is to disable PHP. Because the option is most generallyconfigured at the box level, that would affect the IPv4 behavior and require some configuration change,including at the penultimate router (not a 6PE). The second option is to push a second label in the label stack,at the ingress edge router. The extra label guaranties that no router in the core, including the penultimate hop,will have to forward a nonlabeled packet (which means that the routers does not have to be capable ofhandling IPv6 packets). This second label is distributed by MP-iBGP, using the Subsequent Address Family(SAFI) label (value=4), as specified in RFC 3107. The following configuration example illustrates how to setit up.
Example 3-30. BGP Configuration of Router PE1 Exchanging Prefixes and Labels with PE2
Note that on Cisco routers, the configuration of the SAFI "label" is required, to enable the IPv6 forwarder touse the MPLS LSP.
The MPLS forwarder also needs to be IPv6-aware for load balancing. Cisco routers are somewhat flexible inthat regard; either the core router has been upgraded (software upgrade) with a recent version that is capableof hashing the IPv6 header and it will do so, or the hashing is performed on the bottom label.
The third potential issue in the forwarding plane arise when P-routers need to send an ICMPv6 message, uponreceiving an undeliverable MPLS datagram. One easy way to get around that problem is to ignore it. Thetraceroute, executed between PEs or between CEs, is the most cumbersome method, because one wouldexpect all nodes to respond. This can be hidden by using no mpls ip propagate-ttl at the PE (assuming fewerthan 255 MPLS hops). If ICMPv6 support is a must for the service provider, P-routers must be upgraded withICMPv6 support, and RFC 3032 (see section 2.3.2 in RFC 3032, or Chapter 7, "VPN IPv6 Architecture andServices") is used to provide P-routers with the capability to reach IPv6 nodes without any IPv6-forwardingcapability.
Crossing multiple IPv4 autonomous systems is similar to IPv4 VPNs, as described in the update of RFC 2547called RFC 2547bis. Three approaches are feasible:
The two autonomous systems are connected over IPv6 links. The Autonomous System BoundaryRouters (ASBRs) are both dual-stack 6PE routers that terminate the LSP in their respectiveautonomous system, and redistribute IPv6 routes to the other ASBRs using eBGP, address familyIPv6. This approach is similar to scenario A, section 10, of RFC 2547bis.
•
MPLS forwarding is enabled between ASBRs. Whether the link supports IPv4 or IPv6, a label can beadvertised by eBGP (IPv6+label) on it so that an LSP end-to-end (from egress 6PE in oneautonomous system to egress 6PE in the second autonomous system) is set up. The eBGP peeraddresses between ASBRs determine the type of transport used (6PE if IPv4 addresses are used,native IPv6+label otherwise). This approach is similar to scenario b, section 10, of RFC 2547bis.
•
6PE peering is enabled directly across the two autonomous systems, usually via route reflectors. Withroute reflectors, IPv6 routes are neither maintained nor distributed by the ASBR routers, which do noneed not be dual stack (can be IPv4 only). The ASBRs are required to leak labeled IPv4 /32 routes tothe other autonomous system. This results in the creation of an IPv4 label switched path from theingress 6PE router to the egress 6PE router, across autonomous system boundaries. This approach issimilar to scenario c, section 10, of RFC 2547bis.
•
For further details, see Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network," and the InternetDraft draft-ooms-v6ops-bgp-tunnel (work in progress at the time of this writing).
Native IPv6 MPLS
At the time of this writing, no router implementation provides native IPv6 support for LDP or RSVP.However, specifications exist for both, and one could consider a valid evolution to migrate from one of thetransitioning methods used to carry IPv6 over MPLS to a native IPv6 MPLS LSP setup. As for non-MPLSbackbones, this would require the backbone routers to first become dual stack.
To set up an IPv6 LSP, you could use LDPv6. Similar to BGP, an LDP transport session (over TCP) isrelatively independent from where the prefixes are being transported. You could have two separate LDPsessions: an LDPv4 session for transporting IPv4 prefixes, and an LDPv6 session for transporting IPv6prefixes; alternatively, you could have a single LDP session (for instance, over TCPv4) that carries both typesof prefixes. The prefix Forwarding Equivalence Class (FEC) element contains an Address Family field, perRFC 1700, which encodes the IPv6 address family when the address in the Prefix field is IPv6.
In addition to the label distribution protocol, there should be an IPv6 IGP that advertises the PE and the corerouters' reachability within the MPLS backbone. As in the non-MPLS IPv6 dual-stack case, this could be
150 Part I: Implementing IPv6 Services
150 Part I: Implementing IPv6 Services
OSPFv3 or IS-IS; the latter choice being preferred when the ISP does not want to run multiple routingprocesses on the same box. (See Chapter 4 for an in-depth analysis of routing protocols.)
To advertise customer prefixes between PE routers, you would still use MP-BGP, address family IPv6, butMP-BGP could run over TCP/IPv4 or TCP/IPv6.
Given the nature of MPLS LSPs, which can transport any sort of payload regardless of which protocol is usedto set up these LSPs, you might wonder why it is necessary to set up LSPs using an IPv6 control mechanism.One reason is that core topologies for IPv4 and IPv6 are separate, and traffic follows different paths withdifferent routing policies for both. In that case, of course, many core routers are likely to end up with two IGPinstances (for instance, OSPFv2 and OSPFv3) and two LDP instances (IPv4 and IPv6). Although this scenariooffers greater flexibility, it also entails more configuration and management complexity. The dual-stackMPLS core is not different from the non-MPLS case when both IPv4 and IPv6 are deployed natively.
Translation Mechanisms (NAT-PT)
Transition mechanisms reviewed so far enable end-to-end IPv6 connectivity. They are based onnative IPv6 integration in a network, also called dual stack, or IPv6 encapsulation over IPv4(manual or automatic tunnels). There is a potential scenario (third- and fourth-generationmobile phone networks, for instance) where IPv6-only devices need to communicate withIPv4-only nodes or resources. Such scenarios drive the need for translation mechanisms thatenable communication between equipment that supports only one of the IP versions.
Even when hosts can be migrated to a dual stack at the networking layer, some applications willremain IPv4 only, just because their implementation relies too much on IPv4 addresses, or arecompilation cannot be implemented.
In such environments, you can use a different set of mechanisms, based on protocol translationrather than tunneling. These mechanisms include the following:
Bump-in-the-Stack (BIS), specified in RFC 2767• SOCKs-based gateway, specified in RFC 3089 and RFC 1928• TCP-UDP Relay, specified in RFC 3142• Network Address Translation-Protocol Translation (NAT-PT), specified in RFC 2765and RFC 2766
•
These mechanisms fall into two categories: those that have an impact on hosts, generally onlyon one end of the communication; and those that do not. BIS and SOCKS-based gatewaysbelong to the first category, whereas TCP-UDP Relay and NAT-PT belong to the second. CiscoIOS software implements only NAT-PT because the other translation mechanisms are eithernot relevant to Cisco IOS software or they are not really deployed. For these reasons, thissection focuses only on NAT-PT.
NAT-PT enables IPv6-only hosts to communicate with IPv4-only hosts and applications. It isdescribed in RFC 2766 and uses the IP translation mechanism referred as stateless IP/ICMPtranslation algorithm (SIIT), specified in RFC 2765.
Tables 3-4 and 3-5 present header translation rules, from IPv4 to IPv6 and in reverse.
Part I: Implementing IPv6 Services 151
Part I: Implementing IPv6 Services 151
Table 3-4. Header Translation IPv4 to IPv6IPv6 Header Fields ValuesVersion 6Traffic Class TOSFlow Label 0Payload Length Total
lengthheaderlength
Next Header ProtocolHop Limit TTLSource Address NAT-PTDestination Address NAT-PT
Table 3-5. Header Translation IPv6 to IPv4
IPv4 Header Fields
Values
Version
4
IHL
5 (no options)
TOS
Traffic class
Total Length
Payload length + length of the IPv4 header
Identification
0
Flags
More Fragments Flag=0 Don't Fragment Flag=1
Fragment Offset
0
TTL
Hop limit
Protocol
152 Part I: Implementing IPv6 Services
152 Part I: Implementing IPv6 Services
Next Header field
Checksum
Computed
Source Address
NAT-PT
Destination Address
NAT-PT
Options
Not translated
Any IPv4 option is ignored during the protocol-translation process. IPv4 fragmented packets are translatedusing the IPv6 fragment header. Most ICMPv4 control messages are discarded during translation, except echorequests and replies which are mapped into IPv6 with the proper code (128, 129). Error messages aretranslated whenever possible. The reverse translation is done pretty much the same way. The IPv4 checksumcomputation is performed after the header has been translated.
The way addresses (source and destination) get translated is configuration controlled, or dynamic. In thesimple case, explicit mapping is provided at the NAT-PT for both source and destination, in both directions.
Like for NAT, NAT-PT operates in various modes: static, where one IPv4 address is used to communicatewith the IPv4-only host; and dynamic, where a pool of addresses is available, and dynamically bound to activeflows; and PAT (Port Address Translation), where a single IPv4 address is used, and a TCP/UDP port numberserves as a discriminator.
NAT-PT can also be used as the DNS application-level gateway (ALG) to translate the DNS transaction. TheDNS query for an AAAA record gets translated into a query for an A record. Upon receiving a response withan IPv4 address, the NAT-PT builds an IPv6 address by prefixing it with the global NAT-PT prefix and sendsthe response to the IPv6 host. At the same time, it creates a dynamic entry for translating the destination.
For the destination, when communication is initiated from the IPv6 host, the IPv6 destination can embed theIPv4 address.
Figure 3-18 illustrates the case of dynamic NAT-PT using a pool of addresses.
Figure 3-18. NAT-PT
[View full size image]
Part I: Implementing IPv6 Services 153
Part I: Implementing IPv6 Services 153
Example 3-31 presents the NAT-PT configuration of the router shown in Figure 3-18.
Example 3-31. NAT-PT Router Configuration
interface Ethernet0/0 ipv6 address 3ffe:100:200:1::2/64 ipv6 enable ipv6 nat!interface Ethernet1/0 ip address 192.168.1.2 255.255.255.0 ipv6 nat!Entry for static mapping of v4 source->v6-ipv6 nat v4v6 source 192.168.1.1 3ffe:b00:1::1!Entry for mapping of v6 source->dynamic v4ipv6 nat v6v4 source list pt1 pool v4poolipv6 nat v6v4 pool v4pool 10.50.10.1 10.50.10.10 prefix-length 24ipv6 nat translation udp-timeout 600ipv6 nat prefix 3ffe:b00:1::/96!ipv6 access-list pt1 permit ipv6 3ffe:100:200:1::/64 any
NAT-PT involves many of the same issues as NAT, covered in depth in Chapter 1, "The Case for IPv6AnUpdated Perspective." These issues are also listed in draft-aoun-v6ops-natpt-deprecate (a work in progress inIETF). Whenever you have an alternative solution, you should favor it over NAT-PT. For instance, if there isany possibility to set up the hosts with dual-stack IPv4 and IPv6, other mechanisms (described in section"IPv6 Network Access") such as ISATAP or Teredo should be preferred. NAT-PT is not supported when anIPv6-only network is trying to communicate to another IPv6-only network via an IPv4 backbone or viceversa, because it would require a double translation. In such cases, tunneling mechanisms (described in thesection "IPv6 over the Backbone") should be preferred.
However, a gap exists between a technical alternative and its operational feasibility. This gap may be filled byNAT-PT during the transitioning period. Consider, for example, the case of IPv6-only devices that shouldcommunicate with a node connected to an IPv6 unsupported data link layer (for example, Token Ring). Foreconomical reasons, it may be valuable to run NAT-PT between devices, while waiting for the host to beupgraded to its next generation (thus ridding it of Token Ring).
You can integrate IPv6 into existing infrastructures in various ways. It is expected that dual-stack networkswill become the standard approach, but various transition mechanisms are available today to lower the cost ofthe first steps toward IPv4 and IPv6 coexistence. This chapter has summarized those mechanisms to enableyou to evaluate their use in different deployment scenarios as depicted in the second part of this book.
154 Part I: Implementing IPv6 Services
154 Part I: Implementing IPv6 Services
Chapter 4. IPv6Routing Protocols
Numerous IPv4 routing protocols(RPs) are available for finding routesbetween networks, and almost everyone of them has an IPv6correspondent or extension: RoutingInformation Protocol next-generation(RIPng), Open Shortest Path Firstversion 3 (OSPFv3), IntermediateSystem-to-Intermediate System(IS-IS), Enhanced Interior GatewayRouting Protocol (EIGRP), andBorder Gateway Protocol (BGP). Sofar, IPv6 has brought few innovationsto the IP routing paradigm. There arestill interior gateway protocols (IGPs)and exterior gateway protocols(EGPs), distance vectorbased andlink-state-based routing protocolalgorithms, and so on.
The concept of the autonomoussystem, defined as a set of networkscontrolled by a commonadministrative entity, remainsunchanged with the introduction ofIPv6 RPs. The same autonomoussystem (and autonomous systemnumber [ASN]) will route both IPv4and IPv6. IPv6 IGPs, used toexchange routes within theautonomous system, are namelyRIPng, OSPFv3, IS-IS for IPv6, andEIGRP for IPv6. Only BGP4 isavailable to exchange IPv6 routesbetween autonomous systems.Multiprotocol extensions providesupport in BGP4 for IPv6 routing.
The requirements for IGPs and EGPsare quite different, in terms of routingtable size, number of supportedrouters, convergence time, security,routing policy, and so forth. For thatreason, they use different algorithmsand mechanisms, which also affect thetype of information they exchange and
Part I: Implementing IPv6 Services 155
Part I: Implementing IPv6 Services 155
store. IGPs use distance vector andlink state, whereas BGP uses the pathvector RP algorithm. Table 4-1presents the RP taxonomy, andhighlights their IPv6 correspondent.For more details on how to choose theRP, refer to Top-Down NetworkDesign, Second Edition, by PriscillaOppenheimer.
Table 4-1. Taxonomy of RoutingProtocols
Deployment Domain Algorithm RP ScalabilityConvergenceTime Metric
IPv6Version
Interior gateway protocol (IGP) Distancevector
RIP 15 hops Slow Hop count RIPng
EIGRP 1000srouters
Quick (viaDUALalgorithm)
Bandwidth,delay,reliability,load
EIGRPfor IPv6
Link state OSPF 1000srouters(100s/area)
Quick (viaLSAs andHELLO)
Cost (functionof bandwidthon Ciscorouters)
OSPFv3
IS-IS 1000srouters(100s/area)
Quick (viaLSPs)
Configuredhost, delay,expense
IS-IS forIPv6
Exterior gateway protocol (EGP) Distancevector
EGP Integer <=255
Pathvector
BGPAF=IPv4
1000srouters
Slow (viaUPDATE)
Function ofpath attributesand otherconfigurablefactors
BGPAF=IPv6
The rest of this section briefly reviews existing unicast RP technologies. The next section reviews each of theavailable IPv6 RPs and provides configuration examples. Then the last two sections cover the topic ofmultihoming and deployment aspects, respectively.
Distance Vector Routing Protocol
In a distance vector routing algorithm, routes are selected based on the distance between networks. Thedistance metric is something simple enough to allow consistent values across the domain (for instance,number of hops, the time delay in getting messages to the destination, or the cost of sending messages to it).Routers maintain a database with distance values to all known networks. They periodically send this databaseto each of their neighbors (or peers if connected over virtual links). These neighbors update their own tablesby computing distances to known networks, which typically involves adding their own contribution to thedistance received from neighbors. Then they send the information to their own neighbors and so on. Thismechanism propagates the distance information across the entire network.
156 Part I: Implementing IPv6 Services
156 Part I: Implementing IPv6 Services
To compute the shortest path (from a distance perspective) and next hop to each destination prefix, theBellman-Ford algorithm is used, named after its inventors. RIP, IGRP, and EIGRP are IPv4 examples of RPsusing this technology. For IPv6, this translates into RIPng and EIGRP for IPv6.
Distance vector RPs provide suitable performance on small or medium-sized networks. On large networks,route computation may become slow and impact the convergence time, because it must occur at each routerprior to propagating the routing updates. Problems can also appear because routers are not aware of thetopology of the entire network. They know their connected neighbors and the routes known by theseneighbors (sometimes referred to as routing by rumor). In large networks, this can lead to routing loops, soadditional anti-loop mechanisms are required. RIP implements the split-horizon and poison-reversemechanisms to prevent incorrect routing information from being propagated. The basic split-horizonalgorithm omits routes learned from one neighbor in updates sent to that neighbor. Poison reverse doesinclude such routes in updates, but sets their metrics to infinity. (A metric of 16 means route is unreachable.)BGP relies on the full-path analysis carried in advertisements.
Path Vector Routing Protocol
A path vector protocol is essentially a distance vector protocol that does not rely on the distance to destinationto guarantee a loop-free path but instead relies on the analysis of the path itself. It is typically deployed inenvironments where it is difficult to guarantee a consistent metric (distance) across the routing domain. Thepath is accumulated at each router, and carried in each advertisement, so that any router receiving it canvalidate the loop-free path before propagating the information. BGP4 is the best example of an RP using thistechnology. The main drawback is the size of the advertisements, which grow with the number of hops. As faras IPv6 is concerned, BGP4, enhanced with multiprotocol extensions, remains the path vector RP of choicefor exchanging IPv6 routes between autonomous systems.
Link-State Routing Protocol
With link-state protocols, each router within the routing domain discovers and builds a complete andconsistent view of the network topology as a weighted directed graph. Routers of the domain are nodes of thegraph, and links between neighboring routers represent unidirectional edges or arcs. Weights on links areadministratively assigned.
Routers advertise link-state information, including networks that they are attached to, or network reachabilitythat is being redistributed via another RP. When the router boots up, it obtains a complete database imagefrom its neighbors and builds the routing table by computing best routes to each destination prefix. Later, thelink-state RP receives only deltas and recomputes routes to reflect the changes. The route computation usesthe shortest path first (SPF) algorithm, also known as the Dijkstra algorithm, named after a Dutchmathematician. SPF can run periodically and recompute the entire set of routes to destinations (full SPF) or itcan perform partial route calculation (PRC) when only a single external route changes. Incremental SPF(iSPF) can also be used to recompute only the affected part of the routing tree, thus allowing OSPF toconverge faster on a new routing topology in reaction to a network event. This typically happens when thestate of leaf elements changes.
Link-state algorithms adapt dynamically and quickly to changing network conditions because the changes arepropagated independently of each router's route computation. They also allow routes to be selected based onmore complex metrics than just the number of hops between networks. On the dark side, they are complicatedto set up and can be slow to compute routes in large networks if design recommendations and constraints are
Part I: Implementing IPv6 Services 157
Part I: Implementing IPv6 Services 157
not observed. They also require more complex troubleshooting knowledge. The two most deployedrepresentatives of this family of RPs are IS-IS and OSPF, which both have an IPv6 counterpart: IS-IS for IPv6and OSPFv3. They both implement mechanisms to enhance scalability, by enabling a two-level hierarchicalrouting model.
IPv6 Interior Gateway Protocols
Every modern IPv4 IGP has either an IPv6 version counterpart or an extension that enables it to support IPv6.The following subsections review the four IGPs available on Cisco routers: RIPng, EIGRP for IPv6, OSPFv3,and IS-IS for IPv6.
Routing Information Protocol next-generation
RIP is a simple protocol in the distance vector family. That means it is simple to understand and configure,but it also means it does have some limitations. The main ones are convergence times and scaling. RIPng isbasically RIP version 2 (RFC 2453) extended to handle IPv6 prefixes and next hops.
Support for IPv6
The IPv6 version of RIP is described in RFC 2080. It is called RIPng (RIP next generation); this reflects thecode name used for the next-generation IP protocol.
It has been argued that RIP should be left to "Rest In Peace." Because it is an easy protocol to implement, itwas the first protocol to be supported by vendors, and therefore it saw some deployment in the early days ofIPv6. Now that OSPF and IS-IS are supported, RIP is used in small deployments (for example, in amultihomed host or to pass on a default route from an ISP to a customer's CPE).
There is not much new and exciting about RIPng. It supports split horizon and poison reverse as its IPv4counterpart. It has the same limitations, such as a maximum hop count of 15, and does counting to infinity forcertain routing loops.
The differences between RIP (used for IPv4) and RIPng are as follows:
In IPv4, RIP runs per subnet. Two neighboring routers need to be a part of the same IPv4 subnet toexchange routes. Because IPv6 neighbors always are on the same link-local subnet (FE80::/10), thisrestriction is removed. The consequence of this, however, is that a router will have to advertise itsown prefix on a link, out that interface.
•
Because IPv6 does not use broadcast, RIP messages are sent to the "all RIP routers" link-localmulticast address (FF02::9).
•
In IPv4, RIP relies on some specific RIP authentication mechanism to secure routing exchanges.RIPng relies on the IP Authentication Header and the IP Encapsulating Security Payload to ensureintegrity and authentication/confidentiality of routing exchanges.
•
RIP does not directly support multiple instances of the protocol on a link. There is no instance identifier oranything like that in the message format, so if you require this functionality you will have to run RIP on adifferent UDP port, or use a different RIP multicast address (default FF02::9). The Cisco IOS implementationsupports a maximum of four RIPng instances.
158 Part I: Implementing IPv6 Services
158 Part I: Implementing IPv6 Services
Configuration Example
Configuring RIP on Cisco routers is straightforward. It requires that RIP be enabled on each interface, asillustrated here:
You can change the metric and summary information on a per-interface basis. The IPv6 router RIP modeallows for configuration of redistribution, distribute lists, and knobs for tuning RIP behavior. For example,poison reverse and split horizon can be turned on or off, and the default RIP timers can be changed for betterconvergence times.
To verify that RIP works correctly, you can use the show command shown in Example 4-1.
Example 4-1. Checking RIP Status
Router#show ipv6 ripRIP process "foo", port 521, multicast-group FF02::9, pid 26 Administrative distance is 120. Maximum paths is 16 Updates every 30 seconds, expire after 180 Holddown lasts 0 seconds, garbage collect after 120 Split horizon is on; poison reverse is off Default routes are not generated Periodic updates 14, trigger updates 2 Interfaces: Ethernet0/0 Redistribution: Redistributing protocol static
The show ipv6 rip command shows the status of the RIP process(es). The output includes most of the detailsyou need to know; timers, redistribution status, and on which interfaces RIP is enabled.
Routing information is stored in a local database called a routing table, also referred to as Routing InformationBase (RIB). The RIB essentially contains all routes available for selection. Essentially, it is the sum of allroutes learned via dynamic RPs (including RIP, for instance), all directly attached networks (networks that agiven router has interfaces connected to), and any additional configured routes such as static routes. There isone RIB for IPv4, and a separate one for IPv6. There may be more than one if the VPN feature is enabled (seeChapter 7, "VPN IPv6 Architecture and Services").
Example 4-2. Rip Database Display
Router#show ipv6 rip databaseRIP process "foo", local RIB 2001:200::/64, metric 2 Ethernet0/0/FE80::A8BB:CCFF:FE02:8B00, expires in 159 secs DEAD:BEEF:CAFE::/64, metric 2, installed Ethernet0/0/FE80::A8BB:CCFF:FE02:8B00, expires in 159 secs
In addition, each RP, such as RIPng, has its own database, which you can view.
Part I: Implementing IPv6 Services 159
Part I: Implementing IPv6 Services 159
The show ipv6 rip database command lists the routing database for RIP. You might see entries in this databasethat are not in the IPv6 RIB. For example, the RIB might already have a route with a better administrativedistance. The keyword installed after a prefix indicates that it is installed in the RIB.
EIGRP for IPv6
The Cisco proprietary Enhanced Interior Gateway Protocol (EIGRP) was developed to bridge the gap betweenthe traditional distance vector protocols (IGRP, RIP) and the advanced link-state protocols (OSPF, IS-IS). Itintegrates some of the proven capabilities of the latter to improve the operation and the scalability of theformer. Nevertheless, the intent was to avoid some of the topological constraints that are sometimesassociated with link-state protocols. The result is a simple yet fast converging, resilient, and scalable routingprotocol that is largely adopted in many enterprise networks as well as the edge of some ISP networks.
The protocol is extensively discussed in the book EIGRP Network Design Solutions, by Ivan Pepelnjak; but insummary, EIGRP is a distance vector routing protocol based on IGRP that offers the following improvements:
Diffusing update algorithm (DUAL) used to determine whether a path advertised by a neighbor isloop-free and to identify alternate paths without waiting on updates from other routers.
•
It stores all routes learned, not only the best one learned from neighbors.• EIGRP actively queries neighbors when destinations become unreachable, and that leads tocompetitive convergence times.
•
Use of Hello packets to maintain neighbor state leads to faster convergence.• Use of reliable transport protocol for the exchange of updates eliminates the need for periodic, fullupdates.
•
EIGRP uses complex metrics that provide flexibility in route selection.•
To meet the routing needs of enterprise networks, EIGRP has a modular design with protocol-independentcore functionality and protocol-dependent modules that enable it to be used for IPv4, IPX, and AppleTalk.
Support for IPv6
The large deployed base for EIGRP drove the demand for extending its capabilities to support IPv6. Themodular implementation of EIGRP simplifies the implementation. It requires the introduction of anotherprotocol-dependent module for IPv6 (protocol identifier 88 was chosen, the same as IPv4) and three newTLVs (IPv6_REQUEST_TYPE [0X0401], IPv6_METRIC_TYPE [0X0402] and IPv6_EXTERIOR_TYPE[0X0403]).
EIGRP for IPv4 and EIGRP for IPv6 have strong similarities. Both implement the "diffusing updatealgorithm," developed by J. J. Garcia-Luna-Aceves based on work by E. W. Dijkstra and C. S. Scholten in1980. A few differences exist due to some specific aspects of IPv6:
The router ID for the EIGRP process remains 32 bits long. It is derived from an IPv4 address foundon one of the configured interfaces or is manually configured.
Note
On an IPv6-only router, the EIGRP process does not start until the ID is manually configured.
•
The source address (SA) of the EIGRP Hello is the link-local address of the transmitting interface; thedestination address (DA) is FF02::A (the all EIGRP routers, link-scope multicast address).
•
160 Part I: Implementing IPv6 Services
160 Part I: Implementing IPv6 Services
Note
This format of the Hello packet implies that two neighbor routers do not have to share the same prefixon the link to see each other's Hellos. Packets sent to specific peers are unicasted, in which case,sharing the same prefix on the link becomes relevant.
EIGRP for IPv4 uses MD5 for authentication, and similar support is provided by EIGRP for IPv6.Although not yet available by the time of this writing, support for IPsec authentication will also beprovided on Cisco routers.
•
Automatic summarization enabled by default in EIGRP for IPv4 is disabled in EIGRP for IPv6because IPv6 is classless.
•
Unlike EIGRP for IPv4, there is no split horizon in EIGRP for IPv6 because in IPv6 multiple prefixescould be present on the same interface of a router.
•
EIGRP for IPv6 will be enabled to operate within virtual private networks (VPNs) in a similar way as EIGRPfor IPv4. Scalability characteristics of EIGRP for IPv6 differ from EIGRP for IPv4 mainly due to the need forextra memory resources.
Configuration Example
Similar to all other IPv6 RPs, EIGRP for IPv6 is enabled on a per-interface basis. If a router is able to acquireits ID from an IPv4 address existent on it, the EIGRP for IPv6 protocol configuration is simple, as illustratedhere:
interface Ethernet0 ipv6 enableipv6 eigrp 100
Note
The EIGRP process does not start on an interface unless the ipv6 enable command is present under thatinterface.
If the router is IPv6 only, a router ID has to be explicitly configured under the EIGRP process, as illustratedhere:
ipv6 router eigrp 100Router-id 10.10.10.1
Note
When configured, the EIGRP process is by default shut down and an explicit no shutdown is necessary to getit started.
Part I: Implementing IPv6 Services 161
Part I: Implementing IPv6 Services 161
Once configured, you can use the following show command to display EIGRP-relevant operationalparameters.
Example 4-3. Displaying EIGRP Parameters
Router1#show ipv6 protocolIPv6 Routing Protocol is "eigrp 100"EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0EIGRP maximum hopcount 100
EIGRP maximum metric variance 1 Interfaces:
FastEthernet0/1.1 Redistribution: None
Maximum path: 16 Distance: internal 90 external 170
When established, adjacencies are pointing to the link-local address of the neighbor, as shown in Example4-4.
Example 4-4. EIGRP Neighbor Status
Router1#show ipv6 eigrp neighborIPv6-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num0 FE80::2B0:4AFF:FE5C:ACA Fa0/1.1 14 00:01:43 1 4500 0 1
The EIGRP for IPv6 topology is independent of IPv4, and when queried, the all-links option should be used toview all equal-cost paths when present, as shown in the following show command.
Example 4-5. EIGRP Topology
Router1#show ipv6 eigrp topology all-linksIPv6-EIGRP Topology Table for AS(100)/ID(10.10.10.1)Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia StatusP 2001:FFFF:FFFF::/64, 1 successors, FD is 28160, serno 1 via Connected, FastEthernet0/1.1
via FE80::2B0:4AFF:FE5C:ACA9 (30720/28160), FastEthernet0/1.1
With minor syntax modifications, the commands available for tweaking or troubleshooting EIGRP for IPv4are available for IPv6, too. For example, the command that enables MD5 authentication for a given interfacewould in this case be ipv6 authentication mode eigrp 100 md5. Considering their similar mode of operation,you should use the same configuration and troubleshooting guidelines for IPv6 as for IPv4, such as thosediscussed in the book EIGRP Network Design Solutions, by Ivan Pepelnjak.
162 Part I: Implementing IPv6 Services
162 Part I: Implementing IPv6 Services
OSPFv3
OSPF is an IGP used to distribute routing information between routers of a single autonomous system. OSPFis based on link-state technology, described briefly in the "Overview" section. The IPv4 version is specified inRFC 2328.
Routers running OSPF advertise link state, link prefix/mask, link weight, and other local connectivityparameters in link-state advertisements (LSAs). These LSAs are flooded reliably to other routers in thenetwork to ensure that every OSPF router has a complete and consistent view of the topology.
On broadcast and Non-Broadcast Multiple Access (NBMA) networks, a designated router (DR), electedduring neighboring relationship establishment (Hello protocol) can help reduce the amount of control trafficnecessary for this operation, by acting as a relay between OSPF routers for LSAs. A backup designated router(BDR) is also elected. The BDR picks up the functions of a failed DR with no need of a new election process.
OSPF allows sets of networks to be grouped together into regions called areas. A router maintains a topologydatabase for each area it participates in, and the topology of an area is hidden from the rest of the autonomoussystem. Areas constitute a useful concept that enables a two-level routing hierarchy, a concept that helpsimprove scalability. Routers do not need to maintain a topology database for areas they do not belong to,which leads to significant reduction in routing traffic. Route summarization can occur on the area borders,another way to reduce the routing traffic.
For securing routing distribution and installation, OSPFv2 defines fields AuType and Authentication in itsprotocol header (RFC 2328).
Finally, OSPF has built-in support for classless interdomain routing (CIDR). (Each route distributed by OSPFhas a destination and mask.)
For in-depth information on OSPF, refer to the book OSPF: Anatomy of an Internet Routing Protocol, by JohnT. Moy.
Support for IPv6
OSPFv3 extends OSPF to provide support for IPv6, as specified in RFC 2740. The basic mechanisms alreadyused by OSPFv2, such as flooding, DR election, area support, SPF calculations, and so on, remain applicableto OSPFv3. Neighboring routers are still identified by the 32-bit router ID in OSPFv3. However, changes inprotocol semantics between IPv4 and IPv6, as well as changes in the address format, have led to significantchanges in OSPFv3 compared to OSPFv2.
The two versions of the OSPF protocol operate independently of each other, on disjoint databases. There is nobackward compatibility from OSPFv3 to OSPFv2.
Extensions have been proposed to adapt OSPFv3 as an "integrated model," where OSPFv3 would be extendedto calculate IPv4 routes. This is still a work in progress at the IETF. Two proposals are being discussed:"Multi-topology routing in OSPFv3" (Internet Draft; Sina Mirtorabi, Abhay Roy) and "Support of addressfamilies in OSPFv3" (Internet Draft; Mirtorabi, S., et al.). A Cisco implementation is already available thatprovides a unified command-line interface (CLI), as shown in Example 4-6.
A main goal of OSPFv3 was to create a routing protocol independent of any specific network layer. Toachieve this, OSPFv3's inter-router messages have been redesigned, and addressing semantics have beenremoved from OSPF packets and from the basic LSAs. In OSPFv3, LSAs such as router LSAs and networkLSAs only carry topology information. The following LSAs have been created to carry IPv6 addresses andprefixes:
Link LSAs announce the router's IPv6 link-local address to neighbors on the link, inform theseneighbors of a list of IPv6 addresses to associate with the link, and announce the set of options.
•
Intra-area prefix LSAs carry all IPv6 prefix information to all OSPFv3 routers within an area. (Thisinformation in IPv4 is carried by the router and network LSAs.)
•
The following LSAs have been modified:
Router link state advertisements and network LSAs no longer carry prefix information. In OSPFv3,these LSAs only carry topology information, making them network-protocol independent.
•
Inter-area prefix replaces the network summary or type 3 LSA. An inter-area prefix LSA advertisesinternal networks to routers in other areas. With IPv6, those LSAs are expressed as <prefix, prefixlength> rather than <prefix, mask>.
•
Inter-area router replaces the Autonomous System Boundary Router (ASBR) summary LSA (type 4).It advertises the location of an ASBR.
•
OSPFv3 runs on a per-link basis rather than on a perIP subnet basis as in OSPFv2. When OSPF peeringoccurs over a physical link, OSPF packets are sent using the interface link-local unicast address as source. Theflooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocolitself, instead relying on IPv6's Authentication Header (AH) and Encapsulating Security Payload (ESP). Mostpackets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6addresses.
OSPFv3 supports the ability to run multiple OSPF protocol instances on a single link. The OSPFv3 packetheader includes an 8-bit instance ID used to demultiplex the protocol packets. Each OSPFv3 process sets itsconfigured instance value in the OSPFv3 packets that it sends, and ignores received packets with instancevalues from other OSPFv3 processes.
Instance IDs can control communication between routers sharing a physical network and OSPF area, withoutrelying on complex authentication schemes or access lists, as needed in the past. It enables the providers torun separate OSPF routing domains even though they have one or more physical network segments incommon.
Configuration Example
Configuring OSPFv3 on Cisco routers on a broadcast network is straightforward. It requires just enablingOSPF on each interface participating in the OSPF area, as illustrated in Example 4-7.
Example 4-7. OSPF Configuration Example
interface Ethernet1/0 ipv6 address 2001:200::2/64 ipv6 ospf 100 area 1end
164 Part I: Implementing IPv6 Services
164 Part I: Implementing IPv6 Services
On NBMA interfaces, the neighbor is explicitly configured.
In addition, if the OSPF router does not have an IPv4 address configured, a router ID must be configured. Thisis done under IPv6 router mode.
Other useful options can be configured under IPv6 router mode, such as enabling routes summarization at anarea boundary or enabling authentication for an OSPF area, as illustrated in Example 4-9.
Example 4-9. OSPF Options
ipv6 router ospf 100 router-id 200.11.11.1 area range 1 2001::/48 area 1 authentication ipsec spi 678 md5 1234567890ABCDEF1234567890ABCDEF
Finally, to verify proper OSPF configuration, you can use the following show command.
Example 4-10. OSPF Status
Router#show ipv6 ospf Routing Process "ospfv3 100" with ID 200.11.11.1 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Area 1 Number of interfaces in this area is 2 SPF algorithm executed 4 times Area ranges are 2001::/48 Passive Advertise Number of LSA 12. Checksum Sum 0x04F3D1 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0
The show commands display the process ID and OSPF router ID, the configured LSA timer values, thenumber of areas, and details about each.
Part I: Implementing IPv6 Services 165
Part I: Implementing IPv6 Services 165
IS-IS for IPv6
The Intermediate System-to-Intermediate System (IS-IS) protocol is described in ISO Standard 10589. Thislink-state, OSI routing protocol was not originally developed for IP but rather to provide the routingfunctionality between the routers of Connectionless Network Protocol (CLNP)-based networks. With theaddition of IPv4 support (RFC 1195), the protocol, sometimes referred to as Integrated IS-IS (I/IS-IS), waswidely adopted as the IGP of choice for many ISP and large enterprise networks. (For more information, referto the book IS-IS: Deployment in IP Networks, by Russ White and Alvaro Retana.
In many respects, IS-IS is similar to OSPF, but some terminology and implementation differences do exist.For example, packet encoding in IS-IS is Type Length Value (TLV) based and makes the protocol easilyextensible. Nested TLVs also offer granularity in the protocol extensions.
The link state, link prefix/mask, link weight, and other local connectivity parameters are advertised in linkstate packets (LSPs). Unlike the OSPF LSAs that are exchanged at the IP level, the IS-IS LSPs are exchangedat layer 2. This makes IS-IS less vulnerable to spoofing or other attacks.
Note
Before deploying IS-IS in an IPv6 network using tunnels, it is important to make sure that the tunnelingmechanisms used can forward the IS-IS LSPs.
Similar to OSPF, IS-IS also elects a DR, called a designated intermediate system (DIS). The DIS, however,does not select a BDR. Should the DIS fail, a new DIS election process is started. Notably, IS-IS does nothave direct support for NBMA networks.
IS-IS implements a two-level routing hierarchy as well, an important feature for scalability. Despite that, mostIS-IS deployments are rather flat. Unlike OSPF, where interfaces are bound to areas (thus enabling routers tobelong to multiple areas), in IS-IS the routers belong to a single area. A router (called intermediate system, orIS) performing intra-area functions is a level 1 router. A router performing inter-area functions is a level 2router.
IS-IS, like OSPF, supports authentication, it supports CIDR, and it transports MPLS traffic engineering linkinformation. Both protocols are deployed in enterprise as well as ISP networks (with OSPF more common inenterprise networks, and IS-IS more common in large ISP networks).
Support for IPv6
The third network protocol supported by I/IS-IS is IPv6 (draft-ietf-isis-ipv6-02.txt). The implementationrequired a new protocol ID (0X8E) that was set to be used by the IPv6 routers to signal their capability tosupport ISISv6 and two new TLVs: IPv6_Reachability (0XEC) and IPv6_Interface_Address (0XE8).Extending IS-IS to support IPv6 is an exercise similar to extending it to support IPv4, unlike OSPF where anew protocol had to be developed. For this reason, IS-ISv6 is operationally similar to IS-ISv4. FewIPv6-specific differences exist. Neighbors are listed in the adjacency table with their link-local address.Because the link-local is used in the Hello packets, adjacencies can be built between neighbors even if they donot share the same prefix. From a user perspective, a new address family was added for IPv6. Mostconfiguration commands available for IS-ISv4 are also available for IS-ISv6 with minimal format changes.
IS-IS uses a single topology and runs the same SPF calculation for all protocols supported. This mode ofoperation leads to certain deployment constraints.
166 Part I: Implementing IPv6 Services
166 Part I: Implementing IPv6 Services
Single Topology
By default, IS-IS runs with a single topology for all protocols supported and a single instance of the SPFcalculation per level (1 = area, 2 = domain). This could be a benefit in that fewer resources are being used bythe routers to operate it. On the other hand, the single topology mode comes with some restrictions:
All routers within an area (level 1 or level 2) must support the same set of address families on allinterfaces. This ensures topology consistency. It also means that the single topology mode is notsuitable in IPv4 networks where only some islands of IPv6 will be deployed.
•
The interface configured metric applies to both IPv4 and IPv6.•
This need for capabilities consistency raises this question: What will happen when an IS-ISv4 network ismigrated to the IS-ISv4+IS-ISv6 network? Because routers are configured with the additional IPv6 addressfamily, the adjacencies will be dropped until the consistency is reestablished. To avoid impacting theoperating IPv4 service, you can disable the adjacency checking.
Note
To avoid inconsistencies in the operational network, only disable adjacency checking during the migrationprocess.
Multitopology
IS-IS was later enhanced to support independent topologies and SPF calculations for each protocol(draft-ietf-isis-wg-multi-topology.txt). In this case, various routers can support different sets of addressfamilies. To add multitopology support for IPv6, a new Multi_Topology_Reachable_IPv6_Prefixes TLV isdefined. The multitopology operation can be enabled under the IPv6 address family. In this mode ofoperation, you can set the IPv6 metric independently of the IPv4 one.
To facilitate the migration from single topology to multitopology, you can enable a transition mode. In thiscase, both types of TLVs are advertised in LSPs. Larger LSPs are thus traded off for a smooth transition.
Configuration Example
The simplest way to configure a router to run IS-IS for IPv6 is to enable the protocol on an interface with anIPv6 address. No changes are needed to the configuration of the IS-IS process for IPv4, as illustrated inExample 4-11.
You must configure IPv6 on the interface for the IS-ISv6 process to start.
In this example, IS-IS is operating in single-topology mode. The show ipv6 protocol command indicates thatIS-IS is running on the interface (highlighted below). The adjacencies built with other routers show both IPprotocol addresses, as highlighted in Example 4-12.
Example 4-12. ISIS Neighbor Status
Router1#show clns is-neighbors detailSystem Id Interface State Type Priority Circuit Id FormatRouter2 Fa0/1 Up L1L2 64/64 Router2.01 Phase V Area Address(es): 49.0001IP Address(es): 10.7.1.34*IPv6 Address(es): FE80::2B0:4AFF:FE5C:ACA9
Uptime: 00:01:25 NSF capable
The IPv6 adjacency is identified through the link-local address, so the global prefix configured on theinterface is not relevant for it. A look at the database reveals the capabilities of the neighbors. The followingoutput obtained from the show isis command illustrates the level 1 circuit of the Router2 neighbor.
Example 4-13. IS-IS Database
Router1#show isis database verbose level-1...IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OLRouter2.00-00 0x0000000B 0xAB35 1020 0/0/0 Area Address: 49.0001NLPID: 0xCC 0x8E
Hostname: Router2 IP Address: 10.7.1.34 Metric: 10 IP 10.7.1.32 255.255.255.252IPv6 Address: 2001:FFFF:FFFF::1
Metric: 10 IPv6 2001:FFFF:FFFF::/64 Metric: 10 IS Router2.01
The protocol ID number 8E indicates the support for IPv6. Because in this case IS-IS runs a single topology,no distinction is made in the output between IPv4 and IPv6. By the same token, there is no output for showisis ipv6 topology.
Further protocol customization can be done similar to IPv4, from enabling authentication and summarizationto adjusting metrics. The important thing to remember is that in the single-topology mode, you cannotconfigure the changes on a per-protocol basis.
If the network design requires the two IP protocols to operate independently at the cost of more routerresources used by the two instances of the protocol, you can migrate IS-IS to a multitopology mode. In thiscase, you specifically configure the IPv6 address family under the IS-IS process, as shown in the
168 Part I: Implementing IPv6 Services
168 Part I: Implementing IPv6 Services
configuration excerpt in Example 4-14.
Example 4-14. Migrating IS-IS to Multitopology Mode
router isis example-area net 49.0001.0000.0000.0001.00metric-style wide transition
!address-family ipv6multi-topology transition
The transition option is elected to allow routers in different modes to coexist during the migration. You shouldremote this option when the migration is completed.
With the change to the new operation mode, the outputs of the show commands reflect the existence of twodistinct topologies for the two IP protocols.
Example 4-15. Multitopology IS-IS Neighbor Details
Router1#show clns is-neighbors detailSystem Id Interface State Type Priority Circuit Id FormatRouter2 Fa0/1 Up L1L2 64/64 Router2.01 Phase V Area Address(es): 49.0001 IP Address(es): 10.7.1.34* IPv6 Address(es): FE80::2B0:4AFF:FE5C:ACA9 Uptime: 00:00:14 NSF capable
Topology: IPv4, IPv6
You can now view the IPv6-specific topology.
Example 4-16. Multitopology IS-IS Topology
Router1#show isis ipv6 topology level-1IS-IS IPv6 paths to level-1 routersSystem Id Metric Next-Hop Interface SNPARouter2 10 Router2 Fa0/1 00b0.4a5c.aca9
The database information also reflects the multitopology mode of operation.
Example 4-17. Mutiltopology IS-IS Database
Router1#show isis database verbose level-1IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OLRouter2.00-00 0x00000014 0x8B3E 1086 0/0/0 Area Address: 49.0001
Metric: 10 IP 10.7.1.32/30 IPv6 Address: 2001:FFFF:FFFF::1Metric: 10 IPv6 (MT-IPv6) 2001:FFFF:FFFF::/64Metric: 10 IS (MT-IPv6) Router2.01
Again, the configuration can be detailed further as it is done in IPv4. In this mode, however, you can tweakthe IS-IS operation independently for each protocol with commands such as isis ipv6 metric that adjust themetric on an interface only for IPv6.
BGP
Border Gateway Protocol version 4 (BGP4) is the EGP used to exchange routes between autonomous systemsin the Internet. BGP was designed based on experience gained with EGP, and provides built-in support forCIDR and route aggregation. BGP4 is specified in RFC 1771 and other BGP-related documents: RFC 1772,RFC 1773, and RFC 1774. For in-depth information about BGP, refer to the book Internet RoutingArchitecture: The definitive BGP resource, by Bassam Halabi.
Almost no coordination of global policies takes place between autonomous systems (because of thedifficulties of coordinating policies between independently administrated systems, and because ISPs are notinclined to reveal the setup of internal policies). In this context, a distance vector protocol could not by itselfguarantee loop-free paths and fast convergence across autonomous systems. BGP is a path vector protocol,essentially a distance vector protocol that does not rely on the distance to destination to guarantee a loop-freepath but on the analysis of the path itself. A direct consequence of this approach is that the path, a list oftraversed autonomous systems, is accumulated and carried between BGP routers.
The BGP basic unit of routing information is the BGP path, a route to a certain set of CIDR prefixes. Paths aretagged with various path attributes, of which the most important are AS_PATH and NEXT_HOP.
The AS_PATH attribute contains a list of autonomous systems a route goes through to get to the destination.Loops are detected and avoided by checking that the router's own ASN is not in the AS_PATHs received fromneighboring autonomous systems.
The NEXT_HOP attribute is another important piece of the BGP route advertisement. When the BGP updatecrosses autonomous system boundaries (see the eBGP discussion below), the NEXT_HOP attribute ischanged to be the IP address of the boundary router, while, as long as updates remain within an autonomoussystem, the next hop is left unchanged (see the iBGP discussion below). That ensures that within theautonomous system, the next hop is always the IP address of the external peer that announced the destinationprefix, and that internal BGP peers do not have to be on the path to the advertised destination.
BGP can be deployed in two forms: exterior BGP (eBGP) and interior BGP (iBGP). eBGP is used forinterautonomous system peering, whereas iBGP carries BGP path information inside the same autonomoussystem. Although some of the information (route, metric) carried by iBGP might be redundant with thatadvertised by IGPs, such as IS-IS, OSPF, and so on, no IGP is capable of transporting BGP-specific pathattributes such as the AS_PATH. Hence, iBGP is necessary to ensure that BGP path attributes received on oneedge of the autonomous system, over the eBGP connection, are available on the other edge of the sameautonomous system. Figure 4-1 illustrates where eBGP and iBGP apply and the next-hop/AS_PATH attributesetting.
170 Part I: Implementing IPv6 Services
170 Part I: Implementing IPv6 Services
Figure 4-1. BGP Deployment Example
[View full size image]
To understand how the next hop is updated or propagated, depending on BGP peering type, and how andwhere the AS_PATH is accumulated, you can look at BGP tables of routers in Figure 4-1. In this example,router CE1 advertises a route 2001:200:1::/48 over eBGP to PE1. At PE1, this prefix is received withAS_PATH={200}, and NEXTHOP 2001:100:1:1::2 (CE1). At PE2, the same prefix, received over iBGP, hasthe attributes AS_PATH and NEXTHOP unchanged, as illustrated in the following output of show bgp ipv6command.
Example 4-18. iBGP: Entry Received with Next Hop Unchanged
PE2#show bgp ipv6BGP table version is 8, local router ID is 200.10.10.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path*>i2001:200:1::/48 2001:100:1:1::2 0 100 0 200 ?
When sent from PE2 to CE2, the prefix is announced with AS_PATH={100,200}, and NEXTHOP2001:100:2:1::1 (PE2), as illustrated in Example 4-19.
Example 4-19. eBGP: Entry Received with Next Hop Changed
CE2#show bgp ipv6BGP table version is 8, local router ID is 200.15.15.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete
Part I: Implementing IPv6 Services 171
Part I: Implementing IPv6 Services 171
Network Next Hop Metric LocPrf Weight Path*> 2001:200:1::/48 2001:100:2:1::1 0 100 200 ?
BGP runs over a TCP transport protocol. On connection start, BGP peers exchange complete copies of theirrouting tables. From there, the BGP peers maintain their respective routing database by exchanging onlydeltas, which makes the protocol fairly efficient as far as number of control messages is concerned.
In addition to BGP attributes, CIDR is used by BGP to aggregate prefixes and reduce the size of the routingtables. When an ISP has been delegated a block of addresses, and has allocated part or this block to its owncustomers, BGP can aggregate routes received from these customers, and announce the entire block to itsBGP peers, allowing a significant reduction in the number of BGP routing tables.
Use of MP-BGP Extensions for IPv6 Interdomain Routing
Multiprotocol BGP4 (MP-BGP), specified in RFC 2858, defines extensions enabling BGP4 to carry routinginformation for multiple network layer protocols. Specific network layer protocol bits are specified in separateRFCs: for IPv6, it is RFC 2545. Only three pieces of information carried by BGP4 are IPv4 specific:
The next-hop attribute contains the IPv4 address of the via router.• The aggregator attribute contains the ASN and the IPv4 address of the router performing theaggregation.
•
The Network Layer Reachability Information (NLRI) is a set of IPv4 prefixes, used for pathadvertisement and withdrawal.
•
RFC 2858 assumes that any BGP speaker has an IPv4 address, which can be used in the aggregator attribute.Therefore, to enable BGP4 to support routing for multiple network layer protocols, the next hop and the NLRIwere generically (as TLVs) inserted into a new MP_REACH_NLRI attribute. NLRI was also in a newMP_UNREACH_NLRI attribute. The former attribute is used to announce feasible routes, and the latter towithdraw unfeasible ones. Each of these attributes starts with an Address Family Identifier (AFI) andSubsequent Address Family Identifier (SAFI), to identify the network layer protocol. Both the next hop andthe NLRI are variable-length fields, specified for each AFI/SAFI.
For IPv6 unicast (AFI:2, SAFI:1), the next-hop field is composed of a next-hop length, and one or two IPv6addresses, as detailed in the "BGP Next Hop" section. The NLRI is one or several 2-tuples of the form<length, IPv6-prefix>. Note that IPv6 prefixes can also be found in other SAFI, such as multicast (SAFI:2),label (SAFI:4), or VPN (SAFI:127). Although the formats of the next hop might vary from one SAFI toanother (for instance, VPN will mandate a next hop in the form RD:IPv6-address, as detailed in Chapter 7,"VPN IPv6 Architecture and Services"), as well as the NLRI (for SAFI:4, it is a 3-tuple <length, label,prefix>), the two attributes introduced by MP-BGP still work in all these cases.
MP-BGP extensions provide support for IPv6 through capability negotiation using the capability parameter ofthe OPEN message. During session establishment, the BGP peers negotiate capabilities as defined in RFC2842. A BGP session could end up with many AFI/SAFI-negotiated capabilities, as shown in Example 4-20.
Example 4-20. BGP Neighbor Status
PE1#show bgp all neighborsFor address family: IPv4 UnicastBGP neighbor is 200.10.10.1, remote AS 100, internal link BGP version 4, remote router ID 200.10.10.1 BGP state = Established, up for 00:07:04 Last read 00:00:40, hold time is 180, keepalive interval is 60 seconds
172 Part I: Implementing IPv6 Services
172 Part I: Implementing IPv6 Services
Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Address family IPv6 Unicast: advertised and received ipv6 MPLS Label capability: advertised and received Address family VPNv4 Unicast: advertised and received Address family VPNv6 Unicast: advertised and received
BGP itself works exactly the same way whether it is BGP4 or MP-BGP for a particular AFI/SAFI such asIPv6 unicast.
The interaction between BGP and the IGP running throughout the autonomous system, the scaling elementssuch as route reflectors, the distinction between interior and exterior peers, the route aggregation, thenumerous BGP features, and so on are architectural elements that still apply to MP-BGP IPv6.
BGP Peering
In the most typical cases, BGP peering for announcing IPv6 routes will occur over an IPv6 transport, andeventually coexist with a separate BGP session for announcing IPv4 routes, as shown in Example 4-21.
Example 4-21. Using Distinct BGP Sessions for Address Families IPv4 and IPv6
Note that although the BGP transport layer and address families advertised underneath deal with differentnetwork layer protocols, the ASNs are identical between IPv4 and IPv6. The deployment model implied bythe preceding configuration example suggests that BGP operates independently for IPv4 and IPv6, withseparate sessions over distinct transport layers. Although this is an optionattractive when IPv4 and IPv6topologies are different because it provides the most flexibilityit is not mandated by BGP, and could bringadditional configuration and operation complexity.
As mentioned earlier, MP-BGP runs over TCP. The protocol version (IPv4 or IPv6) used to establish the TCPsession is independent of the address family being advertised. In fact, as shown in the example in the previoussection (show bgp all neighbors), the same TCP (and BGP) session (over TCP IPv4 in the example) cantransport multiple address families (for instance, IPv4 unicast and IPv6 unicast).
However, be aware of a couple of pitfalls while mixing transport and address families of different versions.The next hop advertised in the next-hop MP-BGP attribute is defaulted to the endpoint of the connection: Youcan easily understand that such a default cannot work when advertising an IPv4 AF over IPv6 or vice versa.The default must then be overwritten (for instance, by using a route-map command). Furthermore, BGP willtry to synchronize the path (next hop) with the IGP: Even if the IPv6 update message has been distributedover TCP-v4, the BGP next hop must be routable, using the IGP running in the autonomous system. This ispart of the verification performed by BGP, before electing a path as "best" and re-advertising to other peers.The "BGP Configuration Example" section shows two cases: IPv6 address family over IPv6 transport, and
Part I: Implementing IPv6 Services 173
Part I: Implementing IPv6 Services 173
over IPv4 transport. With the limitations previously listed, the case of IPv4 address family announced over anIPv6 transport works, too.
BGP Next Hop
As already mentioned, the BGP next hop is either an IPv6 address of the eBGP peer sending the update, or inthe iBGP case, the next hop is left unchanged while re-advertised.
Note
You can explicitly configure the iBGP peer to announce itself as the next hop (next-hop self). Anotherexception arises if the iBGP speaker did not receive a valid global next hop from its eBGP peer, which couldhappen when peering with it over link-locals. Finally, if the iBGP speaker is a 6PE (see Chapter 3,"Delivering IPv6 Unicast Services," for details), it must be on the labeled data path, to decode packets withlabels that it owns: In that case, too, it will put itself as the next hop.
When the BGP IPv6 peers share a common subnet, the MP_REACH_NLRI attribute contains a link-localaddress next hop, in addition to the global address next hop. The link-local next hop is then used locally,whereas the global next hop is eventually re-advertised by BGP. As a consequence, a BGP speaker thatadvertises a route to an internal peer may modify the network address of next-hop field by removing thelink-local IPv6 address of the next hop.
Using a link-local next hop to compute the routing interface for reaching a particular prefix proves especiallyuseful with eBGP, when combined with peering over the link-local address. In case the peer changes its globaladdress for whatever reason, neither the peer connection nor the next hop will be directly affected, and noforwarding hole should be seen. Of course, BGP entries will be updated (the renumbered global next hopshould trigger new updates to be sent), but the connection should not be reset.
Example 4-22 illustrates a BGP peering using a link-local address at node CE1, as in Figure 4-1.
Example 4-22. Using Link-Local Address for BGP Peering
router bgp 200neighbor FE80::A8BB:CCFF:FE01:F600%Ethernet0/0 remote-as 100 ! address-family ipv6neighbor FE80::A8BB:CCFF:FE01:F600%Ethernet0/0 activateneighbor FE80::A8BB:CCFF:FE01:F600%Ethernet0/0 route-map SETNH out redistribute connected no synchronization!route-map SETNH permit 10 set ipv6 next-hop 2001:100:1:1::2
Note that the link-local address (highlighted) is followed by the interface to which it belongs. This is becauselink-local addresses are not guaranteed to be unique across interfaces of the router, as explained in Chapter 2,"An IPv6 Refresher." A next hop with a global address is set explicitly (using route-map) so that it can bepropagated by PE1 to PE2 over iBGP.
In the preceding example, the resulting entries in the routing table are as shown in Example 4-23.
174 Part I: Implementing IPv6 Services
174 Part I: Implementing IPv6 Services
Example 4-23. Displaying BGP Table Entries and Next Hop
CE1#show bgp ipv6 BGP table version is 7, local router ID is 200.14.14.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete
While only the global next hop (2001:100:1:1::1) is displayed in this summary, a closer look at one of theseentries will show the following.
Example 4-24. Details of One Specific BGP Entry's Next Hops
CE1#show bgp ipv6 2001:100:1:1::/64BGP routing table entry for 2001:100:1:1::/64, version 71Paths: (2 available, best #2, table default) Advertised to update-groups: 1 100 2001:100:1:1::1 (FE80::A8BB:CCFF:FE01:F600) fromFE80::A8BB:CCFF:FE01:F600%Ethernet0/0 (200.11.11.1) Origin incomplete, metric 0, localpref 100, valid, external Local :: from 0.0.0.0 (200.14.14.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
The link-local next hop, FE80::A8BB:CCFF:FE01:F600, is shown in parentheses, after the global next hop,2001:100:1:1::1.
Note
Even though the eBGP speaker (CE1 in Figure 4-1) is peering over a link-local, and advertising a link-localnext hop, it must also provide a global next hop to enable the eBGP (PE1) to propagate it to its iBGP peers.This global next hop must be explicitly set by a route map. In the absence of it, PE1 will announce one of itsown global addresses and become the intermediate step router for all traffic to CE1.
Part I: Implementing IPv6 Services 175
Part I: Implementing IPv6 Services 175
BGP Configuration Example
The following BGP configuration extract shows how to configure the IPv6 address family, for both eBGP andiBGP.
In this example, the IPv6 address family is configured and activated toward an iBGP peer (with an IPv6 TCPendpoint 2001:100:3:4::1) as well as toward an eBGP peer (IPv4 TCP endpoint 200.10.10.1). For the latter,the route-map statement sets explicitly the next hop, which is expected to be reachable from the peer, eitherusing a default route, some IGP, or because peers are sharing a common subnet.
Site Multihoming
A multihomed site is a site that has multiple connections to the Internet. It can be multiple connections to thesame ISP, links to different ISPs, or multiple connections in separate geographic locations.
There are many reasons to multihome, including the following:
Redundancy• Load sharing• Policy•
The most persuasive reason for multihoming is redundancy. A well-designed multihome solution should beable to handle most failures (from a failed link or failed router to a transit ISP being down).
When you have all those expensive redundant links, the next logical step (when the finance department isbreathing down your neck) is to use that extra capacity for traffic. That is where load sharing comes in.
The IPv4 multihoming solution is to let the routing system sort it out. The customer's prefix is advertisedusing BGP to all the ISPs to which the customer connects. This works with both provider independent (PI)address space and provider aggregated (PA) address space. In the latter case, when the multihomed site hasaddresses from one of the ISPs, advertising that address block will punch a hole in that ISP's aggregate. Eitherthe customer has its own ASN, or uses a private ASN. In the latter case, ISPs will rewrite it with their own.
For the multihomed site, this solution works well. Even existing transport sessions survive in the case of a"rehoming" event.
176 Part I: Implementing IPv6 Services
176 Part I: Implementing IPv6 Services
The problem with this way of multihoming is that it does not scale well. Each multihomed site requires a slotin the default Internet routing table. Not only does this require more memory and higher processingcapabilities in the core routers, it also results in more routing churn, pushing the current routing protocols tothe limit. Doomsayers keep insisting that the end is near. Even if they are wrong, it would be good to come upwith a better solution, one that also allows smaller organizations to multihome. Today's solution requires thatyou have a fair-sized address block, because small advertisements are typically filtered out; it also requiresthat the multihomed site have its own ASN. Both of these prerequisites are unavailable to the typical homeuser.
The original IPv6 address-allocation plan was that a multihomed site would get an address block from each ofits providers. Hosts would then have multiple addresses, one for each of its providers. Transport protocolssuch as TCP do not allow renumbering on-the-fly. IP addresses used as endpoints for an active TCPconnection cannot be changed. So, if the link to one provider fails, and a host picks a source address from thatprovider, the transport connection fails.
A better solution was clearly needed. The multi6 working group was created in the IETF and charted withdefining the requirements and looking at the solution space for scalable multihoming. Several interesting ideascame up. A basis for several of them was that there had to be a separation of the identifier and the locator of anode. The IP address currently serves as both. This is not a trivial thing to change, and the most promisingsolution is to insert a shim layer between the IP header and the transport header, which will handlemultihoming. Note that this is a shift from multihoming being handled by the network to multihoming beinghandled by the hosts. There are some obvious deployment issues with this (for instance, all hosts you need tocommunicate with should support multihoming), but let's assume that these issues will be resolved.
There is hope that a scalable multihoming solution will be found. Until then, IPv6 multihoming is done just asit is for IPv4. Anyone who does IPv4 multihoming today will most likely qualify for doing multihoming inIPv6, too.
Deploying IPv6 Routing Protocols
One simple conclusion that can be drawn from the information presented in this chapter so far is that theimplementation and operation of the IPv6 RPs are similar to their IPv4 counterparts. This means that as far asrouting is concerned, all design rules and strategies used in deploying IPv4 networks apply to IPv6. Theapproach has to be hierarchical and it has to observe the specifics of each layer of the network: core,distribution/edge, and access.
Network Core
The network core is highly redundant to ensure uninterrupted service. The routing protocols deployed in thecore have to leverage the infrastructure by providing fast reconvergence around failures. The traffic should beload balanced across the redundant, equal-cost paths.
The following IGPs are suitable for the network core:
EIGRPIt is commonly used in enterprise networks. It could be used in the core of ISP networks, but todate has not been.
•
OSPFIt is a scalable and fast-converging option that is commonly used in the core of both enterpriseand ISP networks. It could be deployed in single or multiple areas, but it will impose topologicalconstraints.
•
Part I: Implementing IPv6 Services 177
Part I: Implementing IPv6 Services 177
IS-ISIt is commonly used in ISP networks and rarely in enterprise networks. Almost always, it isdeployed in a single-area (level 2) design.
•
Note
Because it is expected that traffic engineering (TE) will be considered in IPv6 MPLS networks, it is importantto remember that TE requires IS-IS or OSPF.
One of the main design concerns is the scale of the network in terms of number of nodes. OSPF topologies arelimited by the network and router LSA size. IS-IS topologies are limited by the LSP count. In a well-designednetwork, these scalability limitations should not be encountered. If the same RP is used across thedistribution/edge layer, however, OSPF should be using multiple areas (whereas IS-IS scales comfortablywith its flat design). It is important to make sure that the distribution/edge layer is injecting a small number ofprefixes in the core RPs, thus ensuring stability and rapid reconvergence.
IPv4 and IPv6 are expected to coexist in networks for a long time. This implies the coexistence of at least twoRPs that have to be managed by the network operator and by the network devices. Some operators might notbe willing to take on this task and prefer to minimize this impact of deploying IPv6 services. From this pointof view, you have two options to consider:
If the IPv6 topology can be identical with the IPv4 one in a dual-stack deployment, ISISv6 insingle-topology mode addresses the manageability and resource duplication concerns.
•
When tunneling (transition tunnels or 6PE) is used as an overlay to provide transport for IPv6 traffic,the IPv6 RP is not a concern for the IPv4 core. Inside the IPv6 network, iBGP running on edge routers(see the following section) can be used to exchange the IPv6 routing information, too. This impliesthe use of a single, already running RP for both IPv4 and IPv6.
•
In both of these cases, the operator will have to run a familiar protocol while saving router resources at thecost of some topology constraints. As the significance and amount of IPv6 traffic increases, the RP design ofthe network might need to be revisited to address new requirements.
Network Distribution/Edge
This network layer provides the interface between the access and the core layers. It also provides the interfacewith external networks. At this layer, IGPs are used alongside BGP.
The same IGPs recommended for the core are suitable for the distribution/edge layer, too. In fact, the same RPoften times covers both network layers. If the protocol used is OSPF, a hierarchical approach is suggestedwith the core in the backbone area and the distribution/edge split in multiple areas. IS-IS and EIGRP extendflatly over this layer.
BGP is also deployed at this network layer. iBGP is used between distribution/edge routers for the followingreasons:
Tie up eBGP speakers together by propagating BGP-specific attributes (NEXTHOP, AS_PATH)across the core
•
Avoid overloading the core with routing information that is not relevant to it that could impact itsconvergence time
•
Exchange information with customers without having to expose the underlying IGP to the customernetwork complexities and instabilities
•
178 Part I: Implementing IPv6 Services
178 Part I: Implementing IPv6 Services
Enable services such as VPNs or 6PE•
The iBGP is deployed in a full mesh realized with the help of route reflectors, confederations, or by fullymeshing all the participating routers.
eBGP is used in the following deployment cases:
To exchange routing information between domains within large service provider or enterprisenetworks designed with multiple autonomous systems.
•
To exchange routing information with external networks. It enables the use of policies andaggregation.
•
To enable services such as "Carrier supporting Carrier" (CsC), which allow an ISP to be a transit forother ISPs.
•
Similar to IPv4 deployments, iBGP should be synchronized with the underlying IGP but, for scalabilityreasons, prefixes should not be distributed between them.
Network Access
The devices in the access layer are exposed to multiple users, but they tend to have less processing power thanthe ones in the other network layers. Moreover, because of IPv6 address assignment guidelines, it is likely thatthese devices will be exposed to large numbers of prefixes in the /64 to /48 range. For these reasons, complexand process-intensive RPs are not deployed in this network layer.
Although OSPF is used at the access layer, simpler routing protocols such as RIPng or EIGRP are sometimesfavored. Static routing is also used actively. Static routes are manually configured or are dynamically installedduring the address-assignment process (as is the case of DHCP-PD). The redistribution of static routes iscommon in this part of the network. Summarization is also an important aspect of the routing design. Theupstream layers should be presented with a smaller number of prefixes to preserve resource in the aggregationnodes.
Chapter 5. Implementing QoS
The rapid adoption of IP communications and the deployment of more complex andbandwidth-demanding applications led to a tremendous increase in network use. In anetwork with limitless resources, this would not be an issue. Although the technology isavailable to throw bandwidth and more powerful switching nodes at the problem, that isnot always the best solution. A TCP session, for example, tries to use as muchbandwidth as is available, to the detriment of other IP flows using the same links.Regardless of bandwidth, links can become congested due to various factors such asbacking up failed paths in the network or handling the unpredictable traffic resultingfrom a security attack. At the same time, upgrading links and network nodes to handlehigher bandwidths usually is an expensive proposition. Companies will try to make themost of the existent infrastructure and increase their return on investments (ROI).Concerted proactive measures can limit the probability that congestion will occur, butultimately, traffic congestion is a fact of life in any network. Under such circumstances,the network operator must decide how to manage it and how to allocate the networkresources based on traffic types. Congestion-management mechanisms should beconsidered regardless of the bandwidth available.
Part I: Implementing IPv6 Services 179
Part I: Implementing IPv6 Services 179
Networks provide a service to applications by transporting their data. Differentapplication types have different expectations from this service; they demand a certainquality of service (QoS). These expectations are for the entire path of the traffic, makingQoS an end-to-end concept. Applications such as interactive voice communications,audio, and video are sensitive to delay and delay variations (jitter), but they can afford tolose randomly a small percentage of the traffic. At the other end of the spectrum are themission-critical applications that need reliable, no-loss data transfers.
The service level needs of any type of traffic can generally be quantified through a set ofparameters such as the following:
Service availability, which represents the percentage of uptime for the service• Packet delivery ratio• Round-trip time• Jitter, which measures delay variations•
For any given service, the target values for such parameters are listed in a service levelagreement (SLA). The SLA can represent the internal network performance goals of anenterprise. It can also represent a contractual agreement between a service provider andits customers.
To meet the requirements of SLAs, the network has to be able to identify different typesof traffic, to reserve bandwidth, to improve the loss characteristics, to avoid and managecongestion, and to prioritize the traffic. These functions are performed by routers andswitches across the entire network in the context of an end-to-end QoS deploymentmodel. Two such models are identified in the case of IPv4:
Integrated services (IntServ) (RFC1633) Rely on a signaling mechanism toreserve the necessary resource prior to forwarding the traffic across the network.This approach simulates the operational concepts of a circuit switchedenvironment.
•
Differentiated services (DiffServ) (RFC 2475) Rely on policies that are definedon the network nodes and on packets being matched against and switched basedon these policies.
•
Network elements leverage several mechanisms that enable them to support theimplementation of these IP QoS models, as follows:
Classification and marking Classification is used to separate packets based oncertain characteristics such as Source or Destination Address, predefinedpatterns of the 8 bits in the Type of Service (ToS) IP header field (IP precedenceor differentiated services code point, DSCP) and higher-layer protocolinformation. The ToS field of a packet header can be overwritten by routers witha value relevant to the QoS policies defined in that network. This action on apacket is called marking.
•
Traffic conditioning (policing and shaping) The policing function enables therouter to force inbound and outbound traffic to stay within a defined profile.Any traffic that does not observe the constraints of the profile is dropped.Through shaping, the router avoids downstream congestion by buffering trafficthat does not fit a defined profile.
•
Congestion avoidance A mechanism that routers can implement to detect thepossible buildup of congestion by monitoring the use of output buffers. If thebuffers are getting full, the low-priority packets are dropped to save resourcesfor the high-priority ones.
•
180 Part I: Implementing IPv6 Services
180 Part I: Implementing IPv6 Services
Congestion management The way the router handles an overflow of traffic. Thisfunctionality is implemented through various queuing algorithms.
•
Figure 5-1 schematically captures these mechanisms as they operate within a router.
Figure 5-1. QoS Mechanisms in a Router
[View full size image]
These mechanisms are implemented the same way in both versions of IP. A number ofbooks focus specifically on this topic, such as IP Quality of Service, by SrinivasVegesna. Table 5-1 lists the QoS features supported by Cisco platforms both IPv4 andIPv6 along with layer 2 QoS features.
Table 5-1. QoS Mechanisms and Their Implementation in Cisco Devices
QoS MechanismImplementationNotes IPv4IPv6
Classification Precedence X XDSCP X XNetwork-basedapplicationrecognition(NBAR)
X N/A
Marking Class-basedmarking(CBM)
X X
Committedaccess rate(CAR)
X
Policy-basedrouting (PBR)
X X
Policing and shaping Rate limiting X XClass-basedpolicing (CBP)
Table 5-1 shows that in Cisco products only a limited number of IPv4 QoS features are not available for IPv6at the time of this writing.
Because of the many similarities between IPv4 and IPv6 QoS, this chapter focuses on the few things thatdifferentiate them today. This chapter covers the following topics:
A review of differences between IPv6 and IPv4 QoS• A discussion on the implementation of QoS for IPv6 over MPLS deployments• Examples of configuring IPv6 QoS in a native environment and in an MPLS-based environment• IPv6 QoS deployment considerations•
182 Part I: Implementing IPv6 Services
182 Part I: Implementing IPv6 Services
It is assumed that the reader is familiar with fundamental concepts of IPv4 QoS. You can apply thisknowledge directly toward deploying IPv6 QoS.
QoS for IPv6
It is difficult to understate the value of QoS in today's networks. Its importance isdemonstrated by the fact that IPv4 QoS is deployed in more and more networks. Somehoped for QoS improvements in the next generation of the IP protocol, and some stillbelieve that IPv6 is better than IPv4 in this respect. The reality is that neitherevolutionary nor revolutionary changes were introduced in IPv6 QoS. QoSimprovements in IPv6 are but a myth at this point. The same concepts and samearchitectures apply to the new protocol, with a few small differences and implementationconsiderations that are worth mentioning.
Differences Between IPv6 and IPv4 QoS
QoS is implemented at both layer 2 and layer 3 of the protocol stack. This sectiondiscusses feature implementation and feature support differences between IPv4 QoS andIPv6 QoS at both layer 2 and layer 3. These differences revolve mostly around thetraffic-classification process where packets or flows are differentiated through the use ofvarious parameters such as IP source address, IP destination address, DSCP, or IPprecedence values, and higher-level protocol types. Once classified, the packets can beprocessed according to a policy that reflects their service level. Differences between thetwo versions of the IP protocol could lead to different classifiers.
Layer 3 QoS
The QoS dedicated resource in the IPv4 packet header, the 8-bit ToS field, is mappedidentically to the Traffic Class field in IPv6 and it is used in the same fashion. WithIPv6, however, you must consider several additional classifiers, all related to the IPv6packet header format:
Protocol type or version Because of the anticipated coexistence of the twoprotocols, it is worth considering the case where different service levels areapplied to IPv4 and IPv6 traffic. The Protocol Type field can be used todistinguish the two protocols. Subsequently, more discrete classifications can bedone for the traffic belonging to each protocol type.
•
Flow label The flow label is unique to IPv6 and was originally intended for usewith resource-reservationbased QoS architectures. It was meant to allow routersto easily recognize a flow for which the resources were reserved. RFC3697documents the flow label specifications. This field has the advantage of beinglocated before the Source Address and the Destination Address fields, and thatplacement helps reduce lookup delays. Moreover, the flow label has anadvantage over upper-layer classifiers: It is not lost when the packet load isencrypted. Some hosts' implementations (FreeBSD) do have the option ofsetting the Flow Label field for TCP connections, which can then be used onCisco routers for classifying the flow.
•
Extension headers The extension headers substitute the functionalities of the•
Part I: Implementing IPv6 Services 183
Part I: Implementing IPv6 Services 183
IPv4 header options while keeping the main IPv6 header at a fixed size of 40bytes. These additional elements could also be viewed as possible trafficclassifiers, but this can increase uncontrollably the number of options. At thispoint, there does not seem to be a justification for implementing classificationbased on extension headers.
For the time being, among these IPv6-specific classifiers, the Protocol Type field is mostused in deployments to differentiate between IPv4 and IPv6 traffic. The use of the otheroptions is still being studied.
Other then these few elements that build on the packet format differences between thetwo protocols, IPv6 and IPv4 are similar as far as QoS is concerned. Table 5-1 showssome features missing from the Cisco implementation of IPv6 QoS at the time of thiswriting. These gaps are just a matter of implementation prioritization and schedule.
Layer 2 QoS
QoS is implemented at layer 2, as well. Moreover, layer 2 devices such as switches oftenintegrate the QoS functionalities in hardware, allowing them to support ahigh-performance service. Therefore, layer 2 QoS represents an important element in theoverall network deployment of QoS.
Various layer 2 technologies implement QoS in a specific way. ATM uses many of thefeatures listed in Table 5-1 for individual virtual circuits (VC) or for bundles of VCs.Frame Relay relies on the Discard Eligible (DE) bit to deal with congestion. Ethernetwith its expansion from enterprise networks to metropolitan-area and service providernetworks has seen an increased interest in implementing differentiated services. Ethernetis leveraging its own QoS, as described by 802.1p. All these technologies implementQoS functions on a hop-by-hop basis, relying on concepts similar to those used byDiffServ at the IP layer.
A detailed discussion of layer 2 QoS is beyond the scope of this book. Moreover, theactual operation of these QoS mechanisms depends little on the IP protocol type. Thedependency relates to the fact that layer 3 criteria and parameters are used todifferentiate traffic in classes and mark it for the layer 2 QoS. This means that networkelements performing classification and marking for layer 2 might have to be able todifferentiate between the two versions of IP.
An example of such layer 2 QoS dependency on layer 3 information is that ofcable-technologies QoS. Cable implements its own form of layer 2 QoS standardizedthrough DOCSIS. The current version of Data Over Cable Service InterfaceSpecifications (DOCSIS) 2.0 does not mention ways of classifying IPv6 packets.Therefore, IPv6 packets can be handled only in a Best Effort manner by cable networks.In congestion situations, IPv4 voice traffic would be properly prioritized, whereas IPv6voice traffic would be impacted. At the time of this writing, proposals have been madeto update the DOCSIS standard in its 3.0 revision to support IPv6 QoS. Cisco is activelyparticipating in the CableLabs consortium defining the DOCSIS specifications.
Link-Efficiency Mechanisms
Time-sensitive applications have stringent requirements on end-to-end packet delivery.In the case of voice transport, for example, the end-to-end delay should not exceed 200milliseconds. It is imperative to make sure the packets spend as little time as possible in
184 Part I: Implementing IPv6 Services
184 Part I: Implementing IPv6 Services
the routers (processing delay). Moreover, time delay variations (jitter) can beparticularly annoying in interactive voice communications. This leads to a secondconstraint in that the packets have to be delivered consistently. Assuming that thetime-sensitive traffic is appropriately prioritized for forwarding through other QoSmechanisms, one thing left to do in helping with the timely and consistent delivery oftraffic is conditioning the traffic to better use the links. This conditioning is particularlyimportant when traffic is switched from a fast interface such as 100-Mbps Ethernet to aslow interface such as 56-kbps Frame Relay. Two mechanisms are often used tooptimize the link usage for time-sensitive traffic: Compressed Real Time Protocol(cRTP) and link fragmentation and interleaving (LFI).
The Real Time Protocol (RTP) supports audio and video applications over unicast ormulticast. Its header, together with the IP and UDP header, represents a significantportion of the total packet (which leads to inefficient use of bandwidth, with seriousconsequences under congestion conditions). cRTP compresses the IP, the UDP, and theRTP headers in one single header with significant improvement in link utilization. Theprocess is done by routers and it is done for each individual link, for each hop. Theresources expended by the router on this process are sometimes justified by the serviceneeds. In the case of IPv6, cRTP has to be aware of the IPv6 header format beforeperforming the compression. As shown in Table 5-1, cRTP is not currently supported forIPv6 in IOS.
Large data packets can hold the smaller voice packets in the queue, leading to delays ordelay variations that impact the voice quality. To deal with this problem, a router canfragment the large frames into smaller sizes and interleave them with the smaller onescarrying voice traffic. This feature is called link fragmentation and interleaving, or LFI.The optimization of the link utilization, although coming at a processing cost, can proveuseful. This feature is independent of the IP protocol type being transported.
Note
Note that with LFI, frames (layer 2) and not packets (layer 3) are being fragmented onlower-speed interfaces such as ATM and Frame Relay. The feature is transparent to thelayer 3 protocols, and that is particularly useful in the case of IPv6 (where IPfragmentation is not permitted).
Differentiated Services
The premise of the QoS architecture presented in RFC 2475 is that as long as the trafficis categorized and marked, network nodes can assign resources to the various categoriesbased on pre-established policies that reflect SLA requirements. When traversing a QoSDiffServ-enabled network, a packet goes through the following stages:
The edge or access network elements categorize the packet based on layer 2through 7 parameters. The packet is placed in one of few classes predeterminedby the QoS design of the network.
•
Based on the class it belongs to, the packet is marked by setting a certain valuefor the DSCP field. This marking makes it easy for the downstream nodes tohandle the packet based on the class it belongs to. Reclassification andremarking is possible along the way.
•
Part I: Implementing IPv6 Services 185
Part I: Implementing IPv6 Services 185
Each network element processes the packet based on the policies or a per-hopbehavior (PHB) assigned for its class. This policy is implemented throughmechanisms such as traffic conditioning and congestion management.
•
This hop-by-hop operation model makes DiffServ a scalable and easily interoperableapproach to implementing QoS in both wide- and local-area networks. A number ofclasses are defined for each layer of the network. More classes are defined at the accesslayer, where the bandwidth resources are smaller, for a more granular trafficdifferentiation. In the network core, traffic can be aggregated in fewer classes. QoSmechanisms are leveraged by each network element to implement defined PHBs. Figure5-2 presents a network-perspective example of a DiffServ-based QoS deployment. Eachnode implements appropriate queuing mechanisms and congestion-avoidancemechanisms.
Figure 5-2. A Network Perspective of DiffServ Operation
[View full size image]
Support for IPv6
The IPv6 implementation of DiffServ is identical to IPv4. As mentioned in Table 5-1,some QoS features might not be ported to IPv6, but the available ones suffice toimplement QoS in an IPv6 network.
The same classifiers can be used to differentiate both IPv6 and IPv4 packets, as follows:
Source IP address, destination IP address, IP Protocol field, source port number,and destination port number
•
IP precedence or DSCP values• TCP/IP header parameters, such as packet length• Source and destination MAC addresses•
The IPv6-specific classifiers that were discussed earlier in this chapter are not currentlyused.
186 Part I: Implementing IPv6 Services
186 Part I: Implementing IPv6 Services
The ToS field in the IPv4 packet header was more appropriately named Traffic Class inIPv6, but it is used in the same way: for packet marking and packet classification. Theguidelines for using these 8 bits, also called the Differentiated Service (DS) field in thecontext of the DiffServ architecture, are standardized in RFC 2474. The formatting ofthe Traffic Class field in relation to the DSCP bits is shown in Figure 5-3. The figurealso shows the original (RFC 791) segmentation of this field into IP precedence and ToSbits. The use of the last 2 bits of the Traffic Class, called explicit congestion notification(ECN), is defined in RFC 2481.
Figure 5-3. DSCP and the IPv6 Traffic Class Field
The DSCP marking of a packet is used by the router to classify it and implement thecorresponding PHB. Several PHBs are standardized:
Best Effort (BE).• Expedited Forwarding (EF) is defined in RFC 2598 as a low-loss, low-latency,low-jitter, assured-bandwidth, end-to-end service.
•
Assured Forwarding (AF) is defined in RFC 2597 and further detailed in RFC3260. Four classes are defined, with three levels of drop precedence.
•
DSCP code points are matched to these PHBs, as shown in Table 5-2.
Table 5-2. DSCP Code Points for Standardized PHBs
PHBLow DropPrecedence
MediumDropPrecedence
High DropPrecedence
BE 000000 (No Constraints)EF 101110 Low latency, low jitter,
assured bandwidthAF1 001010
(AF11)001100(AF12)
001110(AF13)
AF2 010010(AF21)
010100(AF22)
010110(AF23)
AF3 011010(AF31)
011100(AF32)
011110(AF33)
AF4 100010(AF41)
100100(AF42)
100110(AF43)
Both IPv4 and IPv6 use the features listed in Table 5-1 to implement the PHBs. For example, the EF PHBwould use the LLQ for its packets, whereas the AF PHBs could use CB-WFQ combined with acongestion-avoidance mechanism such as WRED that allows the router to drop inbound traffic based on
Part I: Implementing IPv6 Services 187
Part I: Implementing IPv6 Services 187
precedence.
Configuration Example
The implementation similarities between IPv4 and IPv6 Diffserv QoS translate into configuration similarities.This section captures some of the IPv6 DiffServ concepts in configuration examples. The most relevant aspectof these configurations is the classification; everything else in terms of QoS configuration is IP versionindependent. The Modular QoS Command Line Interface (MQC) used for IPv4 is available for IPv6, too, withslight syntax changes. With MQC, three configuration steps are necessary to define and implement QoS on arouter:
1. Class map configurationDefine the QoS classes that will be used with this deployment and the matchingcriteria for each of them. The number and type of classes used is driven by the SLAs that will be honoredby the network. Their design can be different in various layers of the network (fewer in the core and moreat the access and edge, for example).
2. Policy map configurationDefine the actions that the router should apply on the packets of each class.
3. Apply the service policyAttach the policies defined through policy maps to the input or output traffic ofan interface.
These steps are implemented in the following edge router QoS configuration example. The relevant aspects ofeach configuration line are highlighted. The highlights will help you connect the explanations in text with theconfigurations. First, four classes are defined on the router through the following class maps:
EF-IPv6 is an EF class for the IPv6 traffic. The packets that belong to this class are identified by theprotocol type and DSCP EF value.
class-map match-all EF-IPv6match protocol ipv6match dscp ef
•
EF-IPv4 is an EF class for the IPv4 traffic. The packets that belong to this class are identified by theirDSCP EF value.
class-map match-all EF-IPv4match ip dscp ef
The ip qualifier in the match command indicates that it is to be applied only to IPv4.
•
AF1 is an AF class for both IPv6 and IPv4 traffic. The packets that belong to this class are identifiedby their DSCP AF11, AF12, AF13 values.
class-map match-all AF1match dscp af11 af12 af13
The classification applies to both IP protocols because there is no matching done on the protocol type.
•
Voice-Control is the class of packets that are of SIP type and that are intended for the server2001:ABCD:EF:1::1.
class-map match-all Voice-Controlmatch protocol sipmatch access-group name Control
•
One match statement applies to the SIP protocol, and the other is matching packets based on the accesscontrol list (ACL) named Control.
188 Part I: Implementing IPv6 Services
188 Part I: Implementing IPv6 Services
ipv6 access-list Controlpermit ipv6 any host 2001:ABCD:EF:1::1
The ACL identifies traffic destined to 2001:ABCD:EF:1::1.
Note
Numbered ACLs are not supported with the match access-group command for IPv6.
The Cisco IOS implementation of QoS reserves a class called class-default for all traffic that does not meetthe matching criteria of any of the other defined classes.
Note
This example was designed to specifically highlight the fact that common classes can be used for IPv4 andIPv6 if the same policies are to be applied to both. On the other hand, when the QoS design is different for thetwo protocols, Cisco IOS software enables the user to distinguish between IPv4 and IPv6 by using distinctclasses.
The next step is to instruct the router in this example on how it should handle the traffic in each of the classesidentified in the previous step. These instructions represent the PHB for this network element. In this example,the router is required to police the inbound traffic for each class, based on the information provided in theingress policy shown in Example 5-1.
For each class, a committed information rate (CIR) is defined in bits per second. The router drops the trafficthat exceeds this CIR for each class except AF1. In the latter case, the router remarks the DSCP value of theoffending packets to Best Effort (all bits set to 0). The policy is applied as inbound on thenetwork-access-facing interface, as shown here:
On the egress, each traffic class is reserved a certain percentage of the bandwidth and a certain amount ofqueue resources. The voice service control traffic to the server identified by the Control ACL is marked forexpedited forwarding. All these instructions are captured in the Egress-Policy-Child shown in Example 5-2.
Example 5-2. Child Egress Policy Configuration Example
policy-map Egress-Policy-Child class EF-IPv6bandwidth percent 15queue-limit 512
class EF-IPv4 bandwidth percent 20 queue-limit 512 class AF1 bandwidth percent 10 queue-limit 1024class Voice-Control bandwidth percent 1 queue-limit 100set dscp ef
MQC enables users to nest QoS policies and create complex PHBs. For example, Egress-Policy-Child is madepart of an envelope policy called Egress-Policy-Parent that also shapes the traffic, as shown in Example 5-3.
Example 5-3. Parent Egress Policy Configuration Example Integrating the Child Policy from Example 5-2
policy-map Egress-Policy-Parent class class-defaultshape average percent 5 100 ms 100 msservice-policy Egress-Policy-Child
This parent policy is applied to the network-core-facing interface:
You can use the show policy-map command to review the policy maps. The same command directed to aspecific interface provides a lot more useful detail on the policies applied to it. For the router in this example,the output for the network-core-facing interface is shown in Example 5-4.
Example 5-4. Review of QoS Policies Applied to a Router Interface
Another useful command in troubleshooting IPv6 QoS is show cef interface detail. Cisco Express Forwarding(CEF) switching has to be enabled for the QoS features to operate on an interface.
The other important aspect of a complete QoS deployment is the implementation of congestion-avoidance andcongestion-management mechanisms. The queuing mechanisms supported for IPv6 (FIFO, FB-WFQ,CB-WFQ, LLQ, MDRR) and the congestion-avoidance mechanisms (WRED) mentioned in Table 5-1 areconfigured in the same way as they are for IPv4.
Part I: Implementing IPv6 Services 191
Part I: Implementing IPv6 Services 191
As mentioned previously, layer 2 technologies employ various hop-by-hop QoS mechanisms, too. The layer 3QoS discussed so far has the capability to modify parameters that are used in implementing certain PHBs bydevices that operate at lower layers. The example presented in this section had the Egress-Policy-Child set anEF value for the DSCP field of packets in class Voice-Control. The set command provides options that enablethe router to modify layer 2relevant QoS parameters, too, as shown in Example 5-5.
Example 5-5. QoS Options Available for the set Command
Router(config-pmap-c)#set ?atm-clp Set ATM CLP bit to 1cos Set IEEE 802.1Q/ISL class of service/user priority
discard-class Discard behavior identifier dscp Set DSCP in IP(v4) and IPv6 packetsfr-de Set FR DE bit to 1
ip Set IP specific values mpls Set MPLS specific values precedence Set precedence in IP(v4) and IPv6 packets qos-group Set QoS Group
With the options highlighted in Example 5-5 enabled, a router modifies the marking of layer 2 framesregardless of the version of the transported IP packet.
As you can understand from the example in this section (if you are familiar with IPv4 QoS), other thanclassification-specific differences, DiffServ QoS is configured the same way for both IP protocols.
Integrated Services
The IntServ model operates similarly to circuit-switched networks. Prior to sending the traffic, resources arereserved across the entire path based on the service level required. This explains the natural mapping ofIntServ to circuit-based network types such as ATM and Frame Relay. In this architecture, there are two sidesto implementing QoS. One is a cross-network control plane that manages the reservation of resources, and thesecond is the traffic handling by each node based on the reservations made for it.
The control aspect of the IntServ is handled by the Resource ReSerVation Protocol (RSVP; RFC 2205). It is acontrol protocol similar to Internet Control Message Protocol (ICMP). In a nutshell, the operation of RSVPrelies on two steps. First, the source of traffic sends a Path message to the destination, and on the way itcollects resource information from the traversed nodes. Second, the receiver sends a response. The message iscalled Reservation, and it requests the resources needed by the application. This is a unidirectional process, sofor a bidirectional flow it has to be started by each end. Through the reservation process, RSVP initiates andmaintains soft state for each flow on all network elements that are traversed by it. This is, of course, a sourceof scalability concerns because routers will have to maintain state for a significant number of flows in largenetworks. Despite improvements made to the RSVP implementation, these concerns have slowed the adoptionof the IntServ versus the DiffServ model.
After resources have been reserved for a given flow, routers have to recognize the traffic and assign to it thereserved resources. In performing these functions, network elements use some of the mechanisms listed inTable 5-1.
Support for IPv6
Differentiated handling of IPv6 traffic at the network element level is supported through the implementationof the various mechanisms listed in Table 5-1. Their availability in Cisco IOS software was discussed in the
192 Part I: Implementing IPv6 Services
192 Part I: Implementing IPv6 Services
DiffServ section of this chapter. This leaves RSVP as the only missing piece necessary to support the IntServmodel for IPv6 QoS.
RFC 2205 makes all the provisions necessary to support RSVP on top of IPv6, and they are similar to IPv4.The RFC also points out that the IntServ model can capitalize on the flow label that is characteristic to IPv6.The flow label could be used to efficiently mark the packets of a flow for the entire path reserved for it. RFC2205 provisions support for the exchange of flow label information in IPv6. The flow label use with RSVPwas envisioned as early as RFC 1809, and operational guidelines for its use were provided in RFC 3697;however, at the time of this writing, no implementations leverage it.
QoS services implemented based on the IntServ model are not common. Today's networks are more likely toleverage the high-bandwidth infrastructures along with DiffServ implementations. For these reasons, at thetime of this writing, there is no implementation of RSVP for IPv6 in Cisco IOS software or other vendorproducts. Nevertheless, RSVP could be implemented in the future, justified by user demand and to addressspecific applications such as videoconferencing. It is also important to note that demand for itsimplementation might not be driven just by QoS. RSVP found its use in implementing other services such aslabel exchange in Multiprotocol Label Switching (MPLS) and in MPLS traffic engineering. The futureIPv6-based MPLS implementations might drive the implementation of RSVP, too.
Note
Note that IPv6 might leverage IPv4 RSVP during the deployment of 6PE and 6VPE, as described in thefollowing section.
QoS for IPv6 over MPLS
MPLS does not define any new QoS architecture. DiffServ architectures as defined in RFC 2474 and RFC2475 still apply in the MPLS environment. However, MPLS has a number of characteristics and specificmechanisms that enable unique capabilities. For these reasons, RFC 3270 was written to describe MPLSsupport of DiffServ. This specification allows support of DiffServ for both IPv4 and IPv6 traffic transportedover an MPLS network. Using DiffServ in an MPLS environment for IPv6 traffic is not different regardless ofwhether the LSP is set up using IPv4 protocols (this is the case for 6PE and for 6VPE) or set up using IPv6protocols. In fact, there are no interactions at all between MPLS DiffServ, which deals with the MPLS shimlayer, and the LSP setup mechanisms itself; this enables DiffServ to be used indistinctly on traffic using labelpaths set up by LDP IPv4, LDP IPv6, RSVP, or even manually set up.
MPLS-TE offers the means to set up paths with explicitly reserved bandwidth across an MPLS core. TheRSVP signaling used by MPLS-TE can be IPv4 or IPv6. At the time of this writing, IPv6 RSVP is not yetsupported on Cisco routers. However, because 6PE and 6VPE use IPv4-signaled LSP, they benefit seamlesslyfrom IPv4 MPLS-TE setup mechanisms, including IPv4 RSVP. However, the mechanisms to achieve tunnelselection for certain IPv6 traffic may be IPv6 specific. This is the case, for instance, when the operationalchoice is to have tunnels dedicated on a pernetwork layer basis. Those mechanisms are detailed in theRSVP-TE section.
The next sections cover DiffServ and MPLS-TE in the 6PE/6VPE context and provide configuration examplesfor both.
Part I: Implementing IPv6 Services 193
Part I: Implementing IPv6 Services 193
Using DiffServ in a 6PE or 6VPE Environment
MPLS DiffServ can extend the IP DiffServ mechanisms to allow service providers to deliver QoS-basedservice without interfering with the customer's traffic marking. In the MPLS network, QoS information iscarried in the MPLS shim header as described in RFC 3270 and shown in the Table 5-3.
Table 5-3. MPLS Shim Header
[View Full Width]The MPLS header is 4 bytes, out of which 3 bits are used for DiffServ and referred to as the Exp field. Thesebits help define the QoS treatment (PHB) that a node should give to a packet. You can think of this as a sort ofhierarchical PHB, where the Exp field is used for QoS treatment inside the MPLS core, and at the egressboundary, whereas DSCP is used outside the core, and at the ingress boundary.
Using DiffServ on the MPLS ingress boundary for differentiating IPv6 traffic is almost exactly the same asusing it outside an MPLS environment. Packets need to be classified, which may take place prior to reachingthe MPLS edge router or at the MPLS edge router itself. In both cases, the MPLS Exp field must be filled,either by simply copying it from the DSCP field or by applying any sort of classification rule. Because theExp field is only 3 bits (compared to 6 bits for DSCP), you can just copy the class-selector bits into the Expfield, or decide to "map" the DSCP into the Exp field based on a predefined scheme. The former is the defaultbehavior and good enough in environments where the CEs are managed by the service provider or simplytrusted to deliver DSCP classes directly valid in the core network. The latter is used when the CE is untrustedand can also provide some flexibility to distinguish core classes based on dropping precedence. However, itrequires additional packet classification and conditioning at the PE (6PE or 6VPE). This is sometimes referredto as the pipe model. In some cases, the Exp bits can even be used exclusively to encode the droppingprecedence.
Note
Note that 3 bits allow up to 8 classes in the core, which so far has been plentiful in known core QoSdeployments.
Configuration Example
The following example shows how you can implement DiffServ in a 6PE or 6VPE network. Let's assume thatthe CE is unmanaged and does not always set the proper values for the DSCP field. Therefore, the SP wants toclassify and mark explicitly the MPLS Exp field for traffic coming from this CE.
The first step is to classify incoming traffic from the CE. This is done using the following ALCs that identifythe following:
RTP traffic under the UDP ports 16383 or 16384•
194 Part I: Implementing IPv6 Services
194 Part I: Implementing IPv6 Services
Traffic to 2001:300::/64 or with flow label set to 1111•
BGP traffic•
Example 5-6 shows the configuration of the ACLs identifying these three traffic types.
Example 5-6. Access Lists Identifying Three Traffic Types
ipv6 access-list RTP permit udp any any eq 16383 permit udp any any eq 16384!ipv6 access-list BUSINESS permit ipv6 any 2001:300::/64 permit ipv6 any any flow-label 1111!ipv6 access-list RP sequence 20 permit tcp any eq bgp any
On the 6PE, the following four access classes are defined:
1. VoIP
2. Business Data
3. ManagementTraffic
4. Internet
The Internet class uses the default class, which is always present on Cisco routers. The traffic for classes 1 to3 is classified based on the DSCP values and access lists above, using the class maps shown in Example 5-7.
Example 5-7. Configuration of the Four Access Classes Defined for the 6PE QoS Example
class-map match-any voip match dscp cs5 match access-group name RTP!class-map match-any business match access-group name BUSINESS match dscp af31 match dscp af32 match dscp af33!class-map match-any management match dscp 6 match access-group name RP
In the MPLS core network, another four classes (could be fewer) are defined, and specific Exp fields areassociated to each:
Part I: Implementing IPv6 Services 195
Part I: Implementing IPv6 Services 195
1. Real-Time (RT) for Voice and Video (EXP=5)
2. Business Class data (BU) for golden customers or golden applications (EXP=3)
3. Control Traffic (CTRL) for BGP and SNMP (EXP=6)
4. Internet data (STD) for anything else (EXP=0)
Note that the MPLS core classes apply to both IPv4 and IPv6 traffic, and in most cases preexist to theenabling of 6PE or 6VPE. A policy map is configured referring the set of classes defined on the access, andsetting the Exp field in labels imposed at the 6PE/6VPE as shown in Example 5-8.
Example 5-8. Policy Identifying the Exp Bits to be Assigned to Tagged IPv6 Packets Belonging to the Four AccessQoS Classes
policy-map CE1 class voip set mpls experimental imposition 5 class management set mpls experimental imposition 6 class business set mpls experimental imposition 3 class class-default set mpls experimental imposition 0
The policy map is then applied inbound to the 6PE interface facing the CE:
bandwidth 10 police cir 10000 exceed-action drop!class BUS bandwidth 154 police cir 154000 conform-action transmit exceed-action drop
The policy is applied outbound on the core-facing interface, as shown in Example 5-10.
Example 5-10. Applying QoS Policies on the Core-Facing Interface of the 6PE Router
interface Serial2/0 ip address 40.1.1.2 255.255.255.0 ip router isisservice-policy output TO-CORE
tag-switching ip
At the egress 6PE or 6VPE, the DSCP field can be overwritten based on specific policies, including the valueof the Exp field, or simply left to the value they had at the ingress PE, before entering the MPLS network.
Note that in the preceding example, the PE is explicitly setting the Exp field. In fact, in most cases, the SP willjust carry the DSCP field, with the advantage that no classification needs to take place at the PE. So theingress input policies and corresponding policy map (CE1) are not necessary.
Using RSVP-TE in a 6PE or 6VPE Environment
IP routing protocols are not good at optimizing network utilization and performance. Although they canrecover from network failures, they typically select the shortest path to a destination, ignoring other paths.Amazingly, loop-avoidance mechanisms rely significantly on the assumption that all nodes within a routingarea have a consistent view of the topology, hence will be using the same path to the destination. Shortest-pathrouting often leads to unbalanced traffic distribution across the network, creating congestion hot spots in someareas, while some links are underutilized.
One well-known issue related to the topic is the so-called fish problem, named after the shape of the typicaltopology that illustrates it. In Figure 5-4, traffic flowing from 6PE2 to 6PE1 and beyond will tend to use onlyone path (for instance, via P1).
Figure 5-4. Using RSVP-TE with 6PE
[View full size image]
Part I: Implementing IPv6 Services 197
Part I: Implementing IPv6 Services 197
Load balancing may sometimes help improve the traffic distribution, but is certainly not the panacea,particularly when unequal cost paths are available. In the most common case, label binding is based onrouting information, and MPLS performs destination-based forwarding. However, by enablingsource-routing-like mechanisms via the label switch path (LSP), MPLS offers good opportunities to resolvethe issue of bandwidth optimization. When more flexible (or rather more controlled) forwarding policies arerequired, RSVP-TE provides alternative for label binding, other than exclusively based on routinginformation. With RSVP-TE, you can define forwarding policies at a granularity of a flow or group of flows.This technology is referred to as MPLS traffic engineering. One or many tunnels are set up between edgerouters (PEs) or between core routers (Ps), explicitly or automatically, based on available and requiredbandwidth. The traffic between tunnels' endpoints can then select a particular tunnel based on a variety ofcriteria. Those criteria encompass different strategies:
Applications driven (for instance, by looking at UDP or TCP port numbers)• Customers driven (for instance, by looking at source/destination, or at the incoming interface [atPE-CE boundary])
•
Network layer driven (for instance, IPv4 or IPv6)• QoS driven (using the DSCP or Exp fields, respectively, in the IP [IPv4 or IPv6] or in the MPLSheaders)
•
One common MPLS-based approach for traffic engineering is the overlay model. Service providers build avirtual network that includes a full mesh of logically connected PEs.
These logical connections can be MPLS explicit routes enforced via bandwidth reservation. The MPLS LSPsexplicitly set up using RSVP-TE can be used to replace the LSP routes provided by the combination of aninterior gateway protocol (IGP) and LDP to enable more efficient resource utilization.
Both Chapter 3, "Delivering IPv6 Unicast Services" and Chapter 7, "VPN IPv6 Architecture and Services,"review in detail the way IPv6 traffic can use IPv4-signaled LSPs. A direct consequence is that whichevermechanism is available at the IPv4 LSP level can be beneficial to 6PE and 6VPE. As far as MPLS-TE isconcerned, RSVP-TE can be used in the IPv4-based MPLS core to optimize the bandwidth and forfast-reroute purposes. The tunnels are set up exactly as they would be for providing the service to IPv4 traffic.In fact, it is recommended that the tunnels be set up for both IPv4 and IPv6 at the same time because thecriteria to select these tunnels have less to do with the network layer than with applications, type of traffic, orspecific customer.
There are (at least) two methods for selecting the RSVP-TE tunnels for IPv6 (6PE or 6VPE) traffic:
198 Part I: Implementing IPv6 Services
198 Part I: Implementing IPv6 Services
The egress 6PE (or 6VPE) could advertise several different BGP next hops for different sets ofreachable destinations. These next hops (IPv4-mapped IPv6 addresses) can then be used as the tailend of RSVP tunnels by the ingress 6PE.
•
The ingress 6PE could set up multiple TE tunnels to the egress 6PE and select one or the other basedon MPLS QoS after label imposition.
•
Examples of each are provided in the next sections.
Using Multiple BGP Next Hops
The egress 6PE can explicitly set up the next hop announced in BGP updates, based, for instance, on prefixesbeing advertised. The following configuration provides an example of this technique.
A route map is defined that sets different next hops for different match criteria as shown in Example 5-11.
Example 5-11. Route Maps and Corresponding Access Lists Identifying the TE Tunnel-Selection Criteria
PE1#ipv6 prefix-list list-te1 seq 5 permit 2001:100::/64!ipv6 prefix-list list-te2 seq 5 permit 2001:200::/64route-map NH-TE-SELECT permit 10 match ipv6 address prefix-list list-te1 set ipv6 next-hop ::FFFF:200.8.8.1!route-map NH-TE-SELECT permit 20 match ipv6 address prefix-list list-te2 set ipv6 next-hop ::FFFF:200.9.9.1
The route map is applied on prefixes announced by the 6PE, as shown in Example 5-12.
Example 5-12. Applying the Route-Maps Defined in Example 5-11 to the Prefixes Advertised by the 6PE Router
In this example, the tunnel paths are explicitly configured as shown in Example 5-14.
Example 5-14. Explicit Configuration of the Tunnel Paths
ip explicit-path name te1 enable next-address 30.1.1.3 next-address 40.1.1.2!ip explicit-path name te2 enable next-address 31.1.1.3 next-address 41.1.1.2
And static routes are configured to select the tunnel based on the next hop received from the egress PE (PE1):
ip route 200.8.8.1 255.255.255.255 Tunnel1ip route 200.9.9.1 255.255.255.255 Tunnel2
At the ingress PE2, you can display the detailed LSP used by the forwarding plane (CEF) for destination2001:100::/64 and 2001:200::/64. The output of the show ipv6 cef command provides the followinginformation:
Example 5-15. IPv6 CEF Information for Prefix 2001:100::/64
PE2#show ipv6 cef 2001:100::/64 internal recursive via 200.8.8.1[IPv4:Default] label 17, fib 024AC3E8, 1 terminal fib attached to Tunnel1, adjacency IP midchain out of Tunnel1 027F4918 output chain: label 17 TAG midchain out of Tunnel1 027F47A8 label 16 TAG adj out of Ethernet0/0, addr 30.1.1.3 027F4D68PE2#show ipv6 cef 2001:200::/64 internal recursive via 200.9.9.1[IPv4:Default] label 16, fib 024AC360, 1 terminal fib attached to Tunnel2, adjacency IP midchain out of Tunnel2 027F44C8 output chain: label 16 TAG midchain out of Tunnel2 027F4358 label 16 TAG adj outof Ethernet2/0, addr 31.1.1.3 027F4A88
Note that the two paths are distinct from the start, one via interface Ethernet0/0 and the other via interfaceEthernet2/0.
200 Part I: Implementing IPv6 Services
200 Part I: Implementing IPv6 Services
COS-Based TE Tunnel Selection (CBTS)
The idea of CBTS is to allow different parallel tunnels between the same head end and the same tail end toeach carry a different subset of the class of service (CoS).
At ingress PE, the CBTS configuration involves the following:
Create multiple TE tunnels with the same head end and same tail end. Existing TE attributes areconfigured completely independently for each tunnel (bandwidth, bandwidth pools, preemptionpriorities, path options, and so on).
•
Indicate on each of these tunnels which DiffServ code points are to be transported.• Make these tunnels visible to routing. This can be achieved using Autoroute (every prefix via the tailend of the tunnel is routed via the tunnel) or using static routes pointing to the tunnels.
•
At the ingress PE, one tunnel is then selected over the other based on the Exp field value found in the topmostlabel of each packet. As previously discussed, packets arriving unlabeled (IPv6 packets) at ingress 6PE can beclassified and marked with a particular Exp value while the label stack is being imposed, so that CBTS at thesame node can then use this value to further select the tunnel matching the corresponding code points.
In the following example, tunnels (tunnel1 and tunnel2) are configured the same way as in Example 5-13, andagain, CEF has parallel paths to get to a particular destination prefix, via tunnel1 or tunnel2. But in CBTScase, each tunnel gets the additional command highlighted in Example 5-16.
Example 5-16. Tunnel Configuration Example in the CBTS Scenario
Then, as in the DiffServ example, traffic is classified and the Exp field is set, so that some of this traffic is putinto tunnel1 and some into tunnel2 (see Example 5-17).
Example 5-17. Configuration of Policies Setting the Exp Bits Used for Tunnel Selection in the CBTS Scenario
policy-map CE1 class tunnel1 set mpls experimental imposition 3 class tunnel2 set mpls experimental imposition 5!
Part I: Implementing IPv6 Services 201
Part I: Implementing IPv6 Services 201
interface Serial0/0 ip address 50.1.1.2 255.255.255.0service-policy input CE1ipv6 address 2001:10::72B/64
In this example, classification (class map for class tunnel1 and tunnel2) is not shown, but would be similar tothe examples detailed in DiffServ sections. The CE1 policy is applied inbound on the CE-facing interface.
Note
At the time of this writing, CBTS, when used in conjunction with 6PE or 6VPE, is not yet available on Ciscorouters. The feature will become available in the near future.
Deploying QoS for IPv6
QoS is always enabled in an environment that already provides unicast connectivity. The tools and featuresused to enable this service depend on the characteristics of this infrastructure. IPv6 most likely is thenewcomer in a preexistent IPv4 network. Chapter 3 discussed the IPv6 unicast deployment options and howthe QoS design has to be tailored to them. This section looks at design recommendations for native andMPLS-based IPv6 deployments. Inevitably, the coexistence of the two protocols has to be addressed, too.
QoS in a Native IPv6 Deployment
The similarity between the implementations of QoS for the two versions of the IP protocol implies that theIPv4 QoS deployment rules are applicable to IPv6, too. You can find a detailed analysis of these design rulesin the book End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs, by Tim Szigetiand Christina Hattingh. The basic steps to follow in planning for and designing a QoS deployment are asfollows:
1. The most important first step that must be taken before designing or even considering the deployment ofQoS is that of defining its business objectives network. A DiffServ option is discussed here for the QoSdeployment.
Note
IntServ might be considered for applications such as videoconferencing that benefit from reservingresources prior to sending the traffic. The IntServ implementation most likely would be an overlay on topof DiffServ used for most traffic types.
2. A thorough evaluation of the network capacity is required. The identified constraints imposed by theexistent infrastructure provide the framework for prioritizing the business objectives and the resources tobe allocated to them.
3. The outcome of the first two steps is the set of classes that are used throughout the network todifferentiate the traffic types. Three to five classes typically suffice for most deployments; too many
202 Part I: Implementing IPv6 Services
202 Part I: Implementing IPv6 Services
classes make the service difficult to manage.
4. Classify the traffic as close as possible to the source and mark it using DSCP.
5. Define the PHBs for the various devices in the network. The devices that can perform the QoS functionsin hardware should be more heavily used in the design. Policing should be performed as close to thesource as possible.
Note
QoS classification and marking can and should be done prior to it being encrypted and forwarded throughtunnels.
6. Test and verify the QoS design before deployment.
The network layers usually support the end-to-end QoS in different ways:
Access This layer provides the best opportunity to enforce customer traffic profiles through policingand rate limiting. This layer is also the closest to the sources of traffic and it represents the best placeto classify and mark packets. The access layer might use more classes than other layers of the networkto sort more finely customer traffic. The QoS function can be done in both layer 2 and layer 3 devices.
•
Edge/aggregation The traffic that reaches the edge/aggregation layer is typically marked andconditioned by the access layer. At this point, the traffic might be policed again, but it will be shapedbefore entering the core. The number of classes is reduced to the recommended three to five, andhence the packets might be remarked.
•
Core In the past, a common approach was to rely on a high-bandwidth core that would be engineeredso that it would not see congestion (thus rendering the use of QoS unnecessary). Even today, someargue that in SP environments that it is cheaper to oversize the core network than to design it withQoS. When network bandwidth starts to be scarce, it is more convenient to increase link capacity thanto deploy any sort of mechanism that brings complexity and maintenance overhead. Making the coreaware of application, protocols layers (for instance, IPv4 and IPv6), customers, and so on may not beconsidered as a scalable thus viable solution. In such environments, only edge policies will beconfigured. However, this general philosophy may turn to be expensive for a number of reasons,including the following:
- The network must accommodate peaks, sometimes an order of magnitude more than theaverage traffic. Turning on QoS in the network to differentiate traffic may prove to be moreeconomic than oversizing the network.- The network must be able to react well to link failures, where traffic is rerouted on alternatepaths. When the failure occurs on a large trunk, and/or when the failure affects several trunks,some congestion can build on smaller links, which were not sized for absorbing the reroutedtraffic.- Denial-of-service attacks can always saturate links. QoS allows some time-sensitive trafficsuch as voice to work perfectly even at the peak of a denial-of-service incident.- The implementation of QoS in the core is probably the simplest. The traffic is alreadyconditioned by the edge/aggregation and only a few (equal to the number used in theedge/aggregation layer) classes are used.
•
Similar to IPv4, congestion control and management are implemented depending on the characteristics of thetraffic identified through the various classes.
Layer 2 QoS should be leveraged as much as possible throughout the network because switches oftenimplement it in hardware. Usually a mapping of the top three DSCP bits or the TOS bits to COS is sufficientin terms of marking. However, the option is available to have independent marking policies.
Part I: Implementing IPv6 Services 203
Part I: Implementing IPv6 Services 203
QoS in an MPLS-Based IPv6 Deployment
The SLA and its associated network-deployed enforcing mechanism (QoS) are end-to-end concepts.Therefore, it is logical that it is implemented primarily by service providers, who are the ones with theend-to-end perspective. Because MPLS is one of the dominant technologies deployed in SP networks, it isalso one of the primary areas for QoS implementation.
Similar to native IP QoS, MPLS QoS technologies can be split into IntServ and DiffServ. The latter is themost widely deployed mechanism, but one starts to see some deployments with MPLS traffic-engineeredtunnels, to provide guaranteed bandwidth across the MPLS core. MPLS-TE uses RSVP-TE to set up a labeledpath across the MPLS domain. MPLS DiffServ and MPLS-TE can be combined together into an even morepowerful tool for delivering QoS on packet networks. Most of the MPLS QoS deployments focus on thenetwork edge, although some service providers are starting to deploy QoS in the MPLS core, too.
Both 6PE (IPv6 MPLS over v4-signalled Label Switch Path, described in Chapter 3) and 6 VPE (BGP MPLSIPv6 VPN over v4-signalled LSP, described in Chapter 7) involve dual-stack edge routers communicatingover a v4-based MPLS backbone. To enable QoS for 6PE and 6VPE, IPv6 traffic must be classified andconditioned (policed, shaped, and marked) pretty much the same way as IPv4, before entering the MPLSbackbone. This typically must take place at the customer edge (CE) routers in the case of a managed serviceor at the provider edge (PE) router otherwise. This implies identifying IPv6 classes, then performing policing,shaping, and marking. In Figure 5-5, those tasks are referred to as edge policies. In practice, either the CEoutbound policy or the PE inbound policy is set up: CE inbound policy is never used. In addition, in case QoSis also implemented in the MPLS core, a PE outbound policy is configured together with outbound policies ateach hop (P-routers) in the MPLS provider core. This is the PHB, which, in this case, is essentially queuingand dropping.
Figure 5-5. Deploying IPv6 QoS over MPLS
[View full size image]
MPLS is the foundation of a multiservice network, which is intended to transport a large variety of networklayer protocols (IPv4 unicast and multicast, IPv6 unicast and multicast, IPv4 VPN, IPv6 VPN, as well asATM, FR, PPP, Ethernet, and so on) and a variety of application data (Internet content, VoIP, video, and soon). When deploying QoS in the MPLS core, one does not expect to make it aware of the network layerprotocol or of the application being carried. In other words, it is unlikely and even not recommended todifferentiate IPv6 traffic from IPv4, but rather to treat equally IPv4 and IPv6 real-time traffic, and differentiatethem from IPv4 and IPv6 data traffic, for instance.
204 Part I: Implementing IPv6 Services
204 Part I: Implementing IPv6 Services
In that context, enforced by the 6PE (and 6VPE) approach where the same LSP used to transport IPv4 andVPNv4 traffic is also used to transport IPv6 traffic, the setting of core QoS for the latter is straightforward. Itis just a matter of classifying the 6PE/IPv6 traffic into existing MPLS classes, and markingMPLS-encapsulated IPv6 traffic accordingly.
Note
There is no difference regarding DiffServ in an MPLS-based IPv6 deployment, whether the LSP was set upusing IPv4 (6PE and 6VPE) or IPv6 or whether it was setup using LDP, RSVP, or even BGP.
Instead of, or in addition to DiffServ, there may be some interest in deploying an IntServ strategy across thecore (for instance, to reserve some paths for specific customers, or to optimize a better use of the networkbandwidth). This can be done using MPLS-TE.
MPLS, combined with RSVP, provides a mechanism to set up explicit paths across the core, and to associatethem with bandwidth reservation or even DiffServ strategies. Despite the management complexity, someservice providers with an MPLS infrastructure have meshed their core with TE tunnels and manually set uppaths with reserved bandwidth. In that context, DiffServ can also be used to manage congestion conditionsinside the TE tunnels themselves.
When using MPLS-TE in networks where IPv4 and IPv6 traffic coexist, two approaches are possible: EitherTE tunnels are shared for IPv4 and IPv6 traffic (recommended) or separate tunnels are signaled and used forthe two protocol versions. TE tunnels can be combined with DiffServ, where the selection of tunnels isperformed based on DSCP bits. This is referred to as CBTS. DiffServ-aware traffic engineering enablesservice providers to perform separate admission control and separate route computation for discrete subsets oftraffic (for example, voice and data traffic, regardless of the network layer protocol).
Note
When IPv6-RSVP is available, it might still make sense to use a single MPLS-TE setup mechanism (IPv4 orIPv6) to set up a single tunnel used by both IPv4 and IPv6 for certain traffic classes.
IPv4 and IPv6 Coexistence
One question arises with the coexistence of IPv4 and IPv6: Should IPv6 traffic be differentiated from IPv4traffic, or rather should traffic of a given class (for instance, real time) be differentiated from traffic of otherclasses (for instance, data) regardless of IP protocol type? Not only are both approaches possible, but differentstrategies can also apply to different parts of the network.
The PHBs for the two protocols might be different under the following considerations:
IPv4 traffic is revenue generating, and it most likely is more important for the business than the IPv6traffic, at least in the beginning. In that case one might choose to prioritize the IPv6 traffic lower thanIPv4 and provide fewer resources for it.
•
IPv4 and IPv6 traffic might have to observe different PHBs depending on traffic patterns used byvarious applications.
•
Part I: Implementing IPv6 Services 205
Part I: Implementing IPv6 Services 205
In these cases, you should define different classes and policies for each traffic type.
Note
With transition mechanisms, the IPv6 traffic can leverage the deployed QoS of the traversed IPv4infrastructure. In some circumstances, the IPv6 traffic might also lose its markings after crossing the IPv4network.
Differentiating based on applications rather than network layer protocol makes the most sense: After all, endusers running a particular application (for instance, IP telephony) do not care about the network layer beingused and expect the same level of network quality in all cases. This approach also reduces the managementoverhead for the QoS deployment and the use of network element resources.
It is recommended that no differentiation should be made between the two protocol types in implementingQoS at layer 2. Similar to the recommendation made for MPLS, the infrastructure should be kept unaware ofthe transported protocol type. Moreover, different PHBs for IPv4 and IPv6 would lead to an unmanageablenumber of policies.
The aim of IPv6 to reestablish a peer-to-peer model for IP transport will most definitely impact in a positiveway the deployment of QoS. The boundary between private and public domains will no longer even out thecharacteristics of individual streams coming from different internal sources. In an IPv6 world, true end-to-endQoS policy implementations are closer to reality. Despite lacking a consolidated architecture at this time, thefeatures available for IPv6 do provide the means to deploy QoS at least at the level of current IPv4deployments.
Chapter 6. Providing IPv6 MulticastServices
A wide range of applications used over all types of networks rely ondelivering the same data from one source to multiple destinations.Examples of such applications are listed here, grouped together basedon the network environments in which they are typically used:
On enterprise networks Distribution of financial informationsuch as stock quotes, distribution of news, videoconferencing,distance learning, delivery of content such as software updates
•
On service provider networks Content delivery such as videoand audio streaming, collaborative applications such asconferencing for enterprise customers, multiplayer gaming andchat for residential customers
•
Source replication of unicast streams for all destinations clearly is not ascalable approach from the source or network resources perspective.The proper solution to support such applications is to enable a networkthat can replicate the traffic as physically close as possible to thedestinations, a multicast-enabled network. The growing number ofmulticast-based applications, and their increased importance to
206 Part I: Implementing IPv6 Services
206 Part I: Implementing IPv6 Services
businesses and users, drives the demand for multicast services.
IPv4 multicast has evolved over a number of years. Multiple featuresand protocols were developed for it, and many of them were shelvedbased on the experience gained through deploying and operating theservice. With the benefit of hindsight, IPv6 multicast builds on thisexperience. Features or protocols that were not deemed useful to IPv4multicast were completely ignored in IPv6, as shown in Table 6-1. Onthe other hand, IPv6 leverages its address size and structure throughnew, specific features. The implementation is also cleaner or simpler attimes because multicast was part of the IPv6 development from day oneand avoided some constraints introduced by unicast features orconcepts. In Table 6-1, IPv4 multicast features that are explicitly notconsidered in IPv6 are marked NC.
Table 6-1. Taxonomy of Multicast Protocols and Their Availability in IPv6Protocol Function Multicast Protocol IPv4IPv6Group membership management Internet Group
Management Protocol(IGMP) v1, v2, v3
X
Multicast ListenerDiscovery (MLD) v1, v2
X
Multicast support at layer 2 Snooping (IGMP or MLD) X XCisco Group ManagementProtocol (CGMP)
Rendezvous point management Static-RP X XAuto-RP XBootstrap router (BSR) X XEmbedded RP XMulticast Source DiscoveryProtocol
X NC
Part I: Implementing IPv6 Services 207
Part I: Implementing IPv6 Services 207
Table 6-1 is not meant to be complete from a historical perspective. It intends only to summarize the mostrelevant multicast protocols of both IPv4 and IPv6. The IPv6-specific ones are discussed in the remainder ofthis chapter. It is assumed that the reader is familiar with the IPv4 multicast concepts. Some of these conceptsare briefly described here, but for a complete and detailed presentation, refer to the Cisco Press bookDeveloping IP Multicast Networks, Volume 1.
This chapter covers the following topics:
A review of IP multicast concepts and their implementation in IPv6• IPv6 multicast deployment considerations• Examples of configuring IPv6 multicast•
By the end of the chapter, you will most likely conclude that, for the most part, IPv6 multicast is notdramatically different from its predecessor, but it enables cleaner service deployments.
IPv6 Multicast
An important aspect of the multicast service is addressing. Whereas a unicastaddress identifies a node, a multicast address identifies a group of nodesinterested in the same data. There are no constraints on the location of agroup's members. A packet with a multicast destination address (DA) isdelivered to all members of the group identified by that address.
IPv6 multicast, like unicast, benefits from the new addressing architecturedefined in IPv6 for the following reasons:
Larger addressing space implies the availability of plenty of addressesfor multicast groups (unicast-based multicast address described inChapter 2, "An IPv6 Refresher," is a good example). IPv6 addressinglifts major deployment constraints that plagued IPv4; it facilitates andsimplifies multicast service deployments.
Note
IANA assigned the IPv4 Class D addresses, from 224.0.0.0 to239.255.255.255, to designate IPv4 multicast groups. For moreinformation, visit the IANA website at http://www.iana.org.
•
Address scoping offers a cleaner way to contain the multicast trafficwithin the intended domain.
Note
In IPv4 only, the fixed multicast scoping (see Chapter 2) is defined.
Chapter 2 presents the IPv6 multicast addressing architecture for both layer 2and layer 3 of the OSI model. This chapter builds on that knowledge to providea review of key concepts such as multicast group, multicast domain, multicasttrees, and service-supporting protocols.
Group Membership Management
Multicast addresses define "forums" for applications to deliver their content to.These forums (called groups) have a dynamic audience that users can join orleave. On a link, the group is managed through several protocols at both layer 2and at layer 3 of the OSI model.
Multicast Listener Discovery
The Internet Group Management Protocol (IGMP) is used in IPv4 to enablehosts on a link to join a multicast group, leave it, or simply communicate to arouter their group membership. In short, it manages the multicast-relatedinteraction between listeners and routers. IGMP went through severaldevelopmental iterations: IGMPv1, IGMPv2, and IGMPv3. The later versionsare backward compatible, but each adds features that enhance the operation ofits predecessor.
Protocol Description
The Multicast Listener Discovery (MLD) protocol is performing IGMP'sfunction in IPv6. There are two versions of the protocol, MLDv1 and MLDv2.They map identically the last two versions of IGMP, as shown in Table 6-2.Similar to IGMP, MLD is built on top of ICMP.
Table 6-2. MLD Message Types
MLD IGMP
MLDMessageTypes
ICMPv6Type
IGMPv1(RFC1112)
MLDv1 (RFC 2710) IGMPv2(RFC2236)
Multicastlistenerquery
130
Multicastlistenerreport
131
Multicastlistenerdone
132
MLDv2 (MLDv2) IGMPv3(RFC3376)
Multicastlistenerquery
130
Multicastlistenerreport
143
Part I: Implementing IPv6 Services 209
Part I: Implementing IPv6 Services 209
For each of its links, a router has to keep track of all multicast groups that have listeners. It needs to maintainthis state to decide whether it should accept traffic for a multicast group and whether it should forward thattraffic out its interfaces.
On the other hand, by default, routers do not have to track every listener on an interface. They just have toknow whether there is at least one active listener. To perform this function, on each link a single router iselected to query for listeners. In this sense, on a link a router can be in a querier (sending periodic generalqueries) or a nonquerier state. All routers start as queriers, but only the one using the lowest source address(SA) (link-local address is used as the SA) on its queries for a given link remains active. The querier sendsgeneral queries ("Any listener out there?") or specific queries ("Any listeners for group G?"). When a router isinformed of a listener's departure, the latter query type represents an optimal way to verify whether any otherlisteners remain in the group that was just left.
Note
If a router queries a specific group, the packet is sent to the multicast address of that group. The response tothe query is sent with the same DA, and the router ignores it if the router has not subscribed to that group, too.For this, reason a hop-by-hop extension header with a Router Alert option (see the "Hop-by-Hop OptionsHeader" section in Chapter 2) is used with the MLD ICMPv6 packets. It forces routers to examine messagesdestined to multicast groups that the router is not subscribed to.
Nodes respond to queries with report messages that indicate the groups and sources their interfaces arelistening to. Report (MLDv2) or Done (MLDv1) messages are also sent by nodes to indicate a change in thelistening state of one of their interfaces.
The MLDv1 messages are used to perform the following functions:
Multicast listener query Used to identify whether a given group has listeners on a link. There are twotypes of query. The general query sent to the link-local, all-nodes multicast address (FF02::1), andwith the MLD Multicast Address field set to :: is used to learn which multicast group has listeners.The multicast address-specific query is used to identify the listeners for a given group that is listed inthe MLD Multicast Address field of the message and is sent to the queried multicast address.
•
Multicast listener report The message used in response to a query. The IPv6 DA for a report is themulticast address being reported.
•
Multicast listener done Sent by a node to indicate that it stopped listening to a multicast address. TheIPv6 DA for the done message is the link-local, all-routers multicast address (FF02::2).
•
Note
All MLD packets are sent with a link-local address as the IPv6 SA. The hop limit is set to 1. This is done tomake sure the packet is not routed outside of the link.
MLDv2 enhances MLDv1 by enabling a node to express or report interest in a particular source for amulticast group. This capability optimizes the multicast operation through a more discrete control of groupmembership. It also provides the support for the Source Specific Multicast (SSM) deployment model that isdiscussed later in this chapter.
210 Part I: Implementing IPv6 Services
210 Part I: Implementing IPv6 Services
The MLDv2 query message performs the same functions as its MLDv1 counterpart. In addition, it supportsmulticast-source specific queries. The capabilities of the report message were also enhanced for MLDv2. Itconcatenates a set of records, each record containing information that relates to a given multicast address. Thisstructure offers enough flexibility to the MLDv2 report message to perform the function of the MLDv1 donemessage, too. MLDv2 does not use done messages.
Note
MLDv2 is backward compatible with MLDv1, and for this reason it must support the MLDv1 messages,including the 131 and 132 types (see Table 6-2).
Figure 6-1 summarizes some aspects of the MLDv2-governed listener-router interaction on a link.
Figure 6-1. Conceptual Representation of Listener-Router Interaction on a Link
[View full size image]
On Cisco routers, MLDv2 is enabled by default on all interfaces as soon as multicast routing is globallyenabled on the router (using the global configuration command ipv6 multicast-routing). Example 6-1 showsan example of the MLD operational status on an interface.
Example 6-1. MLD Operational Status on a Router Interface
Router#show ipv6 mld interface GE-WAN1/1.1GE-WAN1/1.1 is up, line protocol is up Internet address is ::/10 MLD is enabled on interface
Part I: Implementing IPv6 Services 211
Part I: Implementing IPv6 Services 211
Current MLD version is 2MLD query interval is 125 secondsMLD querier timeout is 255 secondsMLD max query response time is 10 seconds
Last member query response interval is 1 secondsMLD activity: 4 joins, 0 leavesMLD querying router is FE80::20D:29FF:FEE1:4DC0 (this system)
The MLD-specific parameters such as query interval, timeout, or max response time that are highlighted in theexample above can be configured under each interface. The output also lists the querier for the link; in thiscase, it is FE80::20D:29FF:FEE1:4DC0, the router in the example.
Source Specific Multicast Mapping for MLDv1
The SSM service model discussed later in this chapter requires a host to specify both the multicast group itintends to join and the specific source it intends to listen to. Only MLDv2 supports this functionality on thehosts. Although SSM is a popular deployment model, MLDv2 is not commonly implemented on IPv6 stacksat the time of this writing, so a solution is necessary to make SSM work with MLDv1. This solution is calledSSM mapping for MLDv1, and it operates in two modes:
Statically configured mapping A source (S) is statically mapped to a given group (G) on the router.The router maps any (*,G) MLDv1 report to an (S,G) based on the configured mapping. Thismapping feature is off by default on a router. It is enabled with the global command ipv6 mldssm-map enable. The static mapping is configured with the global command ipv6 mld ssm-map static<ACL> source <source>, where the access control list (ACL) identifies the groups mapped to a givensource.
•
Dynamically configured mapping An AAAA record (see Chapter 3, "Delivering IPv6 UnicastServices") is configured for G in a DNS server. When the router receives an MLDv1 report for (*,G),it does a reverse DNS lookup querying for G's record. The DNS server returns the corresponding Sfor G. After the SSM mapping has been enabled globally, as previously shown, you can configure thedynamic mapping option with the global command ipv6 mld ssm-map query dns. In this case, the IPaddress of the DNS server must be configured on the router, too (ip name-server <IP address>). TheDNS server can be reached over IPv6 or over IPv4 in a dual-stack network.
•
This feature, available on Cisco routers, enables IPv6 hosts supporting only MLDv1 to receive SSM-basedmulticast services.
Note
IPv4 faces the same problem of little support for the newer IGMPv3 protocol. While the host stacks aregetting updated to include IGMPv3, the same mapping solution is available to enable IGMPv1/v2-capablehosts to participate in SSM-based multicast service deployments. The feature is called SSM mapping forIGMPv1/v2.
MLD Access Control and Explicit Tracking
Two useful MLD features enable network administrators to block unauthorized user access to multicastresources and to monitor individual MLD client activity on an interface:
212 Part I: Implementing IPv6 Services
212 Part I: Implementing IPv6 Services
MLD access control Configured on a router interface, MLD access control filters inbound MLDreports for groups and sources based on a defined access list. The ACL SA matches the address of themulticast source and the ACL DA matches the group address. Example 6-2 shows the configurationof this feature.
Example 6-2. Denying User Access to (2001::1,FF3A::1) and Permitting All the Other Sources for (*,FF3A::1)
In Example 6-2, the ACL identifies reports for group FF3A::1 and source 2001::1 to be rejected;reports for all other sources of the group are to be accepted.
•
Explicit tracking (ET) Configured on a router interface (ipv6 mld explicit-tracking <access-list>), ETenables the router to explicitly track each multicast client on that interface. By default, the router isinterested in knowing only whether it has any listeners for a group on the interface, so it does notmonitor individual listeners. The tracking can be done for all multicast groups or for a subsetidentified via an access list. The matching rules described for MLD access control apply in this case,too. When ET is enabled on an interface, the router can use the fast-leave mechanism available forMLDv2. In other words, it does not have to query the link for other listeners after each report of alistener leaving a group. The router knows at all times how many listeners are subscribed to eachgroup, and this information can be viewed with the command show ipv6 mld traffic.
•
MLD access control and ET are currently available with Cisco IOS routers.
Another useful MLD feature is MLD authentication, authorization, and accounting (AAA). It complementsthe other two features by offering network operators the means to dynamically control user access and toperform billing for the services accessed. This feature will soon be available on Cisco routers.
Multicast Layer 2 Protocols
Protocols managing the multicast traffic at layer 2 can help improve layer 2 device operation. Severalprotocols that would make switches aware of multicast group membership were developed for IPv4, includingthe Cisco Group Management Protocol (CGMP). CGMP enables routers to provide connected switches withlistener information, and IGMP snooping enables the switches to learn a port's group membership bymonitoring its IGMP traffic. These mechanisms allow layer 2 switches to forward the multicast traffic only tothose ports within a VLAN that have listeners and thus avoid flooding it on every port.
Note
Other protocols have been developed for IPv4 to optimize the layer 2 forwarding of multicast traffic but havenot yet been considered for IPv6. Two of these are Router Group Management Protocol (RGMP; RFC 3488)and GARP (Generic Attribute Registration Protocol) Multicast Registration Protocol.
Although you can implement CGMP and snooping for IPv6 (as you can with IPv4), you must consider someIPv6 specificities. Multicast is extensively used in IPv6 to perform basic functionality such as neighbor
Part I: Implementing IPv6 Services 213
Part I: Implementing IPv6 Services 213
discovery. Each node has to subscribe to multiple groups that are dedicated to proper link operation. A node'sbasic operation can be severely impacted if it is not generating enough MLD traffic that would allow asnooping switch to be aware of all the groups the node listens to.
On layer 2 Cisco devices, MLD snooping is available today and is enabled by default. You can enable thefeature with the command ipv6 mld snooping (if disabled); the feature has tuning parameters such as ratelimiting and number of layer 2 entries that can be installed by MLD snooping. There are no plans toimplement CGMP for IPv6 at the time of this writing.
Multicast Routing and Forwarding
MLD enables routers to learn and manage listeners directly connected to them. The next step in building amulticast-aware network is to enable the routers to inform each other of their listeners' interest in a multicastgroup. These routers can then collectively build the optimal path for the multicast traffic from the sources tothe listeners.
Multicast Distribution Trees
A fundamental concept of multicast routing and forwarding is that of a multicast distribution tree (MDT). Itsbranches lead to routers that service networks hosting listeners. As listeners join or leave, branches are addedto or pruned from the tree. Why a tree? Because with all the replication of traffic, the last thing one wants tohave in the network is looped multicast traffic.
The question that follows the decision to use distribution trees is this: Where should the root of the MDT belocated? Generally speaking, the optimal path for the multicast traffic is that of a tree that has the root at thesource of the traffic. This is called a shortest path tree (SPT), and it is identified by the (S,G) tuple, where S isthe address of the source and G is the address of the multicast group. All the routers that are part of an (S,G)tree have to maintain state for it. In fact, routers have to maintain state for each source-group pair used in thenetwork. This can become a burden when a large number of (S,G)s are present.
When multiple sources serve the same G, it might be worthwhile to share a common distribution tree. Ashared tree is identified as (*,G). The shared tree (ST) is rooted in an administratively selected router calledrendezvous point (RP). One RP is active for each group, but the same RP can handle multiple groups. Sourcesregister with the RP and their traffic is forwarded over an (S,G) to the RP and from there down the sharedtree. This traffic enables edge routers to learn about the existence of these sources.
The shared tree is a common information resource for the multicast domain, but it cannot be the optimal pathfor all multicast sources. If an edge router has listeners for a given group, once it learns about a source, it canchoose to switch to an SPT that offers optimal forwarding of the multicast traffic. Figure 6-2 shows a sharedtree and an SPT over the same topology.
Figure 6-2. Multicast Distribution Tree Types
[View full size image]
214 Part I: Implementing IPv6 Services
214 Part I: Implementing IPv6 Services
Note
The two tree types have advantages and disadvantages. With SPT, routers require more memory to maintainthe state of multiple trees. On the other hand, the SPT will always offer the optimal path between the sourceand destination, whereas that might not always be the case when using an ST. Nonoptimal paths can lead topacket delays and delay variations. The SPT also offers more protection against denial-of-service (DoS)attacks. An RP could be an easy target.
Reverse-Path Forwarding Determination
Regardless of tree type, the control messages used to build and manage it are always sent toward the root.Whether it is the multicast source or the RP, routers need to find the next hop on the reverse path (with respectto the flow of multicast traffic) toward them. The process of identifying this upstream neighbor is calledreverse-path forwarding (RPF) calculation.
To decide the outbound interface for these messages, a router has to be aware of the network topology.Because multicast routing builds and maintains state only for MDT, a router relies on the underlying unicastrouting protocols for network topology information. Based on this information, it executes an RPF calculationand it identifies the best upstream interface toward the RP or the source.
The following information is examined in the RPF calculation process:
Static multicast routes• MBGP (Multiprotocol BGP) multicast routes• IPv6 unicast routing information stored in the Routing Information Base (RIB) and provided by staticroutes, RIPng, EIGRP, OSPFv3, and IS-IS but excluding BGP unicast routes
•
Note
Part I: Implementing IPv6 Services 215
Part I: Implementing IPv6 Services 215
By default, a static route is installed in the unicast RIB, and it is used for multicast RPF calculation, too.Enhancements made to the configuration syntax allow for static routes to be configured for unicast only or forthe multicast RPF calculation only.
First, the longest-match is searched across the three databases. If two or more equivalent routes are foundacross the tables, the tiebreaker used is the administrative distance. If the tie remains, the route found in thefirst of the tables listed above will be selected.
Note
A less-optimal distance-only criteria is currently used in IPv4 multicast RPF calculation. A route with ashorter prefix length can be preferred because its administrative distance happens to be lower than a routewith a longer prefix length.
Note
The RPF calculation takes into account the existence of multiple equal paths to multicast sources. A hash isdone between the last 32 bits of the source and the last 32 bits of the available next hops to select from amongthe interfaces that can be used to receive the multicast traffic. The interface returned by the RPF calculationwill be used for all multicast traffic from a given source. This leads to the load balancing of the multicasttraffic on a per-source basis.
Changes to IPv6 BGP/MBGP led to a different approach to using BGP routes for RPF calculation. Based onRFC 2545 and RFC 2858, the following types of routes are advertised by MBGP:
Unicast-only routes are marked with SAFI=1. For this reason, the BGP entries in the unicast RIB areignored. However, you can enable routers to use the BGP unicast routes for RPF with the commandipv6 rpf use-bgp.
•
Multicast-only routes are marked with SAFI=2. These routes cannot be used for unicast. The sameSAFI=2 is available with IPv4.
•
Note
IETF decided to remove SAFI=3, which was marking routes to be used for both unicast and multicast routing.
With MBGP, an IPv6 multicast address family can be defined for exchanging routes to be used in multicastrouting. The routing information available via static routes and RIB is used for multicast routing purposes andis maintained in the MRIB (Multicast RIB). There is, however, no mapping of the MRIB for MBGP.
Because it can carry multicast routes, MBGP provides the means to exchange IPv6 multicast-relevant routinginformation between PIM domains. You can enable the BGP process on a Cisco router to exchange IPv6multicast routing information by simply configuring a new address family with the command address-familyipv6 multicast, as shown in Example 6-3.
216 Part I: Implementing IPv6 Services
216 Part I: Implementing IPv6 Services
Example 6-3. Enabling BGP to Exchange IPv6 Multicast Routes
The highlights in the preceding example indicate that the IPv6 multicast address family enables BGP process200 to exchange IPv6 multicast information with neighbor 2001:D:1::2. In this example, prefix2001:D:AAAA:1::/64 is advertised for multicast routing only. You can view information regarding themulticast routes exchanged via MBGP through the various options available with the show bgp ipv6 multicastcommand. The command's output on the peer (201.201.201.201 with address 2001:D:1::2) of the routerconfigured in Example 6-3 shows the advertised prefix.
Example 6-4. IPv6 Multicast Route Advertised via BGP
MBGP-Peer-Router#show bgp ipv6 multicastBGP table version is 182, local router ID is 201.201.201.201Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 2001:D:AAAA:1::/64
2001:D:1::1 0 0 200 i
In the cases where the BGP neighbor does not support the multicast SAFI, additional configuration on theSAFI-aware router facilitates the exchange of multicast routes through the unicast address family, as shown inExample 6-5.
Example 6-5. Enabling BGP Process to Exchange IPv6 Routes with a Neighbor That Does Not Support theMulticast SAFI
It is also worth observing that whereas the RPF calculation returns a next hop for the reverse path based on theIPv6 unicast topology, with IPv6 this result does not always match the address of the upstream PIM neighborbecause the router might have multiple addresses on the interconnecting link. In this case, the unicast topologyis not congruent with the PIM topology in terms of next-hop addresses. The PIM Hello message used inbuilding PIM neighbors was enhanced to avoid this type of situation. The Routable Address option of the PIMHello message enables the router to list all its addresses on the interface over which the Hello is sent. The
Part I: Implementing IPv6 Services 217
Part I: Implementing IPv6 Services 217
address of a next-hop router generated by an RPF calculation is always compared with the addresses it listedin the Routable Address option of its PIM Hello messages.
Routers also use RPF checks to ensure a loop-free distribution of multicast traffic throughout the network.After PIM builds the distribution tree, routers do an RPF check on the SA of all received multicast packets. Ifthe RPF check matches the upstream interface in the distribution tree, the packet is forwarded downstream;otherwise, it is discarded.
Protocol Independent Multicast
Multicast routing represents the process of building the MDT. The tree topology information is collected andmaintained in the Tree Information Base (TIB). Many protocols were developed to support this process. Theyall leverage one or both of the tree types mentioned. Distance Vector Multicast Protocol (DVMRP), MulticastOpen Shortest Path First (MOSPF), Core Based Trees (CBT), Protocol Independent Multicast (PIM), andPragmatic General Multicast (PGM) all dealt with certain models of service delivery, and catered to certainapplication needs. In time, implementation issues and deployment experiences trimmed down the number ofpreferred IPv4 multicast routing protocols to PIM variants.
Learning from its predecessor, IPv6 adopted only three multicast routing protocols:
PIM-SM for many-to-many applications, where multiple sources transmit to the same group. Thetypical applications are videoconferencing or peer-to-peer gaming.
•
PIM-SSM is a subset of PIM-SM, and it is used for one-to-many applications, where a single sourcetransmits to multiple listeners. The typical applications are content delivery such as video or audioprograms.
•
PIM-Bidir is used for many-to-many applications, where all members of the group can be bothreceivers and sources. PIM-Bidir is the recommended routing protocol for "hoot 'n' holler"applications, which enable any host to send a message to a group it belongs to.
•
Note
PIM-SM, PIM-SSM, and PIM-Bidir operate based on a "pull" model, where each router requests, or pulls, themulticast information from the source or RP whenever it has listeners or downstream clients. The MDT isbuilt based on demand. By contrast, the "push" model is sending, or pushing, the multicast information to allrouters, so at first all routers are part of the MDT. The nodes that are not interested in that multicast are latertrimmed from the tree. PIM-Dense Mode supports the "push" multicast model. IPv6 multicast does notsupport PIM-DM.
IPv6 PIM implementation is similar to IPv4. As a matter of fact, the PIM protocol standards are transparentwith respect to the version of IP. For these reasons, you can reference multicast technology-specific referencessuch as Developing IP Multicast Networks, Volume 1, by Beau Williamson, to gain an in-depthunderstanding of the PIM protocol.
In this brief review of the protocol, let's start with an important element in its operation, the designated router(DR) election. PIM routers build adjacencies between themselves. If two or more PIM routers are on the samemulti-access link, they elect a DR to handle the PIM control traffic coming from and going to that link. TheDR is the router that registers any source on the link. The DR is also the router that joins a tree when a listenerbecomes active on the link. The PIM router with the highest IPv6 address or the highest priority (configurablevia the ipv6 pim dr-priority interface command) is elected the DR for a multi-access network.
218 Part I: Implementing IPv6 Services
218 Part I: Implementing IPv6 Services
Note
The DR election process uses different rules than the querier election process described earlier in the"Multicast Listener Discovery" section. This means that different routers on the same link might performthese two functions.
This concept, along with that of RPF, identifies the source and the destination of PIM join messages sent byrouters in the process of building the MDT.
PIM-SM
It is important to understand PIM-SM because the other two variants, PIM-SSM and PIM-Bidir, can beviewed as two of its special cases. There are two interesting events in the operation of PIM-SM:
Multicast source registration with an RP• Multicast listener joining the group•
Let's assume that in a multicast domain, the shared tree with the root in the RP is already in place. Multicastsources for a given group need to register with the RP defined for that group. Based on the PIM draft'srecommendation, a virtual tunnel interface is used by routers to register sources connected to them. The tunnelis unidirectional, and it is used to send register messages to the RP. A tunnel interface is created for each RPdefined or advertised in the PIM domain.
Example 6-6 shows interface Tunnel 1 created for the RP 2001:D:AAAA:1::1.
Example 6-6. Tunnel Interface Created to Communicate with a Known RP
Router#show ipv6 pim tunnelTunnel1*
Type : PIM EncapRP : 2001:D:AAAA:1::1Source: 2001:1:FFFF:FFFF:2::
The tunnel interface can be created only for the registration process, and then it can be removed. Cisco IOSsoftware, however, keeps the tunnel interface active for as long as the RP is known. The tunnel interfacecomes up when the RPF calculation for the RP returns an output interface and there is a unicast route installedfor the RP (see Example 6-7).
Example 6-7. Relevant Information for the Tunnel Interface Used for Registering with a Known RP
Router#show interfaces Tunnel1Tunnel1 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set
Example 6-7 refers to the tunnel interfaces created on non-RP routers. On the RP side, a single tunnel is usedfor all registering tunnels set up to it.
When a DR receives multicast traffic from a connected source, it analyzes the group address to find its RP. Itthen encapsulates the multicast traffic and sends it through the appropriate tunnel interface to the appropriateRP. After the source has been registered, the RP sends register-stop messages outside of the tunnel over anSPT built between the source and the RP. From there on, the multicast traffic originated by that source willflow unencapsulated over the shortest path to the RP and then down the shared tree. The leaf routers of the STuse this traffic to learn about the registered sources. Figure 6-3 summarizes the source registration process.
Figure 6-3. Conceptual Representation of Source Registration with PIM-SM
[View full size image]
Consider now how the shared tree is built. When a listener expresses interest in a G by sending MLD reports,the routers on that link install their interface in a list of output interfaces for that multicast traffic. However,only the DR looks up the RP-to-group mapping, identifies the group's RP, and sends a PIM (*,G) join to theupstream neighbor out the interface that is the result of the RPF calculation for that RP. Through this process,all routers that are interested in traffic for group G form an MDT, the ST identified as (*,G).
It was mentioned earlier that routers learn about sources for a group G through traffic that comes down theST. When a DR learns about a certain source, the DR sends an (S,G) PIM join message directly toward thesource. The routers along the reverse path analyze the metric to the source versus the one to the RP andforward the joins up the shortest path, thus building an (S,G) SPT. The DR can choose to switch over to
220 Part I: Implementing IPv6 Services
220 Part I: Implementing IPv6 Services
receiving traffic over the SPT rather than the ST for better delay characteristics.
Note
Cisco routers, by default, immediately switch over from the ST to the SPT for traffic forwarding. To stop theswitchover and have routers use only the ST for forwarding multicast traffic, you must configure themglobally with the ipv6 pim spt-threshold infinity command.
Figure 6-4 summarizes this process.
Figure 6-4. Conceptual Representation of Listener Join with PIM-SM
[View full size image]
Note
In a router, an MDT's representation consists of an upstream neighbor identified through the RPF calculationand an outgoing interface list (OIL). The OIL in IPv6 has two types of entries (unlike IPv4, in which a singlelist is used):
Immediate OIL Generated by PIM joins/leaves and by MLD report messages. They reflect the treetopology and can be seen in the output of show ipv6 pim topology.
•
Inherited OIL Interfaces inherited by an (S,G) from a (*,G). You can see the inherited OIL and theimmediate OIL in the MRIB with the show ipv6 mrib route command.
•
Part I: Implementing IPv6 Services 221
Part I: Implementing IPv6 Services 221
PIM-SM builds shared trees and requires the use of at least one rendezvous point (RP) for every multicastgroup. Different RPs can handle different multicast groups, and for this reason PIM has to be complementedby a mechanism that allows routers to learn which RP to use for a given group. Such mapping mechanisms areneeded both within a PIM domain and between various domains. A discussion of the mapping methodsavailable with IPv6 multicast follows in the "RP Mapping and Redundancy" section of this chapter. PIM alsobuilds SPTs that are used by default for traffic forwarding.
By default, PIM runs on all interfaces of a Cisco router enabled for multicast routing (using the globalconfiguration command ipv6 multicast-routing). You can disable PIM per interface by using the command noipv6 pim. For PIM-SM, you can configure an RP globally with the ipv6 pim rp-address <IPv6-address>command.
The PIM-relevant information can be viewed with the help of the various options available with the commandshow ipv6 pim (see Example 6-8).
Example 6-8. Options Available for the show ipv6 pim Command
Router#show ipv6 pim ? bsr PIM Bootstrap router df Bidir Designated Forwarder group-map PIM group-to-protocol mapping information interface PIM interface information join-prune PIM Join/Prune information neighbor PIM neighbor information range-list PIM range-list information topology PIM topology table information traffic PIM traffic counters tunnel List PIM tunnel interfaces
PIM-SSM
PIM-SSM represents a subset of PIM-SM. In this case, the listener knows a priori both the group and thesource (S,G) it wants to join. PIM-SSM operates similarly to PIM-SM, but it does not build a shared tree andso it does not need an RP. The listener must be able to indicate to its DR what (S,G) it is interested in. For thisreason, MLDv2 listener or the SSM MLDv1 mapping router support is required for a PIM-SSM deployment.
Because it builds only (S,G)s, the deployment and management of the service is much easier than forPIM-SM. Moreover, there is no need for additional protocols that help manage the RP. On the other hand,managing the distribution of source information to listeners might represent a challenge. Application layerprotocols, independent of PIM, are needed to help hosts automatically discover the source of a given group.Work is being done in this area, but for the time being the most common way to distribute source informationis via a known repository such as a web page.
PIM-Bidir
Bidirectional PIM is an extension of PIM optimized for many-to-many communications. It represents theother end of the spectrum in terms of MDT types used. PIM-Bidir, like PIM-SM, uses shared trees, but itnever builds SPTs. There is no source registration process, so the traffic is unconditionally forwarded on theST. This allows it to scale to an arbitrary number of sources with minimal additional overhead. The ST isbidirectional in the case of PIM-Bidir. Under these circumstances, RPF is not operating as in the case ofPIM-SM, and the RP becomes the reference point in maintaining a loop-free network. In the case ofPIM-Bidir, the RP is configured with ipv6 pim rp-address <IPv6-address> bidir.
222 Part I: Implementing IPv6 Services
222 Part I: Implementing IPv6 Services
Ultimately, the multicast routing protocol selection is done based on the application types and service modelsthat are being deployed. Cisco routers can support all three IPv6 PIM protocols simultaneously for differentmulticast groups.
Based on the routing, tree topology, and group membership information available, forwarding decisions aremade for the multicast traffic, and they are mapped into the Multicast Forwarding Information Base (MFIB).The MFIB relates to the MRIB in the same way the RIB relates to FIB for unicast.
Deployment Considerations
Along with MLD and PIM, a few additional operational aspects are important when deploying an IPv6multicast service. Some mechanisms help manage the multicast domain, and some mechanisms help routerscorrelate multicast groups to RPs that serve them. These mechanisms, together with the multicast protocolsalready discussed, fit into complete service architectures that provide the network-wide perspective ondeploying IPv6 multicast. These topics are analyzed in this section.
Multicast Domain Control
For scalability considerations, it is advisable at times to segment the network in PIM domains. The PIMmessages are contained within the PIM domain, leading to smaller-size MDTs. This smaller size translatesinto fewer states to maintain and a lighter RP utilization.
Note
It is worthwhile to note that although PIM uses unicast routing information for RPF calculation, a PIMdomain is not necessarily the same as a routing domain.
The techniques used with IPv4 for multicast domain control, such as Time-To-Live (TTL) constraints andACLs, can be used in the case of IPv6, too. On the other hand, IPv6's address scoping provides a powerfultool to implement domain control in a cleaner way. You can define boundaries on router interfaces for variousaddress scopes.
RP Mapping and Redundancy
For PIM-SM to build and use a shared tree, it is critical for the PIM routers to know what RP to use for eachmulticast group. IPv6 did not inherit all mechanisms developed for distributing RP-to-group mappinginformation in IPv4 multicast. For example, there is no standardization work done for Auto-RP in IPv6 at thetime of this writing. On the other hand, the larger IPv6 addresses support a new, IPv6-specific mechanism thatis described in this section.
Static RP
A basic way to advise routers of the RP that should be used for a multicast group is to statically configure thisinformation on each one of them. Example 6-9 shows the configuration of this static mapping on a Ciscorouter.
Part I: Implementing IPv6 Services 223
Part I: Implementing IPv6 Services 223
Example 6-9. Configuring 2001:1::1 as a Static RP for (*,FF0A ::1)
Despite its simplicity, this method has the potential of being a provisioning and network managementnightmare. It also limits significantly the ways in which you can implement RP redundancy in the network.
Bootstrap Router
Bootstrap router (BSR) provides dynamic distribution of RP-to-group mapping information across a PIMdomain. A set of routers is configured as candidate BSRs. Each of them sends bootstrap messages (BSMs)that are flooded throughout the domain. The messages contain a Priority field. If a candidate BSR receives aBSM from another candidate with a higher priority, it stops sending BSMs for a given period of time.Through this election process, a single BSR is left flooding the domain with BSMs and thus providing theRP-to-group mapping information.
Note
The BSR election tiebreaker between two candidates with equal priorities is their advertised address. Thehighest address wins.
A Cisco router is globally configured to be a candidate BSR with the following command:
ipv6 pim bsr candidate bsr <address of the candidate> <hash-mask length> priority<priority value>
You can view the result of the BSR election process with the show ipv6 pim bsr election command.
A set of routers (same as or different from the BSR candidates) is configured as candidate RPs, and theyperiodically send messages to the BSR to indicate their willingness to be the RP for a list of groups includedin the messages. The RP candidates are globally configured: ipv6 pim bsr candidate rp <address of thecandidate> [access-list identifying the groups] <priority>.
You can view a list of candidate RPs by using the show ipv6 pim bsr rp-cache command.
Note
Cisco routers identify the BSR address from the bootstrap messages. They forward only those BSMs that arereceived over the interface that matches the RPF calculation for the BSR.
The BSR builds a subset of RPs willing to serve the PIM domain. It advertises these candidate RPs and thegroups they are willing to serve with the help of BSMs. The messages are flooded throughout the domain, andPIM routers store the advertised mapping information. You can use the show ipv6 pim group-map command
224 Part I: Implementing IPv6 Services
224 Part I: Implementing IPv6 Services
to view the RP-to-group mapping. If a candidate RP is no longer available, the BSR adjusts the RP-to-groupmapping information in the BSMs. This adjustment provides the PIM domain with a certain level of RPredundancy.
Domain control has to be implemented for the BSMs, too. These flooded packets should not be allowed toleave the designated BSR domain. The interfaces at the edge of the domain are enabled (interface commandipv6 pim bsr border) to drop any BSMs of any scope.
Embedded RP
After all the bits that were reserved by the IPv6 addressing architecture for scopes and flags, there still areplenty left in an IPv6 multicast address to include the address of the RP to be used for a multicast group. Thissimple mechanism of providing the RP-to-group mapping information is called embedded RP. It relies on theunicast-prefix multicast group addresses described in RFC 3306, with an additional flag that indicates thepresence of the RP address. Figure 6-5 details the procedure of building this type of multicast addresses.
Figure 6-5. Creating an Embedded RP Multicast Address
[View full size image]
Example 6-10 applies the procedure described in Figure 6-5 to build a multicast group address that embedsthe RP address 2001:D:AAAA:1::2.
Example 6-10. Generating an Embedded RP Multicast Address
RP Address: 2001:D:AAAA:1::2RP Address Network Length: 64 (decimal) -> 40 (hex)RP Interface ID: 2Scope for the Embedded RP multicast address: 8Group ID: 100Embedded RP multicast address: FF78:240:2001:D:AAAA:1:0:100
The elements used in building an embedded RP multicast address are highlighted in Example 6-10. Highlightsare used to identify the contribution of each element in the resulting embedded RP address. With this
Part I: Implementing IPv6 Services 225
Part I: Implementing IPv6 Services 225
mechanism, each registered unicast address automatically comes with 256 RP addresses for the 16 addressscopes and 232 multicast groups for each RP.
Routers that support the embedded RP concept search for the RP address in MLD reports, PIM traffic, or datatraffic by looking at the destination multicast addresses that have the R flag set to 1. The router whose addressis advertised in the multicast address has to be statically enabled to be an RP.
Embedded RP does not require changes to the PIM protocol, and it can in fact replace BSR for RP-to-groupmapping within a PIM domain. It can also be used for mapping RPs to group addresses across different PIMdomains. However, you must consider a few drawbacks:
Embedded RP does not support PIM-Bidir.• Only one RP address can be used for each group. This means that any RP redundancy mechanismused with embedded RP must have an anycast flavor.
•
Not all vendors support embedded RP. If the network includes routers without support for the feature,you should configure those routers for static RP or BSR.
•
The embedded RP functionality runs by default on multicast-enabled Cisco routers. You can disable itexplicitly on routers operating in domains that do not support the feature across various types of platforms.
RP Redundancy
A single RP per PIM domain represents a single point of failure. Therefore, it is important to consider ways toprovide RP redundancy. A certain level of redundancy was already mentioned in the context of BSR. If acandidate router stops advertising its willingness to be an RP (either because of reconfiguration ordevice/network failure), the BSR removes it from the RP set, and the routers in the domain update theirRP-to-group mapping information accordingly.
There remains, however, the need to identify RP redundancy strategies for deployments that use, for example,static RP or embedded RP. A possible solution is to simulate an anycast-like behavior by configuring tworouters with the same RP address but different prefix lengths, such as RP1=2001:D:AAAA:1::2/128 andRP2=2001:D:AAAA:1::2/127. Because of the longest prefix match, RP1 will always be reached first by bothsources and PIM routers joining the ST. If RP1 fails, its role is picked up by RP2.
Note
The redundancy options discussed do not provide the RPs with a mechanism to exchange source registrationinformation. In IPv4, the Multicast Source Discovery Protocol (MSDP) performed this function. MSDP inIPv4 was considered a temporary solution. Despite not evolving or even becoming a standard, MSDP is stillused in IPv4 multicast deployments. IPv6 did not pursue MSDP-IPv6, and because of that theMSDP/anycast-RP redundancy solution, currently widely used in IPv4 multicast deployments, is not availablein IPv6. MSDP inadvertently provided another fringe benefit: RP load balancing. Mechanisms will have to bedeveloped to provide this functionality in IPv6.
Service Models
The design of the multicast service deployment in a network should be tailored to best fit the applications thatmust be supported by the network. The two popular multicast service models are Any Source Multicast(ASM) and Source Specific Multicast (SSM). Each model leverages a subset of the protocols and mechanismsdiscussed in this chapter, and each has its strengths and weaknesses. This section briefly reviews ASM and
226 Part I: Implementing IPv6 Services
226 Part I: Implementing IPv6 Services
SSM and highlights the IPv6 specificities.
ASM Versus SSM
The simplest service model is the SSM. It is very well suited for content delivery where a set of fixed sourcesprovides video or audio multicast streams to interested users, as shown in Figure 6-6. The important thing tonotice is the localized nature of the sources. A customer's set-top box or PC can map video/audio channel IDsto (S,G)s, and it can handle the process of joining a requested (S,G) when the corresponding channel isselected.
Figure 6-6. Deployment Models, SSM and ASM
[View full size image]
The following is needed to deploy SSM:
MLDv2 or MLDv1 combined with SSM mapping-capable routers (see the earlier section "SourceSpecific Multicast Mapping for MLDv1").
•
Use of multicast group address of the SSM format FF3X::.• PIM-SSM, which is very easy to deploy. It does not require RPs and the overhead necessary tomanage them.
•
SSM has no domain constraints. However, if the number of (S,G)s is very large, the memory and processingresources of the routers supporting the multicast service might be excessively taxed.
In an environment where a large number of sources are used and the applications are more dynamic in natureor multiparty oriented, the use of a shared tree for protocol control might become justifiable (see Figure 6-6).Note that in this example, sources are located in different parts of the network. A shared tree in this casewould reduce the amount of MDT state that has to be maintained by the routers in the network. The service
Part I: Implementing IPv6 Services 227
Part I: Implementing IPv6 Services 227
model applied in this case is ASM. The use of an ST and the mandatory RPs adds complexity to the ASMmodel.
The following is needed to deploy ASM:
MLDv1 or MLDv2• PIM-SM or PIM-Bidir• Static RP, BSR, or embedded RP for RP management• Anycast RP solution to provide redundancy for static or embedded RP• Domain control measures•
SSM can, in principle, support most commonly deployed multicast applications. Its simplicity trades off forscalability limitations. If an application can be supported by both SSM and ASM, the first option in designingthe multicast service deployment should be SSM. Both SSM and ASM models are fully supported on theCisco routers. They can easily coexist in the same network.
Intradomain Versus Interdomain ASM
The ASM model requires the use of RPs. For scalability and manageability considerations, you can partition anetwork into PIM domains. Each PIM domain has its own set of RPs servicing the (*,G)s.
The intradomain multicast refers to the service deployment within a single PIM domain. All the conceptsdiscussed so far for ASM and SSM apply within a PIM domain. The questions are these: What happens whenmultiple PIM domains are defined in a network? How will they interact, and how should interdomainmulticast be deployed?
If you deploy ASM across multiple domains, the following information has to be exchanged betweendomains:
Multicast routes MP-BGP takes care of this function in both IPv4 and IPv6.• RP-to-group mapping In IPv4 and IPv6, it can be done with the help of BSR. With IPv6, you have anadditional option: using embedded RP.
•
Source registration information In IPv4, MSDP takes care of this function. Because in IPv6 there is noMSDP-like mechanism in place, only one of the domains can have RPs.
•
Because of the lack of MSDP-IPv6 or similar functionality, in IPv6 the only option available is to use a singlePIM domain for ASM deployments. SSM will always be the easy alternate solution for interdomain multicast.
Multicast over Tunnels
Chapter 3 describes the various tunneling mechanisms that were developed to facilitate the migration fromIPv4 to IPv6. When choosing tunneling mechanisms for IPv6 deployments, you should consider the long-termservice offerings. Table 6-3 notes multicast services provided by the various tunneling mechanisms.
Table 6-3. IPv6 Multicast Support over Tunnels
Tunnel Type
Cisco Support
IPv6 Multicast Support
228 Part I: Implementing IPv6 Services
228 Part I: Implementing IPv6 Services
Comments
6over4
No
Yes
Historic.
6to4
Yes
No
At the time of this writing, there is no active work within IETF on multicast support over this tunnelingmechanism.
Manual
Yes
Yes
IPv6 over IPv4 GRE
Yes
Yes
IPv4-compatible
IPv6 tunnel
Yes
No
Being deprecated; choose ISATAP instead.
ISATAP
Yes
No
At the time of this writing, there is no active work within IETF on multicast support over this tunnelingmechanism.
It is also important to consider the implications of deploying multicast over certain tunnels. For example, the6over4 tunnels require an IPv4 multicast infrastructure to support IPv6 multicast.
Part I: Implementing IPv6 Services 229
Part I: Implementing IPv6 Services 229
IPv6 islands can also be interconnected with other types of tunnels, such as pseudowire layer 2 tunnels. Thetunnels are layer 3 transparent, and they support multicast. The static nature of such tunnels makes for adeployment that scales poorly.
Multicast over MPLS Infrastructures
During the past decade, MPLS has become a mainstay in the core of most major service provider networks.Proposals are now being made for its deployment in enterprise networks, too. Along with MPLS came virtualprivate networks (VPNs), a popular service deployed over MPLS infrastructures. This service enablesenterprises to securely interconnect remote locations in a more cost-effective way than leasing lines. (Formore information on VPNs, see Chapter 7, "VPN IPv6 Architecture and Services.")
Currently, there is no intrinsic support for IPv4 multicast over MPLS networks. RFC 3353 provides a reviewof the challenges faced by multicast in an MPLS environment. A possible deployment approach is for themulticast to be forwarded untagged, completely ignoring the underlying MPLS infrastructure. This solution iscomplicated by the fact that a VPN's multicast traffic has to be isolated from that of other VPNs. The Ciscosolution to this control-plane problem is called multicast VPN (MVPN).
At the control-plane level, MVPN is virtual routing and forwarding (VRF) aware. On the PE router, a PIMinstance runs for each VRF and it performs the multicast routing function between the CEs and PEs thatbelong to that VPN. The multicast routing and forwarding table created is called a multicast VRF (MVRF).Each MVRF is assigned a multicast group address that is used for forwarding only its traffic (GREencapsulated) between PE routers. These multicast groups are manually mapped to MVRFs, and they aremanaged by a common, global PIM instance. The important thing to remember is that the actual forwardingacross the service provider network, within the global MD, is done at layer 3 and that the presence or absenceof MPLS is irrelevant.
Unlike IPv4, currently there is no MVPN-like solution available for IPv6, which proves particularly relevantwhen considering 6PE, the migration approach discussed in Chapter 3. 6PE is a practical way to provide IPv6unicast service over an MPLS network with minimal impact at the edge and no impact on the core. 6PE itselfcan be viewed as a global VPN. In the absence of an MVPN-like solution for 6PE, others need to be found toprovide multicast support. Such solutions will have to consider all the requirements that were placed on 6PEas a transition mechanism (no impact on the core and so forth). One option being worked on is to look at theMPLS cloud as an NBMA from the 6PE router perspective.
Note
Of course, you can complement a 6PE deployment with an overlay dedicated to the multicast service. You canuse fully meshed layer 2 MPLS-based tunnels to build such an overlay. The drawback is that an overlayentails additional operational and management costs.
Work is currently being done in IETF to solve the multicast over MPLS problem. A solution to this problemcan be leveraged to provide multicast support over 6PE and 6VPE, too.
230 Part I: Implementing IPv6 Services
230 Part I: Implementing IPv6 Services
IPv6 Multicast Deployment Examples
In this section, the IPv6 multicast concepts discussed so far are applied in the following practical examples:
SSM design in a service provider network• ASM design in an enterprise network•
Descriptions of full-scale IPv6 multicast deployments are presented in Part II of this book. At this point, thegoal is to provide a practical sense of how IPv6 multicast is configured and how it works.
SSM in a Service Provider Network
One of the services that service providers are trying to deploy for their broadband subscribers is video andaudio content delivery. The bandwidth available with broadband access is sufficient to support applicationssuch as video (which requires 2-4 Mbps) and audio (which requires 192 kbps). The SP deploys content serversin its data center, and they represent the sources of the streams. Each audio/video channel is a multicast streamidentified by a (S,G). Subscribers can use a PC with an installed client application or a set-top box thatsubscribes to the (S,G) that maps to the channel of interest. The application or the set-top box is configuredfor this mapping, and it handles the process of joining or leaving the (S,G). All the sources and the group IDsare fixed and known to the subscribers.
An SSM deployment best fits such a service model. The multicast protocols used in this example are asfollows:
MLDv2• PIM-SSM•
The deployment of this service is presented in the generic topology of an IP service provider shown in Figure6-7. The network was migrated to dual-stack IPv4/IPv6, and an IPv6 unicast infrastructure is in place. Figure6-7 shows the subset of routers in this topology used for this example.
Figure 6-7. SSM Deployment Example Topology
[View full size image]
The IPv6 IGP is OSPFv3. Two servers are shown in the data center. Two users interested in the contentprovided by these servers are shown in the access portion of the SP network. The two channels used in thisexample map to (2001:D:AAAA::1000, FF3A::100) and (2001:D:AAAA:1001, FF3A::101). The SP can
Part I: Implementing IPv6 Services 231
Part I: Implementing IPv6 Services 231
choose SSM group addresses without a defined scope, and the multicast traffic is meant to stay only withinthe provider's network.
Enabling IPv6 Multicast Routing
Only one global command is needed to enable PIM and MDLv2 on all IPv6-enabled router interfaces:
AC(config)#ipv6 multicast-routing
All routers that are meant to forward the multicast traffic need to be enabled for IPv6 multicast routing.
MLD Configuration
With IPv6 multicast routing enabled, the interfaces facing the two subscribers are running MLDv2. If the SPdoes not want the user to be able to subscribe to groups other than the ones offered through the paid service,FF3A::/96, the SP will enable MLD access control on the user-facing interfaces with the help of the followingACL:
AC#show ipv6 access-listIPv6 access list mld-acc-control
permit ipv6 any FF3A::/96 sequence 10
MLD access control is enabled on the interface that connects to subscriber 1 via VLAN 100, as highlighted inthe interface configuration and interface MLD information listed in Example 6-11.
Example 6-11. Interface Configuration and MLD Interface Status for the MLD Access Control Feature
interface GigabitEthernet0/2.100 encapsulation dot1Q 100 ipv6 address 2001:1:A1:64::1/64 ipv6 enableipv6 mld access-group mld-acc-controlAC#show ipv6 mld interface gig0/2.100GigabitEthernet0/2.100 is up, line protocol is up Internet address is FE80::201:FF:FE01:1/10 MLD is enabled on interfaceCurrent MLD version is 2
MLD query interval is 125 seconds MLD querier timeout is 255 seconds MLD max query response time is 10 seconds Last member query response interval is 1 secondsInbound MLD access group is: mld-acc-control
All three types of supported PIM are running on the routers shown in Figure 6-7. In principle, with PIM-SSM,no other configuration should be needed. However, the topology of this example offers an opportunity to tune
232 Part I: Implementing IPv6 Services
232 Part I: Implementing IPv6 Services
PIM a little bit.
Routers AC, E1L, and E2L in Figure 6-7 are all connected via a common, Ethernet broadcast domain. In thiscase, one router is elected to be a DR (as described in the "Multicast Routing" section of this chapter). Thenetwork designer might choose to control the DR election process by modifying the PIM DR priorities. In thisexample, the intent is to make sure E2L is always the PIM DR for this broadcast domain. The interfaceconfiguration and the result of the election can be displayed on E2L (see Example 6-12).
Example 6-12. Interface PIM Status Showing the Result of the DR Election Process
E2L#show ipv6 pim interface gig1/1.501Interface PIM Nbr Hello DR Count Intvl PriorGi1/1.501 on 2 30 2 Address: FE80::20A:8BFF:FE09:FD01
DR : this system
The PIM neighbors are kept at a lower DR priority, as shown in Example 6-13.
Example 6-13. PIM Neighbor Information as Seen on the Elected DR
E2L#sho ipv6 pim neiNeighbor Address Interface Uptime Expires DR pri BidirFE80::208:7CFF:FED9:F81B Gi1/1.501 00:15:43 00:01:24 1 BFE80::20A:8BFF:FE0A:101 Gi1/1.501 00:15:44 00:01:24 1 B
Subscriber Joining the (S,G)
This section shows what happens when the first subscriber sends an MLDv2 report message and it joins the(S,G) group (2001:D:AAAA:1::1000, FF3A::100). The access router (AC) shows the fact that it has a memberof the FF3A::100 group listening on interface GigabitEthernet 0/2.100, as highlighted in Example 6-14.
Example 6-14. MLD Membership to Group FF3A::100
AC#show ipv6 mld group FF3A::100MLD Connected Group MembershipGroup Address Interface Uptime ExpiresFF3A::100 Gi0/2.100 00:01:27 00:04:03
The PIM debug is turned on for the FF3A::100 group. The subscriber joining the group triggered a PIM joinmessage to be sent to the PIM DR and up the SPT (2001:D:AAAA:1::1000,FF3A::100), as shown in Example6-15.
Example 6-15. Output of IPv6 PIM Debug for Group FF3A::100
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) Create entryIPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) RPF changed from ::/- toFE80::20A:8BFF:FE09:FD01/GigabitEthernet0/1.501IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) MRIB modifyIPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) NULLIF-skip MRIB modify !AIPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/1.501 MRIB modify A !NSIPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) Source metric changed from [0/0] to [1/110]IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) MRIB modifyIPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/1.501 MRIB modify AIPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 Local statechanged from Null to Join Router AC joined the (S,G) SPT
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 Start being last hopIPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 FWD state changefrom Prune to Forward The Multicast traffic can now be forwarded down the SPT
After the second subscriber joins (S2,G2), at the AC router the PIM topology looks like Example 6-16.
Example 6-16. IPv6 PIM Topology on Router AC
AC#show ipv6 pim topologyIP PIM Multicast Topology TableEntry state: (*/S,G)[RPT/SPT] Protocol Uptime InfoEntry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive, RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources, RR - Register Received, SR - Sending Registers, E - MSDP External, DCC - Don't Check ConnectedInterface state: Name, Uptime, Fwd, InfoInterface flags: LI - Local Interest, LD - Local Dissinterest, II - Internal Interest, ID - Internal Dissinterest,
LH - Last Hop, AS - Assert, AB - Admin Boundary(2001:D:AAAA:1::1000,FF3A::100)SSM SPT UP: 00:01:59 JP: Join(now) Flags:RPF: GigabitEthernet0/1.501,FE80::20A:8BFF:FE09:FD01
Gi0/2.100 00:01:59 fwd LI LH(2001:D:AAAA:1::1001,FF3A::101)SSM SPT UP: 00:00:06 JP: Join(00:00:43) Flags:RPF: GigabitEthernet0/1.501,FE80::20A:8BFF:FE09:FD01 Gi0/2.101 00:00:06 fwd LI LH
The PIM topology will look similar throughout the rest of the network. It is interesting, however, to observe itat a node that has two equal-cost paths to the source. This is the case with the AG2L router (see Example6-17).
Example 6-17. PIM Topology on a Node with Two Equal-Cost Paths to the Multicast Source
AG2L#show ipv6 route 2001:D:AAAA:1::/64IPv6 Routing Table - 188 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2OE2 2001:D:AAAA:1::/64 [110/20]
via FE80::20B:60FF:FEA7:D81A, GigabitEthernet0/2via FE80::204:6DFF:FE7F:7C1A, GigabitEthernet0/1
AG2L#show ipv6 pim neighborNeighbor Address Interface Uptime Expires DR pri Bidir
In this case, it is expected that (S1,G1) and (S2,G2) are balanced, as shown in Figure 6-7, based on the path ofthe PIM join messages. The PIM topology does indeed reflect this per-source balancing. The output of showipv6 pim topology indicates that one group's traffic is received over interface GigabitEthernet0/1 and theother's over GigabitEthernet0/2, as highlighted in Example 6-18.
Example 6-18. PIM Topology with Redundant Paths to the Multicast Source
When the sources start transmitting the multicast traffic, you can monitor its forwarding via the MFIBcounters, as shown below for AG2L in Example 6-19.
Example 6-19. IPv6 Multicast Forwarding Information Based on MFIB Counters
AG2L#show ipv6 mfib | b FF3A::100(2001:D:AAAA:1::1000,FF3A::100) Flags:
Forwarding: 199/8/1482/98, Other: 0/0/0 GigabitEthernet0/2 Flags: A
GigabitEthernet0/1 Flags: AGigabitEthernet0/0 Flags: F NSPkts: 199/0
This output indicates that the subscribers are enjoying the content they expressed interest in. The SSM-basedservice is deployed with little configuration, and it is easy to manage.
ASM in an Enterprise Network
For the ASM deployment example, the topology chosen is that of an enterprise network (EN). Typicalapplications deployed in an EN are videoconferencing, remote learning, distribution of information and news,and collaborative tools. The servers supporting all the corporate applications are located in data centers thatare distributed across the network. This makes the deployment more suitable as an ASM model.
Part I: Implementing IPv6 Services 235
Part I: Implementing IPv6 Services 235
To describe an ASM-based deployment, a subset of routers was selected from an EN example topology, asshown in Figure 6-8. The network diagram in Figure 6-8 depicts two topological elements: the main campusand a remote office.
Figure 6-8. ASM Deployment Example Topology
[View full size image]
The following protocols are used to support the multicast services:
PIM-SM and MLDv2 or MLDv1 are used throughout the network.• BSR is used to deliver the RP-to-group mapping information within the main campus only.• The embedded RP functionality is used for the multicast traffic that has to cross domain boundaries.•
As far as routing is concerned, OSPFv3 is used in the main campus, and eBGP is used to exchange routinginformation with the remote offices. One PIM domain spans the entire network, but BSR flooding iscontained within the main campus network.
The setup steps and information common to both the ASM and the SSM examples are not explicitly presentedhere. All routers that have to support the service should be enabled for IPv6 multicast routing.
Configuring BSR
In the main campus shown in Figure 6-8, at least two PIM RPs have to be configured to avoid downtime incase of RP failure. Multiple RPs deployed in a PIM domain require a mechanism that informs routers as towhich RP serves a given group. BSR has been selected for this example to provide dynamic RP-to-groupmapping and RP redundancy.
Router C1 and C2 in the core of the network are set to be candidate BSRs, as highlighted in the configurationin Example 6-20.
236 Part I: Implementing IPv6 Services
236 Part I: Implementing IPv6 Services
Example 6-20. BSR Configuration of Two Candidate Routers
The two routers go through the BSR election process, at the end of which C1 becomes the BSR because of itsconfigured higher priority. The result of the BSR election process is highlighted in the output of show ipv6pim bsr election shown in Example 6-21.
Example 6-21. Outcome of the BSR Election Process
C1#show ipv6 pim bsr electionPIMv2 BSR informationBSR Election Information Scope Range List: ff00::/8
This system is the Bootstrap Router (BSR)BSR Address: 2001:1:FFFF:FFFF:2::Uptime: 00:00:27, BSR Priority: 2, Hash mask length: 128
RPF: FE80::20F:35FF:FE3F:441B,Loopback0 BS Timer: 00:00:32 This system is candidate BSR
The intent is to run BSR only within the main campus. To contain the BSR flooding within the main campus,the M1 interface for the link to the remote site is configured to drop the BSR traffic with the Cisco IOScommand ipv6 pim bsr border.
Configuring Candidate RP routers
With the BSR infrastructure in place, it is time to enable several routers to advertise their willingness to be RPfor certain multicast groups. For this example, routers DC1 and DC2 in the data center are set up as candidateRPs for the groups FF08::1:xxxx/112 identified via ACL bsr-group. This is implemented with the globalconfiguration command shown on router DC1 along with the ACL (see Example 6-22).
Example 6-22. BSR Configuration and Status of a Candidate RP Router
DC1ipv6 pim bsr candidate rp 2001:D:AAAA:1::1 group-list bsr-group priority 2DC1#show ipv6 access-list bsr-groupIPv6 access list bsr-group
Part I: Implementing IPv6 Services 237
Part I: Implementing IPv6 Services 237
permit ipv6 any FF08::1:0/112 sequence 10DC1#show ipv6 pim bsr candidate-rpPIMv2 C-RP information
Advertisement interval 60 seconds Next advertisement in 00:00:19
Group acl: bsr-group
In this example, the RPs are identified by their interface addresses on the same network with the multicastservers: 2001:D:AAAA:1::1 (for DC1) and 2001:D:AAAA:1::2 (for DC2). The same group address range iscovered by both RPs, which provides a level of redundancy for the deployment. If one of the RPs goes away,the BSR does not advertise it anymore. The elected BSR learns about all candidate RPs highlighted inExample 6-23.
Example 6-23. List of RPs Advertised via BSR
C1#show ipv6 pim bsr rp-cachePIMv2 BSR C-RP CacheBSR Candidate RP CacheGroup(s) FF08::1:0/112, RP count 2RP 2001:D:AAAA:1::1Priority 2, Holdtime 150
Then it distributes the RP-to-group mapping information throughout the entire main campus network. The B2edge router learns the BSR and RP-to-group mapping information, and it can be viewed in the output of showipv6 pim group-map (see Example 6-24).
Example 6-24. RP-to-Group Mapping Information Learned by a Router via BSR
The routers enabled for multicast routing throughout the PIM domain create a virtual tunnel for the knownactive RPs. They use this interface to register directly connected sources. Example 6-25 shows the tunnel builtby router C1 to the RP.
238 Part I: Implementing IPv6 Services
238 Part I: Implementing IPv6 Services
Example 6-25. Tunnel Built by C1 to the RP for Registration Purposes
C1#show ipv6 pim tunnelTunnel1* Type : PIM Encap
RP : 2001:D:AAAA:1::1 Source: 2001:1:FFFF:FFFF:2::
The main campus is now ready to support multicast traffic for groups FF08::1:xxxx using RP2001:D:AAAA:1::1.
PIM Topology and Traffic Forwarding
The FF08::1:100 multicast group is used to exemplify the operation of the main campus multicast network.Suppose the users join groups, as shown in Example 6-26 for interface GigabitEthernet0/2.100, but there areno registered sources yet.
Example 6-26. IPv6 MLD Registration State When No Sources Are Registered
B2#show ipv6 mld group FF08::1:100MLD Connected Group MembershipGroup Address Interface Uptime ExpiresFF08::1:100 Gi0/2.100 00:00:16 00:04:03
Because there are no sources, the only information available in the PIM topology is that of the ST (*,FF08::1:100) highlighted in Example 6-27.
Example 6-27. PIM Topology When No Sources Are Registered
B2#show ipv6 pim topology | b FF08::1:100(*,FF08::1:100)SM UP: 00:00:21 JP: Join(00:00:28) Flags: LHRP: 2001:D:AAAA:1::1RPF: GigabitEthernet0/1.501,FE80::20F:35FF:FE3F:441A Gi0/2.100 00:00:21 fwd LI LH
As soon as a source 2001:D:AAAA:1::1000 registers for this group, an (S,G) SPT is built for it, as shown bythe highlighted output in the new PIM topology output in Example 6-28.
Example 6-28. PIM Topology When a Source Registered
No interfaces in immediate olistB2#show ipv6 mfibIP Multicast Forwarding Information BaseEntry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag, AR - Activity Required, K - KeepaliveForwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per secondOther counts: Total/RPF failed/Other dropsInterface Flags: A - Accept, F - Forward, NS - Negate Signalling IC - Internal Copy, NP - Not platform switched SP - Signal PresentInterface Counts: FS Pkt Count/PS Pkt Count(*,FF08::1:0/112) Flags: C Forwarding: 0/0/0/0, Other: 0/0/0(*,FF08::1:100) Flags: C Forwarding: 0/0/0/0, Other: 0/0/0 GigabitEthernet0/1.501 Flags: A NS GigabitEthernet0/2.100 Flags: F NS Pkts: 0/0(2001:D:AAAA:1::1000,FF08::1:100) Flags:
Forwarding: 90974/1096/76/651, Other: 0/0/0 GigabitEthernet0/1.501 Flags: A GigabitEthernet0/2.100 Flags: F NS
Pkts: 94161/10
The MFIB counters indicate the traffic is flowing from the source to the listener over the(2001:D:AAAA:1::1000,FF08::1:100) SPT.
Operation with Embedded RP
MP-BGP offers the means to exchange routing information between the campuses. Because in this exampleBSR flooding was stopped at the boundary between them, embedded RP is used for RP-to-group mapping.For all multicast applications that span the entire network, the multicast group addresses used should containthe address of the RP based on the format described earlier in the "Embedded RP" section.
You must statically configure the router embedded in the multicast group address to be an RP. For thisexample, the router chosen to be RP for embedded RP groups is DC2. DC2 is set to be an RP with thefollowing global configuration command
ipv6 pim rp-address 2001:D:AAAA:1::2
Following the procedure described earlier in the chapter, an embedded group address for this RP isFF78:240:2001:D:AAAA:1:0:100. When a subscriber in the remote campus joins the group, the RP-to-groupmapping is learned from the multicast address. This mapping is highlighted in the output of show ipv6 pimgroup-map on the R1 router in Example 6-29.
Example 6-29. RP-to-Group Mapping with Embedded RP
Client : Embedded Groups : 1 Info : RPF: PO2/0,FE80::20D:66FF:FE40:D8CC
240 Part I: Implementing IPv6 Services
240 Part I: Implementing IPv6 Services
When a source is present for the group, the (S,G) is built for the traffic. Both (S,G) and (*,G) groups can benow seen highlighted in the PIM topology (Example 6-30).
Example 6-30. PIM Topology with a Registered Source for the Embedded RP Group
R1#show ipv6 pim topologyIP PIM Multicast Topology TableEntry state: (*/S,G)[RPT/SPT] Protocol Uptime InfoEntry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive, RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources, RR - Register Received, SR - Sending Registers, E - MSDP External, DCC - Don't Check ConnectedInterface state: Name, Uptime, Fwd, InfoInterface flags: LI - Local Interest, LD - Local Dissinterest, II - Internal Interest, ID - Internal Dissinterest, LH - Last Hop, AS - Assert, AB - Admin Boundary(*,FF78:240:2001:D:AAAA:1:0:100)SM UP: 01:59:30 JP: Join(00:00:20) Flags: LHRP: 2001:D:AAAA:1::2RPF: POS2/0,FE80::20D:66FF:FE40:D8CC Loopback100 01:59:30 fwd LI LH(2001:D:AAAA:1::1000,FF78:240:2001:D:AAAA:1:0:100)SM SPT UP: 00:00:42 JP: Join(00:00:08) Flags: KAT(00:02:48) RARPF: POS2/0,FE80::20D:66FF:FE40:D8CC
No interfaces in immediate olist
The tree topology in the preceding example shows an empty immediate OIL for (2001:D:AAAA:1::1000,FF78:240:2001:D:AAAA:1:0:100). This is because the router did not receive any PIM joins or MLD reportsfor the (S,G), the events that generate entries in the immediate OIL. On the other hand, from a forwardingperspective, the MRIB shows outbound interfaces for the (S,G), as highlighted in the output of show ipv6mrib route in Example 6-31. These are inherited by the (S,G) from the (*,G).
Example 6-31. Forwarding Information for the Embedded RP Multicast Group
R1#show ipv6 mrib route FF78:240:2001:D:AAAA:1:0:100IP Multicast Routing Information BaseEntry flags: L - Domain-Local Source, E - External Source to the Domain, C - Directly-Connected Check, S - Signal, IA - Inherit Accept, D - DropInterface flags: F - Forward, A - Accept, IC - Internal Copy, NS - Negate Signal, DP - Don't Preserve, SP - Signal Present, II - Internal Interest, ID - Internal Disinterest, LI - Local Interest, LD - Local Disinterest(*,FF78:240:2001:D:AAAA:1:0:100) RPF nbr: FE80::20D:66FF:FE40:D8CC Flags: C POS2/0 Flags: A NS
Loopback100 Flags: F NS LI(2001:D:AAAA:1::1000,FF78:240:2001:D:AAAA:1:0:100) RPF nbr: FE80::20D:66FF:FE40:D8CCFlags: POS2/0 Flags: A
Loopback100 Flags: F NS
The IPv6 routing information is exchanged between the main campus and the remote offices via eBGP. In thisnetwork example, it was chosen to advertise the source prefix (2001:D:AAAA:1::/64) only for multicast usevia the multicast IPv6 address family. The output in Example 6-32 shows the prefix advertised within theBGP multicast address family but not present in the IPv6 unicast routing table.
Part I: Implementing IPv6 Services 241
Part I: Implementing IPv6 Services 241
Example 6-32. IPv6 Prefix Advertised by BGP for Multicast Only
R1#show bgp ipv6 multicast 2001:D:AAAA:1::/64BGP routing table entry for 2001:D:AAAA:1::/64, version 3154Paths: (1 available, best #1, table Global-MBGPv6-Table) Not advertised to any peer 200 2001:11:22:1::1 from 2001:11:22:1::1 (200.200.200.200) Origin incomplete, metric 20, localpref 100, valid, external, bestR1#show ipv6 route 2001:D:AAAA:1::/64% Route not found
The prefix is available for multicast but not for unicast routing.
Note
It is important to note here that with the 2001:D:AAAA:1:: advertised as a multicast route only, the listenersin the remote campus will be able to join and receive traffic from sources in the main campus. On the otherhand, because these routers do not have a unicast IPv6 route to the RP (2001:D:AAAA:1::2), they will not beable to bring up their tunnel interface to the RP. Because of this, the routers in the remote campus will not beable to register any sources with the RP.
The deployment examples discussed in the last two sections show IPv6 as an apt successor of its IPv4predecessor in terms of offering multicast services. IPv6 builds on the successes of IPv4, and it ignores itsfailures. Except for a few details, there are no major differences between the two multicast implementations.IPv6's advantage consists of its larger addressing space, its address scoping, and a hindsight perspective onprotocol selection. IPv6 multicast has reached a level of maturity that makes it ready for large-scaledeployments in both ASM and SSM models. The only scenario for which IPv6 does not have a completesolution at this time is that of a multidomain deployment. It currently has no mechanism in place to exchangesource information between PIM domains. This drawback represents one area of the IPv6 protocol that willlikely see further development.
Chapter 7. VPN IPv6 Architecture and Services
"VPN is a generic term that covers the use of public or private networks to create groups of users that areseparated from other network users and that may communicate among them as if they were on a privatenetwork" (RFC 4026). IP-based VPNs have become popular in the recent years, and, as reviewed in Chapter1, "The Case for IPv6An Updated Perspective," the same reasons for deploying IPv4 VPNs apply to IPv6.
The "Virtual Private Network Overview" section introduces VPN terminology, the taxonomy of the varioustypes of VPNs, and their applicability to IPv6.
IP-based VPNs can be offered as a service by a service provider (SP) or they can be deployed by the SP'scustomer itself. Each solution has its benefits and drawbacks.
The "Using IPsec to Implement CE-Based VPNs" section focuses on customer edge (CE)-based VPNs usingIPsec, where the provider edge (PE) devices do not know anything about the routing or the addressing of thecustomer networks.
242 Part I: Implementing IPv6 Services
242 Part I: Implementing IPv6 Services
PE-based VPNs are explored in more detail in the "BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution"section, with a focus on Multiprotocol Label Switching (MPLS) solutions.
The section "Topology Examples" contains examples of various VPN topologies discussed in this chapter.
Virtual Private Network Overview
VPN technology enables enterprises to connect their sites together over apublic infrastructure; it allows businesses to set up extranets betweenthemselves, and telecommuters to connect to their office network. It hasmechanisms that offer security and quality of service (QoS), enablingapplications such as voice and video.
For enterprises buying VPN service (instead of building their own privatenetwork using, for example, leased lines) from an SP, the main benefits areprice and flexibility. The lower prices and flexibility are the result of theSP's ability to reduce operational costs by consolidating its services over asingle IP infrastructure. This consolidation leads to better use of resourcesand enables the provider to offer value-added services such as guaranteedQoS, multicast, redundant routes, fast path recovery, and so on, on a"get-what-you-pay-for" basis.
Two VPN models have been widely deployed in recent years: the CE-based("overlay") model, and the PE-based ("peer-to-peer") model. Although theyare briefly discussed in the following sections, the terminology is introducedhere:
Provider network This is the SP network, enabling connectivitybetween customer sites (also referred as P-network).
•
Customer network This is the customer network, typically a set ofcustomer sites, to be connected over the P-network.
•
Customer site This is one, topologically contiguous customer sitesuch as a campus or remote office.
•
Provider device (P) An SP router that does not connect to customersites.
•
Provider edge device (PE) An SP router connected to VPNcustomer sites. The PE router marks the edge of the P-network.
•
Customer edge device (CE) A customer router that connects thecustomer site to the P-network.
•
Virtual private network (VPN) A set of customer sites that areallowed to communicate with each other and are subject to acommon set of administrative policies. Note that a "site" can be asingle remote user.
•
IPv4 VPN A VPN that connects IPv4-enabled sites.• IPv6 VPN A VPN that connects IPv6-enabled sites.• Dual-stack VPN A VPN that connects separately IPv4-enabled sitesand IPv6-enabled sites.
•
Hybrid VPN A VPN that connects IPv4-only enabled sites andIPv6-only enabled site.
•
Part I: Implementing IPv6 Services 243
Part I: Implementing IPv6 Services 243
Many of the same techniques and mechanisms are used in both theCE-based and the PE-based VPN models. The difference between the twomodels is one of economy, politics, and administrative domains rather thantechnology.
IPsec is most often used in CE-based VPNs, and MPLS in PE-based VPNs.
The mechanisms and technology used in deploying IPv6 VPNs are the sameas for IPv4 VPNs. Some differences apply as to how an IPv6 VPN will bedeployed, however. Because IPv6 has enough addresses (to say the least),there is no need to use a private overlapping address range. Avoidingoverlapping address space simplifies management and makes mergingseveral private internets into a single private internet much easier.
A challenge for the deployment of IPv6 in general and IPv6 VPN inparticular relates to its coexistence with IPv4. It is expected that the publicinfrastructure will migrate to IPv6 at a slower pace than some of the privatenetworks. In a network where most of the core will remain IPv4 only, IPv6VPNs will have to be tunneled over it. Benefits and issues related totunneling are not specific to VPNs, and various mechanisms are reviewed inChapter 3, "Delivering IPv6 Unicast Services," in the section "IPv6 overIPv4 Tunnels.") In an MPLS-enabled network, however, using a similarapproach as 6PE (see Chapter 3, section "IPv6 over 6PE"), IPv6 MPLSVPN could run over an IPv4-based core without the drawbacks of tunneling.Such an implementation of IPv6 VPN is referred to as 6VPE and isdiscussed in the section "BGP-MPLS IPv6 VPNs: A PE-Based VPNSolution."
For a more in-depth study of VPNs, refer to the following books: VPNApplications Guide by David McDysan, and MPLS and VPN Architecturesby Ivan Pepelnjak and Jim Guichard.
Provider-Provisioned VPNs
Provider-provisioned VPNs (PPVPNs) are VPN services operated by theSPs. Table 7-1 illustrates the taxonomy of PPVPN.
Because layer 2 VPNs are transparent to higher-layer protocols, they are applicable to both IPv4 and IPv6.They also prove useful for transporting legacy System Networks Architecture (SNA) NetBIOS and IPXtraffic, for which a layer 3 VPN solution is not available. They offer a quick path for supporting IPv6 VPNs.
CE-Based VPNs
CE-based VPNs can provide layer 2 or layer 3 services. CE routers connect together over the commoninfrastructure by the means of trunks. The trunks can be layer 1 (TDM), layer 2 (virtual circuit), or layer 3 (IPtunnels). The VPN can be operated by the user or the provider. In all cases, they terminate at the customersites. The boundary between the private network and the shared public infrastructure is on the CE router. Anytunneling mechanism can be used to achieve CE-based L3 VPN, such as IPsec, 6to4, or IP-in-IP.
With IPsec, data integrity and confidentiality is guaranteed "end to end" (apart from the fact that there are noguarantees when it comes to security).
Other tunneling mechanisms, such as GRE tunneling, 6to4, or IP-in-IP, can also be used, but these have noneof IPsec's security capabilities, unless of course, you use IPsec to secure them.
L2TP, specified in RFC 2661, is also used as a CE-based L2 VPN protocol.
CE-based VPNs can easily span multiple providers: the CE-to-CE tunnels work as long as there is IPconnectivity.
Routing occurs between customer sites and is transparent to the SP; the customer network is an overlay on topof the provider network, which is used as a transport mechanism. To achieve effective routing, each site has tohave a tunnel to every other site in what is called a fully meshed design. This would result in N(N1)/2 numberof tunnels for N sites. Not only could the number of tunnels result in scalability issues on the routersterminating the tunnels, but the number also results in a huge cost of operating the network. Each time a newsite is added, new tunnels must be created on all the other sites. Typically, some sort of hub-and-spokenetwork is used to work around this problem; however, this workaround might result in suboptimal routing.
QoS is also a problematic area for CE-based VPNs, especially when the VPN crosses multiple SPs. In thiscase, service level agreements (SLAs) are difficult to negotiate. In this respect, PE-based VPNs are better, notbecause they can offer better QoS, but because the provider has already prepared the network for QoS and canoffer this as a value-added service as a part of the PE-based VPN offering.
Part I: Implementing IPv6 Services 245
Part I: Implementing IPv6 Services 245
PE-Based VPNs
PE-based VPN solutions involve the capability of the PE router to separate customer routing policies. Twoapproaches have emerged to achieve this. With the first approach, the physical PE router can be split intodisjointed logical routers, each instance taking care of one VPN. With the second approach, each VPN routingtable is managed independently by a single router exchanging routes between sites. The former is theso-called virtual router approach, whereas the latter is the BGP-MPLS IP VPN approach. You can use bothwith IPv6, but only BGP-MPLS IPv6 VPN has been implemented on Cisco routers.
In the PE-based VPN model, the CE router and the PE router share a common routing protocol and associatedrouting tables. A fraction of the PE is literally a part of the customer network, in charge of exchangingcustomer routes with remote customer sites by peering with remote PEs. CEs never peer directly; instead, theypeer indirectly via PEs. Therefore, to achieve optimal routing, it is sufficient to mesh PEs, which aresignificantly less than the CEs of all customers (a PE can be attached to several customers). If you deployMPLS PE-based VPNs, the data plane is operated independently of the routing plane, so that routing hubs donot result in suboptimal forwarding paths. Because routing uses the Border Gateway Protocol (BGP), it canleverage BGP mechanisms such as route reflectors to limit the number of peerings required.
Addressing Considerations
Regardless of the VPN model deployed, you must define an addressing plan for the VPN, one that allowshosts to communicate within one site, within one VPN (with other sites), and with public resources.
VPN IPv4 sites often use private addressing as defined in RFC 1918 for their addressing plan. Theseaddresses do not need to be registered, and they are not routable on the public network. Whenever a hostwithin a private site needs to access a public domain, it goes through a device exposing a public address on itsbehalf. With IPv4, this can be a Network Address Translator (NAT) or an application proxy.
Given the larger address space available with IPv6, the easiest solution to this problem is to use IPv6 globaladdresses for the private addressing plan.
Another approach is to use unique local addresses (ULAs), described in Chapter 2, "An IPv6 Refresher," inthe section "Unique Local Unicast Address." According to Internet Draft draft-ietf-ipv6-unique-local-addr(Proposed Standard), ULAs are easier to filter at site boundaries based on their scope (well-known prefixstructure). They are also Internet service provider independent and can be used for communications inside of asite without having any permanent or intermittent Internet connectivity.
When a host within a private site needs to access a public domain, it can either go via an IPv6 applicationproxy (such as a web proxy for accessing web pages), which will access the public resource on its behalf witha global routable address, or it can use a public address of its own. In the latter case, if ULAs have beendeployed, the IPv6 host is configured with a routable global address, too. The source address selectionalgorithm, described in Chapter 2, is used to select one or the other based on the destination address.
Security Considerations
The two VPN models approach security in different ways. The goal of the PE-based model is to offer securitysimilar to the layer 2 VPNs it was designed to replace. The CE-based model was designed by the IPsecworking group and focused heavily on all aspects of security from the start.
Table 7-2 compares the security aspects of the two most deployed technologies of each model, IPsec andMPLS.
246 Part I: Implementing IPv6 Services
246 Part I: Implementing IPv6 Services
Table 7-2. Security Comparison Between IPsec and MPLS
Security Feature
IPsec
MPLS
Data confidentiality
Through encryption algorithms
By defining a single path between physical sites.
Data integrity
Through hashing algorithms
Not available, but separate routing lowers the risk of data alteration.
Data availability
None "extra." Relies on Internet transport. Redundancy can be deployed.
Relies on MPLS transport. Label switched path (LSP) can be protected by using private label tables.
Redundancy can be deployed.
You can easily use IPsec to secure remote-access traffic. MPLS VPNs face the challenge of securing thetraffic of a remote user as it traverses the network of an SP other than the one providing the VPN service.Solutions exist to enable the traffic to cross the SP boundaries, but they may entail deployment challenges.You can see examples in the section "Interprovider VPNs" as well as in Chapter 13, "Deploying IPv6 in anMPLS Service Provider Network."
Access to the Internet from a VPN is a challenge because such access can open a door for attackers. However,you can access the Internet from both VPN models, although more easily with IPsec, which does notseparately manage private and public routing tables. In addition, poor implementations or complexconfigurations could easily defeat the best intentions. In that regard, it is important to note that IPsec putsmost of the configuration burden on the CE, whereas for the MPLS VPN, the configuration complexity is onthe PE, which typically is a router with more resources than the CE.
As with all security, it all comes down to whom you trust. MPLS VPNs provide no data confidentiality, andyou have to trust the provider to get the configuration right, so that traffic is not leaked outside the VPN. Inthe IPsec case, you get data confidentiality, but only to the edge of the site. Because traffic inside the site isunencrypted, additional security policies need to be implemented. If communications must be confidential,traffic should be encrypted end to end. In that case, it does not make any difference whether the VPN itselfprovides data confidentiality.
Part I: Implementing IPv6 Services 247
Part I: Implementing IPv6 Services 247
Using IPsec to Implement CE-Based VPNs
IPsec VPNs, as specified in RFC 2401, constitute the most widely deployed example of a CE-based layer 3VPN. An IPsec VPN relies on two protocols to provide secure transport over the IP core backbone.Authentication Header (AH) enables message integrity and authenticity. Encapsulating Security Payload(ESP) headers are inserted in the IP packet to enable encryption and confidentiality. ESP can also providemessage integrity and authenticity, and thus ESP provides a superset of AH's functionality.
Examples of CE-based VPNs range from the remote user connecting into the corporate network to largeenterprises sites being connected together.
Remote Access
The common deployment model is that the remote user runs an IPsec VPN client on his laptop computer,which sets up an IPsec tunnel into a VPN concentrator located at the enterprise. The client's security policycan be controlled on the VPN concentrator. One example of such a policy is to prohibit split tunneling,thereby forcing all traffic to go through the tunnel (split tunneling allows the user to tunnel traffic for certainroutes while forwarding traffic outside the tunnel for others). An alternative is to run the VPN client on thecustomer premises equipment (CPE) router in the telecommuter's home, thereby giving secure access to thecorporation from its whole home network. This model still stands with IPv6, providing that VPN clientsoftware supports IPv6 and an IPv6-enabled VPN concentrator is deployed. At the time of this writing, CiscoVPN concentrators do not support IPv6.
IPsec Tunnel Alternatives
There are alternatives to point-to-point IPsec tunnels. If connecting over an IPv4 network, you can use, forexample, 6to4 combined with BGP tunneling. The control plane is then similar to BGP's use in MPLS-BGP,whereas the transport uses 6to4. In this solution, you do not need a full mesh of tunnels, only a mesh of BGPpeers. By using the same techniques as described in the "Scaling IPv6 VPN" section, you can limit the numberof BGP peers. The CE routers use 6to4 addresses to peer with each other, but the prefixes exchanged can benormal IPv6 prefixes. The downside of this solution is that security is not nearly as good as in the IPsec case,and it is not easy to deploy multicast over a virtual link layer, which is not itself multicast capable. Chapter 3describes BGP tunneling and 6to4 in more detail.
Routing
Although IP tunnels (GRE, IPv6 in IPv4/IPv6) support most IPv6 routing protocols (except IS-IS), IPsec doesnot. The IPv6 routing protocols using IPv6 transport use IPv6 multicast. IPsec supports only unicast.Therefore, a separate tunnel is needed for the routing protocol. This tunnel is then itself tunneled inside IPsecto get the required security. If you ever had a Russian Matryoshka doll, you get the idea.
With the "separate tunnel" solution previously mentioned, you can use any IPv6 routing protocol. You canextend the interior gateway protocol (IGP) running within a site to include the VPN, or you can use a separaterouting protocol between the CEs across the VPN. One example is to run OSPFv3 within the site and iBGPover the CE peerings. Routes would be redistributed between the two.
IPv6 CE-Based VPN deployment
You can deploy IPv6 CE-based VPNs in the same manner as IPv4 CE-based VPNs. If there is an existingtunnel infrastructure, you can deploy IPv6 over it. Both IPv4 and IPv6 can run over an IPsec tunnel
248 Part I: Implementing IPv6 Services
248 Part I: Implementing IPv6 Services
infrastructure that uses IPv4 transport. In the future, when the SP becomes IPv6 capable, you can use IPv6transport for the IPsec tunnels, while still tunneling both versions of the protocol. An example of this scenariois provided in the "Topology Examples" section of this chapter.
BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution
BGP-MPLS VPNs are specified in the Internet Draft draft-ietf-l3vpn-rfc2547bis, by E. Rosen andY. Rekhter. This solution represents an implementation of the PE-based VPN model. Because thistype of VPN technology has become by far the most popular technology for deploying VPN in apeer-to-peer model, the remainder of the chapter focuses on its application to IPv6.
The following terminology is used for the remainder of this chapter:
6VPE router PE router providing BGP-MPLS IPv6 VPN service over an IPv4-based MPLScore. It is basically a VPNv6 PE, dual stack (IPv4+IPv6) that implements 6PE concepts onthe core-facing interfaces.
•
VPNv6 addresses A VPNv6 address is a 24-byte identifier, beginning with an 8-byte routedistinguisher (RD) and ending with a 16-byte IPv6 address. Sometimes it is called an VPNIPv6 address.
•
VPNv6 address family The Address Family Identifier (AFI) identifies a particular networklayer protocol and the Subsequent AFI (SAFI) provides additional information. The AFIIPv6, SAFI VPN (AFI=2, SAFI=128) is referred to as a VPNv6 address family; similarly,AFI IPv4, SAFI VPN is the VPNv4 address family. Sometimes it is called a VPN IPv6address family.
•
VRF (virtual routing and forwarding) A VPN routing and forwarding instance in a PE.• VRF table A routing and a forwarding table associated to a VRF. This is acustomer-specific table, enabling the PE router to maintain independent routing states foreach customer.
•
In principle, no difference exists between IPv4 VPNs, as described in "BGP-MPLS IP VPNs," andIPv6 VPNs, as specified in "BGP-MPLS IP VPN Extension for IPv6 VPN" (Internet Draft,draft-ietf-l3vpn-bgp-ipv6). Similar to IPv4, MP-BGP is the centerpiece of the MPLS VPNv6architecture. It is used to distribute IPv6 routes over the SP backbone, with the same set ofmechanisms to deal with overlapping addresses, redistribution policies, and scalability issues. Eventhough we do not expect overlapping address space in IPv6, addresses are still prepended with anRD. A new Network Layer Reachability Information (NLRI) 3-tuple format <length, IPv6-prefix,label> is defined to distribute these routes using MP-BGP. The extended community attribute(Route-Target) is used to control redistribution of routing information, by tagging exported routesand filtering imported ones. For scalability, you can use route reflectors to concentrate routingpaths, and avoid a full PE mesh. Similar to IPv4, BGP features such as route refresh, automaticroute filtering, and outbound route filtering help reduce the number of routes held in each PE.
The Internet Draft "BGP-MPLS IP VPN Extension for IPv6 VPN" focuses solely on the followingdifferences between IPv4 and IPv6:
Creation of a new MP-BGP VPNv6 address family, and specification of VPNv6 addressformat
•
Specification of a new VPN IPv6 NLRI• Specification of the BGP next-hop encoding in the case of an IPv4-based MPLS core•
Part I: Implementing IPv6 Services 249
Part I: Implementing IPv6 Services 249
A VPNv6 address is a 16-byte IPv6 address, prepended with an 8-byte RD, to form a 24-byteaddress. As in VPN IPv4, the VPNv6 prefix (network portion of the address) is only meaningfulwithin MP-BGP, and only the IPv6 part of this prefix is kept when redistributed into IPv6 routingprotocols.
Example 7-1 shows the VPNv6 prefix 2001:100::/64.
Example 7-1. Showing BGP VPNv6 Address
sa14-72b# show bgp vpnv6 unicast all 2001:100::/64BGP routing table entry for [100:1]2001:100::/64, version 15Paths: (1 available, best #1, table red) Advertised to update-groups: 2001:100::72a (FE80::A8BB:CCFF:FE01:F500) from 2001:100::72a (200.14.14.1) Origin incomplete, metric 0, localpref 100, valid, external, best Extended Community: RT:100:1
Note
The notation RD:IPv4-prefix, used for VPNv4 prefixes, cannot be used for VPNv6 prefixes becauseit conflicts with the IPv6 prefix notation. For instance, 100:1:2001::/64 could be interpreted as anIPv6 prefix or a VPNv6 prefix with an RD of 100:1. For that reason, VPNv6 prefixes use thenotation [RD]IPv6-prefix.
In the latter part of "BGP-MPLS IP VPN Extension for IPv6 VPN" (draft-ietf-l3vpn-bgp-ipv6),transitioning and coexistence aspects are covered, with emphasis on the 6PE approach applied toVPNv6. The main aspects of this approach have been discussed at length in Chapter 3 (in the "IPv6over 6PE" section), and the implications and mechanisms are the same here.
Other aspects of coexistence, in particular interprovider and Carrier Supporting Carrier (CSC)topologies, are specific to BGP-MPLS IPv6 VPN. For instance, the link between AutonomousSystem Boundary Routers (ASBRs) might support IPv4 only, IPv6 only, or both, independently ofthe address family being transported. This creates a new set of variations in the list of cases listed in"BGP/MPLS IP VPNs" (draft-ietf-l3vpn-rfc2547bis) section 10 (Multi-AS backbone).
The "Topology Examples" section of this chapter provides examples of both interprovider topologyand Internet access topology.
Routing Table Segregation
The SP network provides connectivity between "same-customer" sites, while isolating customersfrom each other. The keystone of the PE-based VPN model is the isolation between routing tables,achieved at two levels:
Isolation between customers Customer-specific routing tables (VRF tables) are used on theedge routers. At any particular edge router, one VRF routing table is associated with eachsite connected to that router, and entries from one VRF table do not leak to another, unlessexplicitly configured to do so.
•
Isolation between core and edge routing Provider's routes, used by PE routers to reach eachother over the provider backbone are kept separated from customer's routes. As a matter of
•
250 Part I: Implementing IPv6 Services
250 Part I: Implementing IPv6 Services
fact, most provider core routers (P-routers) only store these routes and never see customerroutes.
To achieve routing segregation, a routing tunnel must be established between PE routers toexchange customer routes. This routing tunnel is transparent to the core routers. This is achievedusing MP-BGP between the PE routers. In addition, a forwarding tunnel must be availablethroughout the provider core network, so that datagrams can be forwarded by P-routers, withoutrequiring the P-routers to keep routing tables for each VPN. In theory, the tunneling mechanismchosen for traffic forwarding could be any of the following kinds: GRE, IPsec, L2TP, MPLS, andso forth. In practice, MPLS has been used for the most part in deployment so far. L2TP has beenspecified for P-networks that do not use MPLS, and it is deployed in few environments. Figure 7-1illustrates how routing segregation is achieved.
Figure 7-1. Routing Tables in BGP-MPLS IPv6 VPN Model
[View full size image]
In Figure 7-1, the following routing tables are being used at PE1:
A set of customer-specific IPv6 routing tables (red and blue) contains customer routes(customer#1 and customer#2, respectively). Each of these routing tables contains routesreceived from the CE routers as well as routes from remote sites in the same VPN. Forexample, the content of table red in node PE1 is shown in Example 7-2.
Example 7-2. IPv6 VRF Table red
PE1#show ipv6 route vrf redIPv6 Routing Table - red - 10 entriesC 2001:100:1:1000::/64 via Serial0/0, directly connectedB 2001:100:1:1000::/56 via 200.14.14.1B 2001:100:1:2000::/56 via 200.10.10.1%Default-IP-Routing-Table, indirectly connected
Note that these customer-specific tables are also referred to as VRF tables.
•
Part I: Implementing IPv6 Services 251
Part I: Implementing IPv6 Services 251
A default routing table that is exclusively used to reach routers inside the provider network.It is an IPv4 table if the MPLS core is IPv4 based, and IPv6 otherwise. For example, thecontent of the default table (IPv4) in node PE1 is shown in Example 7-3.
Example 7-3. IPv4 Default Table
PE1#show ip route 200.10.10.0/32 is subnetted, 1 subnetsi L1 200.10.10.1 [115/30] via 40.1.1.3, Serial1/0 31.0.0.0/24 is subnetted, 1 subnetsi L1 31.1.1.0 [115/30] via 40.1.1.3, Serial1/0 200.11.11.0/32 is subnetted, 1 subnetsC 200.11.11.1 is directly connected, Loopback0
•
A BGP table, which contains entries from all the customer-specific IPv6 routing tables. Anexample of the BGP table in node PE1 is shown in Example 7-4.
Example 7-4. VPNv6 BGP Table
PE1#show bgp vpnv6 unicast all Network Next Hop Metric LocPrf Weight PathRoute Distinguisher: 100:1 (default for vrf red)* 2001:100:1:1000::/562001:100:1:1000::72a0 0 200 ?*> ::0 32768 ?*>i2001:100:1:2000::/56::FFFF:200.10.10.1Route Distinguisher: 200:1 (default for vrf blue)*> 2001:100:2:1000::/56::0 32768 ?*> 2001:100:2:2000::/56::FFFF:200.10.10.10 32768 ?
•
A BGP session is established between edge routers, and entries from the BGP table are carried overthat session. The following steps, illustrated in Figure 7-1, allow route distribution between sites:
1. The CE router (CE1) announces a customer prefix to the provider router (PE1). Although thisentry belongs to the default routing table at the CE, it is installed in a VRF IPv6 table (red) atthe PE. The interface on which these entries are received determines into which table theyshould get installed.
2. PE1 redistributes this entry into its MP-iBGP table, after prefixing it with the RD referencingthe VRF table the entry is coming from (RD 100:1 for entries from table red above).
3. Once in the BGP table, the entry is announced to the BGP peer at PE2.
4. Once installed in the PE2 BGP table, the entry is redistributed into one or more VRF tables,after stripping off the RD. Note that the RD is used solely to distinguish entries in BGP, not asa policy mechanism to determine which entry from which VRF table is to be redistributed inwhich VRF table on the remote PE. Instead, BGP communities (route targets) are used for thatpurpose.
5. From the VRF table, the entry is finally redistributed into the customer site (customer#1,
252 Part I: Implementing IPv6 Services
252 Part I: Implementing IPv6 Services
site#2).
Routing Protocols for BGP-MPLS IPv6 VPN
For those unfamiliar with MPLS-VPN, a good book to start with is MPLS and VPN Architecturesby Ivan Pepelnjak and Jim Guichard. That book provides enough background to appreciate fully thefollowing two sections.
The transition to IPv6 is expected to lead to a long period of coexistence between IPv4 and IPv6.An attractive method for deploying MPLS-VPN IPv6 takes advantage of this coexistence byleveraging an existent MPLS IPv4 core network. This approach, referred to as 6VPE, is similar tothe one described in Chapter 3 in the section "IPv6 over 6PE."
Figure 7-2 lists the most important aspects of the 6VPE architecture.
Figure 7-2. Simple 6VPE Architecture
[View full size image]
The CE routers are connected to the provider's backbone via PE routers. The PE routers areconnected via P-routers. P-routers are unaware of VPN routes, and in the 6VPE case may supportonly IPv4. Only PE routers perform VPN-specific tasks. For 6VPE, the PE routers are dual-stack(IPv4 and IPv6) routers.
The routing component of the VPN operation is divided into core routing and edge routing. Thecore routing, which involves PE routers and P-routers is typically performed by an IPv4 IGP suchas OSPFv2 or IS-IS. In the simple topology illustrated in Figure 7-2, the IGP distributes only routesinternal to the provider's AS. The core routing enables connectivity among P- and PE routers.
Edge routing takes place in two directions: routing between PE pairs and routing between a PE anda CE. The former is achieved via Multiprotocol Internal Border Gateway Protocol (MP-iBGP)using a specific address family (VPNv6). It distributes routes learned from CEs via the PE-CErouting, using appropriate route export policies at the ingress PE router and appropriate route import
Part I: Implementing IPv6 Services 253
Part I: Implementing IPv6 Services 253
policies at the egress PE router.
Routing between the CE and its PE is achieved using a routing protocol that is VRF aware. OnCisco routers, at the time of this writing, only static routes, and eBGP, are VRF aware. In theexample shown in Figure 7-2, eBGP is used between the CE (CE1) and the PE (PE1). At the sametime, the CE runs an IPv6 IGPfor instance, OSPFv3 or IS-IS for IPv6within the VPN site (site1).The CE redistributes IGP routes into MP-eBGP address family IPv6. At the PE, these routes areinstalled in the VRF red, and forwarded to remote PEs (PE2), according to export policies definedfor this VRF.
BGP Next Hop
When announcing a prefix (using the MP_REACH_NLRI attribute), MP-BGP running on one PEinserts a BGP next hop in the update message sent to a remote PE. This next hop is eitherpropagated from the received update (for instance, if the PE is a route reflector), or it is the addressof the PE sending the update message (egress PE). For the VPNv6 address family, it has to be aVPNv6 address, regardless of the nature of the network between the PE speakers. Because the RDhas no significance (the address is not part of any VPN), it is just set to zero. If the providernetwork is a native IPv6 network, the remaining part of the next hop is the IPv6 address of theegress PE. Otherwise, it is an IPv4 address, masqueraded into an IPv6-mapped address(::FFFF:IPv4-address).
Example 7-5 illustrates the case of a 6VPE next hop.
Example 7-5. VPNv6 Configuration Example Using IPv4 Next Hop
By default, the next hop advertised is the VPNv6 address:
[0:0]2001:100:1:1000:0:0:0:72b
Note that it is a 192-bit address in the following form:
[RD]IPv6-address.
Even though current Cisco routers do not provide support for LDPv6, the preceding example canstill be deployed, in the interprovider VPN case, when the two providers exchange VPNv6 routesover an IPv6 link using MP-eBGP. See the section "Interprovider VPNs" later in the chapter fordetails.
When the BGP VPNv6 peers share a common subnet, the MP_REACH_NLRI attribute contains alink-local address next hop, in addition to the global-address next hop. This will typically happen ininter-AS topology, scenario B (see the section "Interprovider VPNs" in the topology examples laterin this chapter), when AS boundary routers are facing each other. In that case, the link-local nexthop is used locally, and the global next hop is eventually re-advertised by BGP.
Building the Label Stack
Figure 7-3 shows how the label stack is computed by combining information obtained from routingand label distribution protocols.
Figure 7-3. Building the Label Stack for 6VPE
[View full size image]
Part I: Implementing IPv6 Services 255
Part I: Implementing IPv6 Services 255
The idea is that ingress PE router (PE2) obtains two separate labels, and combines them into a labelstack, which it can impose when forwarding traffic to a given VPN IPv6 destination. Each of theselabels is learned via a specific mechanism, and has a specific role in the LSP. The outer label (Lc inFigure 7-3) is used to label switch packets from the ingress PE (PE2) to the egress PE (PE1). Thislabel is obtained through a label distribution protocol, such as Label Distribution Protocol (LDP) orReSerVation Protocol (RSVP). The inner label (L1 in Figure 7-3) is used to reach the appropriateCE router (CE1) from the egress PE (PE1). MP-iBGP distributes this label.
The BGP "next hop" (described in the previous section) is the keystone for building the label stack,because it is used to tie the inner and the outer label together at the ingress PE. A recursion isperformed to combine the two labels: the prefix (net1) is reachable via PE1, using label L1, andPE1 itself is reachable via P2, using label Lc. This recursion takes place as soon as labels areavailable, and the resulting label stack (Lc+L1) is stored in the Forwarding Information Base (FIB).
In the case of 6VPE (IPv6 MPLS VPN over an IPv4 core), a cross-table resolution (IPv6, thenIPv4) is performed to build the label stack, just like for 6PE.
The outer label and inner label are sometimes referred to as "BGP next hop" label and VPN label,respectively.
Note
There is no mechanism to force MP-iBGP to follow the same labeled switching path as IPv6 traffic.In fact, for scalability reasons, the MP-iBGP control traffic is moved away from the LabelSwitching Path and directed to concentrators such as route reflectors (see the "Scaling IPv6 VPN"section later in the chapter). MP-iBGP control traffic can take advantage of the labeled paths butdoes not need to. On the other hand, IPv6 traffic between VPN sites requires labeled paths totraverse P-routers (because these are unaware of IPv6 addresses).
256 Part I: Implementing IPv6 Services
256 Part I: Implementing IPv6 Services
This is a fundamental difference from other tunneling techniques, in which the routing updates aresent inside the forwarding tunnel. Should the tunnel break, these updates stop, and edge routersremove corresponding entries from their routing table.
With VPNv6 (and VPNv4), the labeled path may be broken, while the path between PEs is stillusable. The MP-iBGP session will keep exchanging IPv6 routes even though packets forcorresponding destinations will not be able to traverse the core network. The result is that the trafficis black holed.
Forwarding in BGP-MPLS IPv6 VPN
Upon receiving IPv6 traffic from one customer site, the ingress PE router (PE2) will MPLS tunnelIPv6 VPN packets over the backbone toward the egress PE router (PE1) identified as the BGP nexthop. Figure 7-4 shows the forwarding tables (IPv6 and MPLS) built as the result of the labeldistribution across P- and PE routers.
Figure 7-4. MPLS Forwarding Tables
[View full size image]
In Figure 7-4, the network net1 (2001:100:1:1000::/56) is announced by iBGP from PE1 to PE2,with label L1=24. At the same time, LDP is announcing PE1 reachability to PE2 with label Lc=18.The complete label stack (18, 24) for reaching net1 is shown in Example 7-7, via the show ipv6 cefvrf red command. The label forwarding table at routers P2, P1, and PE1 is shown in Example 7-7via the show mpls forwarding command.
Label Label interface16 Pop Label 200.11.11.1/32 Et0/0 40.1.1.2PE1#show mpls forwardingLocal Outgoing Prefix Outgoing Next HopLabel Label interface24 No Label 2001:100:1:1000::/56[V] Et0/0 FE80::A8BB:CCFF:FE01:F500
Figure 7-5 shows the MPLS encapsulation taking place at the ingress PE, and the label swappingoccurring at P-routers.
Figure 7-5. MPLS VPNv6 Forwarding Operation
[View full size image]
In Figure 7-5, an IPv6 packet for 2001:100:1:1000::1 is being encapsulated at PE2 and sent to PE1,via P2 and P1. MPLS packet traces are enabled (using the debug mpls packet command) at P2, P1,and PE1, and you can see the label stack being received and transmitted at each router.
Under normal operation, a P-router along the forwarding path does not look inside the framebeyond the first label. It either swaps the incoming label with an outgoing one, or removes it (forinstance, P1 in Figure 7-5) if the next router is a PE. The latter action is called penultimate hoppopping. The remaining label (L1 in the example) has a side function (other than identifying theegress PE interface toward the customer site). It also hides the protocol version (IPv6) from theP-router, which would need to otherwise forward an IPv6 packet. The following output, shown inExample 7-8, via debug mpls packet enabled all along the LSP, illustrates the label swappinghappening at each router.
Example 7-8. Tracing MPLS IPv6 Packets Along the LSP
You may have noticed that a P-router is ignorant about IPv6 VPN routes. In fact, with 6VPE, it isan IPv6 ignoramus. The IPv6 header remains hidden under one or more MPLS labels. Aninteresting issue arises when the P-router receives an MPLS-encapsulated IPv6 packet that cannotbe delivered. This scenario can occur if the Time To Live (TTL) in the label expires or if themaximum transmission unit (MTU) is exceeded. The P-router then has to expose the IPv6 header,build an ICMPv6 message, and send it to the source of the original packet. At a minimum, thisprocess requires the P-router to be capable of building an ICMPv6 message; otherwise, it wouldhave to drop silently the undeliverable MPLS-encapsulated IPv6 packet. However, two more issuesmust be solved:
The IPv6 source address found in the packet belongs to a VPN unknown to the P-router andcannot be IPv6 routed from there.
•
The P-router must select an IPv6 source address to use in its ICMPv6 message.•
RFC 3032 describes in section 2.3.2 ("Tunneling Private Addresses through a Public Backbone") amechanism applicable to IPv6 similar to IPv4. The original undeliverable packet carried a labelstack that can be imposed to the ICMPv6 message, to enable it to reach the egress PE. The egressPE knows how to reach the private IPv6 network so it can route the packet to the destination.Amazingly, in most cases, the ICMPv6 datagram turns back and traverses the MPLS backboneagain before reaching its destination.
For selecting an IPv6 source address, source address selection can be used. However, the P-routermay not have any IPv6 address, and even when it has one, it does not belong to the private space ofthe destination of the packet. In that case, it sets the source address to the v4-mapped address builtfrom the v4 address configured on the incoming interface. See an example of such ICMPv6 packetin the section "Hub and Spoke."
VRF Concepts and IPv6 Implementation
VRF concepts are discussed at length in MPLS and VPN Architectures by Ivan Pepelnjak and JimGuichard. However, with the introduction of IPv6 VPNs, some of these concepts deserveclarification. A VRF is defined as a virtual routing and forwarding entity, which ties up to a private"customer-specific" routing and forwarding table (RIB and FIB, respectively).
One could conclude that, since IPv6 is carrying its own routing and forwarding tables, there shouldbe distinct IPv4 and IPv6 VRFs. However, although IPv4 and IPv6 routing tables are indeeddistinct, it is convenient, from a deployment standpoint to share the same VRF between the twoprotocols for a given customer.
VPNv6 customers are likely to be existing VPNv4 customers, either deploying dual-stack hosts androuters, or shadowing some of their IPv4 infrastructure with IPv6 nodes. Several deploymentmodels are possible. Some customers use separate logical interfaces for IPv4 and IPv6, and defineseparate VRFs on each. Although this approach provides flexibility to configure separate policiesfor IPv4 and IPv6, it also prevents sharing the same policy. Another more attractive model is tokeep one single VRF on the PE-CE interface, and enable it for IPv4, IPv6, or both. It is thenpossible to define common or separate policies for each IP version. With this model, a VRF is betterdefined as the set of tables, interfaces, and policies found at the PE, privately used by sites of aparticular VPN connected to this PE.
Part I: Implementing IPv6 Services 259
Part I: Implementing IPv6 Services 259
Figure 7-6 shows the latter model, where VRF red is enabled for both IPv4 and IPv6, and isassociated with two interfaces (IF1, IF2), two sets of tables (IPv4 Routing and Forwarding tablesand IPv6 Routing and Forwarding tables), and a set of common or distinct policies. Such a VRFthat is defined for both IPv4 and IPv6 will be referred to as multiprotocol VRF. Examples of suchmultiprotocol VRFs are provided in the "Dual-Stack VPNs" section.
Figure 7-6. Multiprotocol VRF
[View full size image]
Configuring a VRF
Configuring a VRF for IPv6 is no different from configuring a VRF for IPv4. In fact, it could havebeen exactly the same, if IPv4 and IPv6 VRFs had been kept separate. For the reasons mentionedpreviously, a VRF is an address-family-independent object that can be enabled and configured foreach of the supported address families. Configuring a VRF includes three steps:
1. Configuring the AF-independent part of the VRF
2. Enabling and configuring IPv4 for the VRF
3. Enabling and configuring IPv6 for the VRF
In Step 1, a VRF is first given a name and an RD. This is achieved using the command vrfdefinition <name>, and then rd <ASN:nn>.
Note
Interestingly, the RD is configured outside the context of the address family. A careful reader mightwonder why this is the case, when the RD is used to distinguish overlapping addresses within thecontext of a particular BGP address family. Having separate RDs for IPv4 VPN addresses and IPv6VPN addresses should not matter. Indeed it does not. And the same or different RDs for twodifferent address families do not make any difference. On Cisco routers, it was decided to keep theRDs the same to simplify configuration and VPN management.
260 Part I: Implementing IPv6 Services
260 Part I: Implementing IPv6 Services
Still, in Step 1 of the configurationthat is, outside any address family contextyou can configurepolicies in common between IPv4 and IPv6. This is basically shared route targets (import andexport). This feature proves especially useful in a migration scenario, where IPv4 policies alreadyare configured, and IPv6 policies should be the same as the IPv4 ones.
In Step 2 and Step 3, you can configure and enable each address family separately. The addressfamily configuration includes the usual import and export policies, maximum number of routes inthe VRF, and so on. Note that the policies (route map and route target) entered at this level overrideglobal policies specified in the address-family-independent part.
Example 7-9 is a simple example of enabling and configuring each address family separately.
Example 7-9. Multiprotocol VRF Configuration Example
To specify which interface belongs to which VRF, you must use the interface command vrfforwarding <name>. The meaning and effect of this command on an interface is the same as the ipvrf forwarding command used for VPNv4, with the difference that it is multiprotocol. An interfacecannot belong to more than one VRF. When the interface is bound to a VRF, previously configuredaddresses (IPv4 and IPv6) are removed and they must be reconfigured. Example 7-10 is an exampleof the interface configuration.
Example 7-10. Multiprotocol VRF Configuration on the Interface
ipv6 address 2001:100:1:1000::72b/64 ip address 200.11.11.1 255.255.255.0
VRF-Aware Router Commands
Many of the commands to display or troubleshoot Cisco routers are VRF aware for IPv6, similar toIPv4. Here are a few key examples:
Part I: Implementing IPv6 Services 261
Part I: Implementing IPv6 Services 261
To show the routing table:
show ipv6 route vrf red
•
To show the forwarding table:
show ipv6 cef vrf red
•
A number of applications available at the router (PE) have to be VRF aware to enable the operatorto use them within the scope of a particular VRF. Two notations can be used, either vrf <name> or%<name> after the address, referencing VRF tables in the context of an IPv6 address.
Here is the list of such applications:
Ping
ping vrf red 2001:100:1:1000::72eping 2001:100:1:1000::72e%red
•
Traceroute
traceroute vrf red 2001:100:1:1000::72etraceroute 2001:100:1:1000::72e%red
•
Telnet
telnet /vrf red 2001:100:1:1000::72etelnet 2001:100:1:1000::72e%red
•
Scaling IPv6 VPNs
PE-based VPNs such as BGP-MPLS IPv6 VPNs scale better than CE-based VPNs. A networkdesigner still has to consider scaling when designing the network. Scaling a BGP-MPLS IPv6 VPNis similar to scaling a BGP-MPLS IPv4 VPN. The following points need to be considered:
Routing table size, including the size of VRF tables, and the size of BGP tables• Number of BGP sessions, growing as the square of the number of PEs•
The first issue arises at PEs handling many customer sites. Not only do these PEs have to deal withone routing and one forwarding table per connected customer, but their BGP tables, which sum upall entries from individual VRFs, are growing accordingly. Another scalability issue arises when thenumber of PEs in the provider network grows beyond a certain level. Assuming that a significantnumber of sites belonging to the same VPN are spread over many PEs, the number of MP-BGPsessions may rapidly become prohibitive: (N 1) * N/2, where N is the number of PEs.
Identical issues faced by both IPv6 and IPv4 tend to drive similar solutions. The most common onesare the following:
Route refresh and automatic route filtering Limit the size of routing tables because onlyroutes imported into a VRF are kept locally. When the import policy changes, a routerefresh can be sent to query a retransmission of routing updates.
•
Outbound route filtering (ORF) Allows the ingress PE to advertise filters to the egress PEso that updates are not unnecessarily sent over the network.
•
Route reflectors These are iBGP peers that propagate iBGP routes learned from other iBGPpeers. Route reflectors are used to concentrate the iBGP sessions.
•
The following example illustrates the route refresh received at PE2, in a situation where PE1exports routes with route target 500:1 and PE2 imports it. The initial BGP table at PE2 is shown in
262 Part I: Implementing IPv6 Services
262 Part I: Implementing IPv6 Services
Example 7-11.
Example 7-11. BGP Table Before the Route Refresh
PE2#show bgp vpnv6 unicast all Network Next HopRoute Distinguisher: 100:1 (default for vrf red)*>i2001:100:1:1000::/56 ::FFFF:200.11.11.1*> 2001:100:1:1000::/64 ::Route Distinguisher: 200:1 (default for vrf blue)*>i2001:100:1:2000::/56 ::FFFF:200.11.11.1*> 2001:100:1:2000::/64 ::
In one VRF, entries with a route target 500:1 are set up for import as shown here:
PE2#show bgp vpnv6 unicast all Network Next HopRoute Distinguisher: 100:1 (default for vrf red)*>i2001:100:1:1000::/56 ::FFFF:200.11.11.1*> 2001:100:1:1000::/64 ::*>i2001:100:1:5000::/56 ::FFFF:200.11.11.1Route Distinguisher: 200:1 (default for vrf blue)*>i2001:100:1:2000::/56 ::FFFF:200.11.11.1*> 2001:100:1:2000::/64 ::Route Distinguisher: 500:1*>i2001:100:1:5000::/56 ::FFFF:200.11.11.1
The route-refresh feature is negotiated during the initial BGP peer negotiation. Example 7-13 showshow to display it.
Example 7-13. Route-Refresh Capability Display
PE2#show bgp vpnv6 unicast all neighborsBGP neighbor is 200.11.11.1, remote AS 100, internal link
Part I: Implementing IPv6 Services 263
Part I: Implementing IPv6 Services 263
BGP version 4, remote router ID 200.11.11.1 BGP state = Established, up for 2d17h Last read 00:00:55, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Address family VPNv6 Unicast: advertised and received
Note
Although route reflectors solve the problem of the explosion of BGP sessions, they tend to make theissue of BGP table size worse. Because the route reflectors do not have any VRFs themselves, theycannot filter routes based on import policies. Because they can store BGP routes for many clientsPEs, they tend to accumulate routes from many sites. Finally, they can easily become a single pointof failure for the sessions that they reflect. To alleviate these issues, the design of the network usingroute reflectors must be carefully studied. Several route reflectors are generally used in parallel,sometimes in a hierarchy. And of course, the provider backbone topology may be partitioned insuch a way that a given route reflector serves only a limited numbers of PEs.
MP-BGP for VPNv6 at a Glance
As mentioned earlier in the chapter, MP-BGP is a centerpiece of the MPLS-VPNv6 architecture.Table 7-3 summarizes the list of BGP features applicable to VPNv6 in various deploymentscenarios.
Table 7-3. BGP VPNv6 FeaturesMP-BGP Feature DescriptionBase IPv6 MPLS VPN functionality Support of VRF for IPv6.
Handling of labeled IPv6VPN address family inMP-BGP.
EBGP as PE-CE routing protocol eBGP can run on a VRFbasis.
Source of origin (SOO) SOO is used to preventrouting loops in case ofdual-homed CE.
ASN override If a global ASN is specified,BGP automatically replacesthe ASN with a uniquenumber to ensure the site isuniquely identified.
Allow-AS-in
264 Part I: Implementing IPv6 Services
264 Part I: Implementing IPv6 Services
The hub-and-spoke topologywidely deployed withVPNv4 is equally usefulwith VPNv6. This featureenables BGP speakers toaccept updates that containtheir own ASN in theAS_PATH attribute.
BGP prefix list filtering Filter MP-BGP IPv6advertisement based onconfigured IPv6 prefix.
BGP AS path filtering Filter MP-BGP IPv6advertisement based onconfigured AS path.
BGP max prefix Upper limit on the numberof BGP routes learned froma given CE.
BGP route refresh Using this technique, aMP-BGP speaker (PE/CE)can request another BGPspeaker to resend itsMP-BGP updates.
Route target rewrite at AS boundary Allows rewrite of RT valuesat AS boundary for inter-ASoperations.
BGP multipath Support eBGP multipath,iBGP multipath, eiBGPmultipath andDMZ-link-bandwidth-basedload balancing.
Topology Examples
This section provides VPNv6 topology examples and relevant configurations. The first one is a CE-basedVPNv6 example; the remaining examples are PE-based BGP-MPLS IPv6 VPN topologies, starting with abasic topology, then moving forward to more complex cases such as dual-stack VPNs, route reflectors, huband spoke, Internet access, and inter-AS.
Using IPsec to Secure IPv6 over an IPv4 Tunnel
In this example, a preexisting IPv4 IPsec tunnel is used to create an IPv6 VPN. The tunnel type used is anIPv6 manually configured. Figure 7-7 illustrates the relevant topology.
Figure 7-7. Multiprotocol VRF
[View full size image]
Part I: Implementing IPv6 Services 265
Part I: Implementing IPv6 Services 265
Example 7-14 shows CE1's (Figure 7-7) configuration. The key elements of the configuration are preceded byhighlighted comments.
Example 7-14. IPv6 over IPv4 IPsec Tunnel Configuration
hostname CE1ipv6 unicast-routingipv6 cef!IPsec configuration for the IPv4 tunnelcrypto isakmp policy 1 authentication pre-share group 2crypto isakmp key SECRET address 10.1.1.2crypto ipsec transform-set IPSEC ah-sha-hmac esp-des!crypto map IPV6TUNNEL 10 ipsec-isakmp set peer 9.100.17.1 set transform-set IPSEC match address 100!!Configuration of the IPv6 over ipv4 manual tunnelinterface Tunnel0 no ip address ipv6 address 2001:100:2:1000::72a tunnel source Serial0/0 tunnel destination 9.200.17.1 tunnel mode ipv6ip crypto map IPV6TUNNEL!interface Loopback0 ip address 200.14.14.1. 255.255.255.0 !interface Serial0/0 ip address 9.100.27.1 255.255.255.0 crypto map IPV6TUNNEL!
266 Part I: Implementing IPv6 Services
266 Part I: Implementing IPv6 Services
router bgp 1001 neighbor 2001:100:2:1000::72e remote-as 1001 neighbor 9.100.27.2 remote-as 100!! Configure eBGP-IPv4 to peer with the SP address-family ipv4 neighbor 9.100.27.2 activate!! Configure an iBGP-IPv6 routing protocol over the IPsec tunnel address-family ipv6 neighbor 2001:100:2:1000::72e activate network 2001:100:1::1000::/56!!Configure an extended IP access_list to allow IPv6 trafficaccess-list 100 permit 41 host 9.100.27.1 host 9.100.17.1
Basic MPLS VPNv6 Topology
The basic MPLS VPNv6 topology corresponds to an SP connecting two customer sites over its MPLSbackbone. Figure 7-8 shows the steps necessary to design and configure the MPLS IPv6 VPN in the providernetwork.
Figure 7-8. Steps for Configuring the Provider Routers to Enable MPLS VPNv6
[View full size image]
Step 1 focuses on configuring the core MPLS network. This is not needed if the core network already runsMPLS to provide VPNv4 service. For details on how to set up an MPLS network, refer to the book MPLS andVPN Architectures.
Step 2 is driven by the customer needs and requirements. Typically, a new customer triggers the design andconfiguration of one or more VRFs per PE routers facing customer sites. The VRF configuration is essentiallya matter of network design, similar to what is involved in configuring VRFs for VPNv4. VRF design is an
Part I: Implementing IPv6 Services 267
Part I: Implementing IPv6 Services 267
important part of a migration scenario for those SPs that want to offer a VPNv6 service to their VPNv4enterprise customers. Dual-stack VPNs are covered in a subsequent topology example, and the migrationscenario is studied in detail in Chapter 13.
Figure 7-9 shows a basic VRF configuration, where each PE (PE1 and PE2) is attached to two sites, and threeVPNs are designed (VPN-A, VPN-B and VPN-C).
Figure 7-9. Basic VRF Configuration
[View full size image]
Step 3 involves peering the PEs together. In the simple case, this is accomplished by a direct PE-PE peering.More often, however, this is done via one or more route reflectors. In the following example, the MPLS corenetwork is IPv4 based, and the iBGP peer endpoints are IPv4 loopback (/32) addresses, configured at each PEand distributed by the IGP (OSPF, for instance) inside the provider network. Example 7-15 illustrates therelevant configuration at PE1 (Figure 7-9).
Step 4 involves configuring routing between the PE and the CE. The simplest option is to configure staticroutes on the PE, using the ipv6 route command. With this command, you have the option of specifying theVRF in which it applies, as well as the next hop. You have several options when choosing the next hop:
A VRF interface:•
268 Part I: Implementing IPv6 Services
268 Part I: Implementing IPv6 Services
ipv6 route vrf site1 2001:100:1:1000::/56 serial 0/0
A next -hop address in the same VRF as the route being configured:
Another option is to use eBGP between the PE and the CE. This option is attractive because all routes learnedfrom the PE are automatically redistributed to remote PEs and then to CEs participating in a given VPN. Inthe example shown in Figure 7-9, with four sites and three VPNs (VPN-A, VPN-B and VPN-C), you mustconfigure the address family IPv6 for each VRF (site1 and site2 at PE1, site3 and site4 at PE2). Example 7-17illustrates BGP configuration on PE1.
Along with the provider network configuration, the CE routers must be configured. From the CE routers'standpoint, the BGP configuration is a standard eBGP configuration, with no VRF reference.
The CE routers also participate in the site routing, and are therefore configured with an IPv6 IGP or staticroutes, and route redistribution between this IGP and eBGP.
Example 7-18 illustrates the corresponding eBGP configuration on CE1 at site1.
Dual-stack VPNs are likely to be predominant in many of the MPLS IPv6 VPN deployment scenarios. Asdefined earlier, a dual-stack VPN connects IPv4-enabled sites together and IPv6-enabled sites together. In atypical deployment scenario, an MPLS SP will have to enable IPv6 on already-deployed IPv4 VPNs becauseexisting customers will have migrated some or all of their sites to dual stack (IPv4 and IPv6). In such ascenario, the following provisioning steps must be taken:
1. By the customer: Migrate site (or part of it) to dual stack, and configure CE-PE interface with IPv6.
2. By the SP: Migrate PE routers to dual stack, migrate existing IPv4 VRFs to dual-stack VRF (includingspecific IPv6 VRF policies configuration if any), and configure PE-CE interface with IPv6.
3. By the SP: Enable MP-BGP VPNv6 address family between PE pairs connecting IPv6-enabled sites.
Figure 7-10 shows the topology of a dual-stack VPN.
Figure 7-10. Dual-Stack VPN
[View full size image]
Example 7-19 illustrates the BGP configuration of a dual-stack VPN (IPv6-related configuration highlighted).
Note that no bgp default route-target filter command is necessary on the route reflector, because it does notmaintain a VRF table (unless it is also a regular PE), and would not keep any entry otherwise, as described inthe "Scaling IPv6 VPN" section.
Another remarkable element of the preceding configuration is that neither the IPv6 address nor IPv6 routingprotocol need to be configured at the route reflector, if the SP chooses to deploy it in an IPv4-based backbone(6VPE). The only IPv6 configuration is in the VPNv6 address family under the BGP router configuration. It isstill required to enable the address family, however, because route reflection is on a per-AFI/SAFI basis.
Hub and Spoke
Hub-and-spoke topology is one of the most widely deployed network topologies with VPNv4, and there is noreason why it should not be the same with VPNv6. Large corporations, with multiple sites distributed acrossthe SP backbone, may want to centralize services such as Internet access, firewalls, server farms, and so on.To achieve this, a hub site is deployed with all the other sites forwarding traffic to it. Figure 7-12 shows thistopology.
272 Part I: Implementing IPv6 Services
272 Part I: Implementing IPv6 Services
Figure 7-12. Hub-and-Spoke Topology
[View full size image]
Example 7-22 illustrates the BGP configuration of the Paris PE hub router.
Example 7-22. BGP VPNv6 Hub-and-Spoke Configuration Example
!Peering to each spoke siteaddress-family vpnv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 send-community extended neighbor 200.17.17.1 activate
neighbor 200.17.17.1 send-community extended!Peering to Paris central site CE hub address-family ipv6 vrf red-spoke neighbor 2001:2006::16 remote-as 400 neighbor 2001:2006::16 activate neighbor 2001:2006::16 allowas-in 2!Peering to Paris central site CE spoke address-family ipv6 vrf red-hub neighbor 2001:2005::15 remote-as 400 neighbor 2001:2005::15 activate neighbor 2001:2005::15 allowas-in 2
Part I: Implementing IPv6 Services 273
Part I: Implementing IPv6 Services 273
As shown in Example 7-23, a traceroute command, initiated at one of the spoke sites (London-CE), shows thepath used by traffic between spoke sites (the hops are highlighted).
Example 7-23. Traceroute Output Throughout the Hub-and-Spoke Topology
Note that P-routers have not been configured with an IPv6 address and must use an IPv4-mapped address(::FFFF:42.1.1, in this example) to source their ICMPv6 "time-exceeded" messages.
Internet Access
Most VPN sites require access to the Internet. Internet Draft draft-ietf-l3vpn-rfc2547bis describes in section11 a set of models for enabling VPN access to the Internet. All these models (1 to 4) apply to IPv6 VPNs, too.Some are straightforward, such as model 1, in which an interface is used by the CE to connect to the Internetand a different one to connect to the VRF. In model 4 of section 11, all Internet routes are redistributed intothe VRF. This approach has the disadvantage of requiring the Internet routes to be replicated in each VRF.
In the case of model 3, a static route is inserted into the VRF table, with a next hop that points to the Internetgateway, found in the IPv6 default table. Figure 7-13 shows a scenario in which Internet access is provided tothe customer in VRF red based on model 3.
Figure 7-13. Internet Access Topology
[View full size image]
274 Part I: Implementing IPv6 Services
274 Part I: Implementing IPv6 Services
For outbound traffic, the default route configured in the VRF table (red) at PE1 directs traffic for destinationsoutside the VPN to the Internet gateway. Example 7-24 shows PE1's relevant configuration in this scenario.
Example 7-24. Internet Access: (PE ) Static Route to Internet Gateway
PE1#show runningipv6 route vrf red ::/0 2001:BEEF:14::1 nexthop-vrf defaultPE1#show ipv6 route vrf redS ::/0 [1/0] via 2001:BEEF:14::1%defaultThe next hop (2001:BEEF:14::1) is in the default routing table:PE1#show ipv6 routeB 2001:BEEF:14::1/128 [200/0] via 200.14.14.1%Default-IP-Routing-Table, indirectly connected
It is expected that this next hop has been advertised by the Internet gateway (for instance, over MP-iBGP),based on the configuration in Example 7-25.
Example 7-25. Internet Access: (Internet Gateway) BGP Configuration
For inbound traffic, a route must exist at the Internet gateway to direct the traffic for customer site (site1 inFigure 7-13) via its PE of attachment (PE1 above). Assuming that site1 global prefix is 2001:100:1:1000::/64,the following route in Example 7-26 should be configured on the Internet gateway.
Part I: Implementing IPv6 Services 275
Part I: Implementing IPv6 Services 275
Example 7-26. Internet Access: (Internet Gateway) Route to the PE
This route can be distributed by PE1, via MP-iBGP (IPv6 address family), so no specific configuration needsto be done on per-VPN PE basis at the Internet gateway. Nevertheless, for inbound traffic at PE1, a route mustexist in the default table, for site1 global prefix (2001:100:1:1000::/64), pointing to site1 VRF.
Example 7-27. Internet Access: (PE) Route to Customer Site
Example 7-28. Internet Access: (PE) BGP Configuration Example
router bgp 100! Peering with remote VPN site address-family vpnv6 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended! Peering with internet Gateway address-family ipv6 neighbor 200.14.14.1 activate neighbor 200.14.14.1 send-label network 2001:100:1:1000::/56! Peering with local VPN site address-family ipv6 vrf red neighbor 2001:100:1:1000::72a remote-as 200 neighbor 2001:100:1:1000::72a activate
Interprovider VPNs
The challenge with interprovider VPNs is similar for IPv6 and IPv4, assuming IPv6 is deployed everywhereIPv4 is. That, however, is not the situation today.
In IPv6 deployments crossing AS boundaries, providers have to pick up a peering model. Figure 7-14 showsthe interprovider scenarios (A, B, and C, specified in draft-ietf-l3vpn-rfc2547bis, section 10) in the VPNv6case.
276 Part I: Implementing IPv6 Services
276 Part I: Implementing IPv6 Services
Figure 7-14. Interprovider Scenarios
[View full size image]
Depending on the network protocol used between ASBRs, the three scenarios described indraft-ietf-l3vpn-rfc2547bis, section 10, can face several implementation options. For instance, scenario B,which suggests an MP-eBGP-VPNv6 peering between ASBRs, could use an IPv6 link, or an IPv4 link. Thefollowing example illustrates these two cases. If the peering between ASBRs is performed over an IPv4 link,the BGP configuration on ASBR1 is as shown in Example 7-29.
Example 7-29. Inter-AS BGP Configuration, Scenario B, ASBRs Peering over IPv4
router bgp 1001 no bgp default ipv4-unicast no bgp default route-target filter neighbor 40.1.1.1 remote-as 1002 neighbor 200.11.11.1 remote-as 1001 neighbor 200.11.11.1 update-source Loopback1 ! address-family vpnv6!Peering to ASBR2 over an IPv4 link neighbor 40.1.1.1 activate neighbor 40.1.1.1 send-community extended
Part I: Implementing IPv6 Services 277
Part I: Implementing IPv6 Services 277
!Peering to PE1 over an IPv4 link neighbor 200.11.11.1 activate neighbor 200.11.11.1 next-hop-self neighbor 200.11.11.1 send-community extended
If the peering between ASBRs is performed over an IPv6 link, the BGP configuration on ASBR1 is as shownin Example 7-30.
Example 7-30. Inter-AS BGP Configuration, Scenario B, ASBRs Peering over IPv6
router bgp 1001neighbor 2001:101::72d remote-as 1002! address-family vpnv6!Peering to ASBR2 over an IPv6 link neighbor 2001:101::72d activate neighbor 2001:101::72d send-community extended
In inter-AS scenario C, multihop MP-eBGP redistributes VPNv6 routes across route reflectors in differentautonomous systems. Labeled IPv4 routes to the PEs (in the 6VPE case) need to be advertised across ASBRsso that a complete LSP is set up end to end. Figure 7-15 shows inter-AS scenario C, both routing andforwarding paths.
Figure 7-15. Inter-AS Scenario C
[View full size image]
The label stack computed at ingress PE (PE2) contains the following labels:
Label (Ld) to reach the first P-router in the same AS, and get to the ASBR (ASBR2)• Label (L3) to traverse the AS boundary as a labeled packet• Label (L1) to be switched at egress PE (PE1) to the VRF interface•
278 Part I: Implementing IPv6 Services
278 Part I: Implementing IPv6 Services
On PE1, you can display the label stack imposed by the forwarding plane (CEF) to reach a destination(2001::2::1) located in remote VRF blue, as shown in Example 7-31.
Example 7-31. Inter-AS: Example of Three-Label Stack at the PE (Scenario C)
In Example 7-31, the values of labels Ld, L3, L1 are 20, 19, 22.
The commands in the following examples highlight the origin of each label.
Example 7-32 is used to display to bottom label, L1 (22), used to identify the VRF interface at PE2.
Example 7-32. Inter-AS: Looking at Bottom (BGP VPNv6) Label
PE1#show bgp vpnv6 uni all 2001:201::/64BGP routing table entry for [200:1]2001:201::/64, version 4Paths: (1 available, best #1, table blue) Not advertised to any peer 200 65502 ::FFFF:7.7.7.7 (metric 20) from 2.2.2.2 (2.2.2.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:200:1, mpls labels in/out nolabel/22
•
Example 7-33 is used to display the middle label, L3 (19), used to traverse the autonomous systemboundary.
Example 7-33. Inter-AS: Looking at Middle (BGP IPv4) Label
PE1#show bgp ipv4 unicast 7.7.7.7BGP routing table entry for 7.7.7.7/32, version 10Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 200 90.1.1.2 (metric 20) from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 3.3.3.3, Cluster list: 2.2.2.2, mpls labels in/out nolabel/19
•
Example 7-34 is used to display to top label, Ld (20), used to traverse the local autonomous system.
Example 7-34. Inter-AS: Looking at Top (LDP) Label
Finally, it is possible to understand the recursion process by analyzing in detail the way Cisco ExpressForwarding (CEF) has built the label stack, as shown in Example 7-35.
Example 7-35. Inter-AS: Label Stack Recursive Resolution
recursive via 7.7.7.7 label 22recursive via 90.1.1.2 label 19
nexthop 10.1.1.2 Serial0/0 label 20, adjacency IP adj out of Serial0/0 output chain: label 22 label 19 label 20 TAG adj out of Serial0/0
The topology examples discussed in the last sections show the extent of the similarities between VPNv6 andVPNv4. Almost every topology found in the VPNv4 world has a correspondence in the VPNv6 world. Thereverse is also true, except where coexistence leads to a more integrated scenario.
A full-scale IPv6 MPLS deployment is described in Chapter 13. It integrates some of the configurationexamples from this chapter into a complete, end-to-end IPv6 deployment case study.
Chapter 8. Advanced ServicesIPv6 Mobility
From game consoles to IP phones, billions of new devices are becoming IP enabled, requiring a largeraddressing space and improved plug-and-play networking capabilities, and therefore the deployment of IPv6.
At the same time, we observe the creation of a "mobiquitous" pervasive networking and computing fabric,composed of handheld devices, medical diagnostic systems, automotive gateways, and so on. Initiallyavailable to the military and specific verticals such as the police, radio data communication is becomingwidely available to the masses because of the available technology and the local rulings.
For a number of years now, business users have accessed the Internet while in transit. Typically, they coupletheir cell phone to their multimedia assistants and then switch to some public 802.11 wireless access.
As the technology reaches the masses, a new form of connectivity is developing at the fringes of the Internet:low-cost consumer devices have started shaping loose, intermittent, ad-hoc networks; and cities deploy largermesh networks to provide low-cost, high-bandwidth connectivity to all citizens.
The continuous connectivity facilitates the emergence of a new breed of applications: push services such asstock alerts and sport results, peer-to-peer services such as multimedia messaging, and voice integration. Butfor an ISP to deliver these applications, the user must be always reachable at the same network identifierregardless of its point of attachment.
IP mobility and IPv6 are designed to respond to this requirement. Coupling the two appears to be an evenbetter idea. Because Neighbor Discovery (ND) has the built-in mechanisms for faster movement detection andaddress autoconfiguration, IPv6 is significantly better positioned with respect to mobility than IPv4.
280 Part I: Implementing IPv6 Services
280 Part I: Implementing IPv6 Services
IPv6 is the keystone to elaborate on this new service model, and, in return, mobility is one of the drivers formaking IPv6 a deployment reality.
Chapter Overview
When a node changes its location, not only does it change its links, but most often, it also changes its networkof attachment and, as a consequence, its IP address, too. The mechanisms that exist in IPv4 and IPv6 for anode to automatically obtain a new address cannot prevent existing connections to be terminated when thenode moves.
A mobile node is an Internet-connected device whose location and point of attachment to the Internet maychange frequently. It can be a cellular phone, a handheld device, a laptop computer, a router, and so on.Mobile IP (MIP) is a standard that enables a mobile node to arbitrarily change its location on an IP networkwhile maintaining existing connections.
Full terminology is provided in RFC 3753.
This chapter focuses more than other chapters of the book on discussing the protocol aspects of this rapidlyevolving technology. It also presents its current trends and potential deployment opportunities.
From "Internet car" to "fleet in motion," from "personal network" to "home network," deploymentexperiments of IPv6 mobility carry so many promises that one can expect this technology to become a keyenabler for IPv6 success in the near future (see the "Practical Use Cases" section of this chapter for details onthese examples).
This chapter explores IP mobility starting from the established standards to a vision of pervasive computingand networking. The following topics are covered in respective sections:
The "IP Host Mobility" section reviews Mobile IPv6 technology, as well as current IP mobilitylimitations and challenges.
•
The "Network Mobility" section reviews network mobility, and presents a set of deploymentexamples, mostly technology experiments and previews.
•
The "IP Mobility in Nonmobile Scenarios" section covers areas where the technology can be usedoutside the mobility context, such as for hiding the topology of a private network, or buildingcommunities of interest.
•
The "Next Steps in Mobility" section covers improvements being currently discussed at the standardsbodies, such as fast movement detection, and finishes with a short description of the pervasivecomputing vision.
•
IP Host Mobility
A wide consensus exists in the industry and at the standards bodies that IP mobility will better scale throughthe IPv6 adoption. On one hand, millions if not billions of roaming devices, from handhelds to phones andmultimedia players, require more addressing capability than IPv4 can provide. On the other hand, the Internetcan now be reached from any location, including automobiles, trains, airplanes, boats, and so on. This isenabling a new set of peer-to-peer applications, which disqualify Network Address Translation (NAT) as theusual workaround for IPv4 address depletion.
Part I: Implementing IPv6 Services 281
Part I: Implementing IPv6 Services 281
Does that mean IPv6 is ready for large-scale IP mobility deployment? While a number of experiments andtrials are being tested today, many areas remain work in progress, whether at standards, products, orapplications level.
Mobile IPv4 in a Nutshell
Mobile IPv4 (MIPv4), specified in RFC 3344, provides a network-level indirection to the actual location of amobile node, indirection that hides the mobility to its correspondent nodes.
Although the mobile node, an IP host with a MIP stack, is located at a transient CareOf Address (CoA), acorrespondent node reaches the device at its permanent Home Address (HoAddr). The indirection ismaintained by a home agent that intercepts all the packets destined to the HoAddr of the mobile node andtunnels them to the CoA that the mobile node acquires locally at its new location. For details on MIPv4, werecommend the book Mobile IP Technology and Applications by Stefan Raab and Madhavi W. Chandra(Cisco Press).
The IETF Mobile IP working group (MIPv4) took a number of shortcuts to produce a specification, leavingroom for future work and improvements. Some of these unresolved issues (fast movement detection andhandoff, home discovery, initial bootstrap configuration, and so on) are now addressed in the MIPv6-relatedworking groups.
MIPv4 operations imply a triangular routingthe so-called dogleg issue. The flows toward the mobile node arerouted via its dedicated home agent, although only the return path is direct. The home agent is therefore apotential single point of failure for MIPv4 operations and a bottleneck for the forward traffic, whichexperiences additional latency and increased path length.
Another issue with MIPv4 is the requirement for a pervasive deployment of foreign agents, for movementdetection and CoA allocation. A mobile node can connect only at places where a foreign agent is available.This limits the deployability of IPv4 mobility.
Another concern about MIP is the path from mobile node to the corresponding node. Because packets on thispath are not tunneled, the mobile node HoAddr is used as source IPv4 address in all packets. This address isnot topologically correct during a portion of the packet journey (until it leaves the foreign network). Thepacket can appear to be a spoofing attempt. Border routers typically perform ingress filtering (for example,unicast reverse path forwarding check), analyze source address, and prevent packets with a source addressoutside the internal subnet range to be forwarded.
These limitations can be alleviated with the optional support of reverse tunneling and collocated CoA by themobile node. These improvements to the basic MIPv4 are the default behavior in the case of IPv6 mobility.
Mobile IPv6
Note that even though IETF MIPv4 working group is still active, a lot of the mobility-related work in thestandards bodies happens in the context of IPv6. 3GPP2 and 4G telephony standards are considering the useof MIPv6, and vehicular consortiums worldwide (Car2Car in Europe, InternetCar in Japan) have adopted IPv6for car-to-car communication.
Initially, MIPv6 was published as RFC 3775 and RFC 3776. RFC 3775 describes IPv6 mobility for mobilenodes, more specifically mobile hosts. RFC 3776 specifies the use of IP security in the context of RFC 3775.
282 Part I: Implementing IPv6 Services
282 Part I: Implementing IPv6 Services
Mobile IPv6 Operation Overview
A MIPv6 mobile node registers with a home agent and establishes a bidirectional tunnel. One endpoint of thetunnel is fixed at the home agent address. The other endpoint of the tunnel is located at the mobile nodeCareOf Address (CoA), and it changes as the mobile node roams. The association between the HoAddr of amobile node and its CoA is called a binding.
Packets destined for the mobile node are received by the home agent and tunneled to the mobile node. Asopposed to MIPv4, the tunnel between the mobile node and the home agent is bidirectional, and the returnpath is also through the home agent. This ensures the topological correctness of all flows, to avoid anyconflicts with ingress filtering deployed in the IPv6 Network.
RFC 3775 also describes the process of route optimization (RO) between the mobile node and thecorrespondent node. RO can only work between a MIPv6 mobile node and a MIPv6 correspondent node thatsupport the feature in their IPv6 stacks. When RO is established, packets are tunneled directly between thecorrespondent node and the mobile node in both directions. Figure 8-1 shows the MIPv6 operations.
Figure 8-1. MIPv6 Operations
[View full size image]
A MIPv6 service is deployed as follows:
A home link is installed by a service provider or an enterprise at a secure location on the Internet.• One or more router(s) is (are) configured as a home agent for a home prefix on that link. A homeagent must be connected to the home link to operate. It is critical for security reasons that the link beprotected from a rogue access.
•
A mobile node is provisioned with the home prefix, and a HoAddr on that prefix. The HoAddr is the index forMIPv6 bindings. It is also a valid address on the home link, that the mobile node uses when it connects to thehome link. The mobile node is also provisioned with initial security tokens to prove its identity whenestablishing bindings.
Part I: Implementing IPv6 Services 283
Part I: Implementing IPv6 Services 283
IPv6 Mobility Header
MIPv6 was designed as an extension of IPv6. It takes full benefit of the IPv6 packet structure as defined inRFC 2460, creating a new extension header (the Mobility header), a new destination option (the HoAddroption), and a new Routing header (RH type 2). MIPv6 also proxies the Neighbor Discovery Protocol on thehome link, with the benefit of being independent from the data link layer technology. Finally, four ICMPv6messages were created for the purpose of MIPv6, for the Dynamic Home Agent Address Discovery(DHAAD) mechanism and for network renumbering and address configuration on the mobile node (MobilePrefix Solicitation/Advertisement).
Figure 8-2 shows the layout of the Mobility header.
Figure 8-2. Mobility Header
The Mobility header is an extension header used by mobile nodes, correspondent nodes and home agents in allmessaging related to the creation and management of bindings. Binding messages all use the Mobility headerand do not convey any upper-layer information. The Mobility header appears in two different flows, thebinding flow, and the return routability (RR) procedure that secures the MIP route optimization. The MobilityHeader Type field identifies the particular mobility message:
Home Test Init message (type=1) A mobile node uses the Home Test Init (HoTI) message to beginthe RR procedure and request a Home keygen token from a correspondent node. The keygen token isa number that the correspondent node supplies to enable the mobile node to compute the necessarybinding management key for authorizing a binding update.
•
Care-of Test Init message (type=2) Mobile node uses the Care-of Test Init (CoTI) message to beginthe return routability procedure and request a care-of keygen token from a correspondent node.
•
Home Test message (type=3) The Home Test (HoT) message is a response to the Home Test Initmessage from the correspondent node to the mobile node.
•
Care-of Test message (type=4) The Care-of Test (CoT) message is a response to the Care-of Test Initfrom the correspondent node to the mobile node.
•
Binding Refresh Request message (type=0) The correspondent node sends a BReq to request a mobilenode to update its mobility binding.
•
Binding Update message (type=5) The Binding Update (BU) message is used by a mobile node tonotify other nodes of its new CoA.
•
Binding Acknowledgment message (type=6) The Binding Acknowledgment (BA) is used toacknowledge receipt of a Binding Update.
•
Binding Error Message (type=7) The Binding Error (BErr) message is used by the correspondent•
284 Part I: Implementing IPv6 Services
284 Part I: Implementing IPv6 Services
node to signal an error related to mobility, such as an inappropriate attempt, to use the HoAddrdestination option without an existing binding.
To register, the mobile node sends a signed unicast Binding Update to the home agent, specifying its HoAddrand its CoA.
To accept a new binding, the home agent must ensure that the address is not already bound to another homeagent, or present on the home link. This is checked by means of the ND Duplicate Address Discovery (DAD)mechanism on the home link. If the home agent accepts the binding, it sends a positive BindingAcknowledgement back to the mobile node.
Because of the DAD process, the initial binding might take more then 2 seconds to complete. It is notrecommended to use such procedures as Optimistic DAD to improve that initial latency if the HoAddr isconfigured to the mobile node. Note that additional bootstrap mechanisms are being elaborated at IETF toallow the dynamic provisioning of the mobile node.
Upon accepting the first Binding Update, the home agent allocates a binding cache entry indexed by themobile node HoAddr and sets up a tunnel to the mobile node CoA. The mobile node uses the Binding Updatemessage to maintain the tunnel. It is sent periodically, as a keepalive mechanism, and asynchronously whenthe mobile node moves and needs to update the home agent with the new CoA.
Destination Option
MIPv6 defines one new destination option (Next Header value of 60), the home address option (option type201). The HoAddr destination option is used in a packet sent by a mobile node while away from home, toinform the recipient of the mobile node's HoAddr. The receiving stack at the home agent will swap the sourceof the packet with the address in the destination option. As a result, the rest of the processing of the packethappens as if the source was on the home link.
Dynamic Home Agent Address Discovery
Note that RFC 3775 does not provide the means for the mobile node to acquire its full initial configurationdynamically; this is called the bootstrap problem, currently considered at IETF. On the other hand, RFC 3775specifies an Internet Control Messaging Protocol (ICMP) flow for a mobile node to discover which homeagent(s) are available on its home link; this is the Dynamic Home Agent Address Discovery (DHAAD).
DHAAD is performed prior to any binding; it is stateless, unsecured, and is not associated with a HoAddr.With DHAAD, a mobile node forms its home agents anycast address based on its home network prefix and asuffix reserved for that purpose by RFC 2526. The anycast address is then used as destination for the DHAADrequest.
Figure 8-3 shows the DHAAD flow.
Figure 8-3. DHAAD Flow
[View full size image]
Part I: Implementing IPv6 Services 285
Part I: Implementing IPv6 Services 285
The home agents discover each other on the home link using an extension to the Neighbor DiscoveryProtocol. One of them receives the DHAAD request, and answers with a DHAAD reply that carries anordered list of home agents. Note that the computation of the order of that list is not standardized, and that itcan be used for such purposes as load balancing.
As soon as the mobile node selects a new attachment router, it obtains a topologically correct IPv6 address,usually by means of stateless autoconfiguration from a prefix available on that router's link. This address willbe used as CoA. The CoA is the source of the initial DHAAD flow.
Route Optimization
When needed, the mobile node might leverage an RO mechanism in communicating with the correspondentnode. RO bypasses the home agent, at the expense of an additional tunnel, mobile node to correspondentnode. It cannot be expected that in the general case, any potential mobile node and correspondent node pairwill share some form of trust model (such as a Public Key Infrastructure or a shared secret). To provideminimum security, the MIP6 working group designed a lightweight mechanism that allows the correspondentnode to check that, at least, the home agent also trusts the identity of the mobile node.
This mechanism, the return routability (RR) procedure, is initiated by the mobile node and must be completedbefore the mobile node can bind directly with the correspondent node. The mobile node sends two queries tothe correspondent node, one directly from its CoA (the CoTi), and one via the home agent (the HoTi), from itsHoAddr. The correspondent node responds to both over the incoming path. Each response carries a half of thekey that, when complete, will be used by the mobile node to sign its binding and securely establish an ROtunnel with the correspondent node.
The RR test is fully stateless on the correspondent node side, and relies on the fact that the mobile node tohome agent tunnel is secured.
Figure 8-4 shows the RO forwarding path.
Figure 8-4. Route Optimization for MIPv6
[View full size image]
286 Part I: Implementing IPv6 Services
286 Part I: Implementing IPv6 Services
Although only a subset of all IPv6 nodes on the Internet will implement it, the RO mechanism is essential forthe scalability of MIPv6 operations. It is expected to reduce or avoid congestion in the home network, andtherefore to enable the use of low-end home agent equipment. In addition, it should reduce the load across theInternet and improve jitter and latency of communications. This is the reason why it was incorporated in theMIPv6 base specification, RFC 3775. However, RO does not come for free: It introduces additional states inthe correspondent node, additional messages between the correspondent node and the mobile node, andrequires specific MIPv6 support by the correspondent node, that will not be found in early IPv6 stacks andmight be omitted in a number of specific nodes such as Internet routers, web servers, or embedded devices.For these reasons, RO remains an optional mechanism.
Mobile IPv6 Security
As for all modern IETF standards, security issues have been seriously considered in the case of IPv6 mobility.The MIPv6 protocol is normally protected by IPsec. A specific test, the RR procedure, was designed to provethe mobile node identity in the context of RO.
In more detail, RFCs 3775 and 3776 provide a number of security features, as follows:
Protection of Binding Updatesboth to home agents and correspondent nodes. This is achieved by useof IPsec extension headers, or by the use of the Binding Authorization Data option. This optionemploys a binding management key, Kbm, which can be established through the RR procedure.
•
Protection of mobile prefix discoverythrough the use of IPsec extension headers.• Protection of the payload packets The mechanisms related to transporting payload packets such as theHoAddr destination option and type 2 routing header have been specified in a manner that restrictstheir use in attacks. Restrictions are the following:
- The HoAddr destination option can be used only when a correspondent node already has abinding cache entry for the given HoAddr.- The mobile node verifies that the outer IP address corresponds to its home agent.- The home agent verifies that the outer IP address corresponds to the current location of themobile node (Binding Updates sent to the home agents are secure).- The home agent identifies the mobile node through the source address of the inner packet(HoAddr of the mobile node).
•
Part I: Implementing IPv6 Services 287
Part I: Implementing IPv6 Services 287
Note
An alternate mechanism (draft-ietf-mip6-auth-protocol: "Authentication Protocol for Mobile IPv6") is beingdiscussed at the time of this writing in the IETF, for specific situations, such as 3GPP2, where IPsec is toocomplex for a light device such as a mobile phone.
Mobile IPv6 Deployment
MIPv6 revolves around a specific link at a specific site, the home link. The MIP operation is based on NDextensions and proxying on that link. The home network is subnet on that link. MIPv6 is therefore alink-centric technology.
Each mobile node must be provisioned with a home network prefix, its own HoAddr, and some securitytokens to exchange keys and prove its identity.
At a first glance, it might seem that DHAAD and home agent discovery on the home link provide redundancy,high availability, and load balancing. However, it is not all true for the following reasons:
Being a link-centric technology, MIPv6 presents a single point of failure: the link itself.• The binding cache is stored in a single home agent. Should that home agent fail, all states will be lost.It might take time (half of a binding lifetime on average) for the mobile node to discover the loss anduse the next home agent in its DHAAD list. This is a limited level of high availability.
•
Even if multiple home agents can be deployed on the home link and even though a single one takesany given binding, it is likely that over time all the home agents will end up storing some informationabout all the active mobile nodes, at least in their ND neighbor caches. Neighbor caches and bindingcaches are not exactly comparable because Neighbor caches can be flushed, as opposed to bindingcaches, but still, the load of all home agents augments with the number of registered mobile nodes,and that limits the overall scalability.
•
In terms of routing, the home agents advertise the home prefix into their IGP. Note that if the interface to thehome link fails, the home agent operations stop, even for existing flows between correspondent nodes andmobile nodes with an active binding.
When the mobile node roams far away from home, the round-trip delay creates a window of time between themovement and the updating of the tunnel on the home agent side. During that window, packets are sent to theold CoA and cannot be delivered. Local Mobility Management (LMM) can reduce the binding latency and theloss of packets, at the expense of deploying additional, distributed agents in all regions. A LMM agent hidesthe local mobility of the mobile node, reducing dramatically the time window and the associated packet loss.In particular, Hierarchical MIP (HMIP) described in RFC 4140, is an experimental RFC that proposes aregional LMM solution that hides the MN movement from the home agent. A NETLMM working group hasformed at the IETF to standardize a local solution that hides the MN movement from the MN itself. Note thatspecific support might be required in the mobile node for LMM purposes.
Also, mobility and wireless connectivity fit well together. A widely available broadband wireless networkaccess is required for IP mobility to take off. Such a service might take place with the emerging trend of meshnetworking.
A mesh network combines wireless communication (such as WLAN and WWAN) and some ad-hocself-forming and self-healing technology to build a multi-hop radio network that extends the reach oftraditional access points. As a result, mesh networking simplifies and reduces the cost of wireless accessnetworks deployments, enabling new operators such as municipalities to offer citywide broadband services.
288 Part I: Implementing IPv6 Services
288 Part I: Implementing IPv6 Services
A number of radio technologies are being developed or deployed around us. Handling mobility at layer 3enables the reachability-aware use of different radio access technologies available at a given point of time.The type of service (coverage, range, bandwidth, cost, and so on) depends on the type of radio (WLAN,WWAN, EDGE). To optimize the connectivity as it roams, a mobile node can be equipped with multipletypes of interfaces, and should provide the means for the upper layers to select the best access at any point oftime depending on the required service level.
Finally, MIPv6 cannot be deployed in the same fashion in all networks and with all clients. It can be expectedthat most large operating systems will provide a MIP client supporting both RFC 3775 and RFC 3776. But,for instance, lighter devices might not need or be able to handle complex functions such as IPsec.
Configuration Example
The home agent has been available in Cisco IOS Software for field trial since 2001. It is compliant with RFC3775 and is available commercially starting with 12.3(14)T and 12.4 releases. It has been demonstrated intechnology previews, and the following example illustrates one of these previews.
Figure 8-5 presents the MIPv6 example operations.
Figure 8-5. MIPv6 Example
Part I: Implementing IPv6 Services 289
Part I: Implementing IPv6 Services 289
The following elements are identified in Figure 8-5:
The home agent is a Cisco router, with IOS MIPv6 support per RFC 3775.• The mobile node is an Hewlett-Packard HP iPAQ running Linux MIPv6.• The correspondent node is an HP UNIX server.• The application running between the mobile node and the correspondent node is MP3 streaming.• The network infrastructure uses Cisco WiFi access point.•
Example 8-1 shows the configuration of the router in Figure 8-5.
Example 8-1. MIPv6 Home Agent Configuration Example
Router1#show runningipv6 unicast-routinginterface ethernet0 ipv6 address 2001:0001::45c/64 ipv6 address 2001:0001::fdff:ffff:ffff:fffe/64 anycast ipv6 mobile home-agent ipv6 mobile home-agent access mipacl
The command ipv6 mobile home-agent enables the home agent operation on the interface. By default, thehome agent operation is disabled. To support DHAAD, the configuration of the anycast address is required,too.
The command ipv6 mobile home-agent access <acl> configures a binding update filter using an access controllist (ACL). When an ACL is configured, all received binding updates are filtered. This feature can be used todeny home agent services to mobile nodes that have roamed to particular subnetworks. When the filter blocksa Binding Update, a Binding Acknowledgement is returned with error status "Administratively prohibited."The default behavior is to have no filters; all Binding Updates are accepted. Note that the filter is also appliedto DHAAD messages. When blocked, these are silently discarded. In ACL configuration, the source is theCoA and the destination is the HoA.
The details of the CLI commands might evolve over time. For further details about Cisco IOS configuration,consult the Cisco IOS configuration guide.
Note
At the time of this writing, Cisco IOS Release 12.4 does not process the home agent traffic through the IPv6Cisco Express Forwarding (CEF) switching path.
As far as the authentication, Cisco IOS Software will implement an MD5 Lightweight authentication (andIPsec authentication in future releases).
Using ACLs to Control MIPv6 Operation on the Home Agent
A new feature has been introduced on Cisco routers, as part of the IPv6 ACL component, enabling a router tomatch packets containing the IPv6 extension headers introduced or modified by RFC 3775.
The objective is to provide finer-grain control over routing header and ICMPv6 messages and prevent securityholes where "everything" has to be wide open for the home agent MIPv6 operation to be allowed. Thefollowing list provides some examples on how this enhancement can be used:
ICMPv6 message types:
Only ICMPv6 DHAAD request messages between the pair of specified host addresses will bepermitted.
ipv6 access-list List1 permit ipv6 host 2002:100::150 host 2002:100::153 dhaad-request deny ipv6 any any
1.
Mobility header:
Only traffic between the pair of specified hosts, with a mobility header, will be permitted.
Only traffic carrying the specified routing header type will be permitted.
ipv6 access-list List3 permit ipv6 host 2002:100::50 host 2002:100::51 routing-type 2 deny ipv6 any any
3.
Destination options header:
Only traffic carrying the specified destination option type will be permitted.
ipv6 access-list List4 permit ipv6 host 2002:100::10 host 2002:100::11 dest-option-type 201 deny ipv6 any any
4.
Network Mobility
Current MIPv6 deals with mobile hosts as opposed to IP nodes, which include routers. Moving routers aroundalso involves moving the attached networks with them, and it takes some additional signaling to implement.NEtwork MObility (NEMO) defines the operations of a mobile router that handles the mobility of a wholenetwork; the mobile network nodes (MNNs) attached to a NEMO benefit transparently from that support andkeep their global address as the whole network moves.
According to the NEMO IETF working group charter:
The NEMO working group is concerned with managing the mobility of an entire network,which changes, as a unit, its point of attachment to the Internet and thus its reachability in thetopology. The mobile network includes one or more mobile routers (MRs) which connect it tothe global Internet.
The value of a mobile router is already identified through a number of service concepts:
A mobile network can be preconfigured and tested at the factory or at the back office. Whendeployed, the whole network operates the same as it did at configuration time and it is reachable at thesame (home) addresses. For instance, surveillance cameras can be fully checked and integrated withthe management screens before they are sent to the remote location.
•
Deployment is totally plug and play. Benefiting from IPv6 ND, the mobile router discovers itsenvironment, autoconfigures a CoA, and registers home on behalf of the full network. This provesparticularly useful when the installer is not highly skilled in networking and/or not trained toconfigure the routers and the attached devices.
•
IP network mobility saves the burden of renumbering the network when it changes location.• NEMO comes with IPsec and enables a secure hub-and-spoke configuration for branch offices.•
Practical Use Cases
A number of use cases were envisioned for a network that moves as a whole. The degree of global andrelative mobility varies from one case to another, as illustrated in the following examples.
292 Part I: Implementing IPv6 Services
292 Part I: Implementing IPv6 Services
Enterprise on the Move
The first usage for network mobility might be a simple extension of the enterprise network to make itreachable from professional vehicles (DHL, FedEx, Brinks, and so on) or metropolitan public transportation(buses, subways, taxis, truck fleets). In this case, the mobile network is a simple moving stub, which gathersand delivers data on the way to and from multiple devices.
Three distinct subcases can be identified:
Machine to machine. In this case, sensors are deployed in the vehicles, which can report to, or bepolled from base stations. The sensors provide real-time mission-critical information to the back-endcontrol systems. For instance, RFID tags could be used by a trucking company to monitor the deliveryof goods to the final customer and the information could be updated in real time on the companywebsite. GPS information can be sent back to follow the truck activity and ensure that it meets thelocal regulations. Additional sensors can report various engine parameters and when the truck is backat the garage, in depth diagnostics can be run over the high-speed wireless network while microcodeupdates are being downloaded automatically into the truck-embedded controllers.
1.
Content delivery with human interface. In this case, there is a human interaction at either end of theflow. This could be video distribution, multicast from a station into public transportation such asbuses and trains. But, this could also be a set of embarked webcams, used by a transportationcompany to ensure the security of the bus driver, or by a trucking company to check that thetransported goods are not being hijacked while the truck is stopped at along the highway. Examples ofmobile clients could be IP appliances such as screens, ticket scanners, and cameras, as well as the IPterminals used for application hosting or data browsing.
2.
Mobile hotspot. In this case, an employee connects to the company virtual private network (VPN)using its mobile router as default gateway. The burden to select the access network and the roamingcomplexity is handled by the router, once and for all, allowing all employees to use any IP device asman-to-machine interface, even a simple, non-MIP-enabled, portable or embedded gizmo. In thatmodel, the device could handle its own security using some VPN software, leaving the mobility to therouter, or, alternatively, the mobile router could provide an encrypted tunnel back into the company,saving a level of encapsulation.
3.
Home Gateway
With the large address space offered by IPv6, it makes sense to imagine that an ISP will delegate a fullglobally addressable /64 prefix for the home, as opposed to a single public IPv4 as is customary today. Andimagine that the ISP providing a globally reachable network at home to a million of households. In eachhouse, the attached devices are reachable from the Internet. Some devices might be monitored by externalservices (for example, surveillance cameras, fridges, and video servers). They would be known by DNS nameor IPv6 address, and they would be kept in various databases.
Consider that an average family moves every 10 years. Without IP mobility, that would translate into 100,000networks being renumbered each year, updating the various databases everywhere, changing DDNS,configurations, and registrations everywhere. NEMO changes the paradigm, and if the network at home is amobile network, it is left unchanged as the family moves. For the ISP, network mobility could become achargeable service when it was an unmanageable complexity.
This continuity of service has value for both the ISP and for the customers, who perceive a better quality.Service providers have to decide whether an economical model can be based on an always-reachable networkas opposed to application-specialized services based on SIP, for instance.
Inside the home, visiting friends and family might connect to the network and share the facilities, for localgaming as well as Internet connectivity. The visitors might want to be reachable using their own HoAddr andtherefore manage their own mobility.
Part I: Implementing IPv6 Services 293
Part I: Implementing IPv6 Services 293
As a result, the home gateway, which is a mobile router, accepts visitors that are also mobile. This situationresults in a nesting of tunnels, which has a number of dreadful consequences for the traffic in terms of path,latency, and security.
NEMO has identified the need for a RO model where the visitor manages its own mobility and maintains itsown tunnel to its own home agent. In a more generic way, there is a need for a model that guaranteesanonymity and innocuousness for all parties, for their mutual benefit, and enables large nested configurationswith no preexisting trust model, in a tit-for-tat fashion.
Personal-Area Network
A personal-area network connects together various wearable devices and body systems, such as biomonitors.A portable mobile router can provide global reachability for all these devices at all times, as long as a powermanagement scheme is available to ensure a usable autonomy to the system, comparable to that of mobilephones today.
Figure 8-6 shows a personal-area network.
Figure 8-6. Personal Area Network
The mobile router needs close-by, low-power connectivity in its environment. It will connect to the homegateway when at home, and then to buses, airports, cars, planes, trains, hotspots, and so on.
This example creates a nested hierarchy of mobile routers, for instance: PDA > PAN > vehicle > ferry, whichis a form of nesting that happens between entities of different types. The degree of nesting is limited byconstruction to the order of 2 or 3. Each level of hierarchy might be operated by a different service provider,
294 Part I: Implementing IPv6 Services
294 Part I: Implementing IPv6 Services
and there is a need for a meta provider (a form of mobile virtual network operator, MVNO) that integrates theservices of multiple ISPs and presents a single access control and billing to the final users.
Internet-Enabled Car
The European Car2Car and the Japanese InternetCar consortiums are working on the definition ofinter-vehicular communication. There is a wide consensus that this communication should be based on IPv6.
This might mean car-to-car communication (for instance, to enable a continuous sessions between trucks in aconvoy), regardless of the cellular coverage, and without the hassle of actual roaming.
This might also mean packet relaying between cars. In the latter case, the cars organize themselves into adynamic mesh network, helping each other as community service in a tit-for-tat fashion.
Figure 8-7 shows an Internet-enabled car network.
Figure 8-7. Internet-Enabled Car Network
[View full size image]
As opposed to the previous example, all devices are of a same kind, and the network can reach an arbitrarydepth.
A typical use case is a traffic jam with hundreds to thousands of cars stalled. Most could be too far from apublic access point to communicate. It might be mutually beneficial for all of them to collaborate, to share theradio spectrum and to extend the reach of the APs. Also, a geographically localized broadcast might be usefulto signal the jam to vehicles arriving at full speed.
Sensor Network
A sensor network is an extreme form of an ad-hoc network because it relates to the amount of devices andtheir highly limited capabilities. Sensors are low-cost, mass-produced devices, used to monitor variousmetrics such as temperature or seismic activity around an area. A "sensor dust" is usually spread over amonitored location, and from that moment on, the sensors are fixed and operate for the lifetime of theirbatteries, which are their most critical resource.
Figure 8-8 shows a sensor network.
Part I: Implementing IPv6 Services 295
Part I: Implementing IPv6 Services 295
Figure 8-8. Sensor Network
Around a sensor network, sinks are deployed to collect the measurement from the sensors and relay thecommands from the controllers. Therefore, sensors automatically form a structure to forward unicast packetsfrom the sensors to the sinks and to propagate broadcast packets across the network from the sinks.
As in the previous case, the sensors act as a community and relay packets for each other; however, the modelreaches its limits because of the operational cost on the batteries and the complexity involved with thenetworking part.
To form a routing hierarchy and make each sensor much simpler and cheaper, a limited number of mobilerouters can be deployed to form a mesh, act as default gateways for the sensors, and upload the data.
In that case, the sensors can be short-range, plain IPv6 hosts. Mobile routers might be mobile (placed onplanes or drones) to sweep the perimeter, or fixed and well distributed across the monitored location, with afew of them equipped with a back-haul capability acting as sinks.
Fleet in Motion
A fleet is a set of vehicles with global unity in motion and administration, yet allowing some degree ofrelative movement between the vehicles. Classical examples are a truck convoy along a road, vessels at sea, orjeeps in the dunes. Each vehicle owns at least one mobile network.
296 Part I: Implementing IPv6 Services
296 Part I: Implementing IPv6 Services
Figure 8-9 shows a "fleet in motion" network.
Figure 8-9. Fleet in Motion
Interestingly, nodes might need to move physically to cover a dark zone and extend the range of the localnetwork or to interconnect a stray group with the rest of the fleet.
In the case of a fleet that roams far from its base, it is important to maintain the local connectivityindependently of the global connectivity, which can be expensive and potentially erratic.
Members of the fleet need to communicate with each other. This might be achieved by a form of MobileAdhoc NETwork (MANET) within the fleet. They might also need a global reach back, in which case someNEMO support is required, too. A smooth integration of the MANET and the NEMO would be needed tooptimize the flows within the MANET and to the outside.
A mobile home agent can also be deployed within the fleet as a rendezvous point to concentrate the traffic tothe outside, while ensuring that the local traffic is contained within the fleet.
Object Model and Terminology
The SEAMOBY (seamless mobility, for context and micro-mobility routing) and the NEMO terminologydocuments define all the terms used in the context of these technologies. Here follows a summary of the mostimportant terms:
Part I: Implementing IPv6 Services 297
Part I: Implementing IPv6 Services 297
Mobile router "A router capable of changing its point of attachment to the network, moving from onelink to another link. The mobile router is capable of forwarding packets between two or moreinterfaces, and possibly running a dynamic routing protocol modifying the state by which it doespacket forwarding. A mobile router acting as a gateway between an entire mobile network and the restof the Internet has one or more egress interface(s) and one or more ingress interface(s). Packetsforwarded upstream to the rest of the Internet are transmitted through one of the mobile router's egressinterface; packets forwarded downstream to the mobile network are transmitted through one of themobile router's ingress interface."
•
Mobile network (NEMO) "An entire network, moving as a unit, which dynamically changes its pointof attachment to the Internet and thus its reachability in the topology. The mobile network iscomposed of one or more IP-subnets and is connected to the global Internet via one or more mobilerouters (MR). The internal configuration of the mobile network is assumed to be relatively stable withrespect to the mobile router." Note that the definition allows a NEMO be a complex structure withrouters that are fixed with regards to a moving topology, and one or more mobile router(s) assumingthe mobility for all.
•
Mobile network node (MNN) "Any node (host or router) located within a mobile network, eitherpermanently or temporarily. A Mobile Network Node may either be a fixed node (LFN) or a mobilenode (VMN or LMN)." Note that the local fixed node (LFN) is the proverbial "plain" IPv6 node, withno assumed support of MIPv6 or NEMO. In particular, it can be a "fixed" router and mobility ishandled by the mobile router. A visiting mobile node handles its own mobility, and as opposed to alocal mobile node, it is not homed in this NEMO.
•
Correspondent node "Any node that is communicating with one or more MNNs. A correspondentnode could be either located within a fixed network or within a mobile network, and could be eitherfixed or mobile." At this moment, the definition of a correspondent node comes from RFC 3775because RFC 3963 does not cover RO. In the future, NEMO might require additional support from thecorrespondent node for its own RO or introduce new concepts in the network such as a correspondentrouter, which would terminate NEMO on the correspondent side, or a proxy home agent, which wouldhandle RO on behalf of mobile routers, from within the infrastructure.
•
Basic Operations
RFC 3963 specifies the extensions to MIPv6 for networks in motion. Also called the NEMO basic support,this RFC describes the mobile router operation of registering with a home agent, establishing a tunnel, andrequesting that the home agent installs the routes to the mobile network prefix(es) (MNPs) over that tunnel.
Two modes of operation have been initially specified:
In implicit mode, it is expected that both ends have prior knowledge of the MNPs associated to eachgiven mobile router. That mode requires a double configuration (on mobile router and home agent)and will leave configuration errors undetected until runtime.
•
In explicit mode, the mobile router provides its list of MNPs as a new option to the Binding Updatemessages. The home agent must have a way to check whether a mobile router is authorized for aMNP before it accepts a binding.
•
NEMO is now standardizing its prefix delegation, a third mode where the mobile router learns its MNP(s)from the home agent. This can be used by a mobile router that boots for the first time, to obtain dynamicallyits MNP as part of its initial configuration (bootstrap). This can also be used in runtime, to get additionalpersistent prefixes, or session prefixes, which will be valid for the duration of the binding.
What About NEMO?
So, is NEMO simply an adaptation to IPv6 of Cisco mobile router for IPv4? NEMO is actually different in anumber of aspects:
298 Part I: Implementing IPv6 Services
298 Part I: Implementing IPv6 Services
With IPv6 ND and its MIP adaptations, roaming is an order of magnitude quicker than withIPv4/DHCP, decreasing from 20 seconds to 2 seconds. Additional mechanisms are under study togain another order of magnitude or more and reach acceptable values for voice applications.
•
In terms of topology, NEMO has no concept of foreign agent, but in turn, regional boxes dedicated tolocal mobility management, home agent proxying, and so on might be deployed to alleviate somecurrent limitations of the protocol (for instance, related to RO).
•
IPv4 is pervasive, but IPv6 access is scarce at the moment. So, the mobile router for IPv6 needs atransition mechanism for IPv4 traversal, such as Cisco doors.
•
With the plethora of addresses that IPv6 offers, a new model of aggregation based on serviceproviders delegating prefixes to their customers was put in place. The same plethora enables a givencustomer to buy services from several ISPs. But then, he gets as many prefixes as ISPs, and using thewrong one might not pass ingress filtering at the SP edge. This situation is called multihoming in IPv6and was studied at the Multi6 working group at the IETF (see Chapter 4, "IPv6 Routing Protocols," inthe section "Site Multihoming" for details). With NEMO, the situation is even worse, because anumber of additional scenarios might occur, such as a mobile router with multiple CoAs, multiplehome agents, or a mobile network with multiple mobile routers. A new working group, MONAMI6,was chartered to study the problem outside of NEMO.
•
Then, is NEMO a straightforward adaptation of MIPv6 for mobile routers? The answer is not so simple:
In terms of configuration and deployment, NEMO is quite a bit more complex than MIPv6. Inparticular, the next sections review how the concept of home has evolved and which home networkmodels can be considered for deployment.
•
There is a lot more to RO with NEMO than with MIP. At the time of this writing, NEMO isproducing a problem statement document draft-ietf-nemo-ro-problem-statement and a solution spaceanalysis draft-ietf-nemo-ro-space-analysis, which detail the various cases and approaches that couldbe envisioned to solve the problems.
•
An inter-home agent protocol, the HAHA protocol, suggests to get rid of the concept of a home link.HAHA distributes home over the Internet to enable a global roaming. In that model, RO and locationprivacy are ensured by distributed proxies.
•
NEMO is rechartering to address specifically the RO problem. This might open the way to dramatic changesin the Internet such as IPv6 route projection and IPv6-based 4G telephony.
Home Network in NEMO
The MIPv6 home is a subnet on a physical link. As mentioned earlier, it is tied to a physical link byND-related operations. With NEMO, the home network becomes an aggregation. Home is not necessarilycontained on a home link (for instance, extended home network) and can be deployed in a number ofvariations.
Also, with NEMO, the home link can be a virtualized, too. This configuration can be deployed when mobilerouters have no need to return home, which is not necessarily a problem for most scenarios considered. Notethat the single home agent constraint can be fixed by an inter-home agent's protocol, such as HAHA.
In the various models proposed hereafter, an aggregation is partitioned into mobile network prefixes anddeployed in various fashions. The aggregation is generally called home. Home is advertised into theinfrastructure by the home agent(s), and spans the home link and the mobile networks.
Part I: Implementing IPv6 Services 299
Part I: Implementing IPv6 Services 299
Extended Home Network
In this model, the MIP home network is conserved as one subnet of a larger aggregation that alsoencompasses the mobile networks; this aggregation is called an extended home network.
When at home, a mobile router performs its normal routing functions between the home link and the mobilenetworks. To maintain the MNP routes in the absence of a binding, either the home agent is configured withstatic routes to mobile network prefixes or, alternatively, the mobile routers recognizes that it is at home andparticipates in the local IGP.
On the home link, only the home network inherited from MIP is installed, as the subnet from which all mobilenodes (hosts and routers) take their HoAddr. NEMO allows a mobile router to use an address from its ownMNP as a HoAddr, but in the extended home network model, this does not seem to be the most naturaloperation, and it requires an additional support by the home agent to handle the extended range of HoAddrs.
Aggregated Home Network
In this model, the home network is configured as the prefix on the home link, overlapping the MNPs. In theabsence of a binding, the home agent expects all the MNNs to be on link.
Therefore, there is no need for a static route or an automated participation to the local IGP when a mobilerouter is at home. In return, when the mobile router is connected to the home link with an EGRESSINTERFACE, it needs to switch automatically to a bridgingor a proxy ND mode between the home link andthe mobile networks.
If this automated bridging operation is not available on a given implementation, it is possible, alternatively, toconnect the mobile router to the home link with the ingress interface(s) to make all MNNs directly available tothe home agent without any bridging.
A mobile router can use its address on one of its MNP as its HoAddr for binding purposes. But in that case,the ND DAD operation that MIP mandates on the binding cache creation at the home agent is moot becausethe real prefix is not on link.
When configured for aggregated home network, an implementation could optionally verify that that theHoAddr matches (one of) the MNP(s) associated with that mobile router, and skip the DAD process. Inparticular, it should be configurable to reject a binding if the checking fails.
Mobile Home Network
A mobile home network is both a home network and a mobile network, where some mobile routers assumethe role of home agent(s) for their NEMOs, forming a bitwise hierarchy of home networks.
A head home agent advertises the global home to the infrastructure, and attracts all the packets from theoutside to tunnel them to the mobile router that is responsible of the next level of hierarchy. The next mobilerouter decapsulates and re-encapsulates the packets to the next mobile router down the logical tree. Thisprocess is repeated until the destination is reached.
The following is an example CLI for a cab company, with offices distributed in the largest cities in the UnitedStates. Cabs are equipped mobile routers, homed at the closest office from their location of operation. Theexample below focuses on the San Francisco (5F0) office. The topology is illustrated in Figure 8-10.
300 Part I: Implementing IPv6 Services
300 Part I: Implementing IPv6 Services
Figure 8-10. Example of Mobile Home Network
The configuration at the headquarters of the cab company is listed in Example 8-2.
Example 8-2. Mobile Home Network Configuration at the Headquarters of a Cab Company
HQ#show runninginterface Ethernet0 ip address 10.0.2.1 255.255.255.0 ipv6 enable ipv6 nd ra suppress ipv6 Mobile Router-service doorinterface Ethernet1 ipv6 address CAB:C0:CA5A:CA5A::CA5A/64 ipv6 enable ipv6 nd advertisement-interval ipv6 nd ra interval msec 1000 ipv6 mobile home-agent run
The configuration of the San Francisco office is shown in Example 8-3.
Example 8-3. Mobile Home Network Configuration at the San Francisco Office
SFO#show runningipv6 Mobile Router home-network CAB:C0:CA5A:CA5A::/64 discover home-address home-network ::5F0 home-door 10.0.2.1 explicit-prefixinterface Ethernet0 ip address dhcp ipv6 address autoconfig
Part I: Implementing IPv6 Services 301
Part I: Implementing IPv6 Services 301
ipv6 enable ipv6 nd ra suppress ipv6 Mobile Router-service roam try-the-doorinterface Ethernet1 ipv6 address CAB:C0:5F0:5F0::5F0/64 ipv6 enable ipv6 nd advertisement-interval ipv6 nd ra interval msec 1000 ipv6 mobile home-agent run
The configuration of one of the cabs of the San Francisco office is presented in Example 8-4.
Example 8-4. Mobile Home Network Configuration on One of the Cabs
SFO-cab-1#show runningipv6 Mobile Router home-door 10.0.2.1 home-network CAB:C0:5F0:5F0::/64 discover home-address home-network ::CAB1 explicit-prefix!interface Ethernet0 ip address dhcp ipv6 address autoconfig ipv6 enable ipv6 nd ra suppress ipv6 Mobile Router-service roam try-the-door!interface Ethernet1 ip address 10.0.1.1 255.255.255.0 ipv6 address CAB:C0:5F0:CAB1::CAB1/64 ipv6 enable ipv6 nd advertisement-interval ipv6 nd ra-interval msec 1000
In this configuration, each level of the mobile home network CAB:C0::/32 is also an extended home network.The head home agent, CASA, acts as a doors gateway to accept bindings over IPv4. The SFO office and thecabs are configured to use DHAAD, and doors IPv4 traversal is enabled, too. For mobile routers, Ethernet0 isthe egress interface, and Ethernet1 is the ingress interface and the home link on home agents.
Distributed Home Network
The distributed home network model splits the home in different geographies, breaking the home linkparadigm. This cannot be achieved with the NEMO basic support, which is still tied to the home link by itsMIP inheritance.
The global distribution of home agents is useful when a mobile router moves over geographically large areas,as is the case of airplanes, vehicles, and so on. If a mobile router moves far away from its home agent, theoverhead of the basic NEMO caused by the bidirectional tunnel cannot be ignored. With the distribution ofhome, the mobile router establishes its tunnel with the closest home location, and the routing information isdistributed over the mesh of tunnels between the home agents, as a form of RO.
This distribution is also effective for scaling and load balancing. A global home might have multiple sites,each one composed of a number of home agent. Bindings are distributed over the home agents andredistributed by a routing protocol.
302 Part I: Implementing IPv6 Services
302 Part I: Implementing IPv6 Services
The distributed home network requires coordination between the home agents across the Internet to set up amesh of tunnels and establish routes over these tunnels. This is the core of the global HAHA protocol, whichhas been presented to the IETF.
Virtual Home Network
A virtual home network is a specific case where the home link is not a physical link. In fact, this model isapplicable to both MIP and NEMO, and in the NEMO case, it applies orthogonally to any of the previousmodels. Practically, the home link can be configured on a loopback interface or on an automatic (point tomultipoint) tunnel, which resolves the other tunnel endpoint dynamically using the binding cache.
The virtual home model provides a higher availability of the home link, but an external system, such asHSRP, should be put in place to ensure a real high availability of home agent itself, which was partiallycovered by the home agent discovery and DHAAD mechanisms. However, physical mobile nodes on a virtuallink cannot return home.
Another advantage of the virtual home model is that it saves all the ND-related link-layer activities (homeagent discovery, DAD, proxy ND). As a result, the home agent process could be simpler and more efficient.
IP Mobility in Nonmobile Scenarios
IP mobility could also be valuable today in deployments that are not related to devices in motion. MIPv6 hassome characteristics that make it valuable outside mobility usage:
MIP is a dynamic, on-demand tunnel setup protocol, and NEMO enables some routing over it. Thiscan be used as a tool to build a meshed overlay on the Internet, such as a VPN.
•
MIP provides an indirection mechanism in the Internet. This might be used for various purposes, forexample load balancing.
•
MIP exposes a flat network to the rest of the world. This could be used within a private network tohide its topology.
•
When the mobile node is not at home, the HoAddr acts as an identifier of the node and of its binding,separated from the CoA that acts as a locator. As a result, MIPv6 and NEMO enable some devicemanagement and network configuration independent of the final deployment location.
•
IPv4 to IPv6 Transitioning
During the transition phase from IPv4 to IPv6, hotspots that actually provide IPv6 connectivity will be scarceand MIPv6 mobile node as well as NEMO mobile routers should support an alternate roaming technologyover IPv4. Also, real mobility scenarios include satellite and mobile phones (GPRS, EDGE), which do notprovide IPv6 services at all.
A number of Internet Drafts propose to modify MIPv6 and NEMO to tunnel MIPv6 over IPv4, registering anIPv4 CoA to a HA IPv4 address. At the moment, these solutions lack support for NAT traversal, RO, separateIPv4 tunnel termination, and require an upgrade of both the mobile node and the HA.
There is also an existing list of transitioning solutions (ISATAP, 6to4, Teredo, reviewed in Chapter 3,"Delivering IPv6 Unicast Services"), but these solutions fail to traverse in a simple fashion all types of NATand PAT that are heavily deployed today, and their variety makes it difficult for an MN to figure outautomatically which given solution it should use after roaming to a new access network.
Part I: Implementing IPv6 Services 303
Part I: Implementing IPv6 Services 303
On the other hand, there is a real value in combining MIPv6 and IPv4 (NAT) traversal technologies.MIPv6/NEMO brings a mobile node to home agent tunnel and a binding cache into the picture, as well as akeepalive procedure. The MIP cache can be used to store the PAT/NAT states, and the frequency of bindingflow can be tuned to keep the PAT/NAT active. As a result, it is possible for an IPv6 MN to traversePAT/NAT with no protocol overhead or additional states in the network.
This is the essence of the Doors protocol detailed in draft-thubert-nemo-ipv4-traversal. Doors encapsulate theIPv6 packets in an IPv4/UDP tunnel between the client and a stateless gateway, which can be collocated withthe home agent or totally independent from it and placed at a boundary between IPv4 and IPv6. Doors operateas a bump in the client (mobile node) stack, which forges an IPv6 CoA based on a pair of IPv4 addresses andUDP ports. As such, doors are transparent to the MIPv6 support in both the client and home agent.
Figure 8-11 shows a topology where doors apply.
Figure 8-11. Doors
[View full size image]
Interestingly, the mobile node does not need to be mobile per se; and coupling MIP with an IPv4 traversaltechnique can become a tool with a much wider scope than initially intended, and provide connectivity forIPv6 nodes over a PAT/NAT IPv4 infrastructure.
Topology Hiding
NAT in IPv4 was invented 10 years ago with a primary goal of slowing down the IPv4 address-spacedepletion. But since then, NAT has been widely deployed and additional benefits have emerged, such as somesense of security and network isolation. With the drawbacks associated with NAT (reviewed in Chapter 1,"The Case for IPv6An Updated Perspective"), it was decided not to require/support NAT in IPv6. On theother hand, today's deployments rely on some of the NAT-emerged benefits, so IPv6 ought to offer anequivalent solution. Internet Draft draft-ietf-v6ops-nap reviews a list of NAT benefits and suggests IPv6alternative solutions where needed. A good example is the capability of NAT to hide the internal topology ofa private network to the public side.
If a network manager wants to conceal the internal IPv6 topology, and the majority of its host computeraddresses, a good option will be to run all internal traffic using unique-local addresses (ULA), becausepackets using these addresses are confined within the site (or the VPN in case of a multi-site topology). Issuesarise as soon as some hosts need to access public resources. If they use global routable IPv6 addresses to doso, they expose de facto a subset of the internal topology.
An attractive method to hide the internal topology is to deploy a MIPv6 home agent at the boundary betweenthe public and private domain. A global prefix is set up as a home network and advertised within both theprivate domain and the global Internet. All nodes inside the private domain that need to reach the Internet or
304 Part I: Implementing IPv6 Services
304 Part I: Implementing IPv6 Services
to be reachable from the Internet are set to be MIPv6 mobile nodes for that home agent, statically oron-demand using MIPv6 bootstrapping techniques. In MIP terms, their ULAs are used as CoA to accessInternet resources and the MIP tunnel is set up inside the private space.
When needed, and as described in RFC 3775, the MN establishes a tunnel with the home agent and becomesvirtually located on a home link. This arrangement provides a flattened image of the site and hides its truestructure to the outside. Only the nodes that are currently registered can be joined from the outside, and thehome agent is a single point of control for firewalling purposes.
When a node inside the site needs to establish a new connection, it determines whether the destination isinside or outside.
If the correspondent is inside and the node is not mobile, the node uses its inside address (ULA) as source anddoes not use MIP. If the node is mobile, the node selects its HoAddr as source and forwards the packet overits MIP tunnel via the home agent. RO is permitted and desired.
If the correspondent is outside, the node selects its HoAddr as source and forwards the packet over its MIPtunnel via the home agent. RO is not permitted and would not work anyway because the CoA is onlyreachable within the site.
When a correspondent initiates a new connection, the node responds using the same means. If thecorrespondent is outside, it reaches the node via its HoAddr. MIP encapsulation takes place.
Figure 8-12 illustrates how MIPv6 can be used to hide the internal topology of a private site, when accessingpublic resources over an MPLS SP backbone.
Figure 8-12. Using MIPv6 to Hide Internal Topology
[View full size image]
Part I: Implementing IPv6 Services 305
Part I: Implementing IPv6 Services 305
In Figure 8-12, the customer site Site 1 belongs to VPN A. It is connected to the SP backbone using a virtualrouting/forwarding (VRF) instance named red (see Chapter 7, "VPN IPv6 Architecture and Services," fordetails on VRF). It can either access the VPN A server located in VPN A at Site 2 (FC00:201::55) or theInternet server located behind the IPv6 Internet (2001:700::44) using the technique described in Chapter 7.
Traffic directed to public address 2001:700::44 is encapsulated in a MIPv6 tunnel using unique-localaddresses (FC00:101::/64) to reach the home agent, collocated at router CE1. Traffic directed to privateaddress (FC00:201::55) is sent directly to PE1 without any encapsulation.
Community of Interest
Another hot topic where MIPv6 could facilitate deployments is the so-called "community of interest." This issomething that you could think of as a "closed user group" for IPv6. The idea is to group a set of addressableIPv6 devices together and enable communication between them while disabling or limiting communicationfrom devices outside the group. This is similar to a community VPN, but without the setting, management,and security overhead. MIPv6 provides a way of achieving this independently of the application. By creating alevel of indirection, MIPv6 enables the deployment of a "hub-and-spoke" topology, where the home agent islocated at the hub, and controls which devices and which applications can communicate.
Route Projection
The next step for the NEMO working group is to define a RO mechanism that would enable a more directpath between mobile routers. When applied to the community of interest for NEMO, this would turn thehub-and-spoke model into a mesh of routers, maintained by NEMO RO, as an overlay on the Internetinfrastructure.
The general term for this model is route projection. Route projection consists in dynamically setting up atransient tunnel between two routers and then exchanging a set of fine-grained routes for a limited time overthat tunnel.
On one hand, this compares to the BGP backbone that sustains the Internet. But in the backbone, the tunnelsare manually configured and permanent, and the prefixes are much aggregated and stable. Route projectionwould introduce a new level in the hierarchy, with the current Internet serving as backbone.
On the other hand, this compares with the traditional route injection model. With route injection, a new prefixis injected at one end of the Internet, and slowly diffuses into the whole infrastructure until it is finallyreachable globally. With route projection, the routing states are only advertised on-demand to the preciousfew peers in a community that need them and are allowed to get them.
The route projection model allows a quasi infinity of communities to form overlay meshes over the Internet.Communities do not need to interfere with each other or with the infrastructure, and do not require additionalstates in the Internet. As a result, route projection introduces a new way to scale the Internet, and to deployIPv6 networks over and transparently to the current infrastructure.
Server Load Balancing
A number of solutions have been imagined, invented, patented, and deployed for building web server farms.In most cases, a cluster of servers is advertised to web clients as a single entity whether a single name or asingle IP address. As MIPv6 provides an indirection to the network address, it can be used as a load-balancingtechnique at layer 3.
306 Part I: Implementing IPv6 Services
306 Part I: Implementing IPv6 Services
To achieve this, the servers of the given cluster are configured as mobile nodes. They are associated with oneanother by statically or dynamically assigning the same HoAddr to the members of the cluster. The HoAddrbecomes the network identification of the server cluster, returned by the DNS.
MIPv6 establishes a tunnel between the home agent, acting as load balancer and each of the mobile nodes,acting as servers, thereby enabling the HA to distribute a given request to one of the mobile nodes via theassociated tunnel. When a web client issues a server request targeting this HoAddr, the request reaches thehome agent. The home agent can then decide to forward it to one of the mobile node belonging to that cluster,based on server load, distance, or any other usual metric. Figure 8-13 presents a cluster of servers behind ahome agent load-balancing web client requests.
Figure 8-13. Server Load-Balancing Using MIPv6
[View full size image]
Next Steps in Mobility
Although RFC 3775 is a significant step in defining the main concepts and aspects of mobility, someapplications, such as Voice over IP, require additional functionalities. These functionalities, such as fastermovement detection and smoother handover, deal with the time-sensitive aspects of certain applications andservices.
Forthcoming Evolutions
Working groups at IETF and IEEE are already working on a number of additional features that would berequired to support certain applications (Triple Play, for example) and use cases (aviation, cars). This sectionelaborates on the hottest mobility-related topics currently considered by the standards bodies.
Faster Roaming
It is well known that mobility is widely deployed today for voice applications and most if not all based onlayer 2 roaming. IP mobility is not even a niche market. Some studies for the fourth-generation voice network,however, consider Voice over IP and IPv6 mobility for their core technologies.
Part I: Implementing IPv6 Services 307
Part I: Implementing IPv6 Services 307
To meet the seamless handover requirement demanded by interactive applications, a mobile node needs toperform its network attachment detection and its access router selection within 50 to 100 ms after the roamingtook place. IPv6 is leading the way with make-before-break approaches such as Fast MIP (see RFC 4068) andContext Transfer Protocol (CTP).
Proactive techniques for smoother handover, better interaction with layer 2 for movement detection,additional advertisements for access router selection, mobile and correspondent routers, and regional and localmobility are actively being addressed by several working groups at the IETF.
Part of the handover problem is the lack of interaction between the layer 2 and the layer 3; the Ethernetabstraction, emulated by 802.11, was not designed to support hosts moving around. As a result, the layer 3 isnot informed when a layer 2 roaming occurs and cannot take actions in due time. Several transient solutionsbased on layer 2 triggers and SNMP traps have been proposed. Layer 2 and layer 3 triggers are being definedat the IEEE 802.21 working group.
Movement Detection
Traditional routing and bridging were not designed for mobility: Transparent bridging states are, by design,slow to establish, to avoid the meltdown syndrome, loops forming in the bridged fabric with no TTL toterminate them. In addition, most routing protocols will collapse if the links flap and the nodes change theirpoints of attachment without due announcement. Moreover, because the 802.11 radio interface is inheritedfrom Ethernet, there is no provision for mobility-related API, and a layer 2 roaming operation often occursunbeknownst to the network layer.
MIPv4 proposes a layer 3 movement detection based on the ICMP Router Discovery Protocol (IRDP)messages beaconed by the foreign agents as MAC layer broadcast. Similarly, MIPv6 extends the RouterAdvertisement messages to detect the network attachment as quickly as possible in a generic layer 3 fashion.Neither technique, however, offers a handover time that would make roaming transparent to voiceapplications.
To adapt to mobility, a node must first detect when movement occurs, control it if possible, and then act onthe movement to restore the connectivity. With IPv6, a number of means have been introduced at the networklayer to detect the movement, and making this detection as fast as possible is the goal of the activity at theIETF Detecting Network Attachment (DNA) working group.
Attachment Router Selection
When a movement is detected, or if new information is obtained about the routers available in the vicinity, amobile node might roam. The mobile node selects the new attachment router as its default gateway and itautoconfigures a new address from a prefix advertised by that router.
Mobile routers can attach to one another and form a shallow tree rooted in the infrastructure, called a nestedNEMO.
Additional layer 3 information is needed to avoid loops and optimize metrics such as depth in the resultingstructure. This information should also indicate the capabilities by the potential attachment router in term ofreachability (for instance, whether it is connected to the Internet). Internet Draft draft-thubert-tree-discoveryproposes a generic algorithm based on autonomous decisions by each mobile router for building looplessnested NEMO structures.
308 Part I: Implementing IPv6 Services
308 Part I: Implementing IPv6 Services
Integration with Mobile Ad-hoc Networking
Extensive work has already been performed, in the Academia, and within the MANET working group at theIETF and IRTF, around mobile ad-hoc networking. As opposed to MIP, which focuses on a node that changesits point of attachment around the Internet, the goal here is to allow a local communication between unrelatednodes using their persistent global addresses.
A number of experimental standards have been published already, but none widely deployed. MANET is nowworking on standard track solutions, such as OLSRv2 and DYMO.
A MANEMO group is being created to define the MANET for NEMO that would optimize the localreachability while preserving the global reachability. A smooth integration of MANET and NEMOtechnologies can enable applications such as nested NEMO and mesh networking.
Multihoming
A home agent might want to check whether an MNP is registered by a unique mobile router, which, if theHoAddr is constructed out of the mobile prefix, ensures that a HoAddr is unique. But, it might be desirable,for redundancy reasons, that two mobile routers share an ingress link, and both register a same prefix at thesame time, with different HoAddrs, guaranteed unique by the DAD mechanism on the shared ingress link.
How can the home agent make sure that they are actually connected, and more so, that they keep moving as agroup and never split? What would happen if they did? How does the home agent balance the traffic to theMNP over the two available tunnels?
It might happen as well that home itself is multihomed, causing the mobile router to support more then oneprefix; this problem is quite analogous to the traditional site multihoming. Also, a mobile router might want tomaintain more than one tunnel with, maybe, more than one home agent and form multiple CoAs.
There are, in fact, more scenarios with NEMO multihoming than with site multihoming, which is not an easyproblem by itself. This is why the MULTI6 working group at the IETF rejected explicitly to consider themultihoming problems related with mobility, which is now being handled by the MONAMI working group.
Route Optimization for NEMO
Figure 8-14 illustrates a nested NEMO configuration with a visiting mobile node (VMN) attached to a mobilerouter (MR2) itself attached to mobile router MR1.
Figure 8-14. Route Optimization for NEMO
Part I: Implementing IPv6 Services 309
Part I: Implementing IPv6 Services 309
The VMN might be a visitor's laptop, used from inside a rental car in a large parking lot of a supermarket. Inthat example, packets need to be relayed by a mobile router in another car, to the access point, which is out ofdirect reach.
By means of the NEMO basic support, MR1 establishes a tunnel with its home agent (HA1) and installs itsdefault route over that tunnel, and so does MR2 with HA2. As a result, MR1 encapsulates all packets fromMR2 and sends them to HA1. And finally, by means of MIPv6, VMN establishes a tunnel with its home agent(HA-VMN) and installs its default route over that tunnel.
As a result, to reach a supermarket that is two 802.11 hops away, all the packets from VMN are encapsulateda first time by VMN itself, then by MR2, and then by MR1. Hence, each packet sent by VMN carries fourIPv6 headers! Consider a Voice over IP application using an 8-Kbps codec such as G.729a and taking a voicesample every 20 ms, with a transmission rate of 50 packets per second. Each additional IPv6 header is anextra 16 Kbps, which is twice the actual payload.
It may happen that MR1's home network is located at the other end of the country, and that the visitor lives onthe other side of the ocean. As a result of the outer encapsulation, all packets cross the country, aredecapsulated by HA1, and then come back a few blocks away, are decapsulated by HA2, and then cross theOcean, are decapsulated by HA-VMN, to finally come back to the supermarket, in line of sight of the visitor.The latency incurred by this absurd travel is incompatible with voice communications. This effect is calledpinball routing, a packet bouncing across the Internet, for home agent to home agent.
For a larger packet, the three levels of encapsulation might cause a fragmentation, and if by chance onefragment is lost, the rest of the packet makes it all the way to be finally lost in the reception buffers.
The NEMO working group is producing a problem statement for its RO. It will recharter to actually focus onthat specific problem, spinning off MANEMO for MANET integration and MONAMI for multihoming.
310 Part I: Implementing IPv6 Services
310 Part I: Implementing IPv6 Services
A Vision
Initially, the so-called "mobiquity" will be mostly about mobile routers and nodes forming trees to reach theInternet. But, inner connectivity within that fringe will also be required to sustain local applications, as long asthe appropriate services to locate the persons and the services are deployed in the vicinity.
With the emergence of millions and then billions of interconnected devices, we might be on the eve ofpervasive networking, a vision for the Internet where every person and every device is connected to thenetwork in the ultimate realization of Metcalf's law. When this happens, the Internet landscape might nolonger look like anything familiar.
Pervasive networking requires a new model to scale the Internet, which could start with self and group-centricabstractions of the network overlaid on the current IP infrastructure, and enabled by NEMO RO.
It means self-centric nodes, with little to no configuration, and no prior knowledge of the transient peeringsthey might establish and use over time, in some tit-for-tat, anonymous and innocuous cooperation.
It means nodes enjoying an unrestricted mobility over wireless connectivity, always reachable by the preciousfew with the relevant needs and rights.
It means atomic networks, with all the necessary application support, merging and splitting dynamically,interconnecting logical administrative domains within and in between the mobile nodes. And more . . .
Chapter 9. Securing IPv6Networks
It is regularly stated that IPv6 is more secure than IPv4. Infact, this argument is often used to promote thedeployment of IPv6. The assertion stems from the originalmandated use of IPsec in host-to-host communication, asspecified in RFC 2401. It is a natural requirement in thecontext of IPv6's intent to provide a new infrastructure thatsupports peer-to-peer applications. If this mandate wouldbe enforced by all hosts, properly implemented by allapplications, and a reliable and efficient key-exchangesystem would be universally adopted, it would mean amore secure data transport. The consistent use of IPsec onhost-to-host communication would also enable networkoperators to track sources of attacks. Nevertheless, itwould not prevent application layer security threats, whichare common.
Note
RFC 2401's requirement to use IPsec on all hosts mightlimit IPv6 adoption for certain communication devices.Mobile phones, for example, might not have the capabilityto implement IPsec. To stimulate the adoption of IPv6 bythe third generation of mobile systems, the IPsecrequirement might become optional in the future.
Part I: Implementing IPv6 Services 311
Part I: Implementing IPv6 Services 311
At this time, however, the conditions for a consistent useof end-to-end security are not in place; so for the most part,IPv6 is neither more nor less secure than IPv4. Bothprotocols face most of the same threats. IPv6 specificitiesbring new perspectives on some types of attacks. Thesespecificities along with protocol security enhancementsintrinsically close the door for some threats, although opennew doors for others. Moreover, the likely coexistence ofthe two versions of IP can potentially offer attackers newvenues to exploit security holes and to circumvent thedefenses of one protocol to attack the other.
This chapter reviews the security threats faced by an IPv6infrastructure and its users. It draws a parallel to IPv4,highlighting differences and similarities. The review isbased on an exhaustive study of this topic by SeanConvery and Darrin Miller in the white paper, "IPv6 andIPv4 Threat Comparison and Best-Practice Evaluation."Table 9-1 summarizes the topics covered later in thischapter.
Table 9-1. Review of Security ThreatsThreat IPv6 Characteristics MitigationThreats with New Considerations in IPv6Reconnaissance Scanning for hosts is not
feasible because of largeaddress space.Well-known addresses, inparticular multicast, arevulnerable.
Same as IPv4. Privacyextensions can makereconnaissance lesseffective.
Unauthorized access End-to-end securityreduces the exposure.Extension headers (EH)open new attack venues.
Use privacy extensionsto reduce a host'sexposure. Use multipleaddresses with differentscopes. Manage EH use.
Header manipulation IPv6 can take advantageof chained and large-sizeEHs.
EHs that must beprocessed by all stacksare particularly useful toan attacker.
The EHs usage shouldbe strictly controlledbased on deployedservices.
Fragmentation No fragment overlapshould be allowed inIPv6, but some stacks doreassemble overlappingfragments. The impact oftiny fragments is minimalin IPv6.
Use properlyimplemented stacks thatdo not allow fragmentoverlap.
Layer 3/layer 4 spoofing The use of tunnelingoffers more spoofing
Same mitigationtechniques as with IPv4.
312 Part I: Implementing IPv6 Services
312 Part I: Implementing IPv6 Services
opportunities eventhough they are notdifferent from IPv4tunneling.
Host initialization and address-resolution attacks DHCP has similarvulnerabilities for the twoprotocols. NeighborDiscovery has similarvulnerabilities as ARP.Statelessautoconfiguration andrenumbering offer newattack options.
Use an interim solutionsuch as static neighbors;the SENDrecommendations areadopted by the IPv6stacks.
Broadcast-amplification attacks (Smurf) No concept of broadcastin IPv6, and that reducesthe amplification options.
Use filtering formulticast traffic, inparticular, because it isthe only amplificationoption.
Routing attacks IPsec provides additionalpeering security for someprotocols. From a threatperspective, it is similarto IPv4.
Same as IPv4. Whereverpossible, implementIPsec.
Viruses and worms Same as IPv4. Randomscanning used by wormsto propagate isimpractical in IPv6because of the largeaddress space.
Same as IPv4.
Transition-mechanism attacks New ports to open inIPv4 firewalls. Automatictunnels are moresusceptible to attacks.IPv6-IPv4 translation canhide the sources ofattacks.
Tighter control of portsopened in the firewalls;open only the onesneeded. Use statictunnels when possible.
Mobile IP Embedded in IPv6. Hasspecific security features.
Filter out all routingheaders except Type 2 ifMIPv6 is used. SecuringMIPv6 beyond IPsec is awork in progress.
Threats with Similar Behavior in IPv4 and IPv6Sniffing Same as IPv4. Same as IPv4Application layer attacks IPsec offers the potential
to increase security andto track attackers.
Similar to IPv4, securityultimately relies on hostdefenses.
Rogue devices Same as IPv4. IPsec can preventinteraction with suchdevices. Lower-layerprotocols such as 802.1xcan be used to blockunauthorized devicesfrom connecting to thenetwork.
Part I: Implementing IPv6 Services 313
Part I: Implementing IPv6 Services 313
Man-in-the-middle attacks IPsec can protect so longas the key is not stolen.
There is a big need for ascalable andoperationally feasibleauthentication andkey-exchangemechanism.
Flooding attacks Same as IPv4, with a fewadditional traffic types.
Use traffic-limitingmechanisms.
The analysis of the security threats is complemented with a set of best practices rules that apply in each casepresented. The security tools available for IPv6 in Cisco devices are also discussed in this chapter.
Note
The best practices recommended should be viewed in the light of the fact that at the time of this writing thereis limited experience operating IPv6 networks.
Before tackling IPv6 security, it is important to discuss the typical IPv4 topology to implement perimetersecurity. On one hand, this discussion would help choose the best way to integrate IPv6 in the existentnetworks without weakening deployed security measures. On the other hand, because of the similaritiesbetween the two protocols, it is likely that the same concepts will be used to secure IPv6 networks, too.
Figure 9-1 shows the typical topology used in deploying perimeter security for IPv4 networks. You can adddedicated devices such as intrusion detection systems (IDSs) to this topology if the functionality is notsupported by the same device that acts as a firewall. Additional levels of security are most likely implementedat the host level, particularly for important devices and resources.
This figure shows is a common approach to securing networks, but this setup relies on fact that its perimetercan be clearly identified. Many books are available for more in-depth information about IPv4 security such asSean Convery's Network Security Architectures.
314 Part I: Implementing IPv6 Services
314 Part I: Implementing IPv6 Services
Security Threats and Best Practices to Protect Against Them
The relatively small-sized IPv6 deployments of past years did not render them uninteresting to hackers.Attacks surfaced shortly after IPv6 was deployed, based on concepts previously used with IPv4 or takingadvantage of IPv6-specific vulnerabilities. It is therefore reasonable to relate the IPv6 security threats to IPv4and group them into two categories: threats with new considerations in IPv6, and threats with similar behaviorin IPv4 and IPv6. This classification is reflected in the recommended security best practices for mitigatingthese threats. Some recommendations are extrapolations of their IPv4 counterparts, whereas others arecompletely new and specific to IPv6.
Threats with New Considerations in IPv6
IPv6-specific features can make some common attacks more difficult while opening new vulnerabilities. Thissection analyzes those threats that have to adapt to these features as well as new threats that can impactexclusively IPv6.
Reconnaissance
Reconnaissance is not necessarily an attack, because it will most likely not impact negatively the network orthe users. However, it typically is the precursor of an attack and it is intended to provide the attacker withinformation about the victim.
Characteristics
The common IPv4 practice of ping sweeps is not an option anymore with IPv6. It would take years to scan 264
hosts on a typical network of length /64 even if it is done at high rates, rates that would most likely triggersecurity alarms. For this reason, Network Mapper (Nmap), a tool commonly used in IPv4 to identify activehosts, does not even support IPv6 ping sweeps. With IPv6, other mechanisms must be used for reconnaissancepurposes:
DNS crawling DNS crawling remains an option with IPv6. With the elimination of Network AddressTranslation (NAT) and the difficulty of remembering 128-bit addresses, the use of Dynamic DNSmight increase in an IPv6 environment. If the DNS resources are not properly secured, they canprovide information about many hosts.
•
Reducing the scope of the search for hosts The attacker can make a smart choice that could helpnarrow down the address space that needs to be scanned. One can try hosts with easy-to-rememberinterface IDs, such as ::1, ::FFFF, and ::F00D. Because the layer 2 burned-in address (BIA) is oftenused to generate the EUI-64 interface ID of hosts, one can focus the scan on addresses of certain NICvendors based on their organizational unit identifier (OUI).
•
A compromised network element A compromised network element can also provide information onlocal hosts via the neighbor cache.
•
Use multicast addresses standardized for certain protocols This mechanism enables the attacker toidentify key systems such as routers and DHCP servers. Addresses with larger scope are preferredbecause they do not require the attacker to be on a victim's local link. Site scope addresses such as AllRouter (FF05::2) or All DHCP Servers (FF05::1:3) can be targeted.
•
The larger network addresses can potentially pose challenges to the propagation of Internet worms from oneprefix to another because it is more difficult to identify active hosts on a prefix other than that of the infected
Part I: Implementing IPv6 Services 315
Part I: Implementing IPv6 Services 315
host. Locally, an infected host can send a ping to the all-nodes multicast address to find active hosts within itsown prefix.
Best Practices
The recommended best practices deal with each aspect of reconnaissance discussed in the preceding section:
Minimize attacker's chance to discover active hosts.
Do not assign easy-to-guess addresses to key systems and network elements.
Implement the privacy extensions (see the "IPv6 Unicast Address" section in Chapter 2, "An IPv6Refresher") for the addresses used to communicate outside the internal network. Doing so limits theamount of time a given host address can be targeted. The disadvantage of using the privacy extensionsis that the host is difficult to track for internal management purposes. For this reason, networkmanagers may want to disable the use of privacy extensions.
Note
The use of privacy extensions is not suitable for all deployments. In particular, service providers needto be able to track customers for various reasons, including regulatory requirements. In both enterpriseand service provider environments, privacy extensions makes user tracking more difficult.
•
Stop Internet Control Message Protocol (ICMP)-based scanning.
Filter unnecessary ICMP traffic at the network edge while being mindful of its importance in thecontrol plane of IPv6.
Block ICMP echo packets sourced from outside the internal network. Permit the neighbor-androuter-discovery traffic as well as "Packet Too Large" messages used for the Path MaximumTransmission Unit (PMTU) Discovery process.
•
Implement edge security measures.
Use firewalls to filter unnecessary services. Control multicast traffic at the edge, and stop site-scopedexternal traffic while containing internal traffic. Enforce scoping at the network border.
•
Enforce host and application security.
Enable security tools such security agents and virus scans.
•
Unauthorized Access
To be able to exploit the vulnerabilities of hosts and servers, attackers must first reach them through IP. Ahost's ability to communicate implies IP accessibility. The most a network administrator can do to protect thehosts is to control some of the means that an attacker can use to covertly reach them. Network elements anddevices can be used to filter traffic types identified as possibly supporting attacks.
Characteristics
Traffic filtering remains the primary means at a network's disposal to protect hosts from unauthorized access.Such filtering is commonly performed at layers 3 and 4 by routers and firewalls. It applies to IPv6
316 Part I: Implementing IPv6 Services
316 Part I: Implementing IPv6 Services
deployments as it did to IPv4 ones, but with a few specific considerations:
Increased use of end-to-end encryption in IPv6 Can reduce the effectiveness of some filteringmechanisms by hiding the higher-level protocol information.
•
EHs Can be used to get unauthorized access to hosts. With the integration of Mobile IP (MIP) in IPv6,the hosts became particularly exposed to attacks through Type 0 routing headers. That threat wasaddressed through the introduction of a MIP-specific, Type 2 routing header (see Chapter 8,"Advanced ServicesIPv6 Mobility"). However, the routing header is still in usefor example, in thelink-local operation of IPv6 multicast (see Chapter 6, "Providing IPv6 Multicast Services").
•
ICMP Can be used not only for reconnaissance but also to gain access to hosts. ICMPv6, however,plays a more significant role in the proper operation of the network, so its filtering cannot be asaggressive as it was in IPv4.
•
Multicast traffic Should be filtered and inspected in the same manner as it is in IPv4. However, IPv6relies on several specific multicast groups for its proper operation (see Chapter 2).
•
Anycast traffic Should in principle be destined exclusively to routers per RFC 2373. With anincreased interest in expanding the use of anycast, its monitoring might become even more importantwhen you consider the problems identified with its use of IPsec, as discussed in RFC 3547.
•
Best Practices
The following best practices are recommended to deal with the aspects of filtering IPv6 previously mentioned:
Using multiple addresses with various scopes and leveraging the privacy extensions can helpminimize the exposure of enterprise hosts to attackers.
•
When IPsec is used end to end by internal hosts, the firewalls and router filters can manage packetsonly based on layer 3 information. IPv4 faces this problem, too.
Note
If only the Authentication Header (AH) is used, the layer 4 information is still accessible formonitoring and filtering.
•
The EHs necessary for the proper operation of the services deployed in the network should beidentified and allowed through the filters. Specific security policies should be defined for the allowedEHs based on the service and function they support.
Note
The Cisco IOS implementation of extended access lists was enhanced, beginning with Cisco IOS12.4(2)T, to filter based on the routing type, thereby allowing routers to differentiate between EHsused for MIPv6 and for source routing. Only Type 2 routing headers should be allowed to support aMIPv6 service.
•
The IPv4 ICMP policies should be matched by the IPv6 ICMP policies. The following types shouldbe permitted:
- ICMPv6 No route to destination (Type 1, Code 0)- ICMPv6 Time exceeded (Type 3)- ICMPv6 Echo request and echo reply (Type 128 and Type 129, respectively)
•
They should also be complemented with few additional important types:•
Part I: Implementing IPv6 Services 317
Part I: Implementing IPv6 Services 317
- ICMPv6 Packet too big (Type 2) for PMTU Discovery- ICMPv6 Parameter problem (Type 4)- ICMPv6 Multicast listener (Type 130132, 143)- ICMPv6 Router solicitation and router advertisement (Type 133 and 134, respectively) forlink operation- ICMPv6 Neighbor solicitation and neighbor advertisement (Type 135 and 136, respectively)for link operation
Multicast traffic can be filtered based on scope. Also, any traffic with a source address (SA) that is amulticast address should be blocked. Network administrators should be aware that the capabilities offirewalls to filter multicast or anycast traffic are likely limited at this time.
•
Header Manipulation
The IP header structure was changed in IPv6, and these changes provide new venues to attack hosts andnetworks. The EHs in particular can be used in environments that do not pay attention to their usage.
Characteristics
The routing headerbased security threats that were mentioned earlier in this chapter are not the only ones toexploit the EHs in attacks. The other EHs can also be used by an attacker in at least three different ways:
Manipulate EHs with contents that have to be processed by network elements or hosts.• Chain a large number of EHs to force the security devices and mechanisms to do long lookups into apacket, possibly beyond their capabilities, to get to the information that reveals an attack. Thisapproach could provide the means to hide an attack.
•
Use large-size EHs or a large number of EHs to drain the resources of the devices that have to dealwith the EHs.
•
Poor IPv6 stack implementations could be particularly targeted with the help of EHs.
Note
It is important that hosts enforce the standardized rules for handling EHs. Firewalls should be able to filterbased on EHs. The IDSs should be able to alert when detecting noncompliant EHs.
Best Practices
Network administrators might have a limited ability to control the IPv6 stacks deployed on the hosts, so thebest defense against this type of attack is to filter out traffic with any EHs that are not supporting deployedservices. The routing header is of particular interest because of its use for various protocol implementations.
Note
It is also important to understand the default handling of EHs by the network elementsthat is, their capabilityto process multiple or large EHs.
318 Part I: Implementing IPv6 Services
318 Part I: Implementing IPv6 Services
Fragmentation
IP packet fragmentation can serve two purposes to threaten a network. First, it can be used to hide an attackfrom firewalls or IDSs. These devices would have to reconstruct the packets to discover attack patterns.Overlapping fragments and out-of-order fragments can further complicate the job of detecting possibleattacks. Second, IP packet fragmentation can be used to overwhelm network elements that are supposed to dofragmentation or handle these fragments in any special way.
Characteristics
IPv6's perspective on how and where fragmentation should be performed in a network has a significant impacton the threat level of fragmentation attacks. The fact that only end hosts are allowed to perform fragmentation(see RFC 2460 for details) protects network elements from certain types of attacks. The other aspects offragmentation in IPv6 security are as follows:
No fragment overlapping should be allowed in IPv6. An attacker could send a stream of fragmentsand then follow up with fragments that carry the attack information. The receiver's reassemblyalgorithm overwrites the original fragment that contained harmless information and therefore passedthrough security checks with the new fragment containing the attack. This type of attack can bestopped by enforcing the "no-overlap" rule at the network or end-user stack level.
•
The impact of tiny-fragments types of attacks can be reduced. An attacker could choose to sendsmall-enough packets that would push the information that reveals an attack into the second fragmentof the stream. The security measures generally act on the information in the first fragment, so theattack can be masked. Because RFC 2460 recommends the minimum packet size of 1280-bytes,network policies can be implemented where all packets (except for the last fragment) of smaller sizeare dropped. One drawback of such policies is their impact on applications that rely on smallerpackets, such as Voice over IP (VoIP). At the same time, the PMTU Discovery algorithmimplemented by some IPv6 protocol stacks could be adversely impacted by the policy mentionedabove. For example, the algorithm can start the search at 1500-byte frames that might be too large forthe PMTU. Then drop to 750 (binary search), which would be dropped because of the policy. All thesubsequent packet sizes in the binary search steps would be dropped, leading to a falsely unsuccessfulsearch.
Note
Hosts can still send smaller packets and can be proven inconvenient if they have to be analyzed by thefirewalls.
•
Out-of-order fragments can still be used in attacking poorly implemented IPv6 stacks. This is a threatfor hosts, but could be a threat for network elements if the traffic is destined to them.
•
Best Practices
The following are recommended best practices for dealing with the fragmentation security threats:
Dropping the fragments smaller than 1280 bytes could help mitigate the "tiny-fragments" threats, butsuch a policy could impact services that benefit from using small-size packets (VoIP).
•
The "no overlapping fragments" rule should be enforced by all devices.• Deny fragments destined to network elements such as routers.• Devices that monitor the traffic based on layer 3 and 4 information for security risks should be able tohandle the case where EHs push upper-layer information into the second fragment. In these cases,
•
Part I: Implementing IPv6 Services 319
Part I: Implementing IPv6 Services 319
some level of reassembly might be necessary.
Layer 3/Layer 4 Spoofing
An important aspect of an attack and even a common attack strategy is the spoofing of the layer 3 and layer 4information about the originator. It makes the source untraceable, and it can force the device whose addresswas spoofed to have to deal with the response to the attack.
Characteristics
Most aspects of IPv6 spoofing threats are similar to IPv4. Tunneling mechanisms provide a new venue ofattack where the spoofing weakness of both protocols can be used. A few protocol specifics must beconsidered in the case of this class of threats:
Layer 3 spoofing relies on replacing the real source address of the attacker with a random one (in useor reserved) or with that of a victim. In IPv4, the typical mitigation technique is filtering based onRFC 2827 and to identify traffic with SAs incongruent with its source. The implementation of RFC2827 verifies only that the SA is on the expected subnet, so an attacker could still spoof the address ofother users on the same subnet. The same mitigation technique can be used for IPv6, but itsaddressing leads to some specific characteristics:
- The assignment policies and the aggregation properties of the IPv6 addressing schemeallows for easier implementation of RFC 2827 filtering. Organizations can therefore containrogue traffic with simple access control lists (ACLs).- The larger address space implies a larger number of interface IDs, which can still be spoofeddespite RFC 2827 implementation.- IPv6 also offers the option to spoof layer 3 addresses in EHs. In particular, routing headerscan be used as carriers of spoofed information.
Note
Currently, no mechanisms can trace the source of spoofed traffic down to the interface ID of the SA.Any implementation would involve a correlation between layer 3 and layer 2 information on hosts.User-tracking tools, such as Campus Manager 4.0 discussed in Chapter 10, "Managing IPv6Networks," can be used to help identify misbehaving hosts. As mentioned earlier, privacy extensionscan make the tracking process more difficult.
•
Layer 4 spoofing relies on getting the victim to react to a fake application. There is no differencebetween IPv6 and IPv4 in terms of supporting and combating this type of threat.
•
Tunneling mechanisms can provide ways to further hide the source of attacks through spoofing, asdiscussed later with regard to 6to4 tunnels.
•
Figure 9-2 shows a spoofing attack leveraging a 6to4 tunnel. The spoofed address in this case is the anycastaddress of the 6to4 relay router. The attacker can similarly spoof the address of other IPv6 nodes.
Figure 9-2. Spoofing Attack Using a 6to4 Tunnel
[View full size image]
320 Part I: Implementing IPv6 Services
320 Part I: Implementing IPv6 Services
The 6to4 relay forwards the inner part of the packet, removing the IPv4 header (which makes it difficult totrace the source of the packet). There is no packet amplification benefit intrinsic to this type of attack. Theattacker can spoof a global unicast address, but it can also spoof the anycast address of a 6to4 relay router.Several measures can limit this type of threat:
Verify that the outer IPv4 address matches the IPv4 address embedded in the 6to4 IPv6 address.• Block tunneled packets that embed the IPv4 anycast address used for the 6to4 relays (192.88.99.1).•
These measures can be implemented on all devices supporting 6to4 tunneling. The impact of such attacks isnot dramatic because no amplification mechanisms can be leveraged with them. You can find a completeanalysis of the security threats related to 6to4 tunnel deployments in RFC 3964.
Best Practices
The most powerful tool currently available for combating spoofing is the implementation of filtering, basedon the recommendations of RFC 2827. Effective filtering allows networks to contain spoofing trafficgenerated within and to narrow down to the subnet level the location of the attacker.
Note
In the case of IPv6, only the traffic sourced from addresses in the blocks currently allocated by IANA shouldbe permitted: 2001::/16, 2002::/16, 2003::/16, 2400::, 2600::, 2A00::, and 3FFE::/16.
The Unicast Reverse Path Forwarding (uRPF) feature performs a similar function, and it is currently availablefor IPv6. This feature is discussed in further detail later in the chapter in the section "Unicast Reverse PathForwarding."
The tunnels can be secured using IPv4 IPsec to reduce the threat of spoofing. This can easily be done in acontrolled environment, but can also be implemented in open environments with the help of Internet KeyExchange (IKE).
Part I: Implementing IPv6 Services 321
Part I: Implementing IPv6 Services 321
The use of end-to-end IPv6 IPsec should help reduce the number and forms of spoofing attacks.
Host-Initialization and Address-Resolution Attacks
The attacks in this category target the host-initialization process of acquiring an address and other operationalinformation such as default gateway and DNS servers. They also target the process of resolving the layer3-to-layer 2 address binding. The attack can disrupt these processes or try to redirect a host's traffic to acompromised device. In IPv4, these threats target protocols such as Address Resolution Protocol (ARP) andDynamic Host Configuration Protocol (DHCP). Several features are used in IPv4 to protect against thesetypes of attacks (DHCP snooping attacks, for instance).
Characteristics
The host bootstrap process and the layer 2 address-resolution process were modified in IPv6, leading toIPv6-specific host-initialization and address-resolution attacks:
DHCPv6 remains a host-initialization option. It is also often considered in conjunction with statelessautoconfiguration. DHCP-PD (Prefix Delegation) is also used to provide prefixes to routers. In allthese instances, the protocol faces attacks similar to the DHCP potential attacks in IPv4.
•
Stateless autoconfiguration is a host-initialization feature specific to IPv6 and implemented inICMPv6 as discussed in Chapter 2 of this book. The router solicitation or router advertisement (RA)messages can be spoofed to provide the host with the wrong initialization information or with theaddress of a compromised device acting as a gateway. An attacker can also interfere with a host'sinitialization process by replying to its Duplicate Address Detection (DAD)-driven neighborsolicitation.
•
The renumbering capabilities of IPv6 are based on the RA packets. An attacker can modify the RAs totrigger a renumbering of all the hosts on a network segment. The consistent use of the AH wouldclose this security hole.
•
Neighbor Discovery (ND) performs the IPv4 ARP functionality. In its original definition detailed inRFC 2461, no security mechanisms are built in to the protocol, so it is as vulnerable to attacks asARP. Using IPsec between the nodes would involve prohibitively large management overheadbecause it implies static associations.
•
Note
The threats to ND are discussed in detail in RFC 3756. Work done in the Securing Neighbor Discovery(SEND) working group of IETF led to the recently published RFC 3971, which provides non-IPsec securitymechanisms for addressing the ND threats:
A mechanism for certifying routers with a trust anchor that a host consults before accepting a router tobe its default gateway.
•
Cryptographically generated addresses generated with the help of a private and a public key and usedto verify the ownership of an address used in ND messages.
•
Introduction of a signature based on the RSA-based cryptographic scheme that is used to protect allND messages.
•
A timestamp and a nonce (random number used only once) option were introduced to prevent replayattacks.
•
SEND enabled hosts can operate together with non-SEND hosts.
322 Part I: Implementing IPv6 Services
322 Part I: Implementing IPv6 Services
These threats are particularly relevant in environments where the physical layer is not secured (such aswireless environments).
Best Practices
These types of attacks imply a breach in the physical access of the network, which clearly provides theattacker with many opportunities, regardless of protocol. Addressing this security breach should be the firststep in mitigating such problems. With layer 1 and layer 2 secured based on specific mechanisms (PublicSecure Packet Forwarding, for example), the attention can shift to layer 3 security solutions. In the case ofIPv6, static neighbor configuration for critical systems could be a way to mitigate address-resolution attacks.Manual address configuration can be a temporary solution to threats based on the stateless autoconfigurationprocess.
Broadcast-Amplification Attacks (Smurf)
Broadcast-amplification attacks are a type of denial-of-service (DoS) attack in which an ICMP echo is sent tothe broadcast address of a prefix and with the spoofed address of the victim. All hosts on the destination prefixin turn send an echo reply to the victim, overwhelming it.
Characteristics
In IPv6, there is no concept of broadcast. To get any amplification with such an attack, the destination address(DA) can at best be multicast. RFC 2463 clearly states that an ICMP reply should not be generated for packetsthat have a multicast DA, a layer 2 multicast address, or a layer 2 broadcast address. If all stacks implementthe RFC properly, it provides a good level of protection against this type of attack.
Best Practices
No major best practices can be recommended in this case other than traffic filtering for unnecessary multicasttraffic to decline the attacker any amplification venues. To complement the constraints provided by RFC2463, it could prove useful to also block traffic that has layer 3 multicast SAs.
Routing Attacks
A network's routing functions can be impaired in multiple ways. Routing process resources can be drainedthrough flooding attacks or by simulating transitional states such as route or neighbor flapping. Attackers canalso attempt to insert their devices in the routing topology or compromised routers and corrupt the routinginformation.
Characteristics
Routing protocols did not change significantly in IPv6, so there are minor differences in the structure ofrouting attacks for the two versions of IP. The relevant change is the fact that although Border GatewayProtocol (BGP; see RFC 2545), Intermediate System-to-Intermediate System (IS-IS) and Enhanced InteriorGateway Routing Protocol (EIGRP) still use Message Digest 5 (MD5) authentication for the routing updates;Open Shortest Path First version 3 (OSPFv3; see RFC 2740) and Routing Information Protocol nextgeneration (RIPng; see RFC 2081) use IPsec (Authentication Header and Encapsulating Security Payload) fortheir communications with neighbors. The IPsec-based protection provides an increased level of securitycompared with the previous mechanisms.
Part I: Implementing IPv6 Services 323
Part I: Implementing IPv6 Services 323
Note
IPsec protection can be integrated in EIGRP, but as of this writing it has not been implemented yet. IS-ISbenefits from the fact that it exchanges routing information using layer 2 packets, which are more difficult tospoof.
Time-To-Live (TTL) checks can also be used to ensure that routing updates are not coming from farther awaythan what would be expected based on the size of the network managed. Such updates could be spoofedmessages used for an attack.
Best Practices
Several basic best practices are recommended to protect the routing processes:
Routers should be secured from unauthorized access.• Secure the communication between the routers through IPsec wherever the feature is supported orthrough traditional authentication mechanisms.
•
Implement any flooding control mechanisms that could protect the router resources, and the routingprotocol control messages should be a high priority.
•
Viruses and Worms
The most damaging security threats remain viruses and worms that operate at the application layer. Theyimpair primarily hosts, but some side effects can impact the IP infrastructure, too.
Characteristics
Considering the OSI layer affected by this type of threats, there should be little difference between theiroperation in an IPv4 or an IPv6 world. The most significant difference to note is the fact that the largeraddressing space makes it impossible for viruses to spread in an IPv6 environment by scanning active hosts onprefixes other than that of the infected device. As mentioned earlier, such a process would take too much timeto be of practical value. On the other hand, after a host is compromised, a virus could potentially use all nodes'multicast traffic to impact other hosts on the same link.
Best Practices
The typical security measures implemented in IPv4 against this type of threat can be used in IPv6, too. Youcan complement perimeter security via firewalls and IDS systems with up-to-date antivirus software on thehosts.
Transition-Mechanism Attacks
The mechanisms developed for a seamless and gradual migration from IPv4 to IPv6 offer new attack venuesthrough which attackers can leverage weaknesses in the security policies and capabilities of both IPv4 andIPv6.
324 Part I: Implementing IPv6 Services
324 Part I: Implementing IPv6 Services
Characteristics
The tunneling and translation concepts used in IPv6 migration mechanisms have been used in IPv4, too, andthat means they share the same types of vulnerabilities. Therefore, the threats enabled by IPv6 migrationtechnologies neither new nor unique:
Dual-stack environments are threatened over both IP protocols.• IPv6 tunneling mechanisms require new ports to be open in the edge firewalls.• Similar to IPv4, automatic tunnels are more susceptible to attacks than manual tunnels. Well-knowntunneling resources such as 6to4 relays can be particularly targeted. In the case of IPv6, you canmitigate this problem if you secure the tunnels with the help of IPv4 IPsec wherever possible.
•
The IPv6-to-IPv4 translation mechanisms have similar vulnerabilities as NAT in IPv4. They are alsoresponsible for hiding sources of attacks behind the translated addresses.
•
Best Practices
The security best practices for mixed IPv4 and IPv6 environments have to take into consideration the variousways in which IPv6 can be deployed in existent networks:
On dual-stack devices, similar security tools and features should be implemented for both protocols,both within the network and at the network perimeter.
•
Leverage IPv4 IPsec to secure IPv6 tunnels whenever possible. If IPv4 IPsec cannot be used to securethe IPv6 tunnels, static tunnels should be preferred over the dynamic ones wherever possible.Firewalls should open access only for the ports of deployed and operated tunnels.
•
Devices performing protocol translation should be viewed as potential gateways for attacks. At aminimum, the security measures discussed for the various threats should be implemented for eachprotocol on the two sides of the translation.
•
A Note on Mobile IPv6 Security
Mobility is a feature intrinsic to IPv6, so it implies IPv6-specific security concerns. Sniffing,man-in-the-middle, DoS, and masquerading attacks are all threats to Mobile IPv6. A great deal of work wentinto securing the feature to ready it for deployment. IPv6's easy leverage of IPsec is helpful; however, it is notalways applicable to many environments that intend to use MIPv6. Many of the devices used in mobilenetworks, such as mobile phones or PDAs, do not have the computational power to fully implement IPsec. Soalong with this obvious mechanism for securing communications in IPv6, new lighter security mechanismshad to be created.
Chapter 8, "Advanced ServicesIPv6 Mobility," focuses on mobility, and includes a section on security.
Threats with Similar Behavior in IPv4 and IPv6
Several familiar threats behave similarly whether they are executed over an IPv4 or an IPv6 infrastructure. ForIPv6 deployments, you must be mindful of these types of attacks and implement protective measures based onexperience gained securing IPv4 networks.
Sniffing
The process of capturing traffic in transit from one host to the other is called sniffing. It can be done withvarious tools, such as TCPdump or Ethereal, and the captured information can be investigated for informationthat can open other access venues for the attacker.
Part I: Implementing IPv6 Services 325
Part I: Implementing IPv6 Services 325
Assuming that the attacker cannot get the keys used for IPsec, the encrypted packets will be of no use to him.IPv6 with IPsec can, under these conditions, eliminate the threat of sniffing. For the time being, however,IPv6 is not more secure than IPv4 with respect to this type of attack.
Application Layer Attacks
Most attacks occur at the application layer, so the transport layer features are irrelevant. IPsec, if usedconsistently and universally by the hosts, can prove beneficial to trace the source of an attack. On the otherhand, the general use of IPsec reduces the benefits that IDSs provide because they cannot search for attackpatterns inside the encrypted packets. Ultimately, hosts must protect themselves at the application layer.
Rogue Devices
Rogue devices are unauthorized devices inserted in a network as an instrument for an attack. They can be oract as switches, routers, access points, or resources such as DNS, DHCP, or AAA servers. IPsec can helpprevent interaction with such devices.
Man-in-the-Middle Attacks
A device that manages to insert itself in the communication path between two hosts represents aman-in-the-middle attack. IPsec can protect against such attacks so long as the attacker cannot get the keyused to encrypt the communication.
Flooding Attacks
Flooding attacks are meant to busy out infrastructure or host resources. They can disrupt thepacket-forwarding or control-plane functions of the network. Rate limiting can be used to mitigate suchattacks. On dual-stack interfaces, it is likely that IPv6 traffic is rate limited more aggressively to protect theexistent, revenue-generating IPv4 services.
6PE Security
Based on their operational similarities, 6PE and IPv4 VPNs can share the same security policies. On the otherhand, 6PE's role of a "global VPN" for offering IPv6 Internet access services opens the door to other possibleattack vectors. 6PE's use can expose a service provider's infrastructure to potential attackers. Following aresome of the threats that should be considered and the corresponding countermeasures:
IPv6 users can discover aspects of the IPv4 infrastructure. 6PE's dependency on the underlying IPv4Multiprotocol Label Switching (MPLS) network can lead to information leaks. To avoid suchproblems, the 6PE deployment should avoid using IPv6 addresses that incorporate IPv4 information.For example, it should not use 6PE router IPv6 loopback addresses constructed from its IPv4loopback address. IPv6 traceroutes should be explicitly blocked because they could reveal the IPv4addresses of the P-routers. An alternative is to configure P-routers (via the no mpls ip propagate-ttlforwarded command) not to propagate TTL for traceroutes.
•
The IPv4 service can be impacted by IPv6 attacks on 6PE routers. If the same provider edge (PE)router supports both IPv6 (6PE) and IPv4 services at the same time, an attack over IPv6 will impactthe IPv4 service, too. To protect against such attacks, the IPv6 addresses of the 6PE routers should notbe advertised outside the provider network. ACLs can also be used to control access to 6PE routers.Control-plane protection mechanisms (see the subsection later in this chapter) can also be used toguard the PE router resources against IPv6 attacks. However, the best way to avoid this type of
•
326 Part I: Implementing IPv6 Services
326 Part I: Implementing IPv6 Services
exposure is to deploy PE routers and Route Reflectors (RRs) dedicated to the IPv6 service.
The key security concern of enabling 6PE in a network is that it could reveal IPv4 infrastructure information.The best practices mentioned previously for addressing this issue should be implemented even if 6PE is usedonly for a trial service.
A Note on VPN Security
Up to this point, the analysis has focused on the characteristics of the threats and the mitigation best practicesfrom the point of view of both unicast and multicast IPv6 services. The subject of securing MIPv6 was alsocovered, so the only major service left unmentioned is VPN.
There is no significant difference between securing VPNs in IPv4 and IPv6. In both CE-based and PE-basedVPNs, the same concepts apply. The security aspects of IPv6 VPNs are discussed in Chapter 7, "VPN IPv6Architecture and Services." For more details about IPsec VPNs in IPv4, refer to IPSec VPN Design by VijayBollapragada, et al. At the time of this writing, however, the features needed to secure IPv6 VPN serviceswere not yet available.
Note
Whenever an IPv4 IPsec VPN session is available, it can be used to secure the transport of IPv6, too.
One interesting security challenge is raised by the elimination of NAT in IPv6. Although it provides someprotection, NAT should never be considered a security feature. Nevertheless, in IPv4 it provides the fringebenefit of hiding the internal network addressing and topology from the outside world.
In IPv6, the lack of NAT makes it impossible at this time to open up an IPv6 VPN toward the rest of theworld without exposing the internal addressing and structure of the network. Tight perimeter security canprotect the IPv6 network against attacks. The negative impact of removing NAT is being analyzed within thev6ops IETF working group (see draft-vandevelde-v6ops-nap-01.txt), and workarounds for this particular issueare starting to emerge. The "Topology Hiding" section of Chapter 8 describes a possible elegant way to hidethe internal topology of a private network with the help of MIPv6.
Note
The security best practices used for deploying 6PE and discussed in the previous section are applicable to thedeployment of 6VPE, too.
Tools Available for Securing IPv6 Networks
The threat analysis leads to the conclusion that more similarities than differences exist betweenIPv4 and IPv6 as far as security is concerned. Until end-to-end IPsec and a reliable key-distributionprotocol is consistently deployed for IPv6, the proven IPv4 security best practices and tools shouldbe used to secure the IPv6 networks, too. It is thus important to evaluate the IPv6 readiness of thesetools. Although perimeter security is critical, security policies and tools are implemented and used
Part I: Implementing IPv6 Services 327
Part I: Implementing IPv6 Services 327
in multiple parts of the network.
IPsec for IPv6
IPsec is the networking community's answer to the need for secured communication. It was definedin RFC 2401, and conceptually it operates under the same principles in IPv4 and in IPv6.
IPsec Concepts
The implementation of IPsec has two elements:
Authentication Header (AH) is defined in RFC 2402, and it provides source authentication,connectionless integrity, and protection against replay. In IPv6, it is implemented throughan AH extension header.
•
Encapsulating Security Payload (ESP) is defined in RFC 2406, and it providesconfidentiality, source authentication, connectionless integrity, and replay protection. InIPv6, it is implemented through an ESP extension header.
•
You can use AH by itself (if regulations do not allow traffic to be encrypted and the use of an ESP).
There are two modes of securing the traffic between two hosts:
Transport mode In transport mode, IPsec is used end to end between the hosts. In this case,only the payload of the packet is secured. This is the model promoted by IPv6.
•
Tunnel mode In tunnel mode, the packets from a host are transported over a trusted networkto a security gateway. They are then encapsulated in another packet and securelytransported to the destination or to another security gateway that places them on anothertrusted network for the destination. In this case, the entire original packet, payload, andheader are secured. This model is commonly used in IPv4 networks today.
•
In both cases, the process of securing the communication is started by establishing a securityassociation (SA), which is a unidirectional logical connection that encompasses all the participatingelements. These elements include the authentication algorithm, authentication key, encryptionalgorithm, encryption key, and so on. These parameters are negotiated between the two participantsin the SA. In transport mode, a host clearly has to establish multiple SAs. It can differentiatebetween them by using a Security Parameters Index (SPI). These two IDs, the SA and the SPI, arereferenced in every IPsec-protected packet.
In IPv6, two EHs were defined to support IPsec. Figure 9-3 shows their format.
Figure 9-3. Authentication and Encapsulating Security Payload EHs
[View full size image]
328 Part I: Implementing IPv6 Services
328 Part I: Implementing IPv6 Services
The sequence number is a variable that is initialized to zero when the SA is set up. It ticks up withevery packet sent, and that helps keep track of out-of-sequence packets and of played-back packets.
Note
The security key is one important element needed for authentication and encryption. Work is stillbeing done to identify a reliable protocol for key distribution. Cisco IOS routers use InternetSecurity Association and Key Management Protocol (ISAKMP; IKEv1), as defined in RFC 2408,to provide key management and authentication. However, without a generally adoptedauthentication scheme, its use is limited in the public domain. Manually configured keys are alwaysan option, but they pose provisioning and management challenges.
Using IPv4 IPsec to Secure IPv6 Tunnels
IPsec is frequently deployed in today's IPv4 networks to secure communication over VPNs. It isused for access VPNs as well as inter-site VPNs. IPv6 transition mechanisms can leverage such aninfrastructure to achieve a certain level of security, even in the absence of IPv6 IPsec.
Remote IPv4 hosts access private networks by establishing an encrypted access VPN to a gatewayset up for these purposes. If the same host is enabled for IPv6, it can thread an IPv6 tunnel throughthis IPv4-secured communication channel. Because the IPv4 VPN places the remote host on theprivate network, a natural IPv6 tunnel choice is the Intra-Site Automatic Tunnel AddressingProtocol (ISATAP), which is suitable for intra-site communication. In practice, however, you canuse any type of IPv6 tunnel as long as it is supported by the host and a gateway is set up for it insidethe private network.
The configurations for the IPv4 access VPN and the IPv6 tunnel are completely independent. TheIPv4 VPN configuration is beyond the scope of this book, but there are plenty of examples inreferences dedicated to this topic (refer, for example, to IPSec VPN Design by Vijay Bollapragada,
Part I: Implementing IPv6 Services 329
Part I: Implementing IPv6 Services 329
et al.). Chapter 3, "Delivering IPv6 Unicast Services," contains router configuration examples forthe various IPv6 tunnel types. From a host perspective, the tunnel configuration depends on theparticular operating system used. For example, if ISATAP is used in the topology shown in Figure3-11 (Chapter 3) and the host is running Windows XP, the host tunnel configuration would be justone line entered in the command window:
netsh interface ipv6 isatap set router 200.13.13.1
In this example, the IPv4 VPN initiated by the host is terminated at the edge of the private networknot identified in Figure 3-11.
Note
The IPv4 MTU of the host is usually lowered for the IPv4 VPN. The same should be done for theIPv6 MTU to avoid fragmentation.
The "Topologies Examples" section of Chapter 7 shows an example of how to secure the IPv6traffic between two routers by setting up an IPv6 tunnel through an inter-site IPv4 IPsec VPN.Although the example discusses the case of a manually configured tunnel, the same concept appliesto any IPv6 tunnel type, static or dynamic. The example uses a static crypto map, which implies thefact that the routers have fixed IPv4 addresses and are using shared keys. You can implementdynamic maps when the routers acquire their IPv4 addresses dynamically, as in the case of remotesites provisioned every time they connect to the network.
Securing Routerto-Router Communication with IPv6 IPsec
Until IPv6 IPsec is extensively and uniformly deployed as suggested by RFC 2460, it can still beused on a smaller scale. IPv6 IPsec can be leveraged to secure both the control and the data planebetween two routers. The "OSPFv3" section of Chapter 4, "IPv6 Routing Protocols," shows anexample of using IPsec (with static key) to secure a routing protocol. Cisco IOS software also offersa mechanism for securing the data traffic between two routers through a new type of tunnel thatemploys IPv6 IPsec. IKEv1 is used for key management. Figure 9-4 shows a topology in which thisfeature is used between Routers A and B.
Figure 9-4. Using IPv6 IPsec to Secure the Data Exchange Between Two Routers
[View full size image]
330 Part I: Implementing IPv6 Services
330 Part I: Implementing IPv6 Services
Except for the tunnel itself, the configuration of this feature is similar to that used in securing thecommunication between two routers with IPv4 IPsec. On Router A, the steps to configure the IPsecportion are as follows:
Create the ISAKMP policy. Pre-shared keys are used in this example:
crypto isakmp policy 1 authentication pre-share
•
Define the pre-shared key and the address of the peer:
Define the IPsec parameters that are to be used for IPsec encryption between the two IPsecrouters:
crypto ipsec profile ExampleIPsec set transform-set 3des
•
Figure 9-4 shows the tunnel interface configuration for each router.
The operation of this feature is similar to the IPv4 one, so the same troubleshooting commands andmethods apply in the case of IPv6 IPsec (refer to IPSec VPN Design by V. Bollapragada, et al.).This is a useful tool to secure the inter-site communication.
Part I: Implementing IPv6 Services 331
Part I: Implementing IPv6 Services 331
Access Control Lists
Access control lists have proven themselves to be versatile instruments in identifying targetedtraffic for further or particular processing or for filtering. For the most part, the IPv6 ACLs aresimilar to the IPv4 ACLs, but a few differences are worth pointing out:
The packet header format offers several extra fields that should be recognized by the ACLs.• New ICMP types are supported.• The implicit rules of the ACLs need to account for the fact that the ND process relies on alayer 3 protocol (ICMPv6).
•
The use of multiple addresses per interface has to be accounted for when designing theACLs.
•
IPv6's renumbering features can present challenges for ACLs when two different prefixescoexist on a given network segment.
•
The existence of potentially multiple EHs makes the ACL matching against the firstfragment nondeterministic.
•
The differences between the IPv4 and IPv6 ACLs stem from the IPv6 protocol specificities thathave been discussed throughout this book.
Extended IPv6 ACLs and Stateful Filtering
Extended ACLs are supported for IPv6 in a similar way to IPv4. Numbered ACLs are not supportedfor IPv6. Additional parameters are available to deal with some of the IPv6 protocol and operationalspecifics listed earlier.
Example 9-1. Options Available in Cisco IOS Command Line When Configuring an IPv6 Access List
Router(config)#ipv6 access-list EXAMPLERouter(config-ipv6-acl)#permit host 2001:1::1 2001:2::/64 ? dscp Match packets with given dscp value flow-label Flow label fragments Check non-initial fragments log Log matches against this entry log-input Log matches against this entry, including input reflect Create reflexive access list entry routing Routing header sequence Sequence number for this entry time-range Specify a time-range
The implicit rules at the end of the IPv6 ACLs reflect the operational importance of ND. Theypermit the neighbor advertisement and neighbor solicitation ICMP traffic, as shown here:
permit icmp any any nd-napermit icmp any any nd-nsdeny ipv6 any any
Similar to IPv4, if the packet does not meet any of the matching criteria, it is dropped by default.
Note
332 Part I: Implementing IPv6 Services
332 Part I: Implementing IPv6 Services
The implicit rules for the IPv6 ACLs do not take into account the fact that IPv6 hosts need to doPMTU Discovery. To allow the PMTU Discovery process to work through the filters, the ICMPv6Type 2 (Packet Too Big) packets have to be allowed through in both directions.
Stateful filtering is supported with IPv6 ACLs, too. The reflect option enables an ACL's permitstatement to generate an access entry for the return packets of a flow it allowed through (refer to thebook Implementing Cisco IPv6 Networks by Regis Desmeules). This dynamic access entry can bein turn applied to other ACLs with the use of the keyword evaluate, as shown in Example 9-2.
Example 9-2. Reflexive Access List Configuration Example
interface FastEthernet6/1.10 ipv6 address 2001:1::1/64 ipv6 traffic-filter IN in ipv6 traffic-filter OUT out
ipv6 access-list IN permit tcp any eq www host 2001:2::1 reflect REFipv6 access-list OUT evaluate REF
Based on the ACL called IN, any www TCP connection request that comes inbound interfaceFastEthernet6/1.10 for the server 2001:2::1 will be allowed through. For each connection, adynamic permit entry is built under REF for the reply packet coming from the server. REF isincluded in the ACL called OUT, which will apply the return path dynamic entry outbound on theinterface.
The reflexive ACL entries are active for a period of time (3 minutes by default) or until a FIN isdetected for a TCP session.
Note
The implicit deny any any does not apply at the end of reflexive ACLs. Multiple evaluate entriesare allowed per ACL.
Time-based ACLs can be created for IPv6 in the same fashion as for IPv4. They identify ACLs thatare valid only for certain time intervals.
IPv6 ACLs and Fragmentation
When IP packets are fragmented, not all the fragments contain the information relevant to the ACLmatching process. In IPv4, most of the layer 3 and layer 4 information is available in the firstfragment, so the ACL can perform a full match on it. The noninitial fragments typically would notcontain the layer 4 information, so at most a match can be done on the layer 3 header. Because ahost cannot use the noninitial fragments if the first fragment was filtered, it is safe to apply an ACLstatement that contains layer 4 criteria only on the first fragment. The keyword fragment in an IPv4ACL indicates that after the layer 3 information is checked, all noninitial fragments are permitted orpushed through the subsequent ACL line depending on whether the statement is a permit or a deny
Part I: Implementing IPv6 Services 333
Part I: Implementing IPv6 Services 333
(refer to the Cisco document "Access Control Lists and IP Fragments" at Cisco.com).
In IPv6, on the other hand, the router has to first parse through several Next headers before reachingthe Fragmentation header to extract the information on the fragment. Then it must parse throughsome more EHs to get to the upper-layer information. Therefore, the first fragment might notcontain all the necessary information. In IPv6 ACLs, the keyword fragment has the same meaningas in IPv4 with the exception that the filter applies to all noninitial fragments as well if theupper-layer protocol cannot be determined from the first fragment.
Note
IPv6 supports a new keyword, undetermined-transport, for matching IPv6 packets for which thelayer 4 information could not be extracted.
Firewalls can handle fragmented packets comprehensively. They can track all fragments by sourceaddress, destination address, protocol, and IP ID. This allows both the PIX and the Cisco IOSFirewall to apply the filtering policies to all fragments without any of the assumptions mentionedearlier.
IPv6 Access List Example
The concepts presented in this section of the chapter are captured in a practical example for thetopology shown in Figure 9-5.
Figure 9-5. Topology for the Access List Example
[View full size image]
The edge router (ER) has to implement the following policies with the help of ACLs:
Stop traffic with unique-local source addresses from leaving the internal network. It shouldlog any attempts to do so to track misconfigured hosts.
•
Block any outside traffic with the routing EH.• Deny any outside traffic with undetermined transport.•
Allow only DNS traffic from 2001:B:1::/64 to reach the DNS server and for the DNS toreply to that traffic.
•
Allow only WWW traffic from 2001:B:1::/64 to reach the web server daily between 8 a.m.and 5 p.m.
•
Allow traffic necessary to support the PMTU Discovery process.• Secure the Telnet access to the router.• Permit all traffic sourced from inside of the network if it uses the global unicast address.•
These conditions are met with the ACL and interface configuration shown in Example 9-3.
Example 9-3. Access List Configuration Implementing the Policies Listed Above
interface FastEthernet0/0 ipv6 address 2001:1:1::1/64 ipv6 traffic-filter EXAMPLE-IN in ipv6 traffic-filter EXAMPLE-OUT out!interface FastEthernet0/1 ipv6 address 2001:A:1::1/64 ipv6 address FD01:A:1::1/64!ipv6 access-list EXAMPLE-IN deny ipv6 any any routing deny ipv6 any any undetermined-transport permit udp 2001:B:1::/64 host 2001:A:1::D eq domain reflect REF-D permit tcp 2001:B:1::/64 host 2001:A:1::F eq www time-range TimeExample reflect REF-T permit icmp any 2001:A:1::/64 packet-too-big!ipv6 access-list EXAMPLE-OUT deny ipv6 FD00::/8 any log evaluate REF-D evaluate REF-T permit ipv6 2001:A:1::/64 any permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any!ipv6 access-list VTY-protection permit tcp FD00::/8 any eq telnet permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any log!time-range TimeExample periodic daily 8:00 to 17:00!line vty 0 4 ipv6 access-class VTY-protection in
The output of show ipv6 access-list summarizes the filtering policies configured on the router.
Firewall Functions
Firewalls have been mentioned as powerful tools used to enforce security policies at the edge of thenetwork. Figure 9-1 depicts the most commonly deployed security topology in IPv4, with the focuson the firewall. Such perimeter defenses will most likely be used in IPv6 networks, too.
Part I: Implementing IPv6 Services 335
Part I: Implementing IPv6 Services 335
Two types of firewalls are offered through Cisco products: Cisco IOS Firewall features and the PIXfamily of products. Both these options are widely used in IPv4 networks, and now they supportIPv6, too.
Cisco IOS Firewall
The Cisco IOS Firewall capabilities are often used in current IPv4 deployments. Many of thesecapabilities have been extended to support IPv6 (refer to the Cisco document "ImplementingSecurity for IPv6" at Cisco.com):
Packet fragment inspection uses the virtual fragment reassembly (VFR) to check forout-of-sequence fragments and duplicated fragments to identify possible DoS attacks.
Note
The Cisco IOS Firewall inspects the following IPv6 packet header fields: Traffic Class,Flow Label, Payload Length, Next Header, Hop Limit, and Source/Destination Address.
•
IPv6 DoS attack mitigation is implemented in exactly the same way as in IPv4.• Tunneled packet inspection is not performed inside the encapsulating IPv4 packet, but itcan be done on the decapsulated IPv6 packet.
•
Stateful inspection of UDP, TCP, ICMP, and FTP sessions.• Stateful inspections of packets that are translated between IPv4 and IPv6.• It handles EHs, Routing, Hop-by-Hop, Options, and Fragment headers.• Port-to-application mapping (PAM) is a feature that enables network administrators tocustomize the TCP and UDP ports being used (that is, so that they are different from thewell-known ports). This feature enables them to exercise content-based access control evenon a wider range of ports.
•
Note
Cisco IOS Intrusion Detection System (IDS) does not support IPv6 at the time of this writing.
Cisco IOS Firewall can perform these firewall features for both IPv4 and IPv6 at the same time andon the same interfaces.
Cisco IOS Firewall feature configuration involves several considerations. You can modify variousparameters that are used for decision making in the inspection process in the global configuration,as shown in Example 9-4.
Example 9-4. Cisco IOS Firewall Feature Configuration Options
Router(config)#ipv6 inspect ? alert-off Disable alert audit-trail Enable the logging of session information (addresses and bytes) hashtable-size Specify size of hashtable
max-incomplete Specify maximum number of incomplete connections before
clamping name Specify an inspection rule one-minute Specify one-minute-sample watermarks for clamping routing-header Enable session routing header inspection tcp Config timeout values for tcp connections udp Config timeout values for udp flows
Note
It is also important to enable audit capabilities of the router that would track the inspect process.The feature is enabled with the global configuration command ipv6 inspect audit-trail.
You can define inspection policies to include the various protocols recognized. The policy definedin Example 9-5 is named FW-EXAMPLE, and it includes inspection of all supported protocols:FTP, UDP, TCP and ICMP.
Example 9-5. Security Policy Configuration Example
Router(config)#ipv6 inspect name FW-EXAMPLE ftp timeout 100Router(config)#ipv6 inspect name FW-EXAMPLE udp timeout 100Router(config)#ipv6 inspect name FW-EXAMPLE tcp timeout 100Router(config)#ipv6 inspect name FW-EXAMPLE icmp timeout 60Router#show ipv6 inspect allSession audit trail is enabledSession alert is enabledRouting Header inspection is disabledone-minute (sampling period) thresholds are [400:500] connectionsmax-incomplete sessions thresholds are [400:500]max-incomplete tcp connections per host is 50. Block-time 0 minute.tcp synwait-time is 30 sec -- tcp finwait-time is 5 sectcp idle-time is 3600 sec -- udp idle-time is 30 secicmp idle-time is 10 secSession hash table size is 1021Inspection Rule Configuration Inspection name FW-EXAMPLE
ftp alert is on audit-trail is on timeout 100udp alert is on audit-trail is on timeout 100tcp alert is on audit-trail is on timeout 100icmp alert is on audit-trail is on timeout 60
After it has been defined, the policy is applied inbound or outbound to the interfaces of interest, asshown in Example 9-6.
Example 9-6. Applying Security Policies to Router Interfaces
Inbound inspection rule is FW-EXAMPLE ftp alert is on audit-trail is on timeout 100 udp alert is on audit-trail is on timeout 100 tcp alert is on audit-trail is on timeout 100
Part I: Implementing IPv6 Services 337
Part I: Implementing IPv6 Services 337
icmp alert is on audit-trail is on timeout 60 Outgoing inspection rule is not set
To troubleshoot the inspection process, you can turn on the corresponding debug. In Example 9-7,the router is inspecting ICMPv6 traffic.
Example 9-7. Sample Debug of the Packet-Inspection Process
The other important tool used to properly inspect the traffic is the virtual reassembly process, whichhas to be enabled on the interface, as shown in Example 9-8.
Example 9-8. Enabling Virtual Reassembly on a Router Interface
Router(config-subif)#interface FastEthernet6/1.10Router(config-subif)#ipv6 virtual-reassemblyRouter#show ipv6 virtual-reassembly FastEthernet6/1.10%Interface FastEthernet6/1.10 IPv6 configured concurrent reassemblies (max-reassemblies): 64 IPv6 configured fragments per reassembly (max-fragments): 16 IPv6 configured reassembly timeout (timeout): 3 seconds IPv6 configured drop fragments: OFF IPv6 current reassembly count:1 IPv6 current fragment count:3 IPv6 total reassembly count:25 IPv6 total reassembly timeout count:0
Example 9-8 captures the output of the show virtual-reassembly command for the interface ofinterest. It lists the number of packets processed and the number of fragments that are beingprocessed at the time.
PIX Firewall
The PIX Firewall is a device dedicated to implementing perimeter security policies. It is widelydeployed in existent IPv4 networks, so it is important to understand its IPv6 capabilities. PIXFirewalls will most likely be used to secure IPv6 services, too.
PIX software release 7.0 is the first to support IPv6. It can perform security checks of IPv6 headersand EHs, multiple protocol (ICMP, UDP, TCP, SMTP, and HTTP) inspection, and through theadaptive security algorithm (ASA) it can perform stateful application inspection. Fordevice-management purposes, the HTTP, SSH, and Telnet clients were also modified to supportIPv6.
Note
338 Part I: Implementing IPv6 Services
338 Part I: Implementing IPv6 Services
In the PIX 7.0 software release, the Cisco Firewall does not support multicast except for what isnecessary for autoconfiguration and ND. Multicast security can be implemented on the edgerouters.
The IPv6 instructions for the PIX are Cisco IOS Firewall based, so they match the commandsdescribed in the "Access Lists" section of this chapter.
Authentication, Authorization, and Accounting
The authentication, authorization, and accounting (AAA) functions are critical in any deployment.AAA is used to manage users and devices or to collect service-usage information for billing. At thesame time, AAA is a security tool, too. No large-scale IPv6 deployment could be rolled out withoutavailable AAA supporting IPv6.
In the first phase of the Cisco IPv6 implementation, the IPv6 AAA features were implemented byextending some of the vendor-specific attributes (VSAs) used for IPv4. Some of these VSAs havecounterpart attributes that are RFC 3162 compliant and implemented for RADIUS. Table 9-2summarizes the IPv6 RADIUS attributes and VSAs, and includes a brief description of their scope(refer to the Cisco document "Cisco IOS IPv6 Configuration Library" at Cisco.com).
Table 9-2. IPv6 AAA and RADIUS AttributesRADIUS Attributes (RFC 3162) VSAs DescriptionNAS-IPv6-AddressFramed-Interface-Id It is a per-user
attribute usedduring IPv6ControlProtocol(IPv6CP)negotiation toindicate theIPv6 interfaceidentifier to beconfigured.
Framed-IPv6-Prefix IPv6Prefix#
It is a per-userattribute usedto indicate theprefix to beconfigured onthe user in thecase of virtualaccess. Thisprefix isadvertised inthe NDmessages. Thenetworkaccess server(NAS) installsa static routefor the prefix.
Login-IPv6-Host It is a per-userattributed thatindicates thesystem that theuser connectswith when theLogin-Serviceattribute ispresent.
Framed-IPv6-Route IPv6Route
It is a per-userattribute thatspecifies theroutinginformationthat should beconfigured forthe user on theNAS.
Framed-IPv6-Pool IPv6Pool
It is a per-userattribute thatidentifies apool fromwhich prefixesare assigned tothe user. Thepool can beconfigured onrouters orRADIUSservers.
IPv6ACL
It specifies afull ACL thatis applied toan interfacewhile a user islogged in.
The configuration of these attributes is straightforward. Example 9-9 shows a user's profile configured on theRADIUS servers. When the user connects to the NAS via PPP, it is provided with the global prefix2001:A:1::/64. An ACL will be applied outbound to stop any traffic sourced from the unique-local addressesused internally.
These AAA features are important, particularly in the case of broadband deployments where large numbers ofusers have to be managed.
340 Part I: Implementing IPv6 Services
340 Part I: Implementing IPv6 Services
Note
The RADIUS server must be IPv6 aware to be able to handle some of the IPv6-specific attributes.
The other option for implementing the AAA functions is to use Terminal Access Controller Access ControlSystem Plus (TACACS+). Despite being more versatile than RADIUS, TACACS+ is not as commonlydeployed because it is more resource intensive (requires more processing and memory). At the time of thiswriting, TACACS+ is not implemented for IPv6 on Cisco IOS software.
Unicast Reverse Path Forwarding
Security policies that implement source address verification are important in eliminating spoofing attacks.These policies prevent spoofing of the source addresses at the prefix level. They should be implemented asclose as possible to the location of unsecured devices and hosts.
An access network is a typical scenario where such policies can be applied. The service provider operating thenetwork wants to make sure that its customers do not attempt to spoof an address on a different prefix fromtheir own. Figure 9-6 shows the case where Host A is stopped from sending traffic using the address of HostB as a source address.
Figure 9-6. Securing an Access Network from Internally Sourced Spoofing Attacks
[View full size image]
The intent is to verify at the access router that customer packets received on an interface have a source addressthat belongs to the prefixes known (based on the routing table) to be out that interface. Access lists can, of
Part I: Implementing IPv6 Services 341
Part I: Implementing IPv6 Services 341
course, be applied inbound to filter the traffic accordingly; however, this can involve management andprovisioning burdens. Another way to achieve the same goal in a dynamic manner is to implement for unicasta mechanism similar to Reverse Path Forwarding (RPF) used in multicast forwarding. Unicast Reverse PathForwarding (uRPF) checks the routing information to verify that the prefix of an inbound packet's sourceaddress is known to be reachable out the interface it was received on. The actual reverse lookup is done in theCisco Express Forwarding (CEF) forwarding table.
Note
All equal-cost paths are considered valid by the reverse lookup.
If the reverse path calculated for the source address does not match the interface on which the packet wasreceived or the source address cannot be identified (malformed source address), the packet is dropped.
This feature implements dynamically the functions of an inbound ACL. It is currently available in Cisco IOSsoftware for both IPv4 and IPv6, and it represents a simple one-line interface configuration, as shown onFigure 9-6. If an ACL is designated at the end of the command ipv6 verify unicast reverse-path, the routerapplies it to the packet that failed the RPF check. The advantage of using the ACL option is that the ACL canbe configured to log the matches and provide information that can be used to track policy violators.
Example 9-10. uRPF Configuration Example
interface ATM0/0/0.1 point-to-point ipv6 address 2001:1:1:1::1/64 ipv6 verify unicast reverse-path exampleRPF pvc 1/32encapsulation aal5snapipv6 access-list exampleRPFpermit ipv6 2001:1:1:1::/64 any log-inputdeny ipv6 any any log-input
The ACL can simply be configured to permit all traffic and log it, in which case the violators of uRPF are letthrough but the violation is logged.
Note
The uRPF, as discussed so far, operates in what is called a strict mode. In strict mode, the router verifies thatthe source address exists in the Forwarding Information Base (FIB) and that it is also known to be reachableout its interface that received the packet. The verification requirements can be relaxed, leading to a "loosemode" uRPF where the router only verifies a source's reachability by checking for its existence in the FIBtable and not the interface it belongs to. The Cisco IOS command to enable the feature is ipv6 verify unicastreachable-via <reachability-options>.
Depending on platform, the performance impact of enabling these features should be considered.
342 Part I: Implementing IPv6 Services
342 Part I: Implementing IPv6 Services
Protecting the Control Plane with Rate Limiting
To defend the network infrastructure from attacks, it is important to protect the control-plane resources of thenetwork elements. Router resources (memory/CPU) on the line card or the route processor can be depleted bybeing overwhelmed with traffic that appears to be important to the control plane. Under such circumstances,the critical processes that maintain the router's integration in the network can be severely impacted.
This type of threat has been identified in the case of IPv4. IPv6 introduces new venues to attack a router'scontrol plane, such as flooding it with router solicitation traffic or packets with the routing header.
Note
A router can be configured using the no ipv6 source-route command to stop processing packets that containthe source routing header.
At first, IPv6 services are likely to be considered of lower priority than the existent revenue-generating IPv4services. This means that a router's control plane has to be particularly protected against IPv6 threats.
Certain types of traffic can be intelligently filtered out, but others cannot be identified a priori as a potentialthreat. In some of these cases, the attack is identified simply by the high rate of traffic received by the router.One defense against these flooding attacks is to limit that rate of traffic accepted by the router and thuspreserve a minimum amount of CPU and memory for the control-plane operation.
The implementation of such mitigation plans depends on platform. Some platforms incorporate rate-limitingprotection mechanisms in their default behavior, whereas others need to be configured for it. Some implementit in hardware, whereas others configure it in software. Cisco IOS command line offers a dedicated interfacefor configuring traffic rate limiting specifically for protecting a router's control plane, as shown here:
This interface leverages the standard QoS tools. A service policy has to be defined based on the guidelinesdiscussed in Chapter 5, "Implementing QoS."
Summary of Best Practices for Securing IPv6 Deployments
The similarities between the IPv4- and IPv6-based threats lead to the conclusion that the security measuresdeveloped and field proven for IPv4 should be used in the case of IPv6. In review, the best practices thatshould be considered in securing an IPv6 deployment are as follows:
Address management and ND Deploy an addressing scheme for communications with hosts withinthe internal network and another for communications with hosts outside the internal network.Implement privacy extensions for enterprise hosts only in conjunction with user-tracking mechanisms.
Assign fixed but nontrivial addresses to key systems.
•
Part I: Implementing IPv6 Services 343
Part I: Implementing IPv6 Services 343
When considered necessary, use static neighbors for key systems.Traffic filtering Stop the traffic sourced from the internal addresses (ULA) from exiting the network.Contain the larger-scope multicast traffic from within the network boundaries.
Filter ICMP traffic, but keep in mind the operational functions of ICMPv6 such as PMTU Discovery.
Stop traffic with EHs that are not necessary to the deployed services from crossing the networkboundaries.
Filter fragments. Deny IPv6 fragments destined to network elements. Drop fragments of packets forwhich the upper layer cannot be determined.
Implement RFC 2847 filtering to contain spoofing attacks.
Block traffic with a source address that is a multicast address.
The IPv4 firewalls and filters should block the ports used by tunneling mechanisms not deployed inthe network.
•
Application security Implementation at both host and network level (with the help of firewalls untilIDS functionality becomes available).
•
Authentication and encryption Applications should use encryption whenever possible.
Use authentication for BGP and IS-IS routing protocols.
Use IPsec for OSPFv3 and RIPng.
Leverage IPv4 IPsec-secured paths for IPv6 tunnels.
Secure data traffic between routers using IPv6 IPsec.
•
IPv6 deployment options Dual-stack deployments are easier to secure and should be preferred overtunneling.
If tunneling is used to interconnect IPv6 islands, static tunnels are preferred over dynamic onesbecause they are more secure.
•
You should apply these recommendations to hosts, routers, and firewalls as applicable. Before designing thesecurity policies to be applied in an IPv6 deployment, it is important to evaluate the capability of the devicesthat support them. All the features necessary to implement the above best practices in Cisco IOS software andin Cisco Firewalls are currently available.
The perimeter security topology described in Figure 9-1 is likely to be applied to the IPv6 deployments, too. Ithas proven itself in the IPv4 networks, and IPv6 services are likely to coexist with the IPv4 ones for a longtime and therefore share a significant part of the infrastructure. Under these conditions, a first step inprotecting the IPv6 deployments is to match the IPv4 security policies for IPv6. The next step is to implementthose policies that are addressing IPv6-specific vulnerabilities.
Chapter 10. Managing IPv6 Networks
Although IPv6 is not a new technology anymore, production-level IPv6 deployments are fairly recent. Theywere preceded by deployments in research entities and government-funded organizations (for instance, inEurope, 6NET, RENATER, GEANT, and so on). Although the objectives and constraints of such networksdiffer from the industry-driven deployments, they have provided valuable experience in managing IPv6,
344 Part I: Implementing IPv6 Services
344 Part I: Implementing IPv6 Services
experience that can be widely leveraged. A large part of this chapter therefore borrows from theseexperiences.
The chapter starts with a review of all the network-management challenges raised by the deployment of IPv6.Subsequent sections cover the network-management architecture and the key management components:
IPv6 information retrieval• Fault management• Performances management• Configuration management•
The IPv6 support of these components on major network-management platformssuch as CiscoWorks andHewlett-Packard OpenView (HP-OV)is analyzed, too. The last section provides a review ofnetwork-management tools and applications that support IPv6.
IPv6 Network Management: The Challenges
The challenge facing service providers (SPs), original equipment manufacturers, software vendors, andintegrators is to develop robust applications that can perform various network-management operations in achanging, multivendor, multiplatform network.
Introducing IPv6 network services raises a key challenge to the network-management and systems operationssupport systems (NMS-OSS) architects: coping with the technical differences between IPv4 and IPv6technologies. New challenges related to network addressing, usability, and network access have to be dealtwith when IPv6 is deployed.
For instance, IPv6 addresses are awkwardly long and unsightly. Users will neither like to see long strings suchas 2001:100:1234:5678:AB12:CD34:1121:2301 nor will they be able to easily recall them, let alone typethem!
Furthermore, IPv6 addresses can change dynamically because of features such as renumbering, privacymechanisms, and autoconfiguration. Dealing with dynamic addresses is not something new fornetwork-management systems (NMSs) when it comes to managing hosts. It is, however, a bigger issue withIPv6 because dynamic address allocation can happen outside a centralized place (such as stateful DynamicHost Configuration Protocol [DHCP] server), depriving the NMS of a convenient central repository of activehosts addresses.
From the user perspective, the IPv6 services bring up questions that revolve around ease of use. Handling thelarge IPv6 addresses is cumbersome, so the use of Domain Name Systems (DNS) becomes more important forIPv6 deployments. The guideline is for applications to use just host names, which are user friendly, and theDNS can take care of renumbering and fallback.
Another challenge for managing IPv6 relates to integration with IPv4 network management: How shouldoperators manage parallel IPv4 and IPv6 services and resources, because IPv4 and IPv6 are expected tocoexist for the foreseeable future?
IPv6 and IPv4 network-management concepts, requirements, and issues are much alike. This makes thechallenges easier to tackle. The tools and applications necessary to meet the IPv6 network-managementrequirements are therefore mostly identical to the IPv4 ones. In most cases, managing IPv6 will entailproviding proper IPv6 support within existing management tools, proper data availability from IPv6-enableddevices, and IPv6-enabled communications channels between the two.
Part I: Implementing IPv6 Services 345
Part I: Implementing IPv6 Services 345
Allocating IPv6 Addresses to Managed Nodes
Chapter 2, "An IPv6 Refresher," in the section "IPv6 Addressing," reviews the main IPv6 address types:unicast (link-local, unique-local, global), multicast, and anycast. It also emphasizes the fact that multipleaddresses configured on an interface are common and expected with IPv6. For an NMS to communicate withan IPv6 node, it is likely that global unicast addresses (could be unique-local) will be used to manage allnetwork elements from a central location. The network operator has multiple options in selecting themechanism to assign global addresses to nodes: static configuration, autoconfiguration, stateful or statelessDHCPv6, or a combination of autoconfiguration with stateless DHCPv6.
From a network-management standpoint, however, not all the configuration methods are equally practical.
Static address configuration, for instance, is rather prohibitive in large-scale networks. The format, the size,and the complexity of IPv6 addresses tend to make it worse. It is not a scalable option, especially whenconsidering the fact that renumbering is a fact of life in a network. Nevertheless, on networking devices andapplication servers, it is recommended to assign a static address that will be known from the NMS. In case ofhardware changes, the configuration can be reloaded in the new box without change on the NMS to manage it.
Stateless autoconfiguration is an attractive alternative for hosts. However, its unpredictability might be aconcern. Upon receiving multiple router advertisements (RAs) from on-link routers, a host builds multipleaddresses, and the network-management station has a hard time figuring out which one to use (see the section"Topology Management" for further details) to reach the host. This may not be an issue for unmanaged hostssuch as desktop and laptops.
Although stateful DHCP proves quite useful with IPv4 in helping the NMS to learn node addresses, statefulDHCPv6 is not widely available on commercial IPv6 stacks (at the time of this writing). It is, however,available on Cisco Network Registrar (CNR) 6.2 and reviewed in the section "Configuration and ProvisioningManagement."
Integrating IPv6 and IPv4 Network Management
Managing IPv6 nodes from the NMS requires the following elements:
Instrumentation on IPv6-enabled devices to deliver IPv6 network-management data• Transport of the data between the IPv6 device and NMS, using IPv4 or IPv6• NMS application capability to handle/analyze/present the data•
If network-management information transport is not supported over IPv6, IPv4 NMS applications couldmanage the IPv6 devices just like any other IPv4 device as long as they have IPv4 reachability from thenetwork-management platform.
As a major evolutionary step, IPv6 introduces numerous mechanisms and features in the area of transitioningand coexistence with IPv4, including tunneling mechanisms (manual and automatic), IPv6 over MPLS (6PEand 6VPE), and translation mechanisms (NAT-PT). All these mechanisms are reviewed at length in Chapter3, "Delivering IPv6 Unicast Services," and Chapter 7, "VPN IPv6 Architecture and Services." Although theyhelp the coexistence of the two protocols, the transition mechanisms raise new challenges for the NMS.
When tunnels or translation mechanisms are deployed on the path from the NMS to the IPv6 devices, theNMS must be provided with the capability to traverse those tunnels. It might mean that the NMS supportssome of the transitioning mechanisms, most specifically those used by hosts (ISATAP, Teredo, and so on).
Topology discovery is another area of concern with IPv6. The size of the IPv6 addresses as well as therandomization in some cases of address assignment makes it impossible for an NMS to scan the complete
346 Part I: Implementing IPv6 Services
346 Part I: Implementing IPv6 Services
prefix range for active hosts. At the same time, link-locals are often the only addresses reported from neighborcaches, making the topology discovery a true challenge. In practice, topology discovery of IPv6 networks islikely to rely on IPv4, or be driven by manual configurations.
In the majority of the deployments, IPv6 is expected to coexist with IPv4, not to replace it. This comes at thecost of additional network operation complexity. To minimize this extra complexity, network operators mightchoose to stick with dual-stack devices, managed over an IPv4 transport, using generic (IPv4 and IPv6)management objects. It is an IPv6 transition guideline that whenever a node is not reachable through IPv6,there should be a fallback mechanism to contact it through IPv4.
Note
Minimizing network-management complexity is a bigger objective than it appears, and it can impact thenetwork design itself. For instance, some SPs have expressed a preference for an IPv6 over IPv4 tunnelnetwork design (see Chapter 3 for details) over deploying native IPv6 to reduce operating costs such asnetwork management.
Dual-stack devices appear to offer a practical option for managing IPv6. The type of managed objects and theprotocol used to transport the information are independent. For instance, Simple Network ManagementProtocol (SNMP) can run over IPv4 or IPv6 and report IPv4 or IPv6 Management Information Bases (MIBs).IPv6 configuration management or IPv6 topology management can be operated over IPv4 with minimumchanges in the tools and in the operator habits.
Network-Management Architecture
Network-management architecture somewhat follows the network architecture that was defined in Chapter 3:LAN/enterprise network (site), access, aggregation, and core.
Each of these network layers can identify a network-management domain. Often, each domain is under adifferent administration group. In Figure 10-1, network core, aggregation, and edge are under a single SPresponsibility, and managed as a single entity. The access network and each remote site are managedseparately.
Figure 10-1. Network-Management Architecture
[View full size image]
Part I: Implementing IPv6 Services 347
Part I: Implementing IPv6 Services 347
Each domain is under the control of an operation support organization. This organization manages thenetwork with the help of a network-management integrated system (see the section "Management Platforms"),a set of "individual" tools, or a combination of the two.
Network-management functions are detailed in the "FCAPS" framework specified by the ITU'sTelecommunications Management Network (TMN) as follows:
Fault management The goal is to detect, report, notify users of, troubleshoot, and (to the extentpossible) automatically fix network problems to keep the network running effectively. Faultmanagement encompasses several key subservices:
- Traffic monitoring Its purpose is to gather traffic statistics and trigger alerts when anomaliesare detected. Several tools can provide this service today with IPv6; for instance, CiscoNetFlow Collector (NFC), Cisco Network Analysis Module (NAM), Argus, and Nagios.
- Topology monitoring The goal is to perform network topology discovery, and to monitornetwork resources such as interfaces, links, nodes, networks, and so on. Many tools canprovide this service in IPv6 today: HP-OV, CiscoView, Weathermap, and so on.
- Routing management The goal is to provide surveillance of the routing tables throughout thenetwork. ASpath-tree, for instance, will provide this support for IPv6 Border GatewayProtocol (BGP) tables.
•
348 Part I: Implementing IPv6 Services
348 Part I: Implementing IPv6 Services
Performance management The goal is to measure and make available various aspects of networkperformance (network throughput, user response times, and line utilization). Cisco IOS IP servicelevel agreements (IP SLAs, formerly Service Assurance Agent [SAA]), for instance, can achieve thisservice over IPv6 today with the help of an IPv4 over IPv6 tunnel. Services can be monitored, too,such as HTTP, FTP, RADIUS, DHCP, DNS, and any intelligent agent such as Cisco IOS Agent.
•
Configuration management The goal is to monitor network and system configuration information sothat the impact of various versions of hardware and software elements can be tracked and managed.Typical IPv6-enabled tools are CiscoWorks RME, HP-OpenView, and RANCID.
•
Accounting management The goal is to measure resource utilization parameters so that individual orgroup uses on the network can be regulated and billed appropriately. Traffic monitoring, mentionedpreviously, and associated IPv6 tools (NFC, NAM, Argus, and so on) can be used for this purpose.
•
Security management The goal is to control access to network resources according to policies so thatthe network cannot be sabotaged (intentionally or unintentionally) and sensitive information cannot beaccessed by those without appropriate authorization.
•
Depending on the managed domain, the choice of management tools varies, even though management flowsdo exist between entities (as shown in Figure 10-1). Integrated management platforms are the norm in the coremanagement domain, typically HP-OV coupled with CiscoWorks. Availability of IPv6 support on theseNMSs becomes a key requirement for deploying IPv6 in the core. On the site-management domain, dependingon the size of the site, the same NMS platforms or more-discrete tools may apply. Nagios, for instance,provides some IPv6 support for managing hosts and routers in a LAN. Many traffic- andperformance-monitoring tools with IPv6 support are now available for use in this type of environment. Allthese tools and their applicability domain are reviewed in the subsequent sections.
Retrieving Information from Routers and Switches
You can retrieve information from IPv6 devices in many ways, and they are the same asfor IPv4:
SNMP and MIBs• NetFlow or IPfix• Connection to the device and execution of locally available commands• Specific applications can provide additional information: ping, traceroute, andso on.
•
SNMP and MIBs
The Simple Network Management Protocol (SNMP) is a request-reply-based protocolrunning over UDP (ports 161 and 162), although TCP operation is also possible. SNMPis used by the NMS to access or modify data in the managed devices via objects calledManagement Information Bases (MIBs). A MIB is a hierarchy of information thatdescribes an SNMP-manageable object. Each object is associated with a unique objectidentifier descriptor (OID). The MIB is organized as a tree; the leafs are the objectinstances representing a resource (interface address, interface name, event, and so on).MIBs are either standard (described in RFCs) or enterprise specific. Given the relativelyslow progress of IPv6 MIB definitions, a large number of enterprise-specific MIBs havebeen published, including several Cisco ones.
Part I: Implementing IPv6 Services 349
Part I: Implementing IPv6 Services 349
SNMP is an asymmetric protocol, operating between a management station and anagent, the device being managed. Typically, the agent is a router or a switch thatimplements a few simple packet types and a generic get-or-set function on its MIBvariables. The management station provides the user interface. Simple managementstations can be built with UNIX command-line utilities. More complex (and expensive)ones collect MIB data over time and use graphical user interfaces (GUIs) to drawnetwork maps.
An SNMP operation takes the form of a protocol data unit (PDU). Version 1 SNMPsupports five possible PDUs:
GetRequest/SetRequest supplies a list of objects and, possibly, values they are tobe set to.
•
GetResponse informs the management station of the results of a GetRequest orSetRequest.
•
GetNextRequest is used to perform table transversal.• Trap is the only PDU sent by an agent on its own initiative. It is used to notifythe management station of an unusual event.
•
SNMP version 2 (SNMPv2) is an evolution of the SNMPv1. SNMPv2 introduces twonew operations: GetBulk and Inform. The GetBulk operation is used to retrieve largeblocks of data. The Inform operation allows two SNMP entities to exchangeacknowledged information. SNMP version 3 (SNMPv3) adds security andremote-configuration capabilities.
There are two distinct aspects for supporting IPv6 SNMP: the transport of SNMPprotocol over IPv6 and the IPv6 MIBs support.
SNMP over IPv6
Because SNMP runs over UDP, an SNMP over IPv6 implementation is mostly aboutUDP over IPv6 support (and in the router case, some configuration tweaks).
Cisco routers now support SNMP over IPv6. For SNMP GetRequest and SetRequest,which are initiated by the NMS, the router simply responds with the same transportprotocol (UDP over IPv6, for instance) used by the incoming request. When sending anSNMP trap, the router needs to be configured with an IPv6 destination, as illustrated inthe Example 10-1.
Example 10-1. SNMP Configuration Example
snmp-server community public ROsnmp-server enable traps syslogsnmp-server enable traps mpls ldpsnmp-server enable traps mpls traffic-engsnmp-server enable traps mpls vpnsnmp-server host 2001:400::1 version 2c public
On the NMS side, most SNMP application programming interfaces (APIs) supportSNMP over IPv6:
Sun's Java J2SDK/JRE 1.4•
350 Part I: Implementing IPv6 Services
350 Part I: Implementing IPv6 Services
FreeBSD• Linux• Windows•
Note
Running SNMP over IPv6 is required only for IPv6-only devices. In the most commoncase, IPv6-managed devices are dual stack, and need to report management data for bothIPv4 and IPv6. Historically, these devices have been configured for IPv4 first and haveIPv4 connectivity to the NMS: Enabling of IPv6 can and should be done withoutdisturbing the existing NMS/device transport and configuration. Because the transport(UDP) and the content (MIBs) are independent of each other, you can keep the IPv4transport to carry SNMP IPv6 data.
IPv6 MIBs
More than 100 MIBs are available to check for IPv6 support, and they can be classifiedas follows:
MIBs that do not have any address dependencies• MIBs where ipAddress should just be replaced by inetAddress• MIBs that require major redesign to handle both IPv4 and IPv6 protocols• MIBs that require a specific IPv6 version•
RFC 3796 provides a survey of IPv4 address usage in existing IETF documents,including many MIBs.
Current IETF work is putting emphasis on MIB-2 MIBs (basic MIBs such as IP, UDP,TCP, ICMP) to support IPv6. Unfortunately, that work has been going on for quite along time, because the initial approach of creating separate MIBs for IPv6 (with anipv6Address) has evolved toward creating unified MIBs that cover both IPv4 and IPv6.Figure 10-2 illustrates that evolution.
Figure 10-2. IPv6 Basic MIB History
[View full size image]
Part I: Implementing IPv6 Services 351
Part I: Implementing IPv6 Services 351
Two sets of basic MIBs are defined for supporting IPv6-related information. One set isbased on RFC 2465 for textual convention of the IPv6 address (OCTET STRING [SIZE(16)]). The basic IPv6 MIBs supporting that textual convention are as follows:
The second set is based on RFC 3291 for textual convention of both IPv4 and IPv6,through an inetAddress structure, which includes a type (1 for IPv4, 2 for IPv6) and anaddress. These MIBs are sometimes referred to as unified MIBs.
The basic IPv6 MIBs supporting that textual convention are as follows:
At the time of this writing, both the IP-MIB and the IP-FORWARD-MIB are in theIETF Editor Queue, as Proposed Standards, which means close to completion.
Although some network equipment (Hitachi, NEC, Juniper) and NMS (HP-OV) vendorscurrently support IPv6-specific MIBs (based on RFC 2465), others, including Ciscorouters, support some version of the unified MIBs (based on RFC 3291). Because thelatter are not yet published RFCs, the support remains private, and based on variousversion of the Internet Draft. Cisco, for example, implemented the draft version for "IPForwarding Table MIB" and "IP MIB" as a private MIB (update-00). However, becausethe unified MIBs are becoming standard, Cisco actively works on their support, and it isexpected that the NMSs (HP-OV and so on) will integrate them.
352 Part I: Implementing IPv6 Services
352 Part I: Implementing IPv6 Services
BGP and Other MIBs
The BGP IPv6 MIBs are lagging behind the needs of today's networks. The BGPmultiprotocol extensions (MP-BGP) enable BGP to exchange routing information fordifferent types of address families (for instance, IPv6), identified by an Address FamilyIdentifier (AFI) and Subsequent Address Family Identifier (SAFI). RFC 1657 describesBGP4 MIBs, without the multiprotocol bits required to report information about IPv6and VPNv6 (as well as VPNv4 and multicast). An update of RFC 1657 is currently inthe IETF RFC queue (draft-ietf-idr-bgp4-mib), but it also fails to provide MP-BGPinformation (still uses ipAddress).
On the other end, an MP-BGP MIB (draft-ietf-idr-bgp4-mibv2) is revising RFC 1657with much larger ambitions. For several significant capabilities, such as BGPcommunities (RFC 1997), autonomous system confederation (RFC 3065), BGPmultiprotocol extensions (RFC 2858), and route reflection (RFC 2796), the documentproposes object types to manage those extended capabilities and their operation. As faras BGP IPv6 (AFI:IPv6, SAFI:Unicast), 6PE (AFI:IPv6, SAFI:label), and VPNv6(AFI:IPv6, SAFI:VPN), the support of BGP multiprotocol extensions, which relies oninetAddress will be an important first step toward managing these features.
In addition, draft-ietf-idr-bgp4-mibv2 allows transport-independent address indicesconsistent with the AFI and SAFI mechanisms of that extension. Some router vendorsimplement this MIB as a private MIB. Cisco implements another BGP MIB(CISCO-BGP4-MIB), which also handles multiprotocol BGP, with a different format.The following excerpt shows the SAFI support in this MIB:
In theory, nothing prevents the MIB (and the corresponding address, defined as OCTETSTRING(SIZE[0..255]), from supporting IPv6 and VPNv6 addresses. In practice, at thetime of this writing, the Cisco SNMP agent does not expose the IPv6, 6PE, and VPNv6BGP information.
Some other MIBs, such as IP Tunnel MIB, are not yet at a point where they are ready forpublication.
Many MIBs require further study, although they would be useful for managing IPv6networks:
OSPFv3 MIB• Tunnel MIBs (including BGP tunnels such as 6PE and 6VPE)• The VPN MIB• Cisco Express Forwarding MIBs•
IPv6 MIB Example
Using one of the numerous MIB browsers available, you can obtain MIB-2 content froma Cisco router. In the following example, the CISCO-IETF-IP-FORWARD-MIB is
Part I: Implementing IPv6 Services 353
Part I: Implementing IPv6 Services 353
loaded into the MIB browser. Example 10-2 shows an excerpt of the MIB for the routeentry:
Example 10-2. CISCO-IETF-IP-FORWARD-MIB Route-Entry Example
Using the MIB browser, you can execute a (series of) GET-NEXT and display theresulting tree, as shown in Figure 10-3.
Figure 10-3. MIB Example Using a MIB Browser
[View full size image]
For a better understanding of the MIB browsing result, it is possible to execute the showipv6 cef command on the router. The resulting output, shown in Figure 10-3, containsdetails about the router forwarding table that relate directly to the MIB-2 content.
354 Part I: Implementing IPv6 Services
354 Part I: Implementing IPv6 Services
For example, CAFE:10::/64 appears in the MIB with the ASN.1 notation as follows:
Prefix202.254.0.16.0.0.0.0.0.0.0.0.0.0.0.0• Length64• If index13 (Loopback0)•
Note
The unified MIB-2 MIBs are defined for both IPv4 and IPv6. In theory, the devicesshould respond to SNMP queries with values for both protocols. However, current Ciscoimplementations retrieve only IPv6 (type 2) addresses for the MIB-2, although theIPv4-only MIBs must be used to retrieve IPv4 data.
NetFlow
Cisco IOS NetFlow provides network administrators with access to informationconcerning IP flows within their data networks. NetFlow includes three key componentsthat perform the following functions:
Flow caching collects IP data flows entering router or switch interfaces andprepares data for export. It enables the accumulation of data on flows withunique characteristics, such as IP addresses, application, and class of service(CoS). When enabled for IPv6 traffic, flow caching can record IPv6 flows, andaggregate them according to the configured aggregation policy. The flowscaptured on the routers are then exported to a flow collector.
•
Flow collector and data analysis captures exported data from multiple routers,filters and aggregates the data according to customer policies, and then storesthis summarized or aggregated data.
•
Flow analyzer displays and analyzes NetFlow data collected from flow collectorfiles. This allows users to complete near real-time visualization or trendinganalysis of recorded and aggregated flow data.
•
Figure 10-4 highlights these three components in the network.
Figure 10-4. NetFlow Architecture
[View full size image]
Part I: Implementing IPv6 Services 355
Part I: Implementing IPv6 Services 355
Typical flow information found in a NetFlow data record includes the following:
Source and destination IPv6 address• Source and destination TCP/UDP ports• Type of service (ToS)• Packet and byte counts• Start and end time stamps• Input and output interface numbers• TCP flags and encapsulated protocol (TCP/UDP)• Routing information (next-hop address, source autonomous system number,destination autonomous system number, source prefix mask, destination prefixmask)
•
The basic output of NetFlow is a flow record. Several different formats for flow recordshave evolved as NetFlow has matured. The most recent evolution of the NetFlowflow-record format is known as version 9. IPv6 flows can only be reported under thatversion. The distinguishing feature of the NetFlow v9 format is that it is template based.Table 10-1 lists the IPv6-specific NetFlow fields that can be collected and exported.
BPG_IPV6_NEXT_HOP 63 16 Next-hoprouter in theBGPdomain
IPV6_OPTION_HEADERS 64 4 Bit-encodedfieldidentifyingIPv6 optionheadersfound in theflow
The IPv6 option headers are reported into a 32-bit field, as shown in Table 10-2, only when the router isconfigured to do so. This is because this recording can impact the router performances; to obtain the option
Part I: Implementing IPv6 Services 357
Part I: Implementing IPv6 Services 357
headers in the IPv6 packet, the router's forwarding component has to scan the complete chain of headers,although only the first one is usually looked at in a transit node. This scanning might lead certain hardwarerouters to punt the IPv6 packets to a software path, with some performance consequences.
Table 10-2. NetFlow Encoding of IPv6 Option Header
Bit
Option
Option Header Value
1
Fragmentation header (not first fragment)
44
2
Routing header
43
3
Fragmentation header (first fragment)
44
4
Cannot reach layer 4
No readable value
6
Hop-by-hop option header
0
7
Destination option header
60
8
Payload compression header
108
358 Part I: Implementing IPv6 Services
358 Part I: Implementing IPv6 Services
9
Authentication header
51
10
Encrypted Security Payload
50
Table 10-2 shows how the field IPV6_OPTION_HEADERS is encoded.
Example 10-3 shows how to configure option header reporting on the Cisco router.
Example 10-3. NetFlow Option Header Reporting Configuration
interface Ethernet3/0 no ip address ipv6 address 2001:100::/64 eui-64 ipv6 flow ingressipv6 flow mask options-headers 0x24
In this example, the option headers for routing header and hop-by-hop header are recorded.
There are many ways to operate NetFlow on the routers:
You could capture raw flows and store them in the IPv6 NetFlow cache before exporting them to thecollector. The following configuration example shows how to configure the raw IPv6 NetFlow cacheon a Cisco router and export v9 records.
Example 10-4. NetFlow Configuration for Raw Flow Capture
With a configured frequency, the NetFlow routers export the raw data to the NetFlow Collector (inthis example, 172.18.102.245). The collector can then aggregate the flows and produce statistics andalerts. Several IPv6 NetFlow Collectors, including Cisco NFC, are reviewed in the section "FlowAnalysis Using NetFlow."
•
Flows can be aggregated on the NetFlow routers before they are exported to the collector. A specificaggregation cache is then created on the router and mapped onto the chosen aggregation scheme.
•
Part I: Implementing IPv6 Services 359
Part I: Implementing IPv6 Services 359
Example 10-5 illustrates how this can be done.
Example 10-5. NetFlow Configuration with Flow Aggregation
On the router, a distinct aggregation cache is created for each IPv6 aggregation scheme (autonomoussystem, BGP next hop, protocol port, source prefix, destination prefix, prefix). Table 10-3 lists fieldsset for each of the IPv6 aggregation caches.
Table 10-3. NetFlow Aggregation Schemes
Field/Aggregation Scheme
Autonomous System
BGP Next Hop
Protocol Port
Source Prefix
Destination Prefix
Prefix
Protocol Version
[*]
[*]
[*]
[*]
[*]
[*]
Direction
[*]
[*]
[*]
[*]
360 Part I: Implementing IPv6 Services
360 Part I: Implementing IPv6 Services
[*]
[*]
Source Prefix
[*]
[*]
Destination Prefix
[*]
[*]
Protocol
[*]
Source Port
[*]
Destination Port
[*]
Source Interface
[*]
[*]
[*]
Part I: Implementing IPv6 Services 361
Part I: Implementing IPv6 Services 361
[*]
Destination Interface
[*]
[*]
[*]
[*]
Source BGP Autonomous System
[*]
[*]
[*]
[*]
Destination BGP Autonomous System
[*]
[*]
[*]
[*]
Source Prefix Mask
[*]
[*]
Destination Prefix Mask
[*]
[*]
BGP Next Hop
362 Part I: Implementing IPv6 Services
362 Part I: Implementing IPv6 Services
[*]
Next Hop
[X]
[X]
OR'd TCP Flags
[X]
[*] : fields recorded and part of the aggregated record key
[X] : fields recorded but not part of the keyA third option, useful in testing phases but not recommended in real-life deployments, is to obtainrouter statistics and counters via the router command-line interface (CLI). Example 10-6 shows thedetailed output of the show NetFlow command.
Out of the three methods reviewed, the first one (export raw data) should be preferred, as long as the interfacefor exporting the data can handle the overhead of massive flow export. If it cannot, aggregating flows on therouter before exporting them will reduce this overhead while using router resources. Accessing NetFlowcounters via a router's CLI should be reserved to testing and troubleshooting situations.
Note
With the current version of Cisco NetFlow, the v9 records containing the raw or aggregated IPv6 fields arecurrently sent over IPv4 UDP.
Note
Unlike IPv4, the IPv6 main cache (with no aggregation configured on the router) can aggregate addressesbased on a configured mask length. This capability was required with IPv6 because of the larger addressspace. Flows that differ only by a source or destination within the same prefix range (bounded by theconfigured mask length) are aggregated at capture time. The following example shows how this can beconfigured.
Example 10-7. NetFlow Mask-Length Configuration
Router#show runninginterface Ethernet3/0 no ip address ipv6 address 2001:100::/64 eui-64 ipv6 flow ingress ipv6 flow mask destination maximum 64 ipv6 flow mask source maximum 64 end
For performance reasons, it is recommended to turn this option on, unless there is a good reason for recordingfull prefixes.
Note that flows with unrecorded option headers are also aggregated at capture time.
IPfix
The IPfix protocol defines how IP flow information can be exported from routers, measurement probes, andother devices. It is intended to provide this information as input for various applications. IPfix is a generaldata-transport protocol, easily extensible to suit the needs of different applications.
IPfix is currently being defined at the IETF in the Internet Draft draft-ietf-ipfix-protocol. It has all provisionsto support IPv6 addresses and all flexibility to fit future IPv6 needs. When available, it will possibly replaceNetFlow as the next-generation flow-analysis tool. However, at the time of this writing, no productionimplementation of IPfix was yet available, and the Internet Draft has not yet established standards.
Service-usage accounting is one of the major applications for which the IPfix protocol has been developed.
364 Part I: Implementing IPv6 Services
364 Part I: Implementing IPv6 Services
IPfix data provides fine-grained measurements (for example, flow records include details such as IPaddresses, packet and byte counts, time stamps, type of service [ToS], and application ports) for highlyflexible and detailed resource-usage accounting.
Internet service providers (ISPs) can use this information to migrate from single-fee, flat-rate billing to moreflexible charging mechanisms based on time of day, bandwidth usage, application usage, quality of service(QoS), and so forth. Enterprise customers can use this information for departmental chargeback or costallocation for resource usage.
For accounting purposes, it would be advantageous to have the ability to use IPfix flow records as accountinginput in an authentication, authorization, and accounting (AAA) infrastructure. AAA servers could provide themapping between user and flow information.
The IPfix protocol specification has been designed to be transport protocol independent (TCP, UDP, SCTP).However, only SCTP (Stream Control Transmission Protocol) transport is mandated by the specification,because it is the only reliable transport protocol that includes congestion-avoidance mechanisms. There shouldbe no problem in reporting IPv6 data with IPfix, provided only that the transport protocol being used to carryIPfix is running on the IPv6 network.
Other Protocols (Telnet/SSH/RSH/TFTP/FTP)
There exists a collection of well-known protocols that can be used to extract management information fromrouters. They do not define the format of what is being uploaded (or downloaded), but they provide access todevices where specific commands can be executed. Similar to the other retrieval tools, even when theyconnect to the router over IPv4, they have the ability to retrieve IPv6 information.
Here is a list of the most common such protocols, with a status of their IPv6 support on Cisco routers.
Telnet Telnet can be used to log in to a device, such as a router, to obtain console access. Using thelocal user interface, one can then obtain device data and/or configure it. The data can be, for instance,a configuration file, local counters, local cache, link status, and so on.
Cisco routers support both IPv6 Telnet client and server connections. A vty interface and passwordmust be created to enable Telnet access to an IPv6 router. The following configuration illustrates howto enable the IPv6 Telnet server on a Cisco router.
SSH Secure Shell can be handy for connecting to a device over a secure connection and retrievinginformation. On Cisco routers, configuring SSH for IPv6 is not different from its configuration forIPv4. It requires the following:
- An IPsec (Data Encryption Standard [DES, 3DES] or AES) encryption-software Ciscorouter image.- A host name and host domain must be configured.- A Rivest, Shamir, and Adelman (RSA) key pair, which automatically enables SSH, must begenerated for the router.
•
RSH Remote Shell enables users to execute commands remotely. Remote Copy (RCP) enables usersto copy files to and from a file system residing on a remote host or server on the network. Example10-10 illustrates an IPv4 RSH configuration that enables IPv6 command execution on the server side(Router-B). The example also shows an IPv6 command executed on the client side (Router-A) todisplay interface status.
Example 10-10. Configuring a Server for RSH and Executing Commands Remotely
Router-B#show running | include ip rcmdip rcmd rcp-enableip rcmd rsh-enableip rcmd remote-host Router-A 50.1.1.1 Router-A enable
Note that although Example 10-10 shows how to configure RSH over an IPv4 transport, RSH over anIPv6 transport is not yet supported on Cisco IOS routers at the time of this writing.
•
TFTP It can be used to download or upload files to/from a device such as a router. On Cisco routers,IPv6 supports TFTP file downloading and uploading using the copy EXEC command. The copyEXEC command accepts a destination IPv6 address or IPv6 host name as an argument and saves therunning configuration of the router to an IPv6 TFTP server, as follows:
FTP FTP can also be used to upload/download information to/from devices. Although FTP runs overTCP, having IPv6 TCP support is not enough to get FTP working over IPv6. FTP messages include ahost address, and the initial FTP specification assumed network addresses of 32 bits in length. RFC2428 specifies FTP extensions for IPv6. On Cisco routers, at the time of this writing, FTP over IPv6 is
•
366 Part I: Implementing IPv6 Services
366 Part I: Implementing IPv6 Services
not yet supported.
In many cases, Looking Glass can be set up to enable authorized users to access IPv6-enabled devices from aweb interface and to run specific commands. Looking Glass typically uses Telnet, SSH, or RSH to execute therequest on the device. The IPv6 information can be acquired over IPv4 or IPv6. The example illustrated inFigure 10-5 shows one of these Looking Glass outputs used on the regional Picardie (France) IPv6 network.
Figure 10-5. IPv6 Looking Glass
[View full size image]
Fault Management
As already mentioned, fault management encompasses traffic management, topologymonitoring, and routing management.
Traffic management is one of the keystones of successfully deploying services andapplications. It encompasses a large variety of tools and features to follow the life cycle ofnew deployments: from traffic measurement to traffic analysis, before and after new service isdeployed, from link management to node status, to end-to-end service-level management. Alarge part of traffic management deals with network troubleshooting, to provide in-depthanalysis of traffic. Most of the tools can generate reports and alerts to assist the networkadministrator in identifying problems, isolating, and then troubleshooting them. Note thatmany tools used for traffic management are also used for performance monitoring, such asArgus and Nagios. These tools are reviewed in the section "Performance Management."
Part I: Implementing IPv6 Services 367
Part I: Implementing IPv6 Services 367
Flow Analysis Using NetFlow
The NetFlow Collector receives UDP packets containing flow exports from the NetFlowrouter and stores them. Flow content can be used for a variety of purposes, including networkmanagement and planning, enterprise accounting, Internet service provider (ISP) billing, datawarehousing, mitigation of denial-of-service (DoS) attacks, and data mining for marketingpurposes.
NetFlow analyzers process the stored flows and present them in various formats (alerts,statistics, graphics, and so on). Often, these two functions are handled by the same tool. Anumber of NetFlow Collectors and analyzers are available, including several that support thev9 export format, hence IPv6:
Ntop (nProbe) Available for UNIX (including Mac OS X), Windows, and embeddedenvironments, v.3.x.
•
IPFlow IPFlow is a collector that supports NetFlow flows version v1, v5, v6, v7, v8,and v9. It supports logging flow data to disk, data aggregation according toconfiguration, port-scan detection, storage of aggregated data in RRDtool, andgraphical display of flow statistics.
•
Cisco NFC This tool is described in detail in the following section.•
Cisco NFC
The Communication & Network Services (CNS) NetFlow Collection Engine performs thefollowing functions:
NetFlow data collection from multiple export devices• Reduction in data volume through filtering and aggregation• Hierarchical data storage (helps client applications retrieve data)• File system space management•
CNS NetFlow Collection Engine collects and summarizes (aggregates) data into data filesbased on user-defined criteria specified in a CNS NetFlow Collection Engine aggregator. Anaggregator is an aggregation task defined by a set of user-configurable attributes that specifyhow CNS NetFlow Collection Engine summarizes the traffic flows that are received. Twoimportant aggregator attributes are as follows:
Aggregation schemes Defines the subset of data of interest in a traffic flow, as well aswhich statistics are kept
•
Filter Criteria for accepting or rejecting flows that are aggregated or summarized•
CNS NetFlow Collection Engine provides a set of predefined aggregation schemes to helpcollect NetFlow export and summarize the data. Moreover, in release 5.0, you can modify anyof the predefined aggregation schemes or define your own aggregation schemes. You can alsouse filters with aggregation schemes to include or exclude certain types of NetFlow data.
CNS NetFlow Collection Engine consists of the following components:
Collector Collects NetFlow data, aggregates (or summarizes) that data, and filtersspecified data from supported Cisco routers and switches. Output is stored in files thatare organized in an easy-to-use directory structure.
•
Web-based user interface (UI) The web-based UI is provided for configuration,control, status, and reporting.
•
368 Part I: Implementing IPv6 Services
368 Part I: Implementing IPv6 Services
CNS/XML interface The CNS/XML interface is used to send and receiveconfiguration/control requests and responses and unsolicited event notifications.
•
Report generator The report generator produces hourly and daily reports based oncollector output files by performing further aggregation of the records in these filesbased on criteria selected by the user.
•
BGP peer A passive BGP peer is provided to supplement CNS NetFlow CollectionEngine output with BGP attributes.
•
Starting with NFC 5.0, Cisco NetFlow Collector supports IPv6. This means that it can collectNetFlow v9 records, including records with IPv6-specific fields, aggregate them according tothe aggregation scheme configured on the NFC interface, and generate reports and alertsspecific to IPv6.
The screen captures in Figures 10-6 and 10-7 illustrate one of the NFC configuration steps forIPv6 (NetFlow Export field) and show a simple IPv6 report.
Figure 10-6. Configuring NFC: Fields
[View full size image]
Figure 10-7. Sample of an NFC report
[View full size image]
Part I: Implementing IPv6 Services 369
Part I: Implementing IPv6 Services 369
For more detail about Cisco NFC and its IPv6 support, refer to the NFC 5.0 configurationguides.
IPFlow
IPFlow is a collector for NetFlow v1, v5, v6, v7, v8, and v9. It was initially developed formanaging the Picardie regional network, but is freely available. The primary design goal wasto provide a tool suited for troubleshooting networking issues such as link congestion ofunexpected traffic.
It supports logging flow data to disk, data aggregation according to configuration, port-scandetection, storage of aggregated data, and graphical display of flow statistics.
Cisco Network Analysis Module
The Cisco Network Analysis Module (NAM) is a service module installed in a single slot inCisco Catalyst 6500 series switch or Cisco 7600 series router chassis that provides integratednetwork-monitoring services within the switch or router. The NAM collects statistics onnetwork traffic and is used for real-time traffic analysis, performance monitoring, andtroubleshooting. The NAM monitors and analyzes network traffic using remote monitoring(RMON), RMON extensions for switched networks (SMON), and other ManagementInformation Bases (MIBs).
The NAM has the capability to gain visibility into traffic from other switches and routers,whether they are sitting on the LAN or on the WAN. This is done through RSPAN andNetFlow Data Export (NDE). Table 10-4 reviews all possible data sources for the NAM.When enabled on the switch, the NetFlow data source becomes available on the Cisco NAMwithout any SPAN sessions being created. NetFlow can also be enabled on interfaces onremote devices and sent to the NAM for analysis. With NetFlow available as a data source,the Cisco NAM can provide information such as hosts and conversations, applications, and soon directly from the traffic analyzer or other third-party tools.
Table 10-4. Cisco Catalyst 6500 Series and Cisco 7600 Series NAM Data SourcesData Source DescriptionSPAN and Remote SPAN (RSPAN) Using the
SPAN andRSPAN
370 Part I: Implementing IPv6 Services
370 Part I: Implementing IPv6 Services
capabilities ofCisco Catalyst6500 seriesswitches, trafficfrom ports,VLANs, andEtherChannellinks can bemirrored to theCisco NAM.The NAMcollectsstatistics on alllayers ofnetwork trafficspanned to it.
VLAN access control lists (VACLs) The CiscoNAM usesVACLs tocapture or"filter" selectedVLANs andWAN traffic(on Cisco IOSsoftware only)to the NAMports.Additionalfiltering rulescan also beapplied to targetspecific dataflows.
NetFlow Data Export (NDE) local NDE recordsoffer anaggregate viewof the networktraffic. Whenenabled on theswitch, theNetFlow datasource becomesavailable on theCisco NAMwithout theneed to createany SPANsessions.
NetFlow Data Export (NDE) from remote devices The CiscoNAM canreceive NDEfrom remotedevices foranalysis.
Part I: Implementing IPv6 Services 371
Part I: Implementing IPv6 Services 371
NDE records offer greater traffic-monitoring capacity because this data source is available (when enabledfrom the switch) without creating any SPAN sessions to the Cisco NAM. The NAM can provide informationon the packets through the NDE records without having to examine each packet, and thus allow for moretraffic to be analyzed. NetFlow provides statistics on applications, hosts, and conversations.
Starting with version 3.4, NAM provides support for NetFlow v9, making it an IPv6-enabled "NetFlowCollector on a linecard" for the Catalyst 6500/7600 platform.
Cisco NAM can monitor and decode IPv6 traffic. The user can set up alarms with IPv6 addresses andconfigure IPv6 capture filters and IPv6 historical reports. Figures 10-8 and 10-9 are NAM traffic analyzerscreen captures, showing, respectively, an IPv6 packet decode and IPv6 traffic statistics per protocol andaddress.
Figure 10-8. NAM Traffic Analyzer
[View full size image]
Figure 10-9. NAM Traffic Analyzer per Protocol Statistics Example Output
[View full size image]
372 Part I: Implementing IPv6 Services
372 Part I: Implementing IPv6 Services
Note
Although a NAM can receive and decode NetFlow v9 records pertaining to IPv6 flows, it cannot, as of thiswriting, create IPv6 flows itself.
Topology Management
Topology management is the network-management component that keeps track of network topology. Theinformation acquired and maintained by topology management is important to other processes such as faultmanagement.
In simple cases, topology management might simply keep track of system status (active/standby). In largenetworks with a large number of devices, it can include automatic discovery modules and a graphicalrepresentation of the network, with hierarchical views down to the individual nodes and interfaces.
Autodiscovery is done by an NMS to automatically map the devices in a network, to populate an inventoryand to gain information on network topology. Autodiscovery is one of the interesting challenges standing inthe path of deploying IPv6-only networks, and as such, is reviewed thoroughly in the next section.
As long as managed devices and routers are dual stack, the network discovery is likely to keep using existingIPv4-based mechanisms. However, IPv6-only devices are already being deployed, and they create newchallenges for network discovery. To measure the difficulties of discovering automatically an IPv6-onlynetwork, it may be helpful to review existing mechanisms used with IPv4.
With IPv4, network discovery can be achieved by two methods:
By reading the neighbor cache in the devices, a cache created by protocols such as CDP, ILMI, andELMI. This is generally referred to as CDP discovery. The following steps are applied:
•
Part I: Implementing IPv6 Services 373
Part I: Implementing IPv6 Services 373
Start with seed device(s).
Read neighbor cache from these devices from the MIBs CISCO-CDP-MIB,CISCO-FRAMERELAY-MIB, ATM-MIB.
Explore the network by further exploring the neighbor devices.
By using a general discovery mechanism that does not depend on protocols such as CDP, ILMI, andELMI being enabled in customer networks. This is generally referred as non-CDP discovery, IP-baseddiscovery, or general discovery. The following steps are applied:
Start with seed devices.
Read routing tables from the MIBs (RFC 1213), and derive subnet information and theneighboring routers information from these tables.
Compute the possible IP addresses in the discovered subnet.
Do SNMP query for these IP addresses and discover the network.
•
Which mechanisms can be used in IPv6 autodiscovery? As far as the CDP-based technique is concerned, nochange is required in the CDP MIB, but the cdpCacheAddressType object must report a new value (IPv6) forthe network protocol (CiscoNetWorkProtocol). As of this writing, this is not yet supported.
With non-CDP-based discovery, typical discovery algorithms in an IPv4 network rely on information fromMIB-2 (RFC 1213) and ICMP echo requests to discover all devices in a network. Starting from a seed router,neighboring routers can be found from the router's ipRouteTable entry in MIB-2. The values of ipRouteDest,ipRouteMask and ipRouteType can be used to find the subnets directly connected to this router. To make surethe seed router's ARP cache has entries of all the hosts in the subnet, ICMP echo request messages are sent toall the possible IP addresses in the subnet and wait for the echo reply messages.
The router's ARP table can then be queried from ipNetToMediaTable. This provides a list of directlyconnected hosts, layer 2 devices, and other routers. The same technique is then iteratively applied to eachdiscovered router.
With IPv6, the neighbor cache can be accessed as InetNetToMediaTable, which is part of the updated RFC2011 MIB. However, the IPv6 addresses obtained from the Neighbor Discovery (ND) cache are likely to belink-locals, if the router uses them to communicate with its peers. Such addresses are useless to the remoteNMS because they are significant only on a link. The NMS requires a device-global IPv6 address for itsSNMP queries.
On the other hand, unlike with IPv4, the NMS cannot remotely force an ND cache to populate entries to allnodes' neighbors. With IPv6, scanning all hosts on a subnet is out of question, given the number ofpossibilities (remember this was presented as security strength in preventing address scanning!); IPv6broadcast does not exist; IPv6 multicast could be an alternative (using FF02::1), but it has link-local scope,and therefore will return link-local addresses.
That leaves autodiscovery with few open options. One of them is to establish some relationship between thelink-local address and global address based on the relationship between the interface ID used for bothaddresses (see Chapter 2). Example 10-11 shows an interface where EUI-64 is used to generate the interfaceID.
374 Part I: Implementing IPv6 Services
374 Part I: Implementing IPv6 Services
Example 10-11. Using the Automatically Formatted EUI-64 Interface ID to Tie Link-Local and Global Addresses
Router#show runninginterface Ethernet3/0 no ip address ipv6 address 2001:100::/64 eui-64 no cdp enableendRouter#show ipv6 interface briefEthernet3/0 [up/up] FE80::205:DCFF:FE65:9C54 2001:100::205:DCFF:FE65:9C54
After the relationship is established, the NMS can do the following:
Obtain the list of IPv6 subnets from the routing table of the seed router• Start a multicast ping (ping FF02::1) on each subnet/interface of the seed router• Retrieve the neighbor cache from the seed router• Derive EUI-64 global addresses from EUI-64 link-local addresses• Iterate on each of these global addresses to progress in the topology•
Another possibility is to use MIPv6 capability described in RFC 3775 to set a flag bit to indicate that therouter sending the advertisement message is serving as a home agent. When this flag is set, the router (if itsupports that functionality) returns its global address rather than prefixes. The seed router still has to store thisinformation in a MIB that the NMS can query.
Of course, you still have the possibility (recommended by many NMSs) to provide up front the list ofaddresses to be "discovered." It is not a friendly solution, but it is one that works all the time!
Integrated platforms such as HP-OV and CiscoWorks provide extensive capabilities for managing the networktopology. They can autodiscover the topology, currently using IPv4 mechanisms or based on a predefined listof devices to discover.
Specific tools also exist, such as InterMappper and Nagios. InterMapper does not currently support IPv6,although it was used on the 6NET project to monitor the status of the dual-stack network. InterMapper is anetwork- and server-monitoring and alerting tool. It provides a real-time graphical view of traffic flowsthrough networks, routers, and links. It can autodiscover the topology of the network if SNMP-speakingrouters are present. However, the autodiscovery is entirely based on IPv4 mechanisms (SNMP, addressscanning, and so on) and manually configured entries of devices to discover. InterMapper is available athttp://www.intermapper.com/.
Routing Management
Routing can get tricky in large multidomain, multiprotocol networks. Routing management tools providevisibility into network-wide, multiprotocol IP routing activity, enabling network administrators to predict,monitor, and analyze routing problems. One of the most popular tools in this arena is ASpath-tree, whichanalyzes the BGP routing tables. Other tools can analyze OSPF and other routing protocol tables. Most ofthem are based on MIB (BGP, OSPF, and so on) and locally executed router commands.
ASpath-tree is a tool used to perform IPv6 network operation analysis based on snapshots of the BGP routingtable on IPv6 routers. Originally designed to be used by an IPv6 site involved in the experimentation of theBGP protocol inside the 6Bone network, it now supports a set of features useful within any production IPv6network that makes use of BGP.
Based on a single snapshot of the IPv6 BGP table, ASpath-tree automatically generates a set of HTML pages,providing a graphical view of the routing paths toward the other IPv6-connected domains. In addition, itprovides pages for the detection of anomalous route entries announced through BGP (invalid prefixes andunaggregated prefixes), anomalous autonomous system numbers (for instance, reserved or private) in use, anda set of summary information, including the following:
The number of route entries (valid/total/suppressed/damped/history)• The number of autonomous systems in the table (total, originating only, originating/transit, transitonly, private, and reserved)
•
The number of active autonomous system paths• The number of active BGP neighbors (for instance, announcing routing information)• An analysis of the network size, in terms of autonomous system distances• The number of circulating prefixes (total, 6Bone pTLAs, sTLAs, 6to4, others)•
Figure 10-10 captures an ASpath-tree screen, obtained on the whole IPv6 BGP table.
Figure 10-10. ASpath-tree Output Screen
[View full size image]
ASpath-tree was developed inside the TILAB's IPv6 laboratory and is available athttp://carmen.ipv6.tilab.com/ipv6/tools/ASpath-tree/.
Note
The Cisco router must be configured to accept rsh commands from the workstation that is running theASpath-tree scripts. The administrator of the Cisco router must add the following configuration:
ip rcmd remote-host eric valbonne-router rootip rcmd rsh-enable
Polyphemus is a tool for exploring and visualizing the network. It can look inside an autonomous system andexplore a network at the level of routers and their physical links. It can also provide inter-autonomous systemtopologies. Areas are explored by directly accessing the MIB of the routers with SNMP. The user canvisualize routers, LANs, areas, and inter-area relationships. For each item on the map, a full set of informationcan be displayed.
Although it cannot support IPv6 as of this writing, plans exist to extend it to support OSPFv3, SNMP overIPv6 transport, and IPv6 MIBs. It is available at http://www.dia.uniroma3.it/~polyph/.
Analysis for Troubleshooting
Many of the tools reviewed throughout this chapter can be used to "troubleshoot" problems. The toolspresented in this section are more specialized. They analyze in detail the packets exchanged between devicesto help pinpoint specific anomalies. The NAM traffic analyzer reviewed in the section "Cisco NetworkAnalysis Module" is an example of such a tool. Two more tools have become quite popular among networkengineers: Analyzer and Ethereal. Both of them provide full support for analyzing IPv6 packets.
Analyzer is an IPv6-enabled traffic-monitoring and -troubleshooting tool, released under a BSD license. It cancapture (and display) packets on both the local machines and remote probes. Analyzer can monitor thereachability (through a set of ICMP echo, a.k.a. ping, packets) of remote hosts, saving data into a database,and collect additional statistics. Alarms can be sent on unexpected results.
Analyzer can discover the presence of the active station on a local network, monitor station availability, anddetect address spoofing (for instance, when the same IPv4/IPv6 address appears to bind more than one MACaddresses).
Analyzer can monitor the presence of TCP/UDP/ICMP "sessions" over the network, saving a database recordfor each session detected within a timeframe. A summary of the session is then saved into a database for laterprocessing. Analyzer is available from http://analyzer.polito.it/30alpha/.
Ethereal and tcpdump are packet analyzers. Ethereal offers a graphical front end that enables the user to drilldown in the information captured. They are used for network element troubleshooting, network fault isolation,intrusion detection, and so on.
Ethereal fully supports the basic IPv6 protocols and all TCP- and UDP-based application protocols runningover IPv6. It is widely used to develop and troubleshoot IPv6 applications and protocols.
Figure 10-11 illustrates an Ethereal output, with details on a BGP-IPv6 update packet:
Ethereal is available at http://www.ethereal.com/.
Performance Management
When deploying new applications over an existing networking infrastructure, the impact on networkperformance is often a major concern.
With IPv6, application deployment should fall into two categories. The first category is IPv4 applicationsmigrating to IPv6. In this case, traffic patterns generated by these applications are expected to be quite similarto what they are with IPv4, hence predictable based on previous experience. The second category is brandnew classes of applications, enabled by the larger address space, or the new capabilities of the IPv6 protocol.Peer-to-peer applications and Mobile IPv6 (MIPv6) belong to this category. These applications' trafficpatterns are expected to be less predictable. In that context, the availability of management tools for acomplete control and measurement of IPv6 traffic will be a key enabler for their adoption.
Many management tools are already available to monitor IPv6 traffic. Some tools are not dependent on the IPversion, so they can be used for IPv6 seamlessly; others are IPv4 tools that have been enhanced to supportIPv6.
Two distinct and complementary approaches are available for managing network performance.
At the device level, some tools can retrieve data from each router (using SNMP, NetFlow, or locally availablecommands on the devices) and analyze it to determine links, devices, and network utilization. This is the caseof tools such as NetFlow Collectors, Argus, Nagios, Ntop, MRTG, and Cricket.
At the network level, some tools can analyze end-to-end performance by sending traffic through the networkand measuring delay, jitter, and so on. This is the case of Cisco IP SLAs, Iperf, Pchar, and so on.
All the major tools for managing network performance are reviewed in the following subsections. AlthoughNetFlow Collectors (Cisco NFC, IPFlow,) also belong in the category of traffic-monitoring tools, they arecovered separately in the "Flow Analysis Using NetFlow" section. Finally, some networkperformance-monitoring capabilities are also integrated in network-management platforms such as HPOpenView and CiscoWorks, as reviewed in the section "Management Platforms."
Cisco IOS IP Service-Level Agreements
The IP service-level agreements (IP SLAs) is a Cisco IOS feature that enables users to monitor networkperformance between a Cisco router and a remote device (which can be another Cisco router). Variousperformance metrics can be measured, including round-trip response time, connect time, packet loss,application performance, interpacket delay variance (jitter), and more. This feature enables users to receivenotifications and to perform troubleshooting and problem analysis based on the statistics collected by the IPSLAs.
In the absence of native IPv6 support for SAA, you can still use the tool in an IPv6-only environment. Theprinciple of the IP SLAs usage for IPv6 is based on shadow routers that have an IPv4 connection over an IPv6tunnel.
A manual IPv6 tunnel is built between two shadow routers (responder Router-resp, and sender Router-send),as illustrated in Figure 10-12.
Figure 10-12. Building IPv4 over IPv6 Tunnels for IP SLAs
The IPv4 over IPv6 tunnel is configured as illustrated In Examples 10-12 and 10-13.
On the responder:
Example 10-12. IPv4 over IPv6 Tunnel Configuration at the SLA Responder
Router-resp#show running interface tunnel 100interface Tunnel100 ip address 10.10.10.2 255.255.255.0 tunnel source 2001:798:100::2 tunnel destination 2001:798:100::10 tunnel mode gre ipv6end
On the sender:
Part I: Implementing IPv6 Services 379
Part I: Implementing IPv6 Services 379
Example 10-13. IPv4 over IPv6 Tunnel Configuration at the SLA Sender
Router-send#show running interface tunnel 100interface Tunnel100 ip address 10.10.10.10 255.255.255.0 tunnel source 2001:798:100::10 tunnel destination 2001:798:100::2 tunnel mode gre ipv6end
With IPv4 connectivity established through the IPv6 tunnel, a router can be configured to become an SLAresponder or an SLA sender. To configure the SLA responder, the configuration shown in Example 10-14must be set up on the router Router-resp.
Example 10-14. SLA Responder Configuration
Router-resp#show runningrtr responder
For the SLA sender, the tester must be configured to execute certain kinds of tests such as jitter, echo, and soon. Example 10-15 demonstrates an echo reply test.
Example 10-15. SLA Sender Configuration
Router-send#show runningip sla monitor responderip sla monitor type echo protocol ipIcmpEcho 10.10.10.10 source-ipaddr 10.10.10.2 tos 20
frequency 120ip sla monitor schedule 1 start-time now life forever
For further detail about SLAs, refer to the Cisco IP SLAs documentation available at http://www.cisco.com.
Other IPv6-Enabled Tools for Performance Analysis
Network monitoring and performance analysis is one of the richest areas for network-management tools. Thissection reviews some of these tools, the ones that are IPv6 capable and that have been deployed in productionor experimental networks.
Argus is a system- and network-monitoring application that includes IPv6 support since version 3.2. It canmonitor TCP and UDP applications, IP connectivity, SNMP object identifiers, and so on. It comes with a webinterface. Argus contains built-in alert notifications via e-mail and pager, and can be extended to use any otherprogram such as winpopup. Figure 10-13 shows an Argus IPv6 screen.
Argus was started at Carnegie Mellon's Software Engineering Institute and is now distributed as open source.It is available at http://argus.tcp4me.com.
Nagios is an open-source host-, service-, and network-monitoring program. The monitoring plug-ins wererecently ported to support IPv6 and to operate over a native Ipv6 network. Figure 10-14 shows an IPv6 Nagiosscreen.
Nagios was initially created by Ethan Galstad under the Netsaint name and then later renamed. It is availableat http://www.nagios.org.
Ntop is an open-source web-based network-usage monitor that enables users to track relevant networkactivities, including network utilization, established connections network protocol usage, and trafficclassification. It supports various management activities, including network optimization and planning, anddetection of network security violations. In the context of the 6NET project, it was ported to IPv6. Ntop wasinitially developed by Luca Deri and is available at http://www.ntop.org. Ntop can be useful in the context oftroubleshooting.
MRTG is a tool to monitor the traffic load on network links. MRTG includes a Perl script, which gets trafficcounters from the router using SNMP, and an application that logs traffic data, creates graphs, and presentsthem over a web interface. The Computer Networks research group at Roma Tre University added IPv6support to MRTG in version 2.10.0. MRTGv6 can now run SNMP queries over IPv6. MRTG is alreadywidely used to monitor the traffic on network links, CPU usage on routers, and other network and hostparameters. MRTG is available at http://www.mrtg.org.
Weathermap is a Perl-based tool that displays in a visual way the utilization of the network links of thenetwork. The required data is acquired from graphs created by the MRTG package and are displayed astwo-way colored arrows on a map representing the logical topology of the network. The resulting image ispresented in a web page. Figure 10-15 shows a Weathermap screen on the 6NET network.
Figure 10-15. Weathermap Output Screen
[View full size image]
Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and UDPcharacteristics. Iperf reports bandwidth, delay jitter, and datagram loss. Iperf version 2.0.1 supports IPv6.
Pchar is a tool used to characterize the bandwidth, latency, and loss of links along an end-to-end path throughthe Internet. Pchar measures the characteristics of the network path between two Internet hosts on IPv4 or
IPv6 networks. The program measures network throughput and round-trip time by sending varying-sized UDPpackets into the network and waiting for ICMP messages in response. It modulates the IPv4 Time To Live(TTL) field or the IPv6 Hop Limit field to get measurements at different distances along a path. Pchar waswritten by Bruce A. Mah and is available at http://www.kitchenlab.org/www/bmah/Software/pchar.
Jnettop captures traffic coming across the host it is running on and displays streams sorted by bandwidth theyuse. The result is a set of network communications listed by host and port, including bytes out, bandwidthconsumption. Jnettop has been extended to support IPv6. Figure 10-16 shows a Jnettop screen monitoringIPv6 traffic.
Figure 10-16. Jnettop Output Screen
[View full size image]
Jnettop is available at http://jnettop.kubs.info
Configuration and Provisioning Management
Configuration and provisioning management are key network-management functions to control networkoperation.
Configuration management handles hardware and software changes, provides inventory of equipment andprograms, and manages configuration deltas. Besides integrated platforms (CiscoWorks, for instance, includesResource Manager Essentials with a set of applications to perform function such as inventory, configurationmanagement, and software), RANCID has become a major player in this arena.
Really Awesome New Cisco confIg Differ (RANCID) is a configuration archival management tool for Ciscorouters and switches, as well as equipment from other vendors. RANCID monitors a router's configuration,including software and hardware (cards, serial numbers, and so on). It works by periodically connecting to therouter (using Telnet, SSH, or rlogin) and recording the configuration. Any differences are flagged using diffand e-mailed to the operator and saved in Concurrent Versions System (CVS).
Cisco Resource Manager Essentials (RME) is part of CiscoWorks, reviewed in the section "ManagementPlatforms." It provides a GUI for managing the configuration and inventory. It includes a configurationviewer with IPv6 support (both IPv6 addresses and commands), facility to compare archive versions of theconfiguration (with IPv6 address and commands), and facility to set up configuration templates (which acceptIPv6 addresses). An example of an RME screen capture is shown in the section "CiscoWorks."
Network provisioning is the operation where network resources are allocated to nodes (or clients) to enablethem to access the network services. As far as IPv6 is concerned, address provisioning is one important aspect
to look at. As reviewed in the section "Allocating IPv6 Addresses to Managed Nodes," several methods canbe used to allocate IPv6 addresses to nodes, and stateful DHCP is one that provides centralized addressprovisioning. Cisco Network Registrar (CNR) is a DNS and DHCP server product that supports IPv6addressing for DHCP (starting at version 6.2). It includes capability for the following:
Stateless autoconfiguration (RFC 3736) The DHCPv6 server does not assign addresses, but insteadprovides configuration parameters, such as DNS server data, to clients.
•
Stateful autoconfiguration (RFC 3315) The DHCPv6 server assigns (nontemporary or temporary)addresses and provides configuration parameters to clients.
•
Prefix delegation (RFC 3633) The DHCPv6 server does prefix delegation to clients (routers).•
Management Platforms
Network-management platforms integrate all the managementtools in one framework. The most popular (HP OpenView,Tivoli NetView) manage far more than the network, integratingapplication, processes, and so on.
However, integrated platforms must rely on fully acceptedstandards to manage a wide range of heterogeneous devices. Forthe network, it is essentially SNMP and MIBs. As discussed inthe "SNMP and MIBs" section, not all IPv6 MIBs are apublished standard. The IPv6-only MIBs are published RFCs,and the plan is to deprecate them as soon as the correspondinggeneric MIBs (v4 and v6) are published. In that context,integrated management platforms have been slow IPv6adopters. Some of the major vendors have not yet announcedtheir IPv6 plans. Some, however, such as Cisco and HP, arenow proposing some IPv6 support in their respectivemanagement suites.
CiscoWorks
CiscoWorks is a family of products based on Internet standardsfor managing Cisco networks and devices.
The CiscoWorks product line offers a set of solutions designedto manage the enterprise network. These solutions focus on keyareas in the network such as optimization of the WAN,administering switch-based LANs, securing remote and localvirtual private networks, and measuring SLAs within all typesof networks.
The CiscoWorks product line includes a set of managementcomponents, bundled in solution offerings such as SmallNetwork Management Solution (SNMS), LAN ManagementSolution (LMS), Network Analysis Module (NAM) for CiscoCatalyst 6500 and 6000 series, and so on.
The list of major components is as follows:
384 Part I: Implementing IPv6 Services
384 Part I: Implementing IPv6 Services
CiscoWorks Server and CiscoWorks Common Services• Access Control List Manager (ACL)• Campus Manager (CM)• CiscoView• Device Fault Manager (DFM)• Internetwork Performance Monitor (IPM)• nGenius Real-Time Monitor (RTM)• Resource Manager Essentials (RME)• Voice Health Monitor (VHM)• Service Level Manager• Security Policy Manager and Host Intrusion•
Major releases of CiscoWorks components have been madeIPv6 capable.
Table 10-5 lists all CiscoWorks components and solutions andgives a status on IPv6.
Table 10-5. IPv6 Readiness of CiscoWorks Tools
Application DescriptionIPv6Status
CiscoWorks Common Services CiscoWorks Common Services is anadd-on to the CiscoWorks2000Server.
CS3.0
ACL Manager Access control list management onCisco routers and Catalyst switchesas an add-on to RME.
Not yet
Campus Manager Web-based network-managementtools that provide graphical views ofnetwork topology and end-userinformation.
4.0
CiscoView CiscoView is a graphicalSNMP-based device-managementtool that provides real-time views ofnetworked Cisco Systems devices.
6.1
Device Fault Manager Data fault analysis for Cisco devices.Not yetInternetwork Performance Monitor Network response time and
availability troubleshootingapplication.
Not yet
NetScout nGenius Real-Time Monitor Allows understanding currentnetwork and plan for future need.Help to troubleshoot problems areasin the network. Include Server (datacollection/presentation), TrafficMonitor, Packet Analyzer and VoIPmonitor.
Not yet
Resource Manager Essentials Device tracking with networkmonitoring and fault data,deployment for software images, andconfiguration displays for Ciscorouters and Catalyst switches.
SomeIPv6supportin 4.0
Voice Health Monitor Manages the voice-specific devicesin a network.
Not yet
Service Level Manager Not yet
Part I: Implementing IPv6 Services 385
Part I: Implementing IPv6 Services 385
Service-level contract managementand implementation of SLAs for SPs.
Secure Policy Manager Policy-based management of CiscoSecure PIX Firewalls and IOSrouters running Cisco SecureIntegrated Software and CiscoSecure Integrated VPN Software.
Not yet
CiscoWorks added support for IPv6 in the following areas:
CiscoView is a web-based management tool that provides dynamic status, statistics, and comprehensiveconfiguration information for Cisco internetworking products (switches, routers, hubs, concentrators, andaccess servers). When the IPv6 device package is installed, CiscoView manages IPv6 functionality usingTelnet/SNMP over IPv4 transport using dual stacks. IPv6 management features are launched from the device'scontext menu. CiscoView can provide the following IPv6 information:
RME consists of various applications such as inventory, configuration management, software management,availability, and syslog.
Inventory uses SNMP credentials of the device to collect device information and manage it. To manageIPv6-enabled devices, the current RME version requires them to be dual stack, so that it can use the IPv4addresses for management.
Configuration management within RME provides configuration backup, view, update, and track capabilities.It can archive IPv6 configurations, configure IPv6 information on multiple devices, edit an IPv6configuration, and periodically run show commands on IPv6 devices and store the output.
Figure 10-18 shows how configuration can be archived and managed with RME.
Figure 10-18. CiscoWorks RME (Config-viewer)
[View full size image]
NatKit (Network Analysis Toolkit) within RME is a suite of web-based troubleshooting tools integrated into anetwork desktop. NATkit collects network data through SNMP requests, Telnet commands, and syslog eventmessages to produce consolidated reports accessible through a web browser. Although no IPv6 NatKit supportis available at the time of this writing, the plan is to support IPv6 in future versions.
Campus Manager 4.0 provides support for IPv6 in the following network scenarios:
Devices that might have IPv6 configured on their interfaces, but that have at least one IPv4 interface.Devices are managed using IPv4.
•
Hosts running IPv6 are supported in the user-tracking application.•
Campus Manager has been updated as follows for IPv6 support:
Discovery Discovery can collect IPv6 address and related information from devices, which isleveraged in user tracking and path analysis.
•
Part I: Implementing IPv6 Services 387
Part I: Implementing IPv6 Services 387
User tracking IPv6 support in user tracking is available on both Solaris and Windows servers. In usertracking, hosts configured with an IPv6 address are discovered and shown in the main table. IPv6name lookup (reverse name lookup only) is done if IPv4 name lookup fails. All global unicastaddresses are fetched and used for user-tracking computation, but link-local addresses are dropped.User-tracking end-host reports have an IPv6 format.
•
Ping sweep applicability to IPv6 subnets Ping sweep functionality is currently available for Class C orsmaller subnets. Because with IPv6 each of the networks can be larger than Class C networks,individual IPv6 addresses cannot be determined in a given network/subnetwork, ping sweep is not onany of the IPv6 Subnets.
•
Path analysis Path analysis has been modified to support only the IPv6 source to IPv6 destinationthrough IPv6 network scenario.
•
Figure 10-19 illustrates IPv6 support in Campus Manager for user tracking.
Several other network-management platforms are leaders in the IPv4 network-management arena, and theirIPv6 readiness is key in IPv6 adoption. They are, namely, HP OpenView, NetView, and InfoVista.
HP OpenView
HP OpenView is a framework that defines an architecture for managing hosts, applications, and a largevariety of networking devices. OpenView Network Node Manager (NNM) handles the networking portion ofOpenView. It is based on SNMP and provides a wide range of network-management features, such as deviceand topology discovery, device monitoring, and so on.
Within OpenView NNM, Extended Topology discovers the existence of networking devices and createsmaps. Starting with NMN 7.0, Extended Topology can also discover IPv6 devices and create maps showinglayer 3 IPv6 nodes. It can then monitor the status of each of the discovered IPv6 devices. To discover the IPv6
388 Part I: Implementing IPv6 Services
388 Part I: Implementing IPv6 Services
devices, the most efficient way (sometimes the only way; see the section "Autodiscovery") is to configure thelist of addresses to be discovered. To discover and monitor the IPv6 devices, Extended Topology relies onIPv6 MIBs and on IPv6 ping. Currently, the only IPv6 MIBs supported by HP OV are published RFCs (RFC2465, RFC 2452, RFC 2554, RFC 2465, RFC 2566). Unified TCP and UDP MIBs have been publishedrecently as RFC 4022 and RFC 4113, respectively, and other basic unified MIBs are about to becomestandard. Logically, both Cisco and HP OV will upgrade to the set of unified MIBs as soon as this happens.
Tivoli NetView
IBM Tivoli NetView discovers and displays network topologies, correlates and manages events and SNMPtraps, monitors network health, and gathers performance data. At the time of this writing, Tivoli NetViewdoes not support IPv6.
InfoVista
InfoVista software collects data from the IT infrastructure and generates reports on the performance andservice achievements across all system elements (networks, systems, and applications). It provides traps,views (in real time), and reports. At the time of this writing, no IPv6 support is available for InfoVista.
IPv6 Network Management Servicesand Tools at a Glance
Table 10-6 summarizes IPv6-enabled managementtools, per management service area.
PcharConfiguration management Telnet, TFTP, RSH RANCIDAddress provisioning DHCP CNRService management Telnet, SSH, RSH, and so
onLooking Glass
NtopEquipment management Ping, traceroute, SNMP,
Telnet, RSHLooking Glass
Accounting management NetFlow NetFlow
In practice, managing an IPv6 network will vary significantly depending on the segment of the network beingconsidered (site, access, core), on the tools strategy chosen (integrated NMS, standalone tools, home-madetools, and so on), and on the coexistence strategy with IPv4 (dual-stack network managed mostly with IPv4,separation between IPv4 and IPv6, IPv6-only networks).
Given the state of IPv6 management tools and products, there is no one-fits-all solution. Integrated NMSs relymostly on MIBs, which are not all ready for IPv6 deployment. In addition, many tools used in the IPv4environments have not yet been migrated to IPv6.
Managing dual-stack networks using a mixture of IPv4 tools (for instance, for topology discovery) and toolsproviding some IPv6 support sounds like a viable deployment approach today. So far in this book, therecommendation has been to avoid differentiating IPv4 and IPv6 as much as possible when operated in adual-stack network. Network management does not deviate from this rule. Most events generating alerts andtriggering network-management actions should remain applicable when IPv6 is deployed: host down, linkdown, traffic threshold, service anomalies, performance anomalies, and so on. For IPv6-specific alerts andcorresponding actions, tools do exist that complement well the panoply.
Network simulation tools, such as OPNET, Qualnet, NS-2, OMNeT++, and so on, are available for validatingthe IPv6 network design and the impact of deploying IPv6 in an existing IPv4 network. These tools offereither built-in IPv6 capabilities or some flexible way to simulate IPv6 mechanisms.
Managing IPv6-only networks or simply IPv6-only devices coexisting with IPv4-only and dual-stack devicesappears to be problematic. It may require deploying a combination of specialized tools, home-made tools, andan NMS providing some IPv6 support (HP OverView, CiscoWorks). Even so, lack of full IPv6 MIB supportand other issues reviewed in the chapter might lead to management areas poorly covered. Over time, IPv6MIBs are going to be available and supported by the NMS.
IPv6-only networks are going to be a reality sooner than later. For these networks, IPv6 network-managementparity with IPv4 in terms of MIBs and management tools will be a primary requirement.
Finally, you cannot assume that IPv6 deployments will fully match IPv4 deployments in terms of behavior,requirements, issues, and, consequently, management tools. IPv6 can introduce new management methodsand strategies. Easier and more automatic renumbering, for instance, is likely to influence currentnetwork-management approaches; it could lead to new tools while obsolescing others.
390 Part I: Implementing IPv6 Services
390 Part I: Implementing IPv6 Services
Chapter 11. Network Performance Considerations:Coexistence of IPv4 and IPv6
Years of innovation and work to continuously improve various transport technologies and network elementsled operators to have high expectations of their networks. Although richness of supported features candifferentiate networking equipment, high performance is expected by default. Nothing short of line-rateforwarding of raw traffic is expected for most high-speed interfaces of high-end routers and switches.
During the initial phases of its development, IPv6 was viewed as a mere feature, something new to play withand evaluate. Its implementation in software enabled router vendors to stay on the fast track of integrating therecommendations churned out by the standardization bodies. The IPv6 early adopters, universities anddevelopers were offered the tools to play and experiment with the protocol. Cisco engaged on this path with aphased program that led to Cisco IOS software officially supporting IPv6 features as early as 2001 in release12.2(2)T.
After the protocol consolidated and matured, the focus moved toward deployment considerations, and thatnaturally implied focus on IPv6 performance. Fast adoption of features remains important in the case of astill-evolving protocol. However, performance requirements force vendors to look at the entire architecture oftheir products and work on integrating IPv6 in every aspect of it. To meet competitive performancerequirements, depending on router architecture, both software and hardware have to take into account the newprotocol.
The whole topic of performance has an additional twist in the case of IPv6. Today, there are a few caseswhere brand new networks are built specifically for IPv6-based services. For all the other networks, whichinclude the vast majority, the operators ask a natural question: "What is the impact on my network of turningon IPv6?" The IPv4 infrastructure remains the source of revenue and supports the most important services.Bringing IPv6 into the network must not impact it negatively. The performance implications of IPv4 and IPv6coexistence can push the discussion from the network element level to a system level, a higher level ofcomplexity.
This chapter discusses the various aspects of router performance and the challenges posed by IPv6. It providesinformation and guidelines on evaluating a router's performance so that you can choose the right router for thejob.
Aspects of Router IPv6 Performance
It is commonly understood that routers and layer 3 switches are performing functions at different levels of theOSI model. With the increased complexity of supported features, these devices started to operate at levelsbeyond the original first three. It is therefore expected that routers operate in one form or another onparameters that could relate to most of the seven layers of the OSI model.
However, the main focus of a router's operation remains the network layer. Its functions can be separated intothree categories:
Control plane Handles the router's interaction with the other network elements, providing theinformation needed to take decisions and control the overall router operation. This plane runsprocesses such as routing protocols and network management. These functions are generally complex.
•
Part I: Implementing IPv6 Services 391
Part I: Implementing IPv6 Services 391
Data plane Handles packet forwarding from one physical or logical interface to another. It involvesdifferent switching mechanisms such as process switching and Cisco Express Forwarding (CEF) onCisco IOS software routers.
•
Enhanced services Cover router's leverage of advanced features that are applied when forwarding data(for example, packet filtering, quality of service [QoS], encryption, translation, accounting).
•
Figure 11-1 provides a conceptual representation of these functions. The specifics of their implementation andoperation depend on the router architecture.
Figure 11-1. Conceptual Representation of a Router: Data and Forwarding Planes
[View full size image]
Each of these router functions has its own performance characteristics. It is therefore important to qualify arouter's performance in the context of its control-plane, data-plane, or enhanced-services operation. IPv6presents each of these functions with specific new challenges.
IPv6 Control Plane
When IPv6 is enabled on a router, its control plane starts to operate processes specifically for it. Protocolcharacteristics shape the performance of these processes and the amount of resources necessary to operatethem:
Size of IPv6 addresses Address size impacts the information-processing functions of a router. Systemsusing a 64-bit CPU, bus, or memory structure can pass both the IPv4 source and destination address ina single processing cycle. For IPv6, the source and destination addresses require two cycles each, or atotal of four cycles to process the (source address, destination address) information. For this reason,routers that rely exclusively on software processing could see lower performance compared to IPv4.
•
Nodes use multiple IPv6 addresses Each IPv6 node can use several IPv6 unicast addresses such aslink-local and global unicast with different interface ID values. The increased number of addressesused impacts the memory consumption of the Neighbor Discovery cache.
•
392 Part I: Implementing IPv6 Services
392 Part I: Implementing IPv6 Services
IPv6 routing protocols The IPv6 routing protocols are similar to their IPv4 counterparts. However, anIPv6 prefix is four times larger than an IPv4 one, which means that routing updates have to carrymore information in the case of IPv6. This remains true despite various optimizations made to addressthis difference.
•
Size is one of the natural concerns about the IPv6 networks and the IPv6 Internet. Larger networks areexpected with the larger IPv6 address space. In principle, this implies larger routing tables and higher memoryrequirements to support them. At first, as deployments are incipient, this is not an issue. As the number andsize of IPv6 networks increases, aggregation and strict prefix allocation through the provider-enforcedhierarchy represent the means to control and reduce the size of the Internet routing table.
Currently, there are two main address types in the IPv6 Border Gateway Protocol (BGP) routing tables:
6Bone routing tables 3FFE::/16 prefix space allocated for development and experimentation• IPv6 production tables 2xyz::/16 prefix space allocated by the Regional Registries for productionaggregation
•
The 6Bone network will be retired by June 2006. Allocation rate in the 2xyz::/16 range is growing steadily.More than 1000 prefixes are now (February 2005) allocated and present in the IPv6 Internet table. To monitorthe growth and prefix distribution of the IPv6 Internet, several websites provide tools and statistics on IPv6routing tables:
http://www.sixxs.net/tools/grh/dfp/
http://www.switch.ch/network/ipv6/bgp/
http://net-stats.ipv6.tilab.com/bgp/temp0107.html
For a historical perspective, Figure 11-2 shows the prefix-allocation growth seen in the BGP routing tablessince 1998 (source TILAB).
Figure 11-2. Growth of IPv6 Internet Tracked by the Size of the BGP Routing Table
At the time of this writing, the number of IPv6 prefixes in the BGP routing tables is 2573. According to theTILAB statistics, the main contributions to the total number of prefixes present in the routing tables were, atthe date of the snapshot (January 2005), in this order:
IANA assigned prefixes. These are the IPv6 prefixes officially assigned by IANA and the Internetregistries to the requesting organizations for production use of IPv6, the sTLA prefixes.
1.
Unaggregated prefixes. These are the IPv6 prefixes belonging to the 6Bone addressing space that arelonger than the correspondent pTLA delegation.
2.
6Bone pTLA prefixes assigned to the backbone sites.3. Invalid prefixes. These are IPv6 prefixes that do not belong to the address space assigned by IANA.4.
The growth rate depicted in Figure 11-2 is expected to accelerate in the coming years. Similar to IPv4,tracking the size of the BGP IPv6 routing tables remains very important for service providers (SPs) to betterplan network resources such as router memory.
Independent of the routing table size, users want to know whether IPv6 routing protocols perform well interms of convergence. Because of their similarity to the IPv4 counterparts, the convergence performance ofthe IPv6 routing protocols is generally similar to the IPv4 ones.
In general, it should be expected that IPv6 and IPv4 will be competing for the control-plane resources. For thisreason, bringing IPv6 into an operational network has to be done in a controlled way and with full informationabout its potential impact. If justified by the available router resources or the network conditions, limitationscan be placed on IPv6 processes or the router's interaction with other network elements. The intent is toprotect and reserve the CPU or memory resources for the existent revenue-generating IPv4 services.
IPv6 and the Data Plane
The data plane is responsible for forwarding the IP packets based on the decisions made by the control plane.The forwarding engine has to parse the relevant IP packet information. It then has to do a lookup to match theparsed information against the forwarding policies defined by the control plane. The performance of both"parsing" and "lookup" functions is impacted by IPv6 protocol specificities:
Parsing IPv6 extension headers Applications such as mobile IPv6 or source routing often include IPv6address information in the extension headers, which significantly increases their size. These additionalfields need to be accounted for in the hardware registers to properly read the extension headers and,deeper into the packet load, the layer 4 headers. An example is the case where the router has accesscontrol lists (ACLs) that filter on layer 4 information. The router has to be able to apply them topackets with extension headers, too. If the length of the extension headers exceeds the fixed length ofthe hardware registers, hardware switching does not occur. In this case, the packet is punted tosoftware switching, and that has a severe impact on the forwarding performance.
Note
Not all routers on the market choose to punt into the software path the packets that they cannot handlein hardware. In those cases, the packets are simply dropped.
•
IPv6 address lookup The IPv6 lookup occurs when a valid packet enters the router and needs to findan output interface. When the forwarding decision is made based on the destination address, thisprocess entails parsing a maximum of 128 bits rather than 32 bits for IPv4. To improve the lookup
•
394 Part I: Implementing IPv6 Services
394 Part I: Implementing IPv6 Services
performance, the lookup algorithm has been modified. A 128-bit lookup is rare because it applies onlyto host routes, including anycast addresses, which should have a limited presence. An anarchicallocation of anycast addresses can be problematic because a lot of host routes would be injected inthe IPv6 routing table. In a typical autonomous system, however, following the address allocationrecommendations documented in RFC 3177, it is expected that for a service provider, the majority oflookups are centered on a few fixed values: /32 in the core of the network, /48 in the distributionlayer, and /64 at the edge.
Depending on the router type, lookups are performed by a multipurpose CPU or by an application-specificintegrated circuit (ASIC) with a fixed configuration or with a microcode. This impacts the performance andthe versatility of the router functions. Software processing of the IPv6 lookup takes more time than for IPv4because more bits must be processed. The multipurpose CPU is slower but can perform functions based on alimitless program. The ASIC with microcode allows for a certain degree of flexibility in the performedfeatures, although the fixed ASIC performs only the functions for which it was initially designed. Because theIPv6 lookup is more demanding (theoretically four times more demanding), there is a natural tendency toleverage hardware-based lookup engines as much as possible. Hardware-based lookup designs generally leadto IPv6 line-rate forwarding at all interface speeds for most packet sizes.
Note
Not all hardware forwarding platforms in the market achieve line-rate forwarding of IPv6. It is thereforeimportant to evaluate a router's capability, regardless of its architecture.
Note
The hardware forwarding option can come to the detriment of feature richness. If new features need to beadded, the ASICs need to be redesigned, which is a much longer and more costly process than that ofimplementing it in software.
The performance of the various processes and functions discussed in this section depends on the architectureof each router. An overview of these architectures is presented later in this chapter along withperformance-data examples.
Measuring Forwarding Performance
Following the discussion about the various aspects of router performance, it is important to understand how tomeasure and test it. This is a significant part of evaluating a platform for a particular role within a deployednetwork. Consistent and universally accepted test methodologies should be observed for objective evaluations.
Most often, router performance is associated with its forwarding capabilities. Resource requirements cantypically be addressed by increasing the router memory or selecting more powerful processors; however, theforwarding performance is generally limited by the platform design. For this reason, the focus of this sectionis on the best practices for measuring the IPv6 throughput of a router.
Part I: Implementing IPv6 Services 395
Part I: Implementing IPv6 Services 395
Regardless of the IP protocol type, forwarding performance testing is best performed in a black-boxenvironment. The stimulus and the measurements are independent of the device tested and its architecture.RFC 2544 provides general guidelines and requirements for throughput testing:
Throughput, as defined in RFC 1242, is measured as nondrop rate (NDR), the maximum traffic ratewith no packet drop.
•
The NDR should be determined in steps of 60 or fewer seconds and then verified by forwardingtraffic for a minimum of a 60-second time interval at the determined NDR.
•
Frame sizes tested should cover the set recommended for the various media types. In the case ofEthernet, for example, 64, 128, 256, 512, 1024, 1280, and 1518 bytes.
•
Traffic should be bidirectional, unless otherwise specified.•
Note
These recommendations are made to evaluate the performance of forwarding unicast traffic. However, it isalso important to evaluate the forwarding performance of multicast traffic, too. This type of traffic will mostlikely be present in the IPv6 deployments. With multicast, the test options are multiple because there arevarious ways in which the router can replicate traffic. For this reason, it is best for the evaluation to beperformed based on traffic patterns and requirements specific to the network role for which the router isevaluated.
Note
The larger IPv6 addresses require more intense lookups, and that can impact the router performance, asmentioned in the previous section. For this reason, it is more important to evaluate a router's forwardingperformance for prefixes of various lengths in the /16 and /64 range in IPv6 than in IPv4.
All major test tool vendors provide RFC 2544based test suites that can be used to measure the NDR ofdevices under test (DUT). These suites can be executed with both IPv4 and IPv6 traffic. They are well suitedto black-box testing, and they offer a certain level of consistency for this type of measurement.
Note
The test tool suites offer multiple tuning parameters, so it is important to be aware of their settings and ensurethey meet the requirements of RFC 2544.
The test tools that form the shell around the DUT should be complemented with a few probes that acquire datafrom the DUT itself. Relevant data that should be collected during test includes memory utilization andintegrity, CPU values at box or linecard level, and general system messages. Although throughput data initself is important as far as a standalone router is concerned, sometimes NDR is obtained at 100 percent use ofthe CPU. From a network operation perspective, this is unacceptable because the router might have to totallyneglect its control-plane to meet the measured NDR.
Note
396 Part I: Implementing IPv6 Services
396 Part I: Implementing IPv6 Services
Considering all the parameters that are being measured during the evaluation, it is always a good practice todefine a baseline for the test environment that is being used.
The advantage of the black-box testing approach is that it allows for a consistent evaluation of forwardingperformance of raw traffic as well as complex traffic that includes higher-layer content or extension headers.It also provides a good way to evaluate the impact on performance of advanced features (access lists, forexample) enabled on the DUT. A black-box approach to testing allows for a clear one-to-one comparison ofthe results obtained in each of these cases. It also allows for meaningful comparisons between IPv4 and IPv6throughput performance data.
Note
Note that the minimum packet size for IPv6 is larger than IPv4 (IPv6 header: 40 bytes; IPv4 header: 20 bytes).This is important when considering the low-packet-size performance data.
It is important to mention that there are also two different ways to look at the throughput performance of arouter:
Interface-to-interface throughput refers to measuring the NDR by sending bidirectional traffic throughtwo same-type interfaces of the DUT.
•
System throughput refers to measuring the NDR by sending bidirectional traffic through all interfacesof a router that is fully populated in terms of linecards and interfaces.
•
Both tests are conceptually similar, and they should observe the RFC 2544 recommendations.
It is generally expected that a router's IPv6 forwarding performance is similar to its IPv4 forwardingperformance and as close as possible to the line rate of the tested interface.
The Right Router for the Job
When choosing a router for a certain role in a network, performance is not the onlyfactor considered. Others are equally important, such as the following:
Feature richness and versatility• Price• Scalability•
All these factors reflect certain aspects of a router's design. Previous sectionshighlighted some of the IPv6-specific challenges faced by a router's control andforwarding planes. Ultimately, a router's performance is determined by itsimplementation of the control and forwarding functions as well as its integrationof the IPv6 protocol. For this reason, it is important to have an idea of the overalldesign of the evaluated router when analyzing its performance data.
Part I: Implementing IPv6 Services 397
Part I: Implementing IPv6 Services 397
Router Architecture Overview
Routers evolved from mere specialized computers where all processing is softwarebased to sophisticated devices where functionality is shared between softwarerunning on powerful CPUs and highly specialized hardware. Routers arebecoming more powerful, more reliable, and more scalable; but all this comes at acost. It is therefore important to build the right router for the right market segment.This explains the multitude of router types available from which to choose.
Software Versus Hardware Forwarding
The control-plane functions of a router are always performed in software. On theother hand, packet forwarding along with some advanced features can beperformed by dedicated hardware resources. Based on the implementation of theforwarding plane, routers can be classified as follows:
Software forwarding router A device using its main CPU for basic andenhanced packet forwarding; no hardware assistance is available.
•
Hardware Forwarding Router A device that has hardware assistance forbasic or enhanced packet forwarding.
•
Note
A packet that cannot be handled by the hardware is usually punted to softwareprocessing by default. This is not true for all router vendors.
Hardware-assisted forwarding often provides the best forwarding performance.This advantage comes at the expense of versatility. The dedicated hardware isdesigned to support a certain set of features, so additional features require itsredesign. For this reason, hardware-forwarding-based platforms are generally wellpositioned in or close to the network core and edge. There the interfaces are highspeed, and the focus is on forwarding performance rather than feature richness.Software-forwarding-based platforms are more suited in the access layer, wherethe interfaces are lower speed, and various features are being used.
Both types of routers are present in the Cisco product line:
Software forwarding routers Cisco 800, 1700, 1800, 2600, 2800, 3600,3700, 3800, 7200, and 7500 series
•
Hardware forwarding routers Cisco 7600, 10000, 10720, 12000 series andthe Cisco Carrier Routing System (CRS-1); layer 3 switches: Catalyst6500, 3560 and 3750 series
•
Centralized Versus Distributed Forwarding
A router can take all its forwarding decisions in a centralized manner or it candistribute the function among multiple intelligent subsystems. This design choiceseparates routers in two categories:
398 Part I: Implementing IPv6 Services
398 Part I: Implementing IPv6 Services
Centralized forwarding router Every packet-forwarding decision is madeby a central forwarding engine.
•
Distributed forwarding router Forwarding decisions are made on differentforwarding engines that can control a linecard, a port, a section of achassis, and so on.
•
Note
All forwarding engines involved in the decision-making process have to supportIPv6. If they do not, the router defaults to a centralized mode of operation.
The distributed architectures are particularly important for larger, modular routersthat have to scale well with additional linecards. When the forwarding decisionmaking is distributed to these intelligent cards, the router performance is notimpacted by an increase in the number of interfaces and modules. This type ofrouter is prevalent at the core and the edge of the network.
Examples of distributed, IPv6-capable routers from the Cisco family include thefollowing:
Cisco 7500 series router• Cisco 7600 series router with distributed CEF 720 linecards• Cisco 12000 series Internet router• CRS-1 router•
Note
A distributed architecture also allows software forwarding platforms to have aperformance close to line rate and that scales linearly as cards are added. This isthe case of the 7500 Cisco routers.
The concepts presented in this section represent a high-level overview of routerarchitecture. These concepts can help you classify routers and have certainperformance expectations from them based on their design. However, today'srouters are complex systems, and there is a lot more to a complete and thoroughdiscussion of their architecture than what is covered in this brief discussion. Formore detail on this topic, refer to the book Inside Cisco IOS Software Architecture(CCIE Professional Development) by Vijay Bollapragada, et al.
IPv6 Forwarding Performance of Cisco Routers
Armed with an understanding of the various router architectures and themethodology to test their performance, it is time to see the differences betweentheir IPv4 and IPv6 performance. This section presents forwarding performanceexamples for the two protocol types on Cisco routers that target various segmentsof a network.
Part I: Implementing IPv6 Services 399
Part I: Implementing IPv6 Services 399
Low-End Routers
The low-end routers are typically deployed in the access layer of the network.They generally have low speed and few interfaces. Because they aresoftware-based routers, they are easily enabled to support IPv6. The Cisco productline from the 830 series to the Cisco 3800 series can be easily enabled for IPv6when it is upgraded to one of the supported Cisco IOS software release, such as12.2T, 12.3, 12.4, 12.3T, and 12.4T. Low-end routers have a centralizedarchitecture.
Note
CEF is available for IPv6 (Cisco Expressing Forwarding v6 and distributed CiscoExpressing Forwarding v6) starting with Cisco IOS Release 12.2(13)T.
Despite being software platforms, many of the low-end routers use powerful CPUsthat enable them to achieve line-rate packet forwarding on their interfaces. Toprovide encryption services, which are particularly CPU intensive, hardwareassistance might be needed to sustain the same performances as the other services.
Table 11-1 presents an example of how IPv6 compares to IPv4 performance on alow-end router from the Cisco 3700 series. The throughput was determinedbetween two Fast Ethernet interfaces, with bidirectional traffic and no advancedfeatures enabled. The theoretical maximum throughput for the interface typeanalyzed is also listed for reference. Figure 11-3 is a graphical representation ofthe forwarding performance in percentage of the targeted line rate.
Table 11-1. IPv6 Basic Forwarding Between Two Fast Ethernet Interfaces,Bidirectional, No ACL on Cisco 3725
Figure 11-3. Example of IPv4 Versus IPv6 Forwarding Performance of a Low-End Router (Cisco 3725 - FastE)
400 Part I: Implementing IPv6 Services
400 Part I: Implementing IPv6 Services
Note
IMIX is a 7:4:1 distribution of Ethernet-encapsulated packets of sizes 64, 570, and 1518 bytes. This leads to a353-byte packet-size average.
Note
Sometimes the performance numbers are multiplied by a factor of two when bidirectional traffic is usedduring testing. For this reason, it is important to fully qualify the test methodology used.
It is worth noting that line-rate forwarding is obtained before the IMIX packet size, which represents a likelypacket-size distribution in an operational network.
Mid-Range Routers
In the case of mid-range routers, finding the balance between cost, features, and performance becomes evenmore important. Routers in this market segment can be positioned in different roles and have to performmultiple functions from access to distribution/aggregation and even core at times. The versatility required ofthe mid-range platforms is reflected in the multitude of router architectures applied to them. Software andhardware forwarding, as well as centralized and distributed architectures, are all present.
Leveraging powerful CPUs allows routers with low density of ports to deliver competitive forwardingperformance while maintaining the edge in terms of feature richness. Table 11-2 shows the performance dataof a Cisco-software-based, centralized forwarding mid-range platform. The performance is measured with
Part I: Implementing IPv6 Services 401
Part I: Implementing IPv6 Services 401
bidirectional traffic between two Gigabit Ethernet interfaces on a 7304 router with an NPE-G100 processor.Figure 11-4 is a graphical representation of the information in Table 11-2. It shows IPv4 versus IPv6throughput performance in percentage of targeted line rate.
Table 11-2. Cisco 7304 NPE-G100 Performance Between 2 Gigabit Ethernet Interfaces, Bidirectional, No ACL
Packet Size (Ethernet II)
GEIPv4 (pps)
GEIPv6 (pps)
Maximum (pps)
64 bytes
569,103
330,213
1,488,095
128 bytes
579,586
330,213
844,595
256 bytes
452,898
332,877
452,898
512 bytes
234,962
234,962
234,962
1024 bytes
119,731
119,731
119,731
402 Part I: Implementing IPv6 Services
402 Part I: Implementing IPv6 Services
1518 bytes
81,274
81,274
81,274
IMIX
334,224
334,224
334,224
Figure 11-4. Example of IPv4 Versus IPv6 Forwarding Performance of a Mid-Range Router (Cisco 7304 - GigE)
The IPv6 forwarding performance is at line rate below IMIX average packet sizes. On the other hand,mid-range routers from this family can maintain high forwarding performance even with advanced featuresenabled such as access control lists (ACLs). This is not always the case with mid-range hardware platformsavailable on the market. Table 11-3 shows the impact of ACLs on the performance of a Cisco 7200 routerwith an NPE-G1 processor. Unidirectional traffic was used and 100 ACLs were enabled on the ingressinterface. The data is graphically represented in Figure 11-5.
Part I: Implementing IPv6 Services 403
Part I: Implementing IPv6 Services 403
Table 11-3. Cisco 7200 NPE-G1 Performance Between 2 Gigabit Ethernet Interfaces, Unidirectional, With andWithout ACLs
Packet Size (Ethernet II)
IPv6 Without ACLs (pps)
IPv6 With ACLs (pps)
Maximum (pps)
64 bytes
561,209
287,377
1,225,490
128 bytes
558,280
288,403
753,012
256 bytes
425,170
288,988
425,170
512 bytes
227,272
227,272
227,273
1024 bytes
117,702
117,702
117,702
1280 bytes
94,840
404 Part I: Implementing IPv6 Services
404 Part I: Implementing IPv6 Services
94,840
94,841
1518 bytes
81,274
81,274
81,274
Figure 11-5. IPv6 Forwarding Performance With and Without ACLs (Cisco 7206)
Note
If a router is evaluated in a role that involves the extensive use of advanced features such as ACLs, it isimportant to evaluate the impact of these features on its forwarding performance.
Note
The router performance when running advanced features is of particular importance in the case of IPv6.Transition mechanisms such as IPv6 over IPv4 tunneling are falling in this category, so it is important toevaluate a router's performance in this context. Software platforms are well positioned in this case because
Part I: Implementing IPv6 Services 405
Part I: Implementing IPv6 Services 405
packet switching is done in software for both native and tunneled IPv6 traffic. Hardware assist for IPv6 overIPv4 tunneling is not generally available.
When a mid-range platform is targeted for an aggregation role, a centralized, software forwarding designmight be challenged by the high number of interfaces involved. In a distributed architecture, however, theforwarding performance is scaling linearly when interfaces are added to the system. An example of such aplatform is the Cisco 7500 that leverages the distributed Cisco Express Forwarding (dCEF) feature. Anexample of forwarding performance numbers measured for the OC-3 interface of this router is shown in Table11-4. Figure 11-6 also shows this data.
Table 11-4. Cisco 7500 RSP4 or RSP8 + VIP4-80 POSIP OC-3, Bidirectional, No ACL
Packet Size (Ethernet II)
OC-3 IPv4 dCEF (pps)
OC-3 IPv6 dCEF (pps)
Maximum (pps)
64 bytes
198,504
166,000
353,208
128 bytes
153,500
153,490
160,000
256 bytes
76,408
76,408
76,408
512 bytes
37,365
37,365
37,365
406 Part I: Implementing IPv6 Services
406 Part I: Implementing IPv6 Services
1024 bytes
18,480
18,480
18,480
1518 bytes
12,422
12,422
12,422
Figure 11-6. Example of IPv4 Versus IPv6 Forwarding Performance of a Mid-Range Router (Cisco 7500 OC3).
[View full size image]
Higher performance needs generally make hardware forwarding assistance necessary in high-end routers.
High-End Routers
Moving closer to the core of the network, routers need to support multiple very high-speed interfaces such asGigabit Ethernet, 10 Gigabit Ethernet, OC-48, OC-192, and OC-768. To maintain line-rate forwarding,routers cannot rely on CPUs anymore; hardware assistance becomes necessary. To exemplify this need onhigh-end routers, Table 11-5 depicts the differences in performance on a Cisco Catalyst 6500 series switch
Part I: Implementing IPv6 Services 407
Part I: Implementing IPv6 Services 407
and Cisco 7600 Series Router for various switching paths.
Table 11-5. Performance of Various Switching Paths on Catalyst 6500 / Cisco 7600
Switching Path
Performance
Process switched mode
1030 Kpps
Software CEF switch mode
230 Kpps
Centralized PFC3 on a Supervisor Engine 720 for native IPv6 Cisco IOS 12.2(17a)SX1
+20 Mpps
Supervisor Engine 720 with distributed PFC3 on linecards
+200 Mpps
This data clearly shows the performance enhancements that come through hardware assist. Actualperformance numbers for another high-end Cisco router that performs IPv6 forwarding in hardware are shownin Table 11-6.
Consult Cisco documentation to identify the routers and router linecards that support hardware forwarding ofIPv6.
Figure 11-7 shows the forwarding performance improvement at low packet sizes because of itsimplementation in hardware. The other advantage of hardware forwarding is that IPv4 and IPv6 traffic willnot compete for processor resources. Turning IPv6 on is not going to impact the forwarding of existent IPv4traffic.
Figure 11-7. Example of IPv4 Versus IPv6 Forwarding Performance of a High-End Router (Cisco 12000 OC48)
Part I: Implementing IPv6 Services 409
Part I: Implementing IPv6 Services 409
Cisco CRS-1 is its flagship of core routers, and it represents the most compelling example of highperformance achieved through advanced hardware forwarding design. Independent studies by the EuropeanAdvanced Networking Test Center show that it can forward IPv4 and IPv6 traffic at line rate through OC-768(40 Gbps) interfaces with and without advanced features enabled. The system throughput for the singlechassis configuration is 640 Gbps, although the multichassis configuration is 1.28 terabits per second. It alsoachieves line rate at these speeds for traffic mixes (85 percent IPv4, and 15 percent IPv6).
6PE Forwarding Performance
6PE and 6 VPE are key migration options in the deployment of IPv6. See the section "IPv6 over 6PE" inChapter 3, "Delivering IPv6 Unicast Services," and Chapter 7, "VPN IPv6 Architecture and Services," fordetails about these technologies. IPv6 forwarding performance through a 6PE environment is an importantfactor when weighing a certain deployment strategy. A Multiprotocol Label Switching (MPLS)-enabled corehas high forwarding performance, close to line rate, of labeled traffic irrespective of the IP version of thepackets. It is thus up to the PE routers to avoid reducing the end-to-end forwarding performance of IPv6 in a6PE deployment.
In the case of 6PE and 6VPE, there is a level of asymmetry in terms of forwarding performance. Routers willexhibit a certain performance when traffic flows from the IPv6 side toward the MPLS core (router performslabel imposition) and when it flows in the opposite direction (router performs label disposition). For thisreason, a simple bidirectional traffic test is not fully revealing because the forwarding performance result isshaped by the lowest of the performances in each individual direction. In this case, the right testing approachis to use unidirectional streams and analyze each direction separately.
Note
The same approach should be applied when evaluating the forwarding performance over IPv6 tunnels.
410 Part I: Implementing IPv6 Services
410 Part I: Implementing IPv6 Services
Table 11-7 lists the 6PE forwarding performance data for the OC-48 ISE card of the Cisco 12000. Forwardingis hardware assisted for this platform. The performance in the "label imposition" direction shapes the overallperformance on the path. In the Cisco implementation of 6PE, a different label is usually associated with eachprefix, so no IPv6 lookup is performed on the egress 6PE. For this reason, the expected performance in the"label disposition" direction is the usual MPLS performance (line rate on this card). This forwarding data isrepresented graphically in Figure 11-8.
Table 11-7. Unidirectional 6PE Traffic on Cisco 12000 with OC-48 Engine 3 Linecard
Packet size (IP)
Imposition - OC-48 (Mpps)
Disposition - OC-48 (Mpps)
64 bytes
3.8
3.84
128 bytes
1.91
1.95
256 bytes
1.11
1.11
512 bytes
0.570
0.570
1024 bytes
0.289
0.289
1500 bytes
0.198
0.198
Part I: Implementing IPv6 Services 411
Part I: Implementing IPv6 Services 411
Figure 11-8. 6PE Forwarding Performance in the Label Imposition and Label Disposition Directions (Cisco 12000OC48)
The forwarding performance for 6PE is close to line rate for most (and the relevant) packet sizes. Similar highperformance is also available with software-switched platforms, and that certainly qualifies the 6PE solutionfor large-scale, high-performance deployments.
IPv6 Router Performance EvaluationChecklist
For the time being, the IPv6 networks are small compared withIPv4, and the IPv6 traffic most likely represents a fraction of theexistent IPv4 traffic. For these reasons, operators would tend tolook at IPv6 performance in terms of its impact on therevenue-generating IPv4 services. As focus moves towardlarge-scale deployments, router IPv6 performance becomes animportant factor in network planning and design.
This chapter underlines the relevant aspects of routerperformance while showing the importance of keeping in balanceall the other factors relevant in router selection, such as featurerichness and cost. It also discusses the impact of IPv6 protocolspecificities on router performance. The chapter providesguidelines on practical and objective evaluation methodologies ofrouter IPv6 performance. From a practical perspective, thisinformation can be summarized in a checklist of major items tobe verified when evaluating a router's IPv6 performance. Table
412 Part I: Implementing IPv6 Services
412 Part I: Implementing IPv6 Services
11-8 shows this list.
Table 11-8. IPv6 Router Performance Evaluation ChecklistTest Scope Test TargetsControl plane Evaluate the CPU impact of targeted IPv6
features. For routers that will operate indual-stack mode, add the result to theoperational CPU values (generated by IPv4)to see whether it will lead to comfortableoverall CPUs (typically below 60 percentunder regular traffic loads).Evaluate the memory needs for the IPv6routing tables. For routers that will operatein dual-stack mode, add to IPv4 memoryuse to see whether it leads to comfortableoverall memory use.
Data plane Measure unicast interface-to-interface andsystem-level throughput performance forbasic IPv6 traffic and no advanced routerfeatures enabled. Pay particular attention tothe throughput results above the IMIXaverage packet sizes.Measure unicast interface-to-interface andsystem-level throughput performance forIPv6 traffic with various extension headersand no advanced router features enabled.Pay particular attention to the throughputresults above the IMIX average packetsizes.Measure unicast interface-to-interface andsystem-level throughput performance forbasic IPv6 traffic with advanced routerfeatures (the features targeted for thedeployment such as ACLs, QoS, and so on)enabled. Pay particular attention to thethroughput results above the IMIX averagepacket sizes.Evaluate the CPU impact of forwarding theexpected IPv6 traffic rates. Both central andlinecard (where applicable based on therouter design) CPU should be measured.Measure IPv6 multicast performance interms of both forwarding rates andreplication.
This chapter is also making the point that today's routers and layer 3 switches are ready to support large-scale,high-performance IPv6 networks. They deliver line-rate forwarding of IPv6 traffic in the range of packet sizesrelevant for most applications. The data presented supports this statement in the case of platforms of variousdesigns that address the entire market spectrum. IPv6 router performance meets the high standards set byIPv4.
Part I: Implementing IPv6 Services 413
Part I: Implementing IPv6 Services 413
Part II: Deployment Case StudiesChapter 12 Generic Deployment Planning GuidelinesChapter 13 Deploying IPv6 in an MPLS ServiceProvider NetworkChapter 14 Deploying IPv6 in an IP Service ProviderNetworkChapter 15 Deploying IPv6 in an Enterprise Network
The first part of this book reviews the IPv6 technologies from a deployment and practical perspective. Itprovides the tools necessary to implement IPv6 in existent or new networks. The second part of the bookoffers concrete examples on using these tools in different types of environments. These examples go over allthe technical details related to designing and deploying scalable and high-performance IPv6-based services. Inreal life however, the deployment is preceded by significant planning work. Regardless of environment type,enterprise, or service provider, a business faces similar challenges in preparing for such a deployment. Thischapter provides planning guidelines and pointers to useful sources of information, and it focuses on thefollowing key topics:
Cost analysis• Address policies and the registration process• Education•
The importance of these planning aspects resides in their relationship to costs. The deployment case studies ofthe subsequent chapters address business drivers and technical guidelines related to rolling out IPv6 servicesin different market segments. This chapter deals with more generic challenges that apply to any IPv6deployment irrespective of context or environment.
CostAnalysis
Regardless ofnetwork's age, thefull integration ofIPv6 servicesmeans that aninventory of theexisting equipmentmust be performedto evaluate the costof the project. Thisprocess would helpplan the associatedbudget and projecttimescale.
414 Part II: Deployment Case Studies
414 Part II: Deployment Case Studies
Although this stepis mandatory tobudget adeployment, it doesnot necessary helpto evaluate thereturn oninvestment (RoI)associated withIPv6. In somecases, a givenapplication orservice clearlyidentifies a need forIPv6 and RoIbecomes obvious.This leads to arather targetedapproach. Whenrecognizing that theneed for migrationis inevitable,another way tointegrate this newIP version is just torequire products tobe IPv6 capable forany newacquisition. In thisway, the migrationmight occur overyears as thenetworkingenvironment getsupgraded to thenewest generationof products andapplications, butthis plannedapproach will helpto control the costof the integration.The cost analysisincludes theupgrade expensesfor elements, suchas hosts andnetwork devices,but also labor forproject planningand execution.
Part II: Deployment Case Studies 415
Part II: Deployment Case Studies 415
Host-RelatedCosts
An importantrequirement forenabling IPv6 on ahost is theminimum release ofits operating systemthat supports IPv6.This requirementextends to thecapability for anyapplication to runover an IPv6network layer withfull support from agiven vendor. Forexample, Microsoftoffered an IPv6technology previewon Windows 2000,but it did notprovide fullsupport. WindowsXP Service Pack 1got a supportedIPv6 stack but witha limited subset ofsupportedapplications such asInternet Explorer6.0, WindowsMedia Player 9.0and 10.0, andConference XP 3.2,but no IPv6 supportfor popularapplications such asExchange, Outlook,or MicrosoftOffice. It isexpected that thenext-generationoperating system,known as MicrosoftWindows Vista,will deliver paritybetween IPv4 andIPv6 at theapplication level.Table 12-1provides anoverview of IPv6
416 Part II: Deployment Case Studies
416 Part II: Deployment Case Studies
stack availabilityon well-knownoperating systemsat the time of thiswriting.
Table 12-1. IPv6Support on VariousOperating Systems
After the minimum releases for the targeted operating systems are identified, the cost of deployment will varywith respect to the hardware capability to support the respective software releases. This cost could go fromzero in the case of hardware already running the appropriate version to significant amounts if the hardwaremust be replaced to run the latest operating system version. Table 12-2 provides a summary of the variouspossible scenarios.
Limited upgrade; for instance, memory size, disk, and so on
Full upgrade
Local intervention
High
No change
Full upgrade
Local intervention
Medium, depending on the licensing scheme
No change
Partial upgrade: for instance, service pack or application(s)
Remote intervention
High to minimal, depending on the licensing scheme
No change
No change, configuration only
Remote intervention
Low
The preceding process of evaluating the platform and operating systems should be followed by an inventoryof applications. If the integration of IPv6 per application is considered to quickly take advantage of theprotocol, it becomes simpler to classify the applications in categories that indicate the level of priority for agiven corporate network (Table 12-3).
Table 12-3. Classification of Applications
Type of Applications
Priority
Comment
Application must be IPv6 capable
High
Part II: Deployment Case Studies 419
Part II: Deployment Case Studies 419
Minimum requirement to get IPv6 successfully running; for instance, DNS server and network management
Application should be IPv6 capable
High
Applications identified as business drivers to enable IPv6 in the enterprise
Application could be added if IPv6 capable
Medium
Applications identified as potential business drivers but not yet ready to run over an IPv6 network layer
Application might be IPv6 capable
Low
Applications that might migrate to IPv6 as the protocol becomes the incumbent
Costs associated with applications depend on their licensing scheme and the required upgrades. This can leadto significant costs when thousands of hosts running tens of applications are involved).
Network ElementsRelated Costs
It is likely that recently purchased routers and layer 3 switches are generally IPv6 capable. On the other hand,IPv6 support impacts all feature sets available on networking equipment, so a network manager needs tospecifically list the services mandatory for his network to ensure their IPv6 equivalent is supported. In thecase of Cisco IOS release trains, IPv6 features integrated over time are documented in Cisco IOS IPv6 StartHere manual (see http://www.cisco.com/ipv6).
Other networking devices such as layer 2 switches, wireless access points, firewalls, VPN concentrators,intrusion prevention system (IPS) might also require a certain level of IPv6 support to be compliant with thedeployment guidelines. For this reason, the cost of upgrading nonrouter devices to support IPv6 should beincluded in the study, too.
Providing a generic network equipment industry status on IPv6 support might not be easy. You should insteadpoll your favorite vendors about the features of interest for your deployment. At the time of this writing, Table12-4 offers an overview of IPv6 support in Cisco equipment.
Table 12-4. Cisco Equipment IPv6 Support
Type of Device
Status
Comment
Routers with IPv6 hardware forwarding capabilities
Need to evaluate features such as filtering, multicast, and QoS to ensure they are supported.
Routers with IPv6 software forwarding capabilities
OK
Need to evaluate features such as filtering, multicast, and QoS to ensure they are supported.
L3 switches with IPv6 hardware forwarding capabilities
OK
Need to evaluate features such as filtering, multicast, and QoS to ensure they are supported.
L2 switches
OK
IPv6 traffic forwarding is transparent on layer 2 switch.
L2 switches
OK
Features such as MLD snooping impact the hardware.
Firewall
OK
Stateful and layer 7 filtering capabilities must be checked.
IPS
Under development
May require new hardware. Signature of attacks need to be computed for IPv6.
Encryption
OK
Generally require new hardware to support IPv6.
WiFi access point
OK
IPv6 traffic forwarding is generally transparent to WiFi AP.
WiFi access point
Under development
Part II: Deployment Case Studies 421
Part II: Deployment Case Studies 421
Management and security over an IPv6 network layer might not yet be available.
Storage
Under development
Might require hardware and software or just software upgrade.
Similarly to hosts, the cost of upgrading networking devices may vary from zero to significant amountsdepending on the current level of readiness. Table 12-5 summarizes the expected cost of upgrading thenetwork elements to support IPv6.
Table 12-5. Cost Estimate of Upgrading the Network Elements
Hardware
Software
Minimal Operation
Cost
Full replacement
Full upgrade
Local intervention
Very high
Limited upgrade; for instance, memory size, line card, supervisor engine
Full upgrade
Local intervention
High to Medium
No change
Full upgrade
Local or remote intervention
Medium to minimal, depending on the need to purchase an upgraded license
No change
No change, configuration only
Local or remote intervention
422 Part II: Deployment Case Studies
422 Part II: Deployment Case Studies
Minimal
Early planning for IPv6 deployment is critical to save some of these costs. Equipment-acquisition policies thatmandate IPv6 support or a clear roadmap can lead to improved readiness with every scheduled networkupgrade.
Operations-Related Costs
The integration of IPv6 in a production network represents a challenge for the operations team in charge ofmaintaining the integrity of IPv4 services. While working on the new protocol, they need to ensure seamlesscoexistence and similar service quality to the end users for both protocols. The project of integrating andrunning IPv6 has an evident impact on the budget of the department. Spending associated with training,design, product evaluation, service provider costs, deployment tasks such as product upgrade andconfiguration, and day-to-day operation, has to be planned and approved by management before the rolloutcan begin.
Configuration of hundreds or thousands of hosts and networking elements (independent of the need forhardware, operating system, or applications upgrade) is time-consuming and has a cost of labor that needs tobe budgeted from day one. This must include the tasks associated with the update of the network managementsystem and tasks related to the day-to-day support of the end users, the definition of updated operationalprocesses, and their documentation.
Nevertheless, by planning for version-independent IP support through new acquisitions or development ofapplications, the cost of the upgrade could be integrated in the next rollout of equipment, which decreases thecost of deployment. Operating costs could also influence the selection of a given deployment strategy.Whether it mandates a deployment staging, tunnels before native or dual stack in the enterprise, or even leadsto certain architecture choices (6PE versus native IPv6), operational cost could remain at its current level.
Address Policies and RegistrationProcess
To fully understand the IPv6 addressing model, you mustbecome familiar with the various IETF-related documents asintroduced in Chapter 2, "An IPv6 Refresher," and throughoutthe first part of this book. The centerpiece is the IPv6 addressarchitecture as defined in RFC 3513. An understanding of theaddress architecture needs to be complemented by anunderstanding of the current policies for IPv6 address-spaceallocation.
The IETF defines an IPv6 global unicast address format inRFC 3587. This RFC documents an IPv6 addressing structurethat is compliant with the allocation of IPv6 addresses relatedto policy and to the stewardship of the IP similar to IPv4. Theresulting format is an IPv6 global unicast address under the2000::/3 prefix that is currently being delegated by theInternet Assigned Numbers Authority (IANA). The IPv6
Part II: Deployment Case Studies 423
Part II: Deployment Case Studies 423
address-management function was formally delegated toIANA in December 1995 as documented in RFC 1881. Table12-6 presents the IPv6 address-space distribution asdocumented athttp://www.iana.org/assignments/ipv6-address-space.
The following notes add specific details on addressing architecture:
The "unspecified address," the "loopback address," and the IPv6_addresses with embedded IPv4addresses are assigned out of the 0000::/8 address block.
•
0200::/7 was previously defined as an OSI NSAP-mapped prefix set in RFC 1888. This definition hasbeen deprecated as of December 2004 by RFC-carpenter-obsolete-1888-01.txt.
•
The IPv6 unicast space encompasses the entire IPv6 address range_with the exception of FF00::/8.• FEC0::/10 was previously defined as a site-local scoped address_prefix. This definition has beendeprecated as of September 2004 by RFC 3879.
•
0000::/96 was previously defined as the "IPv4-compatible IPv6_address" prefix. This definition hasbeen deprecated by RFC-ietf-ipv6-addr-arch-v4-04.txt.
•
IANA allocates IPv6 prefixes to the five Regional Registries (RIRs) based on their needs:
The list of IANA prefixes assigned to the RIRs can be found athttp://www.iana.org/assignments/ipv6-unicast-address-assignments
Note
Some prefixes might have a specific purpose, such as the following:
3FFE::/16 is an experimental allocation to the 6Bone as described in RFC 2471. This prefix will bereturned to the unassigned address pool when the 6Bone is phased out on June 6, 2006 (see RFC3701).
•
2001:0DB8::/32 has been assigned as a NONROUTABLE range to be used for documentationpurpose as described in RFC 3849.
•
2002::/16 is reserved for use in 6to4 deployments based on RFC 3056.•
IANA also handles the allocations of the IPv6 anycast and global IPv6 multicast address space. The respectiveallocation policies are described at the following websites:
The RIRs allocate, via the Local Internet Registries (LIRs), a ::/32 prefix (formerly ::/35) to Internet serviceproviders (ISPs), government agencies, and National Research & Education Networks (NRENs). Recently,larger address space was allocated to ISPs and government agencies, such as the following:
KORNET 2400::/20• Deutsche Telekom AG 2003::/19•
You can find a current list of allocations at http://www.ripe.net/rs/ipv6/stats/.
The prefix-allocation policies are well described by the RIR documents:
APNIC at http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html• ARIN at http://www.arin.net/registration/ipv6/• RIPE at http://www.ripe.net/ripe/docs/ipv6-policy.html•
At the time of this writing, contrary to IPv4, an end user such as an enterprise cannot generally get a prefixfrom a registry, although there are historical exceptions. This rule, which intended to enforce routeaggregation through assignment policies, is a significant departure from the IPv4 address allocationmechanisms. Its impact on network operations has to be clearly understood well before the need forintegrating IPv6 becomes imminent.
There have been and there continue to be many discussions between experts on the topic of IPv6address-allocation policies. RFC 3177 documents the current recommendations to the RIRs on policies forassigning IPv6 address blocks to end sites. In particular, it recommends the assignment of the following:
/48 in the general case, except for large subscribers• /64 when it is known that one and only one subnet is needed by design• /128 when it is absolutely known that one and only one device is connecting•
The last two rules are practical, because they are based on specific boundaries. Nevertheless, departures fromthese recommendations are possible (discussion about shorter prefix than /48 are still ongoing) because at thislevel in a network, address assignment depends on the business and design models of each service provider orenterprise.
To conclude, there is a need to add to the equipment- and operations-related costs the cost of subscribing anIPv6 prefix. For ISPs, this cost is documented by the RIRs and LIRs. For enterprises and end users, feesassociated with IPv6 services from an ISPs can vary from zero dollars (often the case when this is offered as atrial or beta service or the ISP wants to build service references) up to fees similar to IPv4 services. Toevaluate the pricing associated with IPv6, contact your local ISP to learn about its capability to deliver theservices. (For example, it is also possible to check out the Japanese ISP market fromhttp://www.ipv6style.jp/en/statistics/services/index.shtml.)
Some enterprises or end users would expect IPv6 services to be added for free to their current IPv4subscription; however, this is not always possible because this represents an operational cost for the ISP, too.
Education
Education is one of the key elements for the successful deployment and maintenance of new technologies andassociated products. First, IPv6 deployment started in the mid-1990s with the experimental 6Bone network,meaning years of experiences are now available from and for the networking community. People working onIPv6 should leverage the work done within the 6Bone project; however, because technology, policies, andimplementations evolved over the nearly 10 years of 6Bone's existence, it is important to maintain a timeperspective when evaluating its deliverables. In the meantime, multiple other projects have been started thathave generated a tremendous amount of information about the technology, its deployment, and operation. Tohelp you navigate through this sea of resources, here is a basic and nonexhaustive classification of goodmaterial:
The 6Bone is an IPv6 test bed and a worldwide informal collaborative project started in the middle ofthe 1990s. The 6Bone started as a virtual network (using IPv6 over IPv4 tunneling/encapsulation)operating over the IPv4-based Internet to support IPv6 transport, then migrated to native links for IPv6transport. It will be phased-out in June 2006. The initial 6Bone focus was on testing standards andimplementations; the current focus is more on testing the transition and operational procedures. The6Bone operates under the IPv6 Testing Address Allocation (see RFC 2471).IPv6 Forum (http://www.ipv6forum.com)
A worldwide consortium of leading Internet vendors, National Research Networks (NRNs), and ISPsare shaping the IPv6 Forum, with a clear mission to promote IPv6 by dramatically improving themarket and user awareness of IPv6. Global and regional IPv6 Forum summits are regularly hosted inmember countries, meetings that usually provide educational opportunities.
•
IPv6 Task Force (http://www.ipv6tf.org)
Regional and national IPv6 task forces have been created all over the world. They offer an opportunityfor local industry, education, and government agencies to shape the adoption of IPv6 in their ownregion. The main IPv6 Task Force website provides a list of links to the local task forces:
- North America (http://www.nav6tf.org)- Europe (http://www.ipv6tf.org/meet/tf/eutf.php)- Japan (http://www.v6pc.jp/en/temp0107.html)
•
Other significant IPv6 projects
To develop the IPv6 awareness and disseminate experience within the networking community, severallarge regional projects are being run or have been run over the years. Their work groups havedelivered tens of documents that are an important source of training. For example:
- 6DISS (http://www.6diss.org)
6DISS is a Specific Support Action in the Sixth Framework Programme of the EuropeanUnion. The project aims to promote widespread adoption of IPv6 by providing IPv6 trainingand knowledge transfer in developing regions.- 6NET (http://www.6net.org)
6NET was a three-year European project to demonstrate that continued growth of the Internetcan be met using new IPv6 technology. The project built a native IPv6-based networkconnecting 16 countries to gain experience of IPv6 deployment and migration from existingIPv4-based networks. It concludes by moving IPv6 to full production services for theacademic community in Europe.- Euro6IX (http://www.euro6ix.org)
The goal of the Euro6IX project was to support the rapid introduction of IPv6 among ISPs inEurope. It enabled several SP R&D departments to collaborate.- Moonv6 (http://moonv6.sr.unh.edu)
The Moonv6 project is a global effort led by the North American IPv6 Task Force (NAv6TF)involving universities, Internet2, vendors, service providers, and regional IPv6 Forum Task Forcenetwork pilots worldwide. Taking place across the United States at multiple locations, the Moonv6project is a large, permanently deployed multivendor IPv6 network.
- Network exchange points for IPv6 (http://www.napv6.net)
A site with a list of several IPv6 exchanges known worldwide.
The growing interest in IPv6 led to emerging commercial offerings for IPv6 training and consulting services.For example, Cisco has developed a suite of IPv6 Accelerate series:
ILS is available through Cisco Learning Partners. Partners with a certain status can directly access most of thee-Learning on the Partner e-Learning Connection (PEC). The material is generally available to customers at afee via the Cisco Learning Connection (CLC).
In addition, Cisco Networking Academy and Networker programs now include a series of IPv6 modules.
As often in the IT industry, consulting firms are also ready to be engaged on IPv6 deployment projectsforexample, Cisco Advanced Networking Services has developed a set of IPv6 services for customers.
Remember that training can represent an important investment in the overall project. An enterprise or ISPeducating a large staff will need a budget. That budget can range from low, in the case of reading ande-Learning, to high, for ILS. For example, at $1000 per person per class, the training expenses can quickly addup. A large enterprise or ISP can reduce this cost by applying a "train a trainer" strategy, where a couple ofsenior people train the internal team after attending relevant classes.
With the guidelines described in this section, network and service planners can take the steps necessary toestimate the cost of deploying and operating IPv6 services in their network. Most important, however, thesesteps enable them to plan their equipment and software license purchasing policies. Through the regular,scheduled infrastructure upgrades, they can increase at a lower cost the network readiness for the IP upgrade.
Chapter 13. Deploying IPv6 in an MPLS Service ProviderNetwork
The first part of this book provided the tools and the knowledge necessary to design and operate IPv6networks and services. Because you now have an understanding of the technology, we shift our focus to thesystem perspective of a deployment. IPv6 features are put together in the context of an existent IPv4 networkto provide scalable, high-performance, and valuable services. These exercises intend to provide practicaldesign examples for some of today's network types and to put the accumulated IPv6 knowledge into theend-to-end service context of three case studies.
This chapter presents the design of IPv6 services and their deployment in a service provider that is usingMultiprotocol Label Switching (MPLS) in its core. It is a rather common network type in today's majorservice provider market. The IPv6 deployment is based on the 6PE/6VPE features that leverage the existentMPLS infrastructure. (See Chapter 3, "Delivering IPv6 Unicast Services," and Chapter 7, "VPN IPv6Architecture and Services," for details on these features.) This case study covers all aspects of rolling out andoperating IPv6-based services, including the following:
Existent IPv4 network and services overview• Review of IPv6 service offering plans and their relationship to the IPv4 ones• Design objectives and reasons for making certain design choices• Design and implementation of basic IPv6 servicesunicast transport and VPN• Design and implementation of other featuresQoS, security, network management• Troubleshooting techniques•
The goal of the chapter is to provide a working solution to deploying IPv6 in such an environment; however,more important, it goes through the process of designing, implementing, and running such a deployment.
Network Environment
EuropCom is a fictitious pan-European data and long-distance voice MPLS service provider, with POPs inFrance, the United Kingdom, Spain, Portugal, Italy, Germany, Belgium, Greece, Poland, the Czech Republic,Austria, and Romania. EuropCom has been providing a set of IPv4 services over the past five years todifferent market segments, residential customers, and businesses. Two of these IPv4 services represent theprincipal revenue generators: layer 3 MPLS VPN and Internet access. Both services are MPLS switchedthrough the EuropCom integrated MPLS core backbone.
EuropCom network uses a classical architecture with three levels of POPs, as illustrated in Figure 13-1.
Figure 13-1. EuropCom POP Architecture
Part II: Deployment Case Studies 429
Part II: Deployment Case Studies 429
Level 1 (L1) POPs form the backbone of the network. They are interconnected over OC-192 and OC-48 links.L1 POPs are also Internet exchanges, connected to major European ISPs. The L1 POPs connect to level 2 (L2)POPs over OC-48 links. L2 POPs aggregate level 3 (L3) POPs over OC-48 and OC-3 links, depending of thesize of the L3 POP. Figure 13-2 presents EuropCom network in a geographical context.
Figure 13-2. EuropCom Geographical Topology
[View full size image]
In the EuropCom network, Provider Edge (PE) routers are dedicated to either the Internet or layer 3 MPLSVPN access.
The EuropCom backbone has the following characteristics:
Highly secure over a dedicated private network.• Uses high-bandwidth OC-48 and OC-192 backbone links for L1-L1 POPs connectivity, OC-48 forL2-L1 POPs connectivity, and OC-48 to OC-3 for L3-L2 POPs connectivity.
•
MPLS-based forwarding for both VPN traffic and Internet traffic.• Is overengineered so that QoS is not needed in the core. EuropCom deploys DiffServ in the edge layeronly.
•
Full L1 POP backbone redundancy.• Uses a single autonomous system.• Peers with major Tier 1 carriers.•
EuropCom customer base covers the full range of typical ISP customers:
Small businesses EuropCom provides network access and added-value services such as Internetaccess and Voice over IP (VoIP).
•
Enterprises EuropCom offers transport, VPN, and Internet access services.• Residential EuropCom provides a variety of services such as Internet and VoIP.•
In the IPv6 deployment project, the EuropCom objective is to enable transport over itsbackbone and deliver a range of IPv6 services to its customer base. EuropCom operatesunder the assumption that in the first 1 to 3 years, the IPv6 traffic in the core of the networkwill not exceed 20 percent of its total data traffic. However, for the long run, one of thenetwork design goals is to avoid treating IPv6 differently than IPv4 traffic, but rather make itpart of the overall QoS strategy currently in place for the IPv4 services.
At the same time, EuropCom intends to minimize the impact of introducing IPv6 services,both in terms of network element upgrade (software/hardware/configuration) and operations.To achieve this goal, EuropCom will keep IPv4 and IPv6 topologies congruent in the core,and deploy dual-stack (IPv4 and IPv6) on the network edge, wherever IPv6 is required. Inthe MPLS core, EuropCom plans to transport IPv6 traffic over IPv4-signaled labeled paths.
The EuropCom business model is to deploy VPNv6 services on PEs that currently supportVPNv4, and IPv6 Internet access on PEs that currently provide IPv4 Internet access. PEs inL1 POPs will be enabled for IPv6 before the service launch. PEs at L2 and L3 POPs will beIPv6 enabled on demand (at first attached IPv6 customer).
The same Label Switch Paths (LSPs) used for IPv4 will be used by IPv6 for both VPN andInternet access services: This can be achieved by using 6PE and 6VPE features, and carefullyconfiguring BGP endpoints to match the existing IPv4 ones. This approach allowsEuropCom to avoid making changes in its core configuration in terms of the deployed IGP,the Label Distribution Protocol, the addressing, and so on.
EuropCom Services
EuropCom has been delivering a growing set of services over its IPv4 infrastructure toservice providers, enterprises of all sizes, and residential users. It now starts to receive moreand more requests for IPv6-based services and IPv6 transport from its institutionalcustomers:
Service providers are interested in having access to the IPv6 Internet.• Enterprises would like to interconnect IPv6 clusters in geographically discontiguouslocations. They are also interested in interfacing over IPv6 with some of their owncustomers and having access to the IPv6 Internet. Various members of NationalResearch Networks participating in IPv6-related research projects have alsorequested IPv6 traffic transport services to interconnect their campuses. For thesecustomers, EuropCom provides just IPv6 traffic transport between sites.
•
Home users are generally not interested in the means by which services are delivered tothem, yet there always are a few that are technology curious/savvy who would like to try newthings. They have heard about web pages, radio stations, or game servers accessible overIPv6. EuropCom received multiple enquiries on the availability of IPv6 Internet accessservices. At the same time, EuropCom sees an IPv6 offering as a service differentiator and anopportunity to establish itself as a leader in this respect.
Part II: Deployment Case Studies 431
Part II: Deployment Case Studies 431
For the most part, the IPv6 service requests received by EuropCom are similar to the existentIPv4 services: Internet access, layer 3 VPN, and DNS. The main challenges posed by theseservices are technical in nature; it is a matter of deploying them in a scalable manner withminimal impact on the IPv4 infrastructure. The IPv6 infrastructure is to be built, however,with a long-term perspective in mind and not simply to address small market demands on anad-hoc basis with minimum investments. EuropCom understands the benefits and theopportunities offered by IPv6, thus making it part of its development strategy. EuropComalso plans to capitalize on the IPv6 awareness raised by the European Union and deploy newIPv6 services to differentiate itself from the competition. Therefore, it intends to make themost of an IPv6 infrastructure by developing and experimenting with new services. Thesenew services would add to the technical challenges of deployment and the challenges ofdeveloping viable business models for them.
The IPv6-based services will be kept independent of the IPv4 ones except for the networkinfrastructure resources that are being shared. Table 13-1 summarizes EuropCom plannedoffering. The first three service names are considered basic services, although the remainingnames are considered value-added services.
Table 13-1. EuropCom IP Services
Service NameIPv4Service
IPv6Service
Internet access Yes YesLayer 3 VPN Yes YesDNS Yes YesContent delivery No YesContent hosting No YesVoIP Yes Yes
This section reviews EuropCom's current and planned services along with some of their requirements. TheIPv6 infrastructure is designed to meet these requirements.
Internet Access
The original business model of EuropCom was to provide Internet access (IA) to service providers,Enterprises of all sizes and residences. It reaches its institutional customers through network access and transitproviders or direct peering:
Wholesale access providers and service providers interface with EuropCom through Gigabit or 10Gigabit Ethernet, OC-3 or OC-48 interfaces.
•
Business customers can choose between various high-bandwidth access options such as: E1 leasedlines, ATM, or Frame Relay circuits, and Fast/Gigabit Ethernet access in the metropolitan areas.
•
The details of EuropCom access layer layout are presented in the "Network Design" section of this chapter.EuropCom does not own the last mile to its residential customers, so it relies on access providers to reachthem:
The access providers can simply provision dedicated physical (E1, wavelength) or virtual circuits(VLANs, Frame Relay, or ATM VCs) between EuropCom and its customers. This is generally thecase with businesses.
•
Service providers are providing wholesale network access to residential users by encapsulating theuser traffic in PPP sessions, which in turn are bundled into a Layer 2 Transport Protocol (L2TP)tunnel. In this case, EuropCom POP routers perform an LNS function, terminating the PPP sessions
•
432 Part II: Deployment Case Studies
432 Part II: Deployment Case Studies
and the L2TP tunnels.
In both these scenarios EuropCom Customer Edge (CE) routers represent the layer 3 gateway for theresidential customers. This implies the fact that EuropCom is responsible for address assignment andmanagement.
Note
The L2TP and PPP IPv6 access options were discussed in Chapter 3. For this case study, however, the focusis on the edge features enabled on the PE routers, which are presented with plain, unencapsulated IPv6 traffic.
Other service and content providers can also choose to use EuropCom IA services by peering with EuropComat various POPs through OC-3, OC-48, Gigabit or 10 Gigabit Ethernet interface.
Alongside its existent IPv4 Internet access service, EuropCom intends to offer its customers IPv6 Internetaccess at an additional charge of 10 euros (~12 dollars) to the regular monthly subscription.
L3VPN
The VPNv6 service will be offered to existent IPv4 VPN customers. In addition, IPv6 Internet access will beoffered to VPN customers.
Carrier Supporting Carrier
The Carrier Supporting Carrier (CsC) mechanism is commonly used by service providers to provide transportservices for customer service providers (or carriers). Two types of customers will take advantage of thisservice:
The customer carrier can be an Internet service provider with an IPv6 (or dual-stack) core. It has twosites, each of which is a POP. It connects these sites using a VPNv6 service provided by EuropCom.EuropCom uses MPLS to transport the ISP IPv6 traffic, whereas the ISP sites use IPv6.
•
The customer carrier can be an MPLS service provider with or without VPN services. The customercarrier has two sites. Both the backbone carrier (EuropCom) and the customer carrier use MPLS intheir networks.
•
DNS Services
EuropCom provides DNS services for its IPv4 customers. This service becomes even more important tosupport the IPv6 customers; it is more difficult to remember IPv6 addresses than the IPv4 ones. Alongside allits uses with the IPv6 applications, similar to the IPv4 applications, DNS plays a particularly important role indeploying the peer-to-peer applications made available with IPv6. The DNS service is used by all theremaining services discussed in this section.
The DNS servers are upgraded in EuropCom data center, and AAAA records are added to the A records asneeded.
Part II: Deployment Case Studies 433
Part II: Deployment Case Studies 433
Content Hosting/Storage
Because EuroCom is aware of the fact that the content currently available on the IPv6 Internet lacks richness,EuropCom bundles in the IPv6 IA service subscription a new content hosting and storage service over IPv6.This service can be used by the customers in several different ways:
Store data files on the 2 gigabits of storage offered with the basic subscription. Customers can rentlarger space if they need it. The data can be accessed remotely over the IPv6 Internet.
•
Customer web resources are hosted by EuropCom part of the service subscription.• EuropCom hosts several servers maintained by game manufacturers that offer promotional, online,PC-based games. In exchange for unlimited use of this service, the customers are required to providefeedback on their gaming experience. Console game manufacturers are also considering trialing theirIPv6 ready products over the infrastructure provided by EuropCom.
•
To support these new services, EuropCom set up a set of storage resources in its data center along with thenecessary infrastructure (Figure 13-3).
Figure 13-3. Content Hosting/Storage Service
[View full size image]
EuropCom plans to continue experimenting with several other service offerings that leverage its storageresources. It intends to partner with multimedia companies to deliver content such as movies and video for anadditional subscription fee.
434 Part II: Deployment Case Studies
434 Part II: Deployment Case Studies
Voice over IP
Residential VoIP has seen lately a significant increase in its rate of adoption. It is now offered commonly as asecond-line service to users with broadband access. With the availability of reliable IPv6 unicast transport,EuropCom saw it technically feasible to consider deploying VoIPv6 as an added-value service. In fact,VoIPv6 is often touted by some as the killer application that would push for the mass adoption of IPv6.
In its trial phase, the VoIPv6 service allows for on-net to on-net calls between IPv6 customers of EuropComonly. The enticing aspect of the service is that customers have the option of purchasing from aEuropCom-authorized vendor video phones. This feature also allows EuropCom to advertise the service to itsbusiness customers who could use it for intercampus communication. Such features differentiate the VoIPv6service from the VoIPv4 service that is aggressively being deployed by EuropCom.
EuropCom decided to offer a Session Initiation Protocol (SIP; RFC 2543)-based voice service. The servicedesign is similar to the VoIPv4 one.
To support this service, EuropCom set up a SIP Registrar and a SIP proxy server in its data center. Figure13-4 shows the setup of a VoIPv6 call in this environment.
Figure 13-4. VoIPv6 Service
[View full size image]
The more technical-savvy customers can, of course, set up direct calls between themselves, in which case theyleverage only the DNS resources offered by EuropCom. For business customers, EuropCom is also piloting a"Managed Video VoIPv6 Service" that meets certain service-level agreements at an additional charge.
Part II: Deployment Case Studies 435
Part II: Deployment Case Studies 435
From a transport perspective, voice traffic has different network performance requirements than data traffic,as shown in Table 13-2.
Table 13-2. Voice and Data Traffic Characteristics
Characteristics
Voice Traffic
Data Traffic
Loss
Not sensitive to random small losses
Sensitive
Delay
Smaller then 200ms
Not sensitive (other then application timeouts)
Jitter
Smaller then 10ms
Not sensitive
EuropCom decided to deploy IPv6 quality of service (QoS) at the network edge from the beginning to readyits network for time- and delay-sensitive applications. This enables it to control the quality of the VoIPv6service provided to businesses. On the other hand, EuropCom has no control over the infrastructure used bywholesale access providers, which limits its control on the service quality it offers to residential customers.For the most part, this is not considered an issue in the beginning, but the quality of service will be monitoredas the number of subscribers increases.
The adoption of the service will shape EuropCom future plans for expansion. These plans also include thedeployment of gateways to the PSTN network that will allow for on-net to off-net calls, thus significantlyincreasing the value of the service.
Peer-to-Peer Applications and Other Services
One of the challenges EuropCom faces in the initial IPv6 deployment phase is to quickly increase its IPv6customer base to pay for its investments in the deployment. Part of EuropCom strategy to achieve this is tooffer end-to-end solutions that go a bit beyond its IPv4 model. Setting up services such as content delivery orVoIP is an example of this strategy.
With the same goal in mind (promoting IPv6 utilization through its core network), EuropCom plans to provideto its customer base guidance and support for applications and services that are transparent to the corenetwork but will drive up IPv6 adoption. Two sets of services/applications are perceived by EuropCom aspromising IPv6 enablers: peer-to-peer applications, and IPv6 mobility.
436 Part II: Deployment Case Studies
436 Part II: Deployment Case Studies
Peer-to-peer applications are a complex service concept as far as EuropCom is concerned. They are notservices that it can offer and charge, and because it does not own the software, it cannot distribute it. At thesame time, these applications are expected to drive IPv6 adoption and generate more IPv6 traffic through theEuropCom backbone. EuropCom will promote these applications by testing, referencing, and rating them onits IPv6 website. The current list of EuropCom "Top 4" shows that the most recommended peer-to-peerapplications are the following:
Apache A web server software that has full support for IPv6. Given that EuropCom residential IPv6end users get a fixed range of addresses (unlike IPv4, where the address is renewed every 24 hours),they can easily set up their IPv6 web server, and register its name to EuropCom DNS. Generalinformation about Apache can be found at http://httpd.apache.org.
•
ConferenceXP A shared-source tool from Microsoft Research that provides a conferencing andcollaboration platform. ConferenceXP 3.2 supports the IPv6 protocol. General information can befound at http://www.conferencexp.com/.
•
BitTorrent/Bittornado A peer-to-peer (P2P) file-distribution tool that is IPv6 enabled. Generalinformation about BitTorrent can be found at http://www.bittorrent.com/, and information aboutBittornado is at http://www.bittornado.com/.
•
Jabber An IPv6-enabled Instant Messaging and XML routing system. General information aboutJabber can be found at http://www.jabber.org/protocol/.
•
EuropCom set up a message board that users and its staff can contribute to with tips on installing and usingthese applications.
Network Design
EuropCom is an MPLS-based service provider. It took significant effort to stabilize theirIPv4 infrastructure; therefore, they do not want to put it in jeopardy when starting the IPv6service. Furthermore, operating costs for managing the core are already significant, andEuropCom does not plan to deploy any "service-specific" mechanism in the core thatwould drive these costs higher. Note that EuropCom considers the introduction of IPv6 asa new service, rather than a replacement for IPv4.
The design team studied and tested several approaches, including the following:
Pseudowire emulation (RFC 3916) Although this approach would make the IPv6deployment completely transparent to EuropCom infrastructure, this is a layer 2technology, which was not selected for deploying any of the existing servicescurrently supported by EuropCom, mainly because of scalability concerns.
•
IPv6 over IPv4 tunnels over MPLS This approach was considered seriouslybecause IPv4 over MPLS LSPs were already in place; enabling IPv6 tunnels overthe existing LSP infrastructure sounded like a simple and attractive solution.Testing demonstrated some weakness in terms of configuration (the tunnel typeshave to be manually setup), traffic overhead (on small packets, the extra IPv4header was significant), and troubleshooting (tunnel in tunnel proved be verytricky to manage). Performance-wise, this solution was also disappointing on someof the smaller routers, because of the chain of lookups at the egress PE(label+IPv4+IPv6) before forwarding the packets.
•
6PE/6VPE The mechanisms tested by EuropCom encompass transport over anIPv4 MPLS core of both Internet traffic (6PE) and VPN traffic (6VPE). Theconclusion was that these mechanisms are the perfect fit for EuropCom. They have
the advantages of the tunnel approach, without the overhead and performance hit.In addition, troubleshooting IPv6 over MPLS is not different from troubleshootingVPNv4, which EuropCom is familiar with. In fact, the overall similarity between6PE/6VPE and VPNv4 allows EuropCom to leverage their experience withVPNv4 in deploying and operating the IPv6 services.
The following list of goals was put in place by EuropCom to build a compelling businesscase for choosing the 6PE approach:
Minimal operational cost and risk. The core routers and related operations areunchanged. This applies to core hardware, software, configuration, list of enabledprotocols, network management, QoS, routing and forwarding table size.
•
No impact on existing IPv4 and MPLS services.• Only PE and CE routers are upgraded.• EuropCom can deploy 6PE on existing PE routers or introduce dedicated PEs forIPv6 traffic. This provides a flexible solution depending on EuropCom customerrequirements in terms of traffic and isolation.
•
No impact on IPv6 CE routers, other than peering with EuropCom PEs or CEs.•
6PE will provide IPv6 connectivity over EuropCom core and enable global IPv6 IA. 6VPEwill provide the equivalent service for VPN customers. In addition to these basic services,others such as DNS, IPv6 traffic monitoring, IPv6 content hosting, and VoIPv6 will also bedeployed.
With IPv4, PE routers are already dedicated to either VPN customers or Internet accesscustomers: EuropCom plans to keep the same role separation with IPv6. IPv4 IA customersare the primary target for IPv6 IA, and VPNv4 customers for VPNv6 service. To optimizeits business model, EuropCom plans to reuse IPv4 IA PEs and CEs for IPv6, and VPNv4PEs for VPNv6. However, it does not exclude the cases where it might be practical todeploy dedicated IA IPv6 PEs, especially VPNv6 PEs, based on customer demand.
Access Design
In terms of access to its network resources and services, EuropCom customers can beseparated in two categories:
Directly connected This is the case of other service providers for which EuropComprovides transport or Internet access. Their equipment can be collocated withEuropCom at its various POPs.
•
Indirectly connected This is the case of enterprises and residential users connectingto EuropCom over an access provider.
•
Neither of these groups of customers requires an extensive access layer. Figure 13-5depicts the elements of the access layer. They are independent of the overall design of thePOP, and they can be found in various combinations in all EuropCom POPs.
Figure 13-5. EuropCom Access Layer
[View full size image]
438 Part II: Deployment Case Studies
438 Part II: Deployment Case Studies
The interfaces used at the access layer are summarized in Table 13-3.
Table 13-3. Interface Types Used at the Access LayerInterface Type Speed UseE1 2.048
customersand forserviceproviderscollocatedat the samePOPs
10 Gigabit Ethernet 10Gbps
Access forcontentproviders
Both PE and CE routers make up EuropCom access layer within a POP. They all perform access functionsdepending on their role in a service offering, functions listed here:
CE routers located in the POP interface with residential or small business customers. They have toterminate layer 2 circuits, PPP sessions, or L2TP tunnels depending on the business model of theaccess provider connecting EuropCom to its IA customers. In this role, the CEs can also handlecustomer provisioning for both IPv4 and IPv6 services. In the case of IPv6, this function can beperformed by various means, as mentioned in Chapter 3: stateless autoconfiguration, stateless DHCP,provisioning through IPCP with the help of a RADIUS server, DHCP-PD. The CEs have access toDNS and RADIUS servers.
•
PE routers aggregate multiple CE routers collocated in the POP. They also provide direct access tocertain enterprise customers and to service providers. PE routers have limited involvement, if any, inthe customer-provisioning functions.
•
Additional layer 2 devices such as Ethernet switches or ATM switches are also part of the access layer. Thissection focuses on the access features enabled on these devices.
Intermediate System-to-Intermediate System (IS-IS) is the interior gateway protocol (IGP) used within theaccess layer, between the PE and the CEs managed by EuropCom. In the case of IPv6, considering the lack ofdepth in the access layer, no hierarchy is necessary in the IGP design. Static routing is used in interfacing withresidential and small business customers. eBGP is used between EuropCom and its service provider or largeenterprise customers.
Note
Low-end remote CEs managed by EuropCom might run routing protocols that require less processing power,such as RIP (RIPng) or EIGRP (EIGRPv6).
The EuropCom business model is highly focused on the edge features, and this is reflected in the limiteddepth and complexity of its access layer. Chapter 14, "Deploying IPv6 in an IP Service Provider Network,"presents the case of an access service provider with an extensive rich access layer, which has more features.Its detailed description in terms of design and operation offers the reader examples of other features typical inthe access layer of a service provider's network.
POP Design
In EuropCom network, Internet exchange points (IX) are also L1 POPs delivering IPv4 and IPv6 services toEnterprises and other service providers. A typical IX, shown in Figure 13-6, includes the following:
440 Part II: Deployment Case Studies
440 Part II: Deployment Case Studies
Connections to other IX• PEs delivering services to IPv4 and IPv6 enterprise and service provider nodes• Connections to other POPs• Resources supporting hosted services• Management applications (fault management, performance management, accounting management)•
Figure 13-6. Level 1/IX POP Design
[View full size image]
Figure 13-6 illustrates the layer 2/layer 3 structure of an IX/POP.
EuropCom L1 POPs peer with other EuropCom POPs/IX as well as with other ISPs. At the same time, theyalso connect some local customers, whether IA customers or VPN customers. One of the characteristics ofEuropCom peering with other ISPs with regard to IPv6 is that it is intended to be exclusively over MPLS.This simplifies greatly the interface design between EuropCom and other ISPs sharing the same IX, asdetailed in the "Inter-AS Design" section.
EuropCom interacts with other service providers in the following ways:
EuropCom customers connected to its POP over an infrastructure (layer 1 or layer 2) provided byanother regional service provider
•
EuropCom customers connected to another regional service provider's POP with an inter-serviceprovider agreement (performed in IX)
•
EuropCom customers connected to a EuropCom POP which itself is connected to the EuropCom coreover another service provider
•
Other service provider using EuropCom core as a transit MPLS network•
In terms of implications on IPv6 configurations and operation, the second bullet requires some inter-ASsupport in the context of IPv6, and the fourth bullet requires some CsC IPv6 support. These cases are detailedin the sections "Inter-AS Design" and "Carrier Supporting Carrier Service Design."
Part II: Deployment Case Studies 441
Part II: Deployment Case Studies 441
Note that in L3 POPs, some routers can play both the role of core Provider routers (P-routers) and ProviderEdge (PE) routers.
Core Design
The 6PE/6VPE approach has the advantage of minimizing the impact on the network core when enabling IPv6traffic over it. In particular, P-routers do not need any software or hardware upgrade, or any configurationchange, as long as a few caveats are understood and accepted, which revolve around ICMP (reviewed in the"ICMP Design Considerations" section).
IGP Design Considerations
EuropCom was already running IS-IS as the core IGP prior to deploying IPv6. IS-IS enables IPv4connectivity within the network core and between PE routers. Because IPv6 routes for both Internet accessand VPN will be announced "via" IPv4 PE loopback addresses already distributed by IS-IS, no changes arerequired on IS-IS running in the core, and minimum impact is expected on the routing tables in core routers.
For IA, EuropCom uses the next-hop-self configuration nit on the PE-PE iBGP peering, and advertises PE'sown loopback addresses into IS-IS. So, on both IA PE routers and VPN PE routers, the LSP tail end belongsto the PEs. And the same LSPs are used for IPv4 and IPv6 traffic.
When IPv6 is deployed, the only additional entries in core routers routing tables are IPv4 addressesconfigured on new PE routers. These are essentially Route Reflectors (RRs) because EuropCom design choiceis to deploy dedicated RRs for 6PE/6VPE peering, while enabling IPv6 on existing PEs. With RRs, IPv4addresses distributed via IS-IS in the core, PEs, and RRs can establish BGP peering over IPv4 and exchangeIPv6 routes. Example 13-1 shows the IS-IS configuration (unchanged) in core router Bruxel-P.
For label distribution, EuropCom runs LDP over IPv4 to establish LSPs between the PE's IPv4 loopbackaddresses, on PEs providing Internet access as well as on PEs providing VPN access. P-routers have all theirinterfaces running LDP and allocating labels for these PE loopback addresses. PE routers have theirP-router-facing interfaces also running LDP. Because 6PE and 6VPE are planned to reuse the very sameLSPs, LDP is completely transparent to the IPv6 deployment. Note that because both 6PE and 6VPE use thetwo-label mechanism described in Chapter 3 (in the section "IPv6 over 6PE") and Chapter 7, respectively,Penultimate Hop Popping (PHP) can happen at the last P-router without the need to use explicit-null label to"hide" the IPv6 packet from the penultimate hop router, which is IPv6 unaware. No configuration change istherefore required for LDP on the PE-P interfaces.
442 Part II: Deployment Case Studies
442 Part II: Deployment Case Studies
Example 13-2 presents the LDP configuration bits, valid for both IPv4 and IPv6 traffic.
Example 13-2. LDP Configuration in the Core
hostname Bruxelip ceftag-switching tdp router-id Loopback0interface Serial0/0 ip address 172.20.4.2 255.255.255.0tag-switching ip
Note
Some service providers might be interested in using distinct LSPs for IPv4 and IPv6 traffic. Dedicated LSPhead and tail end can be set up for IPv6 traffic. This is achieved by configuring BGP peering for addressfamilies IPv6 and VPNv6 between dedicated IPv4 loopback addresses, distinct from the ones used for IPv4and VPNv4 peering. Note that, when doing so, the dedicated loopback addresses must be advertised into thecore IGP, and be allocated labels by LDP.
Some MPLS service provider want to control closely what addresses are being allocated labels. They use mplsldp advertise-tag for ldp-pe-filter, where ldp-pe-filter is an access list that permits only LSP certain tail-endaddresses. If different addresses are used for IPv6, these access lists may have to be modified accordingly.
EuropCom has been deploying MPLS-based traffic engineering Fast ReRoute (FRR) to provide bandwidthprotection upon link failure within the core, with restoration times equivalent to SONET/SDH APS andgreater scalability. Because IPv6 traffic uses the very same LSPs that have been set up and protected againstfailures for IPv4, it will take advantage of the same level of protection at no extra cost.
Note
Some Internet service providers have chosen to separate strictly the IA traffic from the VPN traffic in thecore. Sometimes for legacy reasons, only the VPN traffic is MPLS switched, whereas the other traffic is IPforwarded. In such a deployment model, PE routers are dedicated to either providing VPN access service orIA service. The latter routers are not MPLS enabled. Furthermore, MPLS routers, whether core or edge, areconfigured to allocate labels only for certain addresses, usually the one configured on VPN PE routers.
Deploying IPv6 Internet access in that environment requires either dedicating PEs for IPv6 over MPLS traffic,or migrating existing Internet access PEs to MPLS prior to enabling IPv6 on them. In both cases, the PEinterfaces facing the MPLS core network must also be MPLS enabled, which involves some core routersreconfiguration. These core routers may also require configuration changes to allocate labels for the new PEaddresses.
Enabling IPv6 in such a network scenario, not covered in this chapter, leads to bigger impact on the serviceprovider network, including some impact on the core.
Part II: Deployment Case Studies 443
Part II: Deployment Case Studies 443
QOS Design Considerations
QoS design is detailed in the "Quality of Service Design" section. Overall, EuropCom expects its QoS designto be fully transparent to the IPv6 deployment. All classification has been pushed to the CE. The core isoverengineered, so that no QoS mechanism is implemented there. EuropCom edges use the precedence toclassify traffic sent to CEs: Precedence is expected to be set the same way for IPv6 and IPv4 (by CEs), toreach zero impact on edge as well.
ICMP Design Considerations
Until P-routers are upgraded to a software version that provides minimum IPv6 support, they cannot sendICMPv6 messages, not even encapsulated in an MPLS stack. The issue is explained in Chapter 3, in thesection "IPv6 over 6PE."
Although this is acceptable for EuropCom in the initial phases, it is not sustainable on the long run. Note thatthis minimum support is limited to ICMPv6, and requires no IPv6 configuration.
ICMP is useful in two areas: It allows troubleshooting paths using traceroute, and it is used for discoveringoptimal MTU throughout the network (PMTU). None of these two operational aspects is critical, as explainedin section "Operating and Troubleshooting the Network." The EuropCom network has been designed andconfigured so that edge routers are responsible for sending back ICMP too-big messages on behalf of the core,and IP traceroute can be advantageously replaced by MPLS traceroute, which works between 6PE LSPendpoints.
EuropCom has chosen to wait for the next scheduled core software upgrade to get a resolution to thechallenges just discussed.
Edge Design
EuropCom has decided to reuse existing PE routers when deploying IPv6, except for the RRs, which are acritical part of their IPv4 service design. Instead, it is migrating PE routers dedicated to IPv4 IA to 6PErouters (supporting both IPv4 and IPv6 Internet access) and PE routers dedicated to VPNv4 access to 6VPErouters (supporting both VPNv4 and VPNv6 access).
In the initial IPv6 deployment phase, EuropCom anticipates IPv6 connectivity requests only at a few locations(London, Paris, Berlin, Milan, and Nice). It has therefore decided to make these locations IPv6 ready up front,while migrating the remaining locations based on customer demand for service.
Unlike P-routers, the impact on PE routers that need to provide IPv6 connectivity is significant, both in termof node upgrade (hardware/software) and in terms of configuration. PE routers need to be upgraded withimages that support IPv6, 6PE, and, for some of them, 6VPE. Depending on the platforms used on the edge,some edge devices also require hardware upgrades.
Note
At the time of this writing, the 6VPE feature is only available through the Cisco IOS Early Field Testprogram, and on certain Cisco platforms.
Software upgrade is not a concern: All PEs were upgraded a while ago to a Cisco IOS version that supportsIPv6 during a routine maintenance operation. So the current migration envisioned consists essentially of a
444 Part II: Deployment Case Studies
444 Part II: Deployment Case Studies
configuration change. The dedicated RRs represent an addition to EuropCom infrastructure.
For providing a consistent perspective of EuropCom configurations, a few routers (PE and RRs) will bereferred to. Figure 13-7 provides a logical view of EuropCom network, with these few routers (at Nice, Milan,Paris, London, Berlin, and Munich) highlighted.
Figure 13-7. EuropCom Network Details
[View full size image]
The following naming convention is used in EuropCom network:
PEs and CEs are prefixed by POP name (Nice-PE-IA, Milan-IGW, and so on).• PEs are suffixed by their functional role:
- IA for PEs providing IA: Nice-PE-IA- VPN for PEs providing VPN access: London-PE-VPN- RR6 for RRs: Milan-RR6- IGW for Internet gateways: Milan-IGW
•
Part II: Deployment Case Studies 445
Part II: Deployment Case Studies 445
Customer CEs are suffixed by the company name they belong to (Nice-CE-Cisco).• EuropCom CEs are suffixed with EuropCom: Nice-CE-EuropCom.• The first name instance of each router category (London-PE-VPN, Milan-RR6) does not carry anynumeric suffix. If several routers of the same category are deployed in the same location, a numericsuffix is used to distinguish them (London-PE-VPN_1, Milan-RR6_1, and so on).
•
Note that some customers (Cisco in London, IBM in Berlin) are dual homed.
PE Router Design and Implementation Considerations
For the PEs migrating to provide IPv6 access (IA for 6PE and VPN access for 6VPE), the core-facinginterfaces remain unchanged:
Core-facing interfaces are IPv4-only.• IGP toward the core remains IS-IS.• LDP on core-facing interfaces remains LDP over IPv4.•
However, three significant configuration changes have to be made:
IPv6 must be enabled on the CE-facing interfaces.• Some IPv6 routing protocol (static, IGP, BGP) must be configured/enabled on the CE-facinginterfaces to exchange IPv6 routes with CEs.
•
BGP IPv6 (and/or VPNv6) peering must be established with remote PEs to which the PEs intend toforward MPLS-encapsulated IPv6 traffic. Note that in the EuropCom design, the IPv6 iBGP peeringis always performed through RRs, as detailed in the "Route Reflector Design" section.
•
These three basic configuration tasks enable the network to provide basic IPv6 unicast transport and VPNservices. They are reviewed in the sections "PE-CE Interface Design," "PE-CE Routing Design," and "PE-PERouting Design."
EuropCom has chosen to deploy dedicated RRs for 6PE and 6VPE. This is to avoid overloading existing RRswith additional configuration and BGP routes, and keep the potential influence and security concernsdistinguished between IPv4 and IPv6. A full configuration setup is required for these routers that are added tothe existent infrastructure. RR configuration tasks are detailed in the section "Route Reflector Design."
Additional configuration may be needed for advanced services and features such as the following:
QoS configuration for IPv6• Management configuration• Security (access control) configuration•
These topics are detailed in the sections "Quality of Service Design" and "Operating and Troubleshooting theNetwork."
Before making the network changes mentioned, EuropCom has defined the IPv6 addressing plan for thedeployment. This is detailed in the "Addressing" section. It covers both EuropCom's own addressing plan andthe prefix-allocation scheme used for EuropCom customers.
PE-CE Interface Design
6PE routers are routers that migrated from IPv4 only to dual stack (IPv4 and IPv6). EuropCom does notinitially plan to dedicate PEs for IPv6 traffic, but rather to enable IPv6 on interfaces previously connectingIPv4-only customers.
446 Part II: Deployment Case Studies
446 Part II: Deployment Case Studies
EuropCom plans to IPv6 enable these interfaces at the pace of its customers' migration.
Customers migrating to IPv6 are assigned an IPv6 prefix (from /48 up to /64 depending on their size; see the"Addressing" section for details) from the EuropCom owned 2001:6FC::/32 prefix space.
For PE-CE interfaces, link-local addresses are used for IPv6 eBGP peering (see Chapter 2, "An IPv6Refresher," for the benefits of using link-local). These link-local addresses will not derive from the EUI-64address of the interface, because extensive BGP reconfiguration would be necessary when the hardware isreplaced because of failure or to upgrade. Instead, EuropCom is telling its IPv6 customers to use link-localaddresses for CE-PE peering in the form of FE80::ASN:ID, where ASN is the customer autonomous systemnumber, and ID is an arbitrary 16-bit number defined by the autonomous system to identify a particular router.Example 13-3 is illustrates a PE-CE interface configuration on a router providing IA (Nice-PE-IA), wherenew configuration (IPv6) is highlighted.
Example 13-3. PE-CE Interface Configuration for IA
Note that the IPv6 addresses on the CE-facing interface are link-locals, named after the EuropCom ASN(33751/0X83D7). EuropCom is also assigning a global address on the Loopback0 interface, for IPv6operation purpose, and that should not be used for routing protocol peering.
The corresponding CE routers (Nice-CE-b and Nice-CE-c) use the same addressing scheme (link-local onCE-PE interfaces). Example 13-4 illustrates Nice-CE-b configuration.
The configuration for Virtual Routing & Forwarding instances (VRFs) is detailed in the "VRF Design"section.
Although EuropCom does not offer a managed CE service, it does own the CEs that provide access toresidential users. The PE-CE interface in that case is configured exactly the same way as customers CEs, witha link-local address.
PE-CE Routing Design
As discussed in Chapter 4, "IPv6 Routing Protocols," and Chapter 7, "VPN IPv6 Architecture and Services,"several IPv6 routing protocols are available for exchanging routes between the PE and the CE. EuropComwould prefer to use eBGP as much as possible, although some EuropCom customers like the simplicity ofstatic routing, and still others, using OSPFv3 or EIGRPv6, would prefer not to have to operate anotherprotocol such as BGP. In addition, CEs owned by EuropCom (for residential access) will run IS-IS for IPv6toward the PE.
Static Routing Design Considerations
Some of the smallest enterprise customers, which are single homed to EuropCom, are using an IPv6 defaultroute to the PE, which in turn has static routes to the customer site. This configuration is limited to those siteswith a small number of routes and no need for any dynamic routing protocol. These enterprises are usuallygetting a /56 (if they have a single subnet) up to a /48 (multiple subnets) prefix, which end up in a single staticentry at the 6PE.
Static routing is applicable to both VPN and non-VPN enterprise customers. The following configurationexcerpt illustrates the Nice-PE-IA setup, providing static routing toward customers CE-b and CE-c, whichhave been assigned, respectively, 2001:6FC:1119:1::/56 and 2001:6FC:1119:2::/56.
The corresponding CE routers (Nice-CE-b in the following example) use a default route to point toNice-PE-IA:
hostname Nice-CE-b ! Node=61, AS=27301 Prefix=2001:6FC:2124:2::/56..!Static route to EuropComipv6 route ::/0 Serial 0/0
In the case of EuropCom's own CEs interfacing CPEs for providing residential access, static routes are alsoautomatically added when using DHCP Prefix Delegation (DHCP-PD) (a default route ::/0 pointing to thedelegating router and a route toward the Null0 interface for each delegated prefix). See details in Chapter 3.
BGP Routing Design
The majority of EuropCom IPv4 VPN customers use eBGP to exchange routes with the PE. The EuropComnetwork operations team is familiar with BGP, which they like for its flexibility to deal with policies on aper-VPN basis. Given the similarities between 6PE and VPNv4, and the interest in VPNv6 services,EuropCom will be promoting eBGP as the routing protocol of choice on the PE-CE interface.
BGP dampening is configured to limit instability in the control plane caused by route flapping. eBGP peersover link-local addresses, with the addressing scheme defined in the "Addressing" section. Example 13-6illustrates the BGP configuration for a 6PE router providing IPv6 IA (Nice-PE-IA). New configurationelements for IPv6 are highlighted.
Example 13-6. eBGP Configuration for a PE Router Providing IPv6 IA (Nice-PE-IA)
As a general VPNv4 BGP policy, and to protect PE routers, EuropCom is limiting the number of prefixesreceived from a particular CE to 50. Because IPv6 customers can get large chunks of addresses (up to /48; see"Addressing" section), the limit put on each CE connection will be dramatically lower for IPv6 than for IPv4.Example 13-7 illustrates the 6VPE configuration at Nice-PE-VPN, with regard to the PE-CE eBGP peering.The maximum number of prefixes for this customer is five. New configuration elements for IPv6 arehighlighted.
Part II: Deployment Case Studies 449
Part II: Deployment Case Studies 449
Example 13-7. eBGP Configuration for a PE Router Providing VPNv6 Access (Nice-PE-VPN)
The node's global address (2001:6FC::27/128) is announced for the sole purpose of troubleshooting (see the"Operating and Troubleshooting the Network" section).
On the customer side, the eBGP configuration for Nice-CE-Cisco is shown in Example 13-8.
Note that 2001:6FC:1123:1::/52 is the site address for Nice-CE-Cisco.
IGP Routing Design
Some EuropCom IPv4 VPN customers are using an IGP (OSPF, IS-IS, EIGRP) to connect to the PE. Thesame considerations for choosing the IPv4 IGP apply to IPv6. However, with Cisco IOS setups, no IGPcurrently supports IPv6 in a VPN context, so this alternative cannot be offered by EuropCom to its VPNv6customers. Non-VPN enterprise customers would not want to expose their IGP outside the enterprise, so thisis not an attractive alternative for them.
Finally, EuropCom-owned CEs need to run an IPv6 IGP with the PE. One possibility would have been forEuropCom to use iBGP between the CE and the PE. Several drawbacks and deployment constraints ledEuropCom to abandon this design:
With the first approach considered, plain iBGP sessions are set up from the CE to other iBGPspeakers. This requires a full mesh of iBGP sessions from that CE to other CEs and 6PEs, a solutionthat scales poorly.
•
Alternatively, the CE is configured as the RR client of its 6PE router of attachment. This indirectlyleads to MPLS being enabled on the CE-PE interface (BGP reflection implies that the BGP sessionsshare the same attributes, and MPLS is required on one side), which is not an option for EuropCom.Another issue arises with this design: The CE next hop is propagated by the RRs, and would have tobe advertised all over EuropCom network.
•
Alternatively, confederations could be used. The BGP autonomous system is divided into multipleautonomous systems. In the EuropCom case, that would be one autonomous system for the core, andone autonomous system for PE-CE pairs. These autonomous systems are running eBGP betweenthem, but they exchange routing as if they were using iBGP; next hop, metric, and local preferenceinformation are preserved. To the outside world, the confederation (the group of autonomous systems)looks like a single autonomous system. That solution was too complicated to put in place, and wouldrequire a significant redesign of the BGP EuropCom infrastructure.
•
In the end, EuropCom decided to go for IS-IS between these EuropCom CEs and the PE, as illustrated inExample 13-9.
Peering between 6PEs and between 6VPEs is similar to the currently deployed VPNv4 PE-PE peering. It isusing iBGP, with RRs to limit the number BGP sessions.
Because EuropCom plans to deploy dedicated RRs for handling iBGP IPv6 route distribution, the iBGPsessions from each 6PE (and 6VPE) to RRs will not refer the same loopback addresses. They will, however,advertise the same next hop so that the same LSPs are used.
In Examples 13-10 and 13-11, routers Nice-PE-IA and Nice-PE-VPN, the IPv4 RRs, have IPv4 addresses100.56.56.1 and 100.57.57.1, respectively. The IPv6 RRs have addresses 100.46.46.1 and 100.47.47.1. TheRR design is detailed in the section "Route Reflector Design."
In the case of 6PE, the advertised routes must be explicitly labeled (unlike VPN where the labeling is implicitin the configuration, and IPv4, where BGP does not transport a label when advertising prefixes). This isachieved by using the keyword send-label when specifying the 6PE peer, as shown in Example 13-10.
Example 13-10. i BGP Configuration for a PE Router Providing IPv6 IA (Nice-PE-IA)
To scale its IPv4 IA service and its VPNv4 service, EuropCom leveraged RRs in its network design. It makesa lot of sense to deploy a similar RR infrastructure for scaling IPv6 IA and VPNv6 service.
For both IA and VPN services, the primary reason for deploying RRs is to improve scalability, by drasticallyreducing the number of BGP sessions. One RR usually peers with many iBGP speakers, preventing a fullmesh of BGP sessions.
Because both IA traffic and VPN traffic are MPLS switched, RRs are not part of the LSP and can potentiallybe located anywhere in the network. IPv4 RRs are deployed only at L1 POPs, and dedicated for peering withIA PEs and VPN PEs. PEs peer with RRs based on their geographical proximity. RRs peer together in afull-mesh topology.
EuropCom plans to follow a similar design for IPv6 RRs and deploy IPv6 RRs at L1 POPs. Prefix aggregationcan be done more aggressively with IPv6, which will keep the number of routes under better control. With thisin mind, EuropCom does not expect the IPv6 BGP table size to get more than a few hundred entries per VPNfor the next two to three years. As far as the IA, EuropCom considered the total number of allocated IPv6prefixes worldwide (on 17/10/2005, it was 1322) and the number of BGP IPv6 routes currently deployed inIPv6 core BGP routers (700 entries in October 2005 according to http://www.cidr-report.org and evolvinglinearly). EuropCom expects the total number of BGP IPv6 routes to stay below 2000 entries by 2008, wellbelow the current 150,000 IPv4 entries it is experiencing. Therefore, unlike IPv4 RRs, IPv6 RRs will beshared between IPv6 IA and IPv6 VPN.
EuropCom will monitor any change in the RIRs address allocation strategy: If the RIRs agree to allocate /32prefix to large corporations for provider-independent prefixing, BGP IPv6 tables could quickly reach tensthousands of entries. Variation in the pace of the IPv6 prefix allocation, as well as service growth andcustomer needs, will dictate the expansion of the RR infrastructure and the possible specialization of RRs toeach of the two services.
The deployment strategy for RR is different from the one for PE routers. EuropCom wants to separate IPv6RRs from IPv4 RRs. If anything unexpected happens with IPv6, only PEs servicing IPv6 will be affected andonly from the IPv6 service perspective. Because EuropCom plans to deploy IPv6 access incrementally, thisstrategy will dramatically lower the risk on business-critical services such as IPv4 IA and VPNv4. PEs (6PEand 6VPE) will be connected to RRs based on geographical proximity, exactly like the VPNv4 RRs. Forredundancy reasons, two IPv6 RRs per L1 POP will be deployed.
To provide IPv6 RR functionality, EuropCom will install new hardware in L1 POP, and connect it to theP-routers and PE routers. It will then configure BGP peering to PEs in the L1 POP, as well as PEs in L2 POPand L3 POP attached to it. Figure 13-8 illustrates the peering points between the RR in L1 POP, and the set ofRR clients.
Figure 13-8. EuropCom RR Design
[View full size image]
The following list of BGP RR clients must be configured in IPv6 RR (xxx-RR6 and xxx-RR6_1) routers ateach L1 POP:
PE routers (xxx-PE-IA) of the L1 POP providing IPv6 IA to EuropCom customers. This is IPv6 (6PE)peering.
•
PE routers (xxx-PE-VPN) of the L1 POP providing IPv6 VPN access to EuropCom customers. Thisincludes both VPNv6 (6VPE) peering for interconnecting customer sites, and IPv6 peering (6PE) forproviding IA to VPN customers.
•
PE routers (yyy-PE-IA, zzz-PE-IA) of the L2 POPs and L3 POPs (underneath this L1 POP) providingIPv6 IA to EuropCom customers. This is IPv6 (6PE) peering.
•
454 Part II: Deployment Case Studies
454 Part II: Deployment Case Studies
PE routers (yyy-PE-VPN, zzz-PE-VPN) of the L2 POPs and L3 POPs (underneath this L1 POP)providing IPv6 VPN access to EuropCom customers. This includes both IPv6 (6PE) and VPNv6(6VPE) peering.
•
Internet gateway (xxx-IGW) located in the L1 POP, to provide PE customers an access to the IPv6Internet.
•
RRs from other service providers. This is to provide inter-AS connectivity, and it includes both IPv6and VPNv6 peering. This service is detailed in the "Inter-AS Design" section.
•
EuropCom RRs in other L1 POP. All RRs peer together, with both IPv6 and VPNv6 address familiesenabled, as shown in Figure 13-9
•
Figure 13-9. Topology of the IPv6 and VPNv6 Route Reflection
[View full size image]
Example 13-12 illustrates the Milan-RR6 configuration, with regard to peering with Milan PEs (providing IAand VPN access) and Nice PEs (L2 POP attached to Milan). It also includes peering with Milan's Internetgateway (Milan-IGW). It does not show peering with L3 POPs, peering with RRs in other L1 POP, or peeringwith RRs of other service providers.
Example 13-12. RR Configuration Example
hostname Milan-RR6 !RR#46router bgp 33751!6PE peering for providing Internet accessaddress-family ipv6!Peering with Internet Gateway Milan-IGW neighbor 100.1.1.1 activate neighbor 100.1.1.1 route-reflector-client neighbor 100.1.1.1 send-label!Peering with Nice Internet access router Nice-PE-IA
Part II: Deployment Case Studies 455
Part II: Deployment Case Studies 455
neighbor 100.26.26.1 activate neighbor 100.26.26.1 route-reflector-client neighbor 100.26.26.1 send-label!Peering with Nice VPN router Nice-PE-VPN neighbor 100.27.27.1 activate neighbor 100.27.27.1 route-reflector-client neighbor 100.27.27.1 send-label!Peering with Milan Internet access router Milan-PE-IA neighbor 100.61.61.1 activate neighbor 100.61.61.1 route-reflector-client neighbor 100.61.61.1 send-label!Peering with Milan VPN router Milan-PE-VPN neighbor 100.62.62.1 activate neighbor 100.62.62.1 route-reflector-client neighbor 100.62.62.1 send-label!!VPNv6 peering for providing inter-site connectivity address-family vpnv6!Peering with Milan VPN router Nice-PE-VPN neighbor 100.27.27.1 activate neighbor 100.27.27.1 route-reflector-client neighbor 100.27.27.1 send-community extended!Peering with Milan VPN router Milan-PE-VPN neighbor 100.62.62.1 activate neighbor 100.62.62.1 route-reflector-client neighbor 100.62.62.1 send-community extended
VRF Design
The EuropCom business model is to provide VPNv6 access to some of its current VPNv4 customers. TheVRF design for these VPNv6 customers is intended to be rigorously identical to the one already defined,configured, and deployed for IPv4. In particular, all existing VRFs have been assigned names, routedistinguisher (RD), and route target. Enabling them for IPv6 is a matter of service enhancement and servicecoexistence rather than IPv4-to-IPv6 transition or new deployment.
All basic steps for the VRF design have already been made for the VPNv4 service:
1. Definition and configuration of VRF
2. Definition and configuration of RD
3. Definition and configuration of routing policies (import/export)
4. Interaction with the backbone control plane
5. Configuration of CE-facing interfaces
6. QoS policies
The concept of Multiprotocol VRF (MP-VRF) was detailed in Chapter 7, and it suits perfectly EuropComstrategy. Only a fraction of the actual VPNv4 design needs to be revisited. The remaining parts are amigration task, from an IPv4 service to a dual-stack service.
456 Part II: Deployment Case Studies
456 Part II: Deployment Case Studies
Out of the six steps defined above, Steps 1, 2, and 3 are handled by the migration of IPv4 VRF(s) intoMP-VRF(s). VRF names, route targets, and RDs already defined for VPNv4 service apply seamlessly toVPNv6 service wherever MP-VRF is enabled. The VRF migration can be done automatically and withoutdisrupting VPNv4 VRF operations (including forwarding) by executing the following commands:
EuropCom plans to use this command, one VRF at a time (the command can do all VRF at once, but themigration will be driven by individual customer requests). Example 13-13 illustrates how the migration worksin router Nice-PE-VPN.
When enabling a VRF for IPv6, the name and the RD remains unchanged (Cisco-Nice/21214:1, for instance).With the EuropCom design approach, the route targets also remain unchanged: IPv6 is simply "enabled" forthat particular VRF, and on all interfaces that belong to it.
Step 4 requires configuring the VPNv6 interaction with the backbone control plane. The interaction with thebackbone control plane requires some design and configuration work and was described in the "PE-PERouting Design" section.
Step 5 is partly covered by the migration to MP-VRFs (the VRF bound to the interface that was IPv4 onlybecame IPv4 and IPv6). The remaining part is to configure IPv6 (addressing and routing) in the interface.
Part II: Deployment Case Studies 457
Part II: Deployment Case Studies 457
Step 6 does not need to be revisited because the same QoS policies apply to IPv6. The existing QoS design isexpected to map onto VPNv6 and IPv6 IA traffic seamlessly. This is described in the "Quality of ServiceDesign" section.
Note
With MP-VRF, an interface can only belong to one VRF, and a VRF is uniquely identified by a single nameand a single RD. On a given VRF interface, IPv4 and IPv6 can be enabled together or separately, but theycannot be put in different VRFs. The enabling of each protocol is done at two levels: The protocol is enabledin the VRF definition, and then activated on a VRF interface by assigning an address (IPv4 or IPv6) to theinterface.
It is a VRF design choice to share a route target between IPv4 and IPv6, or to keep them distinct. EuropComchose to keep them identical, to minimize the redesign of VRF when deploying IPv6, and to minimizeoperation costs. However, that does not prevent it from enabling IPv4 only on certain sites of a given VPN, inwhich case sites not enabled for IPv6 will not participate in the IPv6 VPN.
Inter-AS Design
To connect to other service providers at POP/IX, EuropCom has been using the Scenario C for its VPNv4traffic, as described in RFC2547bis, in the section "Multi-AS Backbones."
In Scenario C, multihop MP-eBGP redistributes VPN routes across RRs in different autonomous systems.Labeled IPv4 routes to the PEs are advertised across Autonomous System Boundary Routers (ASBRs) so thata complete LSP is set up end to end.
In this scenario, ASBRs are not VPN aware; only RRs are VPN aware. For VPNv4, the followingsetup/configuration has been deployed:
EuropCom VPN PEs and RRs are leaking loopback addresses to service providers they peer with:
- VPN PEs are leaking one loopback address (/32) for enabling next-hop resolution at theremote service provider location.- VPN RRs are leaking one loopback address (/32) for enabling interprovider (inter-RR)eBGP peering.
•
The address leaking is performed over MP-BGP, with label, so that intermediate routers (P-routers)do not see these addresses. Therefore, the following MP-BGP peering has been set up for VPNv4:
- VPN PEs iBGP peering with VPN RRs- EuropCom ASBRs iBGP peering with VPN RRs- EuropCom ASBRs eBGP peering with remote service provider ASBR
•
VPN RRs of each service provider are peering together over eBGP and exchanging VPN routes. Thenext hop is forwarded "unchanged," so that the end-to-end LSP is not via RRs.
•
EuropCom customers at the Nice POP are accessing resources outside the EuropCom network, via xxCom, aTier 1 Italian MPLS service provider. xxCom shares EuropCom Internet exchange facility in Milan.
To enable the service for IPv6 and VPNv6 in Nice, using inter-AS Scenario C, EuropCom needs to modify theconfiguration at Nice-PE-IA, Nice-PE-VPN, Milan-RR6, and Milan-ASBR routers. Note that forMilan-ASBR, the configuration upgrade decision is driven by the new Milan-RR6 (see "Route Reflector
458 Part II: Deployment Case Studies
458 Part II: Deployment Case Studies
Design" section). The ASBRs remain completely IPv6 unaware, and do not need to be IPv6 capable.
Figure 13-10 shows the BGP peering points required to enable IPv6 interprovider connectivity from PErouters Nice-PE-IA and Nice-PE-VPN (providing IPv6 IA and VPN access, respectively) to the xxComnetwork.
Figure 13-10. BGP Peering Points for Enabling Inter-AS in Nice POP
[View full size image]
The following list of additional BGP peerings is necessary to enable inter-AS (Scenario C) communicationfrom an L2 POP such as Nice:
IPv4 with label peering from PE in Nice to the RR in Milan (Milan-RR6). This includes NICE-PE-IA(providing IA) and Nice-PE-VPN (providing VPN access) and comes in addition to peering pointsbetween the same pair of routers already described in the section "Route Reflector Design." TheseBGP peering points are used to distribute IPv4 PE addresses to the other autonomous systems.
•
IPv4 with label peering from the RR in Milan (Milan-RR6) to the ASBR (Milan-ASBR). This is alsofor distributing IPv4 PE addresses to the other autonomous systems.
•
IPv6 (6PE) and VPNv6 (6VPE) peering from the RR in Milan to the RR in the other autonomoussystems, to exchange IPv6 and VPNv6 routes, respectively.
•
The BGP peering (IPv4 with label) between boundary routers (Milan-ASBR and xxCom-ASBR) was alreadyset up for IPv4 inter-AS communication and is reused without configuration changes for IPv6 communication.
Example 13-14 illustrates the additional configuration in a VPN PE (Nice-PE-VPN) required in inter-ASScenario C to distribute the PE IPv4 address with label to xxCom.
Example 13-14. Inter-AS: IPv4+Label Peering from Nice-PE-VPN to RR
The RR in Milan is also peering with the ASBR (Milan-ASBR) and with each PE (Nice-PE-IA andNice-PE-VPN) to exchange IPv4 PE addresses with label, as illustrated in Example 13-16.
Example 13-16. Inter-AS: IPv4+Label Peering from Milan-RR6 to PEs and Milan-ASBR
hostname Milan-RR6 !PE#46router bgp 33751..address-family ipv4neighbor 100.70.70.1 activate !Peering to Milan-ASBR neighbor 100.70.70.1 send-labelneighbor 100.26.26.1 activate !Peering to Nice-PE-IA neighbor 100.26.26.1 send-labelneighbor 100.27.27.1 activate !Peering to Nice-PE-VPN neighbor 100.27.27.1 send-label
The Milan ASBR Milan-ASBR peers with the RR (Milan-RR6) as well as with the xxCom ASBAR(xxCom-ASBR) to exchange IPv4 PE addresses with label, as illustrated in Example 13-17.
Example 13-17. Inter-AS: Configuration at Milan-ASBR
(MP-iBGP peering with 6PE/6VPEs done outside this task)
ASBR
IPv4 with label MP-iBGP peering to IPv6 RRs
(IPv4 MP-eBGP peering with label to xxCom ASBR done already in the context of VPNv4)
Part II: Deployment Case Studies 461
Part II: Deployment Case Studies 461
Basic Services Design and Implementation
The primary services delivered by EuropCom are IPv6 global IA,and IPv6 VPN access. Global IA can also be offered to VPNcustomers. Carrier's Carrier is another IPv6 service that EuropComis offering to other ISPs.
Global IPv6 Internet Access Design and Implementation
The EuropCom infrastructure must be first enabled to provide IPv6over MPLS connectivity from PEs to IPv6 Internet gateways. TheIPv6 Internet gateways are typically located at each EuropCom IX(L1 POP).
PEs located in the L1 POP interface the Internet gateway over nativeIPv6 (routing and forwarding). IS-ISv6 is used to exchange routesbetween the PE to the IGW.
PEs located in L2 and L3 POPs interface with the IGW of theirclosest L1 POP. The peering in that case is performed over 6PE(IPv6 over MPLS), and routes are exchanged using iBGP peering viaRRs. The IGW is also a 6PE with regard to providing IA to thoseremote 6PEs/CE.
From the BGP configuration standpoint, the IGW (for instanceMilan-IGW) is just another PE, peering with the RRs, as describedin the section "Route Reflector Design."
Table 13.5 reviews the tasks taking place to provide IPv6 IA to anew EuropCom customer. I
Table 13-5. A Deployment Task ListEuropCom Task Customer TaskIn L1 POP, enable PE<->IGW IS-ISv6 peering. Note that this isdone prior to service deployment.In L1 POPs, enable RR<->IGW iBGP peering. Note that this is doneprior to service deployment, for the benefit of L2/L3 POP's PEs.Enable L2/L3 POP's PE<->RR iBGP peering. Note that this is doneonce, at first attached IPv6 customer.Allocate an IPv6 prefix P to the customer. Enable the network for IPv6. This is
done using one of the numerousavailable mechanisms (native, tunnels,and so on).
1) Enable the PE-CE interface by configuring link-local in thefollowing form:
ipv6 address FE80::ASN:ID link-local
2) Configure a global address on the loopback interface in thefollowing form:
ipv6 address 2001:6FC::node#/128
1) Enable the CE-PE interface byconfiguring link-local in the followingform:
ipv6 address FE80::ASN:ID link-local
2) Configure a global address on theloopback interface in the following form:
462 Part II: Deployment Case Studies
462 Part II: Deployment Case Studies
3) Protect the global address against denial-of-service (DoS) attacksusing access control lists (ACLs).
ipv6 address 2001:6FC:P::node#/128
3) Protect the global address against DoSattacks using ACLs.
Agree on a routing protocol on the PE-CE interface (preferred is eBGP).Configure the routing protocol on the PE-CE interface. Configure the routing protocol on the
CE-PE interface.
Layer 3 MPLS VPN Service Design and Implementation
Before enabling IPv6 VPN service for its VPNv4 customers, EuropCom has set up its infrastructure toestablish IPv6 MPLS VPN connectivity between 6VPEs (via RRs). This step is described in the section"Network Design." For L1 POP, this task has taken place before any customer service request was received.6VPE peering for remaining locations is configured only when needed (at the first customer request). All RRsare deployed before offering VPN access to the first EuropCom VPNv6 customer.
Table 13-6 reviews the tasks taking place to provide VPNv6 access to a new EuropCom customer.
Table 13-6. Layer 3 VPN Deployment Task List
EuropCom Task
Customer Task
In L1 POPs, enable 6VPE-IGW IS-ISv6 peering. Note that this is done prior to service deployment.
In L1 POPs, enable RR<->IGW iBGP peering. Note that this is done prior to service deployment, for thebenefit of L2/L3 POP's PEs.
Enable L2/L3 POP's PE<->RR iBGP peering. Note that this is done once, at first attached VPNv6 customer.
Allocate an IPv6 prefix P to the customer.
Defines an IPv6 addressing plan for subdividing P among IPv6 VPN sites, typically P:site#::/n.
Enable each site for IPv6. This is done using one of the numerous available mechanisms (native, tunnels, andso on).
Migrate the IPv4 VRF to MP-VRF using vrf upgrade-cli command.
1) Enable the PE-CE interface by configuring link-local in the following form:
ipv6 address FE80::ASN:ID link-local
Part II: Deployment Case Studies 463
Part II: Deployment Case Studies 463
2) Configure a global address on the loopback interface in the following form:
ipv6 address 2001:6FC::node#/128
2) Configure a global address on the loopback interface in the following form:
ipv6 address 2001:6FC::node#:/128
3) Protect the global address against DoS attacks using ACLs.
1) Enable the CE-PE interface by configuring link-local in the following form:
ipv6 address FE80::ASN:ID link-local
2) Configure a global address on the each PE-CE interface in the following form:
ipv6 address 2001:6FC:P:site#::node#/128
3) Protect the global address against DoS attacks using ACLs.
Agree on a routing protocol on the PE-CE interface (preferred is eBGP).
Configure the routing protocol on the PE-CE interface.
Configure the routing protocol on the CE-PE interface.
VPN Internet Access Service Design and Implementation
Most EuropCom VPN customers are also accessing the IPv4 Internet, and those getting VPNv6 access willneed to access the IPv6 Internet. The design of this service is similar to global IA service. 6VPE routerslocated in a L1 POP access the Internet gateway natively, whereas 6VPE routers located in L2 and L3 POPsaccess the IGW (in their closest L1 POP) over 6PE.
In the latter case, core design (essentially setup of 6VPE/RR/IGW iBGP peering) took place before anycustomer request for a few locations, but is a preliminary task for enabling other locations, based on customerrequest. Edge design (PE-CE peering) is always driven by customer request.
Configuring VPN IA in such 6VPE router involves configuring BGP peering with the IGW, via the IPv6 RR,as illustrated in the configuration in Example 13-18.
The corresponding configuration at Milan-RR6 is discussed in the "Route Reflector Design" section.
Note that EuropCom is leaking IPv6 customer site addresses (2001:6FC:1123:1::/56 and2001:6FC:1124:1::/56) toward the IGW. This is to allow the IGW to send back traffic to these customer sites.
In addition to the core iBGP configuration, some static routes are configured to allow VPN traffic to leave theVRF to access global resources, and to allow responses from global resources to enter the VRF. This requiresa default route in the VRF, pointing to the IGW, and a route in the default table pointing to the VRF (forprefixes owned by this VRF's customer). Example 13-19 at Nice-PE-VPN illustrates the static routingconfiguration setup for EuropCom customers Cisco and IBM.
Example 13-19. Static Routing Configuration for IA on VPN PE
hostname Nice-PE-VPN !PE#27..!Routes for outbound traffic from each VRF to Milan-IGWipv6 route vrf Cisco-Nice ::/0 2001:6FC::1:0:0:1 nexthop-vrf defaultipv6 route vrf IBM-Nice ::/0 2001:6FC::1:0:0:1 nexthop-vrf default!Routes for inbound traffic from Milan-IGW to VRFipv6 route 2001:6FC:1123:1::/52 Serial0/0 nexthop-vrf Cisco-Niceipv6 route 2001:6FC:1124:1::/52 Serial1/0 nexthop-vrf IBM-Nice
In summary, to enable IA within a VPN, EuropCom has to perform the steps listed in Table 13-7.
Table 13-7. Layer 3 VPN IA Deployment Task List
EuropCom Task (at PE)
Customer Task (at CE)
Core design (PE<->PE) if not done already for this customer PE of attachment:
iBGP 6PE peering to RR
iBGP RR peering to 6PE
Leak customer prefix into iBGP:
Part II: Deployment Case Studies 465
Part II: Deployment Case Studies 465
address-family ipv6
network 2001:6FC:P:site#::/n
Configure a static route from VRF to IGW:
ipv6 route vrf <vrf name> ::/0
2001:6FC::1:0:0:1 nexthop-vrf default
Configure a default route to 6VPE:
ipv6 route ::0/0 <interface to 6VPE>
Configure a static route from default to VRF:
ipv6 route 2001:6FC:P:site#::/n <VRF
interface> nexthop-vrf <vrf name>
Note that no configuration is necessary at the IGW, other than peering with RRs over 6PE iBGP (done once atcore design phase) and leaking a single loopback IPv6 address. This is shown in Example 13-20.
This service provides VPN access to a customer service provider, so this service needs to exchange routes andsend traffic over the EuropCom MPLS backbone. The only difference from a regular PE is that it providesMPLS-to-MPLS forwarding on the CsC-CE to CsC-PE interface, rather than IP-to-MPLS forwarding.
The EuropCom design of this service mandates that the CsC-CEs are "IPv6 enabled." The peering betweenCsC-CE and CsC-PE is performed over link-locals, using the previously defined address format. Example13-21 illustrates the CsC-6VPE to CsC-CE peering, between EuropCom and yyCom, using IPv6 CsC.
For CsC-6PE, the main difference is the lack of VRFs configured, and the fact that MP-BGP peering is usingaddress family IPv6 with label, as illustrated in Example 13-22.
The QoS provided by EuropCom to its IPv4 enterprise customers is a key feature of itsservice marketing. The demand for guaranteed levels of service has risen because mostEuropCom VPN customers have migrated their mission-critical applications, includingvoice and video, over IP/MPLS. A primary constraint of EuropCom IPv6 deployment is toprevent any impact on IPv4 QoS. At the same time, many IPv6 applications are IPv4applications migrating to IPv6 (critical data, voice, and video). EuropCom customersexpect them to run over IP/MPLS and get the same QoS as their IPv4 counterpart.
IPv6's interaction with the existent QoS deployment for IPv4 is multifaceted:
Impact of IPv6 traffic on IPv4 QoS, its handling with respect to the QoS-basedprocessing of IPv4 traffic
•
Impact of IPv6 QoS configuration on the network edge layer, its interaction withIPv4 QoS
•
Operation costs introduced by IPv6 QoS•
The EuropCom MPLS backbone is overengineered and can accommodate the IPv4 as wellas the additional IPv6 traffic. IPv6 traffic growth forecasts for the next two to three yearsjustify maintaining the current core design for two major reasons:
IPv6 adoption by EuropCom enterprise customers is expected to be slow in thenext few years, and most of the early adopters will run trials with limited numberof end users long before they will engage in full-scale deployments.
•
Part II: Deployment Case Studies 467
Part II: Deployment Case Studies 467
Traffic generated by bandwidth-intensive applications, such as voice and video,will not come on top of its IPv4 counterpart but rather replacing them, initially at aslow pace. Besides a small overhead (IPv6 header is 20 extra bytes), the IPv6traffic growth due to such applications should therefore have a limited impact oncore links utilization.
•
Overengineering the backbone has saved EuropCom from implementing differentiatedservices (DiffServ) in the core network. For this reason, it does not care about mixedclasses received from customer CEs and has not configured any QoS mechanism at theingress PE. For IPv6, the same strategy applies, and no QoS mechanism/configurationneeds to take place on the ingress interfaces. Note that EuropCom customers can configureQoS on the CE-PE interfaces, at their convenience and leading to two possible scenarios:
The application (a good example is IP telephony) marks the Precedence field inthe IP packet, and the CE uses the precedence in its CE-PE policy. In that case,assuming the application can also handle the marking of IPv6 packets, thecustomer-CE can police IPv6 traffic without any configuration change. Example13-23 illustrates Nice-CE-Cisco QoS setup.
Example 13-23. QoS Configuration of CE Router Nice-CE-Cisco
hostname Nice-CE-Cisco !CE#35..interface Serial0/0 ip address 172.21.4.2 255.255.255.0 ipv6 address 2001:6FC:1123:1:33::1/128 ipv6 address FE80::52DE:35 link-local service-policy out policy-CE-PE-QoS ! .. class-map class-interactive match precedence 3 class-map class-non-interactive match precedence 4 6 7 class-map class-RT match precedence 5 ! policy-map policy-CE-PE-QoS ..
Because match precedence is IP protocol independent, the preceding configurationis unchanged when IPv6 is activated.
•
The customer CE classifies traffic, polices it, and marks the Precedence field forPE-CE DiffServ on the remote EuropCom edge. Classification on the CE can getvery complicated, and involves deep packet inspection. In simple cases, thesource/destination addresses and ports are used to distinguish between real-time,high-priority, and Best Effort traffic. Examples of classification and DSCPmarking are provided in Chapter 5, "Implementing QoS."
•
On the egress side, some EuropCom customers have requested DiffServ to be activated onthe PE-CE interfaces. Because QoS is not activated at the ingress or in the core, thePrecedence field set in packets received from the customer network is carried transparentlyup to the egress PE. EuropCom can use the value to apply PHBs on the PE-CE link.EuropCom has defined (for IPv4) the precedence-to-PHB mapping shown in Table 13-8on the PE-CE interface.
468 Part II: Deployment Case Studies
468 Part II: Deployment Case Studies
Table 13-8. Precedence-to-PHB Mapping
Precedence Value PHBType ofTraffic
0,1,2,3 BE Best Efforttraffic
4,6,7 AF41 High-prioritytraffic
5 EF Real-timetraffic
Note
During congestion states, it is important to protect critical control traffic such as routing protocol traffic.Control traffic is tagged with precedence 6, and its prioritized handling is implemented with the help of theSelective Packet Discard (SPD) mechanism. IPv6 control traffic must also be marked with precedence 6, toavoid being dropped by SPD under congestion conditions.
When enabling VPNv6 on the egress PE, no change is expected in the QoS configuration. Example 13-24illustrates Nice-PE-VPN QoS configuration.
Example 13-24. QoS Configuration of PE Router Nice-PE-VPN
hostname Nice-PE-VPN !PE#27..!interface Serial0/0 vrf forwarding Cisco-Nice ip address 172.21.4.1 255.255.255.0 ipv6 address FE80::83D7:27 link-local service-policy out policy-PE-CE-QoS!..class-map class-PrecHigh match precedence 4 6 7class-map class-RT match precedence 5!policy-map policy-PE-CE-QoS class class-PrecHigh priority percent 40 class class-RT priority percent 50 random-detect class class-default bandwidth percent 10 random-detect
The match precedence command applies to both IPv4 and IPv6 packets. The behavior on PE-CE links iscontrolled by customer precedence set at the ingress CE (or application). The customer can decide to use thesame classification policy for IPv4 and IPv6.
Part II: Deployment Case Studies 469
Part II: Deployment Case Studies 469
Operating and Troubleshooting the Network
For the most part, EuropCom plans to keep managing its network as before,using IPv4 tools, processes, Management Information Bases (MIBs), andtransport. It sees IPv6 as a new service deployment rather than a replacementfor IPv4. Therefore, it will be managed as a service (service monitoring, IPv6traffic management, and so on), although the network itself will still bemanaged with the current IPv4 tools. Configuration management and topologymanagement, for instance, will continue to be performed using HP OpenView.This strategy relies on the fact that most devices will be either IPv4 only or dualstack, and none will be IPv6 only.
The core routers are IPv4 only.• The ASBRs are IPv4 only.• The IPv4 RRs are IPv4 only.• Many edge routers, especially in L3 POPs, are IPv4 only, and willremain that way until the first customer using such POP requests anIPv6 access.
•
The IPv6 RRs have no IPv6-enabled interface, and no IPv6 addressesconfigured.
•
Service and Traffic Monitoring
All the IPv6 services management will be performed over MPLS 6PE (all theIPv6 enabled devices have 6PE connectivity). Service availability will bemonitored using Nagios (IPv6 ping) and IPv6 traffic management using CiscoNetwork Analysis Module (NAM). See Chapter 10, "IPv6 NetworkManagement," for details.
Addressing
EuropCom is a well-established ISP, with more than 200 IPv6 customers.Therefore, it could justify and obtain a /32 prefix from the RIPE/NCC (seeChapter 12, "Generic Deployment Planning Guidelines," for details ondeployment planning), as illustrated in Table 13-9. The prefix allocated toEuropCom is 2001:6FC::/32.
The EuropCom addressing plan is in full compliance with RFC2373.
EuropCom will keep 2001:6FC::/48 to use for its own infrastructure. It will assign up to/48 to large enterprisecustomers, and up to /56 to small business customers, out of its 2001:6FC::/32 block. Residential customerswill each get a /64 prefix. Note that there is no fundamental difference whether the customers are VPNcustomers or IA customers. Allocated addresses will always be within the public range (2001:6FC::/32).
For large enterprise customers, the assigned prefix will be in the form 2001:6FC:1abc::/48, where abcidentifies the customer.
Small enterprise customers will get 2001:6FC:2abc:defg::/56, where abc:defg identifies the customer (defg >0).
EuropCom does not intend to "enforce" a routing policy that would require a customer to follow the precedingrule, other than making sure VPNv6 customers will not advertise more than a certain number of prefixes perPE.
Link-Local Addresses
On PE-CE interfaces, EuropCom will use link-local addresses for peering with the CE, in the formFE80::83D7:ID, where 83D7 is EuropCom ASN (33751) in hexadecimal format and the ID is a 16-bitnumeric value, starting at 1, reusable from link to link, and from PE to PE. Note that because most PE-CElinks are point to point, most peering address on the PE-CE interface will be FE80::83D7:1. On the CE side,the corresponding CE-PE address will be in the same format, with the customer ASN. For instance,EuropCom customer Cisco, with ASN 21214, will use FE80::52DE:1.
Addresses for Management
Because using link-local addresses on the PE-CE interface might be an issue for troubleshooting andmanagement (could not ping the interface from remote devices, for instance), and for any router applicationrequired to locally generate packets (including ICMPv6, Telnet, and so on), each side should assign a globaladdress on the PE-CE interface, from its own prefix. Typically, EuropCom customers will choose a smallblock (for instance /64) out of the prefix they got from EuropCom, and configure a loopback address out of it(one per CE). Note that assigning global addresses may open some security breach and such addresses shouldbe properly protected against DoS attacks (see the "Security" section).
EuropCom itself will use 2001:6FC::/64 for that purpose, and assign 2001:6FC::PE#/128 at each 6PE and6VPE (in each vrf). These global addresses will be advertised to all EuropCom 6PEs, but will never cross theautonomous system boundaries.
Using Unique-Local Addresses
EuropCom is not really concerned about unique-local addresses, which could be used for intra-site orinter-site communication. Because unique-local addresses are not publicly routable, a customer usingunique-local addresses will be allocated a public range anyway so that it can access the IPv6 Internet.EuropCom will simply filter unique-local prefix (FC00::/8) on the boundary to the public Internet, whiletreating them as regular global addresses when exchanged between sites of a VPN. In practice, 6PE routerswill have the configuration shown in Example 13-25.
The preceding prefix list will prevent unique-local or anything else outside the EuropCom prefix range to beadvertised to the IGW.
The leaking of addresses from a VPN site to the Internet is closely controlled by EuropCom, so no prefix listis required on 6VPE routers.
Inter-Provider Communications
For connecting IX and POPs together, EuropCom is using IPv4, and therefore does not have to create aspecific IPv6 addressing plan and can just use the existing IPv4 one, based on a private 172/16 block.
For interconnecting with other providers at IXs, EuropCom plans to use inter-AS 6PE, which again will notuse any IPv6 addresses, thus saving the need to agree on IPv6 addressing rules on these interfaces.
Multihoming
EuropCom CE routers can be multihomed in several ways:
Connected to several (usually two) ISPs, in which case they will get a prefix from EuropCom(2001:6FC:abcd::/48) and a prefix from another provider, and advertise both of them on both sides.This does not work differently than IPv4, and has all the same inconveniences (see the "Multihoming"section in Chapter 4 for details). However, "by default", Europcom do no plan to let prefixes morespecific than /35 (other than within its own 2001:6FC::/32 range) spreading over its core routingtables. In order for such multihoming configuration to be enabled, it will take case-by-casenegotiations between EuropCom, an EuropCom customer and the other provider. Whenever possible,EuropCom will rather implement a multihoming solution based on RFC2260 and RFC3178, andestablish a tunnel between the Customer Edge router and the Provider Edge router facing thiscustomer, via the secondary service provider.
•
Connected to two EuropCom PEs. In that case, EuropCom will assign 2001:6FC:1abc::/48, and theCE will advertise back chunks of it (2001:6FC:1abc:WXYZ::/s) to each CE, where WXYZ is amultihomed selector, and s ranges from 49 to 52.
•
In the case of IPv6 VPN service, a customer will be allocated 2001:6FC:1abc::/48, and will distribute smallerchunks to each site, (2001:6FC:1abcd:WXYZ::/s), like in the multihomed case.
472 Part II: Deployment Case Studies
472 Part II: Deployment Case Studies
MTU Discovery
Initially, no backbone routers will be upgraded to software images that can send ICMPv6 messages. SoP-routers cannot send "packet-too-big" ICMPv6 messages back to the source. Unlike IPv4, transit routerscannot fragment IPv6 packets with a size that does not fit the outgoing link MTU. If MTU design is not tunedup front, large IPv6 packets could be black-holed by the MPLS core.
To prevent core routers fragmenting VPNv4 traffic, EuropCom has been using mpls mtu on the ingress PE tocore interfaces, consistent with the core MTU. That way, packets can be fragmented at the edge of thenetwork if it is larger than the configured maximum labeled MTU size.
The same configuration applies to IPv6 labeled packets, because they use the same LSP (and label stack) asVPNv4. The difference is that instead of fragmenting IPv6 packets, the edge routers (6PE and 6VPE) willsend a "packet-too-big" ICMPv6 message back to the source.
Note that the "consistent MTU" approach applies to the core only. The MTU on the PE-CE link can besmaller than the one configured in the core. In this case, the PE will send back an ICMPv6 too-big messageover the MPLS core.
Security
An important aspect of the IPv6 deployment planning and design is that of assessing the security risks itwould introduce in EuropCom network. The analysis was performed based on the guidelines mentioned inChapter 9, "Securing IPv6 Networks," and it was decided that as a general rule, all IPv4 security policies willbe matched for IPv6. At the same time, EuropCom had to consider several IPv6- and 6PE-specific securitypolicies.
Securing the Edge
In the process of securing the edge, EuropCom took the following measures:
Updated the configuration of the PIX Firewall protecting the hosted services in the L1 POPs.• Updated any edge router IPv4 ACLs to IPv6. In matching the IPv4 security policies, the IPv6 filtersdefined on the edge routers observed the requirements of ICMPv6 as mentioned in Chapter 9.
•
Enabled IPv6 uRPF on all interfaces facing the Internet-access customers. This measure preventsspoofing attacks sourced by EuropCom customers.
•
EuropCom interfaces directly with only a subset of its customers. In these cases, it considers implementingprotective measures for its routers against floods of control message such as Router Solicitations, NeighborSolicitation, and MLD traffic. Example 13-26 shows how an interface is configured to police all NeighborSolicitation and "All Routers" messages.
Example 13-26. Configuring Control-Plane Protection
ipv6 access-list DOS-aclpermit icmp any any nd-nspermit ipv6 any host FF02::2
class-map match-all DOS-class match access-group name DOS-aclpolicy-map prevent-attack class DOS-classpolice 70000 1500 1500 conform-action transmit exceed-action drop
When implementing the policies shown in Example 13-26, consideration should be given to their impact onthe router operation. They should be implemented on a large scale only on interfaces that support thefunctionality in hardware.
Securing the 6PE Infrastructure
The MPLS backbone and the PE routers are critical elements to support the IPv6 service as well as existent,revenue-generating IPv4 services. The IPv6 deployment should not open any security holes that can expose itto attacks. A few security measures have to be enforced to protect the MPLS because of the 6PE/VPNv6overlay:
The global addresses of the loopback interfaces should not be advertised outside the EuropComnetwork because they can allow attackers to target a PE router over IPv6 and in the process impact theIPv4 services supported by that PE. Traffic destined for these management prefixes can be easilyblocked because, based on EuropCom addressing plan, they all belong to the prefix range2001:6FC::/64. The same policy should be implemented for any global address used on internal links.
•
If the P-routers in the MPLS backbone are capable of sending ICMP replies, traceroute ICMP traffichas to be particularly blocked at EuropCom border. As it was seen in the traceroute example of aprevious section, in this case the path would reveal the IPv4 addresses of the P-routers. Thisinformation can be used to attack the network core over IPv4.
•
ACLs can be implemented on PE routers to protect bandwidth, buffer, and processing resources incase of an IPv6 attack, as mentioned in the previous section.
•
Another useful feature that should be leveraged on the PE routers but, depending on the platform it can beused for EuropCom CE routers as well, is the control-plane protection. If the policy prevent-attack in Example13-26 is modified to include all ICMP traffic, it could be used to protect the router resources used for controlpurposes.
control-planeservice-policy input prevent-attack
Most network elements that support EuropCom IPv6 service are dual stack. The IPv4 side of these routers isalready secured based on the best practices recommendations.
Troubleshooting
Being able to easily troubleshoot network anomalies with regard to the new deployed service is a key elementof the EuropCom deployment process. EuropCom operation engineers are familiar with BGP, MPLS, IPv4,and VPN. When troubleshooting IPv6, anything that looks similar to VPNv4 will dramatically minimize theirlearning curve. In fact, very few of the tools and commands used to troubleshoot 6PE and 6VPE are specificto IPv6. In the vast majority of the cases, the troubleshooting methodology is the same for IPv4 and IPv6, andthe commands and tools vary by one keyword.
474 Part II: Deployment Case Studies
474 Part II: Deployment Case Studies
Routing
The deployed solution (6PE/6PE) involves principally BGP, which EuropCom has been already operating forIPv4 services. The same set of commands EuropCom is already familiar with can be used (with different setof arguments) for IPv6, and similar outputs are obtained.
For instance, you can display a summary of BGP IPv6 activity as shown in Example 13-27.
Example 13-27. BGP IPv6 Activity Summary
Nice-PE-IA#show bgp ipv6 summaryFor address family: IPv6 UnicastBGP router identifier 100.26.26.1, local AS number 33751BGP table version is 15, main routing table version 1512 network entries using 1692 bytes of memory22 path entries using 1672 bytes of memory5/4 BGP path/bestpath attribute entries using 580 bytes of memory14 BGP rrinfo entries using 336 bytes of memory2 BGP AS-PATH entries using 48 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP using 4328 total bytes of memoryDampening enabled. 0 history paths, 0 dampened pathsBGP activity 13/1 prefixes, 23/1 paths, scan interval 60 secsNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd100.46.46.1 4 33751 991 983 15 0 0 16:26:21 10100.47.47.1 4 33751 991 983 15 0 0 16:26:22 10FE80::4F6B:44%Serial1/0 4 20331 982 987 15 0 0 14:55:52 1
Each table (BGP IPv6, BGP VPNv6) can be looked at individually, as shown in Example 13-28.
Example 13-28. Dumping BGP IPv6 Table
Nice-PE-IA#show bgp ipv6 unicastBGP table version is 15, local router ID is 100.26.26.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path* i2001:500::/48 ::FFFF:100.1.1.1 0 100 0 10000 ?*>i ::FFFF:100.1.1.1 0 100 0 10000 ?* i2001:6FC::1/128 ::FFFF:100.1.1.1 0 100 0 i*>i ::FFFF:100.1.1.1 0 100 0 i..
IPv6 routing tables can be displayed, to identify each routing protocol contributor to routable entries, asshown in Example 13-29.
Example 13-29. Dumping IPv6 Routing Table
Nice-PE-IA#show ipv6 routeIPv6 Routing Table - default - 13 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
Part II: Deployment Case Studies 475
Part II: Deployment Case Studies 475
IA - ISIS interarea, IS - ISIS summary O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2B 2001:500::/48 [200/0]
via 100.1.1.1%Default-IP-Routing-Table, indirectly connectedB 2001:6FC::1/128 [200/0] via 100.1.1.1%Default-IP-Routing-Table, cLC 2001:6FC::26/128 [0/0] via Loopback0, receive..
Note that, from an IPv6 routing perspective, entries reachable over the MPLS backbone are listed as"indirectly connected" because MPLS is providing a layer 2 tunnel mechanism.
Forwarding
Forwarding anomalies should be detected, understood, and troubleshot. Tools such as ping ipv6 and tracerouteipv6 are used to validate data-plane connectivity and detect traffic black-holing. Commands such as traceroutempls and show mpls forwarding can pinpoint the damaged node, interface, and FEC. At the edge,troubleshooting forwarding failures for a particular IPv6 destination commonly leads to breaking down therecursive resolution into elementary pieces. This requires combining analysis of IPv6 routing (iBGP/eBGP),IP routing (IS-IS/OSPF), label distribution (BGP/LDP/RSVP), and adjacency resolution to narrow down aresolution breakage.
PE-CE Connectivity
The IPv6 ping and traceroute are useful to check connectivity from a PE to a CE, whether locally attached, orremote over the MPLS backbone.
When locally attached, EuropCom uses IPv6 ping with the CE link-local address (used for eBGP peering), asillustrated here (pinging Nice-CE):
Nice-PE-IA#ping FE80::4F6B:44%Serial1/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to FE80::4F6B:44, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/48 ms
The same command can be used to test remote PE or CE reachability, but only IPv6 global addresses can beused (link-locals are not advertised beyond the link):
London-PE-IA# ping 2001:6FC:1120:1::44Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:6FC:1120:1:44::1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/48 ms
Note that the ping (and traceroute) over MPLS requires PEs and CEs to announce one IPv6 global prefix.Each 6PE router announces 2001:6FC::PE#/128, filtered at the autonomous system edge. Each IPv6 CEconfigures 2001:6FC:prefix:CE#/128 and announces it as part as their less-specific prefix(2001:6FC:prefix::/n).
476 Part II: Deployment Case Studies
476 Part II: Deployment Case Studies
Reachability of remote PEs and CEs can be tested by using traceroute. EuropCom has configured all its PEswith no mpls ip propagate-ttl forwarded, so when traceroute is executed from a CE, it will only show the IPv6nodes:
After the P-routers have been upgraded with images that support ICMPv6, the same command executed onthe PE router (TTL is then propagated) will also show P-routers responses, as illustrated here:
When run from a 6VPE router, both ping and traceroute commands accept a vrf argument, exactly as in thecase of VPNv4.
Note that the traceroute command is useful for evaluating the path across the MPLS backbone, but not fortroubleshooting data-plane failures. The P-routers are IPv6 unaware (like they are VPNv4 unaware), so theICMPv6 messages that they generate in response to the traceroute command are forwarded to the egress PEusing the received label stack. It is the egress PE that can route the ICMPv6 message to the source of thetraceroute. When the MPLS path is broken, it is also broken from the ICMP message, which cannot reach theegress PE.
For troubleshooting data-plane failures, LSP ping should be used.
PE Imposition Path
On Cisco routers, when it comes to troubleshooting the imposition path, the most useful command to startfrom is the Cisco Express Forwarding (CEF) show ipv6 cef command. You can either display the forwardingtable with label stacks used for each destination prefix, as shown in Example 13-30, or display details for aspecific entry, to analyze how the destination was resolved and the label stack computed, as shown inExample 13-31.
path 024F56A8, path list 024F0BA8, share 0/1, type attached nexthop ifnums: (none) path_list contains at least one resolved destination(s). HW IPv4 notified.
nexthop 172.20.25.1 Serial0/0 label 38, adjacency IP adj out of Serial0/0 0289BEF0 output chain: label 72 label 38 TAG adj out of Serial0/0 0289BD80
From the preceding detailed output, each label composing the label stack has a different origin that can betracked down individually. BGP table has the bottom label, as shown in Example 13-32.
Example 13-32. Details on a BGP Entry in the BGP Table
Nice-PE-IA#show bgp ipv6 unicast 2001:500::/48BGP routing table entry for 2001:500::/48, version 2Paths: (2 available, best #2, table default) Advertised to update-groups: 1 10000 ::FFFF:100.1.1.1 (metric 30) from 100.47.47.1 (100.47.47.1) Origin incomplete, metric 0, localpref 100, valid, internal Originator: 100.1.1.1, Cluster list: 100.47.47.1,
mpls labels in/out nolabel/72 10000 ::FFFF:100.1.1.1 (metric 30) from 100.46.46.1 (100.46.46.1) Origin incomplete, metric 0, localpref 100, valid, internal, best Originator: 100.1.1.1, Cluster list: 100.46.46.1, mpls labels in/out nolabel/72LDP (used in this example, could be replaced by RSVP) has the other labels:Nice-PE-IA#show mpls ldp bindings 100.1.1.1 32 lib entry: 100.1.1.1/32, rev 56 local binding: label: 40
The disposition path can be looked at and troubleshot by displaying the MPLS forwarding table. Example13-33 illustrates the output at Milan-IGW.
Example 13-33. Dumping the MPLS Forwarding Table
Milan-IGW#show mpls forwarding-tableLocal Outgoing Prefix Bytes Label Outgoing Next Hop
478 Part II: Deployment Case Studies
478 Part II: Deployment Case Studies
Label Label or VC or Tunnel Id Switched interface16 Pop Label 100.14.14.1/32 0 Se0/0 point2point17 26 100.46.46.1/32 0 Se0/0 point2point..72 No Label 2001:500::/48 63121 Se1/0 point2point73 Aggregate 2001:6FC::1/128 24123
The label used for switching has been announced by iBGP (6PE in this example), and can be checked.Example 13-34 illustrates this switching.
Example 13-34. BGP Label Analysis
Milan-IGW#show bgp ipv6 2001:500::/48BGP routing table entry for 2001:500::/48, version 2Paths: (1 available, best #1, table default) Advertised to update-groups: 2 10000 FE80::2710:2 (FE80::2710:2) from FE80::2710:2%Serial1/0 (100.2.2.2) Origin incomplete, metric 0, localpref 100, valid, external, best,
mpls labels in/out 72/nolabel
Label Switch Path
Because the 6PE and 6VPE LSP endpoints are IPv4 addresses, the IPv4 tools EuropCom has been using totroubleshoot LSPs are more than ever useful to detect data-plane failures that would lead to IPv6 trafficblack-holing.
In Example 13-35, at Nice-PE-IA, the show ipv6 route command provides the LSP IPv4 tail end.
Example 13-35. Analyzing the Label Switch Path
Nice-PE-IA#show ipv6 route 2001:6FC::1/128Routing entry for 2001:6FC::1/128 Known via "bgp 33751", distance 200, metric 0, type internal Route count is 1/1, share count 0 Routing paths:
100.1.1.1%Default-IP-Routing-Table indirectly connected MPLS Required Last updated 02:42:12 ago
And the traceroute-LSP, executed from Nice-PE-IA, is shown in Example 13-36.
Example 13-36. Traceroute-LSP Example
Nice-PE-IA#traceroute mpls ipv4 100.1.1.1/32 verboseTracing MPLS Label Switched Path to 100.1.1.1/32, timeout is 2 secondsCodes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request
Part II: Deployment Case Studies 479
Part II: Deployment Case Studies 479
Type escape sequence to abort. 0 172.20.25.2 0.0.0.0 MRU 1500 [Labels: 38 Exp: 0]R 1 172.20.25.1 0.0.0.0 MRU 1500 [Labels: 30 Exp: 0] 40 ms, ret code 6R 2 172.20.10.1 0.0.0.0 MRU 1504 [Labels: implicit-null Exp: 0] 60 ms, ret code 6! 3 172.20.40.1 48 ms
Troubleshooting Routing and Forwarding
When it comes to fine troubleshooting of routing and forwarding anomalies, enabling debugging commandscan prove useful, although the number of messages (factor of the activity on the wire) can annihilate theusability of such tool (debug ipv6 cef, debug mpls packet, debug ipv6 packet for the forwarding path; debugbgp ipv6 and debug bgp vpnv6 for the control plane).
External tools, such as ethereal, are also used in critical cases to capture and analyze relevant traffic.
Design Lessons
A number of observations can be made from EuropCom design decisions:
When mapped onto existing IPv4 IA and VPNv4 MPLS services, 6PE and 6VPE, respectively, offer alow-cost, low-risk deployment strategy. Reusing the existing LSPs further minimizes operating costs:Anything in the core that is already set up for existing LSPs (label distribution, FRR, and so on) willbenefit IPv6, too.
•
Link-local peering for eBGP PE-CE session is a useful and safe approach that simplifies theaddressing planeven though it does not save the need to configure at least one global address in eachbox for network error reporting and network management.
•
RR design for IPv6 is strictly identical in nature to the IPv4 RR design. Separating IPv4 RRs and IPv6RRs is not required, but minimizes deployment risks.
•
Whichever QoS mechanism is implemented in the core, and on the edges, it is far easier if it does notdifferentiate between IPv4 and IPv6. QoS MQC commands such as match precedence are usefulbecause they apply to both protocols.
•
A consistent MTU configuration that pushes PMTU management responsibility to the edges is a mustfor IPv6 deployment, unless P-routers are ICMPv6 capable.
•
Chapter 14. Deploying IPv6 in an IP Service ProviderNetwork
This chapter continues the series of case studies by presenting the design of the IPv6 services and theirdeployment for an IP wholesale access provider. Unlike the example in Chapter 13, "Deploying IPv6 in anMPLS Service Provider Network," the provider network in this case does not deploy MPLS in support of itsIPv4 services. The IPv6 deployment strategy matches the IP forwarding-based design of the network. Thiscase study covers all aspects of rolling out and operating IPv6-based services, including the following:
Existent IPv4 network environment and IPv4 services overview• Review of planned IPv6 service offering•
480 Part II: Deployment Case Studies
480 Part II: Deployment Case Studies
IPv6 deployment design objectives, design options, and the reasons for the final design selections• Design and implementation of basic IPv6 unicast transport services• Design and implementation of advanced IPv6 services such as multicast and QoS• Managing, operating, and troubleshooting the network•
This chapter provides a practical example of deploying IPv6 in the network of an IP service provider.
Network Environment and IPv4 Services
RTPCom is a fictitious wholesale access provider that covers most major metropolitan areas inthe United States. It started by providing access services to its residential and businesscustomers over dialup and ISDN. Today, most of its customers are provided broadband accessover xDSL, Fiber, or WiFi. RTPCom provides IPv4 unicast connectivity for its customers,linking them to their Internet service providers of choice.
Considering the large number of residential customers, aggregation is important in RTPCom'snetwork design. Its backbone is structured in three levels of points of presence (POPs) (Figure14-1).
Figure 14-1. RTPCom POP Architecture
Level 1 (L1) POPs form the backbone of the network. They service large metropolitan areasand they provide the interface to various ISPs. Originally the L1 POPs were not interconnectedand RTPCom's network was not contiguous. As its footprint and customer base grew, RTPComcould justify owning the OC-192 lines that currently connect its L1 POPs.
The L1 POPs connect to L2 (L2) POPs over OC-192 or OC-48 links depending on the size ofthe L2 POP. The later provide access services in areas of the metropolitan domain serviced bythe L1 POP or in other smaller cities. L2 POPs aggregate L3 (L3) POPs over OC-48 or OC-3links. Figure 14-2 presents RTPCom's network in geographical context.
Part II: Deployment Case Studies 481
Part II: Deployment Case Studies 481
Figure 14-2. RTPCom NetworkGeographical Topology
[View full size image]
The link and media types used to interconnect RTPCom's POPs are summarized in Table 14-1.
Table 14-1. Backbone Interface TypesInterface Type Speed UseOC-192/10Gig 10
GbpsL1-L1andL1-L2POPs
OC-48 POS 2.5Gbps
L1-L2andL2-L3POPs
OC-3 POS 155Mbps
L2-L3POPs
Gigabit Ethernet 1Gbps
L1-L3andL2-L3POPs
The design of each POP type is emphasizing the need for aggregation and redundancy. The differencesrevolve mainly around the levels of aggregation and the bandwidths of the links used.
The L1 POPs form RTPCom's backbone with the following characteristics:
Highly secure over a dedicated private network• Uses high-bandwidth OC-48 and OC-192 backbone links• Is over-engineered, so that QoS is not used in the core for its IPv4 services•
482 Part II: Deployment Case Studies
482 Part II: Deployment Case Studies
Full backbone redundancy using parallel links between the L1 POPs• Uses a single autonomous system•
They also contain the L2TP Network Server (LNS) routers that terminate the PPP sessions initiated by thecustomers. The de-encapsulated traffic is then handed over to the ISP selected by those customers. Each LNSrouter supports the customers of a single ISP and it connects over dedicated VLANs to two edge routers thatprovide the uplink to that ISP. The L1 POP design and the backbone topology are shown in Figure 14-3.Authentication, authorization, and accounting (AAA) resources that are used by the LNS for managing thePPP sessions are maintained by the corresponding ISP and are not shown in this figure.
Figure 14-3. Level 1 POP Design and Backbone Topology
All routers in the L1 POPs belong to OSPF area 0. The L1 POPs peer via iBGP with the L2 POPs. Adedicated IGP is used between the LNS and the edge routers to implement layer 3 redundancy and loadbalancing. The edge routers connect to the collocated ISP routers which are not shown in the picture.
Multiple L2 POPs are deployed within a metropolitan area to provide customer access. L2 POPs can also beused by themselves in smaller markets. They rely on OC-48 Dynamic Packet Transport (DPT) rings toaggregate the access layer across the covered area or L3 POPs. The same design would have applied to aResilient Packet Ring (RPR, 802.17) infrastructure, too. Figure 14-4 presents the structure of an L2 POP.
Part II: Deployment Case Studies 483
Part II: Deployment Case Studies 483
Figure 14-4. Level 2 POP Design
[View full size image]
L2 POPs peer via interior Border Gateway Protocol (iBGP) with the L1 POPs. They run OSPF with the ringin area 0 and each aggregated location, a local access layer or L3 POPs, connecting to the ring in an area of itsown as shown in Figure 14-4.
The last building block in RTPCom's network design presented here is the L3 POP. It services small marketsor remote locations. It is basically made of the access layer and an aggregation layer that providesconnectivity to L2 POPs (Figure 14-5).
Figure 14-5. Level 3 POP Design
[View full size image]
484 Part II: Deployment Case Studies
484 Part II: Deployment Case Studies
L3 POPs connect to L2 POPs over OC-48 or OC-3 links. They run a single-area OSPF as an IGP.
The access layer represented in the POP design figures is similar for both L2 and L3 POP types. Its maincharacteristic is scalability needed to handle a large number of customers (Figure 14-6).
Figure 14-6. RTPCom Access Layer
[View full size image]
Part II: Deployment Case Studies 485
Part II: Deployment Case Studies 485
In terms of physical and link layers, RTPCom owns the entire last-mile infrastructure for all access types itoffers: ADSL, FTTH, and WiFi.
Note
RTPCom does not offer any services over cable. If it were to offer services, extending IPv6 access over suchan infrastructure would complicate the deployment. As mentioned in Chapter 3, "Delivering IPv6 UnicastServices," the cable specification (DOCSIS) does not support IPv6, so tunneling is the only mechanismavailable for transporting the IPv6 traffic.
RTPCom is currently evaluating WiMAX as an access technology but no service is yet provided as this wouldrequire a license subscription.
For the IPv4 service, RTPCom aggregates the customer-initiated PPP over Ethernet (PPPoE) sessions andbundles them through Layer 2 Tunneling Protocol (L2TP) tunnels to the edge of its network. LNS routers inL1 POPs terminate the PPPoE sessions, de-encapsulate the traffic, and forward it to ISPs. The operation ofthis service is also exemplified in Figure 14-6.
Through this wholesale model, RTPCom is not responsible for managing the global IPv4 addresses used bythese customers, because they are managed by their ISP. RTPCom only provides transport for the
486 Part II: Deployment Case Studies
486 Part II: Deployment Case Studies
encapsulated traffic and for that purpose it uses the private IPv4 address space.
The bulk of RTPCom's business is providing residential customers with access to an ISP. It is alsoaggressively developing its small office/home office (SOHO) customer base. RTPCom would like to expandits service offering into the Triple Play (data, voice, video) arena. Although the wholesale model used for theIPv4 unicast-based services can easily support Voice over IP (VoIP), it does not support in a scalable mannercontent delivery (CD)-based on multicast. All RTPCom's customers have a virtual point-to-point link to theirgateway (LNS) across a large portion of the network (L3, L2, and nearest L1 POP). Because the LNS is theonly device that can do traffic replication for all the end users, RTPCom's network is flooded with multiplereplicas of the same packets for each customer subscribed to a given content channel. This inefficient use ofnetwork resources limits significantly the scale of any multicast-based service.
IPv6 Deployment Plans
RTPCom's pursuit of IPv6 is not driven by IPv4 address-space depletion pressures.RTPCom relies safely on the private address space to support its wholesale business model.On the other hand, RTPCom sees IPv6 as an opportunity to create the next-generationinfrastructure that would allow the company to increase its customer reach, and mostimportant, to diversify its service offering. In particular, RTPCom intends to increase itsrevenue from existent broadband subscribers by providing an infrastructure for value addservices such as CD. Its expansion plans in this sense are limited by the scalability problemsfaced with enabling multicast in its current network.
The potential to leverage IPv6 services as service differentiator in a competitive market didnot escape RTPCom's planning. Nevertheless, RTPCom sees IPv6 as an enabler, as well asan opportunity to reinvent its own infrastructure.
Targeted IPv6 Services
Despite deciding to expand its service portfolio, RTPCom does not intend to significantlychange its business model. In other words, RTPCom will continue to be an access,wholesale provider and will link its customers to service (Internet or content) providers.RTPCom's goal is to prepare its network to support new types of services offered by theservice providers. Table 14-2 summarizes the services RTPCom customers will be able toreceive over IPv4 and IPv6.
Table 14-2. IP Services Available to RTPCom's Customers
Service NameIPv4Service
IPv6Service
Internet access Yes YesDNS service Yes YesMail service Yes YesMulticast-based CD No YesContent hosting/storage No YesVoIP Yes YesMobile IP No Yes
Part II: Deployment Case Studies 487
Part II: Deployment Case Studies 487
To support these services, RTPCom's network needs to provide the following:
Unicast connectivity for Internet access, DNS services, content hosting, storage, and VoIP• Multicast connectivity for CD such as video and audio streaming•
The actual access to the Internet, the voice services, the management, and distribution of the content arehandled by the service providers that RTPCom interfaces with at its L1 POPs.
Chapter 13 already discussed in detail the characteristics of most services RTPCom plans to support, thereforethe following sections will only highlight any differences specific to this case study.
Unicast Connectivity
Providing IPv6 unicast connectivity is essential to all services that would be offered to RTPCom's customers.Unlike IPv4's case, with the IPv6 service an RTPCom subscriber can communicate with any other RTPComsubscriber without going through the ISP. In fact, in the trial phase of the service offering, the subscribers willnot be able to access the IPv6 Internet. The emphasis is placed on peer-to-peer communication and servicessuch as VoIPv6.
Internet Access
In a second phase of the deployment, IPv6 subscribers are offered Internet access services. The subscription issimilar to the IPv4 Internet access service, but only a single ISP will be available.
Initially, the Internet access service is bundled with other services to overcome lower interest because oflimited content availability on the IPv6 Internet.
DNS Services
This is a service managed by RTPCom and it is particularly important because its customers are allowed tocommunicate among themselves without going through their respective ISPs.
BIND 9 is used to implement DNS for the IPv6 deployment. To avoid DNS issues (see Chapter 3), all serversare upgraded to dual stack and they can be reached via both IPv4 and IPv6. The AAAA records are added toall servers.
Mail Services
The IPv6 ISP provides e-mail services similar to the ones offered to IPv4 users. Dual-stack servers areinstalled that share the disk resources used for the IPv4 e-mail services. This makes the e-mail servicesaccessible over IPv4 or IPv6.
Content Hosting/Storage
Content hosting and content storing is also a service offered and managed by RTPCom. These services areviewed as initial incentives to its customers to try IPv6 service. They are also viewed as a means to developthe internal (RTPCom subscribers) community of users. This service is completely new to RTPCom, sofurther refinement of a business model is expected.
The resources needed to support this and the DNS services are hosted in L1 and larger L2 POPs.
488 Part II: Deployment Case Studies
488 Part II: Deployment Case Studies
Voice over IP
Another new service for RTPCom is VoIPv6, which is viewed as an experiment. The intent is to stimulatecustomer interest and adoption through features, such as video telephony, even though there are no serviceproviders that expressed interest in offering the service. For this reason, RTPCom is providing exclusivelyon-net to on-net calls between its subscribers. The service will be expanded to provide off-net calls onlythrough partner service providers.
The business potential of a VoIP service is well understood by RTPCom's management. A aggressive plan todeploy the service over IPv4 is being developed. Despite being well proven in recent years, VoIP is a newendeavor for RTPCom. For this reason, the VoIPv6 service is seen as a precursor of the larger-scale servicerollout for both IPv4 and IPv6. It offers RTPCom the opportunity to develop and test provisioning,management, and billing mechanisms.
Technically, the VoIPv6 service is identical to the one described in Chapter 13 for EuropCom. It is SIP based,with the SIP registrar and SIP proxy servers located in the L1 POP data centers. With the larger number ofservice provided and in particularly in support of VoIPv6, RTPCom will have to implement QoS to meetcurrent and future service level agreement (SLA) requirements.
Content DeliveryMulticast
CD promises to be a profitable service. The large bandwidths already available with broadband access make itpossible to deliver video and audio streams to residential subscribers in parallel with Internet access. Serviceadoption can in turn increase demand for bandwidth, which results in an increase in business for accessproviders such as RTPCom.
Video and audio content can be delivered on demand or on scheduled basis. On-demand services rely onunicast transport and therefore are less scalable and more expensive. On the other hand, scheduled programscan be delivered with the help of multicast in a scalable manner. Each program is a multicast streamcorresponding to one or multiple (S,G). The programs can be received on PCs or set-top boxes provided bythe access provider or the service provider. Subscribers can join the ongoing program and they can be chargedon a monthly subscription basis or on time spent as a listener for the various multicast streams. The businessmodel will of course dictate the AAA resources deployed with the service.
RTPCom is much interested in enabling its infrastructure for multicast. The envisioned business model callsfor allowing content providers (CPs) to offer various programming to its customers. The set-top boxes will beprovided by RTPCom to allow its customers to switch easier between CPs. In the first phase, the accountingfor the service would be done trough monthly subscriptions for program packages. The current wholesaledesign of the IPv4 infrastructure is not capable of supporting a large scale multicast service. This is one of thereasons why RTPCom accelerated the deployment of IPv6, because it enables it to role out themulticast-based services.
Mobile IPv6Communities of Interest
The improvements made to mobility in IPv6 make the service better positioned for deployment. Chapter 8,"Advanced ServicesIPv6 Mobility," describes in detail the MIPv6 operation, support, and configuration onCisco routers. While the protocol continues to evolve, service models are being developed to leverage thisfeature. RTPCom realistically assessed MIPv6 as a long-term opportunity, but it formed a task force that ischarged with developing a market for this feature.
After a thorough market research and participation in several seminars on the topic, RTPCom's MIPv6 taskforce attempted its first service trial of a Cisco-proposed business model called community of interest. Thisconcept, described in Chapter 8, applies differently to different types of businesses. In the case of a service
Part II: Deployment Case Studies 489
Part II: Deployment Case Studies 489
provider, it basically refers to a group of mobile users that share a common interest. All these users have ahome prefix that identifies them. They can move around the service provider network or even the IPv6Internet if the service is available to that extent, and yet be virtually on the same network. These users can besimple mobile nodes or they can be mobile routers. They can share resources on the home prefix accessibleonly to them.
Configuring such a service is not difficult; it requires nothing more than the information presented in Chapter8. The concept clearly is powerful, so the only thing left is to define a service around it. The RTPCom MIPv6task force decided to trial one particular service model that targets business customers in major metropolitanareas.
Companies that operate within a metropolitan area and have mobile assets, such as a truck fleet or distributionrepresentatives, need to provide its field people with order, pick-up, and delivery information. Thisinformation is not updated real time, but rather every 15 to 20 minutes. The necessary amount of informationcannot be sent to a pager or other similar devices and the cell phone use is impractical from a scalability,manageability and cost perspective. However, RTPCom has a MIPv6-based solution to such a problem.
A company that purchases regular access (Internet access for IPv4 and IPv6) can trial for free the mobile CIservice. RTPCom installs and manages a router at the main offices of the customer. This router is enabled forMIPv6 (see Chapter 8). The laptops on each of the trucks and the laptops or handhelds of the sales force allbind to this home agent. When out in the field during the regular work day, all these mobile devices accessRTPCom's network through its WiFi access points (APs) that are spread throughout the city for RTPCom'swireless service. They then connect to the home agent at the main offices and download the relevant data frominformation servers. The APs can be found at coffee shops, fast-food restaurants, or other public places, socoverage is not an issue.
To summarize, the company used in the above example represents a "community of interest," and it is usingRTPCom's infrastructure for its own communication needs. The main reason why RTPCom can lock thecustomers in is that this service is available only when roaming its network and not a competitor's. The mobiledevice can actually be a mobile router in the case of a truck containing multiple IP devices on differentprefixes.
Note
Nothing would stop RTPCom's customers from managing their own home agent and managing their own"community of interest" so long as RTPCom does not specifically control the mobility services on itsnetwork. RTPCom offers the MIPv6 service as an incentive to businesses to subscribe for its access services.The boundaries of this business/service model and its details still need further refinement to make it a sourceof revenue in itself.
This trial has proven to be successful, so RTPCom is considering ways to expand it by identifying newcustomers, new "communities of interest."
Design Goals
Recognizing the benefits of offering multiple types of services such as voice, video, and data (Triple Play) tobroadband subscribers, RTPCom decided to prepare its network to support such services in a scalable andhigh performance manner. It also sees IPv6 as a good opportunity to investigate and trial new network designsthat would not see some of the shortcomings of its current PPP/L2TP-based model for the IPv4 Internet accessservice. In particular, one of the design goals is to support multicast-based services over IPv6. Nevertheless,
490 Part II: Deployment Case Studies
490 Part II: Deployment Case Studies
RTPCom does not intend to build a separate infrastructure for IPv6 but rather to enable the existent one tosupport the new services in parallel with the existent IPv4 ones. This planned coexistence leads to animportant design constraint that the IPv6 services would not impact the revenue generating IPv4 services.
In summary, the following bullets are RTPCom's design goals for this IPv6 deployment:
Overlay on the existent infrastructure with minimal equipment additions or upgrades in support ofIPv6.
•
The IPv6 services should be easy to enable across RTPCom's entire network when a customer requestis received.
•
IPv6 services should have no impact on the existent, revenue generating IPv4 services.• The IPv6-enabled network should be able to support both unicast- and multicast-based services in ascalable manner.
•
Quality of service (QoS) should be implemented to ensure the quality of the provided services.• IPv6 should not reduce the security of the network.•
It is expected that at first the IPv6 traffic will be minimal. RTPCom operates under the assumption that in thefirst one to two years the IPv6 traffic in the core of the network will not be larger than 20 percent of its totaldata traffic. On the other hand, at the access layer, it is expected that the IPv6 multicast will dramaticallychange the traffic profiles.
Design Options
With the deployment targets and guidelines identified, RTPCom set off to investigate its options with respectto enabling IPv6 in its network. Based on the service provider deployment recommendations made by theIETF IPv6 Operations work group (see RFC 4029 and Internet Draft ISP IPv6 Deployment Scenarios inBroadband Access Networks), the guidelines found in documents such as the IPv6 Promotion Council ofJapan (see http://www.v6pc.jp/pdf/041007_v6trans_guideline.pdf) and deployment experiences recorded by6NET project deliverables (see http://www.6net.org/), RTPCom ended up considering two service deploymentoptions:
PPP/L2TP-based service model similar to the IPv4 one• Dual-stack IPv6 deployment•
The solutions that rely on IPv6-over-IPv4 tunnels have been dismissed as not meeting the long term scope ofRTPCom's IPv6 deployment. RTPCom does not intend to postpone infrastructure investments related to theIPv6 deployment at the expense of a less-scalable and lower-performance service. Training its operations staffon a temporary solution based on IPv6 tunneling mechanisms would also be a waste of capital. Nativedeployment is considered on a case-by-case basis as an option in some POPs where routers can be dedicatedto support the IPv6 service exclusively. Routers replaced during regular network upgrades can be used toprovide IPv6 services with minimal impact on the IPv4 infrastructure.
PPP/L2TP-Based Deployment Option
The first option considered was for IPv6 to map the IPv4 design. In this case, RTPCom's customers wouldinitiate IPv6 PPPoE sessions that are bridged by the access router into an L2TP tunnel that is set up betweenthe access router and the LNS located in the data center of L1 POPs (see Figure 14-7). The PPP sessions areterminated by the LNS and the de-encapsulated IPv6 traffic is handed over to the ISP.
All the features necessary to support such a deployment model are currently available as described in Chapter3 of this book. The most important thing to notice is that with this approach, RTPCom has the option to useL2TP tunnels set up over IPv4; therefore, it could avoid the need to enable IPv6 in the core of its network.
The advantages of this deployment option are as follows:
Maintains a service and an operation model familiar to RTPCom In this case, IPv6 service works inthe same way as its IPv4 counterpart. RTPCom does not have to be concerned with customer IPprovisioning and with the characteristics of its traffic.
•
Avoids the upgrade of the core Because the L2TP tunnel can be set up over IPv4, the only portion ofthe network that has to be made IPv6 aware is the access layer, the LNSs in the data center and therouters that interface with the service providers.
•
492 Part II: Deployment Case Studies
492 Part II: Deployment Case Studies
No major training required for the operations staff This deployment model is sufficiently similar tothe IPv4 ones and the IPv6 transport sufficiently encapsulated for the operations staff to manage itwithout major training needed. The NMS systems do not require significant upgrades.
•
There is only one significant disadvantage to this deployment approach: It does not resolve the scalabilityproblem that plagues the deployment of IPv4 multicast.
Considering the advantages of the PPP/L2TP-based design, it is tempting to entertain the idea of a phaseddeployment with its first phase based on the PPP/L2TP design followed by a dual-stack phase.
Dual-Stack Deployment Option
The natural option for an IP service provider to deploy IPv6 in production is dual stack thus using nativeforwarding. As expected, the impact of such an approach is significant because all routers in its network willhave to be configured for IPv6. In this case, RTPCom is responsible for the IP provisioning of its customersand it will switch their traffic at layer 3 all the way to their service providers. The customer traffic is no longercharacterless to RTPCom. Figure 14-8 presents the operation of the IPv4 and IPv6 services in this scenario.
Figure 14-8. Dual-Stack Service Model
[View full size image]
Part II: Deployment Case Studies 493
Part II: Deployment Case Studies 493
The advantages of this deployment option are as follows:
It positions RTPCom for the future IPv6 network structure Despite the added management burden, theknowledge of the customer traffic and needs enables RTPCom to adapt to them and to new serviceswhile taking advantage of IPv6's larger address space.
•
Enables RTPCom to deploy a scalable multicast service By being aware of the customer traffic at IPlayer, RTPCom can leverage the IPv6 multicast control plane for a more optimal distribution of thetraffic. It can replicate the multicast traffic as close to the listeners as possible; therefore, it resolvesthe problems faced by the PPP/L2TP-based design.
•
It can deploy mobile services with MIPv6 In a network that relies on native forwarding throughout itsfootprint, the access provider can easily leverage the IPv6 implementation of the mobility services.
•
The disadvantages of this approach reflect its departure from the model used currently by RTPCom:
494 Part II: Deployment Case Studies
494 Part II: Deployment Case Studies
It might require the upgrade of some of the routers in the network Through the scheduled networkupdates, most routers run software that supports the necessary IPv6 features. However, an inventorywill need to be made with respect to the current state of the infrastructure equipment.
•
This deployment option impacts most devices in RTPCom's network Unlike the PPP/L2TP-basedapproach, in this case the network configuration process is more significant and involved.
•
RTPCom has to manage new aspects of the service With this service model, RTPCom is responsiblefor user provisioning and additional management and security.
•
A more intensive training process is required for the operations staff The personnel in charge of theupgraded network have to be familiar with more complex and detailed IPv6 features and protocols.
•
The dual-stack approach clearly addresses the long-term IPv6 strategy of RTPCom by enabling its networkfor future expansion, for optimal delivery of multicast-based services and mobile services.
Despite higher costs and potentially more significant impact on the current network, RTPCom decided todeploy a dual-stack IPv4-IPv6 network.
Note
Equipment-related costs for rolling out a dual-stack IPv6 service returned numbers lower than originallyexpected. This is particularly because most of RTPCom's network elements already support the targeted IPv6features. The deployment will be implemented in phases with service offered initially in large metropolitanareas and then expanded throughout RTPCom's network. The largest expense of the IPv6 service rollout isthat of training the operations team, provisioning the services and updating the network managementprocedures.
This decision reflects RTPCom's long-term commitment to IPv6 and Triple Play service offering expansion.
Basic Services Design and Implementation
RTPCom's IPv6 deployment strategy was set for dual stack, a framework that nowshapes the design of all IPv6 services. The foundation of the deployment is theaddressing plan.
Addressing Plan
RTPCom secured the 2600:A000::/24 prefix from the American Registry for InternetNumbers (ARIN) for its IPv6 nationwide deployment. It made a strong business casefor such a large address space based on its current customer base growth rate.RTPCom's ARIN record for this allocation is shown in Table 14-3.
network:Street-Address: 4704 Davis Drivenetwork:City: Research Triangle Parknetwork:State: NCnetwork:Postal-Code: 27709network:Country-Code: USnetwork:Tech-Contact: [email protected]:Updates: 20050505network:Updated-By: [email protected]:Class-Name:network: network
In designing the addressing structure of the IPv6 deployment and service, RTPCom decided to use thefollowing constraints:
Leverage the large address space to create a logical hierarchy in its addressing scheme.• Customers will be assigned either /64 or /56 prefixes.• A portion of the address space will be reserved for internal infrastructure needs.•
For administrative purposes, RTPCom's network was divided in two areas: East and West. Three bits arereserved to identify each L1 POP in each area. Four bits are reserved to identify the L2 POPs, and thesubsequent 6 bits are used to identify the L3 POPs. Table 14-4 summarizes the addressing scheme that will beimplemented by RTPCom.
As an example, the prefixes used for the L1 POPs and their respective subdivisions are shown in Table 14-5.
Table 14-5. Prefix Distribution per L1 POPs
L1 Name
Prefix
East
Atlanta
2600:A010::/28
New York
2600:A020::/28
Miami
2600:A030::/28
Chicago
2600:A040::/28
West
Houston
2600:A090::/28
Denver
2600:A0A0::/28
Seattle
2600:A0B0::/28
San Francisco
2600:A0C0::/28
The first prefix in both East (2600:A000::/28) and West (2600:A080::/28) ranges was reserved forinfrastructure purposes. The 2600:A000::/28 prefix is used in the manner described in Table 14-6.
The 2600:A080::/28 is reserved for further growth needs. These prefixes will be protected against outsidereach.
Unicast Connectivity
Unicast connectivity between customers and between customers and the ISP provides the underlying serviceupon which all other services are built.
As it was mentioned earlier, RTPCom decided to deploy IPv6 in dual-stack mode, unlike the PPP/L2TP-basedmodel used for the IPv4 service. RTPCom will switch the customer IPv6 traffic at layer 3 throughout itsnetwork, as depicted in Figure 14-8.
Router naming conventions in RTPCom's network are as follows:
Router_Name = (L1 name)-(L2 number)-(L3 number)-(POP router).• For routers within an L2 POP the (L3 number) field is 0.• For routers within and L1 POP the (L2 number) and (L3 number) fields are 0.• Routers in the data center are marked with D in the (L2 number) field.•
The routers that are used in the following sections to exemplify the implementation of the design concepts areidentified based on the naming convention in Figure 14-9.
500 Part II: Deployment Case Studies
500 Part II: Deployment Case Studies
Figure 14-9. Example of Router-Naming Convention Within the New York L1 POP
RTPCom's addressing scheme presented earlier provides the prefixes relevant to the routers identified inFigure 14-9:
L1 = New York (2600:A020::/28)• L2 = 10 (2600:A02A::/32)• L3 = 12 (2600:A02A:3000::/38)• L3 POP Router = 16 (2600:A02A:30F0::/44)• L3 POP Router 16 subscriber (/64) = 10 (2600:A02A:30F0:0A01::/64)• L3 POP Router 16 subscriber (/56) = 100 (2600:A02A:30F0:6400::/56)•
These prefixes are used for service purposes, while the 2600:A002:A::/36 prefix range is used forinfrastructure purposes.
Part II: Deployment Case Studies 501
Part II: Deployment Case Studies 501
From a routing perspective, the IPv6 deployment matches the IPv4 for the most part. The same routingprotocols are operating in the same areas of the network. There is, however, a significant difference in that theIPv4 infrastructure is not aware of prefixes outside of it. RTPCom provides virtual pipes between the ISPs andthe customers over its self-contained infrastructure. RTPCom's network is aware of the customer's IPv6traffic, so it will have to carry prefixes used for the services provided by the content or Internet serviceproviders.
Access
At the access layer, it is important to note that the same virtual links (VLANs for FTTH and PVCs for ADSL)used to provide IPv4 address are used to provide IPv6 access, too. For IPv4 the access router merely bridgesthe customer initiated PPPoE sessions into an L2TP tunnel, although for IPv6, the access router represents thelayer 3 gateway for the customer. Implementing this hybrid access model is straight forward on the FTTHinterfaces. On the ATM interfaces, the access router has to know to bridge the IPv4 traffic and to route theIPv6. The IPv6 RBE feature will be used for this purpose.
RTPCom is in this case responsible for provisioning the customer and it decided to use the following twomechanisms:
For single-network customers, provide a /64 prefix through Router Advertisements. The user isinstructed to obtain the other provisioning parameters via stateless DHCP (resources being providedby RTPCom). The stateful DHCPv6 option was not selected because it is not implemented in mosthost stacks.
•
Customers that manage multiple networks on their site through a CPE router are provided a /56 prefixvia DHCP-PD based on the DUID of their CPE router (see Chapter 3). On the link between the accessrouter and the CPE, no prefix is assigned.
•
Note
RTPCom considered a PPP-based solution at the access layer where PPPoE sessions initiated by the customerwould be terminated by the access router and the traffic IP switched through the rest of the network. Theadvantage of this approach is that it allows RTPCom to leverage PPP for authenticating and authorizing thecustomer with the help of a RADIUS server. This would simplify provisioning by centralizing it in theRADIUS server. RTPCom decided, however, to keep the deployment simple and avoid the additionalencapsulation even if that might imply more involved provisioning.
Router NY-10-12-16 in Figure 14-9 provides ADSL access and has the relevant configuration shown inExample 14-1.
pvc 0/132 encapsulation aal5snap !ipv6 dhcp server DHCP-Customers
ipv6 enableipv6 nd other-config-flag
!
Note
The DUID of subscriber 100 CPE is 00030001000BBFAA7400 and 2600:A002::1/64 is the address of theDNS server in the New York L1 POP.
No routing protocol is running between the access router and the CPE while OSPFv3 is running between theL3 POP routers. The following three points have to be considered:
For the single-network customers, the assigned /64 prefix is directly connected, so directly connectedprefixes have to be redistributed.
•
For the multiple-network customers, a static route is installed by the access router for each /56 prefixassigned. These static routes have to be redistributed into OSPFv3.
•
Summarize prefixes up to the range assigned for this L3 POP router (2600:A02A:30F0::/44) tominimize the size of the routing tables.
•
The relevant configuration that meets these constraints is shown in Example 14-2.
Example 14-2. Access Router OSPFv3 Configuration
interface GigabitEthernet6/1 no ip address ipv6 address 2600:A002:A0C0:F001::2/64 ipv6 enableipv6 ospf 100 area 10
!interface GigabitEthernet6/2 no ip address ipv6 address 2600:A002:A0C0:F002::2/64 ipv6 enableipv6 ospf 100 area 10
Interfaces GigabitEthernet6/1 and 6/2 link the access router NY-10-12-16 to the routers that connect this L3POP to its L2 upstream POP.
Edge and Core
The L2 POPs aggregate the L3 POPs and they do not run any specific features other than OSPFv3 and iBGP.One of the two L2 POP routers that interface with the New York L1 POP is named NY-10-0-1; the other isNY-10-0-2. The relevant routing points in this case are as follows:
Routers NY-10-0-1 and NY-10-0-2 should be set with higher priority to be elected DR and BDR inthat respective order.
•
The OSPFv3 prefixes should be redistributed into iBGP.• The iBGP prefixes should be redistributed into OSPFv3.• A loop avoidance mechanism should be implemented for the redistribution between OSPFv3 andiBGP because of the redundancy in the design.
•
OSPFv3 should summarize the prefixes to the L2 POP boundary (2600:A02A::/32).•
Router NY-10-0-1's IPv6 relevant configuration is shown in Example 14-3.
Example 14-3. L2 POP Router NY-10-0-1 Configuration
hostname NY-10-0-1!ipv6 unicast-routingipv6 cef!interface SRP1/1 no ip directed-broadcast ipv6 address 2600:A002:A000:1::1/64 ipv6 enableipv6 ospf priority 3ipv6 ospf 100 area 0 srp clock-source line a srp clock-source line b no clns route-cache!interface TenGigabitEthernet9/1 no ip address ipv6 address 2600:A002:A000:1100::2/64 ipv6 enable!interface TenGigabitEthernet9/2 no ip address ipv6 address 2600:A002:A000:1200::2/64 ipv6 enable!router bgp 1600 bgp router-id 2.10.0.1 no bgp default ipv4-unicast
The TenGigabitEthernet9/1 and 9/2 interfaces provide the uplink to L1 POP, while the SRP1/1 interfaceprovides the link to the rest of the routers in its L2 POP.
IPv6 prefixes redistributed from iBGP into OSPFv3 are marked with tag 100. When NY-10-0-1 isredistributing the external type 2 prefixes from OSPFv3 into iBGP, the prefixes with tag 100 are dropped.This avoids the loop created by the redistribution between the two routing protocols.
It is interesting to observe that even though NY-10-0-1 already peers with the L1 POP routers over IPv4,RTPCom decided to enable separate peering over IPv6. Another option would have been to simply add theIPv6 address family to the BGP processes and activate the IPv4 neighbors. Despite its apparent redundancy,RTPCom opted for the approach described in Example 14-3 for two reasons:
Limit the impact of one protocol on the other. Terminating the IPv4 peer TCP session will not affectIPv6. Bringing it up would not lead to possible contention between the two protocols.
•
Allow for the possibility that the IPv4 and IPv6 topologies are not congruent.•
RTPCom assumes a certain level of risk because it uses the same routers as IPv4 and IPv6 route reflectors(RRs). The risk is further enhanced because in this design, the RRs are in the forwarding path (a risk assumedfor IPv4, as well). Based on its operational experience with the current infrastructure, RTPCom is comfortablewith this design. It is also studying the option of deploying dedicated RRs in each L1 POP. Considering theredundancy in the RR design, a migration to this alternate design would not imply a downtime for RTPCom'snetwork.
The L1 routers are running OSPFv3 in area 0 for IGP. At the same time, the L1 routers that provide access tothe core for the L1 POP data centers and for the L2 POPs are all part of the iBGP infrastructure shown inFigure 14-10.
Part II: Deployment Case Studies 505
Part II: Deployment Case Studies 505
Figure 14-10. RTPCom Backbone iBGP Design
[View full size image]
The L1 routers providing access for the L1 POP data centers and for the L2 POPs are also acting as routereflectors for the IPv6 service. They in turn peer with the two pairs of second-level Top-RRs in L1-Denverand L1-Atlanta. This hierarchical RR design provides scalability for RTPCom's network core. The prefixes inthe core of the network that are handled by OSPFv3 are redistributed into BGP but not the other way around.Under this design, the relevant configuration elements for NY-0-0-1 are shown in Example 14-4.
Example 14-4. IPv6 Routing Configuration of NY-0-0-1
interface TenGigabitEthernet9/1 no ip address ipv6 address 2600:A002:A000:1100::1/64 ipv6 enable!interface TenGigabitEthernet9/2 no ip address ipv6 address 2600:A002:A000:1200::1/64 ipv6 enable!router bgp 1600
no synchronizationredistribute ospf 100 match external 2
exit-address-family!
The address of the Top-RRs are 2600:A001:0:F000::2 (Atlanta) 2600:A00A:0:F000::2 (Denver).
The Top-RRs shown in Figure 14-10 are dedicated to the IPv6 deployment and were installed in L1-Denverand L1-Atlanta POPs in addition to the existent IPv4 RRs. RTPCom considers the investment in the additionalequipment worthwhile for the benefit of further minimizing the interaction between the IPv4 and IPv6services.
With the above configuration in place, RTPCom established unicast connectivity between its customers andsome services, such as DNS and content hosting/storage, which can already operate. On the other hand,considering the new architecture used for IPv6, RTPCom has the responsibility to control user access basedon its subscription. With the basic IPv6 unicast service, the user can reach other RTPCom customers butshould not have access to the Internet. To enforce this policy, RTPCom applies an IPv6 filter on the subscriberline at the access layer, as shown in Example 14-5.
ipv6 nd other-config-flag!ipv6 access-list Basic-Accessdeny ipv6 any 2600:A000::/28deny ipv6 any 2600:A080::/28permit ipv6 any 2600:A000:/24
Part II: Deployment Case Studies 507
Part II: Deployment Case Studies 507
Access list Basic-Access blocks access to the infrastructure address space (2600:A000::/28 and2600:A080::/28), and allows access to the other RTPCom customers but not beyond that. This filter ismodified based on the services paid for by the user.
Service Rollout Plan
To safeguard the stability of its network, RTPCom intends to enable it for IPv6 unicast connectivity in phases.In the first phase, it will enable IPv6 in the backbone. In the subsequent phases, it will move toward the accesslayer based on customer demands. RTPCom's deployment will precede demand in the major metropolitanareas where the service will be aggressively advertised. The service rollout steps are summarized in Table14-7.
Table 14-7. Unicast Connectivity Service Rollout Checklist
RTPCom Task
Customer Task
1
Enable IPv6 throughout the backbone and the L1 POPs:
Install the IPv6 dedicated TOP-RRs in L1-Denver and L1-Atlanta.
Configure links for dual stack.
Enable OSPFv3.
Configure the iBGP peering between the L1 POP routers and the TOP-RRs.
2
Enable IPv6 in the L2 POPs in the major metropolitan areas:
Configure links for dual stack.
Enable OSPFv3.
Configure the iBGP peering between the L1 POP routers and the L2 POP routers.
Enable IPv6 in the access layer of the L2 POPs in the major metropolitan areas:
Configure links for dual stack.
Enable OSPFv3.
Configure the Basic-Access ACL on the access routers.
Configure the DNS relevant information.
508 Part II: Deployment Case Studies
508 Part II: Deployment Case Studies
Customer requests basic-access service.
3
Provision the customer access link:
Enable the virtual circuit for IPv6.
For a /64 service configure the IPv6 prefix assigned.
For a /56 service request the customer DUID, configure the pool entry and enable DHCP-PD on the virtualcircuit (PVC or VLAN).
Configure the service control ACL Basic-Access.
The customer is provided with the prefixes that will be assigned to him. If a CPE is used, configure it as aDHCPPD client. This might be the responsibility of RTPCom if it manages the CPE.
Steps 2 and 3 can be repeated for other L2 and L3 POPs based on customer demand for service. By the timethe customer is provided access, the DNS and content resources are already installed in the data centers.
DNS and Content Hosting/Storage
The DNS and content hosting/storage resources are installed in the data center of the L1 POPs. The unicastservice enables the IPv6 customers to reach these resources and take advantage of these two services. TheDNS server addresses are provided to users via DHCP. The addresses for the content hosting/storage serversare available on RTPCom's service web pages where subscribers are provided with all the informationnecessary to use these services.
Internet Access
To provide its customer with Internet access service, RTPCom partnered with USInternet, an ISP similar toEuropCom described in Chapter 13. USInternet will provide IPv6 Internet access in addition to its existentIPv4 Internet access offering. It also packages e-mail services together with the Internet access subscription.
Like the other ISPs that provide IPv4 Internet access services to RTPCom's customers, USInternet has tworouters collocated with RTPCom's edge routers in the data centers of the L1 POPs. These two routersaggregate the LNS routers that are dedicated to USInternet. Open Shortest Path First (OSPF) is used forrouting purposes between the LNS, RTPCom edge and ISP edge routers. An interior gateway protocol (IGP)is seen as a simpler solution than the use of eBGP mainly because RTPCom does not need to use its globaladdresses and its autonomous system for the service. RTPCom can be viewed as merely a virtual access layerfor the ISPs it partners with.
In the IPv6 service design, RTPCom plays a more involved role. It now routes the customer traffic throughoutits network, it is responsible for providing addresses to customers and have them globally routed under itsown autonomous system number. In this case, the use of just and IGP is not feasible. For this reasonUSInternet peers with the RTPCom at its L1 POPs through eBGP and the following constraints shape theconfiguration of NY-D-0-3:
Part II: Deployment Case Studies 509
Part II: Deployment Case Studies 509
RTPCom's autonomous system number is 1600.• It peers with USInternet and also with the routers that provide the data center with access to the core.• Dampening is used to minimize external impact on RTPCom's network.• The infrastructure prefixes are not advertised outside RTPCom's network.•
The implementation of these constraints is shown in the configuration Example 14-6.
Example 14-6. IPv6 eBGP Configuration of Router NY-D-0-3
The addresses of the data center RRs are 2600:A002:D0:1100::1 and 2600:A002: D0:2100::1. USInternet'sautonomous system number is 500. The eBGP peering is done through the link-local addresses on the linkbetween RTPCom and the USInternet. Route map Block-Infra is used to stop the infrastructure prefixes2600:A000::/28 and 2600:A080::/28 from being advertised outside RTPCom's network.
Note
The configuration shows the fact that the eBGP peering is done through link-local addresses. Chapter 2, "AnIPv6 Refresher," describes the benefits of using this option. The important thing is to have a set of rules thatmake the link-local addresses of the peer deterministic. The details of how the link-local addresses are beingassigned will not be discussed here because they were presented in a similar example in Chapter 13.
These changes made on the ISP-facing routers open RTPCom's network to the wider IPv6 Internet. All of itscustomers could in principle access the Internet once they have IPv6 access to the RTPCom network.However, the service is controlled with the help of access lists. When a user decides to add Internet access tohis service subscription, the access list applied to its access line is changed from Basic-Access to
510 Part II: Deployment Case Studies
510 Part II: Deployment Case Studies
Internet-Access:
ipv6 access-list Internet-Accessdeny ipv6 any 2600:A000::/28deny ipv6 any 2600:A080::/28permit ipv6 any any
In the first phase of the IPv6 deployment, the services offered are contained within RTPCom's network orwithin a data center on USInternet's premises (e-mail services, for example). This way the services are easierto manage, and the corresponding business model is not complex. The Internet access service is turned on in asubsequent phase of the deployment when interest for it becomes relevant.
The Internet access service rollout steps are summarized in Table 14-8. Basic connectivity is assumed to addInternet access.
Table 14-8. Internet Access Service Rollout Checklist
RTPCom Task
Customer Task
1
Enable connectivity to the ISP:
Configure the IPv6 eBGP peering to the ISP in the L1 POP data centers.
Configure the Internet-Access ACL on the access routers.
Customer requests Internet access service.
2
Provision the customer access link:
Provide basic connectivity if not available.
Replace the service control ACL Basic-Access with the Internet-Access one.
Advanced Services Design and Implementation
With its network enabled to provide IPv6 unicast connectivity, RTPCom can nowincrease and refine its service offering. It can enable its network to support IPv6
Part II: Deployment Case Studies 511
Part II: Deployment Case Studies 511
multicast for content distribution and it can optimize its network to better supporttime-sensitive applications such as voice and video through QoS. Both of thesetechnologies are new to RTPCom because neither has been used with its current IPv4service. They will imply additional costs in terms of deployment, operation andtraining. The business models for the services they enable will most likely see furtherdevelopment and improvement. Nevertheless, RTPCom is committed to building amulti-service-capable network that supports near term opportunities such as TriplePlay as well as longer-term ones that will be created by IPv6.
Content DistributionIPv6 Multicast
RTPCom considers CD as one of the most promising growth strategies. It will imply aone time, minimal charge for enabling its infrastructure to support multicast whilebeing able to easily increase revenue per-access line thereafter. This revenue increaseis developed in collaboration with the content provider by offering more video andmusic premium channel packages. RTPCom expects that the popularity of theseservices will lead to an increase in its customer base.
This scheduled programming is offered through Video and Audio streams, eachmapped to an (S,G) multicast group. The content will use various digital compressionmechanisms that have different bandwidth requirements. The applications deployed byRTPCom and its partner content providers will have the following characteristics(Table 14-9).
Table 14-9. Bandwidth Requirements for Multimedia StreamsContent Type EncodingBandwidthVideo MPEG4 1.5 MbpsVideo MPEG2 2 Mbps (can
be 1 Mbps to15 Mbps)
Audio 20200 Kbps
The bandwidth consumption is particularly relevant at the access line level. Users register to one or multiplemulticast available groups based on their service subscription. The number of channels that can be accessedsimultaneously does depend on the downstream bandwidth available on the access line. RTPCom will shapethe customer traffic based on two profiles: basic and premium. The basic profile is part of the regularsubscription, whereas the premium profile comes at an additional cost. These aspects of bandwidthmanagement are discussed further in the QoS section of this chapter.
Note
Service will have to be advertised under the disclaimer of availability. The program packages offered willhave to be adapted to bandwidth availability. Some DSL (IDSL, for example) services will not be able tosupport some or even all video streams.
512 Part II: Deployment Case Studies
512 Part II: Deployment Case Studies
IPv6 Multicast Service Design
Three major elements are relevant to deploying this service:
The selections made for each of these elements shape the service design.
Content Management
The video and audio programming is managed by the content provider. It is stored on and distributed fromdedicated servers that are located in RTPCom's L1 POP data centers. This approach simplifies the multicastdeployment because all the relevant elements, sources, and listeners are contained within this single domain.
RTPCom assigns to each content provider a set of multicast groups and a prefix for its servers. With thisinformation the content provider puts together a programming mapping that it delivers to RTPCom. As anexample, content provider X was assigned:
2600:A00(L1):00DD:X000::/64 prefix for its servers in each L1 POP• FF3E:X::1FF3E:X::F multicast group addresses•
Table 14-10 shows the way content provider X mapped its programs to the (S,G) groups.
Table 14-10. Programming to (S,G) Mapping for Content Provider X in the New York Area
Content Provider X Programming Profile
Video Programs
Basic National Channels
FF3E:X::1
National 116
2600:A002:00DD:X000::10110F
Premium 1 National Channels
FF3E:X::2
Premium 1.1Premium 1.100
Part II: Deployment Case Studies 513
Part II: Deployment Case Studies 513
2600:A002:00DD:X000::201264
Premium 2 National Channels
FF3E:X::3
Premium 2.1Premium 2.100
2600:A002:00DD:X000::301364
Premium 3 National Channels
FF3E:X::4
Premium 3.1Premium 3.100
2600:A002:00DD:X000::401464
Local Channels
FF3E:X::5
Local Channel 1100
2600:A002:00DD:X000::5015C8
Audio Programs
Basic National Channels
FF3E:X::A
National 116
2600:A002:00DD:X000::1001100F
Premium 1 National Channels
514 Part II: Deployment Case Studies
514 Part II: Deployment Case Studies
FF3E:X::B
Premium 1.1Premium 1.100
2600:A002:00DD:X000::20012064
Premium 2 National Channels
FF3E:X::C
Premium 2.1Premium 2.100
2600:A002:00DD:X000::30013064
Premium 3 National Channels
FF3E:X::D
Premium 3.1Premium 3.100
2600:A002:00DD:X000::40014064
Local Channels
FF3E:X::F
Local Channel 1100
2600:A002:00DD:X000::500150C8
Note
The group addresses used for the multicast service do not have to be globally unique because the service iscontained within RTPCom's domain.
Part II: Deployment Case Studies 515
Part II: Deployment Case Studies 515
Source Specific Multicast (SSM) group addresses are used because of the deployment model selected (see the"Content Transport" subsection).
For redundancy purposes:
Local programs are multicasted simultaneously from two servers within the same L1 POP and withsubsequent source addresses. For example, local program NewYork1 is available on the followingmulticast groups: (2600:A002:00DD:X00::501, FF3E:X::5) and (2600:A002:00DD:X00::502,FF3E:X::5).
Note
User set-top boxes are programmed to prefer the first multicast source. This way all users connectedto the same access router and interested in a given program will join a single (S,G). Otherwise thecontent stream would be duplicated, unnecessarily wasting bandwidth throughout the network. If thefirst source is not available, the second one is selected.
When switching between the primary and the backup source, the subscriber will encounter somedelay as the multicast tree is built and the traffic makes its way to the access layer. RTPCom decidedto configure static joins for all (S,G) in every L2 POP. This way, the portion of the multicast tree leftto be built when a user joins a channel is much smaller and so is the delay in receiving the traffic. Thisis a feasible solution considering the bandwidth available in RTPCom's core network.
•
National programs are multicasted from at least one server in each L1 POP using similar sourceaddresses. For example, national program National1 is available at least on the following multicastgroups: (2600:A001:00DD:X00::101, FF3E:X::1) and (2600:A002:00DD:X00::101, FF3E:X::1).
•
Note
RTPCom decided to install servers in each L1 POP for the national programs to avoid having significantmulticast traffic crossing the backbone. The multicast traffic of these programs is not routed between L1POPs. However, this is not a strict requirement; it represents an optimal way to use the network coreresources.
Gigabit or 10 Gigabit Ethernet links are available between RTPCom's data centers and the content providersto facilitate fast content updates. RTPCom deployed the Cisco MDS9000 series multilayer SAN switches inthe data center for intelligent storage-management. The MDS900 supports IPv6 starting with release 3.0 of theSAN-OS.
Note
Table 14-10 shows an example of program to (S,G) mapping that was built based on the available addressesand some redundancy considerations (dual servers in the same L1 POP for local programs or a server in eachL1 POP for national programs). This approach does not take into consideration the need to load balance themulticast traffic (see Chapter 6, "Providing IPv6 Multicast Services"). RTPCom can make recommendationsto the content providers regarding the server address selections based on an engineering study of load
516 Part II: Deployment Case Studies
516 Part II: Deployment Case Studies
balancing over the multiple paths available in its network.
Content Transport
In the context of this service, the multicast traffic is always flowing from the servers in the data centers to theusers at the access layer. The appropriate and simplest way to deploy this multicast service is in a SourceSpecific Multicast (SSM) model as described in Chapter 6 of this book. Figure 14-11 depicts the operation ofthe service.
Figure 14-11. Multicast Service Operation in RTPCom's Network
The multicast group addresses assigned to the content providers are SSM specific FF3E:X::1FF3E:X::F. Themulticast routing protocol used is PIM-SSM and this implies minimal provisioning requirements. BGP andOSPFv3 provide unicast reachability of the multicast servers.
Part II: Deployment Case Studies 517
Part II: Deployment Case Studies 517
With the content servers hosted by RTPCom, the multicast domain coincides with its network. This makes iteasy to contain the traffic by blocking multicast at the network edges.
Customer Interface
On the access interfaces, MLDv2 is used to manage users joining and leaving the multicast groups. RTPComprovides one or multiple set-top boxes to service subscribers and they are using MLDv2 for their operation.Users can also receive the multicast streams on PCs that have MLDv2-capable players. The program to (S,G)mapping is available to subscribers on a personalized webpage provided by RTPCom along with allinformation pertinent to their profile.
Note
Enforcing the use of MLDv2 provides RTPCom with some level of control over the types of customer devicesused to access the multicast service. At the time of this writing, there are few stacks on the market that supportMLDv2. For this reason, it is likely that RTPCom's customers will be able to request multicast streams onlythrough the set-top boxes it provides. The manufacturer of these devices used a BSD implementation ofMLDv2.
The other important aspect of the customer interface is the method of controlling access only to subscribedservices. RTPCom decided to roll out the service with the help of the MLD access control feature. Customersare charged monthly for the programming package they signed up for. The subscription provides them fullaccess to all video and audio channels in the package. At the same time RTPCom is evaluating the MLD AAAfeature for its potential to simplify the provisioning process. MLD AAA also provides a mechanism to chargethe users at a more granular level in terms of programs accessed or usage time.
IPv6 Multicast Implementation
The first step in the implementation process is to enable IPv6 multicast on all routers in RTPCom's network.This is easily done with the global command ipv6 multicast-routing. It automatically enables multicastforwarding, PIM-SSM and MLDv2 on all IPv6 interfaces. These are most of the protocols and features neededin the deployment.
Note
At layer 2, MLD snooping is a feature that could be enabled to optimize the service on the access layerswitches. In the case of RTPCom, this is not generally applicable since it is using dedicated VLANs for eachsubscriber and there are no listeners connected to aggregation switches.
The second step in implementing the multicast service is that of making the server addresses availablethroughout the network for Reverse Path Forwarding calculation. To advertise the prefixes for this purposefrom the Data Centers to the L2 POPs, the IPv6 multicast address family has to be added to the existent BGPconfiguration. For the New-York data center in Figure 14-9, the relevant addition to the configuration ofrouter NY-D-0-2 is shown in Example 14-7.
518 Part II: Deployment Case Studies
518 Part II: Deployment Case Studies
Example 14-7. IPv6 BGP Multicast Configuration of Router NY-D-0-2
The two neighbors are the TOP-RRs in the Denver and Atlanta L1 POPs. Prefixes2600:A002:00DD:1000::/64, 2600:A002:00DD:2000::/64, and 2600:A002:00DD:3000::/64 are advertised forthe three existent content providers. The same address family is configured on all L1 POP routers that provideaccess to the network backbone, on all RRs and on all L2 POP routers that are the gateways to the networkbackbone. OSPFv3 takes care of advertising the server prefixes the rest of the way down to the access routers.
The various subscription options marketed to the customers have to be reflected into access lists that willcontrol user access to programming. For example, one of the profiles (Premium1) offered by content provider3 to users is shown in Table 14-11. The subscriber has access to all basic national and local programs and allPremium 1 national channels, both audio and video.
Table 14-11. Programming Offered by Content Provider 3 with the Premium1 Package
Content Provider 3Premium1 Programming
Video Programs
Basic National Channels
FF3E:3::1
National 116
2600:A002:00DD:3000::10110F
Premium 1 National Channels
FF3E:3::2
Premium 1.1Premium 1.100
2600:A002:00DD:3000::201264
Part II: Deployment Case Studies 519
Part II: Deployment Case Studies 519
Local Channels
FF3E:3::5
Local Channel 1100
2600:A002:00DD:3000::5015C8
Audio Programs
Basic National Channels
FF3E:3::A
National 116
2600:A002:00DD:3000::1001100F
Premium 1 National Channels
FF3E:3::B
Premium 1.1Premium 1.100
2600:A002:00DD:3000::20012064
Local Channels
FF3E:3::F
Local Channel 1100
2600:A002:00DD:3000::500150C8
The access list reflecting this profile is CP3-Premium1, as shown in Example 14-8.
520 Part II: Deployment Case Studies
520 Part II: Deployment Case Studies
Example 14-8. IPv6 Multicast Access Control Configuration for the CP3-Premium1 Package
ipv6 access-list CP3-Premium1permit ipv6 any host FF3E:3::1permit ipv6 any host FF3E:3::2permit ipv6 any host FF3E:3::5permit ipv6 any host FF3E:3::Apermit ipv6 any host FF3E:3::Bpermit ipv6 any host FF3E:3::Fdeny ipv6 any any
When a user subscribes to the Premium1 package provided by content provider 3, this ACL is used with MLDto control the programs that are available to the user. This is shown in Example 14-9.
Example 14-9. Applying the CP3-Premium1 Profile to a Subscriber
RTPCom configures the ACLs for all profiles on an access router as soon as it receives the first multicastservice request from a subscriber on that router. The profiles are applied to access lines based onsubscriptions.
Note
After IPv6 multicast routing is enabled on the access routers, MLDv2 is already running on all interfaces, so asubscriber can potentially join a multicast group if he knows the (S,G) addresses. For this reason, the defaultstate of the access lines should block MLD joins. After multicast is enabled on an access router a Block-mcastACL denying all traffic should be configured and used with MDL access control on all customer facinginterfaces. When a user subscribes to the multicast service, the access control is modified according to theuser profile.
The steps that are followed in deploying IPv6 multicast are summarized in Table 14-12.
Table 14-12. Multicast Service Rollout Checklist
RTPCom Task
Customer Task
Part II: Deployment Case Studies 521
Part II: Deployment Case Studies 521
1
Install the content servers.
2
Enable IPv6 multicast routing on all routers except the ones that link RTPCom network to the outside world.
3
Add IPv6 multicast address families to the running BGP process on various routers with the exception of theones that link RTPCom network to the outside world.
On the data center routers, add under the IPv6 multicast address family the prefixes of the content servers.
4
Configure MLD access control blocking the join of any (S,G) on all subscriber interfaces.
Customer requests content service within a certain programming profile.
5
Configure all programming profiles on the access router servicing the requestor.
6
Modify the MLD access control on the subscriber line from the default "deny all" to the profile requested.
Attesting to the simplicity of deploying SSM, the minimal configuration shown so far in this section issufficient to provide multicast content to customers. However, the deployment can be further optimized.
One important implementation aspect is that of controlling the multicast domain. RTPCom does not want theoffered multicast service to leave its network, and it does not want other multicast traffic to enter it. Theeasiest way to enforce this policy is to not enable IPv6 multicast processes on the data center routers thatprovide connectivity to the outside world. This approach eliminates in principle the need for other multicasttraffic control measures. Access lists could be used on the outbound links to reinforce this policy. They arerather straightforward because they would block all multicast traffic in or out. However, care has to be takento make sure that link-local multicast traffic is allowed through for basic operation of IPv6. Multicast addressscoping makes it easier to differentiate between link-local and other types of multicast traffic. This simplifiesthe ACLs.
522 Part II: Deployment Case Studies
522 Part II: Deployment Case Studies
Another item to consider in terms of optimizing the deployment is the possible need to improve subscriber'sperception about channel zapping. Channel zapping refers to the rapid switching between channels thatinpatient and bored users are inclined to do. When the customer base is significant, statistically there is a goodchance that most of the popular channels are drawn down to the access layer by registered listeners. In thiscase, there is little delay when switching between channels. In the early phases of the deployment, however, itis likely that a user's channel selection would have to trigger a set of PIM join messages toward an L1 POPdata center, which might imply a longer delay. RTPCom is addressing this issue by "drawing" the multicaststreams to a convenient layer of the network (L2 POPs, for example) with the help of static joins. This willreduce the delay of joining a channel and therefore the delay during channel zapping. This optimization wouldcome at the cost of some backbone bandwidth use.
Quality of Service
Up to this point in the evolution of its network, RTPCom did not concern itself with IP QoS. Despite anaccess layer design that is characterized by clear oversubscription, RTPCom's customers and their typical useof the access service (Internet access over IPv4) do not complain of relevant bandwidth constraints. At thecurrent levels of subscription, the FTTH service is particularly less prone to resource contention. The xDSLservice on the other hand has to be more carefully managed. To customers that have access to ADSL service,RTPCom provides two levels of subscription: a 3-Mbps downstream service and a premium, more expensive5-Mbps service. These access profiles are enforced with the help of ATM-based traffic shaping.
QoS Service Design
With the expansion into newer services, particularly delay-sensitive ones such as VoIP, video, and audio,RTPCom has to reevaluate its network resource management approach. The backbone and aggregation layersare over engineered so they will not require changes. On the other hand, the access layer has to be enabled tohandle the various types of traffic based on their specific requirements. For this reason, RTPCom decided todeploy IP QoS in this part of its network with emphasis on shaping downstream traffic.
The traffic types under consideration in RTPCom's network are listed in Table 14-13.
Table 14-13. Traffic Types in RTPCom Network
Traffic Type
Characteristics
Transport Protocol Type
1
Voice over IP
Low latency, low jitter
IPv4 and IPv6
2
Video and audio content
Part II: Deployment Case Studies 523
Part II: Deployment Case Studies 523
Low latency
IPv6multicast
3
Internet access
Best effort
IPv4 and IPv6
RTPCom will use a DiffServ model to implement its QoS service. Customer traffic will be placed in threeclasses reflecting the types identified in Table 14-13. It will be marked and handled based on its specificrequirements. Table 14-14 presents the QoS classes (see Chapter 5) deployed, their mapping to traffic, andwhere the marking occurs.
Table 14-14. QoS Classes and Traffic Marking
Traffic Type
Class
Where Marking Occurs
1
Voice over IP
EF
Marking done by the phonesno action needed on the part of RTPCom.
2
Video and audio content
AF1
Marking done by the server gateways in the data center.
3
Internet access
BE
Marking done on the link connecting to the ISP.
524 Part II: Deployment Case Studies
524 Part II: Deployment Case Studies
Class-based weighted fair queuing will be used on the access interfaces to control outbound traffic based onclass membership. Fixed bandwidth will be reserved for the content traffic. Two profiles are made available tothe customer:
Basic service reserves 2 Mbps for the multicast traffic.• Premium service reserves 4 Mbps for the multicast traffic.•
The premium service enables the user to receive two or more video streams simultaneously. Each servicecomes with an additional 1 Mbps. This provides RTPCom with another revenue opportunity that is stimulatedby increased demand for content.
QoS Implementation
The first step in the implementation of the service is making sure that the traffic is appropriately marked.RTPCom is responsible for marking the multicast and the Internet traffic. The IPv6 multicast traffic is marked(AF1) inbound on the interfaces that provide access to the content servers in the data centers of L1 POPs.Example 14-10 shows the relevant configuration of NY-D-0-2 which provides access, among others, to theservers of content provider 3 (2600:A002:00DD:3000::/64).)
Example 14-10. QoS Configuration of Content Provider-Facing Router (NY-D-0-2)
class-map match-all Contentmatch protocol ipv6match access-group name Multicast
!policy-map Content class Content
set dscp af11!interface TenGigabitEthernet1/1service-policy input Content
ipv6 address 2600:A002:00DD:3000::1/64 ipv6 enable!ipv6 access-list Multicastpermit ipv6 any FF3E::/16
!
The same policy is applied inbound on all interfaces that connect to content servers throughout RTPCom'snetwork.
In a similar manner, the IPv6 traffic received from USInternet is marked for Best Effort handling. RTPComhas no visibility (or much interest) in the IPv4 traffic which is wrapped inside the PPP and L2TPencapsulations. For this reason, it will not need to mark it, as it will be placed into default class. For the IPv6Internet traffic, the relevant marking policy applied to NY-D-0-3 is shown in Example 14-11.
Example 14-11. QoS Configuration of Internet Access Provider Router (NY-D-0-3)
The next step in implementing QoS is the definition of the traffic classes based on Table 14-14 (next to thesethree classes, one has to remember the existence of the default class), the policy definition and theirapplication to the access lines. The relevant configuration for access router NY-10-12-16 is shown in Example14-12.
Example 14-12. QoS Configuration of Access Router (NY-10-12-16)
The classification is done based on the DSCP bits relying on the fact that all traffic is properly marked by thetime it reaches the access layer. Two policies are shown for the two service profiles: basic and premium. Thecharacteristics of these two policies are summarized in Table 14-15.
Table 14-15. QoS Customer Profiles
Profile
Voice
Content
Internet access
Basic
High-priority 150 Kbps (sufficient for two G.711 calls)
Reserved 2 Mbps (sufficient for one video stream)
The available bandwidth out of the total 3 Mbps
Premium
High-priority 300 Kbps (sufficient for four G.711 calls)
Reserved 4 Mbps (sufficient for two video stream)
The available bandwidth out of the total 5 Mbps
The parent policies shape the overall traffic for the subscriber. They are applied outbound under the PVCconfiguration for xDSL customers or under the subinterface for FTTH customers. Inbound policies can alsobe defined to shape the traffic coming from the customers.
Note
It is important to observe that RTPCom decided not to re-mark traffic that comes from its own customers.This implies a certain level of trust that will be monitored by RTPCom's network operations group.
The steps of deploying QoS in RTPCom's network are summarized in Table 14-16.
Table 14-16. QoS Service Rollout Checklist
RTPCom Task
Part II: Deployment Case Studies 527
Part II: Deployment Case Studies 527
Customer Task
1
Implement the marking policies on the data center routers.
2
Configure the three traffic classes and the corresponding policies for the basic and premium customer profiles.
Customer signs up for access service. It selects either the basic or the premium profile.
4
Apply the appropriate policy outbound on the customer interface.
Operating and Troubleshooting the Network
Now that all services are in effect operational at this point, it is time to take a look at the new RTPComnetwork through the eyes of those who will operate it. In truth, deploying the new services is rather easy;managing them is a different story. Then there is the important aspect of securing the infrastructure. Newprotocols and new services open new doors to possible attacks. These attacks could endanger both IPv4 andIPv6 infrastructures.
Securing the IPv6 Network
Until its expansion into IPv6 under the design presented so far, RTPCom was relatively protected fromsecurity threats. In the case of IPv4 service, RTPCom is not concerned at all with the customer traffic at layer3, it is all encapsulated in PPP and L2TP. RTPCom has minimal provisioning responsibilities and userprotection against attacks, if any is provided by the ISPs. In this context, RTPCom's infrastructure is notexposed to outside traffic and attacks.
The IPv6 service deployment changes completely the service model and with that it changes the securitychallenges. RTPCom is now switching the customer traffic at layer 3 throughout its network. This mode ofoperation exposes its infrastructure to attacks from the Internet as well as attacks sourced by its owncustomers. RTPCom is now responsible for customer provisioning and also for protecting him to a certainextent. The additional services, such as multicast, open the door to multiple types of threats. In this case,RTPCom has to implement a consistent and complete set of security policies that protects the IPv6 services aswell as the IPv4 ones.
RTPCom's main concern is to secure its infrastructure. It will secure its access layer from attacks originatedby its customers and it will secure its Edge from attacks originated by Internet hosts. Another area of concernis the data center in each L1 POP. It contains resources that are vital to the proper operation of variousservices and their management.
528 Part II: Deployment Case Studies
528 Part II: Deployment Case Studies
Securing the Access
RTPCom identified the following security concerns at the access layer:
Attacks on its infrastructure (prefixes 2600:A000::/28 and 2600:A080::/28), attempts to access orimpair network elements
•
Spoofing attacks sourced by its customers using spoofed source addresses• Link-local multicast attacks that would flood access routers with control traffic• Multicast attacks where RTPCom's multicast enabled network is flooded with traffic sourced by itsown customers
•
The important thing to remember is that in RTPCom's case, IPv4 facilitates IPv6 attacks sourced through itscustomers. IPv6 over IPv4 tunnels set up through the IPv4 service are invisible to RTPCom. Such tunnels canprove to be back doors to its IPv6 service for external hackers.
These four threats are addressed through the following policies and their respective implementations:
Block all traffic destined to prefixes 2600:A000::/28 and 2600:A080::/28. This requirement wasalready built in to the two service ACLs used to implement unicast and Internet connectivity:Basic-Service and Internet-Service.
•
To prevent spoofing attacks RTPCom enables uRPF on all customer facing interfaces (orsubinterfaces) as shown in Chapter 9, "Securing IPv6 Networks."
•
The link-local multicast is important to the proper operation of IPv6, so it cannot just be filtered out.A user could impair the access router by bombarding it with Router Solicitations, for example. Therouter can be protected by policing the link-local multicast traffic down to reasonable values.
•
RTPCom is under no obligation to allow its customers to become sources of multicast traffic or totransport their multicast traffic for that matter. RTPCom could filter out customer traffic withmulticast destinations. The ACL might turn out to be rather complex as it will have to permitlink-local multicast as well as some of the well known control-plane multicast groups. A simpler waywould be to disable PIM on all customer interfaces. The later approach does rely on the assumptionthat the CPE router does not need to use PIM to provide multicast service to hosts behind it. This is areasonable assumption for the time being. Considering the limited resources of such devices, it isexpected that they will more likely implement MLD proxy routing rather than PIM.
•
The implementation of these policies is shown in the configuration of NY-10-12-16 in Example 14-13.
Example 14-13. Relevant Security Configuration of Access Router (NY-10-12-16)
ipv6 access-list Access-mcast-DOSpermit icmp any any nd-nspermit ipv6 any host FF02::2
!class-map match-all Access-mcast-DOS-classmatch access-group name Access-mcast-DOS
!policy-map prevent-mcast-attackclass Access-mcast-DOS-classpolice 70000 1500 1500 conform-action transmit exceed-action drop
RTPCom's operations team is also concerned with attack vectors enabled by IPv6's extension headers.Routing headers are a particular concern. They intend to filter out packets with Type 0 (Source Route) routingheader while the Type 2 (MIPv6) RH are allowed for Mobile IPv6 service. This security policy isimplemented by adding the following line under all security ACLs defined:
deny ipv6 any any routing-type 0
RTPCom decided to delay defining policies that address the other extension header threats until those threatsare better understood.
Securing the Edge
At the network edge, RTPCom peers with various ISPs. In their case, link-local attacks are less likely, eventhough they still are possible. On the other hand, attacks in a global scope are significant because of theexposure to the Internet. RTPCom identified the following threats in this part of its network:
Attacks on its infrastructure network elements• Multicast traffic flooding• Link-local attacks in a smaller measure•
These threats were already addressed while implementing various IPv6 services, so it is just a matter ofadding the following final touches:
While implementing the IPv6 Internet access service, RTPCom specifically blocked the infrastructureprefixes from being advertised outside its network. This policy will also be supported with inboundACLs that will specifically block traffic destined to these prefixes.
•
Considering the service model for its multicast service, RTPCom was able to safely disable it on therouters that provide access to the outside world. RTPCom can complement this measure with explicitfilters applied inbound to its edge router interfaces.
•
Despite being less likely, link-local attacks are still possible if the network of its institutional partnerwith whom it is sharing the link was compromised. As a measure of precaution, RTPCom can applythe policing methods used at the access layer.
•
The practical implementation of these policies is straightforward based on the examples already given for theaccess layer.
Securing the Data Center
A third area of security concern in RTPCom's network is the data center that hosts resources critical to itsservice offering. A first level of defense is provided by the perimeter security policies implemented at theaccess and edge layers. On the other hand, these resources require specific protection beyond layer 3, too.
530 Part II: Deployment Case Studies
530 Part II: Deployment Case Studies
To prevent attacks on the data center servers, RTPCom leverages PIX Firewalls upgraded to release 7.0 forIPv6 support. It also deploys the standard host protection policies on each of the servers. For more details onthese mechanisms, see Chapter 9 of this book.
The multicast servers require particular attention because they can be accessed by the content providers. Thisis done over dedicated circuits to an access router connecting to server interfaces different than the ones usedto transmit the multicast traffic. RTPCom has to treat the server as an unsecured resource. For this reason itwill have to control the unicast traffic it receives from the servers. The same ACLs used at the access layercan be applied in this case.
RTPCom will have to continuously update its security policies based on the experiences learned operatingIPv6. The dynamic character of these policies is also driven by the evolution of the existent IPv6 services andthe emergence of new ones with their own security threats.
Managing the Network
Because most of the network elements are dual stack, RTPCom will continue to manage its network mostlyover IPv4. The CiscoWorks NMS currently in use is upgraded to the latest release to leverage its IPv6capabilities. NetFlow will be particularly used to monitor the traffic while Cisco IP SLA will be used forperformance management. NetFlow captured data is sent to the collectors located in the data centers overIPv4. For topology mapping and IPv6 connectivity, the NOC team is testing Nagios. See Chapter 10, "IPv6Network Management," for details on all these tools and their use.
Troubleshooting
After running the IPv4 for several years, RTPCom's network operations team defined clear processes fortroubleshooting and resolving most common problems. IPv6's characteristics and the design of the servicesdeployed require new troubleshooting methodologies that are significantly different from the ones used for theIPv4 services.
Provisioning
One of the rather new aspects of the IPv6 services is RTPCom's responsibility for customer provisioning.After a customer's line was configured based on the services it subscribed to and the physical interface isverified to be up, the first step in gaining access is to acquire the prefixes assigned. The investigation of theproper completion of this step should be at the top of the list when troubleshooting customer connectivity.
For customers that are assigned /64 prefixes, the operator can use the following troubleshooting steps:
Verify the ND cache to see whether link-local control messages are exchanged with a subscriber'shost. For NY-10-12-16 on the ATM1/0.10 interface where the customer is using statelessautoconfiguration:
NY-10-12-16#show ipv6 neighborsIPv6 Address Age Link-layer Addr State Interface2600:A02A:30F0:A01:20D:29FF:FEE1:4DC0 116 000d.29e1.4dc0 STALE ATM1/0.10FE80::20D:29FF:FEE1:4DC0 116 000d.29e1.4dc0 STALE ATM1/0.10
The MAC address of the user is 000d.29E1.4DC0.
•
Part II: Deployment Case Studies 531
Part II: Deployment Case Studies 531
The customer device is verified for the IPv6 autoconfiguration outcome.•
Turn on the following debug: debug ipv6 nd.•
For customers that are assigned /56 prefixes via DHCP-PD, the operator can use the following troubleshootingsteps:
Verify the presence of the CPE in the access router ND cache.•
Verify the operation of DHCP-PD server on ATM1/0.100 interface of NY-10-12-16 that isprovisioned for DHCP-PD:
NY-10-12-16#show ipv6 dhcp interfaceATM1/0.100 is in server mode Using pool: DHCP-Customers Preference value: 0 Hint from client: ignored Rapid-Commit: disabled
The DHCP-PD address pool is DHCP-Customers.
•
Check the DHCP-PD bindings:
NY-10-12-16#show ipv6 dhcp bindingClient: FE80::20B:BFFF:FEAA:7400 (ATM1/0.100) DUID: 00030001000BBFAA7400 Internet access PD: Internet access ID 0x000A0001, T1 302400, T2 483840 Prefix: 2600:A02A:30F0:6400::/56 preferred lifetime 604800, valid lifetime 2592000 expires at May 8 2005 03:05 AM (2591953 seconds)
Prefix assigned via DHCP-PD: 2600:A02A:30F0:6400::/56.
•
If there are no bindings, verify that the proper DUID was configured for this CPE:00030001000BBFAA7400.
•
Turn on the following debug: debug ipv6 dhcp detail.•
Note
Debugs are a last resort troubleshooting tool on production routers because of their impact on the router'sperformance. It is also recommended that the debugging output is sent to the log rather than the console orterminal.
With the prefix assigned to the clients, the only thing left to verify is that they are reachable via ping from theaccess router.
532 Part II: Deployment Case Studies
532 Part II: Deployment Case Studies
Unicast Routing and Forwarding
Troubleshooting IPv6 unicast routing and forwarding is similar to troubleshooting IPv4. Each routing protocolcan be verified independently. The BGP information on router NY-10-0-1 is shown in Example 14-14.
Example 14-14. IPv6 BGP Information on Router NY-10-0-1
NY-10-0-1#show bgp ipv6 summaryBGP router identifier 2.10.0.1, local AS number 1600BGP table version is 73, main routing table version 7372 network entries using 9576 bytes of memory72 path entries using 5184 bytes of memory7 BGP path attribute entries using 392 bytes of memory1 BGP AS-PATH entries using 24 bytes of memory0 BGP route-map cache entries using 0 bytes of memory0 BGP filter-list cache entries using 0 bytes of memoryBGP using 15176 total bytes of memoryBGP activity 73/0 prefixes, 73/0 paths, scan interval 60 secsNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd2600:A002:A000:1100::1 4 1600 11852 11854 73 0 0 1w1d 712600:A002:A000:1200::1 4 1600 11852 11854 73 0 0 1w1d 71
The BGP information can be viewed separately for each address family, as shown in Example 14-15.
Example 14-15. IPv6 BGP Information for the Unicast Address Family on Router NY-10-0-1
NY-10-0-1#show bgp ipv6 unicastBGP table version is 73, local router ID is 2.10.0.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 2600:A010::/28 2600:A002:A000:1100::1 3 0 201 ?*> 2600:A030::/28 2600:A002:A000:1100::1 3 0 201 ?
Similarly, the OSPFv3 process can be verified, as shown in Example 14-16.
Example 14-16. OSPFv3 Information on Router NY-10-0-1
NY-10-0-1#show ipv6 ospf Routing Process "ospfv3 100" with ID 2.10.0.1 It is an autonomous system boundary router Redistributing External Routes from, bgp 1600 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 19392. Checksum Sum 0x2622F47C Number of areas in this router is 1. 1 normal 0 stub 0 nssa Area BACKBONE(0) Number of interfaces in this area is 1 SPF algorithm executed 11 times Number of LSA 27. Checksum Sum 0xF7C7F Number of DCbitless LSA 0
Part II: Deployment Case Studies 533
Part II: Deployment Case Studies 533
Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0
Finally, the routing tables will indicate whether the network is operating properly from that perspective, asshown in Example 14-17.
Example 14-17. IPv6 Routing Table of Router NY-10-0-1
NY-10-0-1#show ipv6 routeIPv6 Routing Table - 77 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - IS-IS L1, I2 - IS-IS L2, Internet access - IS-IS interarea, IS - IS-IS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2B 2600:A010::/28 [200/0] via FE80::20F:34FF:FEB2:FA40 TenGigabitEthernet9/1 via FE80::20F:34FF:FEB2:F980 TenGigabitEthernet9/2
If routing was proven to be consistent with the design but connectivity was not reestablished, it is necessary totroubleshoot the forwarding path. Once again, the methodologies used are similar to the ones used in IPv4.Ping and traceroute for different destinations and from different sources will help narrow down the problem.If a problem router shows no routing issues, its routing information should be matched with the forwardingone. In the case of NY-10-0-1 and prefix 2600:A010::/28, the CEF information is as follows:
The IPv6 forwarding activity can be reviewed with the help of show ipv6 traffic.
Troubleshooting IPv6 unicast routing and forwarding should present no challenge for the experiencedRTPCom NOC team. It can easily leverage the knowledge accumulated operation the IPv4 services.
Multicast Routing and Forwarding
Concept- and experience-wise, the multicast service is new to the RTPCom operations team. In preparationfor this deployment, they went through technology training. Chapter 6 provides the technology detailsalongside a practical example of how troubleshooting is done.
Routers rely on the underlying unicast routing protocols to make multicast control or forwarding planedecisions. For this reason, the first step in troubleshooting multicast should the verification that the network isconverged an operational from the unicast perspective. In the case of the L2 POP routers connecting to thebackbone, it is worth specifically checking the prefixes advertised via BGP for IPv6 multicast (NY-10-0-1), asshown in Example 14-18.
534 Part II: Deployment Case Studies
534 Part II: Deployment Case Studies
Example 14-18. IPv6 BGP Information for the Multicast Address Family on Router NY-10-0-1
NY-10-0-1#show bgp ipv6 multicastBGP table version is 2, local router ID is 2.10.0.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S StaleOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 2600:A002:00DD:1000::/64 2600:A002:A000:1100::1 0 0 200 i
The multicast-specific troubleshooting should start with the verification of the proper operation of theinvolved protocols (MLD and PIM). The relevant information on router NY-10-12-16 is shown in Example14-19.
Example 14-19. MLD Information on Access Router NY-10-12-16
NY-10-12-16#show ipv6 mld interfaceATM1/0.10 is up, line protocol is up Internet address is FE80::20E:FF:FE0E:E/10 MLD is enabled on interface Current MLD version is 2 MLD query interval is 125 seconds MLD querier timeout is 255 seconds MLD max query response time is 10 seconds Last member query response interval is 1 seconds Inbound MLD access group is: MLD activity: 7 joins, 0 leaves MLD querying router is FE80::20E:FF:FE0E:E (this system)NY-10-12-16#show ipv6 pim interfaceInterface PIM Nbr Hello DR Count Intvl PriorGi6/1 on 1 30 1 Address: FE80::20F:35FF:FE3F:441A DR : FE80::20B:60FF:FEA7:D81AGi6/2 on 1 30 1 Address: FE80::20F:35FF:FE3F:3616 DR : FE80::20B:60FF:FEA6:E84A
The PIM activity can be monitored with the help of the command show ipv6 pim traffic. With the controlprotocol shown operational, it is time to move on to verify the multicast topology, as shown in Example14-20.
Example 14-20. PIM Information on Access Router NY-10-12-16
NY-10-12-16#show ipv6 pim topologyIP PIM Multicast Topology TableEntry state: (*/S,G)[RPT/SPT] Protocol Uptime InfoEntry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive, RA - Really Alive, LH - Last Hop, DSS - Do not Signal Sources, RR - Register Received, SR - Sending Registers, E - MSDP External, DCC - Do not Check ConnectedInterface state: Name, Uptime, Fwd, InfoInterface flags: LI - Local Interest, LD - Local Dissinterest, II - Internal Interest, ID - Internal Dissinterest, LH - Last Hop, AS - Assert, AB - Admin Boundary(2600:A002:00DD:1000::101,FF3E:1::1)
Part II: Deployment Case Studies 535
Part II: Deployment Case Studies 535
SSM SPT UP: 1w1d JP: Join(00:00:02) Flags:RPF: GigabitEthernet6/1,FE80::20B:60FF:FEA7:D81A ATM1/0.10 1w1d fwd Join(00:02:45) Gi6/1 1w1d off LI
This output reveals if the multicast group (2600:A002:00DD:1000::101,FF3E:1::1) is seen by NY-10-12-16and if customers subscribed to it (interface ATM1/0.10). The forwarding information in Example 14-21 canfurther be compared with the control-plane one.
Example 14-21. Multicast Forwarding Information on Access Router NT-10-12-16
NY-10-12-16#show ipv6 mfib verboseIP Multicast Forwarding Information BaseEntry Flags: C - Directly Connected, S - Signal, Internet access - Inherit A flag, AR - Activity Required, D - DropForwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per secondOther counts: Total/RPF failed/Other dropsInterface Flags: A - Accept, F - Forward, NS - Negate Signaling IC - Internal Copy, NP - Not platform switched SP - Signal PresentInterface Counts: FS Pkt Count/PS Pkt Count(*,FF00::/8) Flags: C Forwarding: 0/0/0/0, Other: 0/0/0(*,FF30::/15) Flags: D Forwarding: 0/0/0/0, Other: 0/0/0(*,FF3E:1::/32) Flags: D Forwarding: 0/0/0/0, Other: 0/0/0(2600:A002:00DD:1000::101,FF3E:1::1) Flags: Forwarding: 0/0/0/0, Other: 0/0/0 GigabitEthernet0/1 Flags: A ATM1/0.10 Flags: F NS Pkts: 0/0 MAC: 333300000001000F353F441A8100006786DD
This output provides the forwarding statistics, too. For more information on useful multicast troubleshootingcommands, review Chapter 6 of this book.
Debugs are useful tools in troubleshooting the dynamic aspects of problems. However, they should be usedwith care because of their impact on the network equipment resources. Other tools, such as sniffers, can proveuseful in providing the answer to what exactly is happening on a link.
Deployment Lessons
Several interesting conclusions and observations were drawn from the process of designing and deployingIPv6 in RTPCom's network:
RTPCom justifies the significant undertaking to migrate its network to dual stack by the pressing needto enable it for new, scalable services. In particular, the support of multicast services is fundamentalto its strategic plans of offering multimedia content to customers. RTPCom's long-term commitmentto IPv6 made the idea of a one-step migration more palatable, it has to be done so might as well do itright from the start.
•
Although IPv6 has all the features necessary to implement service models similar to the one used forIPv4, RTPCom decided to take advantage of this migration and use a new design. This design
•
536 Part II: Deployment Case Studies
536 Part II: Deployment Case Studies
encompasses all the improvements it wanted it could do on its IPv4 infrastructure and all the elementsnecessary to support new services such as multicast.RTPCom planned the IPv6 adoption well in advance and in that context it purchased and upgradedequipment with IPv6 support in mind. The few scheduled upgrades it went through up to the point ofdeploying IPv6 refreshed enough its network for RTPCom to require minimal investments inupgrades specific for the deployment.
•
User provisioning remains a concern for RTPCom. Although stateless autoconfiguration andDHCP-PD are practical mechanisms, they require a lot of provisioning done on the router. Theproblems could have been eliminated with the use of PPP; however, RTPCom decided to avoid theadditional encapsulation. It also thinks that it can manage this issue in these initial phases of thedeployment but will continue to investigate alternative options.
•
One immediate limitation experienced with this design is the fact that it is difficult to offer more thanone ISP for the Internet access services. In the case of IPv4 the customer traffic is tunneled to theresources (LNS) dedicated to the ISP it selected with its subscription. In the case of IPv6, this isdifficult because all subscribers are using RTPCom's address space. One possible way to solve thisissue is to reserve a few bits in the addressing scheme that would identify the ISP selected by thecustomer. Policy routing would be used to route the traffic to the ISP based on the source address.Nevertheless, the ISPs will have to use prefixes from the address space allocated to RTPCom.
•
RTPCom deployed the multicast service MLD access control for time-to-market reasons. Thismechanism can also be provisioning intensive, but it is considered a manageable problem comparedwith the benefits provided by running the service. As the customer base for the content deliveryservice increases, RTPCom will migrate to MLD AAA to gain granularity in the way it offers service.This will reduce the service provisioning requirements, too.
•
From a design and maintenance perspective, it is beneficial to apply QoS policies to various servicesindependent of the IP version used for transport. In the case of RTPCom this approach was not a goodfit. The existent infrastructure did not have QoS enabled so the IPv6 deployment could not benefitfrom a preexistent QoS service. On the other hand, the suite of IPv6 services is a superset of the IPv4ones, so it is natural to have some IPv6 traffic types (for instance, multicast) treated in a specificmanner.
•
Security became a more prominent concern for RTPCom with the deployment of IPv6. With the newservice model used, RTPCom's network elements are more exposed to attacks. The new services andthe specifics of IPv6 itself create new kinds of vulnerabilities. For these reasons RTPCom makessecurity policies reviews and updates a priority for its operations team.
•
With the IPv6 services successfully deployed in a dual-stack environment, RTPCom's planners are alreadylooking at the next phase in network development. They are planning the migration to an IPv6-only network.In fact, its IPv4 service design positions RTPCom for a rather simple and straightforward migration. ThePPPoE sessions of its IPv4 customers currently encapsulated in L2TP tunnels over IPv4, could beencapsulated in L2TP tunnels over IPv6 instead. As soon as its network management systems can operate inIPv6-only mode and the LNS routers are upgraded to dual stack, RTPCom is ready to completely removeIPv4 from most of its network. However, RTPCom's operations team understands well the importance oftaking time to let changes settle and of getting familiar with the new protocol. For now, there is plenty ofroom to grow in a dual-stack environment.
Chapter 15. Deploying IPv6 in an Enterprise Network
The first part of the book describes the IPv6 technology in a way that enables you to configure and manage itin your own environment. Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network," and Chapter14, "Deploying IPv6 in an IP Service Provider Network," apply this knowledge to examples of IPv6deployments in service provider networks. This chapter focuses on the main steps to integrate IPv6 services inan enterprise network. It is not an exhaustive list because drivers, requirements, and scenarios vary
Part II: Deployment Case Studies 537
Part II: Deployment Case Studies 537
considerably between the various types of enterprises from commercial to industrial market segments,described in RFC 4057, IPv6 Enterprise Network Scenarios. This chapter provides a practical example ofrunning an IPv6 trial on an enterprise infrastructure followed by basic guidelines to go through the process ofdesigning, implementing, and moving the IPv6 services to full production. The topics covered include thefollowing:
Introduction of AC Corporation business and current networking infrastructure• Business drivers to evaluate IPv6 benefits• Starting an IPv6 trial• Planning for IPv6 integration• Moving IPv6 to production• Future evolutions•
This chapter provides solutions to the generic challenges that every enterprise faces when deploying IPv6.
Introducing AC Corporation
With a presence in more than 40 countries, AC Corporation's business is founded oninnovation that delivers the best set of agricultural products and services. Producing anddelivering new products, growing through acquisitions, and licensing goods around theworld has driven AC to deploy Internet connectivity, which enables its employees, partners,and customers to access the data independently of their location and time table.
AC corporate headquarters is located in San Francisco. Business is split between NorthAmerica, Latin and Central America, Asia, Europe, and Africa/Middle East. Each region hasits set of local headquarters, listed in Table 15-1, linked through dedicated circuits fromprovider T-World, which was selected for its global presence.
Table 15-1. AC Headquarters LocationsRegion HeadquartersAfrica and Middle East Johannesburg,
DubaiAsia and Pacific Hong Kong,
Sydney, TokyoEurope Budapest, ParisLatin and Central America Buenos Aires,
Mexico CityNorth America Atlanta,
Montreal, SanFrancisco
T-World also provides the peering for Internet access (IA) in the different regions. Smaller branches andstorage areas take advantage of local broadband access and VPN technologies to connect to their nearestregional headquarters in a cost-effective communications solution. Figure 15-1 shows the global coverage ofthe AC intranet worldwide.
538 Part II: Deployment Case Studies
538 Part II: Deployment Case Studies
Figure 15-1. AC Geographical Network Map
Over the years, e-Commerce became a leading market-coverage expansion strategy for AC. This drives the ITdepartment to continuously monitor emerging technologies, which can add value to the company business.After participating in a couple of IPv6 Forum (http://www.ipv6forum.com) and National IPv6 Task Forces(http://www.ipv6tf.org) events, the IT team decided to evaluate IPv6's potential. The evaluation consideredpossible business drivers for IPv6 integration in the AC corporate network, including competitive advantagesregarding market segments and adoption in regions where AC does business.
AC Network Environment
Today, the AC intranet covers more than 60 locations worldwide, from small branch offices with fewer than10 people to large sites for the main and regional headquarters. One of the IT department's objectives is tostandardize and reduce the variety of technologies, equipment, and architecture deployed globally (becausemanagement and operations are mostly remote). The life span for networking hardware is around three to fiveyears. Support was a key factor in the selection and partnership with T-World provider, which offers a strongpresence worldwide.
AC Network Infrastructure
For years, LAN switching and Ethernet technologiesfrom 10 Mbps to 10 Gbpshave been selected anddeployed by AC at the company headquarters. More recently, IEEE 802.11 (WiFi) was added to theheadquarters, and it is an ongoing deployment in smaller branch offices.
In the early 1990s, IPv4 became the de facto protocol on the AC network, replacing DECnet and IPX. A ClassB address is registered through the Registry, but private address space is also used for services such asrecently deployed IP telephony. Class B addressing and private address space were basically defined with asubnet mask of 255.255.255.0, enabling 254 hosts per subnet. IPv4 address assignment is not really structuredfor aggregation, because of the new locations and acquisitions happening over years.
On routers and switches, the AC IT team certified a set of IP protocols and services that are relevant to itsintranet and must be validated on every configuration where it makes sense. Deviation from those mustclearly be explained and documented. Other features may be locally implemented when required.
Routing
- EIGRP Deployed as internal gateway protocol between all sites with the exception ofbroadband access links, which are configured with static routes. The original criteria that ledto the selection of EIGRP included its simple setup and enhanced feature set, includingmultiprotocol support.
- BGP-4 used at headquarters locations that have an IA peering with T-World.
•
IP features and services
- HSRP Mandatory for LANs with multiple routers or layer 3 switches to provide first-hoprouter redundancy.
- DHCP Mandatory for all locations, to autoconfigure parameters such as IPv4 addresses,DNS server, and so on, on hosts not acting as an application server.
- NAT Required for locations that are configured with private IPv4 addresses but need tocommunicate with the Internet.
- QoS Mandatory for sites where IP telephony is implemented.
- Multicast Optional as an experimental service for audio and video streamingIGMP snoopingand PIM-SM are the minimum services to be set. Limited to a couple of sites.
•
Security and management
- Auto-secure rules Mandatory on all Cisco IOS routers with a WAN connection that dosupport this Cisco IOS feature.
- Firewall Mandatory deployment on all sites that have an Internet peering.
- SNMP On all networking devices with a defined community for read/write access, enablingwell-known network management stations to access that equipment.
- SAA To evaluate the quality of IP services between sites that run IP telephony.
•
The next sections describe the generic topology and differences between an AC headquarters site and a branchoffice.
Headquarters
Although the 12 headquartersmain and regionalare different with respect to their location, number of users,size of the campus and data center, bandwidth, and external connectivity, their infrastructure tends to followthe same design rules.
The campus consists of core layer 3 switchesCisco Catalyst 6500 serieswhich aggregate stackable switchesconfigured as layer 2 or layer 3 switches, such as Cisco Catalyst 3550 and 3750 series (depending on theirintended role). The backbone technology is actually Gigabit Ethernet, but two locations have already beenupgraded to 10 Gigabit Ethernet.
540 Part II: Deployment Case Studies
540 Part II: Deployment Case Studies
Each region connects to the Internet through a peering with T-World to ensure the best regional access. Thisrequires a demilitarized zone (DMZ) to be set on each of these campuses. Deployed routers are either Cisco7200 or, more recently, Cisco 7600 series (which replace the old Cisco 7500 series). WAN accessconnectivity evolves rapidly because technology and pricing are regularly debated and negotiated between ACand T-World. Previously based on OC-3 ATM or SONET/SDH access, they evolved to Gigabit Ethernet.
Figure 15-2 shows an overview of an AC headquarters infrastructure. Areas such as the data center, DMZ,Internet peering, and the intranet WAN are identified.
Figure 15-2. AC Headquarters Network
Branch Offices
The network of small branch offices is made of a couple stackable LAN switches, such as Cisco Catalyst 3550and 3750 series.
Wide-area connectivity is typically done through the Cisco 1700 or 2600 series, with a planned evolution toCisco 1800 and 2800 series. Depending on the branch location and size, the connection to the nearest regionalheadquarters is either achieved through leased lines configured with PPP or through broadbandaccessdepending on its aggressive price point in many countriestaking advantage of the latest VPNtechnology. The sites reachable via a broadband connection get an IPv4 static address from the local ISP andthen are set up with private addresses behind Network Address Translation (NAT). There is no direct IA froma branch office, because security is enforced from the headquarters.
Cisco EIGRP is the routing protocol configured between headquarters and branch offices. The offices linkedthrough a VPN tunnel over their broadband access just have a static route configure toward the IPsec tunnel.
Part II: Deployment Case Studies 541
Part II: Deployment Case Studies 541
Business Drivers to Integrate IPv6 on the AC Network
As is the case with most enterprises, a new technology or protocol is valuable only as long as it helps endusers accomplish their day-to-day tasks. At the same time, it is misguided to wait for a "killer application"(because nobody knows about it before it becomes so successful that everybody runs it). The IT team looksinto IPv6 for its currently available and upcoming products and features as advertised by vendors. It mapsthem to its business needs with the following key objectives in mind:
Learn the technology to understand its impact on network design and operations, identify the benefitsof integrating it, and evaluate the pros and cons. Evaluate the potential cost of deployment. In thisaspect, IPv6 differs from other new network technologies because it impacts all aspects ofnetworking: applications, operating systems, routers and switches, firewall, management, and so on.
•
Identify the actual missing pieces, either from the technology or its implementationif anyto gauge thepotential limitations of its integration and define the rules and timing of deployment. This includesareas such as multihoming, security, and management policies.
•
Ensure AC competitiveness in countries where the deployment of IPv6 is a nationwide initiative. Oneof the successes of the AC Corporation was its early adoption of e-Commerce with partners andcustomers. Fast adoption of IPv6 in some countries must not take AC by surprise and change itsbusiness flow.
•
Take advantage of basic IPv6 features such as larger address space and autoconfiguration for usagessuch as the following:
- Addressing devices with multiple embedded access technologies (Ethernet, WiFi, and soon). Proliferation of networking access technologies on new-generation PCs generates anincrease in the IP address consumption on a campus network configured with DHCP. Deviceswith multiple wireless and fixed networking interfaces are a growing trend. The support teamwas already intervening when a local address pool of IPv4 addresses was not large enough.Such issues are not relevant with IPv6 because the host portion is the 64 bits of the interfaceID.- AC regularly acquires and merges small businesses at a local level. Renumbering is alwaysproblematic when resources must be shared but may have been configured with privateaddresses overlapping with those already used in AC network. The AC IT team wants tounderstand the benefit of IPv6 addressing and renumbering to ease and avoid renumberingconflicts.- Override the setup of private address space and NAT by allocating a global IPv6 addressspace (as explained in draft-ietf-v6ops-nap) to remote locations. Today, those locations mustuse NAT because of the broadband service conditions. This would enable the deployment ofexternally reachable application servers and ease remote support of hosts that are not alwaysworking transparently through NAT, through applications such as remote assistance. The ACIT team would welcome any decrease in support costs that IPv6 could offer.
•
Continue to take advantage of the expanding IP convergence on applications and usage in areas suchas the following:
- TransportationExpanding Internet connectivity in AC trucks and ships to take advantage ofthe networks in motion concept, where a mobile router (for instance, a Cisco MAR 3200)handles the IP mobility of any attached device. This would enable AC to leverage the latestwireless technologies such as 3G, Edge, EVDO, public WiFi, WiMAX, when available.- Video surveillance over IP for remote locations, such as storage areas.- Mobile devices regularly used by employees, such as the new generation of smart phonesand PDAs.- Industrial tracking of goods with the networked evolution of sensors. An example is the useof radio frequency identification (RFID) to monitor and track the goods managed by the ACCorporation.
•
542 Part II: Deployment Case Studies
542 Part II: Deployment Case Studies
Keep the AC infrastructure secure. The AC IT team realizes that many IPv6 over IPv4 tunnels areavailable on dual-stack operating systems. It does not want its network security to be jeopardized byend users or applications that might configure such mechanisms. One might want to forbid anddisable such features, but the AC IT team prefers to understand and manage a technology (not justdisable things that might be bypassed later). They also understand that IPv6 cannot be integrated if itis not at least as secure as IPv4.
•
Learning the Technology
While visiting Japan (refer tohttp://www.v6pc.jp/en/showcase/showroom/temp0107.html andhttp://www.ipv6style.jp/en/action/20030328/index.shtml for details), the CEO saw ademonstration of IPv6. Back from his trip to Asia, he asks the IT team to study theimpact of this new technology. He is interested in the potential application of some ofthe new industrial and consumer devices, such as IP video surveillance cameras andindustrial sensors, as well as the mobility aspect of accessing those resources.
IT team members have participated in a couple of IPv6 events, but no fiscal-year budgethas been planned for any IPv6-related activity. It is decided to open a trial with severaltasks to educate the team about IPv6 in real life and evaluate the integration of thetechnology for deployment of new applications.
The tasks are defined to tackle the following topics:
Configuration and management of IPv6 routers on a single site• Configuration and management of IPv6 hosts on a single site with a defined setof applications
•
Configuration of IPv6 Internet connectivity, including security setup• Expansion of IPv6 between selected AC sites and evaluation of "transition"mechanisms
•
A team leader is chosen at the San Francisco headquarters to manage the project. Initialproject tasks consist of the following:
Provisioning the appropriate equipment
- Routers
Cisco 2821 routersnamed R7 and R5, as shown on Figure 15-3with 256MB of memory and 64 MB of Flash, integrated 10/100/1000 MbpsEthernet interfaces, loaded with Cisco IOS 12.4(2)T AdvancedEnterprise Services image.
IPv6-enabled laptops running Microsoft Windows XP SP1 will be used.Other operating systems can be selected for evaluation, too. If bothMicrosoft Windows XP and Linux need to be validated on a single PC,a user can run Linux Knoppix v3.9, which boots from a CD-ROM.
IPv6 video surveillance camera, such as Panasonic BB-HCM381.- Miscellaneous
Layer 2 switch to connect the equipment.
802.11 access point to validate IPv6 over WiFi operation.Selecting a set of IPv6 applications
Although all current operating systems do support dual stack, it does not meanall applications can benefit from the IPv6 network layer. At the time of thiswriting, several websites (for instance, the 6NET Project, athttp://www.ipv6.org/v6-apps.html193.55.253.34/WP5Apps/Applications.html)provide a list of software, either commercial or experimental, that can beinstalled to evaluate IPv6. The AC IT team will start the testing with thefollowing well-known basic applications:
- Ping Available from all implementations; basic requirement to checkthe connectivity between devices.
- Traceroute Available from all implementations; basic requirement toverify the Internet connectivity.
- Web browser Such as Internet Explorer 6.0 and Mozilla Firefox 1.0.4to access well-known IPv6 websites as well as the IPv6 video camera.
- Multimedia streaming For instance, Videolan Client 0.8.1 as its clientversion allows generating a network stream using IPv6 unicast andmulticast or Microsoft Windows Media & Server version 9.0 or 10.0.
- To meet the objectives of the different tasks and get full IPv6 Internetconnectivity during the trial, an addressing scheme must be selected. Itcan be either a production prefix assigned by a provider, or 6to4prefixes as introduced in Chapter 3, "Delivering IPv6 Unicast Services"(RFC 3056). It is decided to go with 6to4 because of the simplicity ofthe mechanism, no dependency on a service provider because each sitewith a global IPv4 address can configure these prefixes, and the 6to4tunneling is commonly available on various platforms.- The test bed will be expanded later to include ISATAP and manuallyconfigured tunnels; the IPv6 addressing scheme is planned for theseextensions as shown in Table 15-2.
Table 15-2. Addressing Scheme for the IPv6 Trial
Site
6to4Prefix2002::/16
Public IPv4address(82.121.150.27)from R7interface Lo0
SubnetID
InterfaceID
Router R7 6to4 router
Native IPv6 on VLAN2
2002 5279:961B: 0001 Can beEUI-64ormanualorprivacy(hosts)
Router R5 ISATAP 2002 5279:961B: 8888 ISATAPvalue
Routers R7 and R5 configured tunnel link 2002 5279:961B: 0003 Can beEUI-64ormanual
- It is well understood by the AC IT team that this addressing scheme is a temporary solution defined for thistrial. Mechanisms such as 6to4 and ISATAP have inherent limitations (for instance, the lack of IPv6 multicastsupport or the mandatory need to keep an IPv4 address to build the IPv6 address or prefix). This may not besuitable for a production deployment.With all the equipment now ready, the trial can begin with a setup as shown in Figure 15-3. Routers and hostsare attached on a layer 2 switch configured with two VLANs, one for the IPv6 test segment, the other toenable external IPv4 connectivity on the DMZ segment. For security reasons, the initial setup does not permitcommunications between the IPv6 segment and AC internal network.
A first router, a Cisco 2821 (router R7 in Figure 15-3), is set up for a basic IPv6 configuration, as shown inExample 15-1, which consists of the following:
Enabling IPv6 routing on Cisco IOS routers through the ipv6 unicast-routing command, and IPv6Cisco Express Forwarding (CEF).
Note
IPv6 CEF requires IP CEF to be configured to enable fast processing of IPv6 packets.
•
Part II: Deployment Case Studies 545
Part II: Deployment Case Studies 545
An interface GigaEthernet 0/1.2 configured for native IPv6 to act as gateway on VLAN2, where theIPv6 hosts will be attached
•
An interface Tunnel0 configured as a 6to4 tunnel with the IPv6 address of the interface GigaEthernet0/1.2 and IPv4 address of interface Loopback0
•
A static route for 6to4 prefix 2002::/16 pointing on Tunnel0• A default route ::/0 pointing to the 6to4 relay anycast address as documented in Chapter 3•
Example 15-1. IPv6 Configuration of Router R7
R7#show runningip cefipv6 unicast-routingipv6 cef!interface Tunnel0 no ip address no ip redirects ipv6 unnumbered GigabitEthernet0/1.2 tunnel source Loopback0tunnel mode ipv6ip 6to4!interface Loopback0 ip address 82.121.150.27 255.255.255.255!interface GigabitEthernet0/1.2description === IPv6 vlan === encapsulation dot1Q 2ipv6 address 2002:5279:961B:1::/64 eui-64!ipv6 route 2002::/16 Tunnel0ipv6 route ::/0 2002:C058:6301::R7#
Example 15-2 displays the status of the IPv6 interfaces on router R7 and illustrates their IPv6 addresses.
Example 15-2. IPv6 Interface Status on Router R7
R7#show ipv6 interfaceGigabitEthernet0/1.2 is up, line protocol is up Description: === 6to4 vlan ===IPv6 is enabled, link-local address is FE80::20D:BDFF:FE99:F5F9Global unicast address(es):2002:5279:961B:1:20D:BDFF:FE99:F5F9, subnet is 2002:5279:961B:1::/64 [EUI]
Joined group address(es): FF02::1 FF02::2 FF02::1:FF99:F5F9 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 secondsHosts use stateless autoconfig for addresses.Tunnel0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::5279:961B
546 Part II: Deployment Case Studies
546 Part II: Deployment Case Studies
Interface is unnumbered. Using address of GigabitEthernet0/1.2No global unicast address is configured
Joined group address(es): FF02::1 FF02::2 FF02::1:FF79:961B MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is not supported ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses.
Example 15-3 shows how to verify the status of the two static IPv6 routes on router R7.
Example 15-3. IPv6 Routing Status on Router R7
R7#show ipv6 routeIPv6 Routing Table - 6 entriesCodes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2S ::/0 [1/0]
via 2002:C058:6301::1S 2002::/16 [1/0]
via ::, Tunnel0C 2002:5279:961B:1::/64 [0/0] via ::, GigabitEthernet0/1.2L 2002:5279:961B:1:20D:BDFF:FE99:F5F9/128 [0/0] via ::, GigabitEthernet0/1.2L FE80::/10 [0/0] via ::, Null0L FF00::/8 [0/0] via ::, Null0
After setting up IPv6 on router R7, it is now the time to look at an IPv6 host configuration; the example isdone on Microsoft Windows XP SP1. Hosts will get their IPv6 address through the statelessautoconfiguration.
The IPv6 address is built after receiving Router Advertisement messages. There are three IPv6 addresses seton the interface:
Link-local• Global permanent• Global temporary (privacy address as defined in RFC 3041)•
The gateway address is the link-local address of router R7.
The value %4 at the end of the link-local and gateway addresses indicates the index of the interface on the PC.
Netsh CLI is the recommended interface to set and display IPv6 parameters on Windows XP, but ipconfigcommands can also be used, as shown in Example 15-4.
Part II: Deployment Case Studies 547
Part II: Deployment Case Studies 547
Example 15-4. Checking IPv6 Configuration on Microsoft Windows XP
fe80::20d:bdff:fe99:f5f9%4C:\WINDOWS\system32>netshnetsh>interface ipv6netsh interface ipv6>show addressQuerying active state...Interface 4: Wireless Network ConnectionAddr Type DAD State Valid Life Pref. Life Address--------- ---------- ------------ ------------ -----------------------------Temporary Preferred d23h34m50s 23h33m14s 2002:5279:961b:1:f86e:7f1e:e4b3:6aa9Public Preferred 29d23h59m39s 6d23h59m39s 2002:5279:961b:1:202:8aff:fead:a836 Link Preferred infinite infinite fe80::202:8aff:fead:a836
To verify the operation of IPv6, you can use the following:
Ping6 on Windows XP. In Example 15-5, we are pinging a well-known IPv6 Internet website namedwww.ipv6tf.org.
•
Traceroute on Windows XP to the same destination IPv6 host, as shown in Example 15-6.•
Example 15-5. Verifying Operation with IPv6 Ping
C:\>ping6 www.ipv6tf.orgPinging www.ipv6tf.org [2001:7f9:1000:1::103]from 2002:5279:961b:1:f86e:7f1e:e4b3:6aa9 with 32 bytes of data:Reply from 2001:7f9:1000:1::103: bytes=32 time=415msReply from 2001:7f9:1000:1::103: bytes=32 time=379msReply from 2001:7f9:1000:1::103: bytes=32 time=388msReply from 2001:7f9:1000:1::103: bytes=32 time=407msPing statistics for 2001:7f9:1000:1::103: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 379ms, Maximum = 415ms, Average = 397ms
Example 15-6. Verifying Operation with IPv6 Traceroute
C:\>tracert www.ipv6tf.orgTracing route to www.ipv6tf.org [2001:7f9:1000:1::103]over a maximum of 30 hops:
1 2 ms 2 ms 2 ms 2002:5279:961b:1:20d:bdff:fe99:f5f92 161 ms 162 ms 160 ms 3ffe:c15:c002:5000::23 223 ms 223 ms 223 ms 3ffe:c00:8023:29::24 323 ms 323 ms 321 ms us-nyc02a-re1-fe-0-0.ipv6.aorta.net [2001:730:0:4::1]5 317 ms 314 ms 315 ms nl-ams06d-re1-t-9.ipv6.aorta.net [2001:730::1:61]6 314 ms 314 ms 314 ms telianet-gw1.nl.ipv6.aorta.net [2001:730::1:35]
7 397 ms 507 ms 406 ms 2001:6c0:800:2009::28 396 ms 385 ms 384 ms 2001:7f9:1000:1::103Trace complete.
Then, an IPv6 video camera is attached to the IPv6 LAN segment. Bidirectional accessreception of theimages, transmission of zoom commandsof the IPv6 video camera can be demonstrated as shown in Figure15-4.
Figure 15-4. IPv6 Video Camera View and Control
[View full size image]
Other applications such as web browsing or video streaming can now be installed and verified on an IPv6network layer.
Expanding the Test Bed
After successfully being able to communicate between the AC isolated IPv6 LAN segment and the IPv6Internet, the test bed could now be expanded to include the following:
IPv6 hosts located on the AC headquarters campus• An AC DNS server able to register an IPv6 AAAA record• Extension of IPv6 to remote locations•
Domain Name Service (DNS)
The update of DNS service to support IPv6 is one of the mandatory elements of a successful IPv6deployment. Several functions must be considered. First, the DNS servers must be IPv6 capable (for example,a server running BIND 9 release or at least one of its derivatives). The DNS database has to be populated withthe new AAAA record type, which contains the address of the IPv6 hosts. Then (optionally butrecommended), the IPv6 network layer needs to be supported on the DNS servers and clients.
Part II: Deployment Case Studies 549
Part II: Deployment Case Studies 549
DNS servers on the AC network are currently running BIND version 9.3.1, so the task is limited to theconfiguration of IPv6 registers on the DNS server and the registration of the IPv6 resources in the database.
Note
Microsoft Windows XP does not support IPv6 network layer for its DNS Resolver application. The DNSResolver runs over an IPv6 network layer on .NET Server 2003 (and in the future on the LongHorn release).
When querying DNS, an application might receive both IPv4 (A) and IPv6 (AAAA) records, which leaves thedecision to prefer one over the other to the operating system. Failure to resolve DNS for one stack canpotentially lead to a fallback to the other IP stack. Experience shows that it does not always work (perhapsbecause of a stack or a network connectivity issue). For this reason, AC would start the deployment with aspecific naming for IPv6 resources: www.ipv6.ac.com to avoid impacting end users. It is also a way to controlthe deployment of IPv6 applications, because, generally, names are preferred over IPv6 addresses by endusers accessing a given resource. It is expected that .ipv6 can be removed in the future.
Example 15-7 illustrates a DNS record for an IPv6 news website, showing the following:
AAAA record for ipv6.hs247.com• A plus AAAA records for www.hs247.com• A record for ipv4.hs247.com•
Example 15-7. DNS Lookup to Resolve a Name and IPv6 Address
The first step of the trial is to enable IPv6 connectivity to the Internet for hosts located on an isolated segment.The next step is to evaluate IPv6 communications within the headquarters campus. The population of endusers selected to participate in this evaluation is too small to justify an upgrade of all layer 3 switches on thecampus. Nevertheless, to meet the objectives of its increasing number of users, the AC IT team set upon theintraneta second Cisco 2821 (R5)shown in Figure 15-5as an ISATAP router for use by internal AC users withmanual configuration of the service. It is decided not to declare the ISATAP router into DNS to avoid thepotential use of IPv6 through automatic tunneling. The IT team intends to keep the support costs and the testparticipants under control.
Figure 15-5. ISATAP Router in the AC Network
Example 15-8 shows the minimum required setting on router R5 for an ISATAP tunnel.
Example 15-8. ISATAP Configuration on Router R5
R5#ip cefipv6 unicast-routingipv6 cef!interface Tunnel100no ip addressno ip redirects ipv6 address 2002:5279:961B:8888::/64 eui-64no ipv6 nd suppress-ratunnel source Loopback0
tunnel mode ipv6ip isatap!interface Loopback0 ip address 10.151.151.7 255.255.255.255
Part II: Deployment Case Studies 551
Part II: Deployment Case Studies 551
!
After configuring router R5, you can check the status of interface Tunnel100, which is the ISATAP tunnel, asshown in Example 15-9.
Example 15-9. Displaying ISATAP Tunnel Status
R5# show ipv6 interface Tunnel100Tunnel100 is up, line protocol is upIPv6 is enabled, link-local address is FE80::5EFE:5279:961BGlobal unicast address(es):
2002:5279:961B:8888:0:5EFE:5279:961B, subnet is2002:5279:961B:8888::/64 [EUI] Joined group address(es): FF02::1 FF02::2 FF02::D FF02::16 FF02::1:FF79:961B MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is not supported ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements live for 1800 secondsHosts use stateless autoconfig for addresses.
After an ISATAP router is operational, you can enable ISATAP on Windows XP. You do so with thefollowing command, which manually enables the use of ISATAP:
C:\>netsh interface ipv6 isatap set router 10.151.151.7
When executed on PC 10.149.2.60, you can check the ISATAP interface status (interface #2) as shown inExample 15-10.
Example 15-10. ISATAP Status on Windows XP
C:\>ipv6 if 2Interface 2: Automatic Tunneling Pseudo-Interface{48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE} does not use Neighbor Discovery uses Router Discovery routing preference 1EUI-64 embedded IPv4 address: 10.149.2.60
router link-layer address: 10.151.151.7 preferred global 2002:5279:961B:8888:0:5efe:10.149.2.60, life 16m14s (public) preferred link-local fe80::5efe:10.149.2.60, life infinite link MTU 1480 (true link MTU 65515) current hop limit 64 reachable time 31500ms (base 30000ms) retransmission interval 1000ms DAD transmits 0
552 Part II: Deployment Case Studies
552 Part II: Deployment Case Studies
C:\>
Note
This ISATAP router can later benefit the remote users connecting to the headquarters sites via VPN using theCisco VPN Client 4.x. They can set up an ISATAP tunnel to R5 over the established IPv4 VPN (see Chapter7, "VPN IPv6 Architecture and Services").
IPv6 Internet-to-Campus Connectivity
After the ISATAP router R5 is operational, the overall campus has local IPv6 connectivity. To complete thetrial and enable the connection with the IPv6 Internet through the 6to4 router (R7), additional configurationsare required:
To enable the communication between routers R7 and R5, which are on different sides of anIPv4-only firewall, the firewall must be configured to enable protocol 41 forwarding between theIPv4 addresses of both router R5 and R7. This particular setup blocks any other tunneled IPv6connection not going through these two IT-controlled routers.
Note
Configuration of the firewall is not shown because it depends on the type of device installed toperform the functions. Moreover, this configuration involves only IPv4-related settings.
•
After the IPv4-only firewall is set up to allow protocol 41 to go through, a tunnel can be manuallyconfigured between R5 and R7 routers, as shown in Figure 15-6. This provides the campus withaccess to the IPv6 Internet. Optionally, a dynamic routing protocol can be enabled to pass IPv6routing information through the tunnel (for example, RIPng).
Figure 15-6. Expansion of the IPv6 Test Bed
[View full size image]
•
Part II: Deployment Case Studies 553
Part II: Deployment Case Studies 553
The manually configured tunnel setup between routers R7 and R5 is shown on interfaces Tunnel10 inExample 15-11. RIPng is also enabled on the interfaces to exchange routing information.
Example 15-11. Manually IPv6 Configured Tunnel Setup on Routers R5 and R7
The IPv6 access to AC must be fully secured before opening the IPv6 IA to its users. Generally, thefirewall does not inspect IP in IP traffic. It requires the IPv6 traffic to be filtered on R5 or R7 before itcan be encapsulated in the manually configured tunnel. This can be done by setting reflexive ACLs orthe via the Cisco IOS Firewall IPv6 feature set (see Chapter 9, "Securing IPv6 Networks"). Note that6to4 tunnels can only be secured, by setting IPv4 IPsec between 6to4 routers, if used in a closeenvironment that does not reach the IPv6 Internet through 6to4 relay.
•
554 Part II: Deployment Case Studies
554 Part II: Deployment Case Studies
Expanding the IPv6 Intranet Testing
With the ISATAP router up and running, all sites may now have active IPv6 end users. Nevertheless, thesolution is not optimal for the remote sites because it creates a single IPv6 subnet that connects all IPv6 hostsin an overlay of the IPv4 infrastructure. An easy alternative to expand the test bed to remote locations is to setmanually configured tunnels between their WAN gateway routers and the headquarters ones. For instance:
One remote site is linked to the San Francisco headquarters through a leased line. It is an opportunityto test a dual-stack configuration over a PPP connection. Routers on both ends of the links areupgraded to the same Cisco IOS release as routers R5 and R7, and then IPv6 is enabled between sites.
•
A remote site with broadband access will have a manually configured tunnel that runs over the VPNIPsec-encrypted tunnel. An alternative is to create a secure 6to4 tunnel (see Chapter 3), but that wouldmean the site is not part of the intranet because the headquarters' 6to4 router (R7) is on the DMZ.
•
Because the final IPv6 test network is limited to those two to three sites, static routes are goodenough. Nevertheless, it is easy to turn on a routing protocol such as RIPng over the tunnels, as shownbetween R5 and R7 in the previous configuration.
•
Lessons from the Trial
The main conclusion at the end of the trial is that the basic IPv6 setup appears to be an easy task as long as allthe prerequisite releases of software are installed. At the same time, it is clear that there is a need for moreIPv6-capable applications. Evaluated operating system releases have a really limited set of applications able torun over an IPv6 network layer. It is an expected that the Microsoft next-generation operating system andLinux evolutions will result in all applications becoming more IP version agnostic. Based on the technologyevaluation, the following guidelines were set:
Better to focus on IPv6 deployment by beginning with one or more applications that can run overIPv6 and is either benefiting to the enterprise business or could lower the cost of support when runover IPv6.
•
AC will set criteria on acquisitions of new or updated applications as well as networking equipment.Products must integrate the support of IPv6, although it may not be deployed in the short term.
•
Transition mechanisms such as 6to4 or ISATAP are easy to configure but they have some inherentlimitations in terms of feature capabilities:
- Do not correspond to an IPv6 global prefix as allocated by the Registries and are notoptimized for routing on production IPv6 Internet- No support for IPv6 multicast- Require an IPv4 address in case of ISATAP to set the interface ID value- Add the tunnel overhead and may not deliver the best performances for communications- Make troubleshooting more complex as an operator needs to understand both IPv4 and IPv6topology to identify a problem
•
For the preceding reasons, summarized in Table 15-3, on a long-term basis AC will prefer a dual-stackinfrastructure when cost is not an issue.
Table 15-3. Lessons Learned from Trialing Tunnels
6to4
ISATAP
Part II: Deployment Case Studies 555
Part II: Deployment Case Studies 555
Scope
WAN
Campus
Traffic impact
Return path through 6to4 relay may not be optimum
Dependent of the campus IPv4 infrastructure
Address format
Specific prefix
Specific interface ID
Renumbering when moving to production
Yes, prefix
Yes, interface ID
Multicast support
No
No
Security
Can be secured by IPv4 IPsec when not using a 6to4 relay
Follows host security
Moving IPv6 to Production
At the end of the 1980s, enterprises were mostly running IPv4 as a network management protocol inconjunction with SNMP, a common feature on networking devices and network management stations. Realproduction traffic, however, was flowing over AppleTalk, DECnet, IPX, or SNA. Then, the integration of afree TCP/IP stack on most operating systems accompanied by a large set of applications, including theemergence of the World Wide Web, favored a transition from these legacy protocols to IPv4. Today, IPv4 andthe Internet are deeply part of our life and not anymore reserved to IT departments. New generations ofappliances appear every year that implement IP. The importance of the protocol makes it critical forbusinesses to stay in sync with the rapid evolution of the technology. An upgrade of the IP protocol is asignificant evolutionary step, so it has to be addressed accordingly. AC has to evaluate the costs of versus theurgency and benefits of such an upgrade.
556 Part II: Deployment Case Studies
556 Part II: Deployment Case Studies
Cost Analysis
Regardless of the AC network's age, the full integration of IPv6 services means that an inventorysimilar towhat was done for Y2Kof the existing equipment must be performed to evaluate the cost of the project. Thisprocess would help plan the associated budget and project timescale. In some cases, an enterprise clearlyidentifies a need for IPv6 to support a given application, as described later in this section. But it is expectedthat in many cases the integration of this new IP version will occur over years as the networking environmentgets upgraded to the newest generation of products and applications. The cost analysis of such a project mustinclude the upgrade expenses for elements such as hosts and network devices, as described in Chapter 12,"Generic Deployment Planning Guidelines." The results of the inventory drive an AC policy to require allnew acquisitions to be IPv6 capable or to have a public roadmap for it.
Operations
As introduced in Chapter 12, the move of IPv6 to production impacts the operational team, who mustcomplete the following:
Training An AC team leader and two senior engineers will subscribe to a Cisco IPv6 class through alearning partner. Upon completion, they proceed to teach their colleagues. As a Cisco customer withCCO Learning Connection access, AC people get access to the available e-Learning Cisco IOS IPv6class.
•
Negotiation with T-World Fees associated with IPv6 services vary between Internet service provideras for IPv4. Because AC was T-World's first customer to request a worldwide IPv6 deployment, theynegotiated a free offering for the next two years based on the agreement that T-World can use AC as acustomer reference.
•
Then AC could start the full integration of IPv6 with the setup of the networking equipment as soon as thedesign phase is complete. Configuration will be done remotely and gradually, depending on the readiness ofthe devices. When a local intervention is required, IPv6 will be planned in conjunction with another siteintervention. Global deployment of IPv6 hosts will be complete for several years because new version ofoperating systems and applications must be certified by the IT department. Nevertheless, by mandating theIPv6 support through new acquisitions or development of applications, the cost of the upgrade could beintegrated in the next rollout of desktops and laptops, once again decreasing the cost of deployment.
Design and Setup
Lessons learned during the trial period were positive enough to get the managementapproval for an IPv6 integration project. As with any networking project, there areseveral steps to go through before advertising IPv6 as a production service. One initialstep is to develop a design of the IPv6 intranet and issue AC policies before the startof the rollout. This section does not indicate the amount of time required to achieveeach phase. It is assumed that several months would be needed, depending onparameters such as IT department workload, cost control, and the availability of stableand affordable commercial solutions. Mandatory steps include the following:
Definition of the IPv6 addressing scheme and rules• Guidelines for IPv6 integration on existing intranet, including
- Selection of routing protocol(s)- High-availability options on AC LANs
•
Part II: Deployment Case Studies 557
Part II: Deployment Case Studies 557
Planning of IPv6 services to be set up, compliant with the requirementsdefined by the AC IT department:
- Security Must provide a level of security equivalent with to that forIPv4 from day one for every site that is updated. Must also cope withthe specifics of IPv6, including new services such as IP mobility.
- Network management Integration of the IPv6 configuration andtraffic management in the actual IPv4 NMS system is mandatory.Optionally, SNMP and management applications could run over anIPv6 network layer. Networking devices must support ManagementInformation Bases (MIBs) for IPv6 statistics.
- Multicast IPv4 multicast is an experimental service on the ACnetwork. The operational side of dealing with multicast through NATto cover the remote site was seen as too complex. IPv6 multicastservice should become the de facto production service for multicast.AC expects to decrease the cost of operations and ease the fulldeployment of multicast.
- Mobility This is a new service for AC. It will start as experimental.The purpose is to enable the deployment of new appliances andexpand Internet connectivity in the AC fleet of vehicles.
- QoS The goal is to ensure optimal operation of applicationsindependently of the network layer protocol. Same QoS rules mustapply to both IP versions.
•
Note
Because of the large number of options when designing an enterprise or commercialintranet, this section is not an exhaustive list of actions. You should tailor theseguidelines to your own environment and add any necessary additional steps.
IPv6 Addressing
Similar to the IPv4 design, one of the first actions is to define an address scheme. Thenext section introduces the AC plans for prefix and host address assignments.
Prefix-Assignment Scheme
At the time of this writing, the Registries only allocate an IPv6 prefixa ::/32 or greateraddress spaceto ISPs, NRNs, and government agencies, meaning an enterprise mustget an IPv6 prefix (::/48) from its ISP. Part of the IPv6negotiation with T-World wasthe subscription of a prefix for AC; it is assigned 2001:0DB8:ACAC::/48.
The remaining 16 bits' significance has to be defined. They will be partitioned basedon the scheme shown in Table 15-4.
558 Part II: Deployment Case Studies
558 Part II: Deployment Case Studies
Table 15-4. AC Corporation IPv6 Addressing Scheme
Region ID (3 Bits)
Headquartersand AttachedSites (5 Bits)
LinkID perSite (8Bits)
North America (000) San Francisco(00000)
Atlanta (00100)
Montreal(10000)
00-FF
Europe (001) Budapest(00000)
Paris (00100)
00-FF
Asia-Pacific (010) Hong Kong(00000)
Sydney (00100)
Tokyo (10000)
00-FF
Africa and Middle East (011) Dubai (00000)
Johannesburg(00100)
00-FF
Latin and Central America (100) Buenos Aires(00000)
Mexico City(00100)
00-FF
Reserved for future (101111) Reserved forfuture
00-FF
Address Configuration Rules
Although IPv6 specifications define the support of stateful and stateless autoconfiguration mechanisms toassign an IPv6 address to a host interface, as discussed in Chapter 3, most of the host implementations onlysupport the stateless option. This means there are only two modes of IPv6 address allocation that can bepractically considered for a deployment: manual or stateless.
With the prefix provided, the host needs an interface ID. There are several ways in which the interface ID canbe selected. It can be manually configured, it can be derived from the MAC address following the EUI-64rules, or it can be built using the "privacy extensions" defined in RFC 3041 (as described in Chapter 2, "AnIPv6 Refresher"). Remember that an IPv6 host interface may have a set of unicast addresses in use.
The following guidelines were established for selecting interface IDs in the AC IPv6 network:
DNS servers and network management stations get an IPv6 address manually configured. Forresources not to be known from the Internet (for instance, NMSs), it is recommended to not set anobvious interface ID, such as x::1/128, to avoid easy distributed denial-of-service (DDoS) attacks.
•
Application servers get an IPv6 interface ID manually configured unless they support Dynamic DNS,in which later case they can use stateless autoconfiguration with EUI-64.
•
Part II: Deployment Case Studies 559
Part II: Deployment Case Studies 559
Networking devices can use EUI-64 as the interface ID, but at least one interfacetypicallyloopbackmust have an address with the interface ID manually configured for network managementpurposes. This eliminates the device reachability dependency on its hardware information. Acomplete swap of hardware can take place in case of failure, and the device will remain reachable bythe NMS after the device configuration is reloaded.
•
On point-to-point links, the 2001:0DB8:ACAC:nnnn::/64 prefix will be preferred to keep theconfiguration simple and aligned with the IPv6 address architecture (RFC 3513). For moreinformation, refer also to RFC 3627.
•
Hosts actually configured through DHCP for IPv4 get their IPv6 address through statelessautoconfiguration.
•
Hosts supporting "privacy extensions" interface IDs must have a default value of 24 hours. Privacyextensions is a new capability, and its impact on traceability and managing DDoS threats may not befully understood. Nevertheless, the basic policies related to the use of privacy extensions are asfollows:
- No host ACL should be used unless it only permits a specific IPv6 address and deny all.- A user-tracking network management application is required to identify the hosts.
•
Dual-Stack Deployment
The initial trial lessons and list of identified services AC intends to run over IPv6 led the team to choose adual-stack approach. After running a network inventory, the needs to upgrade some hardware and softwarereleases are known by the AC IT team and adequately budgeted in association with other programs for thenext fiscal year.
On campus LANs, layer 3 switches will be configured to run native IPv6for instance, Catalyst 6500 serieswith supervisor engine 720 and native Cisco IOS 12.2(18)SXE release or Catalyst 3750 series and Cisco IOS12.2(25)SEA release as minimum.
Remote sites connected through leased lines will get their router software releases updated to supportdual-stack operation. To reduce the labor costs, this upgrade will be associated with the update program to theCisco 1800 and 2800 series. The minimum release to match AC service needs is Cisco IOS 12.4(2)T. Table15-5 summarizes the platform/IOS mapping targeted for the deployment.
Table 15-5. Platforms and Minimum Cisco IOS Software Used in the IPv6 Deployment
Network Location
Hardware Platform
Software(IOS)
Main campus
Catalyst 6500
SUP-720
Cisco 3750
12.2(18)SXE
12.2(25)SEA
560 Part II: Deployment Case Studies
560 Part II: Deployment Case Studies
Remote sites' WAN router
Cisco 1800
Cisco 2800
12.4(2)T
12.4(2)T
Remote sites connected via broadband access will have an IPv6-configured tunnel setup. Because IPv4 is theprimary service and is already protected via the VPN tunnel between site-to-site routers to one of the main ACcampuses, there is no local access security concern about adding IPv6 services. The configured tunnel allowsthe allocation of global IPv6 prefixes in accordance with AC rules. The addition of a global IPv6 prefix tothose sites that are configured with a single static IPv4 address on the WAN link and private address on LANease the potential deployment of multicast and peer-to-peer applications. The IPv6 manually configuredtunnels do not have to be terminated on the same device as the IPv4 IPsec VPN tunnel. When possible, theywill get terminated on a Catalyst 6500 supervisor engine 720 that does support this tunnel mechanism inhardware.
Routing Protocols
To keep the learning curve and operational process at a minimal level, similar routing protocols will bedeployed for IPv6 and IPv4, meaning EIGRP for IGP and MP-BGP4 for peering with T-World (see Chapter4, "IPv6 Routing Protocols," for details and configuration on these protocols).
In the final phase of the project, the entire network is converted to dual stack. In an effort to keep theoperational and management tasks as simple as possible, it is decided to align the IPv4 and IPv6 topologiesfor all routers and links in the network. The routing protocol parameters are configured to get all trafficflowing through similar paths. This decision is taken to ease the operational support, to avoid complextroubleshooting where communications between two nodes could work for a given IP version but not the otherbecause different paths followed through the network.
First-Hop Router Redundancy
IPv6 hosts on a broadcast link learn about the presence of one or more gateways by receiving RouterAdvertisements (RAs) sent using the IPv6 Neighbor Discovery Protocol (see Chapter 2). The RouterAdvertisements are periodically sent via multicast at a rate high enough to ensure that hosts learn about therouters in the span of a few minutes, which therefore removes the need to set a "default gateway" (as in thecase of IPv4). The selection of a given router depends on the host IPv6 stack implementation. On the otherhand, by default, RAs are not sent frequently enough to rely on the absence of the router advertisement todetect router failures. Therefore, there is a need for tuning the ND process and leveraging additional protocolsto improve the availability of first-hop routers:
Tuning ICMPv6 and Neighbor Discovery• Configuring Default Router Selection• Enabling one of the first-hop redundancy router protocols: Cisco Hot Standby Router Protocol(HSRP), Cisco Gateway Load Balancing Protocol (GLBP), or Virtual Router Redundancy Protocol(VRRP)
•
Part II: Deployment Case Studies 561
Part II: Deployment Case Studies 561
Note
IETF Mobile IPv6 specification (RFC 3775) reduces the minimum RA interval significantly.
Tuning Neighbor Discovery
Neighbor Discovery (Chapter 2) includes a mechanism called Neighbor Unreachability Detection (NUD),which is used to detect the failure of a neighbor node (router or host) or the forwarding path to a neighbor.This is done by sending Neighbor Solicitation messages to the neighbor node. To reduce the overhead ofsending Neighbor Solicitations, the messages are only sent to neighbors to whom the node is actively sendingtraffic and only after there has been no positive indication that the router is up for a period of time. Using thedefault parameteripv6 nd reachable-timeit will take a host about 30 seconds to learn that a router isunreachable before it will switch to another router. This delay would be noticeable to users and can causesome transport protocol implementations to time out.
In the absence of any other first-hop router redundancy protocol, such as Cisco HSRP, tuning of NUD is auseful alternative. Setting of the ipv6 nd reachable-time parameter to a more aggressive value allows thespeedup of the switchover time, but it has the downside of significantly increasing the overhead of ND traffic.This would be specially noticeable when there are hundreds of hosts on a link (because they all would try todetermine the reachability of their gateways). A good tradeoff between potential ND bursts and switchovertimes seems to be 15 seconds versus the 30-second default value.
Example 15-12 shows how to configure the ND Reachable timer on a router's interface.
There is no reason to tune other IPv6 ND timers to achieve first-hop router redundancy.
On an AC network, this will only be configured when Cisco HSRP for IPv6 or other first-hop redundancymechanisms are not available on layer 3 switches or routers; otherwise, default value are kept.
Configuring Default Router Selection
Because IPv6 ND did not initially specify a way to set a default router, IPv6 hosts learn about all routersavailable on a LAN through the ND RA mechanism. It is the responsibility of the hosts to maintain a defaultrouter list from which one is selected for forwarding traffic to off-link destinations. The selection for adestination is then cached, and the implementation of selecting gateways can be round robin or "always thesame."
562 Part II: Deployment Case Studies
562 Part II: Deployment Case Studies
This is simple and works well in most cases, but in some situations, it is suboptimal:
Some form of traffic engineering is desired (for example, when two routers on a link provideequivalent, but not equal-cost, routing). Policy may dictate that one is preferred. These are tworelevant examples:
- "Accidentally" deploying a new router before it has been fully configured could lead tohosts adopting it as a default router and traffic being black-holed. Management may want toindicate that some routers are more preferred than others.- Multiple routers that route to distinct sets of prefixes. Redirects (sent by nonoptimal routersfor a destination) mean that hosts can choose any router and the system will work. But trafficpatterns may mean that choosing one of the routers would lead to considerably fewerredirects.
•
The IPv6 router selection IETF Internet Draft (draft-ietf-ipv6-router-selection) defines two optionalextensions to ND RA messages:
- Default Router Preferences (DRP) A coarse preference metric for default routers. This is anextremely simple extensionjust the definition of a few unused bits in existing RA messages toaddress the first example mentioned above.
- More-Specific Routes (MSR) An option to allow routers to specify routes more specific thanthe default route, together with a lifetime; a coarse preference metric for each such routes toaddress the second case mentioned above.
•
Both are backward compatible with the existing RA mechanism and host behavior. DRP can be implementedwithout implementing MSR.
Note
At the time of this writing, Cisco IOS software only implements the DRP function. On the host side, thefeature is also supported on Microsoft Windows XP and .NET Server 2003.
By default, Cisco IOS routers send RAs with a preference of medium. The no version of the command returnsthe configuration to the default value. On AC LANs, the routers managed by the IT will be set to high toavoid basic misconfiguration in case a new router is added to a segment.
Example 15-13 shows router preference set up to high on a router's interface loaded with Cisco IOS Release12.4(2)T.
Example 15-14 shows the command to check the configuration of both ND reachable timer and routerpreference.
Example 15-14. Display of ND Reachable Timer and Router Preference Setup
R1#show ipv6 inter e0/0Ethernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:1F00 Global unicast address(es): 2001:DB8:ACAC:10:A8BB:CCFF:FE00:1F00, subnet is 2001:DB8:ACAC:10::/64 [EUI] Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:1F00 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1ND reachable time is 15000 millisecondsND advertised default router preference is High
Enabling Cisco HSRP for IPv6
A first-hop redundancy protocol, such as Cisco HSRP, can provide a much faster switchover to an alternaterouter than can be obtained using standard ND procedures. Using HSRP, a backup router can take over for afailed default router in about 10 seconds using default parameters, or less than 1 second if millisecond HSRPtimers are used. This is done without any interaction with the hosts, and with a minimum amount of HSRPtraffic.
Most IPv4 hosts have a single router IP address configured as the default gateway. When Cisco HSRP is setup, the HSRP virtual IPv4 address is configured as the hosts' default gateway rather than the router IP address.
Most changes to HSRP for IPv6 are to the ND functions (Neighbor Advertisement, Router Advertisement,and ICMPv6 redirects).
An HSRP IPv6 group has a virtual MAC addressblock different from the Cisco HSRP one for IPv4that isderived from the HSRP group number. A virtual IPv6 link-local address is also derived, by default, from theHSRP virtual MAC address.
Note
The Cisco HSRP for IPv6 virtual MAC address block0005.73A0.0000 through 0005.73A0.0FFFUDP portnumber 2029, has been provisionally allocated to HSRP IPv6 by the IANA.
A common way to form an IPv6 link-local address is by appending an interface ID to the prefix FE80::/64.The interface ID for an HSRP group is based on the EUI-64 identifier derived from the HSRP group virtualMAC address. The EUI-64 is formed as shown in Chapter 2. For the MAC address 0005.73A0.0001, theinterface ID is 00-05-73-FF-FE-A0-00-01, and the IPv6 link-local address is FE80::5:73FF:FEA0:1. Note thatthe U/L it is set to 0, indicating local significance.
564 Part II: Deployment Case Studies
564 Part II: Deployment Case Studies
Periodic RAs are sent for the HSRP virtual IPv6 link-local address when the HSRP group is active. TheseRAs stop after a final RA is sent when the group leaves the active state. No restrictions occur for the interfaceIPv6 link-local address other than that mentioned for the RAs. Other protocols continue to receive and sendpackets to this address.
In the case of IPv4, simple load sharing may be achieved by using two HSRP groups and configuring half thehosts with one virtual IP address and half the hosts with the other virtual IP address. In contrast, on IPv6 thishappens by default. If there are two HSRP IPv6 groups on a link, the hosts learn of both through IPv6 ND RAmessages. They are either multicast periodically, or solicited by hosts. Then a host chooses to useonedepending on the IPv6 stack implementationsuch that the load is shared among the advertised routers.Typically, a host may use a round-robin scheme to decide which to use from the list of learned routers.
Cisco HSRP is an efficient mechanism designed to provide high availability of first-hop routers for IPv6hosts. It is therefore decided that on AC LANs, when several routers are available on a given links for IPv6hosts, HSRP for IPv6 will be configured as shown in Figure 15-7.
Figure 15-7. High Availability on AC LANs
Example 15-15 shows a configuration for routers R1 and R2 that requires a Cisco IOS Release 12.4(4)T asminimum:
To verify the HSRP activation, the show standby command can be used, as shown in Example 15-16.
Example 15-16. Display of Cisco HSRP for IPv6 Setup
Router R1R1#show standbyEthernet0/0 - Group 0 (version 2) State is Standby 1 state change, last state change 1d23h Virtual IP address is FE80::5:73FF:FEA0:0 Active virtual MAC address is 0005.73a0.0000 Local virtual MAC address is 0005.73a0.0000 (v2 IPv6 default) Hello time 3 sec, hold time 10 sec Next hello sent in 1.436 secs Preemption disabled Active router is FE80::A8BB:CCFF:FE00:6900, priority 100 (expires in 8.048 sec) MAC address is aabb.cc00.6900 Standby router is local Priority 100 (default 100) IP redundancy name is "hsrp-Et0/0-0" (default)R1#Router R2R2#show standbyEthernet0/0 - Group 0 (version 2) State is Active 2 state changes, last state change 1d23h Virtual IP address is FE80::5:73FF:FEA0:0 Active virtual MAC address is 0005.73a0.0000 Local virtual MAC address is 0005.73a0.0000 (v2 IPv6 default) Hello time 3 sec, hold time 10 sec Next hello sent in 2.872 secs Preemption disabled Active router is local Standby router is FE80::A8BB:CCFF:FE00:6600, priority 100 (expires in 7.540 sec) Priority 100 (default 100) IP redundancy name is "hsrp-Et0/0-0" (default)
Network managers may want to configure another FHRP protocol to achieve a similar behavior. On CiscoIOS implementations, alternatives are either VRRP, if interoperability with other vendors' routers is required,or Cisco GLBP, when multiple upstream paths are available to improve performance by facilitating better useof network resources. Then, additional configuration options, such as Enhanced Object Tracking, can beturned on when available for IPv6.
Securing the IPv6 Deployment
As extensively described in Chapter 9, IPv6 security is a mix of challenges, both those that are IPv4 similarand potentially new challenges. By default, IPv4 security policies will be applied to IPv6 as well on the AC
566 Part II: Deployment Case Studies
566 Part II: Deployment Case Studies
intranet. The IPv6 deployment will also benefit from all the underlying security mechanisms already in placefor IPv4 (for example, AC has already secured the layer 2 access of its network with the wirelessinfrastructure).
Products currently deployed as IPv4 firewalls have to be upgraded to a software release supporting IPv6.When not possible, the upgrade of the current hardware to a new generation of firewall with IPv6 supportmust be planned. The IPv4 configuration of the firewalls has to be updated to block uncontrolled IPv6 overIPv4 tunnels from being set up across the AC network perimeter. Devices performing intrusion detectionsystem (IDS) functions should also be evaluated for an immediate upgrade to IPv6 support.
The IPv6-specific security guidelines outlined in Chapter 9 are also formalized and implemented by theoperation team in the AC network. With regard to security challenges raised by the new services deployedover IPv6, multicast and Mobile IP have to be addressed. The most important aspects of securing the multicastservice relate to multicast domain management. The control and data multicast traffic has to be contained atthe boundaries and blocked from entering the network. The RPs have to also be protected against possibleDDoS. For the experimental deployment of MIPv6, an extended ACL will be edited to filter on the routingheader Type field, permitting type = 2 (MIPv6) and denying type = 0 (source route) as available on Cisco IOSRelease 12.4(2)T. See Chapter 9 for configuration details.
The Cisco 2821 router configured as an ISATAP router in the initial trial will be kept up and running, addingIPv6 connectivity to the Cisco VPN Client usersnot be confused with the VPN tunnels configured onbroadband access routers located at remote sites.
Multicast
On the AC intranet, IPv4 multicast is an experimental service. It started a couple of months ago to streamaudio and video files from headquarters to the rest of the world for scheduled training on new AC productsand services as well as internal management broadcasts. In reality, the IPv4-based service is supported only ata limited number of locations (because of its operational challenges). The service trial shows it to be toocomplex to manage IPv4 multicast across the NAT/PAT devices. AC expects to decrease the cost ofoperations for the service by running it over IPv6. The same commercial applications as in the case of IPv4multicast are already available, so it is now a matter of network support.
The first applications of the multicast service revolve around content distribution that would be well supportedby a Source Specific Multicast (SSM) model. However, AC plans to roll out collaborative applications, whichmeans the multicast sources might not always be located in the AC's data centers and with a well-knownaddress. For this reason, AC opted for an Any Source Multicast (ASM) multicast design.
To avoid the transport of delay/jitter-sensitive traffic across large distances and over expensive circuits, AC'sworldwide network is segmented into three areas, which represent independent multicast domains. Thisapproach also provides the three regions with a certain level of independence that allows them to tailorcontent to the respective markets. Each domain is outfitted with content servers at a headquarters location asdescribed in Table 15-6. It was also decided not to support the multicast traffic of other applications incrossing the boundaries of these domains.
Table 15-6. Multicast Server Distribution in AC's Network
Region
Served by Multimedia Server
Africa and Middle East
Part II: Deployment Case Studies 567
Part II: Deployment Case Studies 567
Paris
Asia-Pacific
Hong Kong
Europe
Paris
Latin and Central America
San Francisco
North America
San Francisco
For content-distribution purposes, two streaming servers are located per data center in the San Francisco,Paris, and Hong Kong headquarters. Content is actually created in San Francisco and then distributed to theother two locations over night. Each data center is responsible to stream the multimedia content in itsrespective region.
The service in each region will be similarly designed and will follow the guidelines and examples shown inChapter 6, "Providing IPv6 Multicast Services." It will also rely on the existent IPv6 IGP for routinginformation and RPF calculation. The following protocols are used to support the multicast service:
PIM Sparse Mode (PIM-SM) on routers and layer 3 switches. It starts running automatically when thenetwork element is enabled to support multicast through the global command ipv6 multicast-routing.
•
The Rendezvous Point (RP) mapping to the multicast group addresses is a key aspect in shaping theservice design. The independent domain approach chosen for this deployment would warrant anelegant and dynamic solution based on BSR as described in Chapter 6. The concern, however, is withthe multiple remote locations present within each multicast domain that connect to the main campusesover smaller bandwidth pipes and use lower-end network elements with limited resources. To limitthe impact of BSR flooding and the state maintained for it, AC decided to select an embedded RPapproach.
•
Although MLDv2 is supported by default on the Cisco routers, at the time of planning the deploymentmost stacks actually support only MLDv1. AC decided to use both at its access layer.
•
To optimize the use of resources for multicast forwarding, MLD snooping is turned on by default onall layer 2 switches deployed on AC LANs. This policy refers in particular to the Cisco Catalyst 6500with supervisor engine 720 and Catalyst 3750 or 3560 series installed on all sites. The feature isenabled with the global configuration command ipv6 mld snooping.
•
The servers acting as sources for the multicasted content are located in the data centers of the three localheadquarters serving each region. A prefix is allocated for these multicast resources in each data center, and itis identified by convention through bits 57 through 64 of the IPv6 address being set as DD:
San Francisco: 2001:DB8:ACAC:00DD::/64• Paris: 2001:DB8:ACAC:24DD::/64• Hong Kong: 2001:DB8:ACAC:80DD::/64•
The two gateways serving the server segment are set to be the RPs for the multicast groups used in that
568 Part II: Deployment Case Studies
568 Part II: Deployment Case Studies
domain. A second prefix is used to identify these RPs. For this prefix, bits 57 through 64 are set to DF. Theloopback interfaces of the RPs are assigned this prefix with the interface ID set as ::F. In the case of anembedded RP-based deployment, the multicast group addresses derive from the RP unicast address, asdescribed in Chapter 6. Table 15-7 summarizes the prefixes relevant to the multicast service.
Table 15-7. Prefixes Used with the Multicast Service
Region
Multicast Servers
RP
Multicast Groups
San Francisco:
-North America
-Latin and Central America
2001:DB8:ACAC:00DD::/64
2001:DB8:ACAC:DF::F/128
2001:DB8:ACAC:DF::F/127
FF75:F40:2001:DB8:ACAC:DF:G
-Where G is the 32 bits group ID
Paris:
-Africa and Middle East
-Europe
2001:DB8:ACAC:24DD::/64
2001:DB8:ACAC:24DF::F/128
2001:DB8:ACAC:24DF::F/127
FF75:F40:2001:DB8:ACAC:24DF:G
-Where G is the 32 bits group ID
Hong Kong:
-Asia-Pacific
2001:DB8:ACAC:80DD::/64
2001:DB8:ACAC:80DF::F/128
Part II: Deployment Case Studies 569
Part II: Deployment Case Studies 569
2001:DB8:ACAC:80DF::F/127
FF75:F40:2001:DB8:ACAC:80DF:G
-Where G is the 32 bits group ID
Example 15-17 shows the relevant configuration of the RP router in the San Francisco data center.
Example 15-17. IPv6 Multicast Configuration
RP-1#ipv6 multicast-routing!ipv6 pim rp-address 2001:DB8:ACAC:DF::F!interface Loopback0 no ip address ipv6 address 2001:DB8:ACAC:DF::F/128 ipv6 enable!
The two segment gateways provide a certain level of redundancy for the RP functionality. The primary RP hasthe loopback address configured with the longer prefix /128, whereas the backup has its configured with thesame address but the /127 prefix length. This means that as long as the primary is active, the longer prefixmatch will send all the PIM traffic to it. If it fails, the IGP will redirect it to its backup.
Note
This mechanism provides a coarse level of redundancy. Chapter 6 discusses its implications, such as sourcere-registration upon RP failure.
An important aspect of implementing the multicast design described is the multicast domain control. All typesof multicast traffic, other than that with link-local scope, have to be blocked from traversing the borderbetween AC's network and the IPv6 Internet. Moreover, to enforce the rules defined for the content services,the FF75:: multicast traffic has to be stopped from crossing the border between the three domains identified.The domain control is implemented with the help of eACLS on the relevant WAN routers. This can be easilydone considering the well-defined scope and structure of the multicast addresses used.
The troubleshooting steps described in Chapter 6 can be used in the case of this deployment. Thisembedded-RP design simplifies significantly to service, making its support much easier than the alternativeBSR-based design.
Network Management
A complex aspect of running a dual-stack network is its management. Hopefully, the new IP version is anaddition to existent IPv4 services on the AC intranet so that there is no need to natively manage the equipmentover an IPv6 network layer. Nevertheless, the NMS is upgraded to dual stack as well and configured with amanual IPv6 address to follow AC addressing rules. Other steps to update the management infrastructure to
570 Part II: Deployment Case Studies
570 Part II: Deployment Case Studies
support IPv6 include the following:
Releases of HP OpenView and Cisco Network Management applications are upgraded to the mostrecent versions, which include IPv6 applications as described in Chapter 10, "Managing IPv6Networks."
•
Additional scripts are written to handle IPv6 configurations on networking devices.• The user-tracking application available from Cisco LMS 2.5 is leveraged to monitor the hostsconfigured with "privacy extension" addresses.
•
Network Analyzer modules already deployed in AC's network will be updated to handle IPv6protocols.
•
Overall, the NM policies and procedures have to be updated to reflect the specificities of IPv6.
Mobility
One of AC management's expectations about the integration of IPv6 is the deployment of new appliancessupported through IP mobility. New generations of smart phones and PDAs, allocated to employees enabledwith various wireless access technologies, should provide easy access intranet resources. The recentdevelopment of mobile router, such as Cisco MAR 3200, would also enable the AC fleet of vehicles to stayconnected while being outfitted with a multitude of data collection and data delivery devices. Applicationssuch as video security, maintenance, and tracking represent an opportunity to optimize resources. Because theimplementations are still in their infancy, the AC IT team will begin an experimental service to learn thetechnology and validate the design.
In the beginning, only the San Francisco headquarters will be configured for MIPv6. If the experiment isdeemed successful, the service will be expanded to other regional headquarters. Minimum steps to beachieved include the following:
A new Ethernet segment is created on the DMZ that represents the MIPv6 home network.• An IPv6 prefix, 2001:0DB8:ACAC:00FF::/64, is assigned to this segment.• A Cisco 2821 router running Cisco IOS Release 12.4(2)T is configured, as shown in Example 15-18,as MIPv6 home agent for the experiment. See Chapter 8, "Advanced ServicesIPv6 Mobility," fordetails about the MIPv6 protocol.
Examble 15-18. Router MIPv6 Home Agent Basic Setup
MIPv6#ipv6 mobile home-agent!interface GigabitEthernet0/0ip address 10.151.1.7 255.255.255.0ipv6 address 2001:0DB8:ACAC:00FF::/64 EUI-64ipv6 mobile home-agent preference 1 ipv6 mobile home-agent
!Checking the Mobile IPv6 Home Agent availabilityMIPv6#show ipv6 mobile home-agentsHome Agent information for GigabitEthernet0/0 Configured: FE80::20F:35FF:FE2D:38C9 preference 1 lifetime 1800 global address 2001:0DB8:ACAC:00FF:20F:35FF:FE2D:38C9/64No Discovered Home AgentsMIPv6#show ipv6 mobile globalsMobile IPv6 Global Settings: 1 Home Agent service on following interfaces:
•
Part II: Deployment Case Studies 571
Part II: Deployment Case Studies 571
GigabitEthernet0/0 Bindings: Maximum number is unlimited. 1 bindings are in use 1 bindings peak Binding lifetime permitted is 262140 seconds Recommended refresh time is 300 seconds
A laptop with WiFi and 3G interfaces loaded with Microsoft Windows XP SP1 and Mobile IPv6technology preview acts as Mobile Node. Example 15-19 are the commands and displays from theWindows MIPv6 client.
•
Example 15-19. Microsoft Windows XP MIPv6 Client Technology Preview Configuration
Disabling IPSec authentication as it is not yet supported on Cisco IOS for Mobile IPv6C:\> ipv6 gpu MIPv6Security offManual HA ConfigurationC:\> ipv6 hau <HoA> <HA>C:\>ipv6 hau 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9
Display MIPv6 Home Agent configurationC:\>ipv6 haHome Address: 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7cHome Agent: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9
Expires : 47s Comments : HOME_AGENT RRState : NO_RR ACTIVE
The purpose of the test is to enable the Mobile Node to reach its home network either from any internal ACsubnet or any external location. Example 15-20 shows a Ping6 when the Mobile Node is away from its homenetwork sent toward a node sitting on the home network shown in Figure 15-8.
Example 15-20. MIPv6 Testing
Ping6 commandC:\> ping6 -t 2001:DB8:ACAC:FF:20d:60ff:fefa:e15bPinging 2001:DB8:ACAC:FF:20d:60ff:fefa:e15bfrom 2001:DB8:ACAC:FF:20c:29ff:feb9:8d7c with 32 bytes of data:Reply from 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b bytes=32 time=137msReply from 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b bytes=32 time=137msPing statistics for 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 119ms, Maximum = 137ms, Average = 128msCtrl+CC:\>Display of MIPv6 Binding Cache during ping6C:\> ipv6 bcHome Address: 2001:DB8:ACAC:FF:20c:29ff:feb9:8d7c
This section gave a basic example of IP mobility configuration. Real production deployment with a largenumber of devices will present more challenges than a single mobile-node test. AC will continue theexperimentation with more complex settings and challenges, such as the following:
Adding multiple mobile nodes with various implementations of MIPv6 for a large-scale evaluation:Microsoft Mobile PC 2003 and its Mobile IPv6 Technology Preview and Linux MIPv6.
•
Adding a Mobile RouterCisco MAR 3200as MIPv6 client. An IPv6 video camera will be attached toone of the MAR 3200 Ethernet interfaces to demonstrate video surveillance in a truck.
•
At the time of writing, MIPv6 implementation on Cisco IOS does not include an authenticationmechanism such as IPsec or Light Authentication. This will be validated when available on acommercial Cisco IOS release. Note that Microsoft Mobile IPv6 Technology Preview allowsdisabling the IPsec authentication.
•
Security rules to protect the AC intranet from attacks when IP mobility is a production service. Tobegin with, extended ACLs to differentiate routing option header type 2 (MIPv6) from type 0 (sourcerouting) are set on access routers.
•
Although there is still a long way to go before running an IP mobility production service, this represents astrong opportunity for innovation, helping AC to keep its technology leadership with its market through
Part II: Deployment Case Studies 573
Part II: Deployment Case Studies 573
improved processes.
QoS
As discussed in Chapter 5, "Implementing QoS," the architectural model is similar between IPv4 and IPv6.The initial QoS setup on the AC network was done to guarantee the bandwidth of the IP telephony traffic andlimit the throughput of the experimental IPv4 multicast traffic over the WAN links. Packets sent over bothversions of IP consume the same resources, meaning that if one application is considered mission critical, itstraffic has to be protected whatever the network layer version. With the assumption in mind that applicationsshould be protocol agnostic, the AC network team decided that all QoS rules must be applied the same way toboth versions of IP. This eases the integration of IPv6-capable applications because no further action isneeded after the QoS rules are set for IPv4 (as long as IPv6 QoS is supported on routers and switches).
QoS is really an internal service for the AC intranet. It was defined to guarantee the bandwidth of IPtelephony and control the throughput of multicast streams in locations where it was enabled. Class of service(CoS) definition has been limited to a minimum, as follows:
All traffic DSCP=0
This should be the default for all traffic except as indicated below. Traffic flowing from and to theInternet is re-marked on the AC edge router with DSCP=0.
•
IP telephony DSCP=5
This is reserved to the IP telephony traffic. This is the original QoS value set by the IP phones andmust be preserved through the intranet.
•
Management traffic DSCP=7
The default value is intact for the network management traffic, (for example, routing protocol) thatgenerates by default packets with such a value.
•
On Cisco IOS routers supporting IPv6 QoS through the Modular QoS CLI (MQC), the default action for QoSis to apply the same rules for both IPv4 and IPv6.
On AC LANs, the IP QoS to 802.1Q/p CoS correspondence is enabled to guarantee the bandwidth of the IPtelephony. On Catalyst 6500 running Cisco IOS Release 12.2(18)SXE and higher, the correspondencebetween IPv6 Traffic Class field and 802.1Q CoS is supported for all CEF switched packets.
Note
To treat an application separately for IPv4 and IPv6, the network manager must add a match criteria with thematch protocol ip and match protocol ipv6 commands in a match-all class map.
See Chapter 5 for a more detailed discussion about IPv6 QoS and its configuration.
574 Part II: Deployment Case Studies
574 Part II: Deployment Case Studies
Troubleshooting
As introduced in this chapter, the deployment of IPv6 in an enterprise infrastructure touches most of itsnetworking equipment and their configured feature sets. Troubleshooting such environments is similar forIPv4 and IPv6. At the same time, it calls for in-depth knowledge of IP version 6, equipment command-lineinterfaces (CLIs), the inherent topology and configured features, and basic (such as ping and traceroute) toadvanced (such as network analyzer, network management applications) tools. Previous chapters includeexamples of Cisco IOS CLI output for debug commands; these examples apply to this chapter for similartroubleshooting needs. It should be added that that although IPv6 is a distinctly identified at layer 2, by theEther Type 86 DD, the procedures to troubleshoot an IPv6 network with tools such as a LAN analyzer do notchange from their IPv4 counterpart.
Future Evolutions
Over the past 10 years, the evolution and growth of the commercial Internet tied to other technologicaldevelopments makes it difficult to forecast what will be the scope of the IPv6 deployment in the next 10 years.By integrating IPv6 services on its intranet, AC is well positioned to take advantage of the potential offered bythese developments. It can quickly evolve in step with them, and it can therefore maintain leadership in itsmarket. Nevertheless, the AC Corporation acknowledges that IPv6as a live protocolstill requires furtherdevelopments from standardization, product, application, and deployment experience perspectives. As a resultof the initial deployment, several topics of interest have been identified to be monitored and evaluated fortheir impact on AC's network:
Definitions of new IPv6 prefix assignment policies and multihoming rules• Evolution of security architecture to cope with centralized and distributed models• Expansion of market and new applications converging to IP•
Prefix Selection, Assignment Policies and Multihoming
The addition of IPv6 services on AC's worldwide network is done with the collaboration of the serviceprovider T-World, which has global presence and support. The IPv6 addressing scheme applied on the ACnetwork is built from the 2001:0DB8::/32 prefix registered by T-World to its Registry, and it in turn assignedthe 2001:0DB8:ACAC::/48 prefix to the AC Corporation. It follows the current allocation policies defined bythe Registries with the goal of enabling the service provider to aggregate its routing table when peering withother providers.
Nevertheless, competitiveness and business drivers may require the AC Corporation to require regionalconnectivity from several ISPs. At the time of this writing, Registry policies do not permit an IPv6multihoming solution. A model similar to IPv4 where a customer may ask an ISP to announce a prefixbelonging to another ISP is not allowed, neither is there an IPv6 address space assigned forprovider-independent prefix to enable enterprises to get their own address space independently from an ISP.Potential solutions developed by the IETF Multi6 and Shim6 working groups as well as new policies from theRegistries to create a provider-independent address space are still under discussion, but are unavailable nowfor practical implementations. This factor is currently slowing down enterprise adoption of IPv6 in general.The AC team recognizes the need for an IPv6 multihoming solution and will welcome any effort by theRegistries to deliver a solution to the market.
The IETF IPv6 working groupdefined unique local unicast IPv6 addresses were also evaluated for use in theAC intranet for local resources, such as printers and storage servers (which do not need to be accessible fromthe Internet). Because the draft defining this type of addresses is still evolving and no real deployment
Part II: Deployment Case Studies 575
Part II: Deployment Case Studies 575
experience could be leveraged, this option was not selected as a solution.
It is expected that prefix-selection and -assignment policies will evolve in the coming years to offer greaterflexibility. Experiments involving new addressing schemes, including renumbering on a large scale andsecurity rules, will be welcomed by AC, as will guidelines on network management when several sets ofaddresses (global and unique local) are overlapped in an intranet. Recommendations to roll out a large numberof mobile devices that reach the Intranet through external connections are another area of expertise that stillhas to be mastered.
Security
Security is a must for an enterprise when it connects to the Internet, regardless the version of the IP protocolused. AC wants to connect to the IPv6 Internet and get some of its public servers reachable via IPv6. This isimportant for the business in regions where IPv6 promotion is active and to allow the IP mobilityexperimentation. After the initial security rules are in place, AC plans to continuously monitor the evolutionof security processes and potential security alerts that may impact a dual-stack type of network. Hopefully,organizations such as CERT, and vendors, such as Cisco, are concerned about IPv6 and are publishing alertsrelevant to these environments when issues are identified.
IPv6 security is an area where the AC team expects to see an increase in market activities. IPv4 security wasmostly built around a centralized model, with firewalls as the key player. IPv6 specifications mandate theimplementation of IPsec. Although not widely available through the stack implementations, this would lead toa distributed model where security is done on each host. This may be acceptable in some contexts, but the ACteam believes the evolution should lean toward an integration of both the centralized and distributed modelwith policy servers to exchange information between hosts and security devices, keeping managementcentralized. The IT department will monitor closely this area.
Market Expansion
The primary deployment of IPv6 over the AC infrastructure covers the same topology as IPv4. Existingapplications such as e-mail, FTP, and web servers will be enhanced over time to run on IPv6. Thisenhancement will enable those public servers to be reachable via this protocol in regions where IPv6 becomesa must have for e-Business. This upgrade can realistically be done without risks and at a low cost. But, thereal expectations from AC management, are as follows:
Complete the deployment ofpreviously run for experimentation onlyservice such as IP multicast forall locations.
•
Expand of the IP service convergence to areas such as industrial sensors (for instance, RFID, ZigBee,and video surveillance).
•
Enable mobile networking, which would offer opportunities for AC to increase its businesscapabilities and enhance its coverage.
•
Experimentation, planning, and deployment of IPv6 in an enterprise infrastructure will mostly be driven bybusiness needs. The lessons learned from AC's experience with IPv6 are as follows:
The addition of IPv6 in a network must be driven by the deployment of new services and associatedapplications or by the potential cost reduction coming from simplification of the network operations.As a business entity, AC does not recognize a need to immediately transition applications that run fineover IPv4 today.
•
When applicable, it is always better to run native IPv6 together with IPv4 in a dual-stack approach.This guarantees the best performance and full IPv6 feature set availability for services such asmulticast. The IPv6 deployment can also leverage IPv4 for certain functions (for example, network
•
576 Part II: Deployment Case Studies
576 Part II: Deployment Case Studies
management). If not possible, review the IETF transition mechanisms to select the most appropriateones.All recent operating system releases are dual stack and support the libraries to make an applicationtransparent to the IP version. As an investment protection, it is recommended to only consider theacquisition or development of applications that are protocol agnostic.
•
Some aspects of the IPv6 deployment are still in their infancy and mandate additionaldevelopmenteither from the standardization standpoint or product, application, and experienceperspectives. It will also imply a learning period to gain familiarity with their evolution.
•
As it happened in the past with phasing out DECnet and IPX protocols from the AC network, there may be aday when IPv4 will be deprecated and all applications will run over IPv6. This may be a long-term objective,but it is not something that is crucial to the deployment of IPv6. At this stage, it is acknowledged that theactual protocol implementations do not allow planning for a full transition. The focus is to leverage theprotocol for new applications and services, and to prepare for the possibilities.
DAD (Duplicate Address Detection) 2nd data plane Default Router Preferences (DRP) Delegating Routersdeployment
addressing content distribution content hosting/storage design
design options dual stack PPP/L2TP
DNS edge core Internet access network environment
582 Part II: Deployment Case Studies
582 Part II: Deployment Case Studies
plans QoS service rollout
targeted services communities of interest content delivery content hosting/storage DNS services Internet access mail services MIPv6 unicast connectivity VoIP
GARP (Generic Attribute Registration Protocol) general prefixes global addresses global IA (Internet access) global multicast GRE (Generic Routing Encapsulation) group multicast addresses
MLD (Multicast Listener Discovery) protocol mobile ad-hoc networking mobile home networks mobile network node (MNN) mobile nodes mobile routersmobility
deployment future
attachment router selection faster roaming integration with mobile ad-hoc networking movement detection multihoming route optimization for NEMO
distributed home networks enterprises on the move extended home networks fleet in motion home gateways home networks Internet-enabled cars mobile home networks object model operations PANs sensor networks terminology virtual home networks
nonmobile scenarios community of interest IPv4 to IPv6 transitioning overview route projection server load balancing topology hiding
service provider deployments access design addressing core design CsC-CE configuration design objectives edge design global Internet access design and implementation inter-AS design MTU discovery POP design QoS design route reflector design security troubleshooting
590 Part II: Deployment Case Studies
590 Part II: Deployment Case Studies
VPN IA service design and implementation VPN service design and implementation VRF design
traffic engineering MPLS-TE MSR (More-Specific Routes) MTU discovery multicast distribution trees (MDTs) Multicast Forwarding Information Base (MFIB) Multicast Listener Discover (MLD) protocol multicast services 2nd
addressing deployment
ASM model 2nd domain control enterprise networks MPLS infrastructures RP mapping and redundancy service models SSM model 2nd tunneling mechanisms
aggregated home networks distributed home networks enterprises on the move extended home networks fleet in motion home gateways home networks Internet-enabled cars mobile home networks operations PANs sensor networks terminology virtual home networks
VPNs 2nd 3rd sensor networks server load balancing service level agreementsservice provider deployments (MPLS)
access design addressing core design CsC-CE configuration design objectives edge design global Internet access design and implementation inter-AS design
Part II: Deployment Case Studies 597
Part II: Deployment Case Studies 597
MTU discovery POP design QoS design route reflector design security troubleshooting VPN IA service design and implementation VPN service design and implementation VRF design
service providersservices
advanced multicast rollout targeted
shaping function shortest path trees (SPTs) SIP (Session Initiation Protocol) smurf attacks sniffingsoftware
forwarding routers upgrade costs
SOLICIT messagesSource Specific Multicast [See SSM] spoofing attacks
TACACS+ (Terminal Access Controller Access Control System Plus)
598 Part II: Deployment Case Studies
598 Part II: Deployment Case Studies
targeted services communities of interest content delivery content hosting/storage DNS services Internet access mail services MIPv6 overview unicast connectivity VoIP
Teredo tunnels TIB (Tree Information Base) topology hiding Traceroute command traffic conditioning traffic engineering traffic filtering traffic forwarding, PIM traffic rate limiting training transition-mechanism attacks transitioning translation mechanisms Tree Information Base (TIB)troubleshooting
