Deploying IPv6 networks Includes index 1587052105, 9781587052101

Citation preview

Deploying IPv6 Networks Ciprian Popoviciu Eric Levy-Abegnoli Patrick Grossetete

Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA

ii

Deploying IPv6 Networks Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete Copyright © 2006 Cisco Systems, Inc. Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing February 2006 Library of Congress Cataloging-in-Publication Number:2004108530 ISBN: 1587052105

Trademark Acknowledgments All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer This book is designed to provide information about the deployment of IPv6. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The author, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it. The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

Corporate and Government Sales Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 [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 is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community.

iii

Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please make sure to include the book title and ISBN in your message. We greatly appreciate your assistance. Publisher Editor-in-Chief Cisco Representative Cisco Press Program Manager Production Manager Development Editor Project/Copy Editor Technical Editors Team Coordinator Book/Cover Designer Compositor Indexer

John Wait John Kane Anthony Wolfenden Jeff Brady Patrick Kanouse Deadline Driven Publishing Interactive Composition Corporation Blair Buchanan, Gunter Van de Velde, Dan Williston Raina Han Louisa Adair Interactive Composition Corporation Interactive Composition Corporation

iv

About the Authors Ciprian Popoviciu, CCIE No. 4499, is a technical leader at Cisco Systems with more than eight years of experience designing, testing, and troubleshooting large IP networks. As part of the Cisco Network Solution Integration Test Engineering (NSITE) organization, he currently focuses on the architecture, design, and test of large IPv6 network deployments in direct collaboration with service providers worldwide. He contributed to various publications and the IETF. Ciprian holds a bachelor of science degree from Babes-Bolyai University, a master of science degree and a doctorate degree in physics from the University of Miami. Eric Levy-Abegnoli is a technical leader in the IP Technologies Engineering group at Cisco Systems, where he is the technical lead for IPv6 development in IOS. Eric has worked with the Cisco IPv6 implementation since 2001, and has been involved in some of the biggest IPv6 deployments. Before joining Cisco, Eric worked for IBM, where he successively led a development team in the Networking Hardware Division and a research team at the Thomas J. Watson Research Center, focusing on networking and content-delivery platforms. Eric received the Diplome d’Ingenieur from the Ecole Centrale de Lyon, France. Patrick Grossetete, manager of product management at Cisco Systems, is responsible for a suite of Cisco IOS software technologies including IPv6 and IP Mobility. He is a member of the IPv6 Forum Technical Directorate and manages Cisco’s participation in the forum. In June 2003, he received the “IPv6 Forum Internet Pioneer Award” at the San Diego summit. Patrick joined Cisco in 1994 as a consulting engineer. Before joining Cisco, Patrick worked for Digital Equipment Corporation as a consulting engineer and was involved with network design and deployment. He received a degree in computer technology from the Control Data Institute, Paris, France.

About the Contributor Pascal Thubert has been with the Technology Center since joining Cisco Systems in 2000. He leads a group that has been working on IPv6 networking mobility for the past five years. Pascal is the author of a number of Internet drafts and IETF working group documents, in particular RFC 3963 (NEMO). He wrote the initial implementation of IPv6 network mobility and experimented with a number of additional features for route optimization and MANET. Some of these experiments were conducted with automakers, and his team, together with the Renault Prospect & Research division, won the Jun MURAI award in 2003 for their IPv6 e-Vehicle project. Before Cisco, Pascal was a lead network architect at IBM.

About the Technical Reviewers Blair Buchanan, CCIE No. 1427, is a senior technical architect and convergence strategist with Sherwood Cameron Associates Limited, in Ottawa, Canada. He has 30 years experience in the communications business. He began his career as a software developer for real-time data communications in process-control applications. Blair has participated in ISO standards development and has taken lead roles in internetwork design for large enterprise and service provider businesses in Canada and the United States. He is currently involved in planning and designing internetworks for converged services over metro Ethernet and IP VPN infrastructures. Blair holds a bachelor degree in computer science and mathematics from the University of Western Ontario (1975). His involvement with Cisco began in 1992 as a Cisco instructor and in 1995 as a CCIE. Gunter Van de Velde is a senior network consulting engineer on the Cisco System’s Advanced Services team, and has been working in the field of core network design, and the implementation of IPv6, since early 2001. Gunter received his master’s degree in electronics in 1993. After graduating, his first professional activities were based on TDMs, modems, and L2 bridges. He joined Cisco Systems in 1997, initially providing reactive worldwide support as part of the Technical Assistance Center, specializing in IP routing protocol technologies. In 1999, he joined the Advanced Services organization as a network consulting engineer, where he has been active in designing large backbone ISP networks and services.

v

Since 2001, Gunter has been working as a design architect for the European Commission–sponsored 6NET IPv6 project, and this year has become involved with the IETF, for which he is authoring a number of drafts in the v6ops working group. Gunter is a member of the IPv6 Task Force, and is a regular speaker at IPv6 conferences and events. Dan Williston is a technical leader at Cisco Systems in Ottawa. He was a key member of the software development team responsible for IPv6 on the Cisco 12000 series router. Prior to joining Cisco, he worked at Nortel Networks as a senior software designer and team leader on inter-LAN switching on the Passport 6400. In the early 1990s, he worked at Norlite Technology, which developed PC-based computer integrated telephony applications and hardware. Dan has 17 years experience in telecommunications and data networking and holds a bachelor’s degree in electrical engineering from McGill University.

vi

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.

vii

Acknowledgments This book benefited from the efforts of all Cisco engineers who share our enthusiasm for the next generation of IP and work tirelessly to implement, test, and deploy it. Among them, there are a few to whom we are particularly grateful: Ole Troan, for his encouragement and support of this work, along with his contribution to Chapters 3 and 7; Pascal Thubert, for his key contribution to Chapter 8; Sean Convery and Darrin Miller, for their guidance and contribution to Chapter 9; and Benoit Lourdelet, for his contribution to Chapter 11. We also want to acknowledge the support of Gunter Van De Velde, Jean-Marc Barozet, Faycal Hadj, Gilles Clugnac, Floris Granvarlet, Tim Gleeson, Stan Yates, Luc Revardel, Vincent Ribiere, Richard Gayraud, Francois Le Faucheur, Alun Evans, Tom Kiely, Kevin Miles, Tin Phan, and Min Li. We want to thank our technical reviewers—Dan Williston, Gunter Van de Velde, and Blair Buchanan—for their thorough review and their valuable suggestions. Special thanks go to our extraordinary editorial team, particularly Grant Munroe, Raina Han, and John Kane. This project could not have been completed without the support of our families and friends.

viii

This Book Is Safari Enabled The Safari® Enabled icon on the cover of your favorite technology book means the book is available through Safari Bookshelf. When you buy this book, you get free access to the online edition for 45 days. Safari Bookshelf is an electronic reference library that lets you easily search thousands of technical books, find code samples, download chapters, and access technical information whenever and wherever you need it. To gain 45-day Safari Enabled access to this book: • Go to http://www.ciscopress.com/safarienabled • Complete the brief registration form • Enter the coupon code BQCN-RDFD-41DI-ITD2-V4Q7 If you have difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail [email protected].

ix

Contents at a Glance Introduction

xxv

Part I

Implementing IPv6 Services

Chapter 1

The Case for IPv6—An Updated Perspective

Chapter 2

An IPv6 Refresher

Chapter 3

Delivering IPv6 Unicast Services

Chapter 4

IPv6 Routing Protocols

Chapter 5

Implementing QoS

Chapter 6

Providing IPv6 Multicast Services

Chapter 7

VPN IPv6 Architecture and Services

Chapter 8

Advanced Services—IPv6 Mobility

Chapter 9

Securing IPv6 Networks

Chapter 10

Managing IPv6 Networks

Chapter 11

Network Performance Considerations: Coexistence of IPv4 and IPv6 415

Part II

Deployment Case Studies

Chapter 12

Generic Deployment Planning Guidelines

Chapter 13

Deploying IPv6 in an MPLS Service Provider Network

Chapter 14

Deploying IPv6 in an IP Service Provider Network

Chapter 15

Deploying IPv6 in an Enterprise Network

Index 615

3 5

25 89

145

175 207 249 291

329 367

437 439

569

509

451

x

Table of Contents Introduction Part I

xxv

Implementing IPv6 Services

3

Chapter 1 The Case for IPv6—An Updated Perspective

5

Unicast Connectivity 6 Addressing 6 IPv4 Address Architecture 6 Private Versus Public Addresses 8 Static Versus Dynamic Addresses 9 Renumbering 10 Network Address Translation 11 Routing 14 QoS Services 14 Multicast Services 16 Virtual Private Networks 18 Security

20

IP Mobility

21

IPv6 Is an Evolutionary Step Chapter 2 An IPv6 Refresher

22

25

IPv6 Addressing 25 IPv6 Address Representation 26 IPv6 Address Architecture 27 IPv6 Unicast Address 28 IPv6 Anycast Addresses 39 IPv6 Multicast Addresses 40 IPv6 and Layer 2 Addressing 45 IPv6 Addresses Required for an Interface 46 Configuring IPv6 Addresses in Cisco IOS Routers 47 IPv6 Addressing Architecture at a Glance 49 IPv6 Packet Format 51 IPv6 Versus IPv4 Basic Header Format IPv6 Extension Headers 55 Hop-by-Hop Options Header 57 Destination Options Header 58 Routing Header 58

52

xi

Fragment Header 58 Authentication Header 59 Encapsulating Security Payload Header 59 Mobility Header 59 Linking Multiple Extension Headers 59 IPv6 and Data-Link Technologies 60 Internet Control Message Protocol for IPv6 62 ICMPv6 Error Messages 65 Destination Unreachable 65 Time Exceeded 65 Packet Too Big 66 Parameter Problem 67 ICMPv6 Informational Messages 67 Source Address Selection Algorithm 68 Conclusion on ICMPv6 68 Neighbor Discovery Protocol 70 Protocol Operations Summary 72 Comparison with IPv4 74 Router and Prefix Discovery 74 Address Resolution 76 Redirecting a Host to a Better Next Hop 78 Inverse Neighbor Discovery 79 Proxy Neighbor Discovery 80 Neighbor Discovery Algorithms 80 Next-Hop Determination 80 Default Router Selection 82 Duplicate Address Detection 83 Neighbor Unreachability Detection 84 The State Machine for Reachability 84 Autoconfiguration 86 Neighbor Discovery at a Glance 86 Chapter 3 Delivering IPv6 Unicast Services

89

Overview 89 IPv6 Provisioning 91 Host IPv6 Address Provisioning 91 Stateless Autoconfiguration 92 Stateful DHCP 93 Router IPv6 Address Provisioning: Prefix Delegation Protocol Description 96 Requesting Router 98

95

xii

Delegating Router 101 What DHCP-PD Does Not Do 103 Other Configuration Information 103 Stateless DHCP 103 DNS Services 104 IPv6 Network Access 106 Media Types 107 Native IPv6 Access 109 Routed Access 109 Bridged Access 109 PPP-Encapsulated IPv6 Access 110 Virtualized Access Layer 115 Access over Tunnels 120 Manually Configured Tunnel 121 Tunnel Broker and Tunnel Server 122 Teredo 122 ISATAP 123 IPv6 over the Backbone 125 Native IPv6 126 IPv6 over IPv4 Tunnels 127 IPv6 over MPLS 131 Translation Mechanisms (NAT-PT)

140

Chapter 4 IPv6 Routing Protocols 145 Distance Vector Routing Protocol 145 Path Vector Routing Protocol 147 Link-State Routing Protocol 147 IPv6 Interior Gateway Protocols 148 Routing Information Protocol next-generation Support for IPv6 148 Configuration Example 149 EIGRP for IPv6 150 Support for IPv6 151 Configuration Example 152 OSPFv3 153 Support for IPv6 154 Configuration Example 155 IS-IS for IPv6 157 Support for IPv6 158 Configuration Example 159 BGP 161

148

xiii

Use of MP-BGP Extensions for IPv6 Interdomain Routing BGP Peering 165 BGP Next Hop 166 BGP Configuration Example 168 Site Multihoming

169

Deploying IPv6 Routing Protocols 170 Network Core 170 Network Distribution/Edge 172 Network Access 172 Chapter 5 Implementing QoS

175

QoS for IPv6 178 Differences Between IPv6 and IPv4 QoS 179 Layer 3 QoS 179 Layer 2 QoS 180 Link-Efficiency Mechanisms 180 Differentiated Services 181 Support for IPv6 182 Configuration Example 184 Integrated Services 189 Support for IPv6 189 QoS for IPv6 over MPLS 190 Using DiffServ in a 6PE or 6VPE Environment 191 Configuration Example 192 Using RSVP-TE in a 6PE or 6VPE Environment 194 Using Multiple BGP Next Hops 196 COS-Based TE Tunnel Selection (CBTS) 198 Deploying QoS for IPv6 200 QoS in a Native IPv6 Deployment 200 QoS in an MPLS-Based IPv6 Deployment IPv4 and IPv6 Coexistence 204 Chapter 6 Providing IPv6 Multicast Services

202

207

IPv6 Multicast 208 Group Membership Management 209 Multicast Listener Discovery 209 Multicast Layer 2 Protocols 214 Multicast Routing and Forwarding 215 Multicast Distribution Trees 215 Reverse-Path Forwarding Determination Protocol Independent Multicast 219

216

164

xiv

Deployment Considerations 225 Multicast Domain Control 225 RP Mapping and Redundancy 226 Service Models 229 Multicast over Tunnels 232 Multicast over MPLS Infrastructures 233 IPv6 Multicast Deployment Examples 234 SSM in a Service Provider Network 234 Enabling IPv6 Multicast Routing 235 MLD Configuration 235 Tuning PIM 236 Subscriber Joining the (S,G) 236 IPv6 Multicast Traffic Forwarding 239 ASM in an Enterprise Network 239 Configuring BSR 240 Configuring Candidate RP routers 241 PIM Topology and Traffic Forwarding 243 Operation with Embedded RP 244 Chapter 7 VPN IPv6 Architecture and Services

249

Virtual Private Network Overview 249 Provider-Provisioned VPNs 251 CE-Based VPNs 251 PE-Based VPNs 252 Addressing Considerations 252 Security Considerations 253 Using IPsec to Implement CE-Based VPNs 254 Remote Access 254 IPsec Tunnel Alternatives 255 Routing 255 IPv6 CE-Based VPN deployment 255 BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution 255 Routing Table Segregation 257 Routing Protocols for BGP-MPLS IPv6 VPN 260 BGP Next Hop 261 Building the Label Stack 262 Forwarding in BGP-MPLS IPv6 VPN 264 VRF Concepts and IPv6 Implementation 267 Configuring a VRF 268 Associating a VRF to an Interface 269 VRF-Aware Router Commands 269

xv

Scaling IPv6 VPNs 270 MP-BGP for VPNv6 at a Glance

272

Topology Examples 273 Using IPsec to Secure IPv6 over an IPv4 Tunnel Basic MPLS VPNv6 Topology 274 Dual-Stack VPNs 278 Route Reflectors 279 Hub and Spoke 280 Internet Access 282 Interprovider VPNs 285 Chapter 8 Advanced Services—IPv6 Mobility

273

291

Chapter Overview 292 IP Host Mobility 292 Mobile IPv4 in a Nutshell 293 Mobile IPv6 294 Mobile IPv6 Operation Overview 294 IPv6 Mobility Header 294 Destination Option 297 Dynamic Home Agent Address Discovery 297 Route Optimization 298 Mobile IPv6 Security 299 Mobile IPv6 Deployment 300 Configuration Example 301 Using ACLs to Control MIPv6 Operation on the Home Agent Network Mobility 304 Practical Use Cases 305 Enterprise on the Move 305 Home Gateway 306 Personal-Area Network 306 Internet-Enabled Car 307 Sensor Network 308 Fleet in Motion 309 Object Model and Terminology 311 Basic Operations 311 What About NEMO? 312 Home Network in NEMO 313 Extended Home Network 313 Aggregated Home Network 314 Mobile Home Network 314 Distributed Home Network 316 Virtual Home Network 317

303

xvi

IP Mobility in Nonmobile Scenarios 317 IPv4 to IPv6 Transitioning 318 Topology Hiding 319 Community of Interest 321 Route Projection 321 Server Load Balancing 322 Next Steps in Mobility 322 Forthcoming Evolutions 323 Faster Roaming 323 Movement Detection 323 Attachment Router Selection 324 Integration with Mobile Ad-hoc Networking Endpoint Identification 325 Multihoming 325 Route Optimization for NEMO 325 A Vision 327

324

Chapter 9 Securing IPv6 Networks 329 Security Threats and Best Practices to Protect Against Them 332 Threats with New Considerations in IPv6 332 Reconnaissance 332 Unauthorized Access 334 Header Manipulation 336 Fragmentation 337 Layer 3/Layer 4 Spoofing 338 Host-Initialization and Address-Resolution Attacks 341 Broadcast-Amplification Attacks (Smurf) 343 Routing Attacks 343 Viruses and Worms 344 Transition-Mechanism Attacks 344 A Note on Mobile IPv6 Security 345 Threats with Similar Behavior in IPv4 and IPv6 346 Sniffing 346 Application Layer Attacks 346 Rogue Devices 346 Man-in-the-Middle Attacks 346 Flooding Attacks 346 6PE Security 347 A Note on VPN Security 347 Tools Available for Securing IPv6 Networks 348 IPsec for IPv6 348 IPsec Concepts 348 Using IPv4 IPsec to Secure IPv6 Tunnels 350

xvii

Securing Router–to-Router Communication with IPv6 IPsec Access Control Lists 352 Extended IPv6 ACLs and Stateful Filtering 353 IPv6 ACLs and Fragmentation 354 IPv6 Access List Example 355 Firewall Functions 356 Cisco IOS Firewall 357 PIX Firewall 359 Authentication, Authorization, and Accounting 360 Unicast Reverse Path Forwarding 361 Protecting the Control Plane with Rate Limiting 363 Summary of Best Practices for Securing IPv6 Deployments 364 Chapter 10 Managing IPv6 Networks

367

IPv6 Network Management: The Challenges 367 Allocating IPv6 Addresses to Managed Nodes 368 Integrating IPv6 and IPv4 Network Management 369 Network-Management Architecture

370

Retrieving Information from Routers and Switches 372 SNMP and MIBs 373 SNMP over IPv6 373 IPv6 MIBs 374 BGP and Other MIBs 376 IPv6 MIB Example 377 NetFlow 378 IPfix 384 Other Protocols (Telnet/SSH/RSH/TFTP/FTP) 385 Fault Management 388 Flow Analysis Using NetFlow 388 Cisco NFC 388 IPFlow 391 Cisco Network Analysis Module 391 Topology Management 393 Routing Management 396 Analysis for Troubleshooting 398 Performance Management 399 Cisco IOS IP Service-Level Agreements 400 Other IPv6-Enabled Tools for Performance Analysis 402 Configuration and Provisioning Management

405

351

xviii

Management Platforms 406 CiscoWorks 406 Other Management Platforms 410 HP OpenView 410 Tivoli NetView 411 InfoVista 411 IPv6 Network Management Services and Tools at a Glance

412

Chapter 11 Network Performance Considerations: Coexistence of IPv4 and IPv6 Aspects of Router IPv6 Performance IPv6 Control Plane 417 IPv6 and the Data Plane 419

416

Measuring Forwarding Performance

420

The Right Router for the Job 422 Router Architecture Overview 423 Software Versus Hardware Forwarding 423 Centralized Versus Distributed Forwarding 424 IPv6 Forwarding Performance of Cisco Routers 425 Low-End Routers 425 Mid-Range Routers 426 High-End Routers 429 6PE Forwarding Performance 432 IPv6 Router Performance Evaluation Checklist Part II

Deployment Case Studies

433

437

Chapter 12 Generic Deployment Planning Guidelines

439

Cost Analysis 439 Host-Related Costs 440 Network Elements–Related Costs 442 Operations-Related Costs 443 Address Policies and Registration Process 444 Education

447

Chapter 13 Deploying IPv6 in an MPLS Service Provider Network Network Environment

451

Network Design Objectives 453 EuropCom Services 454 Internet Access 455 L3VPN 456

451

415

xix

Carrier Supporting Carrier 456 DNS Services 457 Content Hosting/Storage 457 Voice over IP 457 Peer-to-Peer Applications and Other Services 460 Network Design 461 Access Design 462 POP Design 464 Core Design 465 IGP Design Considerations 466 MPLS Design Considerations 466 QOS Design Considerations 468 ICMP Design Considerations 468 Edge Design 468 PE Router Design and Implementation Considerations 470 PE-CE Interface Design 471 PE-CE Routing Design 473 PE-PE Routing Design 477 Route Reflector Design 479 VRF Design 482 Inter-AS Design 484 Basic Services Design and Implementation 488 Global IPv6 Internet Access Design and Implementation 488 Layer 3 MPLS VPN Service Design and Implementation 489 VPN Internet Access Service Design and Implementation 490 Carrier’s Carrier Service Design 493 Quality of Service Design

493

Operating and Troubleshooting the Network 496 Service and Traffic Monitoring 497 Addressing 497 Link-Local Addresses 498 Addresses for Management 498 Using Unique-Local Addresses 498 Inter-Provider Communications 499 Multihoming 499 MTU Discovery 499 Security 500 Securing the Edge 500 Securing the 6PE Infrastructure 501

xx

Troubleshooting 502 Routing 502 Forwarding 503 Design Lessons 507 Chapter 14 Deploying IPv6 in an IP Service Provider Network Network Environment and IPv4 Services 509 IPv6 Deployment Plans 515 Targeted IPv6 Services 516 Unicast Connectivity 516 Internet Access 517 DNS Services 517 Mail Services 517 Content Hosting/Storage 517 Voice over IP 517 Content Delivery—Multicast 518 Mobile IPv6—Communities of Interest 519 Design Goals 520 Design Options 521 PPP/L2TP-Based Deployment Option 521 Dual-Stack Deployment Option 523 Basic Services Design and Implementation 525 Addressing Plan 526 Unicast Connectivity 528 Access 530 Edge and Core 532 Service Rollout Plan 537 DNS and Content Hosting/Storage 538 Internet Access 539 Advanced Services Design and Implementation 541 Content Distribution—IPv6 Multicast 541 IPv6 Multicast Service Design 542 IPv6 Multicast Implementation 547 Quality of Service 551 QoS Service Design 551 QoS Implementation 552 Operating and Troubleshooting the Network Securing the IPv6 Network 555 Securing the Access 556 Securing the Edge 558 Securing the Data Center 558

555

509

xxi

Managing the Network 559 Troubleshooting 559 Provisioning 559 Unicast Routing and Forwarding 561 Multicast Routing and Forwarding 563 Deployment Lessons 565 Chapter 15 Deploying IPv6 in an Enterprise Network Introducing AC Corporation

569

569

AC Network Environment 571 AC Network Infrastructure 571 Headquarters 572 Branch Offices 573 Business Drivers to Integrate IPv6 on the AC Network Learning the Technology 575 Expanding the Test Bed 583 Domain Name Service (DNS) 583 ISATAP Router 584 IPv6 Internet-to-Campus Connectivity 587 Expanding the IPv6 Intranet Testing 589 Lessons from the Trial 589 Moving IPv6 to Production Cost Analysis 591 Operations 591

590

Design and Setup 591 IPv6 Addressing 592 Prefix-Assignment Scheme 593 Address Configuration Rules 593 Dual-Stack Deployment 594 Routing Protocols 595 First-Hop Router Redundancy 596 Tuning Neighbor Discovery 596 Configuring Default Router Selection Enabling Cisco HSRP for IPv6 599 Securing the IPv6 Deployment 601 Multicast 602 Network Management 605 Mobility 606 QoS 609

597

574

xxii

Troubleshooting

610

Future Evolutions 610 Prefix Selection, Assignment Policies and Multihoming Security 611 Market Expansion 612 Index 615

611

xxiii

Icons Used in This Book

Communication Server

PC

PC with Software

Terminal

File Server

Sun Workstation

Macintosh

Access Server

Cisco Works Workstation

Modem

Token Ring Token Ring

Printer

Laptop

Web Server

IBM Mainframe

Front End Processor

Cluster Controller

FDDI Gateway

Router

Catalyst Switch

Network Cloud

Bridge

Multilayer Switch

Line: Ethernet

Hub

ATM Switch

Line: Serial

DSU/CSU DSU/CSU

FDDI

ISDN/Frame Relay Switch

Line: Switched Serial

xxiv

Command Syntax Conventions The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conventions as follows: • Boldface indicates commands and keywords that are entered literally as shown. • Italics indicate arguments for which you supply actual values. • Vertical bars (|) separate alternative, mutually exclusive elements. • Square brackets [ ] indicate optional elements. • Braces { } indicate a required choice. • Braces within brackets [{ }] indicate a required choice within an optional element.

xxv

Introduction There is no doubt that information technologies have become a significant part of our lives, shaping in great measure the way people work, learn, and play. Their rise to prominence was accelerated over the past decade by computer communications. Networked computing devices have proven to be much more than their sum. This concept led to tremendous productivity increases and a plethora of new services that expanded its scope from research communities, to offices, to large corporations, and to the World Wide Web. Unprecedented engineering innovation rapidly improved networking technologies in lockstep with the fast adoption of computer communications (which naturally require larger, faster, and feature-rich infrastructures). On the other hand, the trend of converging all communications, data, voice, and video to a single networking protocol revealed a resource constraint to the further adoption of computer-communication-based services. IPv4’s address space cannot meet the needs of an ever-increasing demand for globally reachable IP devices. New services make address preservation a futile pursuit, with mechanisms such as Network Address Translation becoming anachronisms that block further innovation. With the looming exhaustion of the global IPv4 address space and with the private address space proving inadequate for today’s networks, service providers, enterprises, IP appliances manufacturers, application developers, and governments are now looking at the evolution of IP: IPv6. The foreseen address exhaustion has been the trigger and the driver for moving into a new addressing dimension. IPv6, however, is more than just an extension of the address space. Significant reengineering efforts were applied to solving protocol, deployment, and operation issues. You should expect IPv6 to be a better protocol than IPv4. IPv6 is IPv4’s future, happening now! The IPv6 protocol and its deployment represent the scope of this book.

Goals and Methods The most important goal of this book is to show that IPv6 is a mature technology and it is ready for deployment. It goes beyond discussing the basics of the protocol while remaining accessible to those unfamiliar with IPv6. With this book in hand, you will not only understand IPv6 but, most important, will know how to plan, design, and deploy IPv6 services. Countless books document and explain the vast set of protocols and features known under the name of IPv4. Although its evolutionary nature allows IPv6 to back reference many of its protocols and features, detailing all the changes and improvements made would require more than this book. On the other hand, IPv6 has yet to enter the mainstream and is outpacing many of the reference books on the market. This creates the risk of making any pure deployment case study discussion difficult to follow. These considerations shaped the methodology employed in this book. The most important changes in the foundation of IP, such as addressing architecture, packet format, and layer 2-to-layer 3 address resolution, are reviewed in detail. All the other protocols and features are discussed in the context of a service such as unicast, multicast, virtual private networks, quality of service, and security. The goal is to provide the reader with the understanding and tools needed to deploy the respective services. This approach gives a practical dimension to the information presented. This knowledge is reinforced in the second part of the book, where the reader can see it applied to concrete, complete deployment case studies. Deployment planning, deployment costs, performance, and IPv4–IPv6

xxvi

coexistence topics are also covered to further 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 and design considerations and present in the end configuration of key network elements. You can leverage this knowledge immediately in a real, Cisco IOS-based network infrastructure. In summary, this book’s goals are to: • Provide relevant, advanced IPv6 information from a deployment perspective. • Help you plan IPv6 deployments by offering guidelines and references to relevant resources. • Provide you the opportunity to practice the acquired knowledge on complete case studies. • Offer deployment examples that can be used as a reference in designing IPv6 services.

Who Should Read This Book? This book will be of interest to a rather large audience, potentially all people involved with IP communications in one way or another. Researchers, application developers, and IP appliance manufacturers can learn the protocol and possible ways to harness the IPv6 infrastructures of the future. However, this book primarily targets those who design, plan, deploy, and operate IP networks and services. Networking professionals will find this book taking them from minimal or no IPv6 familiarity to being able to plan, deploy, and operate IPv6 networks.

How This Book Is Organized Although each chapter of this book can be used independently to learn a certain aspect of IPv6, the book’s structure has a clear didactic dimension. It intends to build the knowledge layer by layer, or IP service by IP service, and in closing to offer a set of exercises in the form of case studies. Part I provides the technology tools needed to approach the design and deployment of an IPv6 network. The knowledge is grouped around IP services, each mapped to a chapter. It starts with enabling unicast connectivity, the foundation of any network, and follows with QoS, multicast, VPNs, IP mobility, security, and network management. The second part of the book, ushered in by a discussion of deployment planning, covers three complete case studies that map to three distinct environments: MPLS-based service provider, IP-based service provider, and enterprise. Chapters 1 through 15 cover the following topics:

PART I •

•

Chapter 1, “The Case for IPv6—An Updated Perspective”—This chapter builds the case for IPv6 from a technical perspective. It summarizes the differences between IPv4 and IPv6, and in the process of drawing a parallel between the two versions of IP, this chapter reviews the major concepts and challenges that people manage in their current network. Thus, it provides a framework for the IPv6 discussion in the rest of the book. Chapter 2, “An IPv6 Refresher”—This chapter discusses the fundamentals of IPv6 and some of the areas that saw significant changes from IPv4. It covers the new addressing architecture,

xxvii

•

• •

•

•

•

•

•

•

the new header format and structure, the enhanced functions of ICMP, and the layer 2 addressresolution mechanisms. These are concepts fundamental to understanding any IPv6-related topic. For this reason, they are presented in detail here. Chapter 3, “Delivering IPv6 Unicast Services”—This chapter discusses the elements necessary for establishing unicast IPv6 connectivity, the foundation of all other IPv6 services. It covers the relevant protocols at the access, edge, and core of the network. The mechanisms enabling the transition from IPv4 to IPv6 are discussed along with recommendations on what IPv6 deployment approach to follow in relation to the existent IPv4 infrastructure that will have to host the deployment. Chapter 4, “IPv6 Routing Protocols”—This chapter covers the routing protocols available in IPv6. It parallels their implementation and operation to their IPv4 counterparts. Chapter 5, “Implementing QoS”—This chapter reviews, from the perspective of IPv6, the concepts relevant to implementing quality of service in IP- and MPLS-based networks. It also discusses deployment considerations relevant to the coexistence of IPv4 and IPv6. Chapter 6, “Providing IPv6 Multicast Services”—This chapter reviews the IP multicast concepts and protocols. It draws a parallel between IPv4 and IPv6 features, it explains the new mechanisms available in IPv6, and it provides examples that capture the various deployment options. Multicast deployment in conjunction with the various transition mechanisms is also discussed. Chapter 7, “VPN IPv6 Architecture and Services”—This chapter covers the topic of deploying VPN services in an IPv6 network. It reviews the VPN-related concepts and the deployment models. In closing, the chapter shows several topology examples with relevant configuration examples. Chapter 8, “Advanced Services—IPv6 Mobility”—This chapter covers the concepts of IP mobility and their implementation in IPv6. It discusses the improvements made, the remaining open issues, and various examples of applying the protocol to novel services. Chapter 9, “Securing IPv6 Networks”—This chapter starts with an analysis of the security threats faced by IPv6, the ones specific to the new protocol, and the ones shared with IPv4. The dual perspective is critical because the coexistence of the two protocols can provide new attack vectors on the IPv6-enabled network. The chapter also presents the tools and best practices available to secure IPv6 networks. Chapter 10, “Managing IPv6 Networks”—This chapter discusses the challenges faced in managing IPv6 networks; some challenges are rooted in the protocol specifics, whereas others stem from the availability of tools. It covers the applications and management systems that can be leveraged today to operate IPv6 infrastructures and services. Chapter 11, “Network Performance Consideration: Coexistence of IPv4 and IPv6”—This chapter provides relevant answers to the natural concern about the impact that IPv6 services will have on existing, revenue-generating IPv4 services and infrastructures. It provides guidelines on how to evaluate the IPv6 performance of network elements, and reviews the areas where the coexistence of the two protocols could lead to resource contention.

xxviii

PART II •

•

•

•

Chapter 12, “Generic Deployment Planning Guidelines”—This chapter is intended to assist the reader in planning the deployment of IPv6 services. It provides guidelines on estimating the cost of deployment. It also provides references to resources relevant to planning the deployment, such as getting IPv6 address space. The chapter also discusses the important aspect of education and training. Chapter 13, “Deploying IPv6 in an MPLS Service Provider Network”—This chapter covers the planning, designing, and deployment of IPv6 in an MPLS service provider network. Internet access and VPN services are rolled out in stages, and configuration examples are provided for each one of them. The chapter closes with examples on troubleshooting the IPv6 network and the services supported. Chapter 14, “Deploying IPv6 in an IP Service Provider Network”—This chapter covers the planning, designing, and deployment of IPv6 in an IP service provider network. The ensuing infrastructure is dual stack, end to end. The various services are built in stages, and configuration examples are provided for each one of them. The chapter closes with examples on troubleshooting the IPv6 network and the services supported. Chapter 15, “Deploying IPv6 in an Enterprise Network”—This chapter starts by presenting the steps taken by an enterprise to evaluate IPv6 at both network and host level. It shows the development of a few services addressing specific business needs. The planning, designing, and deployment of the IPv6 services are presented. The chapter closes with a section on network troubleshooting and its future evolution.

This page intentionally left blank

PART

I

Implementing IPv6 Services Chapter 1

The Case for IPv6—An Updated Perspective

Chapter 2

An IPv6 Refresher

Chapter 3

Delivering IPv6 Unicast Services

Chapter 4

IPv6 Routing Protocols

Chapter 5

Implementing QoS

Chapter 6

Providing IPv6 Multicast Services

Chapter 7

VPN IPv6 Architecture and Services

Chapter 8

Advanced Services—IPv6 Mobility

Chapter 9

Securing IPv6 Networks

Chapter 10

Managing IPv6 Networks

Chapter 11

Network Performance Considerations: Coexistence of IPv4 and IPv6

CHAPTER

1

The Case for IPv6—An Updated Perspective It is not only accepted but almost expected that an IPv6 book will try, often hard, to persuade the reader of IPv6’s importance and benefits. Countless pages have been written describing business models that would financially justify the deployment of IPv6. Sometimes innovative, other times controversial, the job of selling IPv6 has its role in challenging today’s tactical approach to planning network-related capital expenditures. But despite all these efforts, it might just be that the accelerated depletion of the IPv4 address space will remain the trigger for a massive upgrade of existing networks to IPv6. The authors decided to steer clear of selling IPv6, and to avoid providing business models for IPv6 services. Instead, we intend to present to the reader the IPv6’s value through technical arguments. We intend to provide a realistic perspective of IPv6, revealing its positives and negatives. This exercise, however, cannot be performed in absolute terms. For this reason, “the case for IPv6” is presented relative to the familiar frame of reference called IPv4. This approach is not original. It is in fact the title of an Internet Architecture Board (IAB) document (http://www.6bone.net/misc/case-for-ipv6.html). Some things have changed since that document was completed, so “an updated perspective” is seen as useful. A deployment perspective is maintained while discussing the various IPv6 topics throughout the book. The technology is presented in the context of each network service layer:

• • • • • •

Unicast connectivity Quality of service Multicast service Virtual private networks (VPNs) Security Mobility

This chapter follows the same structure. Each service is briefly reviewed in the context of the IPv4 world. The protocol limitations and deployment issues are singled out along with pointers to IPv6 solutions or improvements, with further pointers to the chapters of this book where these topics are detailed. This chapter prepares the reader for an IPv6 discussion with the help of this overview of today’s IPv4 services.

6

Chapter 1: The Case for IPv6—An Updated Perspective

Unicast Connectivity The delivery of IP services relies on an infrastructure that provides unicast connectivity between IP hosts. The foundation of such an infrastructure consists of three elements: addressing, routing, and forwarding. IP addresses represent a finite resource used in identifying hosts within private or global networks. The structure and allocation mechanisms of IP addresses are relevant in designing, deploying, and operating IP networks. A review of this topic is compelling; especially under the circumstances of a depleting IPv4 address space. After all, at the time of this writing, addressing is one of the main reasons for deploying IPv6. Routing and forwarding provide the mechanisms to move traffic between IP hosts. Whereas forwarding’s dependency on IP version is relatively straightforward, routing has multiple dependencies on addressing. For this reason, it is important to see whether any of the IPv4 routing challenges were resolved in IPv6.

Addressing IP addressing is a vast topic that influences most of the protocol layers and most of the services. It also represents a critical resource. This section briefly discusses address architecture and address allocation. For a complete and detailed presentation, the following books are helpful references:

• • •

IP Routing Fundamentals by Mark A. Sportack Internet Routing Architectures by Sam Halabi and Danny McPherson Routing in the Internet by Christian Huitema

IPv4 Address Architecture A little bit of history is necessary to understand the debate around the IPv4 address space depletion. An address is used to uniquely identify hosts within the network. Even in a flat nonhierarchical simple world, some minimum requirements on the address structure enable network elements to operate efficiently. In IPv4, the address has a fixed size of 32 bits. That would allow in theory up to 232 addresses or somewhere around four billion. It is important to note that at the time of its specification, these four billion possible addresses appeared to be more than adequate for years if not centuries to come. As soon as early 1990s, however, the Internet community had to introduce a number of changes in the address architecture and the address-allocation scheme to accommodate growing address needs. IPv6, which is based on 128-bit-long addresses, appears to be safe for centuries to come, but who says that history cannot repeat itself?

Unicast Connectivity

7

A considerable waste of IPv4 addresses was generated by two factors:

•

The unwise allocation of classful addresses; often entities with just a little over 255 hosts asked for a Class B, capable of accommodating 65,000 hosts.

•

Users were not challenged to justify their address requests. When people started to foresee address exhaustion, only 3 percent of the allocated addresses were actually in use!

The increasing number of hosts challenged the address space resources and led to the formalization of private addressing and Network Address Translation (NAT) as an addressconservation solution. The increase in the number of hosts is also matched by an increase in the number of networks and this leads to scalability problems for the routers. In 1994, the core routers had approximately 34,000 routes, doubling every year. By 2004, it was expected to reach millions routes. Variable-length subnet mask (VLSM), Classless InterDomain Routing (CIDR), and a new IP address-allocation strategy was the response to the routing table explosion. Although the core routing table size was predicted to grow from 34,000 to 80,000 between 1994 and 1995, in fact it reached 76,000 routes only in 2000 and about 160,000 in mid 2004. With IPv6 and its larger address space, one could fear that routing tables will further expand. Bigger addressing space might logically lead to more hosts followed by more networks. In reality, past experience has shown that the “number of hosts” and the “number of networks” are loosely related. With the proper aggregation mechanisms, partly driven by the right address-allocation strategy, the latter have been well under control. Assuming the same mechanisms are maintained and further enforced with IPv6, it is reasonable to believe that routing table size will remain within manageable limits.

NOTE

For more details on CIDR, and related topics, you can read the following RFCs: RFC 1517, RFC 1518, RFC 1519, and RFC 1520. Also, RFC 1887 provides some hints on the reasoning behind IPv6 address allocation, and architectural implications.

The address-conservation mechanisms cannot stave off for long the need for global IP addresses. Past and current Internet growth rates (source BGP table statistics— http://bgp.potaroo.net/) can be extrapolated to predict the time left before the complete exhaustion of all available IPv4 address space. Conservative studies estimate the IPv4 address-space exhaustion by February 2041, and the exhaustion of the IPv4 unallocated address pool by April 2020. More aggressive models predict even earlier dates such as 2009. These predictions are based on the underlying assumption that the current growth models will remain applicable for years to come, which is not necessarily accurate.

8

Chapter 1: The Case for IPv6—An Updated Perspective

IPv6 might change these assumptions. With the combination of the Internet as an attractive and accessible communications medium, and the emergence of communicating gadgets and devices of all kind (even the most unexpected ones such as phones, home appliances, cars, and so on) you must be ready to see them proliferate and stimulate a growth in Internet usage that cannot be extrapolated from past patterns.

Private Versus Public Addresses Public addresses are registered, globally unique, and can be used to provide reachability over the Internet. By contrast, private addresses are meaningful only within a closed, physical or virtual domain. In IPv4, private addresses have been always associated with unregistered addresses, which in return have been associated with nonunique addresses. There might be many reasons why an organization would want to use both public and private addresses. Public addresses are used to get connectivity across the Internet, to reach public resources. Private addresses are used to accomplish the following:

• • •

Increase the addressable space used internally

•

Protect the internal network from the public domain by preventing private addressing/ topology exposure

Avoid address registration pains Decorrelate from public addressing changes (for instance, at peering points) to save the renumbering hassle

RFC 1918 identifies two categories of hosts that could deal with private addresses:

• •

Hosts that do not require access to hosts in other enterprises or the Internet Hosts that need access to a limited set of outside services (e-mail, FTP, and so on) that can be handled by intermediate gateways

For these two categories, RFC 1918 further defines three blocks of private addresses that should not be routed over the Internet, and therefore free to replicate.

• • •

10.0.0.0/8—A Class A block 172.16.0.0/12—A Class B block 192.168.0.0/16—A Class C block

In an ideal world, privately addressed hosts would be confined to the private network, whereas only hosts with public addresses would be able to access the public domain. In reality, most hosts need to leave the private network boundaries at some point. Usually, there are not enough public addresses for all hosts in the private network, so further mechanisms are necessary to interface them with the public domain. The simplest one is NAT, discussed in the section “Network Address Translation.” One of the benefits of the private address space is the large number of addresses available at the discretion of an enterprise. It was, however, only logical to expect that the private address space will face depletion similar to the overall IPv4 address space. In 2005,

Unicast Connectivity

9

multiple-systems operators (MSOs; or cable operators) reported the fact that they are running out of private address space. This is due to the proliferation of cable modems, Voice over IP (VoIP) phones, and set-top boxes they have to manage over IP. This realization accelerated their plans to deploy IPv6 if not to provide services at least to manage their devices. Some of the reasons to use private addresses become obsolete with IPv6 (there are now plenty of public addresses for everyone) although others will remain. VPN solutions exist for IPv6, too, and that could be sufficient to safeguard the privacy of addressing used within a network. The plethora of IPv6 addresses had suggested some different paradigms for private addressing, in particular the concept of unique yet private address. These concepts are presented in Chapter 2, “An IPv6 Refresher.” The concepts and issues that arose when crossing the boundary between private and public domains are presented in Chapter 7, “VPN IPv6 Architecture and Services.”

Static Versus Dynamic Addresses Addresses can be assigned to IP nodes either statically or dynamically. The static addresses are allocated “indefinitely” or until explicitly removed. Dynamic Host Configuration Protocol (DHCP) allows a computer to have a different IP address each time it connects to a network. This process enables multiple users to overload the use of a pool of dynamically assigned addresses. DHCP also enables mobile hosts to attach to visited subnets without requiring manual reconfiguration. In reality, dynamically allocated addresses might not change often either. In large networks, DHCP servers tend to allocate the same address to the same host over time, unless there is some shortage. For the home environment, there are two categories of users:

•

Users with dialup connections will change their address often. Most Internet service providers (ISPs) make use of DHCP to assign an IP address to each user for the length of time they are connected, and reuse it for another customer after the dialup connection from the previous customer has been terminated.

•

Users with long-life connections such as Digital Subscriber Line (DSL), Integrated Services Digital Network (ISDN), or cable will tend to keep their address for a longer period of time.

There are now advantages and disadvantages with the trend to use more stable source addresses than there were in the past. From a network operation perspective, one could find useful that the same user stays behind the same IP address; it is easier to manage, bill, filter, authenticate, and so on. However, this operational model eliminates address reuse, which conserves the IPv4 address space. For this reason, broadband services are a significant catalyst in the acceleration of IPv4 address consumption. When the address-shortage concerns are eliminated with the adoption of IPv6, there could be a tendency to allocate static addresses, or allocate dynamically the same address to the same user all the time. The advantages of having the IP address uniquely and permanently identify the device are counterbalanced by possible privacy issues. The same address used in multiple contexts (for instance, web surfing, gaming, and so on) can

10

Chapter 1: The Case for IPv6—An Updated Perspective

be used to correlate seemingly unrelated activities. Note that with IPv6, which offers the possibility of using addresses that embed topological information such as link identifier, the concern will grow. The mechanisms to allocate IPv6 addresses dynamically are reviewed in Chapter 3, “Delivering IPv6 Unicast Services.”

Renumbering Want to know a network administrator’s worst nightmare? It is renumbering. Renumbering is the process of replacing existing network prefixes and host addresses considered as deprecated throughout the network with new ones. There can be a large variety of reasons for renumbering:

•

The topology outside the network has changed (for instance, because the ISP providing Internet access has changed).

•

The network is expanding, hence the internal topology is changing; more subnets need to interconnect; a reorganization of the existing ones; more hosts to address; and so on. Renumbering, although not always required in these cases, could potentially improve aggregation and is sometimes highly recommended.

•

The network is merging with another one (for instance, in the case of two companies merging).

•

The network was private and disconnected from the public network, and now wants to provide public access to its hosts and servers.

The complexity of the renumbering process comes from the fact that addresses are used in many different places within a network and for many different reasons. A single address or a set of addresses may have been configured statically or dynamically in various places such as the following:

• • • • •

BOOTP or DHCP servers Applications servers of all kinds (HTTP, FTP, mail, and so on) Routers (interfaces, routing, and access lists configuration, and so on) Firewalls (access list) DNS servers

Sometimes, simply changing the old address can make the new one operational; in many cases, however, the old address has been leaked in caches of all kinds (DNS caches, applications caches, routing caches, web caches, Address Resolution Protocol [ARP] caches). Many of these caches have expiration timers, which will make them invalidate the “old” addresses, but some do not. In most cases, changing the address and network prefix requires rebooting the host. When addresses are cached throughout the network, delays (mostly “uncontrolled”) will occur before the new addresses are operational. Although some believe that renumbering issues have been entirely taken care of in IPv6, others believe that renumbering remains a problem without any good solution. The truth

Unicast Connectivity

11

lies somewhere in between. The renumbering issue is multidimensional, and IPv6 brings some innovative solutions in some areas, although it does not solve the entire problem. Chapter 2 and Chapter 3 describe some built-in IPv6 mechanisms such as link-local addresses, autoconfiguration, and support for multiple addresses on the same interface that can ease aspects of network renumbering.

Network Address Translation Network Address Translation (NAT) has brought the best and the worst to IP deployments. Per NAT RFC authors, NAT was a short-term solution to enable address reuse and solve the address-depletion issue the IP Internet community was anticipating in 1993. That worked out well indeed, and what seemed to be a critical issue in 1993 is less critical more than 10 years later. NAT has enabled private addressing in all sorts of corporate networks, eliminating the need for publicly registered chunks of addresses. Nevertheless, NAT is a controversial subject in the networking community, and for that reason we dedicate this section to it. For technical background and more details on NAT principles and operations, refer to RFC 1631 and books such as the Cisco Press book Routing TCP/IP, Volume II (CCIE Professional Development) by Jeff Doyle. Over the years, NAT has been deployed widely throughout the Internet. During this time, its use was given justifications beyond address conservation: from security to privacy, from preventing renumbering to providing highavailability mechanisms, from deployment of virtual clusters to providing Internet access over VPNs. Each of these justifications was prompted by some deployment scenario and was meant to solve deployment issues. Although some of these reasons will become irrelevant after IPv6 is deployed, not all of them will. Although NAT has hurt the deployment of many applications, and many people would be happy to see this so-called “short-term” solution go away with IPv6, it will be interesting to understand and analyze NAT’s place in today’s networks and the problems it addresses. If we want to rid the world of the evil NAT, we must make sure IPv6 offers solutions for all problems NAT resolved. NAT comes with a number of issues, out of which the most significant is the connection model that it implies. NAT is asymmetrical. Because of the way NAT works, it is mainly usable for client/server sessions where clients within the private network initiate the session with servers sitting in the public network. The client will typically issue a Domain Name System (DNS) query for some public server name, and get the public server address. On the way back, the server will see only the public NAT address, expectantly a globally reachable one. Going the reverse direction is more troublesome. Anybody sitting outside the private network (either on the public network or on a different private network) would have difficulties reaching a host behind NAT. Some proxy servers can be used as “middlemen”: They can handle all necessary application signaling and enable hosts to use each others NAT addresses as the reachable public

12

Chapter 1: The Case for IPv6—An Updated Perspective

address. Session Initiation Protocol (SIP) is a good example of such a solution. However, twisting every single peer-to-peer application to make it fit the client/server model appears to be a great limiting factor to the adoption and deployment of new applications. Another issue with NAT is that it does not look at any information above IP/TCP/UDP/ ICMP layers. Some applications have endpoint source addresses buried within their messages, which do not get translated by NAT at the same time as the IP header addresses. This typically happens with applications such as H.323 that tend to establish multiple connections within a single session. To solve those issues, application layer gateways (ALGs) may need to perform complex application-level translations. When an application that required an ALG is deployed, NAT devices must support this particular ALG. NAT has some security issues, too. Any security mechanism based on signing or verifying part of the packet, whether header or payload including IP addresses, will have trouble when addresses are overwritten. For instance, with IPsec, both Authentication Header (AH) and Encapsulating Security Payload (ESP) have issues with NAT, although at a different order of magnitude.

Can IPv6 Eliminate NAT? NAT is used in the networks of 70 percent of Fortune 1000 companies, for better and worse. So, either NAT is not necessary anymore after IPv6 is deployed, and the worst is gone. Or, IPv6 does not have a proper solution for all deployment scenarios where NAT is in use and these networks will not transition. Although the large IPv6 address space eliminates the need for NAT, it is important to explain how IPv6 also provides similar capabilities as the “perceived” benefits of NAT. This is the main purpose of Network Architecture Protection (NAP), an Internet Draft addressing each NAT benefit (real or perceived) and matching it with an IPv6 solution. Table 1-1 lists NAT features, and for each, it provides pointers to IPv6 documentation (RFC, Internet Drafts, and so on) and refers to chapters of this book where solutions are reviewed. Table 1-1

IPv4 NAT vs. IPv6 NAP NAT Feature

IPv6 Reference

More Details In

Address depletion

IPv6 Addressing Architecture, RFC 3513

Chapter 2, section “IPv6 Address Architecture”

Address management

Preferred lifetime per prefix & multiple addresses per interface (ID)

Chapter 2, section “IPv6 Address Architecture”

IPv6 Unique Local Addresses: RFC 4193

Chapter 2, section “IPv6 Address Architecture”

IPv6 auto-configuration: RFC 2462

Chapter 3, section “IPv6 Provisioning”

Procedure for Renumbering an IPv6 Network without a flag day: RFC 4192

Chapter 3, section “IPv6 Address Renumbering”

IPv6 VPNs (ID)

Chapter 7 “VPN IPv6 Architecture and Services”

Unicast Connectivity

Table 1-1

13

IPv4 NAT vs. IPv6 NAP (Continued) NAT Feature 1

Site multihoming

IPv6 Reference

More Details In

Goals for IPv6 Site-Multi-homing Architectures: RFC 3582

Chapter 4, section “Site Multihoming”

IPv6 Multihoming Support at Site Exit Routers: RFC 3178 Architectural Approaches to Multi-homing for IPv6: RFC 4177 Server load balancing2

Chapter 8, section “Server Load Balancing”

Failover3

Chapter 15, section “Enabling Cisco HSRP for IPv6”

End-system privacy

Privacy Extensions for Stateless Address Auto-configuration in IPv6: RFC 3041

Chapter 2, section “IPv6 Addressing”

Topology hiding

IPv6 Network Architecture Protection (NAP) (ID)

Chapter 2, section “IPv6 Addressing”

MIPv6 tunnels: NAP (ID) and RFC 3575

Chapter 8, section “Topology Hiding”

IPv6 Unique Local Addresses: RFC 4193

Chapter 2, section “IPv6 Addressing”

Recommendations on IPv6 Address Allocations to Sites: RFC 3177

Chapter 13, “Deploying IPv6 in an MPLS Service Provider Network”

DHCP-PD Customer prefix upstream: NAP (ID)

Chapter 3, section “IPv6 Provisioning”

VPN Internet access4

Simple gateway

Chapter 7, section ”Addressing Considerations”

SLACC via RA downstream: NAP (ID) Simple security

Context Based Access Control (ID)

Chapter 9 “Securing IPv6 Networks”

Local usage tracking

Address Uniqueness: RFC 3513

Chapter 2, section “IPv6 Addressing”

14

Chapter 1: The Case for IPv6—An Updated Perspective

Table 1-1

IPv4 NAT vs. IPv6 NAP (Continued) 1A multihomed site can use NAT to translate the various provider addresses into a single set of private-use addresses. 2NAT can be used to load balance traffic over a set of servers by hiding their individual addresses behind a single NAT

address. Other techniques can be used for the same purpose, which do not rely on NAT, and can work with IPv6. 3NAT

is used in some high-availability scenarios by hiding active and standby hosts or routers addresses behind the same virtual address. Other techniques can be used for the same purpose, which do not rely on NAT, and can work with IPv6, such as HSRP (Hot Standby Router Protocol), VRRP (Virtual Router Redundancy Protocol), and GLBP (Gateway Load Balancing Protocol).

4Sites

or individual hosts configured with private addresses use NAT to expose a public address (rather than their private address) when connecting to a public resource.

In addition to verifying that IPv6 deployments do not create issues in areas where NAT has a specific purpose, you will also have to examine coexistence issues. Because IPv4 and IPv6 are likely to cohabit for a significant period of time, you need to know whether there are any IPv6 deployment issues with regard to traversing IPv4 NATs. Indeed, many of the transitioning mechanisms that Chapter 3 describes involve tunneling IPv6 traffic over IPv4. These IPv4 networks are full of NAT, and being able to properly traverse them is critical to IPv6 deployment.

Routing The engineering community has not really touched the routing foundations of unicast services in the context of IPv6. Of course, whenever an IPv4 routing protocol had some dependencies on IPv4 addresses, work was done to produce an IPv6 version of it. This is the case, for instance, with OSPFv3. Chapter 4 “IPv6 Routing Protocols,” reviews these changes in the routing protocols. But besides “cosmetic differences,” all IPv4 routing protocols are closely matched in IPv6, sharing the same design, often the same implementation, with the same area of applicability and the same issues. In IPv6, you will find the familiar Routing Information Protocol (RIP), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and Border Gateway Protocol (BGP). Are you disappointed? You might have expected the IPv6 designers to take advantage of the new address structure to enhance the way routers handle network prefixes to achieve better aggregation. This would have indirectly led to new or significantly modified routing protocols. The opportunity was offered in the way the IPv6 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, these attempts have not materialized into an innovative routing protocol. CIDR with BGP aggregation and allocation policies remain the solution for optimizing aggregation in IPv6, too.

QoS Services

15

QoS Services Packet-switched technologies are well suited for data communications, which, at first, did not care as much about timely delivery or resource reservation. With packet-switched technologies, the faith of packets is entrusted entirely to the best efforts and good will of the network. Although not reassuring, the approach is more flexible and allowed these technologies to develop faster than the circuit-switched ones. Besides being capable of multiplexing the user traffic, they offer features that could easily enable new, revenuegenerating services on existing networks. The success of packet switching led to an ever-expanding set of applications leveraging IP. It was not long before time-sensitive applications were IP enabled, and they required special handling of their packets, especially under congestion conditions. Because not all applications have the same requirements, the IP infrastructure must be enabled to offer different levels of service for their traffic. Services can be grouped in several types depending on packet drop, delay, and delay-variation constraints. These constraints are driven by applications such as interactive voice communications, audio, and video that are sensitive to delay and delay variations (jitter), but they can afford to lose randomly a small percentage of the traffic. At the other end of the spectrum is the missioncritical application that needs reliable, no-loss data transfers while placing a lower emphasis on timing requirements. The service level is an end-to-end concept that qualifies a mode of handling traffic based on its various characteristics such as type, content, source, and destination. Deploying QoS in a network enables it to support various levels of service. For some, the well-being of their network and proper support of deployed applications depend on it. For others, QoS is a revenue source based on contractual agreements called service level agreements. IPv4 QoS is implemented through two architectures. Integrated Services (IntServ, as in RFC 1633, was modeled based on the concept of circuit). In this case, the user, with the help of a signaling protocol called Resource Reservation Protocol (RSVP; RFC 2208), reserves the resources end to end before sending the data. Differentiated Services (DiffServ), described in RFC 2475 and RFC 3260, is the second architecture, and it relies on the information carried within each packet to make resource-allocation decisions at each network node. This approach is simpler and more dynamic; however, it requires a good understanding of the traffic profiles in the network and a consistent end-to-end implementation of policies. DiffServ is a widely adopted QoS deployment architecture. Although the QoS concepts are reviewed in Chapter 5 “Implementing QoS,” in-depth information on them and their deployment strategies can be found in various specialized books such as IP Quality of Service, a Cisco Press book by Srinivas Vegesna. With the dramatic increase of traffic transported over packet networks and the demands of the various services and applications supported, it is difficult to understate the value of QoS in today’s IPv4 networks. The same holds true for IPv6. Some hoped for an improved

16

Chapter 1: The Case for IPv6—An Updated Perspective

QoS in the next generation of the IP protocol, and some still believe that IPv6 is better than IPv4 in this respect. The reality is that neither evolutionary nor revolutionary changes were made to IPv6 versus IPv4. Some claim radical QoS improvements in IPv6. These are but a myth at the time of this writing. The same concepts and architectures apply to the new protocol with few and insignificant differences that are discussed in Chapter 5 of this book. An additional packet header field (Flow Label) is believed to hold the potential for improving the QoS mechanisms, but the means to use it are still being evaluated. Although there appears to be no significant differences between IPv4 and IPv6 QoS today, things might shape up differently going forward. IPv6’s aim to reestablish a peer-to-peer model for IP transport will most definitely change the current approaches on deploying QoS. IPv6 networks hold the potential to implement true end-to-end service level policies. But for now, IPv6 is content to follow in the footsteps of its predecessor.

Multicast Services Simply stated, the problem solved by multicast is this: allow one host to talk to several others without bothering everyone else. In a world with limitless resources, the solution is not difficult—the source would replicate the data stream into multiple unicast streams destined for all interested parties. In the real world, this obviously is not a scalable approach. On one hand, it would overburden the source, and on the other, it would have a tremendous impact on the network whenever bandwidth-intensive traffic such as video is transmitted. A scalable alternative is to let the network replicate the data as needed. In a “multicast-aware” network, the data stream is replicated along the way, by the network elements, at points where paths to various destinations converge. A set of dedicated protocols ensures that this data is delivered with optimal utilization of the underlying IP infrastructure, while selecting shortest paths with minimal delay between the source and the destinations. The demand for multicast services is on the rise, driven by the need for collaborative, real-time information sharing. A wide range of multicast-based applications made their way into both enterprise and service provider types of networks:

•

Enterprise networks—Distribution of financial information (such as stock quotes), distribution of news, videoconferencing, and delivering content to employees (for example, software updates or facilitate distance learning)

•

Service provider—Content delivery such as video and audio streaming, collaborative applications such as conferencing for enterprise customers or multiplayer gaming and chat for residential customers

Despite the interest it generates, multicast took a long time and a lot of creative thinking to be developed to the level of a reliable, manageable, and high-performance service offering. Multicast is deployed on top of an existent IP unicast infrastructure and conceptually it deals with the same issues of addressing, routing, and forwarding, but sometimes from a

Multicast Services

17

radically different perspective. You can find a detailed presentation of the IPv4 multicast operation and its deployment guidelines in Developing IP Multicast Networks, Volume 1 by Beau Williamson. Multicast came as an afterthought in IPv4 and it had to deal with many of the limitations built in to the protocol up to that point. Some of these intrinsic constraints become more evident as productivity-enhancing applications and customer requirements drive up the number of networks that deploy multicast services. By contrast, IPv6 multicast gained a prominent role from the start and it was developed alongside unicast. This offers the unique opportunity to make it a ubiquitous service from day one. The operation and benefits of IPv6 multicast are discussed in Chapter 6 “Providing IPv6 Multicast Services.” However, no dramatic changes should be expected; both implementations are built on the same principles. IPv6 took advantage of the larger addresses and larger addressing space while following a more practical approach with respect to multicast routing protocols selection based on the lessons learned with the IPv4 multicast services. The following are some of the issues that IPv4 multicast faces:

•

Limited availability of globally unique group addresses. This is an expected problem generated by the limited allocation of IPv4 addresses for multicast purposes. IPv6 provides plenty multicast addresses to facilitate the deployment of the service.

•

Limited availability of MAC address for layer 2 multicast address mapping. IPv6 is facing a similar problem.

•

Rendezvous Point (RP) scalability problems in large multicast domains. IPv6 provides additional mechanisms that facilitate RP to multicast group mapping.

•

Complex mechanisms used to contain multicast control and data traffic within multicast domains. Through address scoping, IPv6 offers elegant new ways to mange the multicast traffic.

•

RP source registration information synchronization is done through the MSDP protocol, a protocol that was meant to be a temporary solution for this function. No further development was done on the protocol for a couple of years. No mechanism is yet available in IPv6 to perform these functions.

•

The adoption of MPLS by most service providers and deployment of MPLS/VPN services are a challenge for multicast. Currently there is no mechanism available to support label switching of multicast. At best, multicast traffic is forwarded without leveraging the MPLS infrastructure. An additional control mechanism is needed in order to isolate the multicast traffic within each VPN. A stop-gap solution called Multicast VPN (MVPN) is currently offered in Cisco IOS. Nevertheless, with MPLS commonly deployed in Service Provider networks and making its way into the large Enterprise ones, a comprehensive solution to the “multicast over MPLS” problem is important not only for IPv4 but equally important for IPv6.

18

Chapter 1: The Case for IPv6—An Updated Perspective

NOTE

It is important to point out that MVPN isolates the multicast control plane within each multicast VPN routing and forwarding table (VRF). From a forwarding perspective, the multicast traffic is Generic Routing Encapsulation (GRE) encapsulated and IP forwarded. With MVPN, the multicast traffic is not MPLS labeled even though it might be deployed with MPLS based VPNs.

IPv6 multicast continues to evolve and develop. It adapts to practical market requirements such as Triple Play services and collaborative applications. Chapter 6 discusses the IPv6 multicast protocol set. It also covers the deployment options and improvements with respect to IPv4 multicast, demonstrating that IPv6 is well instrumented to deploy and support multicast services.

Virtual Private Networks The Internet has become for most corporations, campuses, and other isolated networks a shared infrastructure to provide connectivity for their mobile workers or to interconnect distributed locations. Private networks over a shared infrastructure have been deployed since the infancy of the Internet and even before with proprietary protocols or standards such as X.25. After all, 20 years ago, one could dial from home in to his corporate network and upload or download data. What has changed is the virtualization of the links providing the connectivity. Furthermore, the method used for sharing these logical links has moved up from layer 1 (using Time Division Multiplexing, TDM) to layer 2 (X.25, Frame Relay, or ATM Virtual Circuits) to layer 3 (PPP IP tunnels). While so many corporate networks started to use this shared infrastructure, they inevitably started to worry about security. Their sensitive data is being exposed to others on the shared links. Their hosts and servers, connected to a public shared network, can be reached from anywhere by anybody, including malicious hackers. The VPN technology enables telecommuters to connect to their office network (and enterprises to connect their sites together) over a public infrastructure. It has mechanisms that offer security and quality of service. For a complete and detailed presentation on this topic, refer to VPN Applications Guide by David McDysan, and MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard. A review of the reasons for deploying IPv4 VPNs is a useful step toward analyzing whether the concept of VPN applies to IPv6 networks. Here is a nonexhaustive list of some of the VPN benefits, whether real or perceived as such:

Virtual Private Networks

19

•

Cost savings—The Internet has become so ubiquitous, almost everybody can plug into it, potentially enabling connectivity with everybody else. Because it is geographically spread everywhere, corporate users do not need anymore to dial long distance to reach remote corporate resources.

•

Extended connectivity—This is the concept of distributed and dynamic “closed user groups,” where the VPN includes various networks with different privileges and excludes others. In a controlled way, this can include telecommuters and temporary users such as customers, partners, and so on.

•

Easy address-allocation process—Addresses can be allocated from the IPv4 private address range. There is no need to coordinate the allocation through a control organism as long as the communications stay in the VPN.

•

Simplification of the renumbering process—Private addresses are less sensitive to external events, such as public addressing changes.

•

Services—VPN can be used to deploy services not offered by the public network on a general scale.

•

Security—VPNs have some built-in mechanisms to provide secure communications over the public infrastructure. One could argue that the deployment of VPNs is creating the problem that it then claims to solve. A bit of a sophism here!

•

Privacy—The internal addresses are private to some extent because they are not published outside the private infrastructure.

•

Growth options—Using small roads to interconnect remote sites makes it difficult to transport a lot of traffic when needed. Using shared highways provides opportunities to grow and to handle peaks as needed.

•

Address-depletion protection—Some big organization might need more addresses than the IANA is ready to give up. VPNs enable it to use private address space and not worry about exposing these addresses over the public network.

Out of these benefits provided by VPN, some are perceived benefits, in the sense that they are not directly provided by VPN technologies. The protection against address depletion, for instance, is in fact achieved through NAT. Nodes in a private site are likely to require public resources access and will need public addresses to do so. To limit the number of these public addresses required, some other technology is needed, to expose a public address on these nodes behalf (one for many). This can be NAT or an application proxy. So, are VPNs still useful with IPv6? The question is worth asking. Why would IPv6 customers ever need to deploy VPNs when they can get all the addresses they want? Why split the global address space into smaller chunks, if it is guaranteed that none of these addresses will ever overlap? In an ideal world full of honest people, that is probably true. This is

20

Chapter 1: The Case for IPv6—An Updated Perspective

precisely what VPN technology does not assume. It does not deal with issues of overlapping address space, but rather intends to isolate address spaces, and communications, to protect against malicious users. With IPv4, address-space overlapping simply becomes a by-product of VPN and NAT. 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 the same: 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, by design, IPv6 does not support NAT. These differences do not drive fundamental requirement or technology divergence. But, they do have some consequences in various deployment scenarios. Chapter 7, “VPN IPv6 Architecture and Services,” reviews IPv6 VPN technologies in detail and addresses the differences with IPv4. Chapter 13, “Deploying IPv6 in an MPLS Service Provider Network,” provides in-depth VPN deployment hints.

Security Software applications and network infrastructures are mission-critical elements in today’s economy. Those who use these resources as well as those who intend to abuse them understand their value. Security is a broad term that encompasses all the steps taken to evaluate the risks these resources are exposed to and implement the measures to counter them. Examples of threats and countermeasures include the following:

•

Software application attacks, denial-of-service (DoS) attacks, virus distribution, and data security breaches

• •

Network infrastructure attacks, attacks on the network elements Interception of data exchanged across public domains

IP security is not only a concern for enterprise networks; it is a concern even at the smaller scale of home networks. Internet access is becoming part of our daily lives whether we use it for online banking, VoIP, or information gathering. Attackers take this window to the larger world to be their door into the privacy of our own lives. In some contexts, security takes a network management and operational perspective, although in others it becomes a service. Both aspects are interesting, but in the end security has to be looked at and implemented in a holistic and consistent manner. For this reason, the topic is rather vast, and it grew to be this way through the relentless efforts of creative attackers. The reader can get a complete and detailed picture of the IPv4 network security challenges and solutions from books such as Sean Convery’s Network Security Architectures.

Security

21

Cisco SAFE Blueprint is a comprehensive set of references and design guides on securing various types of IPv4 networks and the services they deploy. One of the most common misconceptions with respect to IPv6 is that it is more secure than IPv4. It is believed that when you eliminate NATs, IPv6 enables fully secured traffic to transparently cross the boundary between public and private domains. The peer-to-peer communications model reinstated by IPv6 enables the endpoints to secure their information exchange. This is a good idea if implemented by all endpoints. Otherwise, it could instill a false sense of security. Without having everyone participate in this new security paradigm, some RFC-obeying users might be left with a false sense of security. It all started with the good intentions of RFC 2401 that mandated the use of IP Security (IPsec) with IPv6. Although the mandated observance would bring without a doubt a higher level of security, its success would depend on a consistent and proper implementation of IPsec on all applications and networked devices. Until then, IPv6 is equally secure or insecure as its counterpart is. In fact, most IPv6 deployments to date do not leverage any encryption, and that makes them more vulnerable. The operational lessons learned from securing IPv4 networks and applications have yet to be all applied to IPv6, and this offers attackers extra opportunities during this transitional phase. Overestimating how secure IPv6 is could be dangerous. However, it would be unfair not to mention the committed effort made by the networking community to anticipate and provision for protocol security holes in IPv6. For new protocols that could be built with embedded security from the start, the topic was deemed so important that it blocked the standardization process until it was properly addressed. A good example is Mobile IPv6 (MIPv6), which embedded security in the route-optimization process and provisioned for control steps to secure the binding-update process. For protocols already built on the structure of their IPv4 counterparts, dramatic changes were avoided for practical reasons, and only limited tweaks were implemented. An example in this category is OSPFv3, which replaced the Message Digest 5 (MD5) authentication with IPsec AH and ESP headers to provide integrity, authentication, confidentiality, and anti-replay protection of routing information exchanges. Because of their similarities, IPv6 inherits the vulnerabilities of IPv4. For the common threats, the same countermeasures are applied. There are, of course, security improvements as well as new threats that stem from IPv6’s idiosyncrasies, and these are discussed in Chapter 9, “Securing IPv6 Networks.” It is also important to address the entire area of IPv6 transition mechanisms. In this case, the various tunnel types open the door for IPv6 attacks, but more important, they provide opportunities to circumvent the security measures protecting the underlying IPv4 infrastructure. In addition, changes made to IPv4 security measures and devices to accommodate IPv6 migration mechanisms can weaken an IPv4’s network defense. Standardization work is being done to address these security risks, but for the time being they remain a concern.

22

Chapter 1: The Case for IPv6—An Updated Perspective

These topics are further discussed in Chapter 9. The final word in security risk assessment and best-practices recommendations will come from the operational experience that will be gained while managing large IPv6 deployments.

IP Mobility The Internet has become so pervasive that no matter where you are, you can plug your computer into a wall, or attach to a wireless LAN, and, after a while, you will be able to communicate. Is not this mobility? Well, not quite. That type of “mobility” is achieved by getting a new IP address within the network of attachment and losing all sessions bound to the previous IP address. This might be acceptable for corporate users moving from work to home, but can be much more cumbersome for road warriors, and it can be a showstopper for IP telephony. Mobile IP provides a network layer for hosts that enables them to maintain the same IP address no matter where they are in the Internet, and keep receiving traffic as they move. In Chapter 8, “Advanced Services—IPv6 Mobility,” MIPv6 is compared to MIPv4. Even though MIPv4 is a mature and deployable technology, it faces limitations because of the nature of IPv4. At the same time, IPv6 mobility is considered as one potential enabler for IPv6. The number of IP-enabled devices and the need for any-to-any communications among them is driving requirements that IPv4 cannot easily satisfy, and it is opening opportunities for IPv6. By integrating functionalities designed for Mobile IPv4 into standard IPv6 protocols, and by leveraging existing IPv6 capabilities, MIPv6 has built up a MIP model that is much more compelling than its IPv4 counterpart. It must be noted that enhancements to mobility are largely taking place in IPv6 related working groups, even though a fraction gets retrofitted into the IPv4 standards. Although MIPv6 has benefited greatly from its MIPv4 parent, it is now the driver of the evolution of IP mobility, and it is widely expected to be a foremost steering force for IPv6 deployments. In terms of deployment, it must be considered that IP mobility enables new flows, which impact the wireless infrastructure: Telephony over IP demands a higher level of coverage, latency, and QoS enforcement, whereas peer 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 that actually roam around the Internet as a usual behavior. Sales of consumer routers are plummeting. At the moment, they are related to IPv4 NAT operations. With IPv6, it can be expected that people will deploy unmanaged yet globally addressable networks at home. NEMO support by the home gateways would enable a service provider to deploy preprovisioned devices, and could save hundreds of thousands of networkrenumbering operations per year as customers move from one home to the next.

IPv6 Is an Evolutionary Step

23

At the core, MIP builds dynamic tunnels, and NEMO exchanges routes over those tunnels. In a way, this is a revamping of the traditional model of the core where BGP routers exchange the bulk of the Internet routes over peering tunnels. But whereas the model of the Internet is designed for fixed, aggregated routes that are locally injected and slowly distributed throughout its fabric, MIP and NEMO techniques enable a new model where routes are projected where and when they are needed, on-demand; this opens to a new level of hierarchy 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 a transitional method, a significant number of improvements must be made to cope with the latency of the protocol 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 designing and operating today’s networks. It is not meant to be the background of an IPv6 sale pitch, but rather a frame of reference for the IPv6 discussion in this book. The overview offered us the opportunity to highlight, from a practical perspective, the differences between the two versions of IP and forward reference the chapters addressing these differences. If you remember only one thing from this chapter, remember that IPv6 is an evolutionary 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 addressing shortage gave us a chance to take another look at how things can be improved. Now that we know what to expect from the new protocol, we are ready to talk about its implementation and deployment.

CHAPTER

2

An IPv6 Refresher IPv6 represents an evolutionary step for IP. Despite building upon IPv4 and the experience gained operating IPv4 networks, IPv6 has its own idiosyncrasies and unique functionality implementations. For this reason, you should familiarize yourself with the fundamentals of the protocol prior to looking into deploying it. This chapter 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 subsequent chapters from a deployment perspective. This chapter, however, focuses on a subset of IPv6 protocol characteristics that represent the foundation of its operation, as follows:

• • • •

IPv6 addressing IPv6 packet format ICMPv6 Neighbor Discovery

This chapter particularly emphasizes addressing for a simple reason: It represents one of the most important benefits 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 IPv6 protocols, this book focuses on reviewing the deltas from IPv4 and their impact on deployment. The following books 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. It provides the means to identify information sources and destinations while enabling dedicated resources to appropriately link the two groups together. This holds true whether we talk about the United States Postal Service or an IP network. The previous chapter briefly overviewed the IPv4 addressing structure and the challenges generated by a limited address space and its unwise use. The previous chapter also showed that the most

26

Chapter 2: An IPv6 Refresher

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 inevitable exhaustion of the IPv4 addressing space. The 32-bit long IPv4 address offers roughly 2 billion practically usable IDs. This set will not be able to withstand much longer the growing needs of a rapidly increasing number of users who require unique, globally reachable IP addresses. The natural solution is to increase the address space. The 128-bit long addresses were selected despite more aggressive proposals put forward during the development of IPv6. One might find 2128 or 340,282,366,920,938,463,463,374,607,431,770,000,000 addresses to be excessive. However, there was a 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 into consideration 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) IPv4 addresses in one pass; whereas for IPv6 addresses, the same requires four passes. 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 32 characters, and it appeals to programmers. This representation is still long enough to make it hard to remember, so the string of 32 hexadecimal characters was given some structure and segmented into 8 groups of 4 characters (or 16 bits) separated by a colon (:). The decimal representation, like the one used 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 0s can be eliminated. This means that you can write :00A1: as :A1: (see Figure 2-1).

•

The elimination of consecutive 0s—You can collapse consecutive all-0 groups of 16 bits between consecutive 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, the consecutive-0s rule can be applied only once. It is incorrect to compress the address in the Figure 2-1 example 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 enclose the IPv6 address in a URL in brackets, as shown in Example 2-1.

IPv6 Addressing

Figure 2-1

27

IPv6 Address Representation

0010000000000001000000000000000000000000000000000000000010100001

0000000000000000000000000000000000000000000000000001111000101010

20010000000000A10000000000001E2A 2001: 0000: 0000: 00A1: 0000: 0000: 0000: 1E2A Consecutive 0s Leading 0s

2001:0:0:A1: : 1E2A

Example 2-1 Using an IPv6 Address Within a URL Address: 2001:0:0:A1::1E2A URL address: https://[2001:0:0:A1::1E2A]:7878/webpage.html

Note that the preceding address is shown with an optional port ID of 7878.

IPv6 Address Architecture Understanding the IPv6 address representation enables us to discuss the IPv6 addressing architecture defined 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 a single node.

•

Multicast—Identifies a group of nodes, and traffic destined to a multicast address is forwarded to all the nodes in the group.

•

Anycast—Identifies a group of nodes, and traffic destined to an anycast address is forwarded to the nearest node in the group.

All of these address types were present in IPv4, along with broadcast addresses. Broadcast traffic was shown to be too resource intensive (during regular operation as well as during broadcast storms), so IPv6 ignores it and uses multicast addresses instead.

28

Chapter 2: An IPv6 Refresher

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 IP version, 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, grouping multiple addresses under a common representation. To facilitate this process, IP addresses are segmented in a network portion that identifies a logical group of hosts and a host portion that identifies the host within the group. Hosts are aggregated under the same network or prefix. IPv4 demonstrated the constraints of a class-based addressing architecture, so IPv6 allows variable lengths for the network portion 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 the IPv4 terminology host portion up to this point in the context of IPv6 addresses. IPv6, however, prefers to identify the interface of a host within a prefix rather than the host itself, which could have multiple interfaces. For this reason, the IPv6 addresses are segmented into a prefix or network portion and the interface 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/64 Network portion: 2001:0:0:A1 Interface identifier in non-compressed format: :0:0:0:1E2A Interface 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 be constructed in Modified EUI-64 format.” The rule reveals the intent to maintain a globally unique character for the interface ID whenever possible. You can generate an interface ID in many different ways:

•

Build one from the layer 2 address in the modified EUI-64 format. For the interface ID portion of the network, the seventh high-order bit of the EUI-64 format defines a local scope when set to 0 and a global scope (globally unique) when set to 1. Different mechanisms are defined for each media type to build the complete interface ID in the modified EUI-64 format (see the references in the section “IPv6 and Data-Link Technologies” later in this chapter).

•

Autogenerate a random address as defined in RFC 3041. This assignment mechanism was developed 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.

IPv6 Addressing

• •

29

Manual configuration. Cryptographically generated addresses (CGAs) based on RFC 3972 through a hash that includes a public key. This method of generating an interface ID provides added security and enables address authentication. The Neighbor Discovery process described later in this chapter is secured with the help of CGAs.

The network portion of the address is further refined in the case of IPv6 to integrate the concept of scope. The scope identifies a network domain, be it physical or logical. Being able to easily recognize the scope of an IP stream enables a network to better manage its resources by containing the traffic within the relevant domain and by applying policies relevant to that scope. The IP address is an essential element in making layer 3 forwarding decisions, so it should reflect the scope. Hosts would use the appropriate 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 addresses used within this scope are called link-local addresses.

•

The unique-local scope—Identifies all devices reachable within an administrative site or domain that typically contains multiple distinct links. The unicast addresses used within this scope are called unique-local addresses (ULAs).

•

The global scope—Identifies all devices reachable across the Internet. The unicast addresses used within 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

Global Scope

Site Local Scope

Link Local Scope

Unique local

The link and global scopes represent the two extreme cases, the smallest and the largest scopes. This distinction makes it easier to define them. RFC 3513 identifies a site-local scope that fits logically between the link and global scopes, although its definition is open for interpretation. A site can mean different things to different people. It can be a

30

Chapter 2: An IPv6 Refresher

corporate network, a geographically constrained portion of a corporate network, or simply an administered domain within a corporate network. Because IPv6 addresses are structured based on scope, the ambiguity in site definition increases the complexity of IPv6 features and implementations. The original definition of the site scope also left the door open for the use of nonunique site-local addresses with their drawbacks (discussed later in the section). For these reasons, on March 20, 2003, the IETF IPv6 working group deprecated the site-local scope and the corresponding 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-local scope and the site-local addresses did not go away quietly. Enterprises are accustomed to the safety and the advantages of a site-relevant, private addressing scheme— the good old 10.x.y.z network—so they pressed 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 the concept of a site scope by using local in its name while emphasizing the “nearly” uniqueness of the addressing used within the site. Depending on an IPv6 node’s complexity, it may or may not be aware of the scope information carried within the structure of a unicast address. Routers, however, must be aware of scoping to a certain degree because they have to keep traffic within the scope of its destination or source address. Because hosts typically communicate within more than one scope, interfaces have an address for each of the scopes 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 address that can be used for communication exclusively with other hosts on the same link. The local link defines the scope of these addresses, so packets that have them as SA or DA should never be routed to other links. These addresses are called link-local. They are used for on-link communication as well as link 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 network portion of fixed format FE80::/10, where the high-level 10 bits are 1111 1110 10, and the subsequent 54 bits are 0. As mentioned earlier, in IPv6 the interface identifier terminology is used instead of the host portion of the address, as shown in Figure 2-3. Example 2-3 shows the link-local address of an Ethernet interface with the interface ID generated based on the layer 2 MAC address.

IPv6 Addressing

Figure 2-3

31

Link-Local Address Structure 128 bits

10 bits

54 bits

64 bits

1111111010

Interface Identifier EUI-64

FE8 0000000000000

Interface Identifier

FE80::/64 Example 2-3 Link-Local Address of an Ethernet Interface Layer 2 MAC Address: 0004.6d7f.7c1a EUI-64 Interface Identifier generated from the MAC Address (using the process shown in Figure 2-13 later in this chapter): 204:6DFF:FE7F:7C1A Link-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 internal hierarchy. 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 the overall addressing scheme used in a network. This is consistent with its scope; the link-local address is not meaningful outside the link. For this reason, link local communication is not impacted during network renumbering. Its perennial property is leveraged by various protocols. Routers advertise their link-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-local addresses 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 where addressing does not have to obey any global rules. The IPv6 addresses assigned to this scope as defined in RFC 3513 were called site-local, and they did not have to be unique. Their resemblance to the IPv4 private address space was a reminder of the drawbacks of

32

Chapter 2: An IPv6 Refresher

such an approach (see RFC 3879). Some of the arguments against the use of site-local addresses are as follows:

•

Application issues—Applications have problems when the site-local addresses are carried in payload outside the site. A good example of this is the case of a client/server application that relies on the addresses of each side, which are on different sites. The address overlap between sites can confuse the server with respect to the location of the client. Attempts to deal with address overlap by adding a site identifier to the site-local addresses led to complex implementations. It is difficult for network nodes to keep track of all site identifiers, especially in the case of nodes multihomed over multiple sites. Applications generally do not have a sense of scope, and they often leak private addresses, such as site-local, outside the private network. Leaks between sites with the same addressing can lead to routing or DNS problems.

•

Routing and Forwarding Issues—The nonunique character of site-local addresses would force routers 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 a site over intermediate networks. Tunneling becomes necessary in such circumstances. Multi-sited routers have to base their forwarding decision not only on the destination address but 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 could theoretically live without the concept of a site. However, practical considerations dictate the need to identify scopes smaller than the global one. Enterprises in particular have an understandable fondness for identifying the boundaries of their networks. For these reasons, the deprecated site-local scope and addresses had to be replaced by a better-defined concept that could handle the concerns mentioned. The new concept is that of a uniquelocal scope and the corresponding unique-local addresses. Figure 2-4 shows the format of these addresses. The unique-local unicast addresses are fully standardized in RFC 4193. Figure 2-4

Unique-Local Unicast Address Format L = 1 Locally assigned L = 0 Future use 128 bits

7 bits

1111 110 L

40 bits

Global ID

16 bits

Subnet ID

Unique Local Unicast Address Prefix

FC00::/7

64 bits

Interface Identifier

IPv6 Addressing

33

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 a local assignment.

•

Global ID is a 40-bit identifier that ensures the global uniqueness of the address. It is generated pseudo-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 a hierarchical addressing plan within the site.

•

Interface ID has the same meaning for all unicast addresses, and it is 64 bits long in the modified EUI-64 format.

ULAs have to be used within the confines of a predefined domain that represents the local scope of these particular addresses. Traffic using ULAs as either SA or DA should not be allowed to cross the boundaries of the domain. ULAs make it easy to interconnect distinct local domains because there are no address collisions. Discontiguous site topologies are easier to manage. Routers connected to multiple sites can distinguish between them solely based on the address, thus avoiding the need for additional labels. These examples underline the benefits of the unique-local addressing versus the site-local addressing.

Global Unicast Address The global unicast addresses are defined for use across the IPv6 Internet. They are globally unique and globally routable. The IPv6 addresses reserved for global scoped communication are identified by their high-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 of more address bits. The additional length could come at a cost by impacting routing processes through longer lookups, significantly larger routing tables, and larger routing updates (because many more networks are possible than with IPv4). Add to this the likely possibility that IPv6 networks are expected to have two or more coexistent addressing schemes and it becomes clear that IPv6 routers will need some help. One way to provide the needed relief is to implement and enforce strong rules on prefix aggregation. Such rules and policies would reduce the size of the routing table and the length of most of the prefixes populating them. A lot of effort has been placed on developing a flexible structure for the GUAs that facilitates easy aggregation. Several attempts were made, starting with RFC 2373, to enforce a granular address structure reflecting various levels of aggregation. In the end, it was decided to enforce proper aggregation through rigorous allocation policies and settle for a simpler address structure, as specified in RFC 3587 and shown in Figure 2-5.

34

Chapter 2: An IPv6 Refresher

Figure 2-5

Global Unicast Address Structure

Global Unicast Address Identifier 128 bits n bits

001

64-n bits

64 bits

Subnet Identifier

Interface Identifier

Global Routing Prefix Site Host

2000::/3 The components of the global unicast address are as follows:

NOTE

•

Global routing prefix—A service provider is assigned a portion of this prefix by the Internet Assigned Numbers Authority (IANA), and it then allocates a subspace to its customers. Its length 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 routing prefix identifies the service provider (SP) and the organization inside the SP, and the subnet ID identifies the organizational structure of its network.

•

Interface ID—The low-order 64 bits of the address are used to identify the interfaces of nodes on a link.

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 and with resources on the Internet. This means that a host’s interface within a private network could be assigned two addresses, one to be used to communicate with other hosts and resources within the private network (possibly a uniquelocal) and another to be used to communicate with hosts and resources outside the private network (global unicast). For operational and management purposes, a correlation between the elements of the various address types on an interface might make sense. In this example, 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 is important 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 the time of this writing, from the global unicast address pool.

IPv6 Addressing

Table 2-1

35

Assigned IPv6 Unicast Addresses Prefix (Hex)

Prefix (Binary)

Description

2001::/16

0010 0000 0000 0001

IPv6 Internet —ARIN, APNIC, RIPE NCC, LACNIC

2002::/16

0010 0000 0000 0010

6 to 4 transition mechanisms

2003::/16

0010 0000 0000 0011

IPv6 Internet —RIPE NCC

2400:0000::/19 2400:2000::/19 2400:4000::/21

0010 0100 0000 0000

IPv6 Internet —APNIC

2600:0000::/22 2604:0000::/22 2608:0000::/22 260C:0000::/22

0010 0110 0000 0000 0010 0110 0000 0100 0010 0110 0000 1000 0010 0110 0000 1100

IPv6 Internet —ARIN

2A00:0000::/21 2A01:0000::/23

0010 1010 0000 0000 0010 1010 0000 0001

IPv6 Internet —RIPE NCC

3FFE::/16

0011 1111 1111 1110

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 hierarchical approach to address allocation. Larger address space is assigned to organizations (ISPs, governments, research networks, and so on), who in turn assign smaller pieces to their customers. This approach allowed for hierarchical routing, which is credited with a significant reduction in the size of the routing tables in core routers. A similar yet better-defined and stricter approach was adopted for IPv6. Earlier complex structuring of the IPv6 prefix in fields such as Top Level Aggregation and Next Level Aggregation has been replaced by the simpler format described in this section. IPv6 global unicast address hierarchy is enforced through IANA’s allocation policy rather than fitting a predefined address format. Figure 2-6 exemplifies the address-allocation process for the 2001::/16 pool. IANA provides a prefix no longer than 32 bits to the Regional Internet Registries (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)

36

Chapter 2: An IPv6 Refresher

The RIR allocates pieces of the prefix it received from IANA to National Internet Registries (NIRs; where present), to Local Internet Registries (LIRs), or Internet service providers (ISPs). These allocations are currently in the range of 32 to 35 bits in length. ISPs allocate prefixes to their customers (enterprises or residential users). Figure 2-6

IPv6 Prefix-Allocation Process

2001::/3 IANA

001

RIR

001

NIR

001

ISP/LIR

001

/3

/3 to /32 /32 to /35

35 Organization

001

Local Subnet

001 3

/48

Interface Identifier 32

48

64

/64 128 bits

As shown in Figure 2-6, each organization is assigned a prefix by the one above it and in turn is assigning prefixes to the one below it. Thus, each organization (IANA, RIR, NIR, LIR, and ISP) represents an aggregation boundary. ISPs and LIRs keep track of the usage of their allocations with the help of the same metric used for IPv4, the host density (HD) ratio (defined in RFC 3194). ISPs/LIRs have to allocate prefixes in a way that prevents segmentation and allows for optimal use of aggregation. Such best practices enable them to make the most out of 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 at http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/networks/#hier. Figure 2-7 presents a snapshot of this information for the sole purpose of exemplifying the allocation policies described in this section. NTT/VERIO is a service provider with global coverage, so it acquires prefixes from various RIRs. This example shows its 2001:218::/32 allocation received from APNIC. One of its customers is the University of Leipzig, which was assigned the 2001:218:A20:: /48 prefix. The university allocated a subnet, 2001:218:A20:FFFD::/64, to one of its departments. It is interesting to note that a more practical allocation could be for NTT/ VERIO to assign this European university a prefix from its RIPE NCC allocation 2001:728::/32.

IPv6 Addressing

Figure 2-7

37

IPv6 Prefix-Allocation Example

• VERIO: 2001:0218::/32 Sites: VERIO • IPVH: 2001:0218:0A1F::/48 Sites: IPVH • UNI-LEIPZIG:2001:0218:0A20::/48 Sites: • DE-IPG6-WULF: 2001:0218:0A20:0011::190/126 Sites: • LAW-NET6: 2001:0218:0A20:0011::16B/128 Sites: • DE-IPG6-UWE: 2001:0218:0A20:FFFD::/64 Sites: • TRAXO-NET: 2001:0218:0A21:0002:F66A:0C34:00D1:A81E:0128: Sites: • CTXM: 2001:0218:0A25::/48 Sites: • ZEBBONE: 2001:0218:0A27::/48 Sites: ZEBROC WH-KIEL UNI-ULM TU-ILMENAU TMAG THALES-DE-PF TEUTONET SERNET-6BONE REWTBOX PING-NET JOIN IPG6 IABG GENDORF FLATLINE FH-RHEIN-SIEG FH-OFFENBURG FH-BINGEN FGAN-FFM FAUERN CYBERPHORIA BCC-DE

• • • • • • • • • •

• KELLERBUDE: 2001:0218:0A27:0013::/64 Sites: UNINETWORX: 2001:0218:0A28::/48 Sites: UNIXNETWORK: 2001:0218:0A3A::/48 Sites: GTNET: 2001:0218:0A61::/48 Sites: GTNET SLICED: 2001:0218:0A62::/48 Sites: SLICED TEMA: 2001:0218:0A66::/48 Sites: KVI-6BONE: 2001:0218:0A6F::/48 Sites: KV1-6BONE • ESCAPE-PL: 2001:0218:0A6F:000D::/64 Sites: ESCAPE-PL SPECTARE-NL:2001:0218:0ABE::/48 Sites: SPECTARE-NL RP-6BONE-NET: 2001:0218:0AC1::/48 Sites: ASFALEK: 2001:0218:0ACE::/48 Sites: ASFALEK DE-IPG6-NTT: 2001:0218:0AE0::/48 Sites: IPG6 IABG GENDORF FLATLINE FH-RHEIN-SIEG FH-OFFENBURG FH-BINGEN FGAN-FFM FAUERN CYBERPHORIA BCC-DE

You can find a complete list of global IPv6 allocations made by regional registries at the following URL: http://www.ripe.net/ripencc/mem-services/registration/ipv6/ipv6allocs.html. IPv6’s method of implementing address hierarchy through allocation policies leads to a subtle but important departure from the traditional IPv4 address-management concepts. At the time of this writing, in the case of IPv6, an enterprise no longer owns its global address space. The address space it is using is a subset of their ISP’s allocation. This means that an enterprise will have to go through network renumbering every time it changes ISPs. Despite IPv6’s features that make renumbering easier, this process would carry an operational impact. Because IPv6 interfaces can support multiple unicast addresses, the migration from one ISP to another one can be done through a transient period where the prefixes from both old and new ISPs coexist on the customer network. Operational experience for this type of situation still needs to be developed to evaluate the impact on medium- and large-size enterprises when switching between IPv6 ISPs. Nevertheless, as enterprises become interested 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 for changes 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 they are discussed independently of the other unicast addresses.

38

Chapter 2: An IPv6 Refresher

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 that do not have an IPv6 address or their IPv6 address has not been yet proven to be unique within the local link. The unspecified IPv6 address has all 128 bits set to 0. It can be represented as 0: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 address in IPv4. In IPv6, the loopback address has all the 127 leading bits set to 0, and the last bit is 1. It can be 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 spaces is important to support various aspects of this coexistence. Two mechanisms were developed to map IPv4 addresses into IPv6 addresses:

•

The IPv4-compatible IPv6 address was defined to be used for dynamic tunneling and is built by adding 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 16 bits set to 1.

Example 2-4 shows the IPv4-compatible and the IPv4-mapped IPv6 addresses corresponding to the IPv4 address 192.100.10.1. Example 2-4 Examples of IPv4-Compatible and IPv4-Mapped IPv6 Addresses IPv4 Address: 192.100.10.1 IPv4-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:0A01 IPv4-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

IPv6 Addressing

39

IPv6 Anycast Addresses When the same unicast address is assigned to multiple interfaces, typically belonging to different nodes, it becomes an anycast address as specified in RFC 3513. Because anycast addresses are structurally indistinguishable from unicast addresses, a node has to be configured to understand that an address assigned to its interface is an anycast address. A packet with an anycast DA is routed to the nearest interface configured with it. An anycast address cannot be used as the SA of a packet. Anycast is often used to virtually replicate important network resources, such as Domain Name System (DNS) root servers, web servers, and multicast rendezvous points (RPs), thus providing a level of redundancy and load sharing. IPv6 went beyond this concept that is currently used by IPv4 in that it defined a set of reserved addresses for each unicast prefix to facilitate the future use of anycast. The subnet-router anycast address is defined by RFC 3513 for every prefix as the address with the interface ID set to 0. A router has to support the subnet-router anycast addresses for all the prefixes configured on its interfaces. A packet destined to such an address will be delivered to the nearest router that has an interface with that prefix. RFC 2526 defines an additional set of anycast addresses reserved for a given prefix. Figure 2-8 shows the structure of these anycast addresses. Figure 2-8

IPv6 Reserved Anycast Address Format 128 bits 64 bits

Subnet

57 bits

7 bits

…

1111110111

1111

Anycast ID

Unicast Address with EUI-64 Interface Identifier

n bits

Subnet

121-n bits

1111111111

7 bits

…

1111

Anycast ID

Unicast Address with non-EUI-64 Interface Identifier 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 the group scope of the anycast address, it also makes sense that the high-order bit, which would represent the individual/group bit of a mapped MAC address, is set to 1 (group). In the case of unicast prefixes with EUI-64 interface IDs, the universal/local bit is set to 0 to indicate that the interface ID for the anycast address is not globally 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) home agent’s anycast addresses.

40

Chapter 2: An IPv6 Refresher

NOTE

MIPv6 provides a host with a mechanism to discover the address of one of his home agents (HAs). The host can attempt to register to the home agent's anycast address (described in this section) hosting its home prefix. One of the HAs will receive the request, reject the registration, and instead reply to the host with a list of the actual addresses of the HAs it can use.

The anycast addresses are allocated from the unicast address space. There is little operational experience with this 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 addresses in the control-plane messages, thus becoming a critical part of IPv6 network operation. The larger address space provides plenty of globally unique multicast group addresses to facilitate the deployment of multicast services. A multicast address identifies a group of interfaces. A packet with a multicast destination address is delivered to all the group members. It is important to remember that multicast addresses should not be used as SAs. The IPv6 multicast addresses have their top 8 highorder bits set to 1 (FF00::/8) and the format shown in Figure 2-9. Figure 2-9

IPv6 Multicast Address Format

FF00::/8 128 bits 8 bits

4 bits

4 bits

1111 1111

Flag

Scope

0R P T

Scope

FF

R = 0 No embedded RP R = 1 Embedded RP

T = 0 Permanently assigned multicast address T = 1 Not permanently assigned multicast address

P = 0 Multicast address not built based on a unicast prefix P = 1 Multicast address built based on a unicast prefix

IPv6 Addressing

41

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 that are 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 a unicast 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 the unicast address of the RP servicing that group.

The remaining fourth flag bit is reserved for future use and currently is set to 0.

NOTE

The P bit set to 1 indicates that the multicast address is built from a unicast address. Because the unicast address is considered to have a limited lifetime, the resulting multicast address cannot be permanently assigned. 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 the information needed to contain the multicast traffic within the appropriate domain. Table 2-3 lists the values that 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

Organization-local scope

E

1110

Global-local scope

Similar to the unicast addresses, the multicast address space has its own elements of special interest, as described next.

Unicast-Prefix-Based Multicast Addresses GLOP addresses were introduced in IPv4 to provide globally unique IPv4 multicast group addresses to organizations that own autonomous system numbers (ASNs). The addresses are built based on globally unique ASNs. RFC 3306 extends this concept and defines a

42

Chapter 2: An IPv6 Refresher

mechanism that generates globally unique IPv6 multicast addresses based on a unicast prefix, as shown in Figure 2-10. Figure 2-10 Unicast-Prefix-Based Multicast Address Format 128 bits 8 bits

4 bits

4 bits

8 bits

1111 1111

Flag

Scope

Reserved

FF

3

X

0

Prefix Length

Unicast Prefix

Group ID

8 bits

64 bits

32 bits

FF3x::/96 The reserved bits must be set to 0. The 64 bits provided for the Unicast Prefix field are sufficient based on the structure of the IPv6 unicast addresses (64 bits are used by the interface ID). The format presented in Figure 2-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 prefix 2001:100:abc:1::/64. Example 2-5 Unicast-Prefix-Based Multicast Address Generated from an IPv6 Unicast Prefix Unicast Prefix: 2001:100:abc:1::/64 Unicast Prefix Scope Global: E Choose Group ID: 11FF:11EE Resulting Multicast Address: FF3E:0040:2001:100:abc:1:11FF:11EE

NOTE

The scope of the unicast-prefix-based multicast address should not exceed that of the embedded unicast prefix.

NOTE

The group addresses used in Source Specific Multicast (SSM) deployment models (see Chapter 6, “Providing IPv6 Multicast Services”) were defined as a subset of the unicastprefix-based multicast addresses, where the Prefix Length and the Network Prefix fields are set to 0 (see Figure 2-11).

Figure 2-11 PIM-SSM Multicast Group Addresses FF

3

X

0

Prefix Length = 0

Unicast Prefix = 0

Group ID

8 bits

64 bits

32 bits

FF3x::[Group ID = 32 bits]

IPv6 Addressing

43

Solicited-Node Multicast Addresses The solicited-node multicast address provides a mechanism to contact a host on the local-link when knowing only its layer 3 unicast address. This address type is generated for each unicast and anycast prefix assigned to an interface. The address format is FF02::1:FF00:0000/104, where the low-order 24 bits are the same as the unicast or anycast address that generated it. It represents a deterministic way to identify a local-link multicast group to which a host with a given IPv6 unicast address is listening. If not all the information needed to establish unicast connectivity to the host (the MAC address) is available, the destination can still be reached via multicast sent to its solicited-node multicast address. Fundamental IPv6 control-plane processes, such as layer 2-to-layer 3 address mapping and Duplicate Address Detection (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 Global Unicast Address 64 bits

Interface Identifier

Copy

FF02

0000

0000

0000

0000

0001

FF 24 bits

Solicited-Node Multicast Address

FF02::1:FF00:0000/104 Example 2-6 Generating a Solicited-Node Multicast Address Unicast Address: 2001:100:abc:1:0:0:aabb:ccdd/64 Resulting Solicited-Node Multicast Address: FF02::1:FFbb:ccdd

NOTE

The solicited-node multicast address has a link-local scope. It is used for control-plane functions only within the local link.

NOTE

Based on the structure of the solicited-node multicast address, it is clear that the same solicited-node multicast address represents multiple IPv6 unicast addresses. Considering the large addressing space and assuming that there is no address assignment policy that favors the 40 high-order bits of the interface ID, this oversubscription of the solicited-node multicast address should not be significant.

44

Chapter 2: An IPv6 Refresher

IPv6 Multicast Address Allocation IPv6 multicast addresses are allocated by IANA based on the rules documented on its website: http://www.iana.org/assignments/ipv6-multicast-addresses IANA identifies two multicast address types in its allocation policy:

Table 2-4

•

Variable-scope multicast addresses—These addresses are similar across all scopes, but they represent distinct groups. They are reserved for certain types of services or applications. A good example is NTP (Network Time Protocol), which has a multicast address of FF0X:0:0:0:0:0:0:101, where X masks the address scope.

•

Fixed-scope multicast addresses—These addresses have a certain meaning only within the scope they are defined in. This type of addresses is important in the basic operation of IPv6. For this reason, a few common ones are listed in Table 2-4.

Example of Fixed-Scope IPv6 Multicast Addresses Multicast Address

Scope

Group Within the Scope

FF01:0:0:0:0:0:0:1

Node-local

All-nodes address

FF01:0:0:0:0:0:0:2

Node-local

All-routers address

FF02:0:0:0:0:0:0:1

Link-local

All-nodes address

FF02:0:0:0:0:0:0:2

Link-local

All-routers address

FF02:0:0:0:0:0:0:5

Link-local

OSPF IGP

FF02:0:0:0:0:0:0:6

Link-local

OSPF IGP designated routers

FF02:0:0:0:0:0:0:D

Link-local

All PIM routers

FF02:0:0:0:0:0:0:16

Link-local

All MLDv2-capable routers

FF02:0:0:0:0:0:1:2

Link-local

All DHCP agents

FF02:0:0:0:0:1:FFXX:XXXX

Link-local

Solicited-node address

FF05:0:0:0:0:0:0:2

Site-local

All-routers address

FF05:0:0:0:0:0:1:3

Site-local

All DHCP servers

One part of the multicast address was not talked about too much in this section, the group ID. In theory, the group ID can take any value as long as the rest of the address fits the structure described in the earlier sections. The larger multicast address space raises the concern of significant oversubscription of layer 2 addresses (which are much smaller in size) mapped to the IPv6 multicast groups. To minimize this oversubscription, group ID allocation guidelines were defined in RFC 3307, and they are shown in Table 2-5.

IPv6 Addressing

Table 2-5

45

Group ID Allocation Rules Multicast Address Type

Range

Allocation Determined By

Permanent multicast addresses

0x00000001–0x3FFFFFFF

Expert review

Permanent multicast group ID

0x40000000–0x7FFFFFFF

Expert review

Dynamic multicast addresses—server allocation

0x80000000–0xFFFFFFFF

Server allocation

Dynamic multicast addresses—host allocation

0x80000000–0xFFFFFFFF

Protocol RFC 1750 or 32 bit Pseudo-random

The low end of the group ID value is reserved for the permanent multicast addresses under IANA management. This is consistent with the examples shown earlier in Table 2-4. Permanent multicast group ID is used as a globally unique identifier of a service (such as NTP). The high-end range of group ID values is reserved for dynamically allocated addresses, regardless of mechanism. However, having distinct ranges for the server and host allocations does make it easier to identify the multicast addresses obtained through a managed service. Some of these allocation rules might become irrelevant in the future if other mechanisms are implemented to mitigate 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 IPv6 specific and provides the mechanism of building an interface ID from layer 2 addresses. The second way is common for both IPv4 and IPv6 and provides the mechanism for mapping an IP multicast address to a layer 2 multicast address.

EUI-64 Interface Identifiers IEEE specifies the format of the EUI-64 identifiers. To make such an identifier an IPv6 interface ID, the only thing 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-bit layer 2 address. With such a mechanism in place, a correlation can be established between the MAC address of an interface and the interface ID portion of IPv6 addresses. This type of ID is used, for example, by default by 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 step is to create an EUI-64 identifier; the second step is to modify it to make it an IPv6 interface ID.

46

Chapter 2: An IPv6 Refresher

Figure 2-13 Generating an Interface ID from a MAC Address in the Modified EUI-64 Format 48 bits

MAC Address

00B0

4A5C

F038

Step 1 Insert 1111111111111110

EUI-64 Identifier

00B0

4A FFFE 5C

Step 2

F038

64 bits

Flip 7th Bit

IPv6 Interface ID

0 2 B0 4A FFFE 5C

F038

Layer 2 Multicast Addresses Similar to IPv4, IPv6 is currently mapping layer 3 multicast addresses into layer 2 addresses. For multicast IPv6 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 remaining portion of the MAC address. Figure 2-14 shows an example of this mapping mechanism in the case of a solicited-node multicast IPv6 address. Figure 2-14 Mapping an IPv6 Multicast Address into a MAC Address

IPv6 Multicast Address 32 bits

FF02

0000

0000

0000

0000

0001

FF5C

F038 Copy

Multicast Layer Two Address

3333

FF5C

F038

48 bits

These two address correlation mechanisms are often used in operational networks and are often mentioned throughout 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 of addresses:

• • • •

Loopback address Link-local address Unicast or anycast addresses if configured Subscribe to the all-nodes multicast address

IPv6 Addressing

• •

47

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 or multicast 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.

Configuring IPv6 Addresses in Cisco IOS Routers This section presents the Cisco IOS router-specific configuration steps that are needed to provision a Cisco router interface for IPv6. Example 2-7 presents the process of enabling IPv6 on a router interface and underlines some of the concepts reviewed in this section. Example 2-7 Enabling IPv6 on a Router Interface Router#show interface Gigabit2/0 GigabitEthernet2/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 mode Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface Gigabit2/0 Router(config-if)#ipv6 enable ! Enables IPv6 on Gigabit2/0 Router(config-if)#^Z Router# *Jul 22 22:14:17.833: %SYS-5-CONFIG_I: Configured from console by console Router#show ipv6 interface Gigabit2/0 ! Displays the IPv6 Properties of Interface Gigabit2/0 GigabitEthernet2/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 Interface Identifiers. ! 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

continues

48

Chapter 2: An IPv6 Refresher

Example 2-7 Enabling IPv6 on a Router Interface (Continued) ! 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. A router 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 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 the default behavior of a Cisco router. Cisco IOS commands also enable you to manually configure the link-local address.

Example 2-8 presents the process of configuring various types of addresses on the router interface. The results of these configuration steps are shown in the output of show ipv6 interface, which displays the IPv6 properties of the interface. Example 2-8 Configuring IPv6 Addresses on a Router Interface Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface Gigabit2/0 Router(config-if)#ipv6 address 2001:100:10:1::1/64 ! IPv6 Global Unicast with configured Interface ID: 2001:100:10:1::1/64 Router(config-if)#ipv6 add 2001:100:10:2::/64 eui-64 ! IPv6 Global Unicast enabled to use the EUI-64, MAC generated Interface ID

IPv6 Addressing

49

Example 2-8 Configuring IPv6 Addresses on a Router Interface (Continued) Router(config-if)#ipv6 add 2001:100:10:3::1/64 anycast ! IPv6 Unicast defined to be Anycast Address: 2001:100:10:3::1/64 Router(config-if)#^Z Router#show ipv6 interface Gigabit2/0 GigabitEthernet2/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 EUI6e 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

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 the existing 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 still being worked on (for example, the unique-local unicast address). Despite these ongoing tweaks, at its current level of development and standardization, IPv6 addressing is mature enough for the deployment of large IPv6 networks. Table 2-6 summarizes the information presented in this section for quick reference.

50

Chapter 2: An IPv6 Refresher

Table 2-6

IPv6 Addressing Summary and Significant Address Allocations Prefix (Hex)

Prefix (Binary)

Description

::

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 Special Use

Unicast Link-Local [1111 1110 1000 0000] FE80::/10

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

2001::/16

0010 0000 0000 0001

IPv6 Internet —ARIN, APNIC, RIPE NCC, LACNIC

2002::/16

0010 0000 0000 0010

6 to 4 transition mechanisms

2003::/16

0010 0000 0000 0011

IPv6 Internet —RIPE NCC

2400:0000::/19 2400:2000::/19 2400:4000::/21

0010 0100 0000 0000

IPv6 Internet —APNIC

2600:0000::/22 2604:0000::/22 2608:0000::/22 260C:0000::/22

0010 0110 0000 0000 0010 0110 0000 0100 0010 0110 0000 1000 0010 0110 0000 1100

IPv6 Internet —ARIN

2A00:0000::/21 2A01:0000::/23

0010 1010 0000 0000 0010 1010 0000 0001

IPv6 Internet —RIPE NCC

Unicast Global [001]

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

IPv6 Packet Format

Table 2-6

51

IPv6 Addressing Summary and Significant Address Allocations (Continued) Prefix (Hex)

Prefix (Binary)

Link-Local Scope

1111 1111 0000 0010

FF02::1

1111 1111 0000 0010::1

All-nodes address

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

Description

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]

PIM-SSM Group Addresses

1111 1111 0011

FF3X::[32-bit group ID]

Embedded RP Group Addresses

X—scope; Y—prefix length

X—scope

1111 1111 0111

FF3X:0YZZ[64-bit prefix]:[32-bit group ID]

X—scope; Y— interface ID; ZZ—prefix length

IPv6 Packet Format The structure of the IP packet header was modified in IPv6. These changes reflect some of the lessons learned from years of operating IPv4, and they have a significant impact on the protocol operation. For these reasons, the IPv6 packet format is briefly reviewed in the next section.

52

Chapter 2: An IPv6 Refresher

IPv6 Versus IPv4 Basic Header Format To understand what motivated the choices made with respect to the IPv6 packet header structure, it is important to review the structure of its predecessor. A packet has two components: the header that contains the layer 3 information, and the payload that carries the data and the upper-layer protocol information. RFC 791 defines the following fields for the IPv4 packet header:

•

Version (4 bits)—Represents the version of the IP protocol. In this case, the field is set to 4.

• •

Header Length (4 bits)—The length in octets of the packet header.

•

Total Length (16 bits)—The length in octets of the entire packet, header plus payload. With 16 bits available in this field, the maximum length of an IPv4 packet is 65,535 octets.

•

Identification (16 bits), Flags (3 bits), Fragment Offset (13 bits)—These three fields enable IPv4 networks to support packet fragmentation to negotiate forwarding 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 from packets that loop due to routing problems. This field is used to count down the number of routers that switched the packet. The packet is discarded when the value 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. The numbers 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 by comparing the computed checksum with the value listed in this field.

• • •

Source IPv4 Address (32 bits)—The IPv4 address of the node that sourced the packet.

•

Padding (variable length)—Is used to align the variable-length Options field to the 32-bit boundary.

Type of Service (ToS) (8 bits)—This field carries information that enables routers to classify and forward packet in a differentiated manner. It is an important service identifier used in implementing quality of service (QoS).

Destination IPv4 Address (32 bits)—The IPv4 address of the packet destination node. Options (variable length)—This field is meant as a placeholder for the information relevant to proper handling of the data carried by the packet, information that is not represented in the other fields of the header. Because of this field, the IPv4 header has a variable length, justifying the need for the Header Length field.

Figure 2-15 shows the IPv4 packet header structure.

IPv6 Packet Format

53

Figure 2-15 IPv4 and IPv6 Packet Header Structure 32 bits

Ver (4) Hd Len (4) Type of Service (8)

Total Length (16) Flags (3) Fragment Offset (13) Identification (16) Header Checksum (16) Time to Live (8) Protocol Number (8)

20 Octets

Source IPv4 Address (32) Destination IPv4 Address (32)

IPv4 Packet Header

+ Options (Variable)

Padding (Variable)

Payload

Ver (4)

Traffic Class (8)

Flow Label (20)

Payload Length (16)

IPv6 Packet Header

Next Header (8)

Hop Limit (8)

Source IPv6 Address (128) 40 Octets

Destination IPv6 Address (128)

+ Next Header (8)

Data or Options

Payload

The relevancy of the highlighted fields has been re-evaluated in the process of developing 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 of variable length (minimum 20 bytes). By contrast, IPv6 has the main header length fixed at 40 bytes, a benefit to fast header processing because routers do not have to implement lookup processes that account for variable-length headers. The fixed length makes the Header Length field obsolete. The functionality provided by the options is delivered through extension headers, a concept described later in the section. The options and padding are also removed from the main packet header.

•

Fragmentation is done only by the traffic source—Before sending IPv6 traffic, the source does Path MTU (PMTU) Discovery. It then sends packets at the discovered PMTU, thus freeing the routers from having to fragment them. For this reason, the

54

Chapter 2: An IPv6 Refresher

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 1280 bytes, as specified in RFC 2460.

Header checksums are eliminated—The IP header checksum has to be recalculated by every node switching the packet due to changing Time To Live (TTL) values, thus taxing router resources. Improvements on data-link technologies and their 32-bit cyclic redundancy check (CRC) support since the introduction of IPv4 combined with layer 4 checksums provides sufficient protection to make the layer 3 header checksum unnecessary. For this reason, the packet Header Checksum was eliminated in IPv6 and is in turn enforced at upper layers. It is important to note the fact that both UDP and TCP will calculate the checksum on a pseudo-header that contains critical information from 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.

•

Flow Label (20 bits)—This field identifies a flow and it is intended to enable the router to identify packets that should be treated in a similar way without the need for deep lookups within those packets. The specification for this header field is presented in RFC 3697. The field is set by the source and should not be changed by routers along the path to destination.

Traffic Class (8 bits)—It performs the same function as the Type of Service field in the IPv4 header.

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 the packet, providing routers with the capability to appropriately handle packets without the need to look deep into them. The Flow Label can also provide the router with relevant information (such as TCP/UDP port and so on) that would not be otherwise available because the packet payload is encrypted. This would be 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 tool and similar extensions are being proposed for IPv4. Applications are envisioned where the field is used just as a tag as well as more complex ones that maintain label state on the nodes using a signaling protocol. The Flow Label can be used with differentiated services (DiffServ) as well as integrated services (IntServ) and Resource ReSerVation Protocol (RSVP2).

IPv6 Packet Format

•

55

Payload Length (16 bits)—With the header length fixed at 40 bytes, it is enough to indicate 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 Number in the IPv4 header. It prefaces the information type immediately following the basic header. This can be an extension header or the upper-layer protocol in the payload.

•

Hop Limit (8 bits)—In IPv6, the IPv4 TTL was appropriately renamed Hop Limit because it is a variable that is decremented at each hop, and it does not have a temporal dimension.

•

Source IPv6 Address (128 bits)—The IPv6 address of the node that sourced the packet.

•

Destination IPv6 Address (128 bits)—The IPv6 address of the packet destination node.

Figure 2-15 shows the IPv6 header next to the IPv4 header to underline their differences and similarities. The Flow Label is highlighted because it represents a new functionality introduced by IPv6.

IPv6 Extension Headers The basic IPv6 header is sufficient to perform the functions of simple packet forwarding and ToS- or Flow Label–based QoS. There is, however, more to end-to-end IP communication than what is covered by the basic header capabilities. With the basic header at a fixed size, IPv6 had to find another way to implement the functionality offered by the Options field in IPv4. It does that through the concept of extension headers.

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 limited only by the packet size.

Predefined placeholders for additional information that relates to the packet payload or the packet handling, the extension headers provide the means to complement in a modular way the functionality of the basic packet header. The format of each extension header type

56

Chapter 2: An IPv6 Refresher

supports certain functions. All extension headers, however, are aligned on 8-byte boundaries to maintain 8-octet alignment. Extension headers are chained together as needed. The Next Header field of each header starting 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 the upper-layer protocol in the payload. Figure 2-16 shows an IPv6 packet without extension headers and one with extension headers. There is a specific code for each extension header type as well as for the upper-layer (UL) protocols. Figure 2-16 Chaining Extension Headers to the Basic IPv6 Packet Header

Packet without Extension Header 32 bits

Ver

Traffic Class Payload Length

Flow Label Next Header = UL

Hop Limit

Source IPv6 Address

40 Octets

Destination IPv6 Address Upper Layer (UL) Header

Payload

Packet with Extension Header Ver

Traffic Class Payload Length

Flow Label Next Header = EH1 Source IPv6 Address Destination IPv6 Address

Next Header = EH2 Next Header = EH3 Next Header = UL Upper Layer (UL) Header

Extension Header 1 Extension Header 2 Extension Header 3 Payload

Hop Limit 40 Octets

IPv6 Packet Format

57

RFC 2460 defines the IPv6 extension headers. You can find detailed descriptions of the extension headers, their format, and functionality in most introductory IPv6 books. This section 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 only extension header that has to be processed by all the nodes on the path of the packet other than the destination. For this reason, this extension header, when present, always follows the basic IPv6 header. It is used, for example, to facilitate forwarding of Jumbograms, as described later in this section, or to provide routers with forwarding instructions. The Hop-by-Hop header may carry multiple options containing other parameters that should 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

Type-Length-Value (TLV) Option Format 32 bits 8 bits

8 bits

16 bits

Option Type

Option Data Len

Option Data (variable length)

Every node that receives an IPv6 packet with a Hop-by-Hop extension header will process 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-Hop header. Not all option types generate ICMP error messages. These characteristics of the options 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 the routers.

One use of the Hop-by-Hop extension header is to support the use of large packets. The 16-bit-long Payload Length field in the basic header can represent payload lengths no larger than 65,536 (216) octets. The Hop-by-Hop extension header contains a 32-bit-long field that can represent larger packets called Jumbograms. The Payload Length field is set to 0 when the hop-by-hop options are used to identify a Jumbogram.

58

Chapter 2: An IPv6 Refresher

RFC 2711 defines the Router Alert option of the Hop-by-Hop extension header that is used to provide intermediate routers with forwarding instructions. This feature could be used, for example, for resource reservation with RSVP. It is also used in Multicast Listener Discovery packets to alert routers that they have to process these packets (see Chapter 6).

Destination Options Header As the name indicates, the information carried in the Destination Options extension header is intended for the packet’s destination only. The Destination Options header is used, for example, with MIPv6. Besides the Hop-by-Hop header, the Destination Header is the only one that also carries options in the same format presented in Figure 2-17. The Destination 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 to enforce a certain path for the packet. This path is defined by the source, and is most likely 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 Loose Source and Record Route option. The Routing header contains a Type field that defines the precise functionality of the extension header. At the time of this writing, two types have been defined:

•

Type 0, specified in RFC 2460, identifies a Routing header that contains an ordered list of router addresses that must be visited by the packet on the way to destination. Note that each visited router modifies the DA in the basic header to that of the next router in the list. This way the routers that are not on the Routing extension header list do not need to process the extension header. This provides the source-routing capability to IPv6.

•

Type 2, specified in RFC 3775, identifies a Routing header used with MIPv6. It contains a single unicast address, the address of the home address, and enables the corresponding node to forward traffic directly to the mobile node, a forwarding option called route optimization and available only with IPv6 (see Chapter 8, “Advanced Services—IPv6 Mobility”).

This is a developing topic, and other types are being proposed (but those have not yet reached RFC status).

Fragment Header Fragmentation is processing intensive, and it could be taxing on the resources of network elements. To protect the network infrastructure resources, it was decided that routers in the path of an IPv6 packet should not perform fragmentation. Before sending the packet, the

IPv6 Packet Format

59

source must go through the PMTU Discovery process, as described later in the chapter in the section “Internet Control Message Protocol for IPv6.” It determines the largest packet that it can use without fragmentation along the way. Although the routers are saved the fragmentation trouble, the destination still needs to know how to reassemble the received fragments. It will receive these instructions from the source via the Fragment Options header. The first packet exchanged, however, must contain all the information used in forwarding it between the two endpoints: IPv6 basic header and any extension headers that need to be processed along the way. This is called the unfragmentable part of the original packet.

NOTE

Two new rules in IPv6 relate to MTU handling: The MTU of a link should not be smaller than 1280 bytes, and routers do not do packet fragmentation. In today’s networks, these two requirements are not as stringent as they might seem. Links with small MTUs are becoming less common, so the MTU of a typical Ethernet host is likely to 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. It provides packet source authentication and data integrity protection. The AH header is identified by a Next Header field value of 51.

Encapsulating Security Payload Header This header is similar to the IPv4 IPsec Encapsulating Security Payload (ESP) header defined in RFC 2406. It is identified by a Next Header field value of 50. The ESP and AH 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 the mobile nodes, correspondent nodes, and home agents in establishing and managing bindings (for more details, see Chapter 8). It is identified by a Next Header field value of 135.

Linking Multiple Extension Headers The various extension headers are chained based on the information that needs to be provided to the destination or intermediary hops along with the payload data. The following set of extension headers— Hop-by-Hop, Destination, Routing, Fragmentation—can follow, for example, a basic IPv6 header. The sequence in which these extension headers are added to the basic header is not random. There is a recommended order in which extension headers should be chained in an IPv6 packet, but the only strict requirement is for the

60

Chapter 2: An IPv6 Refresher

Hop-by-Hop (if present) to be ahead of any other extension header type. Table 2-7 lists the extension header in the recommended chaining order along with the Next Header 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 Order

Header Type

Next Header Code

1

Basic IPv6 header

—

2

Hop-by-Hop Options

0

3

Destination Options (with Routing Options)

60

4

Routing header

43

5

Fragment header

44

6

Authentication header

51

7

Encapsulation Security Payload header

50

8

Destination Options

60

9

Mobility header

135

No Next header

59

Upper layer

TCP

6

Upper layer

UDP

17

Upper layer

ICMPv6

58

Extension headers are an important aspect of IPv6, and their capabilities will be leveraged more and more in optimizing the operation of production deployments. They make IPv6 easily extensible compared to its predecessor, 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 the variable-length Options field in the IPv4 header. At the same time, note that extension headers can pose security risks (see Chapter 9, “Securing IPv6 Networks”). The presence of extension headers could also impact packet-forwarding performance the same way options had in the case of IPv4. Routers have to process upper-layer information that now is moved deeper into the packet and would require the processing of the entire 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 the OSI 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).

IPv6 Packet Format

• • • • • • •

61

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, support IPv6 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 for building 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 ID field of the layer 2 header indicates the type of layer 3 protocol it carries in the payload. For example, Table 2-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)

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 differentiate between IPv4 and IPv6 traffic. A good understanding of the IPv6 packet structure and the structure of the corresponding layer 2 framing is important not only for a better understanding of the protocol operation but also in developing IPv6 troubleshooting expertise. The rest of the chapter presents several important IPv6-specific control-plane mechanisms. To facilitate their clear description, the subsequent sections are prefaced at this point with a list of relevant terms used henceforth:

• • • • •

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.

62

Chapter 2: An IPv6 Refresher

• • •

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 node for 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 completely supported by all IPv6 implementations. It combines functionalities supported in IPv4 under different protocols: ICMP (Internet Control Message Protocol version 4), IGMP (Internet Group Membership Protocol), and ARP (Address Resolution Protocol). 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 RFC 2463. Table 2-9, lists the RFCs that define ICMPv6 functionalities and the codes identifying the ICMPv6 types used for these functionalities. Similar to ICMPv4, ICMPv6 enables IPv6 nodes to report errors and performs various control-plane functions. Many of the existing ICMPv4 functionalities have been carried over to ICMPv6, although some were simplified and many more added. This reengineering of ICMP could have been driven independently of the protocol version. However, the IPv4 legacy made that approach unrealistic, so a new protocol type (Next Header) was defined specifically for ICMPv6 (protocol type 58 for ICMPv6, instead of 1 for ICMPv4). In this context, ICMPv6 ended up being a different protocol than ICMPv4. Some features are similar to their IPv4 counterpart (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 design differences from IPv4. Table 2-9 presents a comparison between ICMPv6 and ICMPv4. In the ICMPv6 column, the ICMPv4 messages that are not considered in IPv6 are marked NC. In the ICMPv4 column, the ICMPv6 messages that were not adopted are marked NA. Table 2-9

Comparison Between ICMPv4 and ICMPv6

Name

v6 Type

v4 Type

IPv4 RFC

IPv6 RFC

Destination Unreachable

1

3

RFC 792

RFC 2463

Packet Too Big

2

NA

Time Exceeded

3

11

RFC 792

RFC 2463

Parameter Problem

4

12

RFC 792

RFC 2463

Source Quench

NC

4

RFC 792

Alternate Host Address

NC

6

RFC 792

Timestamp

NC

13

RFC 792

RFC 2463

Internet Control Message Protocol for IPv6

Table 2-9

63

Comparison Between ICMPv4 and ICMPv6 (Continued)

Name

v6 Type

v4 Type

IPv4 RFC

Timestamp Reply

NC

14

RFC 792

Information Request

NC

15

RFC 792

Information Reply

NC

16

RFC 792

Address Mask Request

NC

17

RFC 950

Address Mask Reply

NC

18

RFC 950

Traceroute

NC

30

RFC 1393

Datagram Conversion Error

NC

31

RFC 1475

Mobile Host Redirect

NC

32

RFC 3775

Where-Are-You

NC

33

RFC 1788

I-Am-Here

NC

34

RFC 1788

Mobile Registration Request

NC

35

RFC 1788

Mobile Registration Reply

NC

36

RFC 1788

Domain Name Request

NC

37

RFC 1788

Domain Name Reply

NC

38

RFC 1788

Photuris

NC

40

RFC 2521

Echo Request

128

8

RFC 792

RFC 2463

Echo Reply

129

0

RFC 792

RFC 2463

Multicast Listener Query

130

NA

RFC 2710

Multicast Listener Report

131

NA

RFC 2710

Multicast Listener Done

132

NA

RFC 2710

Router Solicitation

133

10

RFC 1256

RFC 2461

Router Advertisement

134

9

RFC 1256

RFC 2461

Neighbor Solicitation

135

NA

RFC 2461

Neighbor Advertisement

136

NA

RFC 2461

Redirect Message

137

5

Router Renumbering

138

NA

RFC 2894

ICMP Node Information Query

139

NA

RFC 2894

ICMP Node Information Response

140

NA

RFC 2894

Inverse Neighbor Discovery Solicitation Message

141

NA

RFC 3122

Inverse Neighbor Discovery Advertisement

142

NA

RFC 3122

RFC 792

IPv6 RFC

RFC 2461

continues

64

Chapter 2: An IPv6 Refresher

Table 2-9

Comparison Between ICMPv4 and ICMPv6 (Continued)

Name

v6 Type

v4 Type

IPv4 RFC

IPv6 RFC

Version 2 Multicast Listener Report

143

NA

RFC 3810

Home Agent Address Discovery Request Message

144

NA

RFC 3775

Home Agent Address Discovery Reply Message

145

NA

RFC 3775

Mobile Prefix Solicitation

146

NA

RFC 3775

Mobile Prefix Advertisement

147

NA

RFC 3775

The ICMPv6 types 1 to 127 are reserved for errors, and values starting at 128 are for control and information reporting. Regardless of message type, all ICMPv6 messages share the same message header format as shown in Figure 2-18. Figure 2-18 ICMPv6 Packet Format 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Version

Traffic Class Payload Length

Flow Label Next Header Type ⫽ 58

Hop Limit ⫽ 255

Source Address (128 bits): Sender of the request, generally selected by SAS algorithm IPv6 Header

Destination Address (128 bits): Use the source address found in the packet that triggered or depend on each message

ICMP Header ICMP Body

Type

Code

Checksum Message body …

The IPv6 header has a value of 58 in the Next Header field if the upper-layer protocol of the payload data is ICMPv6. If the message is a response to an ICMPv6 messages sent to one of the node’s unicast addresses, the SA is the same address. Otherwise, the SA is calculated using the source address selection algorithm (see the “SAS Algorithm” 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 code depends on each message. The Checksum, unlike ICMPv4, includes the pseudo-header, a set of important fields from the IPv6 header, in addition to the ICMPv6 entire message. The inclusion of the pseudoheader enables ICMPv6 to check the integrity of essential elements of the IPv6 header in the absence of a layer 3 header checksum (see the “IPv6 Packet Format” section earlier in the chapter).

Internet Control Message Protocol for IPv6

65

ICMPv6 Error Messages One of ICMP’s functions is to deliver error messages that help the operation of a network. Currently, ICMPv6 uses 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 their destination. In many cases, this is a transient problem due to network congestion or transient connectivity loss and can be recovered by higher-level protocols, such as TCP. In some cases, however, a feedback mechanism is required. For example, the destination specified in the packet can be wrong, or the routing protocol may be failing to distribute routing information to it. ICMP Destination Unreachable provides such feedback mechanism, in the same way as in IPv4. The ICMP Unreachable message provides a reason code to help the source 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 to IPv6. For instance, “Fragmentation Needed and DF Set” cannot apply to IPv6 because fragmentation does not occur on intermediate routers. In addition to the reason code, the message also includes the original datagram portion 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, or transient routing states in large networks). The ICMPv6 Time Exceeded

66

Chapter 2: An IPv6 Refresher

was carried over from ICMPv4, designed to prevent packets from looping indefinitely in the network. A Hop Count field in the IPv6 header is decremented by each hop until it eventually reaches 0, in which case the datagram is dropped and the ICMPv6 Time Exceeded is sent back to the source.

NOTE

As in ICMPv4, the Time Exceeded message was diverted from its original goal, to provide a fairly inefficient but useful way to trace paths in the network (namely, traceroute). A UDP packet is sent to destination many times, by increasing the Hop Count field from 1 to “whatever it takes to reach the destination.” Each node on the path will successively send back an ICMPv6 Time Exceeded message, enabling the source to identify each router on the path.

Packet Too Big One of the numerous changes brought by IPv6 relates to the packet-fragmentation process. Unlike IPv4, in which any router on the path to the destination could fragment a packet, should it not fit the MTU of the outgoing link, IPv6 does not provision for this functionality. Although it was convenient for hosts to rely on fragmentation performed by routers, wherever needed, this was also concentrating a lot of processing burden on the routers. Routers have to keep state and use additional memory for the fragmentation process. This being said, it cannot be sufficient to not support the fragmentation feature in the middle of the network. Some feedback mechanism becomes required so that a router on the path to the destination can signal to the originating host that packets need to be fragmented. The Packet Too Big ICMPv6 message is used for that purpose. It contains the MTU for the failing link and the original datagram portion that fit into the 1280-byte packet. The ICMPv6 message is primarily an error message. However, it was slightly diverted from its original purpose, to enable hosts to discover the minimum MTU on a path to a particular destination. This is the PMTU 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 reduces the PMTU and fragments packets accordingly. It keeps going until it stops receiving the Packet Too Big messages. 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#ping Protocol [ip]: ipv6 Target IPv6 address: 9009::72e Repeat count [5]: 2 Datagram size [100]: 1400

Internet Control Message Protocol for IPv6

67

Example 2-9 PMTU Discovery Performed by a Cisco Router (Continued) !note that the MTU on one of the routers(biot) on the path has been set to 1300 00:03:21: ICMPv6: Received ICMPv6 packet from FE80::A8BB:CCFF:FE01:F600, type 134 Type 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 ms Router# 00:03:23: ICMPv6: Sending echo request to 9009::72E 00:03:23: ICMPv6: Received ICMPv6 packet from 9009::72D, type 2 00:03:23: ICMPv6: Received ICMP too big from 9009::72D about 9009::72E, MTU=1300 00:03:23: ICMPv6: Sending echo request to 9009::72E 00:03:23: ICMPv6: Received ICMPv6 packet from 9009::72E, type 129 00: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 below Router#show ipv6 mtu MTU Since Destination Address 1300 00:00:07 9009::72E

Parameter Problem As in ICPMv4, the Parameter Problem messages provide a way for routers to report more generic issues not covered by the first three messages described previously. The ICMPv6 message can point out (by signaling the offset of that field) any field anomaly in the IPv6 header that prevented the datagram from being processed further. 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, these two messages are widely used to perform simple connectivity diagnostics, via the ping command. The format of the messages is pretty much unchanged. Besides a type (1) and a code (1), the messages contain an identifier and a sequence number, plus some optional data, copied back from the Request into the Reply.

68

Chapter 2: An IPv6 Refresher

Many more informational messages have been specified in various RFCs for the benefit of a large variety of protocols, such as Neighbor Discovery, MIPv6, and multicast. Those are covered in detail in the corresponding sections.

Source Address Selection Algorithm One of the specificities of IPv6 is that a node can commonly have multiple addresses to choose from when selecting the source or destination of a packet. Multiple unicast addresses can be assigned to the same interface, and they may have different reachability scopes (link-local or global). Dual-stack nodes might even have a choice between IPv4 and IPv6 addresses, in particular if the DNS server has provided both of them for a given name. Multihoming is likely to enable multiple addresses per node, and MIPv6 introduces home address and care-of address in the same node. Two algorithms have been specified in RFC 3484, one for source address selection (SAS) and one for destination address selection (DAS). This section details the former (SAS), because it is commonly used by ICMPv6 to select the SA to use before generating an error or informational message. Many other aspects of IPv6 operation, besides ICMP, are required to deal with SAS, or have ramifications for SAS, and in some cases, encounter issues with SAS. MIPv6 and VPNv6 represent two examples, so the SAS topic will be brought up again in the respective sections. The algorithm presented here describes the current state of SAS. The SAS algorithm does not take precedence over the application or upper-layer choice. For instance, in the ICMP case, a response to a query just uses the SA that is the DA of the corresponding request. When used, the algorithm is provided with a list of candidate addresses, and applies to this list a set of rules to select the candidate that matches the maximum number of these rules. If a rule has no matching candidates, a candidate address from the list before the rule was applied is chosen. Figure 2-19 provides a logic diagram of the SAS algorithm. As mentioned in the “IPv6 Addressing” section of this chapter, the addresses of site-local scope have been deprecated and replaced by unique-local addresses, with global scope. These addresses have not yet explicitly found 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, and used for many different purposes (from error reporting to diagnostic and network operations). Messages are structured the same way as in ICMPv4, with a type, code, and body; some message types have been carried over from ICMPv4, and some new ones have been defined.

Internet Control Message Protocol for IPv6

Figure 2-19 Source Address Selection Algorithm Enter List of Candidate SA

No

Any Candidate Equal To DA

Yes

Select SA with the Closest but Smaller Scope Than DA >1

Candidates Left

1

Avoid Deprecated Address >1

Candidates Left

1

Prefer Home Address >1

Candidates Left

1

Prefer Outgoing Interface >1

Candidates Left

1

Prefer Matching Label >1

Candidates Left

1

Prefer Public Address >1

Candidates Left

Pick one SA from the Remaining List

Pick That SA SA

SA: Source Address DA: Destination Address

1

69

70

Chapter 2: An IPv6 Refresher

However, the uses of ICMPv6, in particular by the Neighbor Discovery Protocol (NDP), are greater than ICMPv4 uses. Whether this is the right approach and the right protocol to perform things as diverse as address resolution, error reporting, autoconfiguration, MIPv6 tasks, and so forth remains to be seen on the deployment side.

Neighbor Discovery Protocol IPv6 Neighbor Discovery (ND) was first designed and published almost 10 years ago, as RFC 1970. It has been revised since then as RFC 2461, and a new version, focusing on fixes rather than revisions, is underway as RFC 2461bis. Some extensions have been described in Inverse Neighbor Discovery (RFC 3122), Default Router Selection (RFC4191), and Autoconfiguration (RFC 2462). In these 10 years, the focus of the Internet community has shifted significantly, and areas that did not get much attention, such as security and mobility, are now the focus of most of the efforts. This change of focus has led to a number of extensions, clarifications, and interactions described in various RFCs and Internet Drafts: Extension for Mobility in MIPv6 (RFC 3775), Security Features in Secure Neighbor Discovery (SEND) (RFC 3971), Detecting Network Attachment (DNA) (RFC 4135), Protocol for Carrying Authentication for Network Access (PANA) (RFC 4058), and Optimistic DAD (draft-ietf-ipv6-optimistic-dad). The IPv6 NDP provides a number of integrated key features for router and host operations, when attached to the same link. Some of these features, such as address resolution and redirect, are seen in IPv4, under specific distinct protocols such as ARP and ICMP Redirect, respectively. Other features—for instance, prefix discovery and neighbor unreachability detection—are new, although some could be achieved by other means with IPv4, too. Table 2-12 lists these features and their correspondence in IPv4. Table 2-12

IPv6 NDP Feature Counterpart in IPv4

IPv6 ND Feature

Short Description

IPv4

Router discovery

Enables hosts to locate routers on attached links

ICMP Router Discovery (RFC 1256)

Prefix discovery

Enables hosts to learn prefixes used on attached links

Not available

Parameter discovery

Enables nodes to learn parameters such as link MTU or hop limit

PMTU Discovery (RFC 1191)

Address autoconfiguration

Enables hosts to configure automatically an address

Not available

Address resolution

Enables nodes to determine link-layer address for on-link destinations

ARP

Next-hop determination

Enables nodes to determine the next hop for a given destination

ARP cache for on-link prefixes

Routing protocols snooping

Default router otherwise

Neighbor Discovery Protocol

Table 2-12

71

IPv6 NDP Feature Counterpart in IPv4 (Continued)

IPv6 ND Feature

Short Description

IPv4

Neighbor unreachability detection

Enables nodes to detect that a neighbor is no longer reachable

Dead Gateway Detection (RFC 816, RFC 1122)

Duplicate address detection

Enables nodes to determine addresses already in use

ARP with source=0

Redirect

Enables routers to inform hosts of a better next hop on the link for a particular destination

ICMP Redirect

Default router and morespecific route selection

Enables routers to inform multihomed hosts of better default routers and more specific routes

Proxying nodes

Accepts packets on behalf of other nodes

Proxy-ARP

NDP applies to both hosts and routers in different ways. Table 2-13 attempts to separate hosts and router roles, with regard to the preceding list of features. Table 2-13

Host and Router Roles with Regard to NDP

Host Algorithms Default router selection

Next-hop determination

Host-Host Communication

Host-Router Communication

Node-Node Communication

Neighbor unreachability detection

Router discovery

Address resolution

Duplicate address detection

Prefix discovery

Default router selection 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 split between ARP/RARP, right above the link layer, and ICMP, running above IP, IPv6 ND is implemented entirely within ICMPv6. Figure 2-20 highlights differences between the protocol stacks. The reasons for the ND positioning within the stack are numerous, but if only one should be mentioned, it is simplicity. 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 security (Authentication Header), multicast, and so on.

72

Chapter 2: An IPv6 Refresher

Figure 2-20 IPv4 and IPv6 Protocol Stack Comparison

IPv4 “Neighbor Related” Protocol Stack Application

HTTP FTP, Telnet, etc.

RIP RADIUS Traceroute DNS, etc.

TCP

UDP

Transport

Router Discovery PING Path MTU Discovery Redirect RTP, SCTP, etc. ICMPv4

IP

Network

ARP

RARP

IPCP

Ethernet/802.3 Token Ring (802.5) SNAP/802.2 X.25 FDDI ISDN Frame Relay SMDS ATM Wireless Fibre Channel DDS/DS0/T-carrier/Ecarrier, SONET/SDH DWDM PPP HDLC SLIP/CSLIP xDSL Cable Modem (DOCSIS)

Data Link

IPv6 Neighbor Discovery Protocol Stack Application

HTTP FTP, Telnet, etc.

RIP RADIUS Traceroute DNS, etc.

TCP

UDP

Transport Network

Data Link

PING

IPv6

Neighbor Discovery/ Inverse ND RTP, SCTP, etc. ICMPv6

Ethernet/802.3 Token Ring (802.5) SNAP/802.2 X.25 FDDI ISDN Frame Relay SMDS ATM Wireless Fibre Channel DDS/DS0/ T-carrier/Ecarrier, SONET/SDH DWDM PPP HDLC SLIP/CSLIP xDSL Cable Modem (DOCSIS)

To secure the various functions in NDP, Secure Neighbor Discovery has introduced a set of specific ND options. They are used to protect NDP messages. Although this IPv6 refresher does not go into more detail about 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 proper decisions when sending IPv6 packets to a neighbor. This knowledge represents a compilation of advertisements received from routers and nodes. These advertisements can be solicited or unsolicited. This information 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)

Neighbor Discovery Protocol

73

To obtain the above information, the following messages are used in the NDP:

• • • • • • •

Router solicitation (RS) Router advertisement (RA) Neighbor solicitation (NS) Neighbor advertisement (NA) Redirect Inverse neighbor solicitation (INS) Inverse neighbor advertisement (INA)

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 that association has to send its query to a wider audience. In IPv4, this is done using MAC-level broadcasts. In IPv6, the node uses multicasts for this query. The multicast group used is the solicited-node (with link-local scope), 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 confirm the 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 use the 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 a global or the link-local address of the sender: The latter is always preferred, to minimize the node’s dependency on renumbering. Here is a list of all special addresses, sources, and destinations that a node can use in NDP exchanges:

• • • • •

All-nodes multicast address (FF02::1, destination) All-routers multicast address (FF02::2, destination) Solicited-node multicast address (destination) Link-local address (source or destination) Unspecified address (::, source)

Finally, two algorithms are leveraged by the IPv6 nodes to process the information gathered through NDP:

• •

Next-hop determination algorithm Default router selection

74

Chapter 2: An IPv6 Refresher

Comparison with IPv4 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 default router.

•

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 are a 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 (being redirected) 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 the target address. Most likely, therefore, only a few (most of the time only the target address owner) nodes will get interrupted with such addressresolution queries. Compare this with IPv4 ARP, which has no other choice than broadcasting (link-layer broadcast) the address-resolution requests (because ARP sits directly above the link layer). One hopes that the IPv6 way of resolving link-layer addresses will make subnets with a much larger number of hosts more manageable by drastically limiting link-layer broadcasts that host software layers have to handle.

•

Some new features such as address autoconfiguration and neighbor unreachability detection are part of the base protocol, simplifying configurations and improving robustness of packet delivery.

•

Router advertisements and Redirect messages carry router addresses in the form of link-local addresses, which makes the router association in the host more robust to renumbering (of global prefixes). In IPv4, the default gateway information has to be modified on the host every time the network changes its addressing scheme.

•

The positioning of address resolution above ICMP makes it possible to use standard IP authentication and 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 parameters related to address configuration. Two messages have been defined for router and prefix discovery: the router solicitation (RS) message and the router advertisement (RA) message.

Neighbor Discovery Protocol

75

Routers advertise themselves periodically (with a slight randomization to avoid synchronization, which could leave some time intervals with no routers being advertised) out of each interface by sending RAs. These unsolicited RAs are sent to the all-nodes “linklocal scope multicast address” (FF02::1). In addition to providing 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 Router Selection” 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). This information 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 particularly useful in mobility, to accelerate autoconfiguration. These solicited RAs are sent either to the all-nodes address or to the unicast address of the host, which issued the RS. As the RS is soliciting a response from on-link routers, it is typically sent to the all-routers multicast group. Figure 2-21 shows the flow for a solicited and for an unsolicited RA exchange. Figure 2-21 Router Advertisement Flow Host1

Valbonne

Host2

Biot

RS 133 unspec all-routers which router? RA

ICMP type: 134 Source: valbonne link-local Destination: all-nodes RA

Solicited RA

ICMP type: Source: Destination: Query:

ICMP type: 134 Source: biot link-local Destination: all-nodes

RA

Packet Source

NOTE

Unsolicited RA

ICMP type: 134 Source: biot link-local Destination: all-nodes

Packet Receiver

In the case of a solicited RA, when the RS does not provide any IPv6 SA (typical for hosts that rely on RAs to autoconfigure themselves), the RA response is sent to all nodes.

76

Chapter 2: An IPv6 Refresher

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 below the RA flow. Figure 2-22 shows a debug trace interleaved with the RA flow. Figure 2-22 Router Advertisement Example Host1

interface Ethernet0/0 ip address 50.1.1.3 255.255.255.0 ipv6 address 2001:200::72c/64

ipv6 unicast-routing ! interface Ethernet0/0 ip address 50.1.1.2 255.255.255.0 ipv6 address 2001:100::72B/64 ipv6 address 2001:200::72B/64

Host1* debug ipv6 nd

Valbonne

Valbonne* debug ipv6 nd RA 03:23:55: ICMPv6-ND: Sending RA to FF02::1 on Ethernet0/0 03:23:55: ICMPv6-ND: MTU = 1500 03:23:55: ICMPv6-ND: prefix = 2001:100::/64 onlink autoconfig 03:23:55: ICMPv6-ND: 2592000/604800 (valid/preferred) 03:23:55: ICMPv6-ND: prefix = 2001:200::/64 onlink autoconfig 03:23:55: ICMPv6-ND: 2592000/604800 (valid/preferred)

00:21:37: ICMPv6-ND: Received RA from FE80::A8BB:CCFF:FE01:F600 on Ethernet0/0

The show ipv6 routers command is used on a Cisco router to display RA information received from other on-link routers. Only the router sends RAs, and only the hosts install them in their database. So in the configuration in Figure 2-22, this command applies only to host1 (a Cisco router in host mode). Example 2-10 shows the output of this command. Example 2-10 Host Perspective of Advertised Routers. host1#show ipv6 routers Router 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 node operations:

• • •

Link-layer address resolution Duplicate address detection (DAD) Neighbor unreachability detection (NUD)

Neighbor Discovery Protocol

77

DAD and NUD are described in next sections. ND link-layer resolution provides a similar service to ARP in IPv4, although using a slightly different method. Two ICMPv6 messages have been defined for IPv6 address resolution: the neighbor solicitation (NS) message and the neighbor advertisement (NA) message. The NS is the query and contains the target (queried) IPv6 address. The NA is the response and contains the link-layer address of the matching interface. 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 the link-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 queried IPv6 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 members of 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 could conclude 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 nodes on the link about a change in their link-layer address. The unsolicited NA is sent to all-nodes multicast address. 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-resolution process. On Cisco routers, the association (layer 3 address, link-layer address) is stored in the neighbor cache. The command show ipv6 neighbor executed on each router lists the neighbor cache content. In Example 2-11, the biot neighbor cache has two entries that relate to router valbonne: 2001:200::72b and FE80::A8BB:CCFF:FE01:F600. They are listed in “reachable” state along with the corresponding link-layer address.

78

Chapter 2: An IPv6 Refresher

Figure 2-23 Address-Resolution Flow Host1

Valbonne

Host2

Biot

NS 135 host1 solicited-node multicast link-layer address matching host2 ? NA

ICMP Type: 136 Source: host2 Destination: host1

Packet Source

Unsolicited RA

NA

ICMP Type: 136 Source: host2 Destination: all-nodes

Solicited RA

ICMP Type: Source: Destination: Query:

Packet Receiver

Example 2-11 Example of IPv6 Neighbor Cache biot#show ipv6 neighbor IPv6 Address 2001:200::72B FE80::A8BB:CCFF:FE01:F600

Age 0 0

Link-layer aabb.cc01.f600 aabb.cc01.f600

AddrStateInterface REACH Et0/0 REACH Et0/0

Redirecting a Host to a Better Next Hop Routers send redirect messages to inform hosts of a better next hop, whether another router or the final destination 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 IP address that is a better next hop and the IP address of the destination that is redirected. If the link-layer address 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 and the router R2. In practice, the benefit may be limited. The router R2 is likely, at some point, to route some traffic back to the host. To do so, it will need to initiate an NS/NA exchange to determine the host link-layer address. This flow would have been unnecessary had the host initiated an address-resolution flow to find R2’s link-layer address. The link-layer address of the initiator of the NS can indeed also be inserted, as an option, in the NS packet.

Neighbor Discovery Protocol

79

Figure 2-24 shows the flow for the redirect message. Figure 2-24 Redirect Flow Host3 Host1

Valbonne

Host2 Biot

Source: host1 Destination: host3 ICMP Type: Source: Destination: ICMP Destination: ICMP Target: Option(*)

137 link-local on outgoing interface host1 host3 biot biot link-layer address

Redirect Source: host1 Destination: host3

Packet Source

Packet Receiver

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 Inverse Neighbor 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 achieve this, it sends solicitations and receives advertisements. The IND was originally developed for Frame Relay networks, but may also apply to other data-link technologies with similar behavior. Two messages—the inverse neighbor discovery solicitation (INS) and the inverse neighbor discovery advertisement (INA)—have been defined. The INS contains the source link-layer address and the target link-layer address (for which the sender expect to get an IPv6 address). The response (INA) contains the source link-layer address, the target link-layer address, and a target address list. It contains the list of one or more IPv6 addresses of the interface identified by 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.

80

Chapter 2: An IPv6 Refresher

Proxy Neighbor Discovery An IPv4 node has the capability to proxy subnets for hosts that do not understand subnet (or are misconfigured) or default routers. This function is sometimes referred to as proxyARP and is specified in RFC 1027. IPv6 does not carry over that concept; instead, it requires IPv6 hosts to process RAs and to come up with a default router to which nonlocal traffic can be sent. Furthermore, proxying an entire subnet might be, 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 link but want neighbors to believe they are not. A classical example is a mobile node that has moved off-link. To achieve this limited proxy address-resolution function, the router just has to register to the solicited-node multicast addresses it wants to proxy and answer NSs on their behalf.

Neighbor Discovery Algorithms A number of ND algorithms have been defined to describe the expected behavior of both hosts and routers in a 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 the destination. Finally, it has to resolve the on-link destination address, or the on-link next hop, into a link-layer address. Unlike IPv4, a destination (or next hop) can be on-link, without the forwarding node having a prefix matching the 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 table and 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 for on-link nodes, either final destination or next hops. Cisco routers also have a forwarding table (Forwarding

Neighbor Discovery Protocol

81

Information Base, or FIB), which takes the RIB one step further by pre-resolving recursive entries to accelerate the forwarding process. In routers, regular routing mechanisms take precedence over information obtained from neighboring routers via prefix discovery or router discovery mechanisms. Then NS/NA messages 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 route IPv6 Routing Table - default - 7 entries Codes: 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 2 C 2001:100::/64 [0/0] via Ethernet0/0, directly connected L 2001:100::72B/128 [0/0] via Ethernet0/0, receive C 2001:200::/64 [0/0] via Ethernet0/0, directly connected L 2001:200::72B/128 [0/0] via Ethernet0/0, receive L FF00::/8 [0/0] via Null0, receive valbonne#show ipv6 neighbors IPv6 Address Age Link-layer Addr State Interface 2001:200::72A 1 aabb.cc01.f400 STALE Et0/0 FE80::A8BB:CCFF:FE01:F400 1 aabb.cc01.f400 STALE Et0/0

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 next hop (neighbor) that was chosen providing linkage into the neighbor cache. This cache is updated with information obtained from redirect messages.

•

Prefix list—Contains the list of prefixes that match the on-link addresses. This list is built from RA messages.

•

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.

82

Chapter 2: An IPv6 Refresher

Figure 2-25 Next-Hop Determination Algorithm

Lookup in Destination Cache for [D, N]

Found

Nexthop = N On-Link

Not Found

Lookup in Prefix List for [D, N]

Nexthop = D Not Found

Off-Link

Retrieve a Default Router N from Router List

Nexthop = D

Lookup in Neighbor Cache for Nexthop

Not Found

Not Found

Neighbor Discovery

Found

Nexthop = N

Found

Reachable

Entry State

Packet Dropped Reachable

D: Destination Address N: Neighbor on Same Link L: Link-Layer Address

Found

Forward Packet

Stale

Neighbor Unreachability Detection

Not Reachable

Address Resolution or Router Selection

The host first does a lookup into the destination cache, in case the destination of the packet has been seen recently. If so, the destination cache provides the next hop that was used (may be the destination itself), and a subsequent lookup into the neighbor cache is likely to provide the link-layer address. This path, shown in bold, will be the most exercised on an established flow. If the destination is not in the destination cache, it is searched in the prefix list (maintained from information received in RAs). As a last resort, a default router is selected, 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 make proper next-hop determinations. Unlike IPv4, a default gateway does not have to be defined on an IPv6 host. The procedure for a host to select a router as the next hop for its traffic is described in the “Default Router

Neighbor Discovery Protocol

83

Preference and More-Specific Routes” 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 RA option Route Information. (See the section “Router and Prefix Discovery” for details.) These hosts simply run the router selection algorithm as described in RFC 2461. Basically, a type A host selects a default router from its default router list (built from RAs received from routers sharing a link with the host). It should prefer a reachable router if any are available (known as reachable, according to the state machine; see the section “The State Machine for Reachability”) or any other router on the list, if available. If the selected router is not known as reachable, it should be selected in a round-robin fashion from among all the routers on the list (thus ensuring that all routers on the list are probed by the 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 preference rather than being round robin.

•

Type C—Hosts that implement a routing table. When they receive an RA with a number of occurrences of the Route Information option, they install a default route, ::/0, pointing to the router that issued the RA; they also install (or remove if the lifetime is 0) one route to the prefix found in the Route Information option, per occurrence. When a type C host does next-hop determination and consults its routing 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 making different 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 the default router. A dual-homed host could potentially receive disjoint prefix lists from two or more routers, and pick up one prefix from one list for autoconfiguration, forming an SA. It could then use this address (selected using SAS) to leave the subnet, via the router (selected as the default router) that did not advertise the prefix used to form this address.

Duplicate Address Detection The NS and NA messages are also used to perform duplicate address detection (DAD), as described in RFC 2462. DAD is performed on all unicast addresses prior to assigning them to an interface. The basic principle is that a node sends an NS to query about an IPv6

84

Chapter 2: An IPv6 Refresher

address ownership, and assigns the address to one of its own interfaces only if no NA was received for it. Optimistic DAD is proposing a modification of the existing IPv6 ND (RFC 2461) and stateless address autoconfiguration (RFC 2462) algorithms. The intention is to minimize address configuration delays in the successful case (the address chosen by the node is unique), and to reduce disruption as far as possible in the failure case. Optimistic DAD is only performed on automatically configured addresses. It is a useful optimization because DAD is far more likely to succeed than fail for a well-distributed random address or for an interface ID–based address constructed in the modified EUI-64 format from the unique MAC.

NOTE

DAD must not be performed on anycast addresses because by definition an anycast address can belong to multiple nodes.

Neighbor Unreachability Detection Communication with a neighbor may fail for a number of reasons. If the path (on the link) to the destination has failed, recovery may be possible. The recovery mechanism to invoke when a failure has been detected differs depending on whether the neighbor is also the final destination. If it is, the address resolution should be re-initiated. Otherwise, a different next hop should be selected. This falls under the next-hop determination algorithm (explained in “Next-Hop Determination” section), where two mechanisms can be used. Routers typically use their routing table, whereas hosts run the router selection algorithm (see the “Default Router Selection” section). The neighbor unreachability detection (NUD), however, deals with detecting the failure. Reachability of a neighbor is obtained in two possible ways. The first method is a confirmation from an upper layer that communication is happening with this neighbor (for instance, received TCP packets acknowledging previously sent packets). The second method is the receipt of an NA as a response to an NS sent by the node looking for reachability confirmation. Any other methods, such as RAs, cannot be used to confirm reachability of a neighbor. A neighbor then remains reachable for a limited amount of time, unless new confirmations come in. If the confirmation is not received in a timely manner, the neighbor is considered unreachable, and recovery mechanisms take place. The complete state diagram for neighbor entries in the ND cache 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 a state diagram of the neighbor cache.

Neighbor Discovery Protocol

85

Figure 2-26 ND Cache Entry State Diagram Create Entry Send NS

T

Incomplete Retry NS Te

NA1

NA2

Reachable

NA3 or U

Delay

NA5 or O T T or O or NA4 or NA5

Send NS

NA3 or U

NA3 or U T

S

Stale

NA5 or O

Probe Retry NS

T

Te

Report Error

Delete Entry

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

86

Chapter 2: An IPv6 Refresher

• • •

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 mapping between 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 moves to REACHABLE state, and traffic can be forwarded. If the router sees no traffic for that neighbor for a certain period of time (typically 30 seconds), the entry moves to the STALE state. From there, it can either move back directly to REACHABLE (typically upon upper-layer reachability confirmation) or to DELAY (if a packet is to be sent to this neighbor), where a new NS is issued, or it can be deleted (in our example) after a certain amount of time in STALE (typically hours).

Autoconfiguration The address autoconfiguration is used to automatically assign addresses to a host. Address autoconfiguration is specified in RFC 2462. It uses the NDP (specifically RAs) to obtain the prefix to build an address on, and again ND (specifically NS and NA messages) to test that the built address is not already in use. The default mechanism for autoconfiguration is stateless. Another mechanism, stateful, can be used and is specified in RFC 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

SLLA1

Router Advertisemen t (RA)

Advertise:

134

Routers

SLLA

Default router

Sender of the RS

On-link prefixes

or

Prefix information

Reachable prefixes

All nodes

Route information

Operation parameters

MTU

Advertisement interval Home agent information

Neighbor Discovery Protocol

Table 2-14

87

NDP at a Glance (Continued)

Message Name

Goal

Neighbor solicitation

Request the link-layer address of a target node

(NS)

ICMP Code

Sender

Target

Options

135

Nodes

Solicited node

SLLA

or Target node

Neighbor advertisement (NA)

Respond to NA

136

Nodes

Advertise link-layer address changes

Sender of the NS

TLLA2

or All nodes

Redirect

Inverse neighbor solicitation

Inform hosts of a better first hop

137

Request an IPv6 address corresponding to a link-layer address

141

Routers

Nodes

Host that triggered the redirect

TLLA

All nodes

SLLA3

Redirected header

TLLA3

MTU

(INS)

Source address list

Inverse neighbor advertisement

Respond to an INA

(INA)

142

Nodes

Sender of the INS

SLLA3 TLLA3 Target address list3

MTU

1SLLA:

Source link-layer address

2TLLA:

Target link-layer address

3Option

required

IPv6 is not limited, in the least, to the protocols reviewed in this chapter. However, this chapter covered the fundamental elements, to provide you with the tools to understand the most relevant differences between IPv6 and IPv4. With these tools in mind, the next chapters review IPv6 network services, all built “on top of” IPv6 addressing, ICMPv6, and the Neighbor Discovery Protocol.

CHAPTER

3

Delivering IPv6 Unicast Services Overview This chapter covers IPv6 unicast connectivity within an enterprise or service provider network, and discusses available options, implementation scenarios, and deployment recommendations. The intent is to present this information as it applies to different parts of the network:

• •

Hosts or Customer Edge (CE) routers Access and backbone infrastructures

The concepts that are relevant in making a host operational in an IPv6 network are presented first. This section of the chapter reviews the mechanisms for providing hosts and CE routers with an IPv6 address, and introduces new concept such as prefix delegation, for providing name-resolution support and for some AAA (authentication, authorization and accounting) management. Subsequent sections discuss the delivery of IPv6 unicast connectivity from a network perspective. The service deployment will most likely interact at some point with or over some segments with existing IPv4 infrastructures. In this interaction, there are three deployment approaches:

• • •

IPv6 only—IPv6 is the only protocol running over a given link (physical or virtual). Dual stack—IPv4 and IPv6 run together over the same link (physical or virtual). IPv6 at the edge only—IPv6 is confined to sites located at the edges of an existing IPv4 core infrastructure that it has to traverse.

These three approaches define a framework for the service deployment strategy. The technological means to implement them are presented in the context of the two relevant layers of the network: access and backbone. Table 3-1 summarizes the deployment mechanisms presented in this chapter. Along with the scope and significant features, the table lists the areas of the network where the mechanism would fit best.

90

Chapter 3: Delivering IPv6 Unicast Services

Table 3-1

IPv6 Unicast Deployment Mechanisms Scope

Where Used

Key Features

Limitations

Routed

Host/ Inter-site

Access/ Backbone

Simplest method in terms of setup.

Support on all network elements in the path.

Bridged (IPv6 RBE)

Host

Access

IPv6 RBE routes the IPv6 traffic out of a bridged ATM encapsulation.

PPP

Host/ Inter-site

Access

Dedicated links/ circuit

Inter-site

Backbone

It is a native method where a physical or virtual link interconnects two sites.

6PE

Inter-site

Backbone

MPLS infrastructure. IPv4 Label Switch Path setup. IPv6 transport over MPLS.

Applicable to MPLS infrastructure only. IPv4 and IPv6 traffic follow the same paths.

IPv6 MPLS

Inter-site

Backbone

MPLS infrastructure. Native IPv6 Label Switch Path setup. IPv6 transport over MPLS

MPLS only. LDP and RSVP IPv6 implementation not available.

Configured

Host/ Inter-site

Access/ Backbone

Static, supported by most IPv6 implementations.

Management overhead.

Mechanism Native IPv6

IPv6 over MPLS

Tunnels

Tunnel endpoints can be secured with IPv4 IPsec. Tunnel broker and tunnel server

Host

Access

Provides the means to automatically set up configured tunnels upon request. A dedicated device or a router performs this function.

Potential security implications.

Teredo

Host

Access

Works through multiple NATs.

Management overhead.

GRE

Inter-site

Access/ Backbone

Static. It supports the transport of layer 2 multicast, which is important for the control plane of some protocols (IS-IS).

Management overhead.

ISATAP

Host/ Inter-site

Access/ Backbone

Automatic tunnel.

Performance. No solution for multicast.

6 to 4

Inter-site

Access/ Backbone

Automatic tunnel. Reserved address space 2002::/16.

Return path selection not optimized. Security issue if not secured through IPsec.

IPv6 Provisioning

91

These mechanisms are presented in this chapter along with more in-depth discussions on deployment recommendations. The recommendations are made only from the perspective of providing IPv6 unicast connectivity. Other selection criteria are presented in the chapters dedicated to other services, such as multicast, virtual private networking (VPN), quality of service (QoS), and security. Overall, a deployment strategy choice depends on technical considerations (best way to leverage existent IPv4 infrastructure and to circumvent constraints such as Network Address Translation [NAT], for example) as well as cost-effectiveness considerations (for instance, return on the investment of upgrading existent resources or adding new ones). Nevertheless, when possible, it is recommended to begin with native IPv6—no IPv6 tunnels—because 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 the following information:

• •

Acquire the IPv6 address information for the node.

•

Finally, the node might have to keep accurate time for security purposes, which requires the addresses of Network Time Protocol (NTP) servers.

To be able to perform name-to-address mapping, the node needs to know the addresses of Domain Name System (DNS) recursive name servers.

These three provisioning aspects are independent of whether the “IPv6 node” is a host or a customer router. The information, other than the IPv6 address, mentioned in the bulleted list and necessary for the proper operation of the node is commonly referred to as other configuration information.

Host IPv6 Address Provisioning Providing IP addresses to hosts is an important aspect of deploying IP-based services. Manual configuration is always an option; however, it is not scalable and it is not easily adaptable to addressing changes. For this reason, IPv4 most often relies on Dynamic Host Configuration Protocol (DHCP) for address provisioning. The same mechanism is available for IPv6; it is called 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 them will not have the resources to support complicated provisioning mechanisms. At the same time, the nature of some of these devices and appliances would require them to have plugand-play capabilities. As a promoter of wider adoption of IP, IPv6 took this provisioning scenario into consideration and developed a simple autoconfiguration mechanism commonly referred to as stateless autoconfiguration.

92

Chapter 3: Delivering IPv6 Unicast Services

Stateless Autoconfiguration Stateless autoconfiguration operation is described in RFC 2462, and it relies on the Neighbor Discovery Protocol (NDP) reviewed in Chapter 2, “An Ipv6 Refresher” It is a simple IPv6 address 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 Router Advertisement (RA) messages to obtain the information needed for autoconfiguration. To acquire 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 and Prefix Discovery” section of Chapter 2. The host can listen to periodic RAs sent by routers on the link or it can poll for routers with the help of Router Solicitation messages. The prefixes information is extracted from the RA messages.

•

Generate an interface ID. To have a full IPv6 address, the host must add an interface identifier to a prefix learned from the routers on the link. The various options available for creating an interface ID are reviewed in the addressing section of chapter 2. Examples of those options are build a EUI-64 ID based on the MAC address, or randomly generate the address.

•

Verify the uniqueness of the generated IPv6 address. The IPv6 address that resulted from the previous two steps must be unique on the link. The Duplicate Address Detection (DAD) mechanism described in the section with the same name in Chapter 2 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 stateless autoconfiguration. This functionality can be turned off for each router interface with the IOS command ipv6 nd suppress-ra. Other parameters relevant to this provisioning mechanism can be 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 reasons—such as network changes, user-distribution changes, and network mergers—the IP addressing scheme must be changed. This process can consume significant resources of the network operations team. For this reason, any mechanism that simplifies renumbering would prove valuable. In the case of IPv6, stateless autoconfiguration provides the means to advertise the deprecation of a prefix at a certain day and time and to advertise a new prefix from that moment onward. This is done through the interface configuration command ipv6 nd prefix at .

IPv6 Provisioning

NOTE

93

A router must have the means to track dates and time if it is using this renumbering mechanisms. Date and time can be set on the router or learned via NTP. At the time of this writing, NTP over IPv6 is not supported by Cisco products. On the other hand, if the routers are 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 its removal is approaching. Hosts on that link deprecate the prefix because of its lifetime expiration 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 perform renumbering every time it changes ISPs. Updating the IPv6 addresses is just one aspect of the complex 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 interest shown by the Internet Engineering Task Force (IETF) in evaluating the renumbering options of IPv6. An example of such work is “Procedures for Renumbering an IPv6 Network without a 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 of hosts. Its operation for IPv6 is described in RFC 3315. The value provided by DHCP consists in the fact that provisioning is done through a centralized resource. This resource is easier to manage than having to make changes on all customer-facing router interfaces in the case of stateless autoconfiguration. DHCP can offer a host not only the IPv6 prefix, but also other relevant information as well over the same message exchange. The disadvantage of using this provisioning 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 this reason deployments favor the stateless autoconfiguration (for IPv6 prefix information) in combination with stateless DHCP (for other configuration information) rather than stateful DHCP. Cisco routers do not act as DHCP servers for IPv6 stateful autoconfiguration; however, the Cisco Network Registrar (CNR) can currently perform that function.

94

Chapter 3: Delivering IPv6 Unicast Services

Although conceptually similar, there are several differences between IPv4 DHCP and IPv6 DHCP:

•

Some message types, such as DHCP-DISCOVER and DHCP-OFFER, are not used in IPv6 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 same time.

Figure 3-1 shows the message exchange between a client and the DHCP server for both provisioning and renewal. The SOLICIT message sent by the client has the role of discovering a DHCP server. It is sent to the reserved, link-local scope multicast address FF02::1:2. In this example, the client requests a nontemporary address (IA-NA). The client selects a server from all the ones that replied with an ADVERTISE message, and it requests the information of interest (nontemporary address, DNS server address, and domain list). The server provides the information in a REPLY message. Figure 3-1

DHCPv6 Client-Server Message Exchange DHCPv6 Server

Client

Solicit

Destination Address: FF02::1:2 Options: ClientId, Option Request Option (IA-NA, DNS-Servers, Domain-List)

Request

Advertise

Options: ServerId, ClientId, Option Request Option (IA-NA, DNS-Servers, Domain-List) Options: ServerId, ClientId, DNS-Servers: 2001:DB8:100::1 IA-NA: IAID: 1, IAPREFIX: Preferred lifetime: 604001, Valid lifetime: 2591201 Prefix: 2001:DB8:FF01:1::1/64

Reply

Reply

NOTE

Address Renew

Renew

Client Initiated Configuration

Options: ServerId, ClientId, DNS-Servers, IA-NA (IAID, IAPREFIX)

For each IPv6 address received from the DHCPv6 server, the client performs Duplicate Address Detection.

IPv6 Provisioning

95

As far as the client is considered, the DHCPv6 server is located on the same link (this is the reason why it sends the SOLICIT message to a link-local scope multicast destination address). However, this is most often not the case. DHCP-based provisioning is done for all links from a centralized location, which means that the DHCP server is not on the same link as most hosts. When the DHCPv6 server is not on the same link with the client, the routers on the link must be configured to relay the client SOLICIT messages to the DHCP server. The interface configuration command for enabling this functionality is ipv6 dhcp relay destination . If the unicast address of the DHCP server is 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 the router unicasts the client messages to each server. The router can also be configured to forward the client DHCPv6 messages to another DHCP relay router. If the address of the DHCP server is not known, the relay router can be configured, with the help of the interface command mentioned previously, to forward the client messages to the All-DHCP-Servers reserved multicast address FF05::1:3. By default, the Cisco router interface advertises the information necessary for stateless autoconfiguration. 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, the RAs inform hosts that they must use DHCPv6 to acquire provisioning information, including the IPv6 address.

NOTE

Stopping the router from transmitting RAs is not a practical option for forcing hosts to use stateful DHCP. On one hand, the host protocol stacks might not switch to stateful DHCP if they do not receive a reply to their router solicitations. On the other, this approach impacts the operation of other link-local functions such as router discovery.

Router IPv6 Address Provisioning: Prefix Delegation Prefix delegation (PD) is a mechanism developed to provide automated delegation of IP address blocks. The delegation is done from an ISP to its customer. The ISP does not require any 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 address blocks are typically delegated manually. That is, when the service is ordered, the ISP informs the customer via e-mail or snail mail what the address block is. The customer then has to manually configure the network with the given network prefix. Not only is this approach error prone, it is also expensive. Because there is little reason to try to conserve address space for IPv6, it is expected that all users will be allocated a

96

Chapter 3: Delivering IPv6 Unicast Services

long-lived address block. Therefore, a scalable way of delegating address blocks is needed. The requirements for prefix delegation can be found in RFC 3769. Various PD proposals were made in the IETF. An initial proposal was made for a protocol based on Internet Control Message Protocol (ICMP). It soon became clear that the requirements and mechanisms suggested for prefix delegation would best be implemented based on DHCP. Address assignment does not, after all, differ greatly from PD. The existing DHCP messages and the DHCP address options were used as a template to create DHCPbased prefix delegation, described in RFC 3633.

Protocol Description The PD protocol runs between a Customer Edge (CE) and a Provider Edge (PE) router. In PD terminology, the CE is called a Requesting Router (RR) and the PE router a Delegating Router (DR). The RR acts as the DHCP client, and requests prefixes from the DR (DHCP server). The DR verifies the authenticity and the profile of the RR with a AAA server, and that server provides the prefix. The DR injects a route into the provider’s routing system for the delegated prefix on behalf of the RR. That way, a dynamic routing protocol between the RR and the DR is not needed; however, the RR and the DR must be directly connected. This restriction is comparable to DHCP, as described in RFC 3315, which allows DHCP relays in the path between the DHCP client and the DHCP server. Figure 3-2 shows this PD process. Figure 3-2

DHCP-PD Architecture AAA Server Customer #1: 2001:DB8:FF00::/48

Customer #1 prefix passed to DR via Radius

Delegating Router ISP Network

Customer #1 prefix passed to RR via DHCP

Customer #1 Network Requesting Router RA: Subnetted prefix: 2001:DB8:FF00:1::/64

Link1

RA: Subnetted prefix: 2001:DB8:FF00:2::/64

Link2

IPv6 Provisioning

97

For a nondirectly connected CE-PE configuration, a DHCP relay option has been proposed. It provides 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 as straightforward as it might first seem. One would need a mechanism to negotiate which of the many dynamic routing protocols to use (manual configuration isn’t acceptable because it would defeat the purpose of a fully automated solution). Making the CE responsible for injecting routing information into the provider routing system might not be a good idea. It not only requires the customer to be able to configure their routers correctly, it also requires the provider to trust the customer not to be tempted to inject routes for prefixes not belonging to it. The latter case can be solved by applying route filters on the PE. Because that also requires explicit knowledge of the delegated prefix on the PE, it might as well also inject the route on behalf 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 identifier created 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 a reboot). 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 the link replies with an ADVERTISE message. The RR then sends a REQUEST, again with the PD 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 to indicate the scope of its request. The association is labeled with an identifier (IAID) that is used throughout the message exchange. Figure 3-3 shows the PD process. The SOLICIT and ADVERTISE messages represent the process of the RR discovering DHCP-PD servers (DR). In cases where an RR can have access to at most one DR (as is the case of point-to-point uplinks), the discovery process can be eliminated and the four steps of negotiation can be shortened to two messages. This shortened process is called DHCPPD Rapid Commit and it can be used only if the DR supports the DHCP Rapid Commit feature. 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 an agreement about the length of time over which the RR is allowed to use the prefix. An RR can request an extension of the lifetimes on a delegated prefix and is required to terminate the use 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 router replies with a REPLY message containing the prefix option with new lifetimes. During a network renumbering, the DR includes both the old and the new prefixes in the message. The old one has shorter lifetimes, and after some time, typically a few weeks, the old prefix expires, and only the new prefix is used.

98

Chapter 3: Delivering IPv6 Unicast Services

Figure 3-3

DHCP-PD Message Exchange Host

RR

DR

Solicit Options: ClientId, Option Request Option (IA-PD,DNS-Servers, Domain-List) Advertise Options: ServerId, ClientId, DNS-Servers, IA-PD (IAID, IAPREFIX) Request Options: ServerId, ClientId, Option Request Option (IA-PD, DNS-Servers, Domain-List) Reply Options: ServerId, ClientId, DNS-Servers: 2001:DB8:100::1 IA-PD: IAID: 1, IAPREFIX: Preferred lifetime: 604001, Valid lifetime: 2591201 Prefix: 2001:DB8:FF01::/48

RA

Packet Source

Packet Receiver

Other DHCP options might, of course, also be included in these messages. For example, DNS configuration options or Simple Network Time Protocol (SNTP) configuration options can be sent to the CE device. The CE device can run a stateless DHCP server on its downstream interfaces 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 facing the provider). The RR assigns a slice of the acquired prefix to each of its IPv6enabled downstream 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, and two downstream interfaces, Ethernet0/0 and Ethernet1/0. Example 3-1 Configuration of a DHCP-PD RR hostname CE ipv6 unicast-routing ! interface Serial2/0 ! Upstream interface—ISP ipv6 address autoconfig default

IPv6 Provisioning

99

Example 3-1 Configuration of a DHCP-PD RR (Continued) ipv6 dhcp client pd genpfx-foo ! interface Ethernet0/0 ! Downstream 1 ipv6 address genpfx-foo 0:0:0:1::1/64 ! interface Ethernet1/0 ! Downstream 2 ipv6 address genpfx-foo 0:0:0:2::1/64 !

No manual configuration of the delegated prefix is required. The upstream interface is configured as a DHCP-PD client. The prefix (or prefixes) received via the PD protocol is given a name, genpfx-foo. The ipv6 address commands on the downstream interfaces refer to this named prefix when configuring their own addresses. The general prefix gives the first part of the prefix, and the address command provides the last part of the address. Let’s assume a /48 prefix. The address specified in the address command is 0:0:0:1::1. The first 48 bits are being replaced by the prefix or prefixes received by DHCP. The next 16 bits are 0001, and the last 64 bits, the interface identifier, are set to ::1. 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 CE#show ipv6 general-prefix IPv6 Prefix genpfx-foo, acquired via DHCP PD 2001:DB8:FF01::/48 Valid lifetime 2591201, preferred lifetime 604001

As you can see, the prefix acquired with DHCP-PD is 2001:DB8:FF01::/48. The lifetime values of the prefix (valid, the amount of time the prefix is valid; preferred, the amount of time 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/0 and Ethernet1/0, as shown in Example 3-3. Example 3-3 Using the General Prefix to Provision Router Interfaces CE#show ipv6 interface Ethernet0/0 Ethernet0/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 603841 CE#show ipv6 interface Ethernet1/0 Ethernet1/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

100

Chapter 3: Delivering IPv6 Unicast Services

Note that if two prefixes were delegated, that would result in two addresses on every Ethernet interface, each generated from the general prefix command based on the prefixes, and the information given in the address command. Both prefixes will be advertised in RAs sent out on the interface. The ipv6 address autoconfig default command on the upstream Serial2/0 interface uses stateless address autoconfiguration to configure a global address on the interface. The default keyword in this command leads to a default route being installed. The default route points out the configured interface and the next hop is the delegating router. Example 3-4 shows the result 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/0 Serial2/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 604795 CE#show ipv6 route IPv6 Routing Table - 10 entries Codes: 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 2 S ::/0 [1/0] via FE80::A8BB:CCFF:FE02:8B00, Serial2/0 C 2001:DB8::/64 [0/0] via ::, Serial2/0 L 2001:DB8::A8BB:CCFF:FE02:8A00/128 [0/0] via ::, Serial2/0 S 2001:DB8:FF01::/48 [1/0] via ::, Null0 C 2001:DB8:FF01:1::/64 [0/0] via ::, Ethernet0/0 L 2001:DB8:FF01:1::1/128 [0/0] via ::, Ethernet0/0 C 2001:DB8:FF01:2::/64 [0/0] via ::, Ethernet1/0 L 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 route toward the Null0 interface has been installed for the delegated prefix. This so-called black hole route makes sure that the RR has routing information for the entire delegated address block. Otherwise, it would forward traffic along the default route for parts of the /48 that are not configured on the CE yet. The DR has a routing entry for the /48 toward the CE, so without the black hole route, you would have a routing loop. The output of the show ipv6 dhcp interface command provides the information relevant to the DHCP client, as shown in Example 3-5.

IPv6 Provisioning

101

Example 3-5 DHCP-PD Client-Relevant Information on the Upstream Interface CE#show ipv6 dhcp interface Serial2/0 Serial2/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:8B00 DUID: 00030001AABBCC028B00 Preference: 0 Configuration parameters: 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 (2590299 seconds) DNS server: 2001:DB8:100::1 Prefix name: genpfx-foo Rapid-Commit: disabled

The preceding output lists all the options received and the state of the DHCP protocol machine. If this output does not give enough information for troubleshooting, you can use the output 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 are several options:

•

Manual configuration with static binding—The DUID and associated prefix are configured on the delegated router for each customer.

•

Using a prefix pool—A pool of prefixes is configured on the DR. A new prefix is allocated from the pool dynamically. To store the state of the pool on a remote server, use the ipv6 dhcp database 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 RADIUS server. This way no customer-specific configuration is needed on the delegating router.

•

DHCP—As an alternative to the above, the delegating router functionality could be running on a central DHCP server. The PE router acts as a DHCP relay. Note that the PE router still needs to inject a route for the prefix into the provider routing system. A PD-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-pool prefix-delegation pool pfx-pool

continues

102

Chapter 3: Delivering IPv6 Unicast Services

Example 3-6 Configuration of DHCP-PD Delegating Router Using Pool of Addresses (Continued) dns-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-ra ipv6 dhcp server pd-pool

The configured DHCP pool is called pd-pool. Prefixes should be delegated from a local prefix pool named pfx-pool, and you should include the DNS attribute with the DNS server at 2001:DB8:100::1. A /40 prefix is reserved for the pfx-pool pool, and /48-sized chunks are delegated, as shown in 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-pool Prefix is 2001:DB8:FF00::/40 assign /48 prefix 1 entries in use, 255 available, 0 rejected 0 entries cached, 1000 maximum User Prefix Interface 00030001AABBCC028A0 2001:DB8:FF01::/48 Se2/0 PE#show ipv6 route C 2001:DB8::/64 [0/0] via ::, Serial2/0 L 2001:DB8::1/128 [0/0] via ::, Serial2/0 S 2001:DB8:FF01::/48 [1/0] via FE80::A8BB:CCFF:FE02:8A00, Serial2/0

In the DR’s Routing Information Base (RIB), the delegated prefix is inserted as a static route with a next hop being the RR’s link-local address out Serial2/0 (as shown in the preceding example). The delegating server keeps state for each RR. This state is kept in a binding database that is shown in Example 3-8. Example 3-8 Binding Database of a DHCP-PD Server Router PE#show ipv6 dhcp binding Client: 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)

IPv6 Provisioning

103

What DHCP-PD Does Not Do DHCP-PD is designed to solve the simple case of delegating a prefix across the administrative boundary between a provider and a customer. It does not solve the problem of how the prefix information should be propagated within the site. Router autoconfiguration has been 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 for hosts to discover DNS servers without relying on “third-party” servers. The idea was that as long as the on-link router worked, and the DNS server worked, no further “configuration servers” should be needed. Because DHCP is one such third-party server, it was initially ruled out as a part of the solution. Many proposals where evaluated, among them was using the Service Location Protocol or DNS options in RAs or well-known site-local DNS addresses. As a reminder, this function is handled by DHCP for IPv4.

NOTE

Note that in an environment running both IPv4 and IPv6, also called a dual-stack environment, 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 names to IPv6 addresses.

Stateless DHCP Stateless DHCP, specified in RFC 3315, is the term used to describe a simplified DHCP message exchange where no state is required to be kept in the DHCP server. The DHCP server simply passes other configuration information on to the host.

NOTE

Network managers can configure routers to leverage the ICMPv6/Neighbor Discovery options, called M bit and O bit in RAs, to signal to a host that it should use a stateful (really meaning DHCP) service to configure addresses and acquire other configuration information.

Nodes that use DHCP for address assignment will also obtain the other configuration information through the normal DHCP message exchange. Stateless DHCP is for nodes that do not use DHCP for address assignment (for example, stateless autoconfiguration or manual configuration). It is important to note that the options and messages used in stateless DHCP are the same as in “stateful” DHCP. There is no need for any special support for the stateless mode in the DHCP server or client.

104

Chapter 3: Delivering IPv6 Unicast Services

The simplified message exchange between the DHCP client and server goes as follows. The client sends an Information-REQUEST message to request configuration parameters, and the server 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 provisioning information other than the IPv6 prefix. A router configured this way sets the OtherFlag field to 1 in its RAs, as shown in the output of show ipv6 routers on a neighboring router (Example 3-9). Example 3-9 Output of show ipv6 routers on a Neighbor to a Router Advertising an OtherFlag Value of 1 Router#show ipv6 routers Router 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 604800 Router FE80::200:FF:FE01:F on GE-WAN1/4, last update 1 min Hops 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 autoconfig Valid lifetime 2592000, preferred lifetime 604800

DNS Services The Domain Name System (DNS) represents a resource and a mechanism that facilitate scalable deployments of IP services. It is a distributed database that stores name-to-IP address mapping information. This information helps users to identify the IP address of other hosts or 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 of several types RRs):

•

Start of Authority (SOA)—Marks the beginning of a DNS zone, typically the first record 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 most common use of the PTR RR is to construct the in-addr.arpa.com domain that provides the name corresponding to a given IPv4 address.

The IP address-to-name mapping is resolved by hosts, also called resolvers, through queries sent to the NSs for the necessary RRs (see RFC 1035). To expand the DNS functionality to IPv6, three aspects of the process had to be considered):

•

Define a new record that would store the 128-bit IPv6 address.

IPv6 Provisioning

• •

105

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 them between the Resolvers and the NS.

AAAA Records Two solutions were proposed for the first aspect of the DNS process: the AAAA record specified in RFC 3596; and the A6 record specified in RFC 2874, which is a super set of AAAA. The A6 could store records where the prefix portion of the address can be modified with no action from the administrators of the DNS zone. This could prove helpful when performing a network renumbering. On the other hand, the AAAA records are similar to the A 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 complete address (see RFC 3364). The IETF DNSEXT working group decided that the AAAA records are preferable for production deployments, whereas the A6 ones were moved to an experimental status. For more information on the AAAA versus A6 discussion, refer to RFC 3363 and RFC 3364.

IP6.ARPA Domain Similar to IPv4, a special domain is defined to find the host names that match an IPv6 address. 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 nibbles listed in reverse order terminated by .IP6.ARPA. Such a record is exemplified in Table 3-2 alongside an AAAA record. Table 3-2

IPv6 vs. IPv4 DNS Resource Records IPv4

IPv6

Name to IP Address

A Resource Record:

AAAA Resource Record:

www.example.com A 172.18.140.154

www.example.com AAAA 2001:1:F:1:F:1:F:1

IP Address to Name

PTR Resource Record:

PTR Resource Record:

154.140.18.172.in-addr.arpa PTR www.example.com

1.0.0.0.F.0.0.0.1.0.0.0.F.0.0.0.1.0.0.0.F.0.0.0.1.0.0. 0.1.0.0.2.ip6.arpa PTR www.example.com

Query Messages Changes To work in a dual-stack environment, the NS, Location of Services, and Mail Exchange query types have been modified. A DNS server replies to queries with both IPv4 and IPv6 information it holds (RFC 3596). In other words, when a dual-stack host queries an NS for the IP address corresponding to a given name, the reply contains an IPv4 and IPv6 address if both are in the RR. The node then selects the one it is interested in.

106

Chapter 3: Delivering IPv6 Unicast Services

All query messages can be transported in UDP or TCP on top of either IPv4 or IPv6, regardless of the IP version 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 the local DNS server is IPv6 only and the root NS for the domain is IPv4, the name resolution is not possible because 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 DNS server resides in an IPv4-only network and climbs up the tree starting with the root NS. The queries are exchanged 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 is similar to that of IPv4. The similarity resides in both implementation and in operation. For this reason, the functionality 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 and the protocols used to transport the user traffic into and out of the network. It is made of layer 2 devices such as Ethernet switches, digital subscriber line access multiplexers (DSLAMs), wireless access points, as well as layer 3 devices and routers. All of them are part of the same network management domain as the rest of the network (distribution and core layers). Depending on the design and service offering, the user traffic can exit the 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 the services 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.

IPv6 Network Access

Figure 3-4

107

Network Access Layer

Access Layer

ISDN/Dial

ATM

DSL

Cable Plant

Aggregation/ Core

FTTH

SP

Enterprise

IP

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 support some types because of market obsolescence:

•

Dialup (PSTN), Integrate Services Digital Network (ISDN)

108

Chapter 3: Delivering IPv6 Unicast Services

•

Digital subscriber line (DSL) with all its variants: symmetrical, asymmetrical, and very high data rate DSL

•

10 Mbps (IEEE 802.3), 100 Mbps (IEEE 802.3u), Gigabit (IEEE 802.3z/802.3ab), and 10 Gigabit (IEEE 802.3ae) Ethernet

•

Wireless WiFi 1–2 Mbps (IEEE 802.11), 11 Mbps (IEEE 802.11b), and 54 Mbps (IEEE 802.11a/g); wireless WiMAX (IEEE 802.16)

• • •

Data Over Cable Service Interface Specification (DOCSIS 3.0 for native IPv6 support) 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 Token Ring. 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. The way each media type handles multicast is important, because of its use in basic protocols such as Neighbor Discovery. Examples: • Turning on a multicast snooping feature on Ethernet switches might isolate users from critical multicast 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 Neighbor Discovery. 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, the network elements, their functionality, and their operation are standardized in the DOCSIS specifications. In its latest version (DOCSIS 2.0) and in the versions used in today’s cable networks, IPv6 is not explicitly supported. 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 the Ethernet interface unless it snooped an Internet Group Management Protocol (IGMP) join message on that 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.

IPv6 Network Access

•

109

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 are available, 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, cable operators 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 natively— that is, by encapsulating the IPv6 packet in layer 2 header and trailer, no tunneling over IPv4. Depending on the network design, you should consider three scenarios:

•

Routed access—The user-facing interface of the access router is not bridged. In this case, the IPv6 packets 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 RFC 2684 bridged Permanent Virtual Circuit (PVC).

•

Point-to-Point Protocol (PPP)-encapsulated IPv6—The user traffic is sent over a PPP session set up between 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 the exception of cable networks is to terminate each layer 2 domain (PVC, VLAN, WLAN) on a routed access aggregator interface. In this case, the customer premises equipment (CPE) has to be enabled for IPv6. For Ethernet and wireless access, the configuration is straightforward: global prefix under the main or the dot1Q/ISL-encapsulated subinterfaces. In the case of DSL and ATM PVCs, in general, the routed RFC 2684 encapsulation 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 from the bridge through a virtual interface, as in the case of Cisco IOS Integrated Routing and Bridging (IRB), or through the use the Cisco IOS Routed Bridged Encapsulation (RBE) feature. The latter solution is the most commonly 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 and route it. Figure 3-5 presents the typical topology in which the IPv6 RBE feature is used. The figure depicts the underlying technologies over which the IPv6 packet is transported.

110

Chapter 3: Delivering IPv6 Unicast Services

Figure 3-5

IPv6 RBE Customer

NAP/ISP

~bridging~

DSLAM

NAS ATM

IPv6

CPE PVC 1/32

IPv6

IPv6

Ethernet

Ethernet

Cat5

2684 b

IPv6 Ethernet IPv6 RBE

Cat5

ATM DSL NAP – Network Access Provider NAS – Network Access Server

When a bridged ATM PVC has the IPv6 RBE feature enabled on the access concentrator (Figure 3-5), it can be configured with an IPv6 address allowing it to terminate the layer 2 domain and route the IPv6 traffic through the rest of the network. Example 3-10 shows this configuration, with the IPv6 address and the RBE configuration highlighted. Example 3-10 IPv6 RBE Configuration interface ATM0/0/0.1 point-to-point ipv6 address 2001:1:1:1::1/64 no ipv6 nd suppress-ra atm route-bridged ipv6 pvc 1/32 encapsulation aal5snap

The interface configuration line no ipv6 nd suppress-ra explicitly re-enables the router to send RAs over that PVC. In this case, the CPE is bridging the traffic, and because it is IPv6 unaware, it does not have to be upgraded. 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 access router 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 to emulate a point-to-point link over Ethernet, as in the case of Point-to-Point

IPv6 Network Access

111

Protocol over Ethernet (PPPoE). This enables an ISP to better manage its customers or a network access provider (NAP) to hand over customer management to an ISP. When the ISP controls the AL, it can terminate the PPP sessions at the network access server (NAS), part of the AL. With DSL, the access media chosen for these examples, there are two ways in which the PPP encapsulation 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 PVC established over DSL to the access concentrator (NAS). The user traffic is encapsulated and transported via a PPP over ATM AL 5 (AAL5) established between the CPE and the NAS. Figure 3-6

IPv6 over PPPoA Customer

NAP/ISP

AAA Server CPE

NAS

DSLAM ATM

IPv6

PVC 1/32

IPv6

PPPoA

IPv6

Ethernet

IPv6

Ethernet

Cat5

PPP

Cat5

AAL5 ATM DSL NAP – Network Access Provider NAS – Network Access Server

The CPE has to route the IPv6 user traffic, and that means it will have to be upgraded to be a dual-stack router. A RADIUS server is used to authenticate and authorize the CPEinitiated PPP session. It also performs accounting functions. The configuration of a PPPoA setup is similar for IPv4 and IPv6. On the CPE, the PVC to the service provider is associated with dialer 1. This is shown in the following example: interface ATM0 pvc 1/32 encapsulation aal5mux ppp dialer dialer pool-member 1

112

Chapter 3: Delivering IPv6 Unicast Services

The dialer interface is configured for PPP, to use Challenge Handshake Authentication Protocol (CHAP) for authentication 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 Dialer1 encapsulation ppp dialer pool 1 dialer-group 1 ipv6 address autoconfig ppp authentication chap dsl ppp chap hostname [email protected] ppp chap password PASSWORD ppp ipcp address accept

The dialer interface is also configured with the host name and password that it will use to identify itself when opening the PPP session. When the PPP session is up and the dialer interface has an IPv6 address assigned by the provider, the CPE has to know where to route the user traffic. For this, a default IPv6 route points all traffic out the dialer interface, as shown here: ipv6 route ::/0 Dialer1

The NAS has to be configured to terminate the 1/32 PVC and associate it with a virtual template: interface ATM0/0/0.1 point-to-point pvc 1/32 encapsulation aal5mux ppp Virtual-Template1

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 the additional headers introduced by PPP, an adjustment is made to the maximum transmission unit (MTU) size used 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 enable ipv6 mtu 1480 no ipv6 nd suppress-ra ppp authentication chap peer 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).

IPv6 Network Access

113

Example 3-13 Relevant Configuration for Using RADIUS Authentication aaa new-model aaa authentication login default none aaa authentication ppp default group radius aaa authorization network default group radius aaa accounting network default wait-start group radius ! radius-server host 172.18.139.17 auth-port 1645 acct-port 1646 radius-server key radius-password

Although IPv6-specific RADIUS attributes are used in this implementation, the NAS is communicating with the RADIUS server over IPv4. It is expected that the RADIUS connection to the NAS will be in place from the operating IPv4 service. When the CPE establishes the PPP session to the NAS, an instance of the virtual interface is created from the template, and the first prefix from the pool is assigned to the session, as shown in Example 3-14. Example 3-14 Output Example Showing Information Relevant to an Established PPP Connection NAS#show ipv6 interface Virtual-Template1 prefix IPv6 Prefix Advertisements Virtual-Access1 Codes: 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 604800 NAS#show ipv6 local pool dsl Prefix is 2001:1:1::/56 assign /64 prefix 1 entries in use, 255 available, 0 rejected 0 entries cached, 1000 maximum User Prefix Interface dsl 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 two deployment options:

•

The CPE initiates the PPPoE session (similar to PPPoA). In this case, the CPE has to be upgraded to dual stack.

•

The user’s host initiates the PPPoE session. In this case, the CPE just has to bridge the traffic to the NAS.

114

Chapter 3: Delivering IPv6 Unicast Services

NOTE

The advantage of having the user initiate the PPPoE session is that the CPE is IPv6 unaware, so it does not have 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.

Figure 3-7

IPv6 over PPPoE Customer

NAP/ISP

IPv6 PPP IPv6

Ethernet

PPP

2684 b

IPv6

Ethernet

ATM

Ethernet

Cat5

DSL

Cat5

CPE

PPPoE

AAA Server

PVC

~bridging~

NAS

DSLAM ATM

IPv6

CPE PVC

PPPoE

IPv6

IPv6

IPv6

Ethernet

PPP

Ethernet

Cat5

2684 b

Cat5

ATM DSL

In the case where the PPPoE session is initiated from the hosts, the CPE is simply configured to bridge between 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 the same, whereas the PPPoEspecific portion is as follows: vpdn enable ! vpdn-group pppoe request-dialin protocol pppoe

IPv6 Network Access

115

The ATM subinterface configured for the 1/32 PVC to the NAS is enabled for PPPoE as shown here: interface ATM0.1 point-to-point pvc 1/32 pppoe-client dial-pool-number 1

The NAS configuration is the same in both cases. The RADIUS, virtual template, and pool configuration is identical to the example presented in the PPPoA section. The PPPoEspecific elements are as follows: vpdn enable ! vpdn-group pppoe accept-dialin protocol pppoe virtual-template 1

And the protocol being enabled on the ATM interface is this: interface ATM0/0/0.1 point-to-point pvc 1/32 encapsulation aal5snap protocol pppoe

In addition to the PPP-relevant show commands and debugs, you can use PPPoE-specific commands such as show vpdn and debug vpdn pppoe-events.

NOTE

Although this configuration example was given for a DSL access type, the same applies if the access is Ethernet 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. After providing broadband access, the NAP tunnels the subscribers to an ISP for address assignment and IP traffic forwarding. In other words, the NAP provides the ISP with a virtual AL. Figure 3-8 shows a conceptual representation of a NAP’s operation. In today’s IPv4 wholesale service provider networks, the most commonly used aggregation method is that of tunneling the PPP-encapsulated user traffic over a Layer 2 Transport Protocol version 2 (L2TPv2) tunnel to the ISP. However, L2TPv2 can be used only if the user is accessing the network via PPP. Otherwise, the option is to bridge the user traffic to the ISP over an L2TPv3 tunnel (Figure 3-8) .

116

Chapter 3: Delivering IPv6 Unicast Services

Figure 3-8

Virtualized Access Layer Using L2TP

L2TPv2 Access Aggregation NAP

PPP

IPv6

IPv6

ISP

L2TPv2

PPP

LNS

LAC

IPv6

IPv6

L2TPv3 Access Aggregation NAP

IPv6

IPv6

L2TPv3

ISP

L2TPv3

LAC

LNS

IPv6

IPv6

L2TPv2 Access Aggregation In this scenario, the NAP collects the PPP sessions at the L2TP access concentrator (LAC) that is part of the AL and sends them over an L2TPv2 tunnel to the L2TP network server (LNS), where the PPP sessions are terminated (see Figure 3-9) .

IPv6 Network Access

Figure 3-9

117

L2TPv2 Aggregation Customer

NAP

ISP

AAA Server ~bridging~

DSLAM

LNS

172.18.140.1

172.18.141.121

ATM

IPv4

IPv6

CPE PVC 1/32

LAC AAA Server

IPv6

PPPoE L2TP

PPP Ethernet Cat5

IPv6

IPv6 PPP

IPv6

Ethernet

PPP

2684 b

L2TP

ATM

UDP

DSL

IPv4

Ethernet Cat5

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 Loopback0 ip address 172.18.140.1 255.255.255.255 ! interface FastEthernet0 ipv6 address 2001:100:100:100::1/64 interface ATM0/0/0.1 point-to-point pvc 1/32 encapsulation aal5mux ppp Virtual-Template1 ! interface Virtual-Template1 ip unnumbered FastEthernet0 ppp authentication chap

The virtual template interface borrows the IPv6 address of FastEthernet0. The L2TP tunnel is set up over IPv4 between the LAC (172.18.140.1 and identifying itself as lac-example

118

Chapter 3: Delivering IPv6 Unicast Services

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 1 accept-dialin protocol l2tp virtual-template 2 terminate-from hostname lac-example local name lns-example ! interface Virtual-Template1 ipv6 mtu 1480 ppp authentication chap default peer 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 would most 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 service deployment.

The status of the PPP and L2TP sessions can be viewed on the LAC, as shown in Example 3-17. The tunnel to lns-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 tunnels L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions L2TP Class/ VPDN Group 28361 58155 lns-example est 172.18.141.121 1701 1 1 LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 24189 24189 28361 [email protected], - est 11w4d 1655

IPv6 Network Access

119

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 distinct access routers (when interconnecting two customer sites together) or the interface toward the ISP (when providing access to an ISP). The two endpoints are part of the same layer 2 domain, and there is no need for PPP encapsulation. This tunneling mechanism can be applied to Ethernet and Frame Relay interfaces. Similar to the L2TPv2 case, the tunnel is set up over IPv4 (Figure 3-10). Figure 3-10 L2TPv3 Aggregation Customer

NAP

ISP

172.18.140.1 172.18.141.121

IPv4

IPv6 ISP1

CPE AC1 IPv6

IPv6 L2TPv3

Ethernet Cat5

Ethernet

IPv6 Ethernet

IPv6

2684 b

L2TP

ATM

UDP

DSL

IPv4

Cat5

When applied to the interface, the protocol can be instructed to match only the IPv6 traffic based on its 0x86DD 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 the relevant configuration of the routers in Figure 3-10. Example 3-18 Configuration of Routers in an L2TPv3 Aggregation Deployment Model AC1 pw-class IPv6-user encapsulation l2tpv3 ! interface Loopback0 ip address 172.18.140.1 255.255.255.255 ! interface ethernet 0/1 ip address 10.1.1.1 255.255.255.0

continues

120

Chapter 3: Delivering IPv6 Unicast Services

Example 3-18 Configuration of Routers in an L2TPv3 Aggregation Deployment Model (Continued) xconnect 172.18.141.121 888 pw-class IPv6-user match protocol ipv6 ISP1 pw-class IPv6-user encapsulation l2tpv3 ! interface Loopback0 ip address 172.18.141.121 255.255.255.255 ! interface ethernet 0/2 ip address 10.2.2.2 255.255.255.0 xconnect 172.18.140.1 888 pw-class IPv6-user match protocol ipv6

The L2TPv3 approach proves useful in offering SOHO or other businesses a native IPv6 link between campuses or to an IPv6 ISP. For broadband users, however, the L2TPv2 would probably scale better.

Access over Tunnels IPv6 over IPv4 tunnels can be used over various segments of a network, and the reasons for using them fall into one or more of the following categories:

•

They represent a quick and inexpensive way to provide IPv6 connectivity. Although the endpoints have 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 the same entities.

•

They offer the means to transport the IPv6 traffic over portions of the network where the deployment of 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 option in this portion of the network because its interface with devices of various types and capabilities, devices that cannot be easily upgraded to support IPv6 natively. For a service provider, it might be cost-ineffective to replace 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 IPv4 NATs or scaling to a large number of sites. Table 3-1 in the “Overview” section of this chapter summarizes the IPv6 over IPv4 tunneling types currently in use along with their key features. Some of these tunneling mechanisms are intended to provide IPv6 connectivity to hosts only so they are used specifically in the AL portion of the

IPv6 Network Access

121

network. These tunnels are discussed in more detail in this section. The others can be used to interconnect sites as well as hosts and thus can be used in any part of the network. To show them applied in various contexts, some of them are presented in this section; the others are presented in the “IPv6 over the Backbone” section of this chapter.

Manually Configured Tunnel The manually configured tunnel (MCT) was one of the first transition mechanisms developed for IPv6. For this reason, MCT is supported by most IPv6 implementations, making it a safe choice when different vendors make the tunnel-termination devices. MCT is a static, point-to-point tunnel. It terminates on dual-stack routers. The tunnel endpoint’s IPv4 addresses have to be routable in the transitioned domain. A fixed IPv6 prefix has to be configured on the tunnel interfaces. Figure 3-11shows the relevant router configuration for the MCT. Figure 3-11 Configured Tunnel IPv4 Tunnel IPv6 Header Header Packet

2001:300::1/64 e0/0:200.15.15.1

IPv4 Access

Customer IPv6 Network

Tunnel 100 ipv6 address 201:300::1/64 no ipv6 nd suppress-ra tunnel source 200.15.15.1 tunnel destination 200.13.13.1 tunnel mode ipv6ip

2001:300::2/64 e0/0:200.13.13.1

Provider IPv6 Network

Configured Tunnel

Tunnel 100 ipv6 address 201:300::2/64 no ipv6 nd suppress-ra tunnel source 200.13.13.1 tunnel destination 200.15.15.1 tunnel mode ipv6ip

Dual Stack Router

In the case of the network AL, the tunnel is typically set up between a CPE or the user’s host and a router within the AL. Figure 3-11 shows an example of a configured tunnel between a CPE with IPv4 address 200.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 be exchanged over the tunnel interface, the feature should be re-enabled, as shown in the configuration example of no ipv6 nd suppress-ra.

122

Chapter 3: Delivering IPv6 Unicast Services

The static, manually configured nature of the tunnel makes it difficult to scale and manage. It is not suitable for providing access to home users where significant provisioning and scalability issues would impact the deployment. MCT is better used in linking a few customer (enterprise or ISP) sites in a fixed, long-term topology.

Tunnel Broker and Tunnel Server The MCT is suitable for the static setup of interconnecting IPv6 locations. If used for connectivity of a large number 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 the tunnel 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 by the same device that terminates the tunnel. Both these mechanisms are attempting to provide means to scale the 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 be achieved with an interoperating third-party device that acts as the broker.

Teredo NATs are a pervasive fact in today’s IPv4 networks. Most IPv6 over IPv4 tunneling mechanisms cannot transit NAT because of the protocol number used (41 for configured tunnel, for example). This means that if a user’s NAT router cannot be upgraded to support tunneling mechanisms, no tunnels can be sourced from the customer site. Teredo, or the shipworm, was developed to solve this problem. It provides address assignment and hostto-host, automatic tunneling for unicast IPv6 connectivity when hosts are located behind IPv4 NAT(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 client initiates the tunnel by contacting the server, which in turn signals the setup process to a Teredo Relay router connected to the IPv6 domain that has to be reached. The server is a stateless device and just proxies the tunnel setup process. The operation of the Teredo tunnel is described in detail in the latest revision of Internet Draft drafthuitema-v6ops-teredo.

NOTE

In a Teredo-based deployment, a router can perform the function of a server or a relay. However, this tunneling mechanism is not supported in Cisco IOS software.

IPv6 Network Access

123

Teredo is a last-resort transition mechanism for providing IPv6 connectivity. It is limited to host-to-host types of tunnels (as opposed to edge to edge or host to edges), and it is not a practical solution for providers to use it for the deployment of a paid service. If the infrastructure (CPEs and access routers) supports it or if/when IPv4 NAT handles protocol translation 41, the deployment should focus on native IPv6, 6 to 4, or ISATAP connectivity, as discussed in the next sections.

ISATAP The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specified in RFC 4214 was designed to provide a scalable tunneling mechanism within a privately addressed or globally addressed IPv4 site. Similar to other tunneling mechanisms, ISATAP encapsulates IPv6 in IPv4 using ip-protocol 41, so it does not work through NAT. ISATAP treats the underlying IPv4 infrastructure as an NBMA link layer. This mechanism is automatic; after the router has been configured, any client or other router within the site that is aware of its existence 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 sure that 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 to build an EUI-64 format interface ID from the layer 2 address. You can use a similar concept if considering the IPv4 infrastructure as the link layer on which IPv6 is running. In the case of ISATAP, the first 32 bits of the interface ID are 0000:5EFE; the other 32 are the IPv4 address of the interface, as shown in Example 3-19. Example 3-19 Building an ISATAP Format Interface ID IPv4 Address 200.15.15.1 IPv4 Address in hexadecimal format C80F:0F01 ISATAP-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 address based on the mechanism described in the preceding example. They can then do a name service lookup for the well-known service ISATAP and download the list of IPv4 addresses of the ISATAP operating routers in that domain. This enables the hosts to establish an ISATAP tunnel to one of these routers. The client sends a Router Solicitation and, with the suppression of RAs being explicitly disabled on the tunnel interface of the router, it will receive the necessary information to autoconfigure. Figure 3-12 shows a configuration example for an access router terminating ISATAP tunnels of users.

124

Chapter 3: Delivering IPv6 Unicast Services

Figure 3-12 ISATAP Tunnel IPv4 Tunnel IPv6 Header Header Packet

e0/0:200.13.13.1

200.15.15.1

IPv4 Access Access Router Provider IPv6 Network

ISATAP Tunnel

Tunnel 100 ipv6 address 2001:300:1:F::/64 eui-64 no ipv6 nd suppress-ra tunnel source 200.13.13.1 tunnel mode ipv6ip isatap

Dual Stack Router

A look at the IPv6 properties of the tunnel interface reveals the concepts of this tunneling mechanism (see Example 3-20) . Example 3-20 Status of ISATAP Tunnel Interface Access-Router#show ipv6 interface tunnel 100 Tunnel100 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

The interface ID used for the link-local, unique local and/or the global IPv6 addresses is generated from the IPv4 address. The ISATAP tunnels can be used between the routers within a site. The router configuration will be the same as 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 with NAT, 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. ISATAP could still be used in such scenarios if the tunnels are set up from the CPEs that have an IP address routable within the provider’s network. ISATAP is particularly suited for providing IPv6 access to individual, isolated dual-stack nodes within an IPv4 site. Its mode of operation also lends itself well to ad-hoc networking, and this proves useful for 3GPP networks.

IPv6 over the Backbone

125

IPv6 over the Backbone The backbone network can be defined as the network portion of the communication system that provides aggregation, interconnection, and transfer between network accesses defined in the “IPv6 Network Access” section. In a simple case, the backbone network is a single ISP infrastructure. Considering the complexity of the Internet, the backbone network is a combination of enterprises and ISP networks. In a typical topology, the backbone starts at the enterprise and spreads over several ISPs. Note that although some of the methods for transporting IPv6 customer traffic over the backbone assume that the backbone itself supports IPv6, others envision the case where it does not. In that context, the transitioning and coexistence mechanisms are of primary importance. 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 core routers run both IPv4 and IPv6 stacks.

•

IPv6 (and IPv4) uses a separate link layer—Some service provider backbones are simply using a layer 2 technology such as Frame Relay, ATM or Packet over SONET (PoS) to transport IPv4 traffic between edge routers. To establish IPv6 connectivity, routers attached to the ISP WAN or MANs can use the same layer 2 infrastructure as IPv4, but over separate ATM or Frame Relay PVCs, or over different optical lambda. Layer 2 links are terminated at the Internet exchange point 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 objectives—for instance, deploy some IPv6 service (for an enterprise), offer an IPv6 access (for the ISP), transition from IPv4 to IPv6—should drive tactical as well strategic choices. In the most likely scenarios, where IPv4-based networks are dominant in the backbone, tactical choices will typically deal with tunnel deployments, whereas dualstack backbones will be seen as the long-term strategy. Tunnels tend to be initially cheaper to deploy because they deal with a subset of the backbone nodes. On the dark side, they deliver suboptimal paths in most cases while causing packet overhead (in the form of an extra header). Tunnels also carry some configuration and management overhead, which grows with the number of tunnels, getting to a crossing point where it becomes more costeffective to migrate to dual-stack backbone. When tunnel mechanisms are used to transport IPv6 traffic over the backbone, tunnel endpoints can always be set up between edge-router pairs (PE) or between customer-router pairs (CE). Networks where a layer 2 transport technology or MPLS have been already deployed may keep IPv6 on the edge for a long time.

126

Chapter 3: Delivering IPv6 Unicast Services

IPv6 connectivity across the backbone can be set up with multiple segments managed independently, using a variety of IPv6 transport mechanisms. For instance, the enterprise could decide to deploy a dual-stack network, and be attached to an MPLS ISP providing native IPv6 access through 6PE, itself connected to a second ISP providing IPv6 over IPv4 tunnels. The IPv6 traffic across the backbone will follow these network segments, so the mechanisms reviewed hereafter become building blocks assembled to enable IPv6 connectivity end to end. Although a particular enterprise or ISP will make its own choices and set up its own strategy for transporting IPv6 traffic, it will also have to deal with 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 routers and the links interconnecting them. In theory, nothing prevents the backbone from being IPv6 only, but it remains likely that an existing IPv4 network will coexist with the IPv6 network. 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 provide IPv6 connectivity.

•

Upgrade a subset of the existing routers to dual stack, establish IPv6 dedicated circuits between them, and set up the IPv6 network as an overlay network on top of the IPv4 network. The circuits can be ATM or Frame Relay, using PVCs or SVCs.

•

Build an IPv6 network as a parallel network to the existing IPv4 network. This scenario includes the case where an IPv6 network is built from scratch, without considerations 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 routing protocols, but the extra configuration and operation costs of running two sets of routing protocols in the backbone are worth mentioning in the dual-stack approach. Although the dual-stack approach carries twice the complexity of single stack, it appears to be the natural choice in the long run. It is the only one that allows separating at the finest level IPv4 and IPv6 topologies and services in the core. It is also the only approach that does not have to worry about traversing NATs (when leaving the enterprise boundaries), and it can support IPv6 multicast properly. However, before investing in a dual-stack deployment throughout the backbone, remember that tunneling mechanisms offer a reasonable intermediary step. Many tunneling mechanisms exist, and they are covered throughout the remainder of this chapter. You should see, however, that dual-stack deployments do not compete with tunneling; instead, they complement each other during the transitioning period.

IPv6 over the Backbone

127

IPv6 over IPv4 Tunnels When the backbone network does not support IPv6, some tunneling mechanism is required. IPv6 over IPv4 tunnels encapsulates IPv6 traffic into IPv4 packets to traverse the IPv4 backbone. Many tunneling mechanisms are available for deploying IPv6: They differ by the location of the tunnel endpoints and the way these endpoints are determined. All of them, however, require the tunnel endpoints to be dual stack. Two tunnel 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, in particular 6 to 4 tunnels. Other tunneling mechanisms, typically deployed on hosts, are discussed in the “IPv6 Network Access” section.

IPv6 over GRE IPv6 over Generic Routing Encapsulation (GRE) tunnels represent another type of MCT; the first example of such was introduced in the “IPv6 Network Access” section. It enables IPv6 traffic forwarding over an existing IPv4 infrastructure, with minimum changes. Tunnel endpoints can be set up between provider edges. The tunnel endpoints are dual-stack routers, which encapsulate IPv6 traffic into IPv4, with both tunnel source and destination configured manually for GRE. Tunnels over GRE, specified in RFC 2473 and RFC 1701, have an extra encapsulation header (GRE header), with the protocol type of the encapsulated protocol (0x86DD for IPv6). This enables protocols other than IP to share the same tunnel (for instance, IS-IS) running over a layer 2 data link. Figure 3-13 shows an example of an IPv6 over GRE tunnel. Figure 3-13 GRE Tunnel IPv4 GRE IPv6 Header Header Packet

IPv4 Backbone e0/0:200.15.15.1

e0/0:200.13.13.1

IPv6 Network

IPv6 Network 2001:300::1/64

Tunnel 100 ipv6 address 201:300::1/64 tunnel source ethernet 0/0 tunnel destination 200.13.13.1 tunnel mode gre ip ipv6 router isis

Dual Stack Router

2001:300::2/64

GRE Tunnel

Tunnel 100 ipv6 address 201:300::2/64 tunnel source ethernet 0/0 tunnel destination 200.15.15.1 tunnel mode gre ip ipv6 router isis

128

Chapter 3: Delivering IPv6 Unicast Services

GRE tunnels are point-to-point tunnels. The number of tunnels needed for the service grows with the number of endpoints, making them difficult to scale. This is a typical problem with manual tunneling mechanisms, and for this reason they are usually used just to interconnect a few sites.

6to4 6to4 is an automatic tunneling mechanism, specified in RFC 3056. It enables isolated IPv6 islands, using the 6to4 addressing plan, to interconnect over an IPv4-only backbone at minimum configuration costs. In particular, the tunnel destination is not explicitly configured as in other tunneling mechanisms, but obtained dynamically from the IPv4 address embedded in the destination IPv6 address of the packet. Figure 3-14 shows a 6to4 configuration. Figure 3-14 6to4 Tunnel HostA

2002:C80F:F01:100::1

IPv6 Site1 2002:C80F:F01::/48

6 to 4 Router1

e0/0:200.15.15.1

IPv4 Backbone

6 to 4 Relay Router

IPv6 Backbone

e0/0:192.88.99.1 e0/0:200.11.11.1

e1/0

6 to 4 Router2

IPv4 IPv6 Header Packet

2001:100::1/64

ServerY

IPv6 Site2 2002:C80B:B01::/48 2002:C80B:B01:100::1

Dual Stack Router

HostB

IPv6 over the Backbone

129

Two deployment scenarios are possible. In the simple case, two or more IPv6 sites need to interconnect over an IPv4 backbone. Each site is configured with a 2002: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 has 2002:C80B:B01::/48. The embedded IPv4 address C80F:F01 (200.15.15.1) is the IPv4 address for Site1. IPv4 prefixes (200.15.15/24, for instance) are distributed by an IPv4 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 a 6to4 tunnel configured, with a tunnel source (200.15.15.1) but no tunnel destination. The tunnel destination is computed on-the-fly by extracting the embedded IPV4ADDR from the destination address (2002:C80B:B01:100::1/64, and used to encapsulate the IPv6 packet into IPv4 (source 200.15.15.1, destination 200.11.11.1). The reverse path is symmetrical. Example 3-21 highlights the relevant configuration for Router1 and Router2. Example 3-21 Configuration of 6to4 Routers in Figure 3-14 Router1 interface Tunnel2002 ipv6 address 2002:C80F:F01::1/128 tunnel source Ethermet0/0 tunnel mode ipv6ip 6to4 ! interface Ethernet0/0 ip address 200.15.15.1 255.255.255.0 ! interface Ethernet1/0 ipv6 address 2002:C80F:F01:100::2/64 ! ipv6 route 2002::/16 Tunnel2002 !route to native IPv6 service ipv6 route ::/0 2002:C058:6301::1 Router 2 interface Tunnel2002 ipv6 address 2002:C80B:B01::1/128 tunnel source Ethernet0/0 tunnel mode ipv6ip 6to4 ! 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 service ipv6 route ::/0 2002:C058:6301::1

The second possible scenario is that of a 6to4 site that needs to access global, native IPv6 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

130

Chapter 3: Delivering IPv6 Unicast Services

instance, using a default route ipv6 route ::/0 2002:C058:6301::1). This route provides the IPv4 tunnel destination (192.88.99.1). A dual-stack router on the boundary between the IPv4 network and the native IPv6 domain, namely a 6to4 relay, removes the IPv4 header and forwards the IPv6 packet natively. In the other direction, the 6to4 relay uses the destination (HostA 2002:C80F:F01:100::1, for instance) to determine the tunnel endpoint and impose the IPv4 header. The configuration of the 6to4 Relay router in Figure 3-14 contains no specific elements for the 6to4 routers, as shown in Example 3-22. Example 3-22 Configuration of 6to4 Relay Router 6to4-relay interface Tunnel2002 no ip address ipv6 address 2002:C80A:A01::1/128 tunnel source Loopback0 tunnel mode ipv6ip 6to4

Therefore, a 6to4 router willing to access a service hosted in an IPv6 native network behind 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 using external Border Gateway Protocol (eBGP), address family IPv6 (see Chapter 4). The BGP configuration of eBGP peering with the 6to4 relay in Figure 3-14 is shown in Example 3-23. Example 3-23 BGP Configuration for Peering with the 6to4 Relay router bgp 100 neighbor 2002:C80A:A01::1 remote-as 200 neighbor 2002:C80A:A01::1 ebgp-multihop 255 ! address-family ipv6 neighbor 2002:C80A:A01::1 activate

Although this model allows for a more granular routing policy, it requires the BGP configuration of the 6to4 relay to be modified for each 6to4 peer. This would not be a scalable deployment approach. BGP peering should be reserved for 6to4 routers providing access to large sites. With the promulgation of RFC 3068, 6to4 routers can use the anycast address 2002:C058:6301:: for their default 6to4 router to get to the nearest (in BGP terms) 6to4 relay 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 nearest 6to4 relay router. The 6to4 transition mechanism has some advantages over manual tunnels. IPv4 tunnel endpoints do not have to be advertised: The IPv6 sites can get the address of the endpoints through a name-to-address lookup performed by a Domain Name Server (DNS). The

IPv6 over the Backbone

131

tunnels are stateless, not consuming resources like manual tunnels do. Finally, after the 6to4 relays have been set up, no extra configuration is required to provide 6to4 sites with connectivity to a wide-area IPv6 routing infrastructure, such as the 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) to select from, they must select their 6to4 address; otherwise, the 6to4 relay cannot dynamically figure out the endpoint of the tunnel. Note

•

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 to implement services such as virtual private networks (VPN), traffic engineering (TE), quality of service (QoS), and fast convergence. ISPs and enterprises that have selected the technology may view the integration of IPv6 services over an MPLS infrastructure as a normal evolution. For those unfamiliar with MPLS terminology, a PE is a provider edge router, and a CE is a customer edge router. A packet enters the MPLS backbone at the ingress PE and is label switched up to the egress PE. This mechanism uses what is known as a label switch path (LSP), set up by control-plane protocols such as Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP). Refer to the book MPLS and VPN Architectures, by Ivan Pepelnjak and Jim Guichard, for detailed information on MPLS. A motivation for deploying IPv6 transport capability over an MPLS backbone relates to the transitioning paradigm. MPLS stands for Multiprotocol Label Switching, and one would expect MPLS to be capable of transporting IPv4 or IPv6 datagrams seamlessly. Therefore, none or few changes would be expected to enhance an existing MPLS backbone, initially providing IPv4 connectivity, to transport IPv6 traffic: an attractive transitioning path for customers who have deployed an MPLS backbone, and want to enhance it to offer IPv6 connectivity at the edge. In reality, this is partly true; although the label switch path is independent from the transported payload, two areas of the control plane are not, as noted here: 1 The setting of the LSP requires an interior gateway protocol (IGP) such as

Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF), which do depend on the protocol version (for instance OSPFv2 for IPv4, OSPFv3 for IPv6). The label distribution protocol falls into the same category: both

132

Chapter 3: Delivering IPv6 Unicast Services

LDP and RSVP depend on the IGP being run among routers in the core, and they both need to be separately enabled and set up for IPv4 and IPv6 (for instance, LDP runs over TCP). 2 An exterior routing protocol (BGP) is needed to exchange IPv6 routes between edge

routers. There must be separate address families enabled for IPv4 (or VPNv4) and IPv6 (or VPNv6), even though they could share the same BGP session. Several approaches are possible to offer IPv6 connectivity over the MPLS backbone. They differ from many standpoints: transitioning strategy, scalability, data overhead, and configuration. Table 3-3 below compares the different solutions. Table 3-3

IPv6 over MPLS Mechanisms

Mechanism

Primary Use

Benefits

Limitations

IPv6 over a circuit transport over MPLS

Service provider with circuit to the CE (ATM, Ethernet, and so on)

Transparent to the service provider

Scalability

IPv6 over IPv4 tunnels over MPLS

Service provider willing to offer IPv6 service on top of an existing IPv4 MPLS service

Impact limited to PE

Tunnel overhead

IPv6 MPLS with IPv4-based core (6PE)

Service provider willing to offer IPv6 service on top of an existing IPv4 MPLS service

Impact limited to PE

Core unaware of IPv6; limitations in load balancing and troubleshooting (ICMP)

IPv6 MPLS with IPv6-based core

Service provider willing to offer MPLS services in an IPv6-only context

Full MPLS-IPv6 functionality

Impact on entire MPLS infrastructure

Configuration

Complexity if coexistence with an IPv4-MPLS service

IPv6 over a Layer 2 Circuit While layer 3 mechanisms have a lot of advantages for connecting IPv6 over MPLS, they require mingling customer and service provider routing. However, some customers may just want connectivity (particularly at commodity pricing for connectivity without additional services). Using a layer 2 circuit to transport IPv6 traffic is an alternative solution to address this simple requirement, with no routing or any additional MPLS service. Although layer 2 tunnels between CEs do not scale well in terms of number of tunnels (N2/2, where N is the number of CEs), they consume few resources at PEs and even less on Provider routers (P routers). When scaling is an issue because of the number of peers involved, you can implement a partial mesh of tunnels using hubs. However, doing so potentially leads to suboptimal routing, with traffic transiting the backbone twice or more. The layer 2 circuit can use Any Transport over MPLS (ATOM) or Ethernet over MPLS

IPv6 over the Backbone

133

(EoMPLS). One advantage of this approach is that it has no configuration impact on any of the backbone boxes (including PE and P). The link between CEs is seen as a layer 2 link, running IPv6 Neighbor Discovery and any IPv6 routing protocol. The IPv6 traffic is tunneled over the MPLS backbone, as shown in Figure 3-15. Figure 3-15 Ethernet over MPLS MPLS Label

IPv6 Network

VC Label

Ctrl Word

CE1

VLAN 10 e0/0.10

IPv6 Packet

IPv6 network

Lo0:200.10.10.1

Lo0:200.11.11.1 VLAN 100

VLAN 10

e0/0.10:50.1.1.1 VLAN 100

Layer2 VLAN PDU 100

e0/0.10:50.1.1.2

PE1

PE2

e0/0.10

CE2

EoMPLS Tunnel

Dual Stack Router

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 CE1 interface Ethernet0/0.10 encapsulation dot1Q 10 ip address 50.1.1.1 255.255.255.0 ipv6 address 2001:100::72A/64 PE1 interface Loopback0 ip address 200.15.15.1 255.255.255.0 ! interface Ethernet0/0.10 encapsulation dot1Q 10 xconnect 200.11.11.1 100 encapsulation mpls PE2 interface Loopback0 ip address 200.15.15.1 255.255.255.0 ! interface Ethernet0/0.10 encapsulation dot1Q 10 xconnect 200.10.10.1 100 encapsulation mpls CE2 interface Ethernet0/0.10 encapsulation dot1Q 10 ip address 50.1.1.2 255.255.255.0 ipv6 address 2001:100::72E/64

134

Chapter 3: Delivering IPv6 Unicast Services

Note that this method may work well for a limited IPv6 deployment over a single ISP network. However, it is unlikely that two ISPs will interconnect using layer 2 links, making the approach unsuitable in environments where several ISPs have to be crossed by the IPv6 traffic. In an environment where the service provider already provides a layer 2 over MPLS service to transport IPv4 traffic, extending the service to IPv6 is low cost and straightforward.

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. After IPv4 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 between these PEs using the same IPv4 endpoints. A routing protocol, such as MP-iBGP can then run over the tunnel to distribute IPv6 routes. From a transitioning or coexistence perspective, this solution has the advantage of requiring only the PEs to be dual stack. It has no impact on core MPLS routers. In the forwarding plane, IPv6 traffic is encapsulated twice—first into an IPv4 packet, and second into an MPLS frame. This double encapsulation, together with the extra configuration of the IPv6 over IPv4 tunnel, is the main drawback of the approach. Figure 3-16 illustrates a simple topology and relevant configuration to set up an IPv6 over IPv4 over MPLS LSP tunnel. Crossing SP boundaries with this approach is no different from doing it for VPNv4. The tunnel endpoints (IPv4 addresses) can be leaked between PEs, either by the IGP, or using MP-eBGP with label, which leads to an extra label in the label stack imposed at the ingress router (as described in RFC 2547bis, section 11, case c). Figure 3-16 IPv6 over IPv4 over MPLS MPLS Label IPv4 IPv6 (LDP) Header Packet

IPv6 Network

IPv6 Network 200.11.11.1

200.10.10.1

CE1

PE1 2001:100::1

PE2 Tunnel100

CE2 2001:100::2

MP-iBGP, Address Family IPv6 Dual Stack Router

The relevant configuration of the PE routers in Figure 3-16 is shown in Example 3-25.

IPv6 over the Backbone

135

Example 3-25 Configuration of PE Routers in Figure 3-16 PE1 interface Loopback0 ip address 200.10.10.1 255.255.255.0 ! interface Tunnel100 ipv6 address 2001:100::1/64 tunnel source Loopback0 tunnel destination 200.11.11.1 tunnel mode ipv6ip ! router bgp 100 bgp log-neighbor-changes neighbor 2001:100::2 remote-as 100 ! address-family ipv6 neighbor 2001:100::2 activate PE2 interface Loopback0 ip address 200.11.11.1 255.255.255.0 ! interface Tunnel100 ipv6 address 2001:100::2/64 tunnel source Loopback0 tunnel destination 200.10.10.1 tunnel mode ipv6ip ! router bgp 100 bgp log-neighbor-changes neighbor 2001:100::1 remote-as 100 ! address-family ipv6 neighbor 2001:100::1 activate

IPv6 over 6PE An IPv6 Provider Edge router (or 6PE) is an alternative solution to IPv6 over an IPv4 tunnel over MPLS. The goal of 6PE is to get the benefits of the IPv6 over IPv4 tunnel (no impact on core routers) while avoiding the tunnel 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 MPLS forwarding mechanisms, based on label swapping and is independent of the payload

The exchange of IPv6 routes between edge routers, which is generally performed by MP-BGP, and requires enabling of an IPv6 address family

The key for leaving the core routers untouched (whether configuration wise, or software version wise) is to enable IPv6 traffic to be tunneled in LSPs set up with IPv4-based

136

Chapter 3: Delivering IPv6 Unicast Services

protocols. The LSP between edge routers can be used to transport any type of packets, including IPv6, providing that there exists some mechanism to associate 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, configured explicitly. In the case of 6PE, the association is controlled directly by MP-BGP, which correlates the next hop advertised 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 LDP Label

P1 IPv6 Network

BGP Label

IPv6 Packet

P2

2001:200::/64

2001:100::/64

CE1

IPv6 Network

200.10.10.1

200.11.11.1

PE1

LSP setup iGP (OSPF, ISIS), LDP

PE2

CE2

MP-eBGP session Address-family IPv6 IPv6 routing MP-iBGP session Address-family IPv6+label

Dual Stack Router

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 PE1 interface Loopback0 ip address 200.11.11.1 255.255.255.255 ! router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 ! address-family ipv6 neighbor 200.10.10.1 activate

An LSP is set up between 200.10.10.1 and 200.11.11.1, as shown in the forwarding entry details at PE1 (see Example 3-27) .

IPv6 over the Backbone

137

Example 3-27 Forwarding Information on Router PE1 from Figure 3-17 PE1#show ip cef 200.10.10.1/32 det 200.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 Example 3-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

The next hop (::FFFF:200.10.10.1) is the IPv4-mapped IPv6 address built from the IPv4 address of the LSP tunnel endpoint. It identifies the LSP to be used to reach the receive prefix (2001:200::/64), as shown in the forwarding table (Example 3-29). Example 3-29 CEF Forwarding Table of Router PE1 in Figure 3-17 PE1#show ipv6 cef 2001:200::/64 details 2001:200::/64, epoch 0 recursive via 200.10.10.1 label 25 nexthop 40.1.1.3 Ethernet1/0 label 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 a v6 prefix (2001:200::/64) over the LSP. In fact, the MPLS forwarding plane is not entirely independent from the payload. Here are the exceptions:

•

At the penultimate hop, when penultimate hop popping (PHP) is enabled, and the label stack on the received 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 of those 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 be IP-aware.

In these three cases, the MPLS forwarder requires some IP knowledge (and therefore some IPv6 knowledge when the payload is IPv6). For the PHP, two options are possible. The first option is to disable PHP. Because the option is most generally configured at the box level, that would affect the IPv4 behavior and

138

Chapter 3: Delivering IPv6 Unicast Services

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 of handling 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 set it up. Example 3-30 BGP Configuration of Router PE1 Exchanging Prefixes and Labels with PE2 PE1 router bgp 100 neighbor 200.10.10.1 neighbor 200.10.10.1 ! address-family ipv6 neighbor 200.10.10.1 neighbor 200.10.10.1

remote-as 100 update-source Loopback0

activate send-label

Note that on Cisco routers, the configuration of the SAFI “label” is required, to enable the IPv6 forwarder to use the MPLS LSP. The MPLS forwarder also needs to be IPv6-aware for load balancing. Cisco routers are somewhat flexible in that regard; either the core router has been upgraded (software upgrade) with a recent version that is capable of 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, upon receiving an undeliverable MPLS datagram. One easy way to get around that problem is to ignore it. The traceroute, executed between PEs or between CEs, is the most cumbersome method, because one would expect all nodes to respond. This can be hidden by using no mpls ip propagate-ttl at the PE (assuming fewer than 255 MPLS hops). If ICMPv6 support is a must for the service provider, P-routers must be upgraded with ICMPv6 support, and RFC 3032 (see section 2.3.2 in RFC 3032, or Chapter 7, “VPN IPv6 Architecture and Services”) is used to provide P-routers with the capability to reach IPv6 nodes without any IPv6-forwarding capability. Crossing multiple IPv4 autonomous systems is similar to IPv4 VPNs, as described in the update of RFC 2547 called RFC 2547bis. Three approaches are feasible:

•

The two autonomous systems are connected over IPv6 links. The Autonomous System Boundary Routers (ASBRs) are both dual-stack 6PE routers that terminate the LSP in their respective autonomous system, and redistribute IPv6 routes to the other ASBRs using eBGP, address family IPv6. 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 be advertised by eBGP (IPv6+label) on it so that an LSP end-to-end (from egress 6PE in one autonomous system to egress 6PE in the second autonomous

IPv6 over the Backbone

139

system) is set up. The eBGP peer addresses 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. With route reflectors, IPv6 routes are neither maintained nor distributed by the ASBR routers, which do no need not be dual stack (can be IPv4 only). The ASBRs are required to leak labeled IPv4 /32 routes to the other autonomous system. This results in the creation of an IPv4 label switched path from the ingress 6PE router to the egress 6PE router, across autonomous system boundaries. This approach is similar to scenario c, section 10, of RFC 2547bis.

For further details, see Chapter 13, “Deploying IPv6 in an MPLS Service Provider Network,” and the Internet Draft 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 the transitioning methods used to carry IPv6 over MPLS to a native IPv6 MPLS LSP setup. As for non-MPLS backbones, 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) is relatively independent from where the prefixes are being transported. You could have two separate LDP sessions: an LDPv4 session for transporting IPv4 prefixes, and an LDPv6 session for transporting IPv6 prefixes; alternatively, you could have a single LDP session (for instance, over TCPv4) that carries both types of prefixes. The prefix Forwarding Equivalence Class (FEC) element contains an Address Family field, per RFC 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 core routers’ reachability within the MPLS backbone. As in the non-MPLS IPv6 dual-stack case, this could be OSPFv3 or IS-IS; the latter choice being preferred when the ISP does not want to run multiple routing processes 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, but MP-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 used to 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 with different routing policies for both. In that case, of course, many core routers are likely to end up with two IGP instances (for instance, OSPFv2 and OSPFv3) and two LDP instances (IPv4 and IPv6). Although this

140

Chapter 3: Delivering IPv6 Unicast Services

scenario offers greater flexibility, it also entails more configuration and management complexity. The dual-stack MPLS 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 on native 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 fourthgeneration mobile phone networks, for instance) where IPv6-only devices need to communicate with IPv4-only nodes or resources. Such scenarios drive the need for translation mechanisms that enable 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 will remain IPv4 only, just because their implementation relies too much on IPv4 addresses, or a recompilation cannot be implemented. In such environments, you can use a different set of mechanisms, based on protocol translation rather 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 2765 and RFC 2766

These mechanisms fall into two categories: those that have an impact on hosts, generally only on one end of the communication; and those that do not. BIS and SOCKS-based gateways belong to the first category, whereas TCP-UDP Relay and NAT-PT belong to the second. Cisco IOS software implements only NAT-PT because the other translation mechanisms are either not relevant to Cisco IOS software or they are not really deployed. For these reasons, this section focuses only on NAT-PT. NAT-PT enables IPv6-only hosts to communicate with IPv4-only hosts and applications. It is described in RFC 2766 and uses the IP translation mechanism referred as stateless IP/ICMP translation algorithm (SIIT), specified in RFC 2765. Tables 3-4 and 3-5 present header translation rules, from IPv4 to IPv6 and in reverse. Table 3-4

Header Translation IPv4 to IPv6 IPv6 Header Fields

Values

Version

6

Traffic Class

TOS

Translation Mechanisms (NAT-PT)

Table 3-4

Table 3-5

141

Header Translation IPv4 to IPv6 (Continued) IPv6 Header Fields

Values

Flow Label

0

Payload Length

Total length—header length

Next Header

Protocol

Hop Limit

TTL

Source Address

NAT-PT

Destination Address

NAT-PT

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

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 translated using the IPv6 fragment header. Most ICMPv4 control messages are discarded during translation, except echo requests and replies which are mapped into IPv6 with the proper code (128, 129). Error messages are translated whenever possible. The reverse translation is done pretty much the same way. The IPv4 checksum computation is performed after the header has been translated. The way addresses (source and destination) get translated is configuration controlled, or dynamic. In the simple case, explicit mapping is provided at the NAT-PT for both source and destination, in both directions.

142

Chapter 3: Delivering IPv6 Unicast Services

Like for NAT, NAT-PT operates in various modes: static, where one IPv4 address is used to communicate with the IPv4-only host; and dynamic, where a pool of addresses is available, and dynamically bound to active flows; and PAT (Port Address Translation), where a single IPv4 address is used, and a TCP/UDP port number serves as a discriminator. NAT-PT can also be used as the DNS application-level gateway (ALG) to translate the DNS transaction. The DNS query for an AAAA record gets translated into a query for an A record. Upon receiving a response with an IPv4 address, the NAT-PT builds an IPv6 address by prefixing it with the global NAT-PT prefix and sends the 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 the IPv4 address. Figure 3-18 illustrates the case of dynamic NAT-PT using a pool of addresses. Figure 3-18 NAT-PT Source: Destination 3FFE:100:200:1::1 3FFE:B00:1::1

IPv6-Only Host

Source: 10.50.10.1

Destination 192.168.1.1

IPv4-Only Server

NAT-PT Router IPv6 Network 3ffe:100:200:1::/64

IPv4 Network

3ffe:100:200:1::1

192.168.1.1 NAT-PT: address pool: 10.50.10.1 10.50.10.10 NAT-PT Prefix 3ffe:b00:1::/96

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->v6ipv6 nat v4v6 source 192.168.1.1 3ffe:b00:1::1 !Entry for mapping of v6 source->dynamic v4 ipv6 nat v6v4 source list pt1 pool v4pool ipv6 nat v6v4 pool v4pool 10.50.10.1 10.50.10.10 prefix-length 24 ipv6 nat translation udp-timeout 600 ipv6 nat prefix 3ffe:b00:1::/96 ! ipv6 access-list pt1 permit ipv6 3ffe:100:200:1::/64 any

Translation Mechanisms (NAT-PT)

143

NAT-PT involves many of the same issues as NAT, covered in depth in Chapter 1, “The Case for IPv6—An Updated Perspective.” These issues are also listed in draft-aounv6ops-natpt-deprecate (a work in progress in IETF). Whenever you have an alternative solution, you should favor it over NAT-PT. For instance, if there is any 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 an IPv6-only network is trying to communicate to another IPv6-only network via an IPv4 backbone or vice versa, because it would require a double translation. In such cases, tunneling mechanisms (described in the section “IPv6 over the Backbone”) should be preferred. However, a gap exists between a technical alternative and its operational feasibility. This gap may be filled by NAT-PT during the transitioning period. Consider, for example, the case of IPv6-only devices that should communicate with a node connected to an IPv6 unsupported data link layer (for example, Token Ring). For economical reasons, it may be valuable to run NAT-PT between devices, while waiting for the host to be upgraded to its next generation (thus ridding it of Token Ring). You can integrate IPv6 into existing infrastructures in various ways. It is expected that dualstack networks will become the standard approach, but various transition mechanisms are available today to lower the cost of the first steps toward IPv4 and IPv6 coexistence. This chapter has summarized those mechanisms to enable you to evaluate their use in different deployment scenarios as depicted in the second part of this book.

CHAPTER

4

IPv6 Routing Protocols Numerous IPv4 routing protocols (RPs) are available for finding routes between networks, and almost every one of them has an IPv6 correspondent or extension: Routing Information Protocol next-generation (RIPng), Open Shortest Path First version 3 (OSPFv3), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), and Border Gateway Protocol (BGP). So far, IPv6 has brought few innovations to the IP routing paradigm. There are still interior gateway protocols (IGPs) and exterior gateway protocols (EGPs), distance vector–based and link-state-based routing protocol algorithms, and so on. The concept of the autonomous system, defined as a set of networks controlled by a common administrative entity, remains unchanged with the introduction of IPv6 RPs. The same autonomous system (and autonomous system number [ASN]) will route both IPv4 and IPv6. IPv6 IGPs, used to exchange routes within the autonomous system, are namely RIPng, OSPFv3, IS-IS for IPv6, and EIGRP for IPv6. Only BGP4 is available to exchange IPv6 routes between autonomous systems. Multiprotocol extensions provide support in BGP4 for IPv6 routing. The requirements for IGPs and EGPs are quite different, in terms of routing table size, number of supported routers, convergence time, security, routing policy, and so forth. For that reason, they use different algorithms and mechanisms, which also affect the type of information they exchange and store. IGPs use distance vector and link state, whereas BGP uses the path vector RP algorithm. Table 4-1 presents the RP taxonomy, and highlights their IPv6 correspondent. For more details on how to choose the RP, refer to Top-Down Network Design, Second Edition, by Priscilla Oppenheimer. The rest of this section briefly reviews existing unicast RP technologies. The next section reviews each of the available IPv6 RPs and provides configuration examples. Then the last two sections cover the topic of multihoming and deployment aspects, respectively.

146

Chapter 4: IPv6 Routing Protocols

Table 4-1

Taxonomy of Routing Protocols

Deployment Domain

Algorithm

RP

Scalability

Convergence Time

Metric

IPv6 Version

Interior gateway protocol (IGP)

Distance vector

RIP

15 hops

Slow

Hop count

RIPng

EIGRP

1000s routers

Quick (via DUAL algorithm)

Bandwidth, delay, reliability, load

EIGRP for IPv6

OSPF

1000s routers (100s/area)

Quick (via LSAs and HELLO)

Cost (function of bandwidth on Cisco routers)

OSPFv3

IS-IS

1000s routers (100s/area)

Quick (via LSPs)

Configured host, delay, expense

IS-IS for IPv6

Link state

Exterior gateway protocol (EGP)

Distance vector

EGP

—

—

Integer SA (B) => B is querier.

4

Multicast

Non-Querier

Querier

Listener wants to join group G.

The querrier for the link was elected.

5

Non-Querier

Multicast

Querier

Periodic General MLD Query

6

Multicast

Non-Querier

Querier

G Specific MLD Query MLD Report G

MLD Listener Report –Response to Query

Listener wants to leave group G.

No response to query, multicast traffic is not forwarded on link anymore.

Example 6-1 MLD Operational Status on a Router Interface Router#show ipv6 mld interface GE-WAN1/1.1 GE-WAN1/1.1 is up, line protocol is up Internet address is ::/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 MLD activity: 4 joins, 0 leaves MLD 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 the example above can be configured under each interface. The output

IPv6 Multicast

213

also lists the querier for the link; in this case, 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 it intends to join and the specific source it intends to listen to. Only MLDv2 supports this functionality on the hosts. Although SSM is a popular deployment model, MLDv2 is not commonly implemented on IPv6 stacks at the time of this writing, so a solution is necessary to make SSM work with MLDv1. This solution is called SSM 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. This mapping feature is off by default on a router. It is enabled with the global command ipv6 mld ssm-map enable. The static mapping is configured with the global command ipv6 mld ssm-map static source , where the access control list (ACL) identifies the groups mapped to a given source.

•

Dynamically configured mapping—An AAAA record (see Chapter 3, “Delivering IPv6 Unicast Services”) 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 S for G. After the SSM mapping has been enabled globally, as previously shown, you can configure the dynamic mapping option with the global command ipv6 mld ssm-map query dns. In this case, the IP address of the DNS server must be configured on the router, too (ip name-server ). The DNS 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-based multicast services.

NOTE

IPv4 faces the same problem of little support for the newer IGMPv3 protocol. While the host stacks are getting updated to include IGMPv3, the same mapping solution is available to enable IGMPv1/v2-capable hosts to participate in SSM-based multicast service deployments. The feature is called SSM mapping for IGMPv1/v2.

MLD Access Control and Explicit Tracking Two useful MLD features enable network administrators to block unauthorized user access to multicast resources and to monitor individual MLD client activity on an interface:

•

MLD access control—Configured on a router interface, MLD access control filters inbound MLD reports for groups and sources based on a defined access list. The ACL SA matches the address of the multicast source and the ACL DA matches the group address. Example 6-2 shows the configuration of this feature.

214

Chapter 6: Providing IPv6 Multicast Services

Example 6-2 Denying User Access to (2001::1,FF3A::1) and Permitting All the Other Sources for (*,FF3A ::1) Router(config)# ipv6 access-list mld-acc-control Router(config-ipv6-acl)# deny ipv6 host 2001::1 host ff3a::1 Router(config-ipv6-acl)# permit ipv6 any host ff3a::1 Router(config-ipv6-acl)# interface GE-WAN1/1.1 Router(config-if)# ipv6 mld access-group mld-acc-control

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 explicittracking ), ET enables the router to explicitly track each multicast client on that interface. By default, the router is interested in knowing only whether it has any listeners for a group on the interface, so it does not monitor individual listeners. The tracking can be done for all multicast groups or for a subset identified 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 for MLDv2. In other words, it does not have to query the link for other listeners after each report of a listener leaving a group. The router knows at all times how many listeners are subscribed to each group, 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 complements the other two features by offering network operators the means to dynamically control user access and to perform 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. Several protocols that would make switches aware of multicast group membership were developed for IPv4, including the Cisco Group Management Protocol (CGMP). CGMP enables routers to provide connected switches with listener information, and IGMP snooping enables the switches to learn a port’s group membership by monitoring its IGMP traffic. These mechanisms allow layer 2 switches to forward the multicast traffic only to those 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 have not 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.

IPv6 Multicast

215

Although you can implement CGMP and snooping for IPv6 (as you can with IPv4), you must consider some IPv6 specificities. Multicast is extensively used in IPv6 to perform basic functionality such as neighbor discovery. Each node has to subscribe to multiple groups that are dedicated to proper link operation. A node’s basic operation can be severely impacted if it is not generating enough MLD traffic that would allow a snooping 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 the feature with the command ipv6 mld snooping (if disabled); the feature has tuning parameters such as rate limiting and number of layer 2 entries that can be installed by MLD snooping. There are no plans to implement 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 a multicast-aware network is to enable the routers to inform each other of their listeners’ interest in a multicast group. These routers can then collectively build the optimal path for the multicast traffic from the sources to the listeners.

Multicast Distribution Trees A fundamental concept of multicast routing and forwarding is that of a multicast distribution tree (MDT). Its branches lead to routers that service networks hosting listeners. As listeners join or leave, branches are added to or pruned from the tree. Why a tree? Because with all the replication of traffic, the last thing one wants to have 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 be located? Generally speaking, the optimal path for the multicast traffic is that of a tree that has the root at the source of the traffic. This is called a shortest path tree (SPT), and it is identified by the (S,G) tuple, where S is the 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 the network. 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. A shared tree is identified as (*,G). The shared tree (ST) is rooted in an administratively selected router called rendezvous point (RP). One RP is active for each group, but the same RP can handle multiple groups. Sources register with the RP and their traffic is forwarded over an (S,G) to the RP and from there down the shared tree. 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 path for all multicast sources. If an edge router has listeners for a given group,

216

Chapter 6: Providing IPv6 Multicast Services

once it learns about a source, it can choose to switch to an SPT that offers optimal forwarding of the multicast traffic. Figure 6-2 shows a shared tree and an SPT over the same topology. Figure 6-2

Multicast Distribution Tree Types Shared Tree (ST)

Shortest Path Tree (SPT)

RP (*, G)(S, G)’

(*, G)

(S, G)

(*, G)(S, G)’

(S, G)

Listener

(*, G)

(*, G)

Listener

(S, G)

(S, G)

(S, G)’

S Listener

Source

S Listener

Source

Multicast Traffic PIM Source Registration (S,G)’ Represents the SPT between the Source and the RP.

NOTE

The two tree types have advantages and disadvantages. With SPT, routers require more memory to maintain the state of multiple trees. On the other hand, the SPT will always offer the optimal path between the source and destination, whereas that might not always be the case when using an ST. Nonoptimal paths can lead to packet 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 respect to the flow of multicast traffic) toward them. The process of identifying this upstream neighbor is called reverse-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

IPv6 Multicast

217

on the underlying unicast routing protocols for network topology information. Based on this information, it executes an RPF calculation and it identifies the best upstream interface toward the RP or the source. The following information is examined in the RPF calculation process:

• • •

NOTE

Static multicast routes MBGP (Multiprotocol BGP) multicast routes IPv6 unicast routing information stored in the Routing Information Base (RIB) and provided by static routes, RIPng, EIGRP, OSPFv3, and IS-IS but excluding BGP unicast routes

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 for the multicast RPF calculation only. First, the longest-match is searched across the three databases. If two or more equivalent routes are found across the tables, the tiebreaker used is the administrative distance. If the tie remains, the route found in the first 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 a shorter prefix length can be preferred because its administrative distance happens to be lower than a route with a longer prefix length.

NOTE

The RPF calculation takes into account the existence of multiple equal paths to multicast sources. A hash is done between the last 32 bits of the source and the last 32 bits of the available next hops to select from among the interfaces that can be used to receive the multicast traffic. The interface returned by the RPF calculation will be used for all multicast traffic from a given source. This leads to the load balancing of the multicast traffic on a per-source basis. Changes to IPv6 BGP/MBGP led to a different approach to using BGP routes for RPF calculation. Based on RFC 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 are ignored. However, you can enable routers to use the BGP unicast routes for RPF with the command ipv6 rpf use-bgp.

•

Multicast-only routes are marked with SAFI=2. These routes cannot be used for unicast. The same SAFI=2 is available with IPv4.

218

NOTE

Chapter 6: Providing IPv6 Multicast Services

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 multicast routing. The routing information available via static routes and RIB is used for multicast routing purposes and is 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 routing information between PIM domains. You can enable the BGP process on a Cisco router to exchange IPv6 multicast routing information by simply configuring a new address family with the command address-family ipv6 multicast, as shown in Example 6-3. Example 6-3 Enabling BGP to Exchange IPv6 Multicast Routes router bgp 200 bgp router-id 200.200.200.200 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 2001:D:1::2 remote-as 201 neighbor 2001:D:1::2 update-source GigabitEthernet0/1 ! address-family ipv6 multicast neighbor 2001:D:1::2 activate network 2001:D:AAAA:1::/64 exit-address-family

The highlights in the preceding example indicate that the IPv6 multicast address family enables BGP process 200 to exchange IPv6 multicast information with neighbor 2001:D:1::2. In this example, prefix 2001:D:AAAA:1::/64 is advertised for multicast routing only. You can view information regarding the multicast routes exchanged via MBGP through the various options available with the show bgp ipv6 multicast command. The command’s output on the peer (201.201.201.201 with address 2001:D:1::2) of the router configured in Example 6-3 shows the advertised prefix. Example 6-4 IPv6 Multicast Route Advertised via BGP MBGP-Peer-Router#show bgp ipv6 multicast BGP table version is 182, local router ID is 201.201.201.201 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin 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

IPv6 Multicast

219

In the cases where the BGP neighbor does not support the multicast SAFI, additional configuration on the SAFI-aware router facilitates the exchange of multicast routes through the unicast address family, as shown in Example 6-5. Example 6-5 Enabling BGP Process to Exchange IPv6 Routes with a Neighbor That Does Not Support the

Multicast SAFI address-family ipv6 neighbor 2001:D:1::2 translate-update ipv6 multicast unicast neighbor 2001:D:1::2 activate no synchronization exit-address-family address-family ipv6 multicast neighbor 2001:D:1::2 activate

It is also worth observing that whereas the RPF calculation returns a next hop for the reverse path based on the IPv6 unicast topology, with IPv6 this result does not always match the address of the upstream PIM neighbor because the router might have multiple addresses on the interconnecting link. In this case, the unicast topology is not congruent with the PIM topology in terms of next-hop addresses. The PIM Hello message used in building PIM neighbors was enhanced to avoid this type of situation. The Routable Address option of the PIM Hello message enables the router to list all its addresses on the interface over which the Hello is sent. The address of a next-hop router generated by an RPF calculation is always compared with the addresses it listed in 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. If the 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 and maintained in the Tree Information Base (TIB). Many protocols were developed to support this process. They all leverage one or both of the tree types mentioned. Distance Vector Multicast Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), Core Based Trees (CBT), Protocol Independent Multicast (PIM), and Pragmatic General Multicast (PGM) all dealt with certain models of service delivery, and catered to certain application needs. In time, implementation issues and deployment experiences trimmed down the number of preferred IPv4 multicast routing protocols to PIM variants.

220

Chapter 6: Providing IPv6 Multicast Services

Learning from its predecessor, IPv6 adopted only three multicast routing protocols:

NOTE

•

PIM-SM for many-to-many applications, where multiple sources transmit to the same group. The typical 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 source transmits to multiple listeners. The typical applications are content delivery such as video or audio programs.

•

PIM-Bidir is used for many-to-many applications, where all members of the group can be both receivers 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.

PIM-SM, PIM-SSM, and PIM-Bidir operate based on a “pull” model, where each router requests, or pulls, the multicast information from the source or RP whenever it has listeners or downstream clients. The MDT is built based on demand. By contrast, the “push” model is sending, or pushing, the multicast information to all routers, so at first all routers are part of the MDT. The nodes that are not interested in that multicast are later trimmed from the tree. PIM-Dense Mode supports the “push” multicast model. IPv6 multicast does not support PIM-DM.

IPv6 PIM implementation is similar to IPv4. As a matter of fact, the PIM protocol standards are transparent with respect to the version of IP. For these reasons, you can reference multicast technology-specific references such as Developing IP Multicast Networks, Volume 1, by Beau Williamson, to gain an in-depth understanding 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 same multi-access link, they elect a DR to handle the PIM control traffic coming from and going to that link. The DR is the router that registers any source on the link. The DR is also the router that joins a tree when a listener becomes active on the link. The PIM router with the highest IPv6 address or the highest priority (configurable via the ipv6 pim dr-priority interface command) is elected the DR for a multi-access network.

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 perform these two functions.

This concept, along with that of RPF, identifies the source and the destination of PIM join messages sent by routers in the process of building the MDT.

IPv6 Multicast

221

PIM-SM It is important to understand PIM-SM because the other two variants, PIM-SSM and PIMBidir, can be viewed 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. Multicast sources for a given group need to register with the RP defined for that group. Based on the PIM draft’s recommendation, a virtual tunnel interface is used by routers to register sources connected to them. The tunnel is unidirectional, and it is used to send register messages to the RP. A tunnel interface is created for each RP defined 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 tunnel Tunnel1* Type : PIM Encap RP : 2001:D:AAAA:1::1 Source: 2001:1:FFFF:FFFF:2::

The tunnel interface can be created only for the registration process, and then it can be removed. Cisco IOS software, however, keeps the tunnel interface active for as long as the RP is known. The tunnel interface comes up when the RPF calculation for the RP returns an output interface and there is a unicast route installed for 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 Tunnel1 Tunnel1 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 Tunnel source 2001:1:FFFF:FFFF:2:: (Loopback0), destination 2001:D:AAAA:1::1 Tunnel protocol/transport PIM/IPv6, key disabled, sequencing disabled Tunnel TTL 255 Checksumming of packets disabled Tunnel is transmit only

NOTE

Example 6-7 refers to the tunnel interfaces created on non-RP routers. On the RP side, a single tunnel is used for all registering tunnels set up to it.

222

Chapter 6: Providing IPv6 Multicast Services

When a DR receives multicast traffic from a connected source, it analyzes the group address to find its RP. It then encapsulates the multicast traffic and sends it through the appropriate tunnel interface to the appropriate RP. After the source has been registered, the RP sends register-stop messages outside of the tunnel over an SPT built between the source and the RP. From there on, the multicast traffic originated by that source will flow unencapsulated over the shortest path to the RP and then down the shared tree. The leaf routers of the ST use this traffic to learn about the registered sources. Figure 6-3 summarizes the source registration process. Conceptual Representation of Source Registration with PIM-SM RP

1

RP

2

Multicast Traffic Multicast Protocol

(*, G)

C (*, G)

B

(*, G)

C

(*, G) (*, G)

Tunnel 1

Tunnel 1

C

RP

3

Tunnel 1

Figure 6-3

(*, G)

B

(*, G)

B

RP-to-Group Map Group RP (*, G)

G

(*, G)

A

Source

S

Traffic for G

Source sends traffic to group G. RP

4

C

Tunnel

Source

A Source

S

Router looks up RP for G, the tunnel to it = RPF calc. RP

5

(*, G)

(*, G)(S, G)

PIM Join (S, G)

C

B

Traffic for G

Traffic to group G is sent encapsulated to RP and then down the (*, G) ST. RP

6

(*, G)(S, G)

C (*, G)

Tunnel 1

(*, G)

S

Register Stop

C (*, G)

(*, G)

Tunnel 1

(*, G)

Tunnel 1

A

(*, G)(S, G)

B

Tunnel 1

DR

(*, G)(S, G)

B

Register Stop

PIM Join (S, G)

(*, G)(S, G)

A Source

S

A

(*, G)

Traffic for G

The RP builds the (S, G) SPT.

Source

S

A

(*, G)(S, G)

Traffic for G

The RP advises router A to stop sending traffic over the tunnel.

Source

S

Traffic for G

Traffic flows over (S, G) to the RP and then over the (*, G).

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 the upstream 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).

IPv6 Multicast

223

It was mentioned earlier that routers learn about sources for a group G through traffic that comes down the ST. When a DR learns about a certain source, the DR sends an (S,G) PIM join message directly toward the source. The routers along the reverse path analyze the metric to the source versus the one to the RP and forward the joins up the shortest path, thus building an (S,G) SPT. The DR can choose to switch over to receiving traffic over the SPT rather than the ST for better delay characteristics.

Cisco routers, by default, immediately switch over from the ST to the SPT for traffic forwarding. To stop the switchover and have routers use only the ST for forwarding multicast traffic, you must configure them globally with the ipv6 pim spt-threshold infinity command.

NOTE

Figure 6-4 summarizes this process. Figure 6-4

Conceptual Representation of Listener Join with PIM-SM

RP

1

RP

2 (*, G)(S, G)

C

C

(*, G) (S, G)

S

A

B

Source

(*, G) PIM Join

Rp-to-Group Map Group RP G

DR

RPF B/Gig0

C

(*, G)(S, G)

C

(*, G) (S, G)

(*, G) PIM Join

Traffic for G

A

B Gig0

RP

3 (*, G)(S, G)

S

(*, G) (S, G)

(*, G)

A

B

Source

S Source

(*, G)

DR

DR

MLD Report for (*, G)

Listener

Listener

Listener

Source S is registered with the RP. The listener expresses interest in group G.

(*, G) PIM-Joins sent toward RP based on RPF calculation results.

DR is part of (*, G), receives traffic over the ST and learns about source S.

RP

4

RP

5 (*, G)(S, G)

C

C

(*, G) (S, G)

S

A Gig0

DR

MRIB Prefix Next Hop S

B

(*, G)(S, G)

C

(*, G) (S, G)

Traffic for G

(*, G)

B

RP

6 (*, G)(S, G)

(*, G)

A

B

Source

S

(*, G) (S, G)

(*, G) (S, G)

A

B

Source

S Source

(S, G) PIM Join Int Gig0

(*, G)

DR

(*, G)(S, G)

DR

Listener

Listener

Listener

RPF calculation for S in order to send PIM-Joins for the (S, G) SPT.

(S, G) PIM-Joins sent toward S to build SPT.

Traffic flows over the (S, G) SPT.

224

NOTE

Chapter 6: Providing IPv6 Multicast Services

In a router, an MDT’s representation consists of an upstream neighbor identified through the RPF calculation and an outgoing interface list (OIL). The OIL in IPv6 has two types of entries (unlike IPv4, in which a single list is used): • Immediate OIL—Generated by PIM joins/leaves and by MLD report messages. They reflect the tree topology 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 the immediate OIL in the MRIB with the show ipv6 mrib route command. PIM-SM builds shared trees and requires the use of at least one rendezvous point (RP) for every multicast group. Different RPs can handle different multicast groups, and for this reason PIM has to be complemented by a mechanism that allows routers to learn which RP to use for a given group. Such mapping mechanisms are needed both within a PIM domain and between various domains. A discussion of the mapping methods available with IPv6 multicast follows in the “RP Mapping and Redundancy” section of this chapter. PIM also builds 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 global configuration command ipv6 multicast-routing). You can disable PIM per interface by using the command no ipv6 pim. For PIM-SM, you can configure an RP globally with the ipv6 pim rp-address command. The PIM-relevant information can be viewed with the help of the various options available with the command show 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 the source (S,G) it wants to join. PIM-SSM operates similarly to PIM-SM, but it does not build a shared tree and so it does not need an RP. The listener must be able to

IPv6 Multicast

225

indicate to its DR what (S,G) it is interested in. For this reason, 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 for PIM-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 layer protocols, 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 information is 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 the other end of the spectrum in terms of MDT types used. PIM-Bidir, like PIM-SM, uses shared trees, but it never builds SPTs. There is no source registration process, so the traffic is unconditionally forwarded on the ST. This allows it to scale to an arbitrary number of sources with minimal additional overhead. The ST is bidirectional in the case of PIM-Bidir. Under these circumstances, RPF is not operating as in the case of PIM-SM, and the RP becomes the reference point in maintaining a loop-free network. In the case of PIMBidir, the RP is configured with ipv6 pim rp-address bidir. Ultimately, the multicast routing protocol selection is done based on the application types and service models that are being deployed. Cisco routers can support all three IPv6 PIM protocols simultaneously for different multicast groups. Based on the routing, tree topology, and group membership information available, forwarding decisions are made 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 IPv6 multicast service. Some mechanisms help manage the multicast domain, and some mechanisms help routers correlate multicast groups to RPs that serve them. These mechanisms, together with the multicast protocols already discussed, fit into complete service architectures that provide the network-wide perspective on deploying 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 PIM messages are contained within the PIM domain, leading to smaller-size MDTs. This smaller size translates into fewer states to maintain and a lighter RP utilization.

226

NOTE

Chapter 6: Providing IPv6 Multicast Services

It is worthwhile to note that although PIM uses unicast routing information for RPF calculation, a PIM domain 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 and ACLs, can be used in the case of IPv6, too. On the other hand, IPv6’s address scoping provides a powerful tool to implement domain control in a cleaner way. You can define boundaries on router interfaces for various address 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 each multicast group. IPv6 did not inherit all mechanisms developed for distributing RP-to-group mapping information in IPv4 multicast. For example, there is no standardization work done for Auto-RP in IPv6 at the time of this writing. On the other hand, the larger IPv6 addresses support a new, IPv6-specific mechanism that is 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 this information on each one of them. Example 6-9 shows the configuration of this static mapping on a Cisco router. Example 6-9 Configuring 2001:1::1 as a Static RP for (*,FF0A ::1) Router(config)# ipv6 access-list RP-group Router(config-ipv6-acl)# permit ipv6 any host ff0a::1 Router(config)# ipv6 pim rp-address 2001:1::1 RP-group

Despite its simplicity, this method has the potential of being a provisioning and network management nightmare. 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 PIM domain. 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 a BSM 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 the RP-to-group mapping information.

IPv6 Multicast

NOTE

227

The BSR election tiebreaker between two candidates with equal priorities is their advertised address. The highest address wins.

A Cisco router is globally configured to be a candidate BSR with the following command: ipv6 pim bsr candidate bsr priority

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 they periodically send messages to the BSR to indicate their willingness to be the RP for a list of groups included in the messages. The RP candidates are globally configured: ipv6 pim bsr candidate rp [access-list identifying the groups] . 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 are received 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 the groups they are willing to serve with the help of BSMs. The messages are flooded throughout the domain, and PIM routers store the advertised mapping information. You can use the show ipv6 pim group-map command to view the RP-to-group mapping. If a candidate RP is no longer available, the BSR adjusts the RP-to-group mapping information in the BSMs. This adjustment provides the PIM domain with a certain level of RP redundancy. Domain control has to be implemented for the BSMs, too. These flooded packets should not be allowed to leave the designated BSR domain. The interfaces at the edge of the domain are enabled (interface command ipv6 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 are plenty left in an IPv6 multicast address to include the address of the RP to be used for a multicast group. This simple mechanism of providing the RP-to-group mapping information is called embedded RP. It relies on the unicast-prefix multicast group addresses

228

Chapter 6: Providing IPv6 Multicast Services

described in RFC 3306, with an additional flag that indicates the presence 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 4

RP Address

Network Prefix

AddressID Interface

0

8 bits

4

FF

7

4

4

4

64 bits

32 bits

RP Network Prefix

Group ID

8 bits

0

R=1 P=1 T=1

Flags

Scope

Network Prefix Length

R = 1 Embedded RP P = 1 Unicast Based Prefix T = 1 Not Permanently Assigned

4

Network Prefix

RP Address

Example 6-10 applies the procedure described in Figure 6-5 to build a multicast group address that embeds the RP address 2001:D:AAAA:1::2. Example 6-10 Generating an Embedded RP Multicast Address RP Address: 2001:D:AAAA:1::2 RP Address Network Length: 64 (decimal) -> 40 (hex) RP Interface ID: 2 Scope for the Embedded RP multicast address: 8 Group ID: 100 Embedded 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. Highlights are used to identify the contribution of each element in the resulting embedded RP address. With this mechanism, each registered unicast address automatically comes with 256 RP addresses for the 16 address scopes 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 data traffic by looking at the destination multicast addresses that have the R flag set to 1. The router whose address is 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-group mapping within a PIM domain. It can also be used for mapping RPs to

IPv6 Multicast

229

group addresses across different PIM domains. However, you must consider a few drawbacks:

• •

Embedded RP does not support PIM-Bidir.

•

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.

Only one RP address can be used for each group. This means that any RP redundancy mechanism used with embedded RP must have an anycast flavor.

The embedded RP functionality runs by default on multicast-enabled Cisco routers. You can disable it explicitly 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 to provide RP redundancy. A certain level of redundancy was already mentioned in the context of BSR. If a candidate router stops advertising its willingness to be an RP (either because of reconfiguration or device/network failure), the BSR removes it from the RP set, and the routers in the domain update their RP-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 two routers with the same RP address but different prefix lengths, such as RP1=2001:D:AAAA:1::2/128 and RP2=2001:D:AAAA:1::2/127. Because of the longest prefix match, RP1 will always be reached first by both sources 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 registration information. In IPv4, the Multicast Source Discovery Protocol (MSDP) performed this function. MSDP in IPv4 was considered a temporary solution. Despite not evolving or even becoming a standard, MSDP is still used in IPv4 multicast deployments. IPv6 did not pursue MSDP-IPv6, and because of that the MSDP/anycast-RP redundancy solution, currently widely used in IPv4 multicast deployments, is not available in IPv6. MSDP inadvertently provided another fringe benefit: RP load balancing. Mechanisms will have to be developed 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 that must be supported by the network. The two popular multicast service

230

Chapter 6: Providing IPv6 Multicast Services

models are Any Source Multicast (ASM) and Source Specific Multicast (SSM). Each model leverages a subset of the protocols and mechanisms discussed in this chapter, and each has its strengths and weaknesses. This section briefly reviews ASM and 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 sources provides video or audio multicast streams to interested users, as shown in Figure 6-6. The important thing to notice is the localized nature of the sources. A customer’s set-top box or PC can map video/audio channel IDs to (S,G)s, and it can handle the process of joining a requested (S,G) when the corresponding channel is selected. Figure 6-6

Deployment Models, SSM and ASM Listeners RP

Source Listeners

ST

PIM Domain

SSM

Sources

Source Source

Listeners Listeners SPT Listeners

Listeners

ASM

Listeners

Listeners

IPv6 Multicast

231

The following is needed to deploy SSM:

•

MLDv2 or MLDv1 combined with SSM mapping-capable routers (see the earlier section “Source Specific 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 to manage them.

SSM has no domain constraints. However, if the number of (S,G)s is very large, the memory and processing resources 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 nature or 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 case would reduce the amount of MDT state that has to be maintained by the routers in the network. The service model applied in this case is ASM. The use of an ST and the mandatory RPs adds complexity to the ASM model. 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 for scalability limitations. If an application can be supported by both SSM and ASM, the first option in designing the multicast service deployment should be SSM. Both SSM and ASM models are fully supported on the Cisco 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 a network 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 concepts discussed so far for ASM and SSM apply within a PIM domain. The questions are these: What happens when multiple PIM domains are defined in a network? How will they interact, and how should interdomain multicast be deployed?

232

Chapter 6: Providing IPv6 Multicast Services

If you deploy ASM across multiple domains, the following information has to be exchanged between domains:

• •

Multicast routes—MP-BGP takes care of this function in both IPv4 and IPv6.

•

Source registration information—In IPv4, MSDP takes care of this function. Because in IPv6 there is no MSDP-like mechanism in place, only one of the domains can have RPs.

RP-to-group mapping—In IPv4 and IPv6, it can be done with the help of BSR. With IPv6, you have an additional option: using embedded RP.

Because of the lack of MSDP-IPv6 or similar functionality, in IPv6 the only option available is to use a single PIM 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 from IPv4 to IPv6. When choosing tunneling mechanisms for IPv6 deployments, you should consider the long-term service 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

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 tunneling mechanism.

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 tunneling mechanism.

It is also important to consider the implications of deploying multicast over certain tunnels. For example, the 6over4 tunnels require an IPv4 multicast infrastructure to support IPv6 multicast. IPv6 islands can also be interconnected with other types of tunnels, such as pseudowire layer 2 tunnels. The tunnels are layer 3 transparent, and they support multicast. The static nature of such tunnels makes for a deployment that scales poorly.

IPv6 Multicast

233

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 virtual private networks (VPNs), a popular service deployed over MPLS infrastructures. This service enables enterprises to securely interconnect remote locations in a more cost-effective way than leasing lines. (For more 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 review of the challenges faced by multicast in an MPLS environment. A possible deployment approach is for the multicast to be forwarded untagged, completely ignoring the underlying MPLS infrastructure. This solution is complicated by the fact that a VPN’s multicast traffic has to be isolated from that of other VPNs. The Cisco solution 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 PIM instance runs for each VRF and it performs the multicast routing function between the CEs and PEs that belong 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 (GRE encapsulated) between PE routers. These multicast groups are manually mapped to MVRFs, and they are managed by a common, global PIM instance. The important thing to remember is that the actual forwarding across the service provider network, within the global MD, is done at layer 3 and that the presence or absence of MPLS is irrelevant. Unlike IPv4, currently there is no MVPN-like solution available for IPv6, which proves particularly relevant when considering 6PE, the migration approach discussed in Chapter 3. 6PE is a practical way to provide IPv6 unicast service over an MPLS network with minimal impact at the edge and no impact on the core. 6PE itself can be viewed as a global VPN. In the absence of an MVPN-like solution for 6PE, others need to be found to provide multicast support. Such solutions will have to consider all the requirements that were placed on 6PE as a transition mechanism (no impact on the core and so forth). One option being worked on is to look at the MPLS 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 can use fully meshed layer 2 MPLS-based tunnels to build such an overlay. The drawback is that an overlay entails additional operational and management costs.

234

Chapter 6: Providing IPv6 Multicast Services

Work is currently being done in IETF to solve the multicast over MPLS problem. A solution to this problem can be leveraged to provide multicast support over 6PE and 6VPE, too.

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, the goal 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 and audio content delivery. The bandwidth available with broadband access is sufficient to support applications such as video (which requires 2-4 Mbps) and audio (which requires 192 kbps). The SP deploys content servers in its data center, and they represent the sources of the streams. Each audio/video channel is a multicast stream identified by a (S,G). Subscribers can use a PC with an installed client application or a set-top box that subscribes to the (S,G) that maps to the channel of interest. The application or the set-top box is configured for this mapping, and it handles the process of joining or leaving the (S,G). All the sources and the group IDs are fixed and known to the subscribers. An SSM deployment best fits such a service model. The multicast protocols used in this example are as follows:

• •

MLDv2 PIM-SSM

The deployment of this service is presented in the generic topology of an IP service provider shown in Figure 6-7. The network was migrated to dual-stack IPv4/IPv6, and an IPv6 unicast infrastructure is in place. Figure 6-7 shows the subset of routers in this topology used for this example. The IPv6 IGP is OSPFv3. Two servers are shown in the data center. Two users interested in the content provided by these servers are shown in the access portion of the SP network. The two channels used in this example map to (2001:D:AAAA::1000, FF3A::100) and (2001:D:AAAA:1001, FF3A::101). The SP can choose SSM group addresses without a defined scope, and the multicast traffic is meant to stay only within the provider’s network.

IPv6 Multicast Deployment Examples

Figure 6-7

235

SSM Deployment Example Topology

PIM-Join (S2, G2)

AREA 3 E1R

MLDv2 (S1,G1)

Core SW

AREA 1

S2

E1L AC

E2R

AREA 0 E2L

DR

S1 Video Server

AG2L PIM-Join (S1, G1)

PIM-Join (S1, G1) (S2, G2)

MLDv2 (S2, G2)

Aggregation Edge

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 SP does 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 following ACL: AC#show ipv6 access-list IPv6 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 in the 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

continues

236

Chapter 6: Providing IPv6 Multicast Services

Example 6-11 Interface Configuration and MLD Interface Status for the MLD Access Control Feature (Continued) ipv6 enable ipv6 mld access-group mld-acc-control AC#show ipv6 mld interface gig0/2.100 GigabitEthernet0/2.100 is up, line protocol is up Internet address is FE80::201:FF:FE01:1/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-acc-control MLD activity: 36 joins, 31 leaves MLD querying router is FE80::201:FF:FE01:1 (this system)

Tuning PIM 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 PIM a little bit. Routers AC, E1L, and E2L in Figure 6-7 are all connected via a common, Ethernet broadcast domain. In this case, one router is elected to be a DR (as described in the “Multicast Routing” section of this chapter). The network designer might choose to control the DR election process by modifying the PIM DR priorities. In this example, the intent is to make sure E2L is always the PIM DR for this broadcast domain. The interface configuration 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.501 Interface PIM Nbr Hello DR Count Intvl Prior Gi1/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 nei Neighbor Address FE80::208:7CFF:FED9:F81B FE80::20A:8BFF:FE0A:101

Interface Gi1/1.501 Gi1/1.501

Uptime 00:15:43 00:15:44

Expires DR pri Bidir 00:01:24 1 B 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)

IPv6 Multicast Deployment Examples

237

shows the fact that it has a member of 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::100 MLD Connected Group Membership Group Address FF3A::100

Interface Gi0/2.100

Uptime 00:01:27

Expires 00:04:03

The PIM debug is turned on for the FF3A::100 group. The subscriber joining the group triggered a PIM join message to be sent to the PIM DR and up the SPT (2001:D:AAAA:1::1000,FF3A::100), as shown in Example 6-15. Example 6-15 Output of IPv6 PIM Debug for Group FF3A::100 AC#debug ipv6 pim group FF3A::100 IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/2.100 MRIB update (f=100,c=100) IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) Create entry IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) RPF changed from ::/- to FE80::20A:8BFF:FE09:FD01/GigabitEthernet0/1.501 IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) MRIB modify IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) NULLIF-skip MRIB modify !A IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/1.501 MRIB modify A !NS IPv6 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 modify IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/1.501 MRIB modify A IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 Local state changed 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 hop IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 FWD state change ←The Multicast traffic can now be forwarded down the SPT from Prune to Forward

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 topology IP PIM Multicast Topology Table Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info Entry 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 Connected Interface state: Name, Uptime, Fwd, Info Interface flags: LI - Local Interest, LD - Local Dissinterest, II - Internal Interest, ID - Internal Dissinterest, LH - Last Hop, AS - Assert, AB - Admin Boundary

continues

238

Chapter 6: Providing IPv6 Multicast Services

Example 6-16 IPv6 PIM Topology on Router AC (Continued) (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 it at a node that has two equal-cost paths to the source. This is the case with the AG2L router (see Example 6-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::/64 IPv6 Routing Table - 188 entries Codes: 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 OE2 2001:D:AAAA:1::/64 [110/20] via FE80::20B:60FF:FEA7:D81A, GigabitEthernet0/2 via FE80::204:6DFF:FE7F:7C1A, GigabitEthernet0/1 AG2L#show ipv6 pim neighbor Neighbor Address Interface Uptime Expires DR pri Bidir FE80::204:6DFF:FE7F:7C1A Gi0/1 10:29:06 00:01:23 255 (DR) B FE80::283:AFFF:FE47:401A Gi0/0 10:29:06 00:01:36 1 B FE80::20B:60FF:FEA7:D81A Gi0/2 00:57:58 00:01:18 255 (DR) B

In this case, it is expected that (S1,G1) and (S2,G2) are balanced, as shown in Figure 6-7, based on the path of the PIM join messages. The PIM topology does indeed reflect this persource balancing. The output of show ipv6 pim topology indicates that one group’s traffic is received over interface GigabitEthernet0/1 and the other’s over GigabitEthernet0/2, as highlighted in Example 6-18. Example 6-18 PIM Topology with Redundant Paths to the Multicast Source E2L#show ipv6 pim topology (2001:D:AAAA:1::1000,FF3A::100) SSM SPT UP: 00:01:08 JP: Join(00:00:46) Flags: RPF: GigabitEthernet0/2,FE80::20B:60FF:FEA7:D81A Gi0/0 00:01:08 fwd Join(00:03:21) (2001:D:AAAA:1::1001,FF3A::101) SSM SPT UP: 00:01:07 JP: Join(00:00:46) Flags: RPF: GigabitEthernet0/1,FE80::204:6DFF:FE7F:7C1A Gi0/0 00:01:07 fwd Join(00:03:22)

IPv6 Multicast Deployment Examples

239

IPv6 Multicast Traffic Forwarding When the sources start transmitting the multicast traffic, you can monitor its forwarding via the MFIB counters, 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/0 Flags: F NS Pkts: 199/0 (2001:D:AAAA:1::1001,FF3A::101) Flags: Forwarding: 199/8/1482/98, Other: 0/0/0 GigabitEthernet0/1 Flags: A GigabitEthernet0/0 Flags: F NS Pkts: 199/0

This output indicates that the subscribers are enjoying the content they expressed interest in. The SSM-based service 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). Typical applications 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 that are distributed across the network. This makes the deployment more suitable as an ASM model. To describe an ASM-based deployment, a subset of routers was selected from an EN example topology, as shown in Figure 6-8. The network diagram in Figure 6-8 depicts two topological elements: the main campus and a remote office. The following protocols are used to support the multicast services:

• •

PIM-SM and MLDv2 or MLDv1 are used throughout the network.

•

The embedded RP functionality is used for the multicast traffic that has to cross domain boundaries.

BSR is used to deliver the RP-to-group mapping information within the main campus only.

As far as routing is concerned, OSPFv3 is used in the main campus, and eBGP is used to exchange routing information with the remote offices. One PIM domain spans the entire network, but BSR flooding is contained within the main campus network. The setup steps and information common to both the ASM and the SSM examples are not explicitly presented here. All routers that have to support the service should be enabled for IPv6 multicast routing.

240

Chapter 6: Providing IPv6 Multicast Services

Figure 6-8

ASM Deployment Example Topology

R1

Multicast Domain 1 AS 1

eBGP

BSR Domain M1

Area 0

Core

Area 1

eBGP

Remote Campus

C2

C1

SW

Multicast Domain 2 AS 2

Service Provider

DR

B2

DC2

DC1

Candidate BSR2

Candidate BSR1

Candidate RP1

Candidate RP2

S

RP for Embedded RP Groups

Intranet Data Center

Main Campus

Configuring BSR In the main campus shown in Figure 6-8, at least two PIM RPs have to be configured to avoid downtime in case of RP failure. Multiple RPs deployed in a PIM domain require a mechanism that informs routers as to which RP serves a given group. BSR has been selected for this example to provide dynamic RP-to-group mapping and RP redundancy. Router C1 and C2 in the core of the network are set to be candidate BSRs, as highlighted in the configuration in Example 6-20. Example 6-20 BSR Configuration of Two Candidate Routers Router C1: ipv6 pim bsr candidate bsr 2001:1:FFFF:FFFF:2:: 128 priority 2 Router C2: ipv6 pim bsr candidate bsr 2001:1:FFFF:FFFF:1:: 128 priority 1

IPv6 Multicast Deployment Examples

241

The two routers go through the BSR election process, at the end of which C1 becomes the BSR because of its configured higher priority. The result of the BSR election process is highlighted in the output of show ipv6 pim bsr election shown in Example 6-21. Example 6-21 Outcome of the BSR Election Process C1#show ipv6 pim bsr election PIMv2 BSR information BSR 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 Candidate BSR address: 2001:1:FFFF:FFFF:2::, priority: 2, hash mask length : 128 C2#show ipv6 pim bsr election PIMv2 BSR information BSR Election Information Scope Range List: ff00::/8 BSR Address: 2001:1:FFFF:FFFF:2:: Uptime: 00:00:19, BSR Priority: 2, Hash mask length: 128 RPF: FE80::204:6DFF:FE7F:7C1A,Gi0/1.10 BS Timer: 00:01:50 This system is candidate BSR Candidate BSR address: 2001:1:FFFF:FFFF:1::, priority: 1, hash mask length : 128

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 IOS command 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 RP for certain multicast groups. For this example, routers DC1 and DC2 in the data center are set up as candidate RPs for the groups FF08::1:xxxx/112 identified via ACL bsr-group. This is implemented with the global configuration 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 DC1 ipv6 pim bsr candidate rp 2001:D:AAAA:1::1 group-list bsr-group priority 2 DC1#show ipv6 access-list bsr-group IPv6 access list bsr-group permit ipv6 any FF08::1:0/112 sequence 10 DC1#show ipv6 pim bsr candidate-rp PIMv2 C-RP information

continues

242

Chapter 6: Providing IPv6 Multicast Services

Example 6-22 BSR Configuration and Status of a Candidate RP Router (Continued) Candidate RP: 2001:D:AAAA:1::1 All Learnt Scoped Zones, Priority 2, Holdtime 150 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 multicast servers: 2001:D:AAAA:1::1 (for DC1) and 2001:D:AAAA:1::2 (for DC2). The same group address range is covered 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 in Example 6-23. Example 6-23 List of RPs Advertised via BSR C1#show ipv6 pim bsr rp-cache PIMv2 BSR C-RP Cache BSR Candidate RP Cache Group(s) FF08::1:0/112, RP count 2 RP 2001:D:AAAA:1::1 Priority 2, Holdtime 150 Uptime: 00:04:35, expires: 00:01:55 RP 2001:D:AAAA:1::2 Priority 1, Holdtime 150 Uptime: 00:03:18, expires: 00:02:12

Then it distributes the RP-to-group mapping information throughout the entire main campus network. The B2 edge router learns the BSR and RP-to-group mapping information, and it can be viewed in the output of show ipv6 pim group-map (see Example 6-24). Example 6-24 RP-to-Group Mapping Information Learned by a Router via BSR B2#show ipv6 pim group-map FF08::1:0/112* SM, RP: 2001:D:AAAA:1::2 RPF: Gi0/1.501,FE80::20F:35FF:FE3F:441A Info source: BSR From: 2001:1:FFFF:FFFF:2::(00:02:15), Priority: 1 Uptime: 00:00:14, Groups: 0 FF08::1:0/112 SM, RP: 2001:D:AAAA:1::1 RPF: Gi0/1.501,FE80::20F:35FF:FE3F:441A Info source: BSR From: 2001:1:FFFF:FFFF:2::(00:02:15), Priority: 2 Uptime: 00:00:14, Groups: 0

The routers enabled for multicast routing throughout the PIM domain create a virtual tunnel for the known active RPs. They use this interface to register directly connected sources. Example 6-25 shows the tunnel built by router C1 to the RP.

IPv6 Multicast Deployment Examples

243

Example 6-25 Tunnel Built by C1 to the RP for Registration Purposes C1#show ipv6 pim tunnel Tunnel1* 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 RP 2001: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 are no registered sources yet. Example 6-26 IPv6 MLD Registration State When No Sources Are Registered B2#show ipv6 mld group FF08::1:100 MLD Connected Group Membership Group Address FF08::1:100

Interface Gi0/2.100

Uptime 00:00:16

Expires 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: LH RP: 2001:D:AAAA:1::1 RPF: 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 by the highlighted output in the new PIM topology output in Example 6-28. Example 6-28 PIM Topology When a Source Registered B2#show ipv6 pim topology | b FF08::1:100 (*,FF08::1:100) SM UP: 00:00:37 JP: Join(00:00:12) Flags: LH RP: 2001:D:AAAA:1::1 RPF: GigabitEthernet0/1.501,FE80::20F:35FF:FE3F:441A

continues

244

Chapter 6: Providing IPv6 Multicast Services

Example 6-28 PIM Topology When a Source Registered (Continued) Gi0/2.100 00:00:37 fwd LI LH (2001:D:AAAA:1::1000,FF08::1:100) SM SPT UP: 00:00:37 JP: Join(00:00:12) Flags: KAT(00:02:52) RA RPF: GigabitEthernet0/1.501,FE80::20F:35FF:FE3F:441A No interfaces in immediate olist B2#show ipv6 mfib IP Multicast Forwarding Information Base Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag, AR - Activity Required, K - Keepalive Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second Other counts: Total/RPF failed/Other drops Interface Flags: A - Accept, F - Forward, NS - Negate Signalling IC - Internal Copy, NP - Not platform switched SP - Signal Present Interface 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 example BSR 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 contain the 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 this example, the router chosen to be RP for embedded RP groups is DC2. DC2 is set to be an RP with the following 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 is FF78:240:2001:D:AAAA:1:0:100. When a subscriber in the remote campus

IPv6 Multicast Deployment Examples

245

joins the group, the RP-to-group mapping is learned from the multicast address. This mapping is highlighted in the output of show ipv6 pim group-map on the R1 router in Example 6-29. Example 6-29 RP-to- Group Mapping with Embedded RP R1#show ipv6 pim group-map FF78:240:2001:D:AAAA:1::/96* RP : 2001:D:AAAA:1::2 Protocol: SM Client : Embedded Groups : 1 Info : RPF: PO2/0,FE80::20D:66FF:FE40:D8CC

When a source is present for the group, the (S,G) is built for the traffic. Both (S,G) and (*,G) groups can be now 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 topology IP PIM Multicast Topology Table Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info Entry 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 Connected Interface state: Name, Uptime, Fwd, Info Interface 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: LH RP: 2001:D:AAAA:1::2 RPF: 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) RA RPF: 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 reports for the (S,G), the events that generate entries in the immediate OIL. On the other hand, from a forwarding perspective, the MRIB shows outbound interfaces for the (S,G), as highlighted in the output of show ipv6 mrib route in Example 6-31. These are inherited by the (S,G) from the (*,G).

246

Chapter 6: Providing IPv6 Multicast Services

Example 6-31 Forwarding Information for the Embedded RP Multicast Group R1#show ipv6 mrib route FF78:240:2001:D:AAAA:1:0:100 IP Multicast Routing Information Base Entry flags: L - Domain-Local Source, E - External Source to the Domain, C - Directly-Connected Check, S - Signal, IA - Inherit Accept, D - Drop Interface 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:D8CC Flags: 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 this network example, it was chosen to advertise the source prefix (2001:D:AAAA:1::/64) only for multicast use via the multicast IPv6 address family. The output in Example 6-32 shows the prefix advertised within the BGP multicast address family but not present in the IPv6 unicast routing table. Example 6-32 IPv6 Prefix Advertised by BGP for Multicast Only R1#show bgp ipv6 multicast 2001:D:AAAA:1::/64 BGP routing table entry for 2001:D:AAAA:1::/64, version 3154 Paths: (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, best R1#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 listeners in the remote campus will be able to join and receive traffic from sources in the main campus. On the other hand, because these routers do not have a unicast IPv6 route to the RP (2001:D:AAAA:1::2), they will not be able to bring up their tunnel interface to the RP. Because of this, the routers in the remote campus will not be able to register any sources with the RP.

IPv6 Multicast Deployment Examples

247

The deployment examples discussed in the last two sections show IPv6 as an apt successor of its IPv4 predecessor in terms of offering multicast services. IPv6 builds on the successes of IPv4, and it ignores its failures. 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 on protocol selection. IPv6 multicast has reached a level of maturity that makes it ready for large-scale deployments in both ASM and SSM models. The only scenario for which IPv6 does not have a complete solution at this time is that of a multidomain deployment. It currently has no mechanism in place to exchange source information between PIM domains. This drawback represents one area of the IPv6 protocol that will likely 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 are separated from other network users and that may communicate among them as if they were on a private network” (RFC 4026). IP-based VPNs have become popular in the recent years, and, as reviewed in Chapter 1, “The Case for IPv6—An 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 various types 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’s customer itself. Each solution has its benefits and drawbacks. The “Using IPsec to Implement CE-Based VPNs” section focuses on customer edge (CE)-based VPNs using IPsec, where the provider edge (PE) devices do not know anything about the routing or the addressing of the customer networks. 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 a public infrastructure; it allows businesses to set up extranets between themselves, and telecommuters to connect to their office network. It has mechanisms that offer security and quality of service (QoS), enabling applications such as voice and video. For enterprises buying VPN service (instead of building their own private network using, for example, leased lines) from an SP, the main benefits are price and flexibility. The lower prices and flexibility are the result of the SP’s ability to reduce operational costs by consolidating its services over a single IP infrastructure. This consolidation leads to better use of resources and enables the provider to offer value-added services such as guaranteed QoS, multicast, redundant routes, fast path recovery, and so on, on a “get-what-you-pay-for” basis.

250

Chapter 7: VPN IPv6 Architecture and Services

Two VPN models have been widely deployed in recent years: the CE-based (“overlay”) model, and the PE-based (“peer-to-peer”) model. Although they are briefly discussed in the following sections, the terminology is introduced here:

•

Provider network—This is the SP network, enabling connectivity between customer sites (also referred as P-network).

•

Customer network—This is the customer network, typically a set of customer sites, to be connected over the P-network.

•

Customer site—This is one, topologically contiguous customer site such as a campus or remote office.

• •

Provider device (P)—An SP router that does not connect to customer sites.

•

Customer edge device (CE)—A customer router that connects the customer site to the P-network.

•

Virtual private network (VPN)—A set of customer sites that are allowed to communicate with each other and are subject to a common set of administrative policies. Note that a “site” can be a single remote user.

• • •

IPv4 VPN—A VPN that connects IPv4-enabled sites.

•

Hybrid VPN—A VPN that connects IPv4-only enabled sites and IPv6-only enabled site.

Provider edge device (PE)—An SP router connected to VPN customer sites. The PE router marks the edge of the P-network.

IPv6 VPN—A VPN that connects IPv6-enabled sites. Dual-stack VPN—A VPN that connects separately IPv4-enabled sites and IPv6enabled sites.

Many of the same techniques and mechanisms are used in both the CE-based and the PEbased VPN models. The difference between the two models is one of economy, politics, and administrative domains rather than technology. 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 same as for IPv4 VPNs. Some differences apply as to how an IPv6 VPN will be deployed, however. Because IPv6 has enough addresses (to say the least), there is no need to use a private overlapping address range. Avoiding overlapping address space simplifies management and makes merging several private internets into a single private internet much easier. A challenge for the deployment of IPv6 in general and IPv6 VPN in particular relates to its coexistence with IPv4. It is expected that the public infrastructure will migrate to IPv6 at a slower pace than some of the private networks. In a network where most of the core will remain IPv4 only, IPv6 VPNs will have to be tunneled over it. Benefits and issues related to tunneling are not specific to VPNs, and various mechanisms are reviewed in Chapter 3, “Delivering IPv6 Unicast Services,” in the section “IPv6 over IPv4 Tunnels.”) In an MPLSenabled network, however, using a similar approach as 6PE (see Chapter 3, section “IPv6 over 6PE”), IPv6 MPLS VPN could run over an IPv4-based core without the drawbacks of

Virtual Private Network Overview

251

tunneling. Such an implementation of IPv6 VPN is referred to as 6VPE and is discussed in the section “BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution.” For a more in-depth study of VPNs, refer to the following books: VPN Applications Guide by David McDysan, and MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard.

Provider-Provisioned VPNs Provider-provisioned VPNs (PPVPNs) are VPN services operated by the SPs. Table 7-1 illustrates the taxonomy of PPVPN. Table 7-1

Taxonomy of PPVPNs PPVPN

L2 VPN

CE-based

L2TP: Layer 2 Tunneling Protocol.

PE-based

VPWS: Wire service. VPLS: LAN service. IPLS: IP-only LAN service.

L3 VPN

CE-based

IPsec. VPN knowledge limited to CEs.

PE-based

BGP-MPLS IP VPN: The PE maintains VPN states to provide users isolation.

Per-VPN forwarding tables

Virtual router: The PE maintains a logical view per VPN.

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 IPX traffic, 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 common infrastructure by the means of trunks. The trunks can be layer 1 (TDM), layer 2 (virtual circuit), or layer 3 (IP tunnels). The VPN can be operated by the user or the provider. In all cases, they terminate at the customer sites. The boundary between the private network and the shared public infrastructure is on the CE router. Any tunneling 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 no guarantees when it comes to security). Other tunneling mechanisms, such as GRE tunneling, 6to4, or IP-in-IP, can also be used, but these have none of 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.

252

Chapter 7: VPN IPv6 Architecture and Services

CE-based VPNs can easily span multiple providers: the CE-to-CE tunnels work as long as there is IP connectivity. Routing occurs between customer sites and is transparent to the SP; the customer network is an overlay on top of the provider network, which is used as a transport mechanism. To achieve effective routing, each site has to have a tunnel to every other site in what is called a fully meshed design. This would result in N(N–1)/2 number of tunnels for N sites. Not only could the number of tunnels result in scalability issues on the routers terminating the tunnels, but the number also results in a huge cost of operating the network. Each time a new site is added, new tunnels must be created on all the other sites. Typically, some sort of hub-and-spoke network 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 this case, service level agreements (SLAs) are difficult to negotiate. In this respect, PE-based VPNs are better, not because they can offer better QoS, but because the provider has already prepared the network for QoS and can offer this as a value-added service as a part of the PE-based VPN offering.

PE-Based VPNs PE-based VPN solutions involve the capability of the PE router to separate customer routing policies. Two approaches have emerged to achieve this. With the first approach, the physical PE router can be split into disjointed logical routers, each instance taking care of one VPN. With the second approach, each VPN routing table is managed independently by a single router exchanging routes between sites. The former is the so-called virtual router approach, whereas the latter is the BGP-MPLS IP VPN approach. You can use both with 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 associated routing tables. A fraction of the PE is literally a part of the customer network, in charge of exchanging customer routes with remote customer sites by peering with remote PEs. CEs never peer directly; instead, they peer indirectly via PEs. Therefore, to achieve optimal routing, it is sufficient to mesh PEs, which are significantly less than the CEs of all customers (a PE can be attached to several customers). If you deploy MPLS PE-based VPNs, the data plane is operated independently of the routing plane, so that routing hubs do not result in suboptimal forwarding paths. Because routing uses the Border Gateway Protocol (BGP), it can leverage 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 allows hosts to communicate within one site, within one VPN (with other sites), and with public resources.

Virtual Private Network Overview

253

VPN IPv4 sites often use private addressing as defined in RFC 1918 for their addressing plan. These addresses do not need to be registered, and they are not routable on the public network. Whenever a host within a private site needs to access a public domain, it goes through a device exposing a public address on its behalf. 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 global addresses for the private addressing plan. Another approach is to use unique local addresses (ULAs), described in Chapter 2, “An IPv6 Refresher,” in the 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 prefix structure). They are also Internet service provider independent and can be used for communications inside of a site 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 application proxy (such as a web proxy for accessing web pages), which will access the public resource on its behalf with a global routable address, or it can use a public address of its own. In the latter case, if ULAs have been deployed, the IPv6 host is configured with a routable global address, too. The source address selection algorithm, 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 security similar to the layer 2 VPNs it was designed to replace. The CE-based model was designed by the IPsec working 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 and MPLS. 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.

254

Chapter 7: VPN IPv6 Architecture and Services

You can easily use IPsec to secure remote-access traffic. MPLS VPNs face the challenge of securing the traffic 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 an MPLS 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 not separately manage private and public routing tables. In addition, poor implementations or complex configurations could easily defeat the best intentions. In that regard, it is important to note that IPsec puts most of the configuration burden on the CE, whereas for the MPLS VPN, the configuration complexity is on the 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, and you have to trust the provider to get the configuration right, so that traffic is not leaked outside the VPN. In the IPsec case, you get data confidentiality, but only to the edge of the site. Because traffic inside the site is unencrypted, 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 itself provides data confidentiality.

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 3 VPN. 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 provide message 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 large enterprises 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 policy can 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 certain routes while forwarding traffic outside the tunnel for others). An alternative is to run the VPN client on the customer premises equipment (CPE) router in the telecommuter’s home, thereby giving secure access to the corporation from its whole home network. This model still stands with IPv6, providing that

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

255

VPN client software supports IPv6 and an IPv6-enabled VPN concentrator is deployed. At the time of this writing, Cisco VPN 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, for example, 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 BGP peers. By using the same techniques as described in the “Scaling IPv6 VPN” section, you can limit the number of BGP peers. The CE routers use 6to4 addresses to peer with each other, but the prefixes exchanged can be normal 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 3 describes 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 does not. 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 IPsec to 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 can extend the interior gateway protocol (IGP) running within a site to include the VPN, or you can use a separate routing protocol between the CEs across the VPN. One example is to run OSPFv3 within the site and iBGP over 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 existing tunnel infrastructure, you can deploy IPv6 over it. Both IPv4 and IPv6 can run over an IPsec tunnel infrastructure that uses IPv4 transport. In the future, when the SP becomes IPv6 capable, you can use IPv6 transport for the IPsec tunnels, while still tunneling both versions of the protocol. An example of this scenario is 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 and Y. Rekhter. This solution represents an implementation of the PE-based VPN

256

Chapter 7: VPN IPv6 Architecture and Services

model. Because this type of VPN technology has become by far the most popular technology for deploying VPN in a peer-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 IPv4based MPLS core. It is basically a VPNv6 PE, dual stack (IPv4+IPv6) that implements 6PE concepts on the core-facing interfaces.

•

VPNv6 addresses—A VPNv6 address is a 24-byte identifier, beginning with an 8-byte route distinguisher (RD) and ending with a 16-byte IPv6 address. Sometimes it is called an VPN IPv6 address.

•

VPNv6 address family—The Address Family Identifier (AFI) identifies a particular network layer protocol and the Subsequent AFI (SAFI) provides additional information. The AFI IPv6, 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 IPv6 address 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 a customer-specific table, enabling the PE router to maintain independent routing states for each customer.

In principle, no difference exists between IPv4 VPNs, as described in “BGP-MPLS IP VPNs,” and IPv6 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 VPNv6 architecture. It is used to distribute IPv6 routes over the SP backbone, with the same set of mechanisms to deal with overlapping addresses, redistribution policies, and scalability issues. Even though we do not expect overlapping address space in IPv6, addresses are still prepended with an RD. A new Network Layer Reachability Information (NLRI) 3-tuple format 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 routes and filtering imported ones. For scalability, you can use route reflectors to concentrate routing paths, and avoid a full PE mesh. Similar to IPv4, BGP features such as route refresh, automatic route 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 following differences between IPv4 and IPv6:

•

Creation of a new MP-BGP VPNv6 address family, and specification of VPNv6 address format

• •

Specification of a new VPN IPv6 NLRI Specification of the BGP next-hop encoding in the case of an IPv4-based MPLS core

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

257

A VPNv6 address is a 16-byte IPv6 address, prepended with an 8-byte RD, to form a 24-byte address. As in VPN IPv4, the VPNv6 prefix (network portion of the address) is only meaningful within MP-BGP, and only the IPv6 part of this prefix is kept when redistributed into IPv6 routing protocols. 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::/64 BGP routing table entry for [100:1]2001:100::/64, version 15 Paths: (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 because it conflicts with the IPv6 prefix notation. For instance, 100:1:2001::/64 could be interpreted as an IPv6 prefix or a VPNv6 prefix with an RD of 100:1. For that reason, VPNv6 prefixes use the notation [RD]IPv6-prefix. In the latter part of “BGP-MPLS IP VPN Extension for IPv6 VPN” (draft-ietf-l3vpn-bgpipv6), transitioning and coexistence aspects are covered, with emphasis on the 6PE approach applied to VPNv6. The main aspects of this approach have been discussed at length in Chapter 3 (in the “IPv6 over 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 Autonomous System Boundary Routers (ASBRs) might support IPv4 only, IPv6 only, or both, independently of the 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 topology and Internet access topology.

Routing Table Segregation The SP network provides connectivity between “same-customer” sites, while isolating customers from 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 the edge routers. At any particular edge router, one VRF routing table is associated with each site connected to that router, and entries from one VRF table do not leak to another, unless explicitly configured to do so.

258

Chapter 7: VPN IPv6 Architecture and Services

•

Isolation between core and edge routing—Provider’s routes, used by PE routers to reach each other over the provider backbone are kept separated from customer’s routes. As a matter of fact, most provider core routers (P-routers) only store these routes and never see customer routes.

To achieve routing segregation, a routing tunnel must be established between PE routers to exchange customer routes. This routing tunnel is transparent to the core routers. This is achieved using MP-BGP between the PE routers. In addition, a forwarding tunnel must be available throughout the provider core network, so that datagrams can be forwarded by P-routers, without requiring the P-routers to keep routing tables for each VPN. In theory, the tunneling mechanism chosen for traffic forwarding could be any of the following kinds: GRE, IPsec, L2TP, MPLS, and so forth. In practice, MPLS has been used for the most part in deployment so far. L2TP has been specified for P-networks that do not use MPLS, and it is deployed in few environments. Figure 7-1 illustrates how routing segregation is achieved. Figure 7-1

Routing Tables in BGP-MPLS IPv6 VPN Model Customer#1 Site1

Default Routing Table

2001:100:1:1000::/56

Routing Table “Red”

Customer#1 Site2 2001:100:1:2000::/56

BGP Table

CE1

CE

200.14.14.1 2001:100:1:1000::/64

1

200.11.11.1

200.10.10.1

2

4

5

2001:100:1:2000::/64

3 2001:100:2:1000::/64

MP-iBGP PE1 Default Routing Table

CE2 2001:100:2:1000::/56

Customer#2 Site1

2001:100:1:2000::/64

PE2

Provider Network

CE 2001:100:2:2000::/56

Routing Table “Blue”

Customer#2 Site2

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 routes received from the CE routers as well as routes from remote sites in the same VPN. For example, 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 red IPv6 Routing Table - red - 10 entries C 2001:100:1:1000::/64 via Serial0/0, directly connected

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

259

Example 7-2 IPv6 VRF Table red (Continued) B B

2001:100:1:1000::/56 via 200.14.14.1 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.

•

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, the content 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 subnets i L1 200.10.10.1 [115/30] via 40.1.1.3, Serial1/0 31.0.0.0/24 is subnetted, 1 subnets i L1 31.1.1.0 [115/30] via 40.1.1.3, Serial1/0 200.11.11.0/32 is subnetted, 1 subnets C 200.11.11.1 is directly connected, Loopback0

•

A BGP table, which contains entries from all the customer-specific IPv6 routing tables. An example 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 Path Route 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.1 Route 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 over that 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 this entry belongs to the default routing table at the CE, it is installed in a VRF IPv6 table (red) at the PE. The interface on which these entries are received determines into which table they should get installed. 2 PE1 redistributes this entry into its MP-iBGP table, after prefixing it with the RD

referencing the VRF table the entry is coming from (RD 100:1 for entries from table red above).

260

Chapter 7: VPN IPv6 Architecture and Services

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 as a policy mechanism to determine which entry from which VRF table is to be redistributed in which VRF table on the remote PE. Instead, BGP communities (route targets) are used for that purpose. 5 From the VRF table, the entry is finally redistributed into the customer site

(customer#1, 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 Architectures by Ivan Pepelnjak and Jim Guichard. That book provides enough background to appreciate fully the following 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 by leveraging an existent MPLS IPv4 core network. This approach, referred to as 6VPE, is similar to the 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 Site2

Site1 Host-1

2001:100:1:1000::/56

2001:100:1:2000::/56 200.14.14.1

CE1

MP-eBGP session Address-Family IPv6

CE2

IPv6 ND iGP-v6 (OSPFv3, ISIS, etc.) 2001:100:1:1000::/64

200.11.11.1

VRF Red P1

2001:100:1:2000::/64

VRF Red P2

PE2

PE1 iGP-v4 (OSPF, ISIS) LDP-v4 MP-iBGP session Address-Family VPNv6

200.10.10.1

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

261

The CE routers are connected to the provider’s backbone via PE routers. The PE routers are connected via P-routers. P-routers are unaware of VPN routes, and in the 6VPE case may support only 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. The core routing, which involves PE routers and P-routers is typically performed by an IPv4 IGP such as OSPFv2 or IS-IS. In the simple topology illustrated in Figure 7-2, the IGP distributes only routes internal 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 and a 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-CE routing, using appropriate route export policies at the ingress PE router and appropriate route import policies at the egress PE router. Routing between the CE and its PE is achieved using a routing protocol that is VRF aware. On Cisco routers, at the time of this writing, only static routes, and eBGP, are VRF aware. In the example shown in Figure 7-2, eBGP is used between the CE (CE1) and the PE (PE1). At the same time, the CE runs an IPv6 IGP—for instance, OSPFv3 or IS-IS for IPv6— within the VPN site (site1). The CE redistributes IGP routes into MP-eBGP address family IPv6. At the PE, these routes are installed in the VRF red, and forwarded to remote PEs (PE2), according to export policies defined for this VRF.

BGP Next Hop When announcing a prefix (using the MP_REACH_NLRI attribute), MP-BGP running on one PE inserts a BGP next hop in the update message sent to a remote PE. This next hop is either propagated from the received update (for instance, if the PE is a route reflector), or it is the address of the PE sending the update message (egress PE). For the VPNv6 address family, it has to be a VPNv6 address, regardless of the nature of the network between the PE speakers. Because the RD has no significance (the address is not part of any VPN), it is just set to zero. If the provider network is a native IPv6 network, the remaining part of the next hop is the IPv6 address of the egress 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 interface Loopback0 ip address 200.11.11.1 255.255.255.255 ! router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0

continues

262

Chapter 7: VPN IPv6 Architecture and Services

Example 7-5 VPNv6 Configuration Example Using IPv4 Next Hop (Continued) ! address-family vpnv6 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended exit-address-family

By default, the next hop advertised will be the VPNv6 address: [0:0]::FFFF:200.11.11.1

Note that it is a 192-bit address in the following form: [RD]::FFFF:IPv4-address.

In this particular case, only 32 bits are significant out of 192 bits sent on the wire. Example 7-6 shows that BGP configuration can be used when peering takes place over a native IPv6 network. Example 7-6 VPNv6 Configuration Example Using an IPv6 Next Hop router bgp 100 neighbor 2001:100:1:1000::72d remote-as 100 ! address-family vpnv6 neighbor 2001:100:1:1000::72d activate neighbor 2001:100:1:1000::72d send-community extended

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 can still be deployed, in the interprovider VPN case, when the two providers exchange VPNv6 routes over an IPv6 link using MP-eBGP. See the section “Interprovider VPNs” later in the chapter for details. When the BGP VPNv6 peers share a common subnet, the MP_REACH_NLRI attribute contains a link-local address next hop, in addition to the global-address next hop. This will typically happen in inter-AS topology, scenario B (see the section “Interprovider VPNs” in the topology examples later in this chapter), when AS boundary routers are facing each other. In that case, the link-local next hop 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 routing and label distribution protocols.

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

Figure 7-3

263

Building the Label Stack for 6VPE

iGP+LDP v4 : PE1v4, Label Lb v4

v4

iGP+LDP v4 : PE1 , Label La

VRF Red

PE1

iGP+LDP v4 : PE1 , Label Lc

P1

PE2

P2

VRF Red

MP-iBGP VPN-IPv6 update: RD:Net1, Next-hop=::FFFF:PE1v4 SOO=Site1, RT=Red, Label=L1

LDP v4 Table BGP VPNv6 Table

Prefix Next Hop Label RD:Net1 ::FFFF PE1 L1

Prefix PE1

Next Hop P2

Label Lc

Import route

IPv6 vrf Table Red

Prefix Net1

Layer2 MacP2

Label Stack Lc L1

The idea is that ingress PE router (PE2) obtains two separate labels, and combines them into a label stack, which it can impose when forwarding traffic to a given VPN IPv6 destination. Each of these labels is learned via a specific mechanism, and has a specific role in the LSP. The outer label (Lc in Figure 7-3) is used to label switch packets from the ingress PE (PE2) to the egress PE (PE1). This label is obtained through a label distribution protocol, such as Label Distribution Protocol (LDP) or ReSerVation Protocol (RSVP). The inner label (L1 in Figure 7-3) is used to reach the appropriate CE router (CE1) from the egress PE (PE1). MPiBGP 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 is performed to combine the two labels: the prefix (net1) is reachable via PE1, using label L1, and PE1 itself is reachable via P2, using label Lc. This recursion takes place as soon as labels are available, 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, then IPv4) is performed to build the label stack, just like for 6PE.

264

Chapter 7: VPN IPv6 Architecture and Services

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 Label Switching 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 but does not need to. On the other hand, IPv6 traffic between VPN sites requires labeled paths to traverse P-routers (because these are unaware of IPv6 addresses). This is a fundamental difference from other tunneling techniques, in which the routing updates are sent inside the forwarding tunnel. Should the tunnel break, these updates stop, and edge routers remove corresponding entries from their routing table. With VPNv6 (and VPNv4), the labeled path may be broken, while the path between PEs is still usable. The MP-iBGP session will keep exchanging IPv6 routes even though packets for corresponding destinations will not be able to traverse the core network. The result is that the traffic is black holed.

Forwarding in BGP-MPLS IPv6 VPN Upon receiving IPv6 traffic from one customer site, the ingress PE router (PE2) will MPLS tunnel IPv6 VPN packets over the backbone toward the egress PE router (PE1) identified as the BGP next hop. Figure 7-4 shows the forwarding tables (IPv6 and MPLS) built as the result of the label distribution across P- and PE routers. Figure 7-4

MPLS Forwarding Tables CE1

PE1

200.14.14.1

200.11.11.1 FE80::A8BB:CCFF:FE01:F500

P1 40.1.1/24 2

3

PE2

P2 30.1.1/24 3

1

CE2

200.10.10.1 31.1.1/24 1

4

2001:100:1:1000::/56 FE80::A8BB:CCFF:FE01:F200 [PE1, PE1, La] Idp+iGP

[PE1, P1, Lb] Idp+iGP

[PE1, P2, Lc] Lc = 18 Idp+iGP

Install Entry in Global Table IPv4 or IPv6

[net1, CE1] net1=2001:100:1:1000::/56 eBGP IPv6

[rd1:net1, 6VPE1, L1] L1 = 24 MP-iBGP VPNv6

Compute Label Stack Lc+L1

[net1, 6VPE2] eBGP IPv6

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

265

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 cef vrf red command. The label forwarding table at routers P2, P1, and PE1 is shown in Example 7-7 via the show mpls forwarding command. Example 7-7 Showing MPLS Labels Along the LSP PE2#show ipv6 cef vrf red 2001:100:1:1000::/56 nexthop 31.1.1.1 Ethernet0/0 label 18 24 P2#show mpls forwarding Local Outgoing Prefix Outgoing Label Label interface 18 16 200.11.11.1/3 Et0/0 P1#show mpls forwarding Local Outgoing Prefix Outgoing Label Label interface 16 Pop Label 200.11.11.1/32 Et0/0 PE1#show mpls forwarding Local Outgoing Prefix Label Label 24 No Label 2001:100:1:1000::/56[V]

Next Hop 30.1.1.3 Next Hop 40.1.1.2 Outgoing interface Et0/0

Next Hop FE80::A8BB:CCFF:FE01:F500

Figure 7-5 shows the MPLS encapsulation taking place at the ingress PE, and the label swapping occurring at P-routers. Figure 7-5

MPLS VPNv6 Forwarding Operation

CE1 VRF Red

PE1

P1

P2

PE2 VRF Red CE2

IPv6 Header IPv6 Payload

Lc=18 L1=24 IPv6 Header IPv6 Payload Dst=2001:100:1:1000::1

Lb L1 IPv6 Header IPv6 Payload

L1 IPv6 Header IPv6 Payload

IPv6 Header IPv6 Payload

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.

266

Chapter 7: VPN IPv6 Architecture and Services

Under normal operation, a P-router along the forwarding path does not look inside the frame beyond the first label. It either swaps the incoming label with an outgoing one, or removes it (for instance, P1 in Figure 7-5) if the next router is a PE. The latter action is called penultimate hop popping. The remaining label (L1 in the example) has a side function (other than identifying the egress PE interface toward the customer site). It also hides the protocol version (IPv6) from the P-router, which would need to otherwise forward an IPv6 packet. The following output, shown in Example 7-8, via debug mpls packet enabled all along the LSP, illustrates the label swapping happening at each router. Example 7-8 Tracing MPLS IPv6 Packets Along the LSP P2#debug mpls packet 00:07:25: MPLS les: Et1/0: 00:07:25: MPLS les: Et0/0: P1#debug mpls packet 00:07:25: MPLS les: Et1/0: 00:07:25: MPLS les: Et0/0: PE1#debug mpls packet 00:07:25: MPLS les: Et1/0:

NOTE

rx: Len 122 Stack {18 0 63} {24 0 63} - ipv6 data tx: Len 122 Stack {16 0 62} {24 0 63} - ipv6 data rx: Len 122 Stack {16 0 62} {24 0 63} - ipv6 data tx: Len 118 Stack {24 0 61} - ipv6 data rx: Len 118 Stack {24 0 61} - ipv6 data

You may have noticed that a P-router is ignorant about IPv6 VPN routes. In fact, with 6VPE, it is an IPv6 ignoramus. The IPv6 header remains hidden under one or more MPLS labels. An interesting issue arises when the P-router receives an MPLS-encapsulated IPv6 packet that cannot be delivered. This scenario can occur if the Time To Live (TTL) in the label expires or if the maximum 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, this process requires the P-router to be capable of building an ICMPv6 message; otherwise, it would have to drop silently the undeliverable MPLSencapsulated IPv6 packet. However, two more issues must be solved: • The IPv6 source address found in the packet belongs to a VPN unknown to the P-router and cannot 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”) a mechanism applicable to IPv6 similar to IPv4. The original undeliverable packet carried a label stack that can be imposed to the ICMPv6 message, to enable it to reach the egress PE. The egress PE 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 backbone again before reaching its destination. For selecting an IPv6 source address, source address selection can be used. However, the P-router may not have any IPv6 address, and even when it has one, it does not belong to the private space of the destination of the packet. In that case, it sets the source address to the v4-mapped address built from the v4 address configured on the incoming interface. See an example of such ICMPv6 packet in the section “Hub and Spoke.”

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

267

VRF Concepts and IPv6 Implementation VRF concepts are discussed at length in MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard. However, with the introduction of IPv6 VPNs, some of these concepts deserve clarification. 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 should be distinct IPv4 and IPv6 VRFs. However, although IPv4 and IPv6 routing tables are indeed distinct, it is convenient, from a deployment standpoint to share the same VRF between the two protocols for a given customer. VPNv6 customers are likely to be existing VPNv4 customers, either deploying dual-stack hosts and routers, or shadowing some of their IPv4 infrastructure with IPv6 nodes. Several deployment models are possible. Some customers use separate logical interfaces for IPv4 and IPv6, and define separate VRFs on each. Although this approach provides flexibility to configure separate policies for IPv4 and IPv6, it also prevents sharing the same policy. Another more attractive model is to keep one single VRF on the PE-CE interface, and enable it for IPv4, IPv6, or both. It is then possible to define common or separate policies for each IP version. With this model, a VRF is better defined as the set of tables, interfaces, and policies found at the PE, privately used by sites of a particular VPN connected to this PE. Figure 7-6 shows the latter model, where VRF red is enabled for both IPv4 and IPv6, and is associated with two interfaces (IF1, IF2), two sets of tables (IPv4 Routing and Forwarding tables and IPv6 Routing and Forwarding tables), and a set of common or distinct policies. Such a VRF that is defined for both IPv4 and IPv6 will be referred to as multiprotocol VRF. Examples of such multiprotocol VRFs are provided in the “Dual-Stack VPNs” section. Figure 7-6

Multiprotocol VRF VRF Red I/F List

CE

Protocols

IPv4 IPv6

Common Policies

SiteB IF1

CE IF2

SiteB PE

Tables

RIBv4, FIBv4

Specific Policies

Route-Map Route-Targets

Tables

RIBv6, FIBv6

Specific Policies

Route-Map Route-Targets

IF1, IF2

Route-Targets

268

Chapter 7: VPN IPv6 Architecture and Services

Configuring a VRF Configuring a VRF for IPv6 is no different from configuring a VRF for IPv4. In fact, it could have been exactly the same, if IPv4 and IPv6 VRFs had been kept separate. For the reasons mentioned previously, a VRF is an address-family-independent object that can be enabled and configured for each 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 vrf definition , and then rd .

NOTE

Interestingly, the RD is configured outside the context of the address family. A careful reader might wonder why this is the case, when the RD is used to distinguish overlapping addresses within the context of a particular BGP address family. Having separate RDs for IPv4 VPN addresses and IPv6 VPN addresses should not matter. Indeed it does not. And the same or different RDs for two different address families do not make any difference. On Cisco routers, it was decided to keep the RDs the same to simplify configuration and VPN management.

Still, in Step 1 of the configuration—that is, outside any address family context—you can configure policies in common between IPv4 and IPv6. This is basically shared route targets (import and export). This feature proves especially useful in a migration scenario, where IPv4 policies already are 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 address family configuration includes the usual import and export policies, maximum number of routes in the VRF, and so on. Note that the policies (route map and route target) entered at this level override global 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 vrf definition site1 rd 1000:1 address-family ipv4 route-target export route-target import address-family ipv6 route-target export route-target import

100:1 100:1 200:1 200:1

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

269

Associating a VRF to an Interface To specify which interface belongs to which VRF, you must use the interface command vrf forwarding . The meaning and effect of this command on an interface is the same as the ip vrf forwarding command used for VPNv4, with the difference that it is multiprotocol. An interface cannot belong to more than one VRF. When the interface is bound to a VRF, previously configured addresses (IPv4 and IPv6) are removed and they must be reconfigured. Example 7-10 is an example of the interface configuration. Example 7-10 Multiprotocol VRF Configuration on the Interface hostname PE-1 ! vrf definition site1 rd 100:1 route-target export 100:1 address-family ipv4 address-family ipv6 ! interface Serial0/0 vrf forwarding site1 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 to IPv4. Here are a few key examples:

•

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 operator to use them within the scope of a particular VRF. Two notations can be used, either vrf or % 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::72e ping 2001:100:1:1000::72e%red

•

Traceroute traceroute vrf red 2001:100:1:1000::72e traceroute 2001:100:1:1000::72e%red

270

Chapter 7: VPN IPv6 Architecture and Services

•

Telnet telnet /vrf red 2001:100:1:1000::72e telnet 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 network designer still has to consider scaling when designing the network. Scaling a BGPMPLS IPv6 VPN is 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 with one routing and one forwarding table per connected customer, but their BGP tables, which sum up all entries from individual VRFs, are growing accordingly. Another scalability issue arises when the number of PEs in the provider network grows beyond a certain level. Assuming that a significant number of sites belonging to the same VPN are spread over many PEs, the number of MP-BGP sessions 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 ones are the following:

•

Route refresh and automatic route filtering—Limit the size of routing tables because only routes imported into a VRF are kept locally. When the import policy changes, a route refresh can be sent to query a retransmission of routing updates.

•

Outbound route filtering (ORF)—Allows the ingress PE to advertise filters to the egress PE so that updates are not unnecessarily sent over the network.

•

Route reflectors—These are iBGP peers that propagate iBGP routes learned from other iBGP peers. Route reflectors are used to concentrate the iBGP sessions.

The following example illustrates the route refresh received at PE2, in a situation where PE1 exports routes with route target 500:1 and PE2 imports it. The initial BGP table at PE2 is shown in Example 7-11. Example 7-11 BGP Table Before the Route Refresh PE2#show bgp vpnv6 unicast all Network Next Hop Route 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 ::

BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution

271

In one VRF, entries with a route target 500:1 are set up for import as shown here: PE2(config)#vrf definition red PE2(config-vrf)#route-target import 500:1

The following trace (obtained using the debug bgp command) shows the route refresh being sent, and the BGP update being received and installed: 01:09:28: BGP: 200.11.11.1 sending REFRESH_REQ(5) for afi/safi: 2/128 01:09:28: BGP: 200.11.11.1 send message type 5, length (incl. header) 23 01:09:36: BGP IPv6: Updating route (not batched) 2001:100:1:5000::/56 m/d 0/200, flags 0

Example 7-12 shows the BGP table. Example 7-12 BGP Table After the Route Refresh PE2#show bgp vpnv6 unicast all Network Next Hop Route 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.1 Route 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 shows how to display it. Example 7-13 Route- Refresh Capability Display PE2#show bgp vpnv6 unicast all neighbors BGP neighbor is 200.11.11.1, remote AS 100, internal link 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 the issue of BGP table size worse. Because the route reflectors do not have any VRFs themselves, they cannot filter routes based on import policies. Because they can store BGP routes for many clients PEs, they tend to accumulate routes from many sites. Finally, they can easily become a single point of failure for the sessions that they reflect. To alleviate these issues, the design of the network using route 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 in such a way that a given route reflector serves only a limited numbers of PEs.

272

Chapter 7: VPN IPv6 Architecture and Services

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 deployment scenarios. Table 7-3

BGP VPNv6 Features MP-BGP Feature

Description

Base IPv6 MPLS VPN functionality

Support of VRF for IPv6. Handling of labeled IPv6 VPN address family in MP-BGP. Appropriate route handling (import/export) taking into account RT. Automatic inbound route filtering.

EBGP as PE-CE routing protocol

eBGP can run on a VRF basis.

Source of origin (SOO)

SOO is used to prevent routing loops in case of dual-homed CE.

ASN override

If a global ASN is specified, BGP automatically replaces the ASN with a unique number to ensure the site is uniquely identified.

Allow-AS-in

The hub-and-spoke topology widely deployed with VPNv4 is equally useful with VPNv6. This feature enables BGP speakers to accept updates that contain their own ASN in the AS_PATH attribute.

BGP prefix list filtering

Filter MP-BGP IPv6 advertisement based on configured IPv6 prefix.

BGP AS path filtering

Filter MP-BGP IPv6 advertisement based on configured AS path.

BGP max prefix

Upper limit on the number of BGP routes learned from a given CE.

BGP route refresh

Using this technique, a MP-BGP speaker (PE/CE) can request another BGP speaker to resend its MPBGP updates.

Route target rewrite at AS boundary

Allows rewrite of RT values at AS boundary for inter-AS operations.

BGP multipath

Support eBGP multipath, iBGP multipath, eiBGP multipath and DMZ-link-bandwidth-based load balancing.

Topology Examples

273

Topology Examples This section provides VPNv6 topology examples and relevant configurations. The first one is a CE-based VPNv6 example; the remaining examples are PE-based BGP-MPLS IPv6 VPN topologies, starting with a basic topology, then moving forward to more complex cases such as dual-stack VPNs, route reflectors, hub and 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 an IPv6 manually configured. Figure 7-7 illustrates the relevant topology. Multiprotocol VRF Customer Network Site 1

Customer Network Site 2

2001:100:1::1000::/56

2001:100:1::2000::/56

9.200.17.1

MP-eBGP Session Address-Family IPv4

9.100.27.2

2001:100:2:1000::72a/64

CE2 9.100.27.1

CE1

IPv4 Network (ospfv2, ...)

PE1

P2

2001:100:2:1000::72e/64

9.200.17.2

Figure 7-7

PE2

IPv6 in IPv4 IPsec Tunnel

MP-iBGP Session Address-Family IPv6

IPv6 Over IPv4 IPsec Tunnel

Example 7-14 shows CE1’s (Figure 7-7) configuration. The key elements of the configuration are preceded by highlighted comments. Example 7-14 IPv6 over IPv4 IPsec Tunnel Configuration hostname CE1 ipv6 unicast-routing ipv6 cef !IPsec configuration for the IPv4 tunnel crypto isakmp policy 1 authentication pre-share

continues

274

Chapter 7: VPN IPv6 Architecture and Services

Example 7-14 IPv6 over IPv4 IPsec Tunnel Configuration (Continued) group 2 crypto isakmp key SECRET address 10.1.1.2 crypto 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 tunnel interface 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 ! 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 traffic access-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 MPLS backbone. Figure 7-8 shows the steps necessary to design and configure the MPLS IPv6 VPN in the provider network.

Topology Examples

Figure 7-8

275

Steps for Configuring the Provider Routers to Enable MPLS VPNv6 Step 1: Configure PE-P and P-P Routing and Label Distribution

Site1

Site2 CE1

PE1

P

PE2

CE2

Step 2: Design and Configure VRFs Step 3: Design and Configure PE-PE Routing Step 4: Design and Configure PE-CE Routing

Step 1 focuses on configuring the core MPLS network. This is not needed if the core network already runs MPLS to provide VPNv4 service. For details on how to set up an MPLS network, refer to the book MPLS and VPN Architectures. Step 2 is driven by the customer needs and requirements. Typically, a new customer triggers the design and configuration of one or more VRFs per PE routers facing customer sites. The VRF configuration is essentially a matter of network design, similar to what is involved in configuring VRFs for VPNv4. VRF design is an important part of a migration scenario for those SPs that want to offer a VPNv6 service to their VPNv4 enterprise customers. Dualstack VPNs are covered in a subsequent topology example, and the migration scenario 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 three VPNs are designed (VPN-A, VPN-B and VPN-C).

276

Chapter 7: VPN IPv6 Architecture and Services

Figure 7-9

Basic VRF Configuration

vrf site1 rd 100:1 address-family ipv6 route-target export route-target import vrf site2 rd 100:2 address-family ipv6 route-target export route-target import route-target import route-target export

100:1 100:1

P2

P1 100:2 100:2 100:1 100:1

200.11.11.1

PE1

VRF for Site1 Site1 Routes Site2 Routes

PE2

vrf site3 rd 100:2 address-family ipv6 route-target export route-target import route-target import route-target export vrf site4 rd 100:3 address-family ipv6 200.10.10.1 route-target export route-target import

VRF for Site3 Site2 Routes Site3 Routes Site4 Routes

VRF for Site2 Site1 Routes Site2 Routes Site3 Routes

100:2 100:2 100:3 100:3

100:3 100:3

VRF for Site4 Site3 Routes Site4 Routes

CE1

VPN-C

Site1

VPN-A

Site2

2001:100:1:1000::/56

2001:100:1:2000::/56

CE2 Site3

VPN-B

2001:100:1:3000::/56

Site4 2001:100:1:4000::/56

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 core network is IPv4 based, and the iBGP peer endpoints are IPv4 loopback (/32) addresses, configured at each PE and distributed by the IGP (OSPF, for instance) inside the provider network. Example 7-15 illustrates the relevant configuration at PE1 (Figure 7-9). Example 7-15 BGP VPNv6 Peering Configuration hostname PE1 interface Loopback0 ip address 200.11.11.1 255.255.255.255 ! router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 ! address-family vpnv6 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended exit-address-family

Step 4 involves configuring routing between the PE and the CE. The simplest option is to configure static routes on the PE, using the ipv6 route command. With this command, you have the option of specifying the VRF in which it applies, as well as the next hop. You have several options when choosing the next hop:

•

A VRF interface: ipv6 route vrf site1 2001:100:1:1000::/56 serial 0/0

Topology Examples

•

277

A next -hop address in the same VRF as the route being configured: ipv6 route vrf site1 2001:100:1:1000::/56 2001:100:1:1000::72a

•

A next-hop address in a different VRF: ipv6 route vrf site2 2001:100:1:1000::/56 2001:100:2:1000::72a nexthopvrf site3

Static routes are useful in deployments that involve stub sites—that is, sites with only one access interface to the SP. After static routes have been configured at the PE, they must be redistributed into MP-BGP, using the redistribute command shown in Example 7-16. Example 7-16 Redistributing Static Route into BGP VRF hostname PE1 router bgp 100 address-family ipv6 vrf site1 redistribute static

Another option is to use eBGP between the PE and the CE. This option is attractive because all routes learned from the PE are automatically redistributed to remote PEs and then to CEs participating in a given VPN. In the example shown in Figure 7-9, with four sites and three VPNs (VPN-A, VPN-B and VPN-C), you must configure the address family IPv6 for each VRF (site1 and site2 at PE1, site3 and site4 at PE2). Example 7-17 illustrates BGP configuration on PE1. Example 7-17 Using eBGP on the PE-CE Interface router bgp 100 address-family ipv6 vrf site1 neighbor 2001:100:1:1000::72a remote-as 65001 ! address-family ipv6 vrf site2 neighbor 2001:1001:2000::72a remote-as 65002

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 static routes, and route redistribution between this IGP and eBGP. Example 7-18 illustrates the corresponding eBGP configuration on CE1 at site1. Example 7-18 eBGP Configuration Example at CE hostname CE1 router bgp 65001 neighbor 2001:100:1:1000::72b remote-as 100 address-family ipv6 neighbor 2001:100:1:1000::72b activate redistribute ospf 1

278

Chapter 7: VPN IPv6 Architecture and Services

Dual-Stack VPNs Dual-stack VPNs are likely to be predominant in many of the MPLS IPv6 VPN deployment scenarios. As defined earlier, a dual-stack VPN connects IPv4-enabled sites together and IPv6-enabled sites together. In a typical deployment scenario, an MPLS SP will have to enable IPv6 on already-deployed IPv4 VPNs because existing customers will have migrated some or all of their sites to dual stack (IPv4 and IPv6). In such a scenario, 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 (including specific 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 Dual-Stack Network

Dual-Stack Network

Site2

Site1 2001:100:1:1000::/56 10.101/16

2001:100:1:2000::/56 10.201/16

CE1

Dual Stack Server

CE2

MP-eBGP Session Address-Family IPv4 Address-Family IPv6

MP-eBGP Session Address-Family IPv4 Address-Family IPv6

Dual-Stack ipv4 addresses: 10.100/16 ipv6 addresses: 2001:100:1:1000::/64

VRF Red

P1

P2 VRF Red

PE1 PE2 VRF Address-Family IPv4 Address-Family IPv6

iGP-v4 (OSPF, ISIS) LDP-v4

MP-iBGP Session Address-Family VPNv4 Address-Family VPNv6

Dual stack VPN

Topology Examples

279

Example 7-19 illustrates the BGP configuration of a dual-stack VPN (IPv6-related configuration highlighted). Example 7-19 BGP Configuration of Dual-Stack VPN hostname PE1 router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 address-family ipv4 vrf site1 neighbor 10.100.1.1 remote-as 100 neighbor 10.100.1.1 activate ! address-family ipv6 vrf site1 neighbor 2001:100:1:1000::72a remote-as 100 neighbor 2001:100:1:1000::72a activate ! address-family vpnv4 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended ! address-family vpnv6 neighbor 200.10.10.1 activates neighbor 200.10.10.1 send-community extended

And Example 7-20 shows the VRF configuration. Example 7-20 Configuration Example of Dual-Stack VRF vrf definition site1 rd 100:1 route-target import 100:1 route-target export 100:1 address-family ipv4 address-family ipv6 ! interface serial0/0 vrf forwarding site1 ip address 10.100.1.2 255.255.0.0 ipv6 address 2001:100:1:1000::72b/64

Route Reflectors Route reflectors are discussed in the “Scaling IPv6 VPN” section. Figure 7-11 shows a simple topology with route reflectors.

280

Chapter 7: VPN IPv6 Architecture and Services

Figure 7-11 Route Reflectors Topology

Route-Reflectors Topology 200.12.12.1

RRs CE1

200.11.11.1

P1

P2

200.10.10.1

CE2

Site1

Site2 VRF Red

MP-eBGP session Address-Family IPv6

PE1

PE2 VRF Red MP-eBGP session Address-Family IPv6 MP-iBGP session Address-Family VPNv6

Example 7-20 is an example of route reflector configuration. Example 7-21 Route Reflector Configuration Example router bgp 101 no bgp default route-target filter neighbor 200.11.11.1 remote-as 101 neighbor 200.10.10.1 remote-as 101 neighbor 200.11.11.1 update-source Loopback0 neighbor 200.10.10.1 update-source Loopback0 address-family vpnv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 route-reflector-client neighbor 200.11.11.1 send-community extended neighbor 200.10.10.1 activate neighbor 200.10.10.1 route-reflector-client neighbor 200.10.10.1 send-community extended

Note that no bgp default route-target filter command is necessary on the route reflector, because it does not maintain a VRF table (unless it is also a regular PE), and would not keep any entry otherwise, as described in the “Scaling IPv6 VPN” section. Another remarkable element of the preceding configuration is that neither the IPv6 address nor IPv6 routing protocol 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 is still 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 no reason why it should not be the same with VPNv6. Large

Topology Examples

281

corporations, with multiple sites distributed across the 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 this topology. Figure 7-12 Hub-and-Spoke Topology 2001:100::/56

Site1

AS200 200.14.14.1

14

Hub-and-Spoke Topology

London-CE MP-eBGP Session Address-Family IPv6

2001:100::/64

Hub-Site

AS100

AS400 MP-iBGP Session Address-Family VPNv6

200.11.11.1

200.16.16.1

Paris-CE-Hub

2001:2006::/64 40.1.1/24 11 London-PE-Spoke

Nice-PE-Spoke

200.10.10.1 42.1.1/24

13 P

10 Paris-PE-Hub 2001:2005::/64

17

MP-iBGP Session Address-Family VPNv6

200.17.17.1

16

200.15.15.1 2001:2001::/64

15 Paris-CE-Spoke

2001:201::/56

Nice-CE

IPv6 Internet 18

200.18.18.1

2001:201::/64

Site2

AS300 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 site address-family vpnv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 send-community extended neighbor 200.17.17.1 activate

continues

282

Chapter 7: VPN IPv6 Architecture and Services

Example 7-22 BGP VPNv6 Hub-and-Spoke Configuration Example (Continued) 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

As shown in Example 7-23, a traceroute command, initiated at one of the spoke sites (London-CE), shows the path used by traffic between spoke sites (the hops are highlighted). Example 7-23 Traceroute Output Throughout the Hub-and-Spoke Topology London-CE#traceroute 2001:201::1 1 London-PE-spoke 2001:100::11 2 P ::FFFF:40.1.1.13 [MPLS: Labels 16/36 Exp 0] 3 Paris-PE-hub 2001:2006::10 [AS 100] [MPLS: Label 36 Exp 0] 4 Paris-CE-hub 2001:2006::16 [AS 100] 5 Paris-CE-spoke 2001:2001::15 [AS 400] 6 Paris-PE-hub 2001:2005::10 [AS 400] 7 P ::FFFF:42.1.1.3 [MPLS: Labels 17/25 Exp 0] 8 Nice-PE-spoke 2001:200::17 [AS 100] [MPLS: Label 25 Exp 0] 9 Nice-CE 2001:200::18 [AS 100]

Note that P-routers have not been configured with an IPv6 address and must use an IPv4mapped 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 section 11 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 Internet and a different one to connect to the VRF. In model 4 of section 11, all Internet routes are redistributed into the 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 Internet gateway, found in the IPv6 default table. Figure 7-13 shows a scenario in which Internet access is provided to the customer in VRF red based on model 3.

Topology Examples

283

Figure 7-13 Internet Access Topology Site1 2001:100:1:1000::/56

CE1 2001:700::/64 2001:100:1:1000::/64 MP-eBGP Session Address-Family IPv6

Internet

MP-iBGP Session Address-Family IPv6 + Label

P1

IGW

P2

MP-iBGP Session Address-Family IPv6 + Label

VRF Red PE2 200.11.11.1

PE1

iGP-v4 (OSPF, ISIS) LDP-v4

200.14.14.1 2001:BEEF:14::1

VRF Red CE2

Site2 2001:100:1:2000::/56

200.10.10.1

SP-Backbone MP-iBGP Session Address-Family VPNv6

Internet-Access Topology For outbound traffic, the default route configured in the VRF table (red) at PE1 directs traffic for destinations outside 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 running ipv6 route vrf red ::/0 2001:BEEF:14::1 nexthop-vrf default PE1#show ipv6 route vrf red S ::/0 [1/0] via 2001:BEEF:14::1%default The next hop (2001:BEEF:14::1) is in the default routing table: PE1#show ipv6 route B 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.

284

Chapter 7: VPN IPv6 Architecture and Services

Example 7-25 Internet Access: (Internet Gateway) BGP Configuration IGW#show running router bgp 100 address-family ipv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 send-label network 2001:BEEF:14::1/128

For inbound traffic, a route must exist at the Internet gateway to direct the traffic for customer site (site1 in Figure 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. Example 7-26 Internet Access: (Internet Gateway) Route to the PE IGW#show ipv6 route IPv6 Routing Table - default - 6 entries B 2001:100:1:1000 ::/56 [200/0] via 200.11.11.1%Default-IP-Routing-Table, indirectly connected

This route can be distributed by PE1, via MP-iBGP (IPv6 address family), so no specific configuration needs to be done on per-VPN PE basis at the Internet gateway. Nevertheless, for inbound traffic at PE1, a route must exist 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 PE1#show running ipv6 route 2001:100:1:1000::/56 2001:100:1:1000::72a/64 nexthop-vrf red PE1#show ipv6 route IPv6 Routing Table - default - 5 entries S 2001:100:1:1000::/56 [1/0] via 2001:100:1:1000::72a%red

Example 7-28 shows the BGP configuration for PE1. 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

Topology Examples

285

Interprovider VPNs The challenge with interprovider VPNs is similar for IPv6 and IPv4, assuming IPv6 is deployed everywhere IPv4 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 shows the interprovider scenarios (A, B, and C, specified in draft-ietf-l3vpnrfc2547bis, section 10) in the VPNv6 case. Figure 7-14 Interprovider Scenarios

Inter provider VPN Scenario A Carrier Backbone Running IGP and LDP

Carrier Backbone Running IGP and LDP

ASBR1 PE1

ASBR2 PE2

sub-int1: vrf blue

VRF Blue

VRF Blue

P1

P2

MP-eBGP for IPv6

MP-iBGP for VPN-IPv6

MP-iBGP for VPN-IPv6

Scenario B Carrier Backbone Running IGP and LDP

ASBR1

Carrier Backbone Running IGP and LDP

ASBR2

40.1.1/24 2001:101::/64

PE1

PE2

VRF Blue

200.10.10.1

P1

CE1 200.11.11.1

VRF Blue MP-eBGP for VPNv6

RR1

CE2

MP-iBGP for VPN-IPv6

MP-iBGP for VPN-IPv6

Scenario C

P2

RR2

MP-eBGP for VPNv6 Nexthop Unchanged

5.5.5.5

2.2.2.2

ASBR1

MP-iBGP for VPN-IPv6 3.3.3.3

PE1 VRF Blue

MP-iBGP w/label

10.1.1.1 1.1.1.1

PE2

ASBR2

VRF Blue

90.1.1.2 90.1.1.1

P1

4.4.4.4 MP-eBGP w/label

10.1.1.2

MP-iBGP for VPN-IPv6

MP-iBGP w/label

P2

7.7.7.7

2001:2::/64

286

Chapter 7: VPN IPv6 Architecture and Services

Depending on the network protocol used between ASBRs, the three scenarios described in draft-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. The following 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 !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 shown in Example 7-30. Example 7-30 Inter-AS BGP Configuration, Scenario B, ASBRs Peering over IPv6 router bgp 1001 neighbor 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 different autonomous systems. Labeled IPv4 routes to the PEs (in the 6VPE case) need to be advertised across ASBRs so that a complete LSP is set up end to end. Figure 7-15 shows inter-AS scenario C, both routing and forwarding paths. 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

Topology Examples

287

Figure 7-15 Inter-AS Scenario C CE2

PE1

RR1

10.1.1.2

P1

ASBR1

ASBR2

P2

RR2

PE2

CE2

90.1.1/24 1.1.1.1

2.2.2.2

3.3.3.3

4.4.4.4

5.5.5.5

7.7.7.7

2001:201::/64

[net, CE1] eBGP IPv6

[net, PE1, L1] [net, PE1, L1] iBGP VPNv6

[net, PE1, L1]

eBGP VPNv6 iBGP VPNv6

[PE1, PE1, La] LDP+OSPFv2 LDP+OSPFv2

[net, PE2] eBGP IPv6

[PE1, P1, Lb] [PE1, ASBR1, L2] [PE1, ASBR2, L3] eBGP IPv4 w/label iBGP IPv4 w/label

[PE1, ASBR2, L3]

[ASBR2, ASBR2, Lc]

iBGP IPv4 w/label [ASBR2, P2, Ld]

LDP+OSPFv2

Routing

LDP+OSPFv2 IPv6 Packet [net] Ld, L3, L1, IPv6 Packet L3, L1, IPv6 Packet L2, L1, IPv6 Packet Lb, L1, IPv6 Packet L1, IPv6 Packet

IPv6 Packet

Forwarding

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) pe1#show ipv6 cef vrf blue 2001:201::/64 nexthop 10.1.1.2 Serial0/0 label 20 19 22

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::/64 BGP routing table entry for [200:1]2001:201::/64, version 4 Paths: (1 available, best #1, table blue) Not advertised to any peer 200 65502

continues

288

Chapter 7: VPN IPv6 Architecture and Services

Example 7-32 Inter-AS: Looking at Bottom (BGP VPNv6) Label (Continued) ::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 system boundary.

Example 7-33 Inter-AS: Looking at Middle (BGP IPv4) Label PE1#show bgp ipv4 unicast 7.7.7.7 BGP routing table entry for 7.7.7.7/32, version 10 Paths: (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 PE1#show mpls ldp bindings 90.1.1.2 32 lib entry: 90.1.1.2/32, rev 16 local binding: label: 21 remote binding: lsr: 30.1.1.2:0, label: 20

Finally, it is possible to understand the recursion process by analyzing in detail the way Cisco Express Forwarding (CEF) has built the label stack, as shown in Example 7-35. Example 7-35 Inter-AS: Label Stack Recursive Resolution PE1#show ipv6 cef vrf blue internal 2001:2::/64, epoch 0, RIB sources: RIB recursive via 7.7.7.7 label 22 recursive 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 and VPNv4. Almost every topology found in the VPNv4 world has a

Topology Examples

289

correspondence in the VPNv6 world. The reverse 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 configuration examples from this chapter into a complete, end-to-end IPv6 deployment case study.

CHAPTER

8

Advanced Services— IPv6 Mobility From game consoles to IP phones, billions of new devices are becoming IP enabled, requiring a larger addressing 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. Initially available to the military and specific verticals such as the police, radio data communication is becoming widely 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 couple their 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 larger mesh networks to provide low-cost, highbandwidth connectivity to all citizens. The continuous connectivity facilitates the emergence of a new breed of applications: push services such as stock alerts and sport results, peer-to-peer services such as multimedia messaging, and voice integration. But for an ISP to deliver these applications, the user must be always reachable at the same network identifier regardless of its point of attachment. IP mobility and IPv6 are designed to respond to this requirement. Coupling the two appears to be an even better idea. Because Neighbor Discovery (ND) has the built-in mechanisms for faster movement detection and address autoconfiguration, IPv6 is significantly better positioned with respect to mobility than IPv4. IPv6 is the keystone to elaborate on this new service model, and, in return, mobility is one of the drivers for making IPv6 a deployment reality.

292

Chapter 8: Advanced Services—IPv6 Mobility

Chapter Overview When a node changes its location, not only does it change its links, but most often, it also changes its network of attachment and, as a consequence, its IP address, too. The mechanisms that exist in IPv4 and IPv6 for a node to automatically obtain a new address cannot prevent existing connections to be terminated when the node moves. A mobile node is an Internet-connected device whose location and point of attachment to the Internet may change 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 network while 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 rapidly evolving technology. It also presents its current trends and potential deployment opportunities. From “Internet car” to “fleet in motion,” from “personal network” to “home network,” deployment experiments of IPv6 mobility carry so many promises that one can expect this technology to become a key enabler for IPv6 success in the near future (see the “Practical Use Cases” section of this chapter for details on these examples). This chapter explores IP mobility starting from the established standards to a vision of pervasive computing and networking. The following topics are covered in respective sections:

•

The “IP Host Mobility” section reviews Mobile IPv6 technology, as well as current IP mobility limitations and challenges.

•

The “Network Mobility” section reviews network mobility, and presents a set of deployment examples, mostly technology experiments and previews.

•

The “IP Mobility in Nonmobile Scenarios” section covers areas where the technology can be used outside the mobility context, such as for hiding the topology of a private network, or building communities of interest.

•

The “Next Steps in Mobility” section covers improvements being currently discussed at the standards bodies, such as fast movement detection, and finishes with a short description of the pervasive computing vision.

IP Host Mobility A wide consensus exists in the industry and at the standards bodies that IP mobility will better scale through the IPv6 adoption. On one hand, millions if not billions of roaming devices, from handhelds to phones and multimedia players, require more addressing capability than IPv4 can provide. On the other hand, the Internet can now be reached from any location, including automobiles, trains, airplanes, boats, and so on. This is enabling a

IP Host Mobility

293

new set of peer-to-peer applications, which disqualify Network Address Translation (NAT) as the usual workaround for IPv4 address depletion. Does that mean IPv6 is ready for large-scale IP mobility deployment? While a number of experiments and trials are being tested today, many areas remain work in progress, whether at standards, products, or applications level.

Mobile IPv4 in a Nutshell Mobile IPv4 (MIPv4), specified in RFC 3344, provides a network-level indirection to the actual location of a mobile 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), a correspondent node reaches the device at its permanent Home Address (HoAddr). The indirection is maintained by a home agent that intercepts all the packets destined to the HoAddr of the mobile node and tunnels them to the CoA that the mobile node acquires locally at its new location. For details on MIPv4, we recommend 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, leaving room for future work and improvements. Some of these unresolved issues (fast movement detection and handoff, home discovery, initial bootstrap configuration, and so on) are now addressed in the MIPv6-related working groups. MIPv4 operations imply a triangular routing—the so-called dogleg issue. The flows toward the mobile node are routed via its dedicated home agent, although only the return path is direct. The home agent is therefore a potential single point of failure for MIPv4 operations and a bottleneck for the forward traffic, which experiences additional latency and increased path length. Another issue with MIPv4 is the requirement for a pervasive deployment of foreign agents, for movement detection 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 this path are not tunneled, the mobile node HoAddr is used as source IPv4 address in all packets. This address is not topologically correct during a portion of the packet journey (until it leaves the foreign network). The packet 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 address outside the internal subnet range to be forwarded. These limitations can be alleviated with the optional support of reverse tunneling and collocated CoA by the mobile node. These improvements to the basic MIPv4 are the default behavior in the case of IPv6 mobility.

294

Chapter 8: Advanced Services—IPv6 Mobility

Mobile IPv6 Note that even though IETF MIPv4 working group is still active, a lot of the mobilityrelated work in the standards bodies happens in the context of IPv6. 3GPP2 and 4G telephony standards are considering the use of MIPv6, and vehicular consortiums worldwide (Car2Car in Europe, InternetCar in Japan) have adopted IPv6 for car-to-car communication. Initially, MIPv6 was published as RFC 3775 and RFC 3776. RFC 3775 describes IPv6 mobility for mobile nodes, more specifically mobile hosts. RFC 3776 specifies the use of IP security in the context of RFC 3775. Figure 8-1

MIPv6 Operations CN, Correspondent Node Destination IP host in session with a Mobile Node

Without Optimization

With Optimization

Internet

HA, Home Agent Maintains an association between the MN’s “home” IP address and its Care of Address on the foreign network

MN, Mobile Node An IP host that maintains network connectivity using its “home” IP address, regardless of which link (or network) it is connected to

MN

Mobile IPv6 Operation Overview A MIPv6 mobile node registers with a home agent and establishes a bidirectional tunnel. One endpoint of the tunnel is fixed at the home agent address. The other endpoint of the tunnel is located at the mobile node CareOf Address (CoA), and it changes as the mobile node roams. The association between the HoAddr of a mobile 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. As opposed to MIPv4, the tunnel between the mobile node and the home agent is bidirectional, and the return path is also through the home agent. This ensures the topological correctness of all flows, to avoid any conflicts with ingress filtering deployed in the IPv6 Network.

IP Host Mobility

295

RFC 3775 also describes the process of route optimization (RO) between the mobile node and the correspondent node. RO can only work between a MIPv6 mobile node and a MIPv6 correspondent node that support the feature in their IPv6 stacks. When RO is established, packets are tunneled directly between the correspondent node and the mobile node in both directions. Figure 8-1 shows the MIPv6 operations. 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 home agent must be connected to the home link to operate. It is critical for security reasons that the link be protected from a rogue access.

A mobile node is provisioned with the home prefix, and a HoAddr on that prefix. The HoAddr is the index for MIPv6 bindings. It is also a valid address on the home link, that the mobile node uses when it connects to the home link. The mobile node is also provisioned with initial security tokens to prove its identity when establishing bindings.

IPv6 Mobility Header MIPv6 was designed as an extension of IPv6. It takes full benefit of the IPv6 packet structure as defined in RFC 2460, creating a new extension header (the Mobility header), a new destination option (the HoAddr option), and a new Routing header (RH type 2). MIPv6 also proxies the Neighbor Discovery Protocol on the home link, with the benefit of being independent from the data link layer technology. Finally, four ICMPv6 messages 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 (Mobile Prefix Solicitation/Advertisement). Figure 8-2 shows the layout of the Mobility header. Figure 8-2

Mobility Header Next Header = 135 Mobility Header

Previous Header Mobility Header

Mobility Header Next Header = 59 Hdr Ext Length Checksum

MH Type

Message Data

Reserved

296

Chapter 8: Advanced Services—IPv6 Mobility

The Mobility header is an extension header used by mobile nodes, correspondent nodes and home agents in all messaging related to the creation and management of bindings. Binding messages all use the Mobility header and do not convey any upper-layer information. The Mobility header appears in two different flows, the binding flow, and the return routability (RR) procedure that secures the MIP route optimization. The Mobility Header Type field identifies the particular mobility message:

•

Home Test Init message (type=1)—A mobile node uses the Home Test Init (HoTI) message to begin the RR procedure and request a Home keygen token from a correspondent node. The keygen token is a number that the correspondent node supplies to enable the mobile node to compute the necessary binding 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 begin the 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 Init message 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 Init from the correspondent node to the mobile node.

•

Binding Refresh Request message (type=0)—The correspondent node sends a BReq to request a mobile node to update its mobility binding.

•

Binding Update message (type=5)—The Binding Update (BU) message is used by a mobile node to notify other nodes of its new CoA.

•

Binding Acknowledgment message (type=6)—The Binding Acknowledgment (BA) is used to acknowledge receipt of a Binding Update.

•

Binding Error Message (type=7)—The Binding Error (BErr) message is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt, to use the HoAddr destination option without an existing binding.

To register, the mobile node sends a signed unicast Binding Update to the home agent, specifying its HoAddr and its CoA. To accept a new binding, the home agent must ensure that the address is not already bound to another home agent, 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 Binding Acknowledgement back to the mobile node. Because of the DAD process, the initial binding might take more then 2 seconds to complete. It is not recommended to use such procedures as Optimistic DAD to improve that initial latency if the HoAddr is configured to the mobile node. Note that additional bootstrap mechanisms are being elaborated at IETF to allow the dynamic provisioning of the mobile node. Upon accepting the first Binding Update, the home agent allocates a binding cache entry indexed by the mobile node HoAddr and sets up a tunnel to the mobile node CoA. The

IP Host Mobility

297

mobile node uses the Binding Update message to maintain the tunnel. It is sent periodically, as a keepalive mechanism, and asynchronously when the 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 type 201). The HoAddr destination option is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node’s HoAddr. The receiving stack at the home agent will swap the source of the packet with the address in the destination option. As a result, the rest of the processing of the packet happens 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 configuration dynamically; this is called the bootstrap problem, currently considered at IETF. On the other hand, RFC 3775 specifies an Internet Control Messaging Protocol (ICMP) flow for a mobile node to discover which home agent(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 a suffix reserved for that purpose by RFC 2526. The anycast address is then used as destination for the DHAAD request. Figure 8-3 shows the DHAAD flow. Figure 8-3

DHAAD Flow CN

HA

Internet

Home Agent Address Discovery Request sent to Home Agents Anycast address of its own home subnet prefix.

MN

Home Agent Address Discovery Reply.

MN

298

Chapter 8: Advanced Services—IPv6 Mobility

The home agents discover each other on the home link using an extension to the Neighbor Discovery Protocol. One of them receives the DHAAD request, and answers with a DHAAD reply that carries an ordered list of home agents. Note that the computation of the order of that list is not standardized, and that it can 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 will be 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 correspondent node. RO bypasses the home agent, at the expense of an additional tunnel, mobile node to correspondent node. It cannot be expected that in the general case, any potential mobile node and correspondent node pair will share some form of trust model (such as a Public Key Infrastructure or a shared secret). To provide minimum security, the MIP6 working group designed a lightweight mechanism that allows the correspondent node 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 completed before the mobile node can bind directly with the correspondent node. The mobile node sends two queries to the correspondent node, one directly from its CoA (the CoTi), and one via the home agent (the HoTi), from its HoAddr. The correspondent node responds to both over the incoming path. Each response carries a half of the key that, when complete, will be used by the mobile node to sign its binding and securely establish an RO tunnel with the correspondent node. The RR test is fully stateless on the correspondent node side, and relies on the fact that the mobile node to home agent tunnel is secured. Figure 8-4 shows the RO forwarding path. Although only a subset of all IPv6 nodes on the Internet will implement it, the RO mechanism is essential for the scalability of MIPv6 operations. It is expected to reduce or avoid congestion in the home network, and therefore to enable the use of low-end home agent equipment. In addition, it should reduce the load across the Internet and improve jitter and latency of communications. This is the reason why it was incorporated in the MIPv6 base specification, RFC 3775. However, RO does not come for free: It introduces additional states in the correspondent node, additional messages between the correspondent node and the mobile node, and requires specific MIPv6 support by the correspondent node, that will not be found in early IPv6 stacks and might 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.

IP Host Mobility

Figure 8-4

299

Route Optimization for MIPv6 Packets from CN are routed directly to the CoA of MN. CN checks its binding cache for the packet's destination address. If an entry is found, CN uses IPv6 RH type 2 to route the packet to the MN.

CN Home Link

Internet Home Agent

Traffic is going through HA until the Return Routability procedure is performed. Signalling via HA, and Home Registrations still keep HA informed.

MN When routing packets directly to CN, MN sets the Source Address in the packet's IPv6 header to its current CoA. MN adds an IPv6 “Home Address” destination option to carry its home address.

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 prove the 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 Updates—both to home agents and correspondent nodes. This is achieved by use of IPsec extension headers, or by the use of the Binding Authorization Data option. This option employs a binding management key, Kbm, which can be established through the RR procedure.

• •

Protection of mobile prefix discovery—through the use of IPsec extension headers. Protection of the payload packets—The mechanisms related to transporting payload packets such as the HoAddr destination option and type 2 routing header have been specified in a manner that restricts their use in attacks. Restrictions are the following: — The HoAddr destination option can be used only when a correspondent node already has a binding cache entry for the given HoAddr. — The mobile node verifies that the outer IP address corresponds to its home agent.

300

Chapter 8: Advanced Services—IPv6 Mobility

— The home agent verifies that the outer IP address corresponds to the current location of the mobile 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).

NOTE

An alternate mechanism (draft-ietf-mip6-auth-protocol: “Authentication Protocol for Mobile IPv6”) is being discussed at the time of this writing in the IETF, for specific situations, such as 3GPP2, where IPsec is too complex 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 ND extensions and proxying on that link. The home network is subnet on that link. MIPv6 is therefore a link-centric technology. Each mobile node must be provisioned with a home network prefix, its own HoAddr, and some security tokens 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 and use 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 takes any given binding, it is likely that over time all the home agents will end up storing some information about all the active mobile nodes, at least in their ND neighbor caches. Neighbor caches and binding caches are not exactly comparable because Neighbor caches can be flushed, as opposed to binding caches, 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 the home link fails, the home agent operations stop, even for existing flows between correspondent nodes and mobile nodes with an active binding.

IP Host Mobility

301

When the mobile node roams far away from home, the round-trip delay creates a window of time between the movement and the updating of the tunnel on the home agent side. During that window, packets are sent to the old CoA and cannot be delivered. Local Mobility Management (LMM) can reduce the binding latency and the loss of packets, at the expense of deploying additional, distributed agents in all regions. A LMM agent hides the 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 a regional LMM solution that hides the MN movement from the home agent. A NETLMM working group has formed at the IETF to standardize a local solution that hides the MN movement from the MN itself. Note that specific support might be required in the mobile node for LMM purposes. Also, mobility and wireless connectivity fit well together. A widely available broadband wireless network access is required for IP mobility to take off. Such a service might take place with the emerging trend of mesh networking. A mesh network combines wireless communication (such as WLAN and WWAN) and some ad-hoc self-forming and self-healing technology to build a multi-hop radio network that extends the reach of traditional access points. As a result, mesh networking simplifies and reduces the cost of wireless access networks deployments, enabling new operators such as municipalities to offer citywide broadband services. A number of radio technologies are being developed or deployed around us. Handling mobility at layer 3 enables 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 multiple types of interfaces, and should provide the means for the upper layers to select the best access at any point of time 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 expected that 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 RFC 3775 and is available commercially starting with 12.3(14)T and 12.4 releases. It has been demonstrated in technology previews, and the following example illustrates one of these previews. Figure 8-5 presents the MIPv6 example operations.

302

Chapter 8: Advanced Services—IPv6 Mobility

Figure 8-5

MIPv6 Example MP3 Client (MN) AP2

Ethernet-2 Client moving from AP1 to AP2

Ethernet-1 Home Agent

AP1 MP3 Jukebox (CN) MP3 Client (MN)

The following elements are identified in Figure 8-5:

• • • •

The home agent is a Cisco router, with IOS MIPv6 support per RFC 3775.

•

The network infrastructure uses Cisco WiFi access point.

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.

Example 8-1 shows the configuration of the router in Figure 8-5. Example 8-1 MIPv6 Home Agent Configuration Example Router1#show running ipv6 unicast-routing interface 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 interface ethernet1 ipv6 address 2001:0002::45a/64 ipv6 address 2001:0002::fdff:ffff:ffff:fffe/64 anycast ipv6 mobile home-agent

IP Host Mobility

303

The command ipv6 mobile home-agent enables the home agent operation on the interface. By default, the home agent operation is disabled. To support DHAAD, the configuration of the anycast address is required, too. The command ipv6 mobile home-agent access configures a binding update filter using an access control list (ACL). When an ACL is configured, all received binding updates are filtered. This feature can be used to deny home agent services to mobile nodes that have roamed to particular subnetworks. When the filter blocks a 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 applied to DHAAD messages. When blocked, these are silently discarded. In ACL configuration, the source is the CoA 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 IPv6 Cisco Express Forwarding (CEF) switching path. As far as the authentication, Cisco IOS Software will implement an MD5 Lightweight authentication (and IPsec 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 to match 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 security holes where “everything” has to be wide open for the home agent MIPv6 operation to be allowed. The following list provides some examples on how this enhancement can be used: 1 ICMPv6 message types:

Only ICMPv6 DHAAD request messages between the pair of specified host addresses will be permitted. ipv6 access-list List1 permit ipv6 host 2002:100::150 host 2002:100::153 dhaad-request deny ipv6 any any

2 Mobility header:

Only traffic between the pair of specified hosts, with a mobility header, will be permitted. ipv6 access-list List2 permit ipv6 host 2002:100::160 host 2002:100::161 mobility deny ipv6 any any

304

Chapter 8: Advanced Services—IPv6 Mobility

3 Routing header:

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

4 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

Network Mobility Current MIPv6 deals with mobile hosts as opposed to IP nodes, which include routers. Moving routers around also 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 whole network; the mobile network nodes (MNNs) attached to a NEMO benefit transparently from that support and keep 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 the topology. The mobile network includes one or more mobile routers (MRs) which connect it to the 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. When deployed, the whole network operates the same as it did at configuration time and it is reachable at the same (home) addresses. For instance, surveillance cameras can be fully checked and integrated with the management screens before they are sent to the remote location.

•

Deployment is totally plug and play. Benefiting from IPv6 ND, the mobile router discovers its environment, autoconfigures a CoA, and registers home on behalf of the full network. This proves particularly useful when the installer is not highly skilled in networking and/or not trained to configure 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.

Network Mobility

305

Practical Use Cases A number of use cases were envisioned for a network that moves as a whole. The degree of global and relative mobility varies from one case to another, as illustrated in the following examples.

Enterprise on the Move The first usage for network mobility might be a simple extension of the enterprise network to make it reachable 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 gathers and delivers data on the way to and from multiple devices. Three distinct subcases can be identified: 1 Machine to machine. In this case, sensors are deployed in the vehicles, which can

report to, or be polled from base stations. The sensors provide real-time missioncritical information to the back-end control systems. For instance, RFID tags could be used by a trucking company to monitor the delivery of goods to the final customer and the information could be updated in real time on the company website. GPS information can be sent back to follow the truck activity and ensure that it meets the local regulations. Additional sensors can report various engine parameters and when the truck is back at the garage, in depth diagnostics can be run over the high-speed wireless network while microcode updates are being downloaded automatically into the truck-embedded controllers. 2 Content delivery with human interface. In this case, there is a human interaction at

either end of the flow. This could be video distribution, multicast from a station into public transportation such as buses and trains. But, this could also be a set of embarked webcams, used by a transportation company to ensure the security of the bus driver, or by a trucking company to check that the transported goods are not being hijacked while the truck is stopped at along the highway. Examples of mobile clients could be IP appliances such as screens, ticket scanners, and cameras, as well as the IP terminals used for application hosting or data browsing. 3 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 roaming complexity is handled by the router, once and for all, allowing all employees to use any IP device as man-to-machine interface, even a simple, non-MIP-enabled, portable or embedded gizmo. In that model, the device could handle its own security using some VPN software, leaving the mobility to the router, or, alternatively, the mobile router could provide an encrypted tunnel back into the company, saving a level of encapsulation.

306

Chapter 8: Advanced Services—IPv6 Mobility

Home Gateway With the large address space offered by IPv6, it makes sense to imagine that an ISP will delegate a full globally addressable /64 prefix for the home, as opposed to a single public IPv4 as is customary today. And imagine that the ISP providing a globally reachable network at home to a million of households. In each house, the attached devices are reachable from the Internet. Some devices might be monitored by external services (for example, surveillance cameras, fridges, and video servers). They would be known by DNS name or 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,000 networks 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 a mobile network, it is left unchanged as the family moves. For the ISP, network mobility could become a chargeable 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 network as 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 local gaming as well as Internet connectivity. The visitors might want to be reachable using their own HoAddr and therefore manage their own mobility. As a result, the home gateway, which is a mobile router, accepts visitors that are also mobile. This situation results 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 its own tunnel to its own home agent. In a more generic way, there is a need for a model that guarantees anonymity and innocuousness for all parties, for their mutual benefit, and enables large nested configurations with no preexisting trust model, in a titfor-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 power management scheme is available to ensure a usable autonomy to the system, comparable to that of mobile phones today. Figure 8-6 shows a personal-area network. The mobile router needs close-by, low-power connectivity in its environment. It will connect to the home gateway when at home, and then to buses, airports, cars, planes, trains, hotspots, and so on.

Network Mobility

Figure 8-6

307

Personal Area Network

Root Mobile Router

This example creates a nested hierarchy of mobile routers, for instance: PDA > PAN > vehicle > ferry, which is a form of nesting that happens between entities of different types. The degree of nesting is limited by construction to the order of 2 or 3. Each level of hierarchy might be operated by a different service provider, and there is a need for a meta provider (a form of mobile virtual network operator, MVNO) that integrates the services 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 of inter-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 a convoy), 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 a dynamic mesh network, helping each other as community service in a titfor-tat fashion.

308

Chapter 8: Advanced Services—IPv6 Mobility

Figure 8-7 shows an Internet-enabled car network. Figure 8-7

Internet-Enabled Car Network

!

IPv6

IPv6

Mobile Router SOS Emergency HotSpot (Roadside)

IPv6

Mobile Router

As opposed to the previous example, all devices are of a same kind, and the network can reach an arbitrary depth. A typical use case is a traffic jam with hundreds to thousands of cars stalled. Most could be too far from a public access point to communicate. It might be mutually beneficial for all of them to collaborate, to share the radio spectrum and to extend the reach of the APs. Also, a geographically localized broadcast might be useful to 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 and their highly limited capabilities. Sensors are low-cost, mass-produced devices, used to monitor various metrics such as temperature or seismic activity around an area. A “sensor dust” is usually spread over a monitored location, and from that moment on, the sensors are fixed and operate for the lifetime of their batteries, which are their most critical resource. Figure 8-8 shows a sensor network. Around a sensor network, sinks are deployed to collect the measurement from the sensors and relay the commands from the controllers. Therefore, sensors automatically form a structure to forward unicast packets from 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 model reaches its limits because of the operational cost on the batteries and the complexity involved with the networking part.

Network Mobility

Figure 8-8

309

Sensor Network

To form a routing hierarchy and make each sensor much simpler and cheaper, a limited number of mobile routers 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 on planes or drones) to sweep the perimeter, or fixed and well distributed across the monitored location, with a few 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 of relative movement between the vehicles. Classical examples are a truck convoy along a road, vessels at sea, or jeeps in the dunes. Each vehicle owns at least one mobile network.

310

Chapter 8: Advanced Services—IPv6 Mobility

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 local network 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 connectivity independently 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 Mobile Adhoc NETwork (MANET) within the fleet. They might also need a global reach back, in which case some NEMO support is required, too. A smooth integration of the MANET and the NEMO would be needed to optimize 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 to the outside, while ensuring that the local traffic is contained within the fleet.

Network Mobility

311

Object Model and Terminology The SEAMOBY (seamless mobility, for context and micro-mobility routing) and the NEMO terminology documents define all the terms used in the context of these technologies. Here follows a summary of the most important terms:

•

Mobile router—“A router capable of changing its point of attachment to the network, moving from one link to another link. The mobile router is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which it does packet forwarding. A mobile router acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). Packets forwarded upstream to the rest of the Internet are transmitted through one of the mobile router’s egress interface; packets forwarded downstream to the mobile network are transmitted through one of the mobile router’s ingress interface.”

•

Mobile network (NEMO)—“An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed of one or more IP-subnets and is connected to the global Internet via one or more mobile routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the mobile router.” Note that the definition allows a NEMO be a complex structure with routers that are fixed with regards to a moving topology, and one or more mobile router(s) assuming the mobility for all.

•

Mobile network node (MNN)—“Any node (host or router) located within a mobile network, either permanently or temporarily. A Mobile Network Node may either be a fixed node (LFN) or a mobile node (VMN or LMN).” Note that the local fixed node (LFN) is the proverbial “plain” IPv6 node, with no assumed support of MIPv6 or NEMO. In particular, it can be a “fixed” router and mobility is handled by the mobile router. A visiting mobile node handles its own mobility, and as opposed to a local mobile node, it is not homed in this NEMO.

•

Correspondent node—“Any node that is communicating with one or more MNNs. A correspondent node could be either located within a fixed network or within a mobile network, and could be either fixed or mobile.” At this moment, the definition of a correspondent node comes from RFC 3775 because RFC 3963 does not cover RO. In the future, NEMO might require additional support from the correspondent node for its own RO or introduce new concepts in the network such as a correspondent router, which would terminate NEMO on the correspondent side, or a proxy home agent, which would handle 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

312

Chapter 8: Advanced Services—IPv6 Mobility

home agent, establishing a tunnel, and requesting 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 each given 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 Update messages. The home agent must have a way to check whether a mobile router is authorized for a MNP 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 dynamically its MNP as part of its initial configuration (bootstrap). This can also be used in runtime, to get additional persistent 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 a number of aspects:

•

With IPv6 ND and its MIP adaptations, roaming is an order of magnitude quicker than with IPv4/DHCP, decreasing from 20 seconds to 2 seconds. Additional mechanisms are under study to gain 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 to local mobility management, home agent proxying, and so on might be deployed to alleviate some current 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 a transition mechanism for IPv4 traversal, such as Cisco doors.

•

With the plethora of addresses that IPv6 offers, a new model of aggregation based on service providers delegating prefixes to their customers was put in place. The same plethora enables a given customer to buy services from several ISPs. But then, he gets as many prefixes as ISPs, and using the wrong one might not pass ingress filtering at the SP edge. This situation is called multihoming in IPv6 and was studied at the Multi6 working group at the IETF (see Chapter 4, “IPv6 Routing Protocols,” in the section “Site Multihoming” for details). With NEMO, the situation is even worse, because a number of additional scenarios might occur, such as a mobile router with multiple CoAs, multiple home agents, or a mobile network with multiple mobile routers. A new working group, MONAMI6, was chartered to study the problem outside of NEMO.

Network Mobility

313

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. In particular, the next sections review how the concept of home has evolved and which home network models can be considered for deployment.

•

There is a lot more to RO with NEMO than with MIP. At the time of this writing, NEMO is producing a problem statement document draft-ietf-nemo-ro-problemstatement and a solution space analysis draft-ietf-nemo-ro-space-analysis, which detail the various cases and approaches that could be 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 location privacy are ensured by distributed proxies.

NEMO is rechartering to address specifically the RO problem. This might open the way to dramatic changes in 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 by ND-related operations. With NEMO, the home network becomes an aggregation. Home is not necessarily contained on a home link (for instance, extended home network) and can be deployed in a number of variations. Also, with NEMO, the home link can be a virtualized, too. This configuration can be deployed when mobile routers have no need to return home, which is not necessarily a problem for most scenarios considered. Note that 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 and deployed in various fashions. The aggregation is generally called home. Home is advertised into the infrastructure by the home agent(s), and spans the home link and the mobile networks.

Extended Home Network In this model, the MIP home network is conserved as one subnet of a larger aggregation that also encompasses 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 mobile networks. To maintain the MNP routes in the absence of a binding, either the home agent is configured with static routes to mobile network prefixes or,

314

Chapter 8: Advanced Services—IPv6 Mobility

alternatively, the mobile routers recognizes that it is at home and participates in the local IGP. On the home link, only the home network inherited from MIP is installed, as the subnet from which all mobile nodes (hosts and routers) take their HoAddr. NEMO allows a mobile router to use an address from its own MNP as a HoAddr, but in the extended home network model, this does not seem to be the most natural operation, 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 the absence 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 mobile router is at home. In return, when the mobile router is connected to the home link with an EGRESS INTERFACE, it needs to switch automatically to a bridging—or a proxy ND mode between the home link and the mobile networks. If this automated bridging operation is not available on a given implementation, it is possible, alternatively, to connect the mobile router to the home link with the ingress interface(s) to make all MNNs directly available to the 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 because the real prefix is not on link. When configured for aggregated home network, an implementation could optionally verify that that the HoAddr matches (one of) the MNP(s) associated with that mobile router, and skip the DAD process. In particular, 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 assume the 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 the outside to tunnel them to the mobile router that is responsible of the next level of hierarchy. The next mobile router decapsulates and re-encapsulates the packets to the next mobile router down the logical tree. This process 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 United States. Cabs are equipped mobile routers, homed at the closest office from their location of operation. The example below focuses on the San Francisco (5F0) office. The topology is illustrated in Figure 8-10.

Network Mobility

315

Figure 8-10 Example of Mobile Home Network HQ Headquarters of Cab Company: CA5A SFO Regional Offices San-Francisco Office SFO-Cab-1 Cabs Fleet

SFO-Cab-2

SFO’s Cabs

SFO-Cab-n

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 running interface Ethernet0 ip address 10.0.2.1 255.255.255.0 ipv6 enable ipv6 nd ra suppress ipv6 Mobile Router-service door interface 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 running ipv6 Mobile Router home-network CAB:C0:CA5A:CA5A::/64 discover home-address home-network ::5F0 home-door 10.0.2.1 explicit-prefix

continues

316

Chapter 8: Advanced Services—IPv6 Mobility

Example 8-3 Mobile Home Network Configuration at the San Francisco Office (Continued) interface Ethernet0 ip address dhcp ipv6 address autoconfig ipv6 enable ipv6 nd ra suppress ipv6 Mobile Router-service roam try-the-door interface 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 running ipv6 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 the cabs are configured to use DHAAD, and doors IPv4 traversal is enabled, too. For mobile routers, Ethernet0 is the 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 link paradigm. This cannot be achieved with the NEMO basic support, which is still tied to the home link by its MIP inheritance.

IP Mobility in Nonmobile Scenarios

317

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, the overhead of the basic NEMO caused by the bidirectional tunnel cannot be ignored. With the distribution of home, the mobile router establishes its tunnel with the closest home location, and the routing information is distributed 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 and redistributed by a routing protocol. The distributed home network requires coordination between the home agents across the Internet to set up a mesh of tunnels and establish routes over these tunnels. This is the core of the global HAHA protocol, which has 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 is applicable to both MIP and NEMO, and in the NEMO case, it applies orthogonally to any of the previous models. Practically, the home link can be configured on a loopback interface or on an automatic (point to multipoint) 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 as HSRP, should be put in place to ensure a real high availability of home agent itself, which was partially covered by the home agent discovery and DHAAD mechanisms. However, physical mobile nodes on a virtual link cannot return home. Another advantage of the virtual home model is that it saves all the ND-related link-layer activities (home agent 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 has some characteristics that make it valuable outside mobility usage:

•

MIP is a dynamic, on-demand tunnel setup protocol, and NEMO enables some routing over it. This can 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, for example load balancing.

•

MIP exposes a flat network to the rest of the world. This could be used within a private network to hide its topology.

318

Chapter 8: Advanced Services—IPv6 Mobility

•

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 device management 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 scarce and MIPv6 mobile node as well as NEMO mobile routers should support an alternate roaming technology over IPv4. Also, real mobility scenarios include satellite and mobile phones (GPRS, EDGE), which do not provide IPv6 services at all. A number of Internet Drafts propose to modify MIPv6 and NEMO to tunnel MIPv6 over IPv4, registering an IPv4 CoA to a HA IPv4 address. At the moment, these solutions lack support for NAT traversal, RO, separate IPv4 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 NAT and PAT that are heavily deployed today, and their variety makes it difficult for an MN to figure out automatically which given solution it should use after roaming to a new access network. 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 a keepalive procedure. The MIP cache can be used to store the PAT/NAT states, and the frequency of binding flow can be tuned to keep the PAT/NAT active. As a result, it is possible for an IPv6 MN to traverse PAT/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 the IPv6 packets in an IPv4/UDP tunnel between the client and a stateless gateway, which can be collocated with the home agent or totally independent from it and placed at a boundary between IPv4 and IPv6. Doors operate as a bump in the client (mobile node) stack, which forges an IPv6 CoA based on a pair of IPv4 addresses and UDP 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. Interestingly, the mobile node does not need to be mobile per se; and coupling MIP with an IPv4 traversal technique can become a tool with a much wider scope than initially intended, and provide connectivity for IPv6 nodes over a PAT/NAT IPv4 infrastructure.

IP Mobility in Nonmobile Scenarios

319

Figure 8-11 Doors CN

PAT/NAT Private IPv4

IPv6

Door IPv4

MR

IPv6

Reverse NAT Door Tunnel

MN

Private IPv4

HA

MR Tunnel

Topology Hiding NAT in IPv4 was invented 10 years ago with a primary goal of slowing down the IPv4 address-space depletion. But since then, NAT has been widely deployed and additional benefits have emerged, such as some sense of security and network isolation. With the drawbacks associated with NAT (reviewed in Chapter 1, “The Case for IPv6—An Updated Perspective”), it was decided not to require/support NAT in IPv6. On the other hand, today’s deployments rely on some of the NAT-emerged benefits, so IPv6 ought to offer an equivalent solution. Internet Draft draft-ietf-v6ops-nap reviews a list of NAT benefits and suggests IPv6 alternative solutions where needed. A good example is the capability of NAT to hide the internal topology of a private network to the public side. If a network manager wants to conceal the internal IPv6 topology, and the majority of its host computer addresses, a good option will be to run all internal traffic using unique-local addresses (ULA), because packets using these addresses are confined within the site (or the VPN in case of a multi-site topology). Issues arise as soon as some hosts need to access public resources. If they use global routable IPv6 addresses to do so, 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 between the public and private domain. A global prefix is set up as a home network and advertised within both the private domain and the global Internet. All nodes inside the private domain that need to reach the Internet or to be reachable from the Internet are set to be MIPv6 mobile nodes for that home agent, statically or on-demand using MIPv6 bootstrapping techniques. In MIP terms, their ULAs are used as CoA to access Internet 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 becomes virtually located on a home link. This arrangement provides a flattened image of the site and hides its true structure to the outside. Only the nodes that are currently

320

Chapter 8: Advanced Services—IPv6 Mobility

registered can be joined from the outside, and the home 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 is inside or outside. If the correspondent is inside and the node is not mobile, the node uses its inside address (ULA) as source and does not use MIP. If the node is mobile, the node selects its HoAddr as source and forwards the packet over its 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 MIP tunnel via the home agent. RO is not permitted and would not work anyway because the CoA is only reachable within the site. When a correspondent initiates a new connection, the node responds using the same means. If the correspondent 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 accessing public resources over an MPLS SP backbone. Figure 8-12 Using MIPv6 to Hide Internal Topology 2001:700::44

CN: Internet Server

IPv6 Internet FC00:101::33 FC00:101::1 2001:100::33 2001:700::44 Payload

Site-1 VPN-A HoAddr: 2001:100::33 CoA: FC00:101::33/64

Traffic to Public Resource

2001:100::33 2001:700::44 Payload Home Agent 2001:100::72a/64

IGW PE1 MPLS SP-Backbone

CE1

VRF Red

PE2

MN: Host1

VRF Red FC00:101::33 FC00:201::55 Payload

Traffic to Private Resource

VPN-A Server

CE2

FC00:201::55

Site-2 VPN-A

IP Mobility in Nonmobile Scenarios

321

In Figure 8-12, the customer site Site 1 belongs to VPN A. It is connected to the SP backbone using a virtual routing/forwarding (VRF) instance named red (see Chapter 7, “VPN IPv6 Architecture and Services,” for details on VRF). It can either access the VPN A server located in VPN A at Site 2 (FC00:201::55) or the Internet 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-local addresses (FC00:101::/64) to reach the home agent, collocated at router CE1. Traffic directed to private address (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 is something that you could think of as a “closed user group” for IPv6. The idea is to group a set of addressable IPv6 devices together and enable communication between them while disabling or limiting communication from 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 a level of indirection, MIPv6 enables the deployment of a “hub-and-spoke” topology, where the home agent is located 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 direct path between mobile routers. When applied to the community of interest for NEMO, this would turn the hub-and-spoke model into a mesh of routers, maintained by NEMO RO, as an overlay on the Internet infrastructure. The general term for this model is route projection. Route projection consists in dynamically setting up a transient tunnel between two routers and then exchanging a set of fine-grained routes for a limited time over that tunnel. On one hand, this compares to the BGP backbone that sustains the Internet. But in the backbone, the tunnels are manually configured and permanent, and the prefixes are much aggregated and stable. Route projection would 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 prefix is injected at one end of the Internet, and slowly diffuses into the whole infrastructure until it is finally reachable globally. With route projection, the routing states are only advertised on-demand to the precious few 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

322

Chapter 8: Advanced Services—IPv6 Mobility

infrastructure, and do not require additional states in the Internet. As a result, route projection introduces a new way to scale the Internet, and to deploy IPv6 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 a single IP address. As MIPv6 provides an indirection to the network address, it can be used as a load-balancing technique at layer 3. To achieve this, the servers of the given cluster are configured as mobile nodes. They are associated with one another by statically or dynamically assigning the same HoAddr to the members of the cluster. The HoAddr becomes 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 the associated tunnel. When a web client issues a server request targeting this HoAddr, the request reaches the home 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 a home agent load-balancing web client requests. Figure 8-13 Server Load-Balancing Using MIPv6 CN, Correspondent Node Any web client MN, Mobile Node A server, unaware of how many servers serve the same cluster address == Home Address.

Server Network

Internet HA, Home Agent Accepts multiple bindings for a same Home Address and load balances over the bindings.

Next Steps in Mobility Although RFC 3775 is a significant step in defining the main concepts and aspects of mobility, some applications, such as Voice over IP, require additional functionalities. These functionalities, such as faster movement detection and smoother handover, deal with the time-sensitive aspects of certain applications and services.

Next Steps in Mobility

323

Forthcoming Evolutions Working groups at IETF and IEEE are already working on a number of additional features that would be required to support certain applications (Triple Play, for example) and use cases (aviation, cars). This section elaborates 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 on layer 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. To meet the seamless handover requirement demanded by interactive applications, a mobile node needs to perform its network attachment detection and its access router selection within 50 to 100 ms after the roaming took place. IPv6 is leading the way with make-before-break approaches such as Fast MIP (see RFC 4068) and Context 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 local mobility 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 Ethernet abstraction, emulated by 802.11, was not designed to support hosts moving around. As a result, the layer 3 is not informed when a layer 2 roaming occurs and cannot take actions in due time. Several transient solutions based on layer 2 triggers and SNMP traps have been proposed. Layer 2 and layer 3 triggers are being defined at 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 to terminate them. In addition, most routing protocols will collapse if the links flap and the nodes change their points of attachment without due announcement. Moreover, because the 802.11 radio interface is inherited from Ethernet, there is no provision for mobility-related API, and a layer 2 roaming operation often occurs unbeknownst 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 Router Advertisement messages to detect the network attachment as quickly as possible in a generic layer 3 fashion. Neither technique,

324

Chapter 8: Advanced Services—IPv6 Mobility

however, offers a handover time that would make roaming transparent to voice applications. To adapt to mobility, a node must first detect when movement occurs, control it if possible, and then act on the movement to restore the connectivity. With IPv6, a number of means have been introduced at the network layer to detect the movement, and making this detection as fast as possible is the goal of the activity at the IETF 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, a mobile node might roam. The mobile node selects the new attachment router as its default gateway and it autoconfigures 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 nested NEMO. Additional layer 3 information is needed to avoid loops and optimize metrics such as depth in the resulting structure. This information should also indicate the capabilities by the potential attachment router in term of reachability (for instance, whether it is connected to the Internet). Internet Draft draft-thubert-tree-discovery proposes a generic algorithm based on autonomous decisions by each mobile router for building loopless nested NEMO structures.

Integration with Mobile Ad-hoc Networking Extensive work has already been performed, in the Academia, and within the MANET working group at the IETF and IRTF, around mobile ad-hoc networking. As opposed to MIP, which focuses on a node that changes its point of attachment around the Internet, the goal here is to allow a local communication between unrelated nodes using their persistent global addresses. A number of experimental standards have been published already, but none widely deployed. MANET is now working 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 local reachability while preserving the global reachability. A smooth integration of MANET and NEMO technologies can enable applications such as nested NEMO and mesh networking.

Next Steps in Mobility

325

Multihoming A home agent might want to check whether an MNP is registered by a unique mobile router, which, if the HoAddr 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 the same 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 a group and never split? What would happen if they did? How does the home agent balance the traffic to the MNP over the two available tunnels? It might happen as well that home itself is multihomed, causing the mobile router to support more then one prefix; this problem is quite analogous to the traditional site multihoming. Also, a mobile router might want to maintain 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 easy problem by itself. This is why the MULTI6 working group at the IETF rejected explicitly to consider the multihoming 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 mobile router (MR2) itself attached to mobile router MR1. The VMN might be a visitor’s laptop, used from inside a rental car in a large parking lot of a supermarket. In that example, packets need to be relayed by a mobile router in another car, to the access point, which is out of direct reach. By means of the NEMO basic support, MR1 establishes a tunnel with its home agent (HA1) and installs its default route over that tunnel, and so does MR2 with HA2. As a result, MR1 encapsulates all packets from MR2 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.

326

Chapter 8: Advanced Services—IPv6 Mobility

Figure 8-14 Route Optimization for NEMO HA1 (HA of MR1)

HA2 (HA of MR2)

Internet CN

HA-VMN (HA of VMN)

MR1

MR2

VMN

As a result, to reach a supermarket that is two 802.11 hops away, all the packets from VMN are encapsulated a first time by VMN itself, then by MR2, and then by MR1. Hence, each packet sent by VMN carries four IPv6 headers! Consider a Voice over IP application using an 8-Kbps codec such as G.729a and taking a voice sample every 20 ms, with a transmission rate of 50 packets per second. Each additional IPv6 header is an extra 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 on the other side of the ocean. As a result of the outer encapsulation, all packets cross the country, are decapsulated by HA1, and then come back a few blocks away, are decapsulated by HA2, and then cross the Ocean, 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 called pinball 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 one fragment 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 on that specific problem, spinning off MANEMO for MANET integration and MONAMI for multihoming.

Next Steps in Mobility

327

A Vision Initially, the so-called “mobiquity” will be mostly about mobile routers and nodes forming trees to reach the Internet. But, inner connectivity within that fringe will also be required to sustain local applications, as long as the 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 of pervasive networking, a vision for the Internet where every person and every device is connected to the network in the ultimate realization of Metcalf’s law. When this happens, the Internet landscape might no longer look like anything familiar. Pervasive networking requires a new model to scale the Internet, which could start with self and group-centric abstractions 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 peerings they 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 precious few 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 IPv6 Networks It is regularly stated that IPv6 is more secure than IPv4. In fact, this argument is often used to promote the deployment of IPv6. The assertion stems from the original mandated use of IPsec in host-to-host communication, as specified in RFC 2401. It is a natural requirement in the context of IPv6’s intent to provide a new infrastructure that supports peer-to-peer applications. If this mandate would be enforced by all hosts, properly implemented by all applications, and a reliable and efficient key-exchange system would be universally adopted, it would mean a more secure data transport. The consistent use of IPsec on host-to-host communication would also enable network operators to track sources of attacks. Nevertheless, it would not prevent application layer security threats, which are common.

NOTE

RFC 2401’s requirement to use IPsec on all hosts might limit IPv6 adoption for certain communication devices. Mobile phones, for example, might not have the capability to implement IPsec. To stimulate the adoption of IPv6 by the third generation of mobile systems, the IPsec requirement might become optional in the future.

At this time, however, the conditions for a consistent use of end-to-end security are not in place; so for the most part, IPv6 is neither more nor less secure than IPv4. Both protocols face most of the same threats. IPv6 specificities bring new perspectives on some types of attacks. These specificities along with protocol security enhancements intrinsically close the door for some threats, although open new doors for others. Moreover, the likely coexistence of the two versions of IP can potentially offer attackers new venues to exploit security holes and to circumvent the defenses of one protocol to attack the other. This chapter reviews the security threats faced by an IPv6 infrastructure and its users. It draws a parallel to IPv4, highlighting differences and similarities. The review is based on an exhaustive study of this topic by Sean Convery and Darrin Miller in the white paper, “IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation.” Table 9-1 summarizes the topics covered later in this chapter.

330

Chapter 9: Securing IPv6 Networks

Table 9-1

Review of Security Threats

Threat

IPv6 Characteristics

Mitigation

Threats with New Considerations in IPv6 Reconnaissance

Scanning for hosts is not feasible because of large address space. Well-known addresses, in particular multicast, are vulnerable.

Same as IPv4. Privacy extensions can make reconnaissance less effective.

Unauthorized access

End-to-end security reduces the exposure. Extension headers (EH) open new attack venues.

Use privacy extensions to reduce a host’s exposure. Use multiple addresses with different scopes. Manage EH use.

Header manipulation

IPv6 can take advantage of chained and largesize EHs.

The EHs usage should be strictly controlled based on deployed services.

EHs that must be processed by all stacks are particularly useful to an attacker. Fragmentation

No fragment overlap should be allowed in IPv6, but some stacks do reassemble overlapping fragments. The impact of tiny fragments is minimal in IPv6.

Use properly implemented stacks that do not allow fragment overlap.

Layer 3/layer 4 spoofing

The use of tunneling offers more spoofing opportunities even though they are not different from IPv4 tunneling.

Same mitigation techniques as with IPv4.

Host initialization and address-resolution attacks

DHCP has similar vulnerabilities for the two protocols. Neighbor Discovery has similar vulnerabilities as ARP. Stateless autoconfiguration and renumbering offer new attack options.

Use an interim solution such as static neighbors; the SEND recommendations are adopted by the IPv6 stacks.

Broadcastamplification attacks (Smurf)

No concept of broadcast in IPv6, and that reduces the amplification options.

Use filtering for multicast traffic, in particular, because it is the only amplification option.

Routing attacks

IPsec provides additional peering security for some protocols. From a threat perspective, it is similar to IPv4.

Same as IPv4. Wherever possible, implement IPsec.

Viruses and worms

Same as IPv4. Random scanning used by worms to propagate is impractical in IPv6 because of the large address space.

Same as IPv4.

Transition-mechanism attacks

New ports to open in IPv4 firewalls. Automatic tunnels are more susceptible to attacks. IPv6-IPv4 translation can hide the sources of attacks.

Tighter control of ports opened in the firewalls; open only the ones needed. Use static tunnels when possible.

Mobile IP

Embedded in IPv6. Has specific security features.

Filter out all routing headers except Type 2 if MIPv6 is used. Securing MIPv6 beyond IPsec is a work in progress.

Securing IPv6 Networks

Table 9-1

331

Review of Security Threats (Continued)

Threat

IPv6 Characteristics

Mitigation

Threats with Similar Behavior in IPv4 and IPv6 Sniffing

Same as IPv4.

Same as IPv4

Application layer attacks

IPsec offers the potential to increase security and to track attackers.

Similar to IPv4, security ultimately relies on host defenses.

Rogue devices

Same as IPv4.

IPsec can prevent interaction with such devices. Lower-layer protocols such as 802.1x can be used to block unauthorized devices from connecting to the network.

Man-in-the-middle attacks

IPsec can protect so long as the key is not stolen.

There is a big need for a scalable and operationally feasible authentication and key-exchange mechanism.

Flooding attacks

Same as IPv4, with a few additional traffic types.

Use traffic-limiting mechanisms.

The analysis of the security threats is complemented with a set of best practices rules that apply in each case presented. 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 there is limited experience operating IPv6 networks.

Before tackling IPv6 security, it is important to discuss the typical IPv4 topology to implement perimeter security. On one hand, this discussion would help choose the best way to integrate IPv6 in the existent networks without weakening deployed security measures. On the other hand, because of the similarities between 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 add dedicated devices such as intrusion detection systems (IDSs) to this topology if the functionality is not supported by the same device that acts as a firewall. Additional levels of security are most likely implemented at the host level, particularly for important devices and resources.

332

Chapter 9: Securing IPv6 Networks

Figure 9-1

Typical IPv4 Perimeter Security Topology

Server Farm DNS

WWW

Internet Service Provider

Mail

Internal Network Edge Router

Firewall

This figure shows is a common approach to securing networks, but this setup relies on fact that its perimeter can be clearly identified. Many books are available for more in-depth information about IPv4 security such as Sean Convery’s Network Security Architectures.

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 taking advantage of IPv6-specific vulnerabilities. It is therefore reasonable to relate the IPv6 security threats to IPv4 and group them into two categories: threats with new considerations in IPv6, and threats with similar behavior in IPv4 and IPv6. This classification is reflected in the recommended security best practices for mitigating these threats. Some recommendations are extrapolations of their IPv4 counterparts, whereas others are completely 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. This section analyzes those threats that have to adapt to these features as well as new threats that can impact exclusively IPv6.

Reconnaissance Reconnaissance is not necessarily an attack, because it will most likely not impact negatively the network or the users. However, it typically is the precursor of an attack and it is intended to provide the attacker with information about the victim.

Security Threats and Best Practices to Protect Against Them

333

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 trigger security alarms. For this reason, Network Mapper (Nmap), a tool commonly used in IPv4 to identify active hosts, does not even support IPv6 ping sweeps. With IPv6, other mechanisms must be used for reconnaissance purposes:

•

DNS crawling—DNS crawling remains an option with IPv6. With the elimination of Network Address Translation (NAT) and the difficulty of remembering 128-bit addresses, the use of Dynamic DNS might increase in an IPv6 environment. If the DNS resources are not properly secured, they can provide information about many hosts.

•

Reducing the scope of the search for hosts—The attacker can make a smart choice that could help narrow down the address space that needs to be scanned. One can try hosts with easy-to-remember interface IDs, such as ::1, ::FFFF, and ::F00D. Because the layer 2 burned-in address (BIA) is often used to generate the EUI-64 interface ID of hosts, one can focus the scan on addresses of certain NIC vendors based on their organizational unit identifier (OUI).

•

A compromised network element—A compromised network element can also provide information on local hosts via the neighbor cache.

•

Use multicast addresses standardized for certain protocols—This mechanism enables the attacker to identify key systems such as routers and DHCP servers. Addresses with larger scope are preferred because they do not require the attacker to be on a victim’s local link. Site scope addresses such as All Router (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 one prefix to another because it is more difficult to identify active hosts on a prefix other than that of the infected host. Locally, an infected host can send a ping to the all-nodes multicast address to find active hosts within its own 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 IPv6 Refresher”) for the addresses used to communicate outside the internal network. Doing so limits the amount of time a given host address can be targeted. The disadvantage of using the privacy extensions is that the host is difficult to track for internal management purposes. For this reason, network managers may want to disable the use of privacy extensions.

334

Chapter 9: Securing IPv6 Networks

Note

•

The use of privacy extensions is not suitable for all deployments. In particular, service providers need to be able to track customers for various reasons, including regulatory requirements. In both enterprise and 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 the control plane of IPv6. Block ICMP echo packets sourced from outside the internal network. Permit the neighbor- and router-discovery traffic as well as “Packet Too Large” messages used for the Path Maximum Transmission Unit (PMTU) Discovery process.

•

Implement edge security measures. Use firewalls to filter unnecessary services. Control multicast traffic at the edge, and stop site-scoped external 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. A host’s ability to communicate implies IP accessibility. The most a network administrator can do to protect the hosts is to control some of the means that an attacker can use to covertly reach them. Network elements and devices 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 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 filtering mechanisms 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

Security Threats and Best Practices to Protect Against Them

335

routing headers. That threat was addressed through the introduction of a MIP-specific, Type 2 routing header (see Chapter 8, “Advanced Services—IPv6 Mobility”). However, the routing header is still in use—for example, in the link-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 as aggressive as it was in IPv4.

•

Multicast traffic—Should be filtered and inspected in the same manner as it is in IPv4. However, IPv6 relies 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 an increased interest in expanding the use of anycast, its monitoring might become even more important when 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 help minimize the exposure of enterprise hosts to attackers.

•

When IPsec is used end to end by internal hosts, the firewalls and router filters can manage packets only 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 for monitoring and filtering.

The EHs necessary for the proper operation of the services deployed in the network should be identified and allowed through the filters. Specific security policies should be defined for the allowed EHs based on the service and function they support. Note

The Cisco IOS implementation of extended access lists was enhanced, beginning with Cisco IOS 12.4(2)T, to filter based on the routing type, thereby allowing routers to differentiate between EHs used for MIPv6 and for source routing. Only Type 2 routing headers should be allowed to support a MIPv6 service.

336

Chapter 9: Securing IPv6 Networks

•

The IPv4 ICMP policies should be matched by the IPv6 ICMP policies. The following types should be 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: — ICMPv6 Packet too big (Type 2) for PMTU Discovery — ICMPv6 Parameter problem (Type 4) — ICMPv6 Multicast listener (Type 130–132, 143) — ICMPv6 Router solicitation and router advertisement (Type 133 and 134, respectively) for link 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 a multicast address should be blocked. Network administrators should be aware that the capabilities of firewalls 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 and networks. The EHs in particular can be used in environments that do not pay attention to their usage.

Characteristics The routing header–based security threats that were mentioned earlier in this chapter are not the only ones to exploit 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.

•

Use large-size EHs or a large number of EHs to drain the resources of the devices that have to deal with the EHs.

Chain a large number of EHs to force the security devices and mechanisms to do long lookups into a packet, possibly beyond their capabilities, to get to the information that reveals an attack. This approach could provide the means to hide an attack.

Poor IPv6 stack implementations could be particularly targeted with the help of EHs.

Security Threats and Best Practices to Protect Against Them

NOTE

337

It is important that hosts enforce the standardized rules for handling EHs. Firewalls should be able to filter based 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 the best defense against this type of attack is to filter out traffic with any EHs that are not supporting deployed services. 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 elements— that is, their capability to process multiple or large EHs.

Fragmentation IP packet fragmentation can serve two purposes to threaten a network. First, it can be used to hide an attack from 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 possible attacks. Second, IP packet fragmentation can be used to overwhelm network elements that are supposed to do fragmentation 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 impact on 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 of fragmentation in IPv6 security are as follows:

•

No fragment overlapping should be allowed in IPv6. An attacker could send a stream of fragments and then follow up with fragments that carry the attack information. The receiver’s reassembly algorithm overwrites the original fragment that contained harmless information and therefore passed through security checks with the new fragment containing the attack. This type of attack can be stopped 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 send small-enough packets that would push the information that reveals an

338

Chapter 9: Securing IPv6 Networks

attack into the second fragment of the stream. The security measures generally act on the information in the first fragment, so the attack 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 size are dropped. One drawback of such policies is their impact on applications that rely on smaller packets, such as Voice over IP (VoIP). At the same time, the PMTU Discovery algorithm implemented by some IPv6 protocol stacks could be adversely impacted by the policy mentioned above. For example, the algorithm can start the search at 1500byte frames that might be too large for the PMTU. Then drop to 750 (binary search), which would be dropped because of the policy. All the subsequent packet sizes in the binary search steps would be dropped, leading to a falsely unsuccessful search. Note

•

Hosts can still send smaller packets and can be proven inconvenient if they have to be analyzed by the firewalls.

Out-of-order fragments can still be used in attacking poorly implemented IPv6 stacks. This is a threat for 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 “tinyfragments” threats, but such 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 to handle the case where EHs push upper-layer information into the second fragment. In these cases, 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 4 information about the originator. It makes the source untraceable, and it can force the device whose address was spoofed to have to deal with the response to the attack.

Security Threats and Best Practices to Protect Against Them

339

Characteristics Most aspects of IPv6 spoofing threats are similar to IPv4. Tunneling mechanisms provide a new venue of attack where the spoofing weakness of both protocols can be used. A few protocol specifics must be considered 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 use or reserved) or with that of a victim. In IPv4, the typical mitigation technique is filtering based on RFC 2827 and to identify traffic with SAs incongruent with its source. The implementation of RFC 2827 verifies only that the SA is on the expected subnet, so an attacker could still spoof the address of other users on the same subnet. The same mitigation technique can be used for IPv6, but its addressing leads to some specific characteristics: — The assignment policies and the aggregation properties of the IPv6 addressing scheme allows for easier implementation of RFC 2827 filtering. Organizations can therefore contain rogue traffic with simple access control lists (ACLs). — The larger address space implies a larger number of interface IDs, which can still be spoofed despite RFC 2827 implementation. — IPv6 also offers the option to spoof layer 3 addresses in EHs. In particular, routing headers can 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 IPv6 Networks,” can be used to help identify misbehaving hosts. As mentioned earlier, privacy extensions can make the tracking process more difficult.

•

Layer 4 spoofing relies on getting the victim to react to a fake application. There is no difference between 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, as discussed 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 anycast address of the 6to4 relay router. The attacker can similarly spoof the address of other IPv6 nodes.

340

Chapter 9: Securing IPv6 Networks

Figure 9-2

Spoofing Attack Using a 6to4 Tunnel

Fake ICMP echo request sent by the attacker:

6to4 Relay forwards to the Edge Router. The original IPv4 encapsulation is lost:

IPv4 SA=192.88.99.1 (spoofs the IPv4 address of 6to4 relay) IPv4 DA=192.88.99.1

IPv4 SA=192.88.99.1 (address of 6to4 relay) IPv4 DA=200.15.15.1

IPv6 SA=2002:C80A:A01::1 (spoofs the IPv6 address of 6to4 relay) IPv6 DA=2002:C80F:F01:100::1 (address of server A)

Attacker

IPv6 SA=2002:C80A:A01::1 IPv6 DA=2002:C80F:F01:100::1

IPv6 Network 1 192.88.99.1

2

DA SA SA DA

IPv6 Internet

3

200.15.15.1

SA DA

DA SA

5

6to4 Relay

IPv4 Internet

6to4 Relay receives Echo Reply from Server A: IPv4 SA=200.15.15.1 IPv4 DA=192.88.99.1 IPv6 SA=2002:C80F:F01:100::1 IPv6 DA=2002:C80A:A01::1

Edge Router

4

DA SA

Server A

Server A replies to the ICMPv6 Echo: IPv6 SA=2002:C80F:F01:100::1 IPv6 DA=2002:C80A:A01::1

IPv4 encapsulation removed: IPv6 SA=2002:C80A:A01::1 IPv6 DA=2002:C80F:F01:100::1

The 6to4 relay forwards the inner part of the packet, removing the IPv4 header (which makes it difficult to trace the source of the packet). There is no packet amplification benefit intrinsic to this type of attack. The attacker 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 is not dramatic because no amplification mechanisms can be leveraged with them. You can find a complete analysis 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, based on the recommendations of RFC 2827. Effective filtering allows networks to contain spoofing traffic generated within and to narrow down to the subnet level the location of the attacker.

Security Threats and Best Practices to Protect Against Them

NOTE

341

In the case of IPv6, only the traffic sourced from addresses in the blocks currently allocated by IANA should be 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 available for IPv6. This feature is discussed in further detail later in the chapter in the section “Unicast Reverse Path Forwarding.” The tunnels can be secured using IPv4 IPsec to reduce the threat of spoofing. This can easily be done in a controlled environment, but can also be implemented in open environments with the help of Internet Key Exchange (IKE). 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 operational information such as default gateway and DNS servers. They also target the process of resolving the layer 3-to-layer 2 address binding. The attack can disrupt these processes or try to redirect a host’s traffic to a compromised device. In IPv4, these threats target protocols such as Address Resolution Protocol (ARP) and Dynamic Host Configuration Protocol (DHCP). Several features are used in IPv4 to protect against these types of attacks (DHCP snooping attacks, for instance).

Characteristics The host bootstrap process and the layer 2 address-resolution process were modified in IPv6, leading to IPv6-specific host-initialization and address-resolution attacks:

•

DHCPv6 remains a host-initialization option. It is also often considered in conjunction with stateless autoconfiguration. DHCP-PD (Prefix Delegation) is also used to provide prefixes to routers. In all these 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 in ICMPv6 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 the address of a compromised device acting as a gateway. An attacker can also interfere with a host’s initialization process by replying to its Duplicate Address Detection (DAD)-driven neighbor solicitation.

342

NOTE

Chapter 9: Securing IPv6 Networks

•

The renumbering capabilities of IPv6 are based on the RA packets. An attacker can modify the RAs to trigger a renumbering of all the hosts on a network segment. The consistent use of the AH would close this security hole.

•

Neighbor Discovery (ND) performs the IPv4 ARP functionality. In its original definition detailed in RFC 2461, no security mechanisms are built in to the protocol, so it is as vulnerable to attacks as ARP. Using IPsec between the nodes would involve prohibitively large management overhead because it implies static associations.

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 security mechanisms for addressing the ND threats: • A mechanism for certifying routers with a trust anchor that a host consults before accepting a router to be its default gateway. • Cryptographically generated addresses generated with the help of a private and a

public key and used to 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 all ND messages. • A timestamp and a nonce (random number used only once) option were introduced

to prevent replay attacks. SEND enabled hosts can operate together with non-SEND hosts.

These threats are particularly relevant in environments where the physical layer is not secured (such as wireless environments).

Best Practices These types of attacks imply a breach in the physical access of the network, which clearly provides the attacker with many opportunities, regardless of protocol. Addressing this security breach should be the first step in mitigating such problems. With layer 1 and layer 2 secured based on specific mechanisms (Public Secure Packet Forwarding, for example), the attention can shift to layer 3 security solutions. In the case of IPv6, 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 autoconfiguration process.

Security Threats and Best Practices to Protect Against Them

343

Broadcast-Amplification Attacks (Smurf) Broadcast-amplification attacks are a type of denial-of-service (DoS) attack in which an ICMP echo is sent to the broadcast address of a prefix and with the spoofed address of the victim. All hosts on the destination prefix in 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 packets that have a multicast DA, a layer 2 multicast address, or a layer 2 broadcast address. If all stacks implement the 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 multicast traffic to decline the attacker any amplification venues. To complement the constraints provided by RFC 2463, 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 drained through flooding attacks or by simulating transitional states such as route or neighbor flapping. Attackers can also attempt to insert their devices in the routing topology or compromised routers and corrupt the routing information.

Characteristics Routing protocols did not change significantly in IPv6, so there are minor differences in the structure of routing attacks for the two versions of IP. The relevant change is the fact that although Border Gateway Protocol (BGP; see RFC 2545), Intermediate System-toIntermediate System (IS-IS) and Enhanced Interior Gateway 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 next generation (RIPng; see RFC 2081) use IPsec (Authentication Header and Encapsulating Security Payload) for their communications with neighbors. The IPsec-based protection provides an increased level of security compared with the previous mechanisms.

NOTE

IPsec protection can be integrated in EIGRP, but as of this writing it has not been implemented yet. IS-IS benefits from the fact that it exchanges routing information using layer 2 packets, which are more difficult to spoof.

344

Chapter 9: Securing IPv6 Networks

Time-To-Live (TTL) checks can also be used to ensure that routing updates are not coming from farther away than what would be expected based on the size of the network managed. Such updates could be spoofed messages used for an attack.

Best Practices Several basic best practices are recommended to protect the routing processes:

• •

Routers should be secured from unauthorized access.

•

Implement any flooding control mechanisms that could protect the router resources, and the routing protocol control messages should be a high priority.

Secure the communication between the routers through IPsec wherever the feature is supported or through traditional authentication mechanisms.

Viruses and Worms The most damaging security threats remain viruses and worms that operate at the application layer. They impair 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 their operation in an IPv4 or an IPv6 world. The most significant difference to note is the fact that the larger addressing space makes it impossible for viruses to spread in an IPv6 environment by scanning active hosts on prefixes other than that of the infected device. As mentioned earlier, such a process would take too much time to 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. You can complement perimeter security via firewalls and IDS systems with up-to-date antivirus software on the hosts.

Transition-Mechanism Attacks The mechanisms developed for a seamless and gradual migration from IPv4 to IPv6 offer new attack venues through which attackers can leverage weaknesses in the security policies and capabilities of both IPv4 and IPv6.

Security Threats and Best Practices to Protect Against Them

345

Characteristics The tunneling and translation concepts used in IPv6 migration mechanisms have been used in IPv4, too, and that means they share the same types of vulnerabilities. Therefore, the threats enabled by IPv6 migration technologies neither new nor unique:

• • •

Dual-stack environments are threatened over both IP protocols.

•

The IPv6-to-IPv4 translation mechanisms have similar vulnerabilities as NAT in IPv4. They are also responsible for hiding sources of attacks behind the translated addresses.

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-known tunneling resources such as 6to4 relays can be particularly targeted. In the case of IPv6, you can mitigate this problem if you secure the tunnels with the help of IPv4 IPsec wherever possible.

Best Practices The security best practices for mixed IPv4 and IPv6 environments have to take into consideration the various ways 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 secure the 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 a minimum, the security measures discussed for the various threats should be implemented for each protocol 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 went into securing the feature to ready it for deployment. IPv6’s easy leverage of IPsec is helpful; however, it is not always applicable to many environments that intend to use MIPv6. Many of the devices used in mobile networks, such as mobile phones or PDAs, do not have the computational power to fully implement IPsec. So along with this obvious mechanism for securing communications in IPv6, new lighter security mechanisms had to be created. Chapter 8, “Advanced Services—IPv6 Mobility,” focuses on mobility, and includes a section on security.

346

Chapter 9: Securing IPv6 Networks

Threats with Similar Behavior in IPv4 and IPv6 Several familiar threats behave similarly whether they are executed over an IPv4 or an IPv6 infrastructure. For IPv6 deployments, you must be mindful of these types of attacks and implement protective measures based on experience 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 with various tools, such as TCPdump or Ethereal, and the captured information can be investigated for information that can open other access venues for the attacker. 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 used consistently and universally by the hosts, can prove beneficial to trace the source of an attack. On the other hand, the general use of IPsec reduces the benefits that IDSs provide because they cannot search for attack patterns 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 or act as switches, routers, access points, or resources such as DNS, DHCP, or AAA servers. IPsec can help prevent interaction with such devices.

Man-in-the-Middle Attacks A device that manages to insert itself in the communication path between two hosts represents a man-in-the-middle attack. IPsec can protect against such attacks so long as the attacker cannot get the key used to encrypt the communication.

Flooding Attacks Flooding attacks are meant to busy out infrastructure or host resources. They can disrupt the packet-forwarding or control-plane functions of the network. Rate limiting can be used to mitigate such attacks. On dual-stack interfaces, it is likely that IPv6 traffic is rate limited more aggressively to protect the existent, revenue-generating IPv4 services.

Security Threats and Best Practices to Protect Against Them

347

6PE Security Based on their operational similarities, 6PE and IPv4 VPNs can share the same security policies. On the other hand, 6PE’s role of a “global VPN” for offering IPv6 Internet access services opens the door to other possible attack vectors. 6PE’s use can expose a service provider’s infrastructure to potential attackers. Following are some 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 IPv4 Multiprotocol Label Switching (MPLS) network can lead to information leaks. To avoid such problems, 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 IPv4 loopback address. IPv6 traceroutes should be explicitly blocked because they could reveal the IPv4 addresses of the P-routers. An alternative is to configure P-routers (via the no mpls ip propagate-ttl forwarded 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 impact the IPv4 service, too. To protect against such attacks, the IPv6 addresses of the 6PE routers should not be 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 to guard the PE router resources against IPv6 attacks. However, the best way to avoid this type of 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 used only 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 practices from the point of view of both unicast and multicast IPv6 services. The subject of securing MIPv6 was also covered, 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-based VPNs, the same concepts apply. The security aspects of IPv6 VPNs are discussed in Chapter 7, “VPN IPv6 Architecture and Services.” For more details about IPsec VPNs in IPv4, refer to IPSec VPN Design by Vijay Bollapragada, et al. At the time of this writing, however, the features needed to secure IPv6 VPN services were not yet available.

NOTE

Whenever an IPv4 IPsec VPN session is available, it can be used to secure the transport of IPv6, too.

348

Chapter 9: Securing IPv6 Networks

One interesting security challenge is raised by the elimination of NAT in IPv6. Although it provides some protection, NAT should never be considered a security feature. Nevertheless, in IPv4 it provides the fringe benefit 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 the world without exposing the internal addressing and structure of the network. Tight perimeter security can protect the IPv6 network against attacks. The negative impact of removing NAT is being analyzed within the v6ops IETF working group (see draftvandevelde-v6ops-nap-01.txt), and workarounds for this particular issue are starting to emerge. The “Topology Hiding” section of Chapter 8 describes a possible elegant way to hide the 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 the deployment of 6VPE, too.

Tools Available for Securing IPv6 Networks The threat analysis leads to the conclusion that more similarities than differences exist between IPv4 and IPv6 as far as security is concerned. Until end-to-end IPsec and a reliable key-distribution protocol is consistently deployed for IPv6, the proven IPv4 security best practices and tools should be used to secure the IPv6 networks, too. It is thus important to evaluate the IPv6 readiness of these tools. Although perimeter security is critical, security policies and tools are implemented and used in multiple parts of the network.

IPsec for IPv6 IPsec is the networking community’s answer to the need for secured communication. It was defined in 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 through an AH extension header.

•

Encapsulating Security Payload (ESP) is defined in RFC 2406, and it provides confidentiality, source authentication, connectionless integrity, and replay protection. In IPv6, it is implemented through an ESP extension header.

Tools Available for Securing IPv6 Networks

349

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 network to a security gateway. They are then encapsulated in another packet and securely transported to the destination or to another security gateway that places them on another trusted network for the destination. In this case, the entire original packet, payload, and header 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 security association (SA), which is a unidirectional logical connection that encompasses all the participating elements. These elements include the authentication algorithm, authentication key, encryption algorithm, encryption key, and so on. These parameters are negotiated between the two participants in the SA. In transport mode, a host clearly has to establish multiple SAs. It can differentiate between them by using a Security Parameters Index (SPI). These two IDs, the SA and the SPI, are referenced 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

Authentication Header 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Next Header

Payload Length

Reserved

Security Parameters Index (SPI) Sequence Number Authentication Data (Variable length)

Encapsulating Security Payload Header 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Security Parameters Index (SPI) Sequence Number Payload Data (Variable length) Padding (0–255 octets) Authentication Data (Variable length)

Pad Length

Next Header

350

Chapter 9: Securing IPv6 Networks

The sequence number is a variable that is initialized to zero when the SA is set up. It ticks up with every 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 still being done to identify a reliable protocol for key distribution. Cisco IOS routers use Internet Security Association and Key Management Protocol (ISAKMP; IKEv1), as defined in RFC 2408, to provide key management and authentication. However, without a generally adopted authentication scheme, its use is limited in the public domain. Manually configured keys are always an 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 is used for access VPNs as well as inter-site VPNs. IPv6 transition mechanisms can leverage such an infrastructure 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 gateway set up for these purposes. If the same host is enabled for IPv6, it can thread an IPv6 tunnel through this IPv4-secured communication channel. Because the IPv4 VPN places the remote host on the private network, a natural IPv6 tunnel choice is the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), which is suitable for intra-site communication. In practice, however, you can use any type of IPv6 tunnel as long as it is supported by the host and a gateway is set up for it inside the private network. The configurations for the IPv4 access VPN and the IPv6 tunnel are completely independent. The IPv4 VPN configuration is beyond the scope of this book, but there are plenty of examples in references dedicated to this topic (refer, for example, to IPSec VPN Design by Vijay Bollapragada, et al.). Chapter 3, “Delivering IPv6 Unicast Services,” contains router configuration examples for the various IPv6 tunnel types. From a host perspective, the tunnel configuration depends on the particular operating system used. For example, if ISATAP is used in the topology shown in Figure 3-11 (Chapter 3) and the host is running Windows XP, the host tunnel configuration would be just one 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 network not 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 the IPv6 MTU to avoid fragmentation.

Tools Available for Securing IPv6 Networks

351

The “Topologies Examples” section of Chapter 7 shows an example of how to secure the IPv6 traffic 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 applies to any IPv6 tunnel type, static or dynamic. The example uses a static crypto map, which implies the fact that the routers have fixed IPv4 addresses and are using shared keys. You can implement dynamic maps when the routers acquire their IPv4 addresses dynamically, as in the case of remote sites provisioned every time they connect to the network.

Securing Router–to-Router Communication with IPv6 IPsec Until IPv6 IPsec is extensively and uniformly deployed as suggested by RFC 2460, it can still be used on a smaller scale. IPv6 IPsec can be leveraged to secure both the control and the data plane between two routers. The “OSPFv3” section of Chapter 4, “IPv6 Routing Protocols,” shows an example of using IPsec (with static key) to secure a routing protocol. Cisco IOS software also offers a mechanism for securing the data traffic between two routers through a new type of tunnel that employs IPv6 IPsec. IKEv1 is used for key management. Figure 9-4 shows a topology in which this feature is used between Routers A and B. Figure 9-4

Using IPv6 IPsec to Secure the Data Exchange Between Two Routers interface Tunnel0 ipv6 address 2001:2:1::1/64 ipv6 enable ipv6 cef tunnel source GigabitEthernet0/1 tunnel destination 2001:A:1::1 tunnel mode ipsec ipv6 tunnel protection ipsec profile ExampleIPsec

IPv6 Network FE0/1

2001:A:1::1

Router A

interface Tunnel0 ipv6 address 2001:1:1::1/64 ipv6 enable ipv6 cef tunnel source FastEthernet0/1 tunnel destination 2001:B:1::1 tunnel mode ipsec ipv6 tunnel protection ipsec profile ExampleIPsec

GigE0/1

2001:B:1::1

Router B

352

Chapter 9: Securing IPv6 Networks

Except for the tunnel itself, the configuration of this feature is similar to that used in securing the communication between two routers with IPv4 IPsec. On Router A, the steps to configure the IPsec portion 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: crypto isakmp key myPreshareKey0 address ipv6 2001:B:1::1/128

•

Configure the IPsec transform set that will be offered during negotiation to support ESP/3DES and the integrity algorithm: crypto ipsec transform-set 3des ah-sha-hmac esp-3des

•

Define the IPsec parameters that are to be used for IPsec encryption between the two IPsec routers: 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 and methods 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.

Access Control Lists Access control lists have proven themselves to be versatile instruments in identifying targeted traffic for further or particular processing or for filtering. For the most part, the IPv6 ACLs are similar 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 use of multiple addresses per interface has to be accounted for when designing the ACLs.

•

IPv6’s renumbering features can present challenges for ACLs when two different prefixes coexist on a given network segment.

•

The existence of potentially multiple EHs makes the ACL matching against the first fragment nondeterministic.

The implicit rules of the ACLs need to account for the fact that the ND process relies on a layer 3 protocol (ICMPv6).

The differences between the IPv4 and IPv6 ACLs stem from the IPv6 protocol specificities that have been discussed throughout this book.

Tools Available for Securing IPv6 Networks

353

Extended IPv6 ACLs and Stateful Filtering Extended ACLs are supported for IPv6 in a similar way to IPv4. Numbered ACLs are not supported for IPv6. Additional parameters are available to deal with some of the IPv6 protocol and operational specifics listed earlier. Example 9-1 Options Available in Cisco IOS Command Line When Configuring an IPv6 Access List Router(config)#ipv6 access-list EXAMPLE Router(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. They permit the neighbor advertisement and neighbor solicitation ICMP traffic, as shown here: permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any

Similar to IPv4, if the packet does not meet any of the matching criteria, it is dropped by default.

NOTE

The implicit rules for the IPv6 ACLs do not take into account the fact that IPv6 hosts need to do PMTU Discovery. To allow the PMTU Discovery process to work through the filters, the ICMPv6 Type 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 permit statement to generate an access entry for the return packets of a flow it allowed through (refer to the book Implementing Cisco IPv6 Networks by Regis Desmeules). This dynamic access entry can be in 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 REF ipv6 access-list OUT evaluate REF

354

Chapter 9: Securing IPv6 Networks

Based on the ACL called IN, any www TCP connection request that comes inbound interface FastEthernet6/1.10 for the server 2001:2::1 will be allowed through. For each connection, a dynamic permit entry is built under REF for the reply packet coming from the server. REF is included in the ACL called OUT, which will apply the return path dynamic entry outbound on the interface. The reflexive ACL entries are active for a period of time (3 minutes by default) or until a FIN is detected for a TCP session.

NOTE

The implicit deny any any does not apply at the end of reflexive ACLs. Multiple evaluate entries are allowed per ACL.

Time-based ACLs can be created for IPv6 in the same fashion as for IPv4. They identify ACLs that are 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 ACL matching process. In IPv4, most of the layer 3 and layer 4 information is available in the first fragment, so the ACL can perform a full match on it. The noninitial fragments typically would not contain the layer 4 information, so at most a match can be done on the layer 3 header. Because a host cannot use the noninitial fragments if the first fragment was filtered, it is safe to apply an ACL statement that contains layer 4 criteria only on the first fragment. The keyword fragment in an IPv4 ACL indicates that after the layer 3 information is checked, all noninitial fragments are permitted or pushed through the subsequent ACL line depending on whether the statement is a permit or a deny (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 reaching the Fragmentation header to extract the information on the fragment. Then it must parse through some more EHs to get to the upper-layer information. Therefore, the first fragment might not contain all the necessary information. In IPv6 ACLs, the keyword fragment has the same meaning as in IPv4 with the exception that the filter applies to all noninitial fragments as well if the upper-layer protocol cannot be determined from the first fragment.

NOTE

IPv6 supports a new keyword, undetermined-transport, for matching IPv6 packets for which the layer 4 information could not be extracted.

Tools Available for Securing IPv6 Networks

355

Firewalls can handle fragmented packets comprehensively. They can track all fragments by source address, destination address, protocol, and IP ID. This allows both the PIX and the Cisco IOS Firewall to apply the filtering policies to all fragments without any of the assumptions mentioned earlier.

IPv6 Access List Example The concepts presented in this section of the chapter are captured in a practical example for the topology shown in Figure 9-5. Figure 9-5

Topology for the Access List Example DNS 2001:B:1::/64

2001:A:1::D FD00:A:1::D

WWW Edge Router

IPv6 Internet

FE0/0

FE0/1

2001:1:1::1

2001:A:1::F 2001:A:1::1

FD00:A:1::F

FD01:A:1::1

IPv6 Network interface FastEthernet0/0 ipv6 address 2001:1:1::1/64 ipv6 traffic-filter EXAMPLE-IN in ipv6 traffic-filter EXAMPLE-OUT out

FD00:A::/32

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 should log any attempts to do so to track misconfigured hosts.

• • •

Block any outside traffic with the routing EH.

•

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.

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 to reply to that traffic.

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.

356

Chapter 9: Securing IPv6 Networks

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 the network. Figure 9-1 depicts the most commonly deployed security topology in IPv4, with the focus on the firewall. Such perimeter defenses will most likely be used in IPv6 networks, too. Two types of firewalls are offered through Cisco products: Cisco IOS Firewall features and the PIX family of products. Both these options are widely used in IPv4 networks, and now they support IPv6, too.

Tools Available for Securing IPv6 Networks

357

Cisco IOS Firewall The Cisco IOS Firewall capabilities are often used in current IPv4 deployments. Many of these capabilities have been extended to support IPv6 (refer to the Cisco document “Implementing Security for IPv6” at Cisco.com):

•

Packet fragment inspection uses the virtual fragment reassembly (VFR) to check for out-of-sequence fragments and duplicated fragments to identify possible DoS attacks. Note

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.

• • • •

Stateful inspection of UDP, TCP, ICMP, and FTP sessions.

Tunneled packet inspection is not performed inside the encapsulating IPv4 packet, but it can be done on the decapsulated IPv6 packet. 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 to customize the TCP and UDP ports being used (that is, so that they are different from the well-known ports). This feature enables them to exercise content-based access control even on a wider range of ports.

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 and on the same interfaces. Cisco IOS Firewall feature configuration involves several considerations. You can modify various parameters 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

continues

358

Chapter 9: Securing IPv6 Networks

Example 9-4 Cisco IOS Firewall Feature Configuration Options (Continued) max-incomplete name one-minute routing-header tcp udp

NOTE

Specify maximum number of incomplete connections before clamping Specify an inspection rule Specify one-minute-sample watermarks for clamping Enable session routing header inspection Config timeout values for tcp connections Config timeout values for udp flows

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 defined in 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 100 Router(config)#ipv6 inspect name FW-EXAMPLE udp timeout 100 Router(config)#ipv6 inspect name FW-EXAMPLE tcp timeout 100 Router(config)#ipv6 inspect name FW-EXAMPLE icmp timeout 60 Router#show ipv6 inspect all Session audit trail is enabled Session alert is enabled Routing Header inspection is disabled one-minute (sampling period) thresholds are [400:500] connections max-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 sec tcp idle-time is 3600 sec -- udp idle-time is 30 sec icmp idle-time is 10 sec Session hash table size is 1021 Inspection Rule Configuration Inspection name 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 icmp 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, as shown in Example 9-6. Example 9-6 Applying Security Policies to Router Interfaces Router(config-subif)#interface FastEthernet6/1.10 Router(config-subif)#ipv6 inspect FW-EXAMPLE in

continues

Tools Available for Securing IPv6 Networks

359

Example 9-6 Applying Security Policies to Router Interfaces (Continued) Router#show ipv6 inspect interface Interface Configuration Interface FastEthernet6/1.10 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 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 Router#debug ipv6 inspect icmp Mar 10 17:48:43.797: CBAC sis 69E1EAC4 2001:2:2:1::1:0) (2001:2:C1:A001::2:0) Mar 10 17:48:45.797: CBAC sis 69E1EAC4 2001:2:2:1::1:0) (2001:2:C1:A001::2:0)

L4 inspect bytes 1448 L4 inspect bytes 1448

result: PASS packet 6724896C ( icmp result: PASS packet 67249D34 ( icmp

The other important tool used to properly inspect the traffic is the virtual reassembly process, which has 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.10 Router(config-subif)#ipv6 virtual-reassembly Router#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 of interest. It lists the number of packets processed and the number of fragments that are being processed at the time.

PIX Firewall The PIX Firewall is a device dedicated to implementing perimeter security policies. It is widely deployed in existent IPv4 networks, so it is important to understand its IPv6 capabilities. PIX Firewalls will most likely be used to secure IPv6 services, too.

360

Chapter 9: Securing IPv6 Networks

PIX software release 7.0 is the first to support IPv6. It can perform security checks of IPv6 headers and EHs, multiple protocol (ICMP, UDP, TCP, SMTP, and HTTP) inspection, and through the adaptive security algorithm (ASA) it can perform stateful application inspection. For device-management purposes, the HTTP, SSH, and Telnet clients were also modified to support IPv6.

NOTE

In the PIX 7.0 software release, the Cisco Firewall does not support multicast except for what is necessary for autoconfiguration and ND. Multicast security can be implemented on the edge routers.

The IPv6 instructions for the PIX are Cisco IOS Firewall based, so they match the commands described 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 the same time, AAA is a security tool, too. No large-scale IPv6 deployment could be rolled out without available AAA supporting IPv6. In the first phase of the Cisco IPv6 implementation, the IPv6 AAA features were implemented by extending some of the vendor-specific attributes (VSAs) used for IPv4. Some of these VSAs have counterpart attributes that are RFC 3162 compliant and implemented for RADIUS. Table 9-2 summarizes 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 Attributes

RADIUS Attributes (RFC 3162)

VSAs

NAS-IPv6-Address

—

Framed-Interface-Id

—

It is a per-user attribute used during IPv6 Control Protocol (IPv6CP) negotiation to indicate the IPv6 interface identifier to be configured.

Framed-IPv6-Prefix

IPv6 Prefix#

It is a per-user attribute used to indicate the prefix to be configured on the user in the case of virtual access. This prefix is advertised in the ND messages. The network access server (NAS) installs a static route for the prefix.

Login-IPv6-Host

—

It is a per-user attributed that indicates the system that the user connects with when the Login-Service attribute is present.

Description

Tools Available for Securing IPv6 Networks

Table 9-2

361

IPv6 AAA and RADIUS Attributes (Continued)

RADIUS Attributes (RFC 3162)

VSAs

Description

Framed-IPv6-Route

IPv6 Route

It is a per-user attribute that specifies the routing information that should be configured for the user on the NAS.

Framed-IPv6-Pool

IPv6 Pool

It is a per-user attribute that identifies a pool from which prefixes are assigned to the user. The pool can be configured on routers or RADIUS servers.

—

IPv6 ACL

It specifies a full ACL that is applied to an interface while a user is logged in.

The configuration of these attributes is straightforward. Example 9-9 shows a user’s profile configured on the RADIUS servers. When the user connects to the NAS via PPP, it is provided with the global prefix 2001:A:1::/64. An ACL will be applied outbound to stop any traffic sourced from the unique-local addresses used internally. Example 9-9 RADIUS Server User Profile Example [email protected] Password = secret Service-Type = Framed, Framed-Protocol = PPP, Cisco-AVpair = “ipv6:prefix#1=2001:A:1::/64", Cisco-AVPair = "ipv6:outacl#1=deny FD00::/8 any"

These AAA features are important, particularly in the case of broadband deployments where large numbers of users have to be managed.

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 Control System Plus (TACACS+). Despite being more versatile than RADIUS, TACACS+ is not as commonly deployed because it is more resource intensive (requires more processing and memory). At the time of this writing, 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 as close as possible to the location of unsecured devices and hosts.

362

Chapter 9: Securing IPv6 Networks

An access network is a typical scenario where such policies can be applied. The service provider operating the network wants to make sure that its customers do not attempt to spoof an address on a different prefix from their own. Figure 9-6 shows the case where Host A is stopped from sending traffic using the address of Host B as a source address. Figure 9-6

Securing an Access Network from Internally Sourced Spoofing Attacks interface ATM0/0/0.1 point-to-point ipv6 address 2001:1:1:1::1/64 ipv6 verify unicast reverse-path pvc 1/33 encapsulation aal5snap

Host A IPv6

-Loa

IPv6 2001:1:1:1::2/64

d S A=

200

1:1:

1:2:

:2

Network Access Provider

DA

Host B Access Router

IPv6 2001:1:1:2::2/64 interface ATM0/0/0.2 point-to-point ipv6 address 2001:1:1:2::1/64 ipv6 verify unicast reverse-path pvc 1/34 encapsulation aal5snap

The intent is to verify at the access router that customer packets received on an interface have a source address that belongs to the prefixes known (based on the routing table) to be out that interface. Access lists can, of course, be applied inbound to filter the traffic accordingly; however, this can involve management and provisioning burdens. Another way to achieve the same goal in a dynamic manner is to implement for unicast a mechanism similar to Reverse Path Forwarding (RPF) used in multicast forwarding. Unicast Reverse Path Forwarding (uRPF) checks the routing information to verify that the prefix of an inbound packet’s source address is known to be reachable out the interface it was received on. The actual reverse lookup is done in the Cisco 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 was received or the source address cannot be identified (malformed source address), the packet is dropped.

Tools Available for Securing IPv6 Networks

363

This feature implements dynamically the functions of an inbound ACL. It is currently available in Cisco IOS software for both IPv4 and IPv6, and it represents a simple one-line interface configuration, as shown on Figure 9-6. If an ACL is designated at the end of the command ipv6 verify unicast reverse-path, the router applies it to the packet that failed the RPF check. The advantage of using the ACL option is that the ACL can be 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/32 encapsulation aal5snap ipv6 access-list exampleRPF permit ipv6 2001:1:1:1::/64 any log-input deny 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 let through 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 that the source address exists in the Forwarding Information Base (FIB) and that it is also known to be reachable out its interface that received the packet. The verification requirements can be relaxed, leading to a “loose mode” uRPF where the router only verifies a source’s reachability by checking for its existence in the FIB table and not the interface it belongs to. The Cisco IOS command to enable the feature is ipv6 verify unicast reachable-via .

Depending on platform, the performance impact of enabling these features should be considered.

Protecting the Control Plane with Rate Limiting To defend the network infrastructure from attacks, it is important to protect the controlplane resources of the network elements. Router resources (memory/CPU) on the line card or the route processor can be depleted by being 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’s control plane, such as flooding it with router solicitation traffic or packets with the routing header.

364

NOTE

Chapter 9: Securing IPv6 Networks

A router can be configured using the no ipv6 source-route command to stop processing packets that contain the source routing header.

At first, IPv6 services are likely to be considered of lower priority than the existent revenuegenerating IPv4 services. 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 potential threat. 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 thus preserve 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-limiting protection mechanisms in their default behavior, whereas others need to be configured for it. Some implement it in hardware, whereas others configure it in software. Cisco IOS command line offers a dedicated interface for configuring traffic rate limiting specifically for protecting a router’s control plane, as shown here: Router(config)#control-plane Router(config-cp)#service-policy input

This interface leverages the standard QoS tools. A service policy has to be defined based on the guidelines discussed 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 measures developed and field proven for IPv4 should be used in the case of IPv6. In review, the best practices that should be considered in securing an IPv6 deployment are as follows:

•

Address management and ND—Deploy an addressing scheme for communications with hosts within the 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. 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.

Summary of Best Practices for Securing IPv6 Deployments

365

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 network boundaries. Filter fragments. Deny IPv6 fragments destined to network elements. Drop fragments of packets for which 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 in the network.

•

Application security—Implementation at both host and network level (with the help of firewalls until IDS 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 over tunneling. If tunneling is used to interconnect IPv6 islands, static tunnels are preferred over dynamic ones because they are more secure.

You should apply these recommendations to hosts, routers, and firewalls as applicable. Before designing the security policies to be applied in an IPv6 deployment, it is important to evaluate the capability of the devices that support them. All the features necessary to implement the above best practices in Cisco IOS software and in Cisco Firewalls are currently available. The perimeter security topology described in Figure 9-1 is likely to be applied to the IPv6 deployments, too. It has proven itself in the IPv4 networks, and IPv6 services are likely to coexist with the IPv4 ones for a long time and therefore share a significant part of the infrastructure. Under these conditions, a first step in protecting the IPv6 deployments is to match the IPv4 security policies for IPv6. The next step is to implement those 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. They were preceded by deployments in research entities and governmentfunded organizations (for instance, in Europe, 6NET, RENATER, GEANT, and so on). Although the objectives and constraints of such networks differ from the industry-driven deployments, they have provided valuable experience in managing IPv6, experience that can be widely leveraged. A large part of this chapter therefore borrows from these experiences. 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 platforms— such as CiscoWorks and Hewlett-Packard OpenView (HP-OV)—is analyzed, too. The last section provides a review of network-management tools and applications that support IPv6.

IPv6 Network Management: The Challenges The challenge facing service providers (SPs), original equipment manufacturers, software vendors, and integrators is to develop robust applications that can perform various network-management operations in a changing, multivendor, multiplatform network. Introducing IPv6 network services raises a key challenge to the network-management and systems operations support systems (NMS-OSS) architects: coping with the technical differences between IPv4 and IPv6 technologies. New challenges related to network addressing, usability, and network access have to be dealt with when IPv6 is deployed.

368

Chapter 10: Managing IPv6 Networks

For instance, IPv6 addresses are awkwardly long and unsightly. Users will neither like to see long strings such as 2001:100:1234:5678:AB12:CD34:1121:2301 nor will they be able to easily recall them, let alone type them! Furthermore, IPv6 addresses can change dynamically because of features such as renumbering, privacy mechanisms, and autoconfiguration. Dealing with dynamic addresses is not something new for network-management systems (NMSs) when it comes to managing hosts. It is, however, a bigger issue with IPv6 because dynamic address allocation can happen outside a centralized place (such as stateful Dynamic Host Configuration Protocol [DHCP] server), depriving the NMS of a convenient central repository of active hosts addresses. From the user perspective, the IPv6 services bring up questions that revolve around ease of use. Handling the large IPv6 addresses is cumbersome, so the use of Domain Name Systems (DNS) becomes more important for IPv6 deployments. The guideline is for applications to use just host names, which are user friendly, and the DNS can take care of renumbering and fallback. Another challenge for managing IPv6 relates to integration with IPv4 network management: How should operators manage parallel IPv4 and IPv6 services and resources, because IPv4 and IPv6 are expected to coexist for the foreseeable future? IPv6 and IPv4 network-management concepts, requirements, and issues are much alike. This makes the challenges easier to tackle. The tools and applications necessary to meet the IPv6 network-management requirements are therefore mostly identical to the IPv4 ones. In most cases, managing IPv6 will entail providing proper IPv6 support within existing management tools, proper data availability from IPv6-enabled devices, and IPv6-enabled communications channels between the two.

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 multiple addresses configured on an interface are common and expected with IPv6. For an NMS to communicate with an IPv6 node, it is likely that global unicast addresses (could be unique-local) will be used to manage all network elements from a central location. The network operator has multiple options in selecting the mechanism to assign global addresses to nodes: static configuration, autoconfiguration, stateful or stateless DHCPv6, 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

IPv6 Network Management: The Challenges

369

not a scalable option, especially when considering the fact that renumbering is a fact of life in a network. Nevertheless, on networking devices and application servers, it is recommended to assign a static address that will be known from the NMS. In case of hardware 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 a concern. Upon receiving multiple router advertisements (RAs) from on-link routers, a host builds multiple addresses, 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 hosts such as desktop and laptops. Although stateful DHCP proves quite useful with IPv4 in helping the NMS to learn node addresses, stateful DHCPv6 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 Provisioning Management.”

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 could manage the IPv6 devices just like any other IPv4 device as long as they have IPv4 reachability from the network-management platform. As a major evolutionary step, IPv6 introduces numerous mechanisms and features in the area of transitioning and coexistence with IPv4, including tunneling mechanisms (manual and automatic), IPv6 over MPLS (6PE and 6VPE), and translation mechanisms (NAT-PT). All these mechanisms are reviewed at length in Chapter 3, “Delivering IPv6 Unicast Services,” and Chapter 7, “VPN IPv6 Architecture and Services.” Although they help 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, the NMS must be provided with the capability to traverse those tunnels. It might mean that the NMS supports some 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 the randomization in some cases of address assignment makes it impossible for an

370

Chapter 10: Managing IPv6 Networks

NMS to scan the complete prefix range for active hosts. At the same time, link-locals are often the only addresses reported from neighbor caches, making the topology discovery a true challenge. In practice, topology discovery of IPv6 networks is likely 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 the cost of additional network operation complexity. To minimize this extra complexity, network operators might choose 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 the network design itself. For instance, some SPs have expressed a preference for an IPv6 over IPv4 tunnel network design (see Chapter 3 for details) over deploying native IPv6 to reduce operating costs such as network management.

Dual-stack devices appear to offer a practical option for managing IPv6. The type of managed objects and the protocol used to transport the information are independent. For instance, Simple Network Management Protocol (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 minimum changes 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 a different administration group. In Figure 10-1, network core, aggregation, and edge are under a single SP responsibility, and managed as a single entity. The access network and each remote site are managed separately. Each domain is under the control of an operation support organization. This organization manages the network 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 Architecture

371

Figure 10-1 Network-Management Architecture

Access Edge Aggregation

Core/Aggregation/Edge Management Domain

Access Management Domain

Core

Site Management Domain

Site

Network-management functions are detailed in the “FCAPS” framework specified by the ITU’s Telecommunications Management Network (TMN) as follows:

•

Fault management—The goal is to detect, report, notify users of, troubleshoot, and (to the extent possible) automatically fix network problems to keep the network running effectively. Fault management encompasses several key subservices: — Traffic monitoring—Its purpose is to gather traffic statistics and trigger alerts when anomalies are detected. Several tools can provide this service today with IPv6; for instance, Cisco NetFlow Collector (NFC), Cisco Network Analysis Module (NAM), Argus, and Nagios.

372

Chapter 10: Managing IPv6 Networks

— Topology monitoring— The goal is to perform network topology discovery, and to monitor network resources such as interfaces, links, nodes, networks, and so on. Many tools can provide 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 the network. ASpath-tree, for instance, will provide this support for IPv6 Border Gateway Protocol (BGP) tables. • Performance management—The goal is to measure and make available various aspects of network performance (network throughput, user response times, and line utilization). Cisco IOS IP service level agreements (IP SLAs, formerly Service Assurance Agent [SAA]), for instance, can achieve this service 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 so that 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 or group uses on the network can be regulated and billed appropriately. Traffic monitoring, mentioned previously, 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 that the network cannot be sabotaged (intentionally or unintentionally) and sensitive information cannot be accessed by those without appropriate authorization. Depending on the managed domain, the choice of management tools varies, even though management flows do exist between entities (as shown in Figure 10-1). Integrated management platforms are the norm in the core management domain, typically HP-OV coupled with CiscoWorks. Availability of IPv6 support on these NMSs becomes a key requirement for deploying IPv6 in the core. On the site-management domain, depending on 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- and performancemonitoring tools with IPv6 support are now available for use in this type of environment. All these 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 as for 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, and so on.

Retrieving Information from Routers and Switches

373

SNMP and MIBs The Simple Network Management Protocol (SNMP) is a request-reply-based protocol running over UDP (ports 161 and 162), although TCP operation is also possible. SNMP is used by the NMS to access or modify data in the managed devices via objects called Management Information Bases (MIBs). A MIB is a hierarchy of information that describes an SNMP-manageable object. Each object is associated with a unique object identifier descriptor (OID). The MIB is organized as a tree; the leafs are the object instances representing a resource (interface address, interface name, event, and so on). MIBs are either standard (described in RFCs) or enterprise specific. Given the relatively slow progress of IPv6 MIB definitions, a large number of enterprise-specific MIBs have been published, including several Cisco ones. SNMP is an asymmetric protocol, operating between a management station and an agent, the device being managed. Typically, the agent is a router or a switch that implements a few simple packet types and a generic get-or-set function on its MIB variables. The management station provides the user interface. Simple management stations 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 draw network maps. An SNMP operation takes the form of a protocol data unit (PDU). Version 1 SNMP supports five possible PDUs:

•

GetRequest/SetRequest supplies a list of objects and, possibly, values they are to be set to.

•

GetResponse informs the management station of the results of a GetRequest or SetRequest.

• •

GetNextRequest is used to perform table transversal. Trap is the only PDU sent by an agent on its own initiative. It is used to notify the management station of an unusual event.

SNMP version 2 (SNMPv2) is an evolution of the SNMPv1. SNMPv2 introduces two new operations: GetBulk and Inform. The GetBulk operation is used to retrieve large blocks of data. The Inform operation allows two SNMP entities to exchange acknowledged information. SNMP version 3 (SNMPv3) adds security and remote-configuration capabilities. There are two distinct aspects for supporting IPv6 SNMP: the transport of SNMP protocol over IPv6 and the IPv6 MIBs support.

SNMP over IPv6 Because SNMP runs over UDP, an SNMP over IPv6 implementation is mostly about UDP 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 transport protocol (UDP over

374

Chapter 10: Managing IPv6 Networks

IPv6, for instance) used by the incoming request. When sending an SNMP trap, the router needs to be configured with an IPv6 destination, as illustrated in the Example 10-1. Example 10-1 SNMP Configuration Example snmp-server snmp-server snmp-server snmp-server snmp-server snmp-server

community public RO enable traps syslog enable traps mpls ldp enable traps mpls traffic-eng enable traps mpls vpn host 2001:400::1 version 2c public

On the NMS side, most SNMP application programming interfaces (APIs) support SNMP over IPv6:

• • • • NOTE

Sun’s Java J2SDK/JRE 1.4 FreeBSD Linux Windows

Running SNMP over IPv6 is required only for IPv6-only devices. In the most common case, IPv6-managed devices are dual stack, and need to report management data for both IPv4 and IPv6. Historically, these devices have been configured for IPv4 first and have IPv4 connectivity to the NMS: Enabling of IPv6 can and should be done without disturbing the existing NMS/device transport and configuration. Because the transport (UDP) and the content (MIBs) are independent of each other, you can keep the IPv4 transport to carry SNMP IPv6 data.

IPv6 MIBs More than 100 MIBs are available to check for IPv6 support, and they can be classified as 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 a long time,

Retrieving Information from Routers and Switches

375

because the initial approach of creating separate MIBs for IPv6 (with an ipv6Address) 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 IP Forwarding Table MIB RFC1354

RFC2096

MIB for Network Management of TCP/IP+Based Internets: MIB-II

RFC1158

Unified-MIBs

Uses inetAddress

RFC2011

RFC1213

RFC2012 RFC2013

draft-ietf-ipv6-rfc2096-update-07.txt

IP/ICMP MIB

draft-ietf-ipv6-rfc2011-update-10.txt

TCP MIB

RFC4022

UDP MIB

Uses ipAddress

Uses IPv6 Address

RFC4113

RFC2465

MIB for IPv6

RFC2466

MIB for ICMPv6

RFC2452

MIB for TCPv6

RFC2454

MIB for UDPv6

RFC2466 IPv4:ipAddress STRING SIZE(4)

Evolution of the Textual Convention

RFC2465

RFC2851

RFC3291

IP:inetAddresstype, inetAddress INT STRING SIZE(0..255)

IPv6:ipv6Address STRING SIZE(16)

1990

1991

1992

1993

1996

1997

1998

2000

2001

2002

Two sets of basic MIBs are defined for supporting IPv6-related information. One set is based 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:

• • • • •

IPV6-TC (RFC 2465) IPV6-TCP-MIB (RFC 2452) IPV6-UDP-MIB (RFC 2554) IPV6-MIB (RFC 2465) IPV6-ICMP-MIB (RFC 2466)

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 an address. These MIBs are sometimes referred to as unified MIBs. The basic IPv6 MIBs supporting that textual convention are as follows:

•

INET-ADDRESS-MIB (RFC 3291) (defines basic generic types for Internet address (IPv4, IPv6, DNS)

•

IP-MIB (draft-ietf-ipv6-rfc2011-update)

376

Chapter 10: Managing IPv6 Networks

• • •

TCP-MIB (RFC 4022) UDP-MIB (RFC 4113) IP-FORWARD-MIB (draft-ietf-ipv6-rfc2096-update)

At the time of this writing, both the IP-MIB and the IP-FORWARD-MIB are in the IETF Editor Queue, as Proposed Standards, which means close to completion. Although some network equipment (Hitachi, NEC, Juniper) and NMS (HP-OV) vendors currently support IPv6-specific MIBs (based on RFC 2465), others, including Cisco routers, support some version of the unified MIBs (based on RFC 3291). Because the latter are not yet published RFCs, the support remains private, and based on various version of the Internet Draft. Cisco, for example, implemented the draft version for “IP Forwarding Table MIB” and “IP MIB” as a private MIB (update-00). However, because the unified MIBs are becoming standard, Cisco actively works on their support, and it is expected that the NMSs (HP-OV and so on) will integrate them.

BGP and Other MIBs The BGP IPv6 MIBs are lagging behind the needs of today’s networks. The BGP multiprotocol extensions (MP-BGP) enable BGP to exchange routing information for different types of address families (for instance, IPv6), identified by an Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI). RFC 1657 describes BGP4 MIBs, without the multiprotocol bits required to report information about IPv6 and VPNv6 (as well as VPNv4 and multicast). An update of RFC 1657 is currently in the IETF RFC queue (draft-ietf-idrbgp4-mib), but it also fails to provide MP-BGP information (still uses ipAddress). On the other end, an MP-BGP MIB (draft-ietf-idr-bgp4-mibv2) is revising RFC 1657 with much larger ambitions. For several significant capabilities, such as BGP communities (RFC 1997), autonomous system confederation (RFC 3065), BGP multiprotocol extensions (RFC 2858), and route reflection (RFC 2796), the document proposes object types to manage those extended capabilities and their operation. As far as 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 on inetAddress will be an important first step toward managing these features. In addition, draft-ietf-idr-bgp4-mibv2 allows transport-independent address indices consistent with the AFI and SAFI mechanisms of that extension. Some router vendors implement this MIB as a private MIB. Cisco implements another BGP MIB (CISCOBGP4-MIB), which also handles multiprotocol BGP, with a different format. The following excerpt shows the SAFI support in this MIB: CbgpSafi ::= INTEGER { unicast(1), multicast(2), unicastAndMulticast(3), vpn(128) }

Retrieving Information from Routers and Switches

377

In theory, nothing prevents the MIB (and the corresponding address, defined as OCTET STRING(SIZE[0..255]), from supporting IPv6 and VPNv6 addresses. In practice, at the time of this writing, the Cisco SNMP agent does not expose the IPv6, 6PE, and VPNv6 BGP information. Some other MIBs, such as IP Tunnel MIB, are not yet at a point where they are ready for publication. Many MIBs require further study, although they would be useful for managing IPv6 networks:

• • • •

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 from a Cisco router. In the following example, the CISCO-IETF-IP-FORWARD-MIB is loaded into the MIB browser. Example 10-2 shows an excerpt of the MIB for the route entry: Example 10-2 CISCO-IETF-IP-FORWARD-MIB Route-Entry Example CInetCidrRouteEntry ::= SEQUENCE { cInetCidrRouteInstance cInetCidrRouteDestType cInetCidrRouteDest cInetCidrRoutePfxLen cInetCidrRouteNextHopType cInetCidrRouteNextHop cInetCidrRouteIfIndex cInetCidrRouteType cInetCidrRouteProto cInetCidrRouteAge cInetCidrRouteNextHopAS cInetCidrRouteMetric1 cInetCidrRouteMetric2 cInetCidrRouteMetric3 cInetCidrRouteMetric4 cInetCidrRouteMetric5 cInetCidrRouteStatus }

Unsigned32, InetAddressType, InetAddress, InetAddressPrefixLength, InetAddressType, InetAddress, InterfaceIndex, INTEGER, IANAipRouteProtocol, Integer32, InetAutonomousSystemNumber, Integer32, Integer32, Integer32, Integer32, Integer32, RowStatus

Using the MIB browser, you can execute a (series of) GET-NEXT and display the resulting tree, as shown in Figure 10-3.

378

Chapter 10: Managing IPv6 Networks

Figure 10-3 MIB Example Using a MIB Browser

Forwarding MIBII on the MIB Browser clnetCidrRouteIfIndex. value 0.2.16.32.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 8 0.2.16.32.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.128.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 8 0.2.16.64.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 9 0.2.16.64.1.0.0.0.0.0.0.0.0.0.0.0.0.0.2.128.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 9 0.2.16.202.254.0.16.0.0.0.0.0.0.0.0.0.0.0.0.64.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 13 0.2.16.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.10.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 12 0.2.16.255.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 12

Router#show ipv6 cef 2000::1/128 Ethernet3/0 2000::/64 Ethernet3/0 4001::/64 Ethernet3/1 4001::2/128 Ethernet3/1 CAFE:10::/64 Loopback0 FE80::/10 Null0 FF00::/8 Null0 Forwarding Table on the Router

ifDescr.1 ifDescr.2 ifDescr.3 ifDescr.4 ifDescr.5 ifDescr.6 ifDescr.7 ifDescr.8 ifDescr.9 ifDescr.10 ifDescr.11 ifDescr.12 ifDescr.13 ifDescr.14 ifDescr.15 ifDescr.16

Serial2/0 FastEthernet0/0 FastEthernet0/1 Serial1/0 Serial1/1 Serial1/2 Serial1/3 Ethernet3/0 Ethernet3/1 Ethernet3/2 Ethernet3/3 Null0 Loopback0 Loopback100 Ethernet3/1-mpls layer Ethernet3/3-mpls layer

For a better understanding of the MIB browsing result, it is possible to execute the show ipv6 cef command on the router. The resulting output, shown in Figure 10-3, contains details about the router forwarding table that relate directly to the MIB-2 content. For example, CAFE:10::/64 appears in the MIB with the ASN.1 notation as follows:

• • • NOTE

Prefix—202.254.0.16.0.0.0.0.0.0.0.0.0.0.0.0 Length—64 If index—13 (Loopback0)

The unified MIB-2 MIBs are defined for both IPv4 and IPv6. In theory, the devices should respond to SNMP queries with values for both protocols. However, current Cisco implementations retrieve only IPv6 (type 2) addresses for the MIB-2, although the IPv4only MIBs must be used to retrieve IPv4 data.

NetFlow Cisco IOS NetFlow provides network administrators with access to information concerning IP flows within their data networks. NetFlow includes three key components that perform the following functions:

•

Flow caching collects IP data flows entering router or switch interfaces and prepares data for export. It enables the accumulation of data on flows with unique

Retrieving Information from Routers and Switches

379

characteristics, such as IP addresses, application, and class of service (CoS). When enabled for IPv6 traffic, flow caching can record IPv6 flows, and aggregate them according to the configured aggregation policy. The flows captured 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 stores this summarized or aggregated data.

•

Flow analyzer displays and analyzes NetFlow data collected from flow collector files. This allows users to complete near real-time visualization or trending analysis of recorded and aggregated flow data.

Figure 10-4 highlights these three components in the network. Figure 10-4 NetFlow Architecture Netflow Router

Netflow Router

IPv6 Network

IPv6 Traffic

IPv6 Traffic

IPv6 Flow Exporting Over UDP4

Third-Party Collector and Applications

Netflow Collector

• Flow Capture • Flow Aggregation • Flow Exporting

• Data Collection • Data Filtering • Data Aggregation • Data Storage

• Data Presentation • NFC Control • NFC Configuration

Ciscoworks

Netflow Data Analyzer

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)

380

Chapter 10: Managing IPv6 Networks

• • • • •

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 prefix mask)

The basic output of NetFlow is a flow record. Several different formats for flow records have evolved as NetFlow has matured. The most recent evolution of the NetFlow flowrecord format is known as version 9. IPv6 flows can only be reported under that version. 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. Table 10-1

IPv6 NetFlow Fields Field Type

Value

Length (Bytes)

Description

IPV6_SRC_ADDR

27

16

IPv6 source address

IPV6_DST_ADDR

28

16

IPv6 destination address

IPV6_SRC_MASK

29

1

Length of the IPv6 source mask in contiguous bits

IPV6_DST_MASK

30

1

Length of the IPv6 destination mask in contiguous bits

IPV6_FLOW_LABEL

31

3

IPv6 flow label as per RFC 2460 definition

IP_PROTOCOL_VERSION

60

1

Internet Protocol version set to 4 for IPv4, set to 6 for IPv6 (If not present in the template, version 4 is assumed.)

DIRECTION

61

1

Flow direction: 0—ingress flow; 1—egress flow

IPV6_NEXT_HOP

62

16

IPv6 address of the next-hop router

BPG_IPV6_NEXT_HOP

63

16

Next-hop router in the BGP domain

IPV6_OPTION_HEADERS

64

4

Bit-encoded field identifying IPv6 option headers found in the flow

The IPv6 option headers are reported into a 32-bit field, as shown in Table 10-2, only when the router is configured to do so. This is because this recording can impact the router performances; to obtain the option 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

Retrieving Information from Routers and Switches

381

looked at in a transit node. This scanning might lead certain hardware routers to punt the IPv6 packets to a software path, with some performance consequences. Table 10-2 shows how the field IPV6_OPTION_HEADERS is encoded. 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

9

Authentication header

51

10

Encrypted Security Payload

50

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 ingress ipv6 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 the collector. The following configuration example shows how to configure the raw IPv6 NetFlow cache on a Cisco router and export v9 records.

Example 10-4 NetFlow Configuration for Raw Flow Capture interface Ethernet3/0 ip address 100.1.1.2 255.255.255.0 ipv6 address 2001:100::2/64 ipv6 flow ingress ipv6 flow egress ! ip flow-export version 9 ipv6 flow-export source FastEthernet0/0 ipv6 flow-export destination 172.18.102.245 10000

382

Chapter 10: Managing IPv6 Networks

With a configured frequency, the NetFlow routers export the raw data to the NetFlow Collector (in this example, 172.18.102.245). The collector can then aggregate the flows and produce statistics and alerts. Several IPv6 NetFlow Collectors, including Cisco NFC, are reviewed in the section “Flow Analysis Using NetFlow.”

•

Flows can be aggregated on the NetFlow routers before they are exported to the collector. A specific aggregation cache is then created on the router and mapped onto the chosen aggregation scheme. Example 10-5 illustrates how this can be done.

Example 10-5 NetFlow Configuration with Flow Aggregation ipv6 flow-aggregation cache bgp_nexthop cache entries 100000 export version 9 enabled ipv6 flow-export source FastEthernet0/0 ipv6 flow-export destination 172.18.102.245 10000

On the router, a distinct aggregation cache is created for each IPv6 aggregation scheme (autonomous system, BGP next hop, protocol port, source prefix, destination prefix, prefix). Table 10-3 lists fields set 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

*

*

*

*

*

*

Source Prefix

*

Destination Prefix

* *

Protocol

*

Source Port

*

Destination Port

*

Source Interface

*

*

Destination Interface

*

*

Source BGP Autonomous System

*

*

Destination BGP Autonomous System

*

*

*

*

* *

*

* *

*

*

Retrieving Information from Routers and Switches

Table 10-3

383

NetFlow Aggregation Schemes (Continued)

Field/ Aggregation Scheme

Autonomous System

BGP Next Hop

Protocol Port

Source Prefix Mask

Source Prefix

Destination Prefix

*

Destination Prefix Mask BGP Next Hop

Prefix *

*

*

x

x

*

Next Hop OR’d TCP Flags

x

*: fields recorded and part of the aggregated record key X: fields recorded but not part of the key

•

A third option, useful in testing phases but not recommended in real-life deployments, is to obtain router statistics and counters via the router command-line interface (CLI). Example 10-6 shows the detailed output of the show NetFlow command.

Example 10-6 NetFlow Cache Display Router#show ipv6 flow cache IP packet size distribution (10761 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .280 .307 .377 .034 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 475168 bytes 25 active, 4071 inactive, 3324 added 53962 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 33928 bytes 0 active, 1024 inactive, 0 added, 0 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:400::2 Local 2001:400::1 Et3/0 0x3A 0x0000 0x8100 5 2001:300::2 Local 2001:300::1 Et3/0 0x3A 0x0000 0x8100 5 2001:200::2 Local 2001:200::1 Et3/0 0x3A 0x0000 0x8100 5 2001:300::1 Et3/0 FF02::1:FF00:2 Local 0x3A 0x0000 0x8700 2 2001:400::1 Et3/0 FF02::1:FF00:2 Local 0x3A 0x0000 0x8700 2 2001:400::1 Et3/0 2001:400::2 Local 0x06 0x2B00 0x0017 88 2001:400::2 Local 2001:400::1 Et3/0 0x06 0x0017 0x2B00 38 2001:300::2 Local 2001:300::1 Et3/0 0x06 0x0017 0x2B01 29 2001:300::1 Et3/0 2001:300::2 Local 0x06 0x2B01 0x0017 70 2001:500::72A Et7/0 2001:800::25C Eth8/00x06 0x2B01 0x0017 123

384

Chapter 10: Managing IPv6 Networks

Out of the three methods reviewed, the first one (export raw data) should be preferred, as long as the interface for exporting the data can handle the overhead of massive flow export. If it cannot, aggregating flows on the router before exporting them will reduce this overhead while using router resources. Accessing NetFlow counters 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 are currently sent over IPv4 UDP.

NOTE

Unlike IPv4, the IPv6 main cache (with no aggregation configured on the router) can aggregate addresses based on a configured mask length. This capability was required with IPv6 because of the larger address space. Flows that differ only by a source or destination within the same prefix range (bounded by the configured mask length) are aggregated at capture time. The following example shows how this can be configured.

Example 10-7 NetFlow Mask-Length Configuration Router#show running interface 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 recording full 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, and other devices. It is intended to provide this information as input for various applications. IPfix is a general data-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 provisions to support IPv6 addresses and all flexibility to fit future IPv6 needs. When available, it will possibly replace NetFlow as the next-generation flow-analysis tool. However, at the time of this writing, no production implementation 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. IPfix data provides fine-grained measurements (for example, flow

Retrieving Information from Routers and Switches

385

records include details such as IP addresses, packet and byte counts, time stamps, type of service [ToS], and application ports) for highly flexible and detailed resource-usage accounting. Internet service providers (ISPs) can use this information to migrate from single-fee, flatrate billing to more flexible 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 cost allocation for resource usage. For accounting purposes, it would be advantageous to have the ability to use IPfix flow records as accounting input in an authentication, authorization, and accounting (AAA) infrastructure. AAA servers could provide the mapping 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 should be no problem in reporting IPv6 data with IPfix, provided only that the transport protocol being used to carry IPfix 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 from routers. They do not define the format of what is being uploaded (or downloaded), but they provide access to devices where specific commands can be executed. Similar to the other retrieval tools, even when they connect 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 the local 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 password must be created to enable Telnet access to an IPv6 router. The following configuration illustrates how to enable the IPv6 Telnet server on a Cisco router.

Example 10-8 IPv6 Telnet Configuration Router#show running ipv6 host sophia 2001:100::1 line vty 0 4 password mypassw login

386

Chapter 10: Managing IPv6 Networks

A Telnet client can connect using telnet Router and execute a local command (for instance, to retrieve interface statistics), as shown in Example 10-9. Example 10-9 Displaying Router Statistics over a Telnet Session Router#show interfaces accounting FastEthernet0/0 ProtocolPkts InChars In Pkts Out Chars Out IP 232 13920 13179 1055192 ARP 0 0 2 120 CDP 1295 488215 1295 624190 IPv6 87 7343 10821 1154992 Serial3/0 ProtocolPkts InChars In Pkts Out Chars Out IP 1032152 172480455 971046 99846637 CDP 11848 4703656 11851 4633741 IPv6 72565 6178060 72582 6304396

•

SSH—Secure Shell can be handy for connecting to a device over a secure connection and retrieving information. On Cisco routers, configuring SSH for IPv6 is not different from its configuration for IPv4. It requires the following: — An IPsec (Data Encryption Standard [DES, 3DES] or AES) encryptionsoftware Cisco router image. — A host name and host domain must be configured. — A Rivest, Shamir, and Adelman (RSA) key pair, which automatically enables SSH, must be generated for the router.

•

RSH—Remote Shell enables users to execute commands remotely. Remote Copy (RCP) enables users to copy files to and from a file system residing on a remote host or server on the network. Example 10-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) to display interface status.

Example 10-10 Configuring a Server for RSH and Executing Commands Remotely Router-B#show running | include ip rcmd ip rcmd rcp-enable ip rcmd rsh-enable ip rcmd remote-host Router-A 50.1.1.1 Router-A enable Router-A#rsh 50.1.1.2 /user Router-A show ipv6 interface brief Ethernet0/0 [up/up] FE80::A8BB:CCFF:FE01:F600 2001:100::72B Ethernet1/0 [up/up] unassigned Loopback0 [up/up] FE80::A8BB:CCFF:FE01:F600 2001:101::123

Retrieving Information from Routers and Switches

387

Note that although Example 10-10 shows how to configure RSH over an IPv4 transport, RSH over an IPv6 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 copy EXEC command accepts a destination IPv6 address or IPv6 host name as an argument and saves the running configuration of the router to an IPv6 TFTP server, as follows: Router#copy running-config tftp://[2001:100::1]/running-config

•

FTP—FTP can also be used to upload/download information to/from devices. Although FTP runs over TCP, having IPv6 TCP support is not enough to get FTP working over IPv6. FTP messages include a host address, and the initial FTP specification assumed network addresses of 32 bits in length. RFC 2428 specifies FTP extensions for IPv6. On Cisco routers, at the time of this writing, FTP over IPv6 is not yet supported.

In many cases, Looking Glass can be set up to enable authorized users to access IPv6-enabled devices from a web interface and to run specific commands. Looking Glass typically uses Telnet, SSH, or RSH to execute the request on the device. The IPv6 information can be acquired over IPv4 or IPv6. The example illustrated in Figure 10-5 shows one of these Looking Glass outputs used on the regional Picardie (France) IPv6 network. Figure 10-5 IPv6 Looking Glass

Output for "show ipv6 traffic" on 7600_UTC: IPv6 statistics: Rcvd: 6499726 total, 1541940 local destination 0 source-routed, 0 truncated 0 format errors, 97 hop count exceeded 0 bad header, 0 unknown option, 0 bad source 0 unknown protocol, 0 not a router 0 fragments, 0 total reassembled 0 reassembly timeouts, 0 reassembly failures Sent: 3629007 generated, 2064907 forwarded 0 fragmented into 0 fragments, 0 failed 759 encapsulation failed, 939762 no route, 0 too big Mcast: 1150469 received, 74330 sent ICMP statistics: Rcvd: 1455892 input, 0 checksum errors, 0 too short 9 unknown info type, 0 unknown error type unreach: 0 routing, 0 admin, 0 neighbor, 1 address, 89 port parameter: 0 error, 0 header, 0 option 178 hopcount expired, 0 reassembly timeout,0 too big 41 echo request, 684710 echo reply

388

Chapter 10: Managing IPv6 Networks

Fault Management As already mentioned, fault management encompasses traffic management, topology monitoring, and routing management. Traffic management is one of the keystones of successfully deploying services and applications. It encompasses a large variety of tools and features to follow the life cycle of new deployments: from traffic measurement to traffic analysis, before and after new service is deployed, from link management to node status, to end-to-end service-level management. A large part of traffic management deals with network troubleshooting, to provide in-depth analysis of traffic. Most of the tools can generate reports and alerts to assist the network administrator in identifying problems, isolating, and then troubleshooting them. Note that many tools used for traffic management are also used for performance monitoring, such as Argus and Nagios. These tools are reviewed in the section “Performance Management.”

Flow Analysis Using NetFlow The NetFlow Collector receives UDP packets containing flow exports from the NetFlow router and stores them. Flow content can be used for a variety of purposes, including network management and planning, enterprise accounting, Internet service provider (ISP) billing, data warehousing, mitigation of denial-of-service (DoS) attacks, and data mining for marketing purposes. 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. A number of NetFlow Collectors and analyzers are available, including several that support the v9 export format, hence IPv6:

•

Ntop (nProbe)—Available for UNIX (including Mac OS X), Windows, and embedded environments, 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 to configuration, port-scan detection, storage of aggregated data in RRDtool, and graphical 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 the following functions:

•

NetFlow data collection from multiple export devices

Fault Management

• • •

389

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 files based on user-defined criteria specified in a CNS NetFlow Collection Engine aggregator. An aggregator is an aggregation task defined by a set of user-configurable attributes that specify how CNS NetFlow Collection Engine summarizes the traffic flows that are received. Two important aggregator attributes are as follows:

•

Aggregation schemes—Defines the subset of data of interest in a traffic flow, as well as which 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 help collect NetFlow export and summarize the data. Moreover, in release 5.0, you can modify any of the predefined aggregation schemes or define your own aggregation schemes. You can also use 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 filters specified data from supported Cisco routers and switches. Output is stored in files that are 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.

•

CNS/XML interface— The CNS/XML interface is used to send and receive configuration/control requests and responses and unsolicited event notifications.

•

Report generator—The report generator produces hourly and daily reports based on collector output files by performing further aggregation of the records in these files based on criteria selected by the user.

•

BGP peer—A passive BGP peer is provided to supplement CNS NetFlow Collection Engine output with BGP attributes.

Starting with NFC 5.0, Cisco NetFlow Collector supports IPv6. This means that it can collect NetFlow v9 records, including records with IPv6-specific fields, aggregate them according to the aggregation scheme configured on the NFC interface, and generate reports and alerts specific to IPv6. The screen captures in Figures 10-6 and 10-7 illustrate one of the NFC configuration steps for IPv6 (NetFlow Export field) and show a simple IPv6 report.

390

Chapter 10: Managing IPv6 Networks

Figure 10-6 Configuring NFC: Fields

Figure 10-7 Sample of an NFC report

Fault Management

391

For more detail about Cisco NFC and its IPv6 support, refer to the NFC 5.0 configuration guides.

IPFlow IPFlow is a collector for NetFlow v1, v5, v6, v7, v8, and v9. It was initially developed for managing the Picardie regional network, but is freely available. The primary design goal was to provide a tool suited for troubleshooting networking issues such as link congestion of unexpected traffic. It supports logging flow data to disk, data aggregation according to configuration, port-scan detection, 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 in Cisco Catalyst 6500 series switch or Cisco 7600 series router chassis that provides integrated network-monitoring services within the switch or router. The NAM collects statistics on network traffic and is used for real-time traffic analysis, performance monitoring, and troubleshooting. The NAM monitors and analyzes network traffic using remote monitoring (RMON), RMON extensions for switched networks (SMON), and other Management Information 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 and NetFlow 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 NAM without any SPAN sessions being created. NetFlow can also be enabled on interfaces on remote 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 so on directly from the traffic analyzer or other thirdparty tools. Table 10-4

Cisco Catalyst 6500 Series and Cisco 7600 Series NAM Data Sources Data Source

Description

SPAN and Remote SPAN (RSPAN)

Using the SPAN and RSPAN capabilities of Cisco Catalyst 6500 series switches, traffic from ports, VLANs, and EtherChannel links can be mirrored to the Cisco NAM. The NAM collects statistics on all layers of network traffic spanned to it.

VLAN access control lists (VACLs)

The Cisco NAM uses VACLs to capture or “filter” selected VLANs and WAN traffic (on Cisco IOS software only) to the NAM ports. Additional filtering rules can also be applied to target specific data flows. continues

392

Chapter 10: Managing IPv6 Networks

Table 10-4

Cisco Catalyst 6500 Series and Cisco 7600 Series NAM Data Sources (Continued) Data Source

Description

NetFlow Data Export (NDE) local

NDE records offer an aggregate view of the network traffic. When enabled on the switch, the NetFlow data source becomes available on the Cisco NAM without the need to create any SPAN sessions.

NetFlow Data Export (NDE) from remote devices

The Cisco NAM can receive NDE from remote devices for analysis.

NDE records offer greater traffic-monitoring capacity because this data source is available (when enabled from the switch) without creating any SPAN sessions to the Cisco NAM. The NAM can provide information on the packets through the NDE records without having to examine each packet, and thus allow for more traffic 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 IPv6enabled “NetFlow Collector 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 and configure IPv6 capture filters and IPv6 historical reports. Figures 10-8 and 10-9 are NAM traffic analyzer screen captures, showing, respectively, an IPv6 packet decode and IPv6 traffic statistics per protocol and address. Figure 10-8 NAM Traffic Analyzer

Fault Management

393

Figure 10-9 NAM Traffic Analyzer per Protocol Statistics Example Output

NOTE

Although a NAM can receive and decode NetFlow v9 records pertaining to IPv6 flows, it cannot, as of this writing, create IPv6 flows itself.

Topology Management Topology management is the network-management component that keeps track of network topology. The information acquired and maintained by topology management is important to other processes such as fault management. In simple cases, topology management might simply keep track of system status (active/ standby). In large networks with a large number of devices, it can include automatic discovery modules and a graphical representation 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 inventory and to gain information on network topology. Autodiscovery is one of the interesting challenges standing in the path of deploying IPv6-only networks, and as such, is reviewed thoroughly in the next section.

394

Chapter 10: Managing IPv6 Networks

As long as managed devices and routers are dual stack, the network discovery is likely to keep using existing IPv4-based mechanisms. However, IPv6-only devices are already being deployed, and they create new challenges for network discovery. To measure the difficulties of discovering automatically an IPv6-only network, 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, and ELMI. This is generally referred to as CDP discovery. The following steps are applied: — 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, and ELMI being enabled in customer networks. This is generally referred as non-CDP discovery, IP-based discovery, 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 the neighboring 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, no change is required in the CDP MIB, but the cdpCacheAddressType object must report a new value (IPv6) for the 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 from MIB-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 sure the seed router’s ARP cache has entries of all the hosts in the subnet, ICMP echo request messages are sent to all 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 directly connected hosts, layer 2 devices, and other routers. The same technique is then iteratively applied to each discovered router.

Fault Management

395

With IPv6, the neighbor cache can be accessed as InetNetToMediaTable, which is part of the updated RFC 2011 MIB. However, the IPv6 addresses obtained from the Neighbor Discovery (ND) cache are likely to be link-locals, if the router uses them to communicate with its peers. Such addresses are useless to the remote NMS because they are significant only on a link. The NMS requires a device-global IPv6 address for its SNMP queries. On the other hand, unlike with IPv4, the NMS cannot remotely force an ND cache to populate entries to all nodes’ neighbors. With IPv6, scanning all hosts on a subnet is out of question, given the number of possibilities (remember this was presented as security strength in preventing address scanning!); IPv6 broadcast 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 the link-local address and global address based on the relationship between the interface ID used for both addresses (see Chapter 2). Example 10-11 shows an interface where EUI-64 is used to generate the interface ID. Example 10-11 Using the Automatically Formatted EUI-64 Interface ID to Tie Link-Local and Global Addresses Router#show running interface Ethernet3/0 no ip address ipv6 address 2001:100::/64 eui-64 no cdp enable end Router#show ipv6 interface brief Ethernet3/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 the router sending the advertisement message is serving as a home agent. When this flag is set, the router (if it supports that functionality) returns its global address rather than prefixes. The seed router still has to store this information in a MIB that the NMS can query.

396

Chapter 10: Managing IPv6 Networks

Of course, you still have the possibility (recommended by many NMSs) to provide up front the list of addresses 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 network topology. They can autodiscover the topology, currently using IPv4 mechanisms or based on a predefined list of 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 dualstack network. InterMapper is a network- and server-monitoring and alerting tool. It provides a real-time graphical view of traffic flows through networks, routers, and links. It can autodiscover the topology of the network if SNMP-speaking routers are present. However, the autodiscovery is entirely based on IPv4 mechanisms (SNMP, address scanning, and so on) and manually configured entries of devices to discover. InterMapper is available at http://www.intermapper.com/.

Routing Management Routing can get tricky in large multidomain, multiprotocol networks. Routing management tools provide visibility 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, which analyzes the BGP routing tables. Other tools can analyze OSPF and other routing protocol tables. Most of them 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 routing table on IPv6 routers. Originally designed to be used by an IPv6 site involved in the experimentation of the BGP protocol inside the 6Bone network, it now supports a set of features useful within any production IPv6 network 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 IPv6connected domains. In addition, it provides pages for the detection of anomalous route entries announced through BGP (invalid prefixes and unaggregated prefixes), anomalous autonomous system numbers (for instance, reserved or private) in use, and a set of summary information, including the following:

• •

The number of route entries (valid/total/suppressed/damped/history)

•

The number of active autonomous system paths

The number of autonomous systems in the table (total, originating only, originating/ transit, transit only, private, and reserved)

Fault Management

• • •

397

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

ASpath-tree was developed inside the TILAB’s IPv6 laboratory and is available at http://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 the ASpath-tree scripts. The administrator of the Cisco router must add the following configuration: ip rcmd remote-host eric valbonne-router root ip rcmd rsh-enable

Polyphemus is a tool for exploring and visualizing the network. It can look inside an autonomous system and explore a network at the level of routers and their physical links. It can also provide inter-autonomous system topologies. Areas are explored by directly accessing the MIB of the routers with SNMP. The user can visualize routers, LANs, areas,

398

Chapter 10: Managing IPv6 Networks

and inter-area relationships. For each item on the map, a full set of information can be displayed. Although it cannot support IPv6 as of this writing, plans exist to extend it to support OSPFv3, SNMP over IPv6 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 tools presented in this section are more specialized. They analyze in detail the packets exchanged between devices to help pinpoint specific anomalies. The NAM traffic analyzer reviewed in the section “Cisco Network Analysis Module” is an example of such a tool. Two more tools have become quite popular among network engineers: 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 can capture (and display) packets on both the local machines and remote probes. Analyzer can monitor the reachability (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, and detect address spoofing (for instance, when the same IPv4/IPv6 address appears to bind more than one MAC addresses). Analyzer can monitor the presence of TCP/UDP/ICMP “sessions” over the network, saving a database record for each session detected within a timeframe. A summary of the session is then saved into a database for later processing. 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 drill down 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 running over 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

399

Figure 10-11 Ethereal Output Screen

Performance Management When deploying new applications over an existing networking infrastructure, the impact on network performance is often a major concern. With IPv6, application deployment should fall into two categories. The first category is IPv4 applications migrating to IPv6. In this case, traffic patterns generated by these applications are expected to be quite similar to what they are with IPv4, hence predictable based on previous experience. The second category is brand new classes of applications, enabled by the larger address space, or the new capabilities of the IPv6 protocol. Peer-topeer applications and Mobile IPv6 (MIPv6) belong to this category. These applications’ traffic patterns are expected to be less predictable. In that context, the availability of management tools for a complete 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 IP version, so they can be used for IPv6 seamlessly; others are IPv4 tools that have been enhanced to support IPv6. Two distinct and complementary approaches are available for managing network performance.

400

Chapter 10: Managing IPv6 Networks

At the device level, some tools can retrieve data from each router (using SNMP, NetFlow, or locally available commands on the devices) and analyze it to determine links, devices, and network utilization. This is the case of 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 network and 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. Although NetFlow Collectors (Cisco NFC, IPFlow,) also belong in the category of traffic-monitoring tools, they are covered separately in the “Flow Analysis Using NetFlow” section. Finally, some network performance-monitoring capabilities are also integrated in network-management platforms such as HP OpenView 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 network performance between a Cisco router and a remote device (which can be another Cisco router). Various performance 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 receive notifications and to perform troubleshooting and problem analysis based on the statistics collected by the IP SLAs. In the absence of native IPv6 support for SAA, you can still use the tool in an IPv6-only environment. The principle of the IP SLAs usage for IPv6 is based on shadow routers that have an IPv4 connection over an IPv6 tunnel. 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 SLA Sender: Router-Send IPv4

SLA Responder Router-Resp

IPv6 Network

2001:798:100::10

IPv4 2001:798:100::2

IPv6 Tunnel

Performance Management

401

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 100 interface 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 ipv6 end

On the sender: Example 10-13 IPv4 over IPv6 Tunnel Configuration at the SLA Sender Router-send#show running interface tunnel 100 interface 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 ipv6 end

With IPv4 connectivity established through the IPv6 tunnel, a router can be configured to become an SLA responder or an SLA sender. To configure the SLA responder, the configuration shown in Example 10-14 must be set up on the router Router-resp. Example 10-14 SLA Responder Configuration Router-resp#show running rtr responder

For the SLA sender, the tester must be configured to execute certain kinds of tests such as jitter, echo, and so on. Example 10-15 demonstrates an echo reply test. Example 10-15 SLA Sender Configuration Router-send#show running ip sla monitor responder ip sla monitor type echo protocol ipIcmpEcho 10.10.10.10 source-ipaddr 10.10.10.2 tos 20 frequency 120 ip 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.

402

Chapter 10: Managing IPv6 Networks

Other IPv6-Enabled Tools for Performance Analysis Network monitoring and performance analysis is one of the richest areas for networkmanagement tools. This section reviews some of these tools, the ones that are IPv6 capable and that have been deployed in production or experimental networks. Argus is a system- and network-monitoring application that includes IPv6 support since version 3.2. It can monitor TCP and UDP applications, IP connectivity, SNMP object identifiers, and so on. It comes with a web interface. Argus contains built-in alert notifications via e-mail and pager, and can be extended to use any other program such as winpopup. Figure 10-13 shows an Argus IPv6 screen. Figure 10-13 Argus Output 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 were recently ported to support IPv6 and to operate over a native Ipv6 network. Figure 10-14 shows an IPv6 Nagios screen. Nagios was initially created by Ethan Galstad under the Netsaint name and then later renamed. It is available at http://www.nagios.org.

Performance Management

403

Figure 10-14 Nagios Output Screen

Ntop is an open-source web-based network-usage monitor that enables users to track relevant network activities, including network utilization, established connections network protocol usage, and traffic classification. It supports various management activities, including network optimization and planning, and detection of network security violations. In the context of the 6NET project, it was ported to IPv6. Ntop was initially developed by Luca Deri and is available at http://www.ntop.org. Ntop can be useful in the context of troubleshooting. MRTG is a tool to monitor the traffic load on network links. MRTG includes a Perl script, which gets traffic counters from the router using SNMP, and an application that logs traffic data, creates graphs, and presents them over a web interface. The Computer Networks research group at Roma Tre University added IPv6 support to MRTG in version 2.10.0. MRTGv6 can now run SNMP queries over IPv6. MRTG is already widely used to monitor the traffic on network links, CPU usage on routers, and other network and host parameters. 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 the network. The required data is acquired from graphs created by the MRTG package and are displayed as two-way colored arrows on a map representing the logical topology of the network. The resulting image is presented in a web page. Figure 10-15 shows a Weathermap screen on the 6NET network.

404

Chapter 10: Managing IPv6 Networks

Figure 10-15 Weathermap Output Screen

Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and UDP characteristics. 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 endto-end path through the 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 UDP packets 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 was written 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 they use. The result is a set of network communications listed by host and port, including bytes out, bandwidth consumption. Jnettop has been extended to support IPv6. Figure 10-16 shows a Jnettop screen monitoring IPv6 traffic. Jnettop is available at http://jnettop.kubs.info

Configuration and Provisioning Management

405

Figure 10-16 Jnettop Output Screen

Configuration and Provisioning Management Configuration and provisioning management are key network-management functions to control network operation. Configuration management handles hardware and software changes, provides inventory of equipment and programs, and manages configuration deltas. Besides integrated platforms (CiscoWorks, for instance, includes Resource Manager Essentials with a set of applications to perform function such as inventory, configuration management, 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 Cisco routers 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 the router (using Telnet, SSH, or rlogin) and recording the configuration. Any differences are flagged using diff and emailed to the operator and saved in Concurrent Versions System (CVS). Cisco Resource Manager Essentials (RME) is part of CiscoWorks, reviewed in the section “Management Platforms.” It provides a GUI for managing the configuration and inventory. It includes a configuration viewer with IPv6 support (both IPv6 addresses and commands), facility to compare archive versions of the configuration (with IPv6 address and commands), and facility to set up configuration templates (which accept IPv6 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 enable them 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 can be used to allocate IPv6 addresses to nodes, and stateful DHCP is one that provides centralized address provisioning. Cisco

406

Chapter 10: Managing IPv6 Networks

Network Registrar (CNR) is a DNS and DHCP server product that supports IPv6 addressing 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 instead provides 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 management tools in one framework. The most popular (HP OpenView, Tivoli NetView) manage far more than the network, integrating application, processes, and so on. However, integrated platforms must rely on fully accepted standards to manage a wide range of heterogeneous devices. For the network, it is essentially SNMP and MIBs. As discussed in the “SNMP and MIBs” section, not all IPv6 MIBs are a published standard. The IPv6-only MIBs are published RFCs, and the plan is to deprecate them as soon as the corresponding generic MIBs (v4 and v6) are published. In that context, integrated management platforms have been slow IPv6 adopters. Some of the major vendors have not yet announced their IPv6 plans. Some, however, such as Cisco and HP, are now proposing some IPv6 support in their respective management suites.

CiscoWorks CiscoWorks is a family of products based on Internet standards for managing Cisco networks and devices. The CiscoWorks product line offers a set of solutions designed to manage the enterprise network. These solutions focus on key areas in the network such as optimization of the WAN, administering switch-based LANs, securing remote and local virtual private networks, and measuring SLAs within all types of networks. The CiscoWorks product line includes a set of management components, bundled in solution offerings such as Small Network Management Solution (SNMS), LAN Management Solution (LMS), Network Analysis Module (NAM) for Cisco Catalyst 6500 and 6000 series, and so on. The list of major components is as follows:

• •

CiscoWorks Server and CiscoWorks Common Services Access Control List Manager (ACL)

Management Platforms

• • • • • • • • •

407

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 made IPv6 capable. Table 10-5 lists all CiscoWorks components and solutions and gives a status on IPv6. Table 10-5

IPv6 Readiness of CiscoWorks Tools Application

Description

IPv6 Status

CiscoWorks Common Services

CiscoWorks Common Services is an add-on to the CiscoWorks2000 Server.

CS3.0

ACL Manager

Access control list management on Cisco routers and Catalyst switches as an add-on to RME.

Not yet

Campus Manager

Web-based network-management tools that provide graphical views of network topology and end-user information.

4.0

CiscoView

CiscoView is a graphical SNMP-based devicemanagement tool that provides real-time views of networked Cisco Systems devices.

6.1

Device Fault Manager

Data fault analysis for Cisco devices.

Not yet

Internetwork Performance Monitor

Network response time and availability troubleshooting application.

Not yet

NetScout nGenius Real-Time Monitor

Allows understanding current network and plan for future need. Help to troubleshoot problems areas in the network. Include Server (data collection/presentation), Traffic Monitor, Packet Analyzer and VoIP monitor.

Not yet

Resource Manager Essentials

Device tracking with network monitoring and fault data, deployment for software images, and configuration displays for Cisco routers and Catalyst switches.

Some IPv6 support in 4.0

continues

408

Chapter 10: Managing IPv6 Networks

Table 10-5

IPv6 Readiness of CiscoWorks Tools (Continued) Application

Description

IPv6 Status

Voice Health Monitor

Manages the voice-specific devices in a network.

Not yet

Service Level Manager

Service-level contract management and implementation of SLAs for SPs.

Not yet

Secure Policy Manager

Policy-based management of Cisco Secure PIX Firewalls and IOS routers running Cisco Secure Integrated Software and Cisco Secure Integrated VPN Software.

Not yet

CiscoWorks added support for IPv6 in the following areas:

• • •

CiscoView Resource Manager Essentials Campus Manager

CiscoView is a web-based management tool that provides dynamic status, statistics, and comprehensive configuration information for Cisco internetworking products (switches, routers, hubs, concentrators, and access servers). When the IPv6 device package is installed, CiscoView manages IPv6 functionality using Telnet/SNMP over IPv4 transport using dual stacks. IPv6 management features are launched from the device’s context menu. CiscoView can provide the following IPv6 information:

•

Configuration—IPv6 address configuration (unicast and multicast), ND, RA, multicast listener discovery

•

Interface information—IPv6 neighbors (ND and RA), CDP information, statistics (IPv6 versus IPv4 traffic)

•

BGP IPv6 peer management

Figure 10-17 illustrates IPv6 CiscoView interface management. 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 manage IPv6-enabled devices, the current RME version requires them to be dual stack, so that it can use the IPv4 addresses 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 IPv6 configuration, 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.

Management Platforms

Figure 10-17 CiscoView Interface Management

Figure 10-18 CiscoWorks RME (Config-viewer)

409

410

Chapter 10: Managing IPv6 Networks

NatKit (Network Analysis Toolkit) within RME is a suite of web-based troubleshooting tools integrated into a network desktop. NATkit collects network data through SNMP requests, Telnet commands, and syslog event messages to produce consolidated reports accessible through a web browser. Although no IPv6 NatKit support is 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 is leveraged in user tracking and path analysis.

•

User tracking—IPv6 support in user tracking is available on both Solaris and Windows servers. In user tracking, hosts configured with an IPv6 address are discovered and shown in the main table. IPv6 name lookup (reverse name lookup only) is done if IPv4 name lookup fails. All global unicast addresses are fetched and used for user-tracking computation, but link-local addresses are dropped. Usertracking end-host reports have an IPv6 format.

•

Ping sweep applicability to IPv6 subnets—Ping sweep functionality is currently available for Class C or smaller 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 on any of the IPv6 Subnets.

•

Path analysis—Path analysis has been modified to support only the IPv6 source to IPv6 destination through IPv6 network scenario.

Figure 10-19 illustrates IPv6 support in Campus Manager for user tracking.

Other Management Platforms Several other network-management platforms are leaders in the IPv4 network-management arena, and their IPv6 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 large variety of networking devices. OpenView Network Node Manager (NNM) handles the networking portion of OpenView. It is based on SNMP and provides a wide range of network-management features, such as device and topology discovery, device monitoring, and so on.

Management Platforms

411

Figure 10-19 CiscoWorks Campus Manager (User Tracking)

Within OpenView NNM, Extended Topology discovers the existence of networking devices and creates maps. Starting with NMN 7.0, Extended Topology can also discover IPv6 devices and create maps showing layer 3 IPv6 nodes. It can then monitor the status of each of the discovered IPv6 devices. To discover the IPv6 devices, the most efficient way (sometimes the only way; see the section “Autodiscovery”) is to configure the list of addresses to be discovered. To discover and monitor the IPv6 devices, Extended Topology relies on IPv6 MIBs and on IPv6 ping. Currently, the only IPv6 MIBs supported by HP OV are published RFCs (RFC 2465, RFC 2452, RFC 2554, RFC 2465, RFC 2566). Unified TCP and UDP MIBs have been published recently as RFC 4022 and RFC 4113, respectively, and other basic unified MIBs are about to become standard. 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 SNMP traps, monitors network health, and gathers performance data. At the time of this writing, Tivoli NetView does not support IPv6.

InfoVista InfoVista software collects data from the IT infrastructure and generates reports on the performance and service achievements across all system elements (networks, systems, and

412

Chapter 10: Managing IPv6 Networks

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 Services and Tools at a Glance Table 10-6 summarizes IPv6-enabled management tools, per management service area. Table 10-6

IPv6 Network-Management Readiness Management Service

Interface

Tools

NMS

Network traffic monitoring

Ping, traceroute, SNMP, NetFlow

Cisco NFC

CiscoWorks

Cisco NAM

HP OverView

IPFlow Ntop/Nprobe Argus Nagios MRTG Jnettop Weathermap InterMappper Topology monitoring

SNMP, Ping, Telnet, RSH

Polyphemus InterMappper Nagios

Routing management

SNMP, RSH

ASpath-tree

Network performance management

Ping, other traffic (UDP, TCP, and so on)

Cisco IP SLAs Iperf Pchar

Configuration management

Telnet, TFTP, RSH

RANCID

Address provisioning

DHCP

CNR

Service management

Telnet, SSH, RSH, and so on

Looking Glass

Equipment management

Ping, traceroute, SNMP, Telnet, RSH

Looking Glass

Accounting management

NetFlow

NetFlow

Ntop

IPv6 Network Management Services and Tools at a Glance

413

In practice, managing an IPv6 network will vary significantly depending on the segment of the network being considered (site, access, core), on the tools strategy chosen (integrated NMS, standalone tools, home-made tools, 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 rely mostly on MIBs, which are not all ready for IPv6 deployment. In addition, many tools used in the IPv4 environments have not yet been migrated to IPv6. Managing dual-stack networks using a mixture of IPv4 tools (for instance, for topology discovery) and tools providing some IPv6 support sounds like a viable deployment approach today. So far in this book, the recommendation has been to avoid differentiating IPv4 and IPv6 as much as possible when operated in a dual-stack network. Network management does not deviate from this rule. Most events generating alerts and triggering network-management actions should remain applicable when IPv6 is deployed: host down, link down, traffic threshold, service anomalies, performance anomalies, and so on. For IPv6-specific alerts and corresponding 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 validating the IPv6 network design and the impact of deploying IPv6 in an existing IPv4 network. These tools offer either 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 devices appears to be problematic. It may require deploying a combination of specialized tools, home-made tools, and an NMS providing some IPv6 support (HP OverView, CiscoWorks). Even so, lack of full IPv6 MIB support and other issues reviewed in the chapter might lead to management areas poorly covered. Over time, IPv6 MIBs 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-management parity 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 methods and strategies. Easier and more automatic renumbering, for instance, is likely to influence current network-management approaches; it could lead to new tools while obsolescing others.

CHAPTER

11

Network Performance Considerations: Coexistence of IPv4 and IPv6 Years of innovation and work to continuously improve various transport technologies and network elements led operators to have high expectations of their networks. Although richness of supported features can differentiate networking equipment, high performance is expected by default. Nothing short of line-rate forwarding 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 with and evaluate. Its implementation in software enabled router vendors to stay on the fast track of integrating the recommendations churned out by the standardization bodies. The IPv6 early adopters, universities and developers were offered the tools to play and experiment with the protocol. Cisco engaged on this path with a phased program that led to Cisco IOS software officially supporting IPv6 features as early as 2001 in release 12.2(2)T. After the protocol consolidated and matured, the focus moved toward deployment considerations, and that naturally implied focus on IPv6 performance. Fast adoption of features remains important in the case of a still-evolving protocol. However, performance requirements force vendors to look at the entire architecture of their products and work on integrating IPv6 in every aspect of it. To meet competitive performance requirements, depending on router architecture, both software and hardware have to take into account the new protocol. The whole topic of performance has an additional twist in the case of IPv6. Today, there are a few cases where brand new networks are built specifically for IPv6-based services. For all the other networks, which include the vast majority, the operators ask a natural question: “What is the impact on my network of turning on 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 IPv6 coexistence can push the discussion from the network element level to a system level, a higher level of complexity. This chapter discusses the various aspects of router performance and the challenges posed by IPv6. It provides information and guidelines on evaluating a router’s performance so that you can choose the right router for the job.

416

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

Aspects of Router IPv6 Performance It is commonly understood that routers and layer 3 switches are performing functions at different levels of the OSI model. With the increased complexity of supported features, these devices started to operate at levels beyond the original first three. It is therefore expected that routers operate in one form or another on parameters 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 into three categories:

•

Control plane—Handles the router’s interaction with the other network elements, providing the information needed to take decisions and control the overall router operation. This plane runs processes such as routing protocols and network management. These functions are generally complex.

•

Data plane—Handles packet forwarding from one physical or logical interface to another. It involves different switching mechanisms such as process switching and Cisco Express Forwarding (CEF) on Cisco 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 and operation depend on the router architecture. Figure 11-1 Conceptual Representation of a Router: Data and Forwarding Planes ACL QoS etc.

Enhanced Services

View of Network Topology

Routing Table Neighbor Info

Network Mgmt

Packet

Forwarding Mechanisms (Cisco Express Forwarding)

Data Plane

Decision

Control Plane

Packet

Aspects of Router IPv6 Performance

417

Each of these router functions has its own performance characteristics. It is therefore important to qualify a router’s performance in the context of its control-plane, data-plane, or enhanced-services operation. IPv6 presents 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. Protocol characteristics shape the performance of these processes and the amount of resources necessary to operate them:

•

Size of IPv6 addresses—Address size impacts the information-processing functions of a router. Systems using a 64-bit CPU, bus, or memory structure can pass both the IPv4 source and destination address in a single processing cycle. For IPv6, the source and destination addresses require two cycles each, or a total 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 as link-local and global unicast with different interface ID values. The increased number of addresses used impacts the memory consumption of the Neighbor Discovery cache.

•

IPv6 routing protocols—The IPv6 routing protocols are similar to their IPv4 counterparts. However, an IPv6 prefix is four times larger than an IPv4 one, which means that routing updates have to carry more information in the case of IPv6. This remains true despite various optimizations made to address this difference.

Size is one of the natural concerns about the IPv6 networks and the IPv6 Internet. Larger networks are expected with the larger IPv6 address space. In principle, this implies larger routing tables and higher memory requirements to support them. At first, as deployments are incipient, this is not an issue. As the number and size of IPv6 networks increases, aggregation and strict prefix allocation through the provider-enforced hierarchy 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 production aggregation

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

418

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

in the IPv6 Internet table. To monitor the growth and prefix distribution of the IPv6 Internet, several websites provide tools and statistics on IPv6 routing tables: http://www.sixxs.net/tools/grh/dfp/ http://www.switch.ch/network/ipv6/bgp/ http://net-stats.ipv6.tilab.com/bgp/index.html For a historical perspective, Figure 11-2 shows the prefix-allocation growth seen in the BGP routing tables since 1998 (source TILAB). Figure 11-2 Growth of IPv6 Internet Tracked by the Size of the BGP Routing Table

IPv6 Prefixes Advertised Within the BGP Cloud 900 800

Number of Prefixes

700 600 500 400 300 200 100 0 1 Oct 1998

1 Oct 1999

1 Oct 2000

1 Oct 2001 Time

1 Oct 2002

1 Oct 2003

At the time of this writing, the number of IPv6 prefixes in the BGP routing tables is 2573. According to the TILAB statistics, the main contributions to the total number of prefixes present in the routing tables were, at the date of the snapshot (January 2005), in this order: 1 IANA assigned prefixes. These are the IPv6 prefixes officially assigned by IANA and

the Internet registries to the requesting organizations for production use of IPv6, the sTLA prefixes. 2 Unaggregated prefixes. These are the IPv6 prefixes belonging to the 6Bone

addressing space that are longer than the correspondent pTLA delegation. 3 6Bone pTLA prefixes assigned to the backbone sites. 4 Invalid prefixes. These are IPv6 prefixes that do not belong to the address space

assigned by IANA. 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

Aspects of Router IPv6 Performance

419

important for service providers (SPs) to better plan network resources such as router memory. Independent of the routing table size, users want to know whether IPv6 routing protocols perform well in terms of convergence. Because of their similarity to the IPv4 counterparts, the convergence performance of the 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 this reason, bringing IPv6 into an operational network has to be done in a controlled way and with full information about its potential impact. If justified by the available router resources or the network conditions, limitations can be placed on IPv6 processes or the router’s interaction with other network elements. The intent is to protect 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 the parsed 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 IPv6 address information in the extension headers, which significantly increases their size. These additional fields 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 access control lists (ACLs) that filter on layer 4 information. The router has to be able to apply them to packets with extension headers, too. If the length of the extension headers exceeds the fixed length of the hardware registers, hardware switching does not occur. In this case, the packet is punted to software 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 handle in 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 find an output interface. When the forwarding decision is made based on the destination address, this process entails parsing a maximum of 128 bits rather than 32 bits for IPv4. To improve the lookup performance, the lookup algorithm has been

420

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

modified. A 128-bit lookup is rare because it applies only to host routes, including anycast addresses, which should have a limited presence. An anarchic allocation of anycast addresses can be problematic because a lot of host routes would be injected in the IPv6 routing table. In a typical autonomous system, however, following the address allocation recommendations documented in RFC 3177, it is expected that for a service provider, the majority of lookups are centered on a few fixed values: /32 in the core of the network, /48 in the distribution layer, and /64 at the edge. Depending on the router type, lookups are performed by a multipurpose CPU or by an application-specific integrated circuit (ASIC) with a fixed configuration or with a microcode. This impacts the performance and the versatility of the router functions. Software processing of the IPv6 lookup takes more time than for IPv4 because more bits must be processed. The multipurpose CPU is slower but can perform functions based on a limitless program. The ASIC with microcode allows for a certain degree of flexibility in the performed features, although the fixed ASIC performs only the functions for which it was initially designed. Because the IPv6 lookup is more demanding (theoretically four times more demanding), there is a natural tendency to leverage hardware-based lookup engines as much as possible. Hardware-based lookup designs generally lead to 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 therefore important 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 be added, the ASICs need to be redesigned, which is a much longer and more costly process than that of implementing it in software.

The performance of the various processes and functions discussed in this section depends on the architecture of each router. An overview of these architectures is presented later in this chapter along with performance-data examples.

Measuring Forwarding Performance Following the discussion about the various aspects of router performance, it is important to understand how to measure and test it. This is a significant part of evaluating a platform for a particular role within a deployed network. Consistent and universally accepted test methodologies should be observed for objective evaluations. Most often, router performance is associated with its forwarding capabilities. Resource requirements can typically be addressed by increasing the router memory or selecting more powerful processors; however, the forwarding performance is generally limited by the platform design. For this reason, the focus of this section is on the best practices for measuring the IPv6 throughput of a router.

Measuring Forwarding Performance

421

Regardless of the IP protocol type, forwarding performance testing is best performed in a black-box environment. 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 rate with no packet drop.

•

The NDR should be determined in steps of 60 or fewer seconds and then verified by forwarding traffic 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 of Ethernet, 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 is also important to evaluate the forwarding performance of multicast traffic, too. This type of traffic will most likely be present in the IPv6 deployments. With multicast, the test options are multiple because there are various ways in which the router can replicate traffic. For this reason, it is best for the evaluation to be performed based on traffic patterns and requirements specific to the network role for which the router is evaluated.

NOTE

The larger IPv6 addresses require more intense lookups, and that can impact the router performance, as mentioned in the previous section. For this reason, it is more important to evaluate a router’s forwarding performance for prefixes of various lengths in the /16 and / 64 range in IPv6 than in IPv4. All major test tool vendors provide RFC 2544–based test suites that can be used to measure the NDR of devices under test (DUT). These suites can be executed with both IPv4 and IPv6 traffic. They are well suited to 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 ensure they 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 data from the DUT itself. Relevant data that should be collected during test includes memory utilization and integrity, CPU values at box or linecard level, and general system messages. Although throughput data in itself is important as far as a standalone router is concerned, sometimes NDR is obtained at 100 percent use of the CPU. From a network operation perspective, this is unacceptable because the router might have to totally neglect its control-plane to meet the measured NDR.

422

NOTE

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

Considering all the parameters that are being measured during the evaluation, it is always a good practice to define 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 forwarding performance of raw traffic as well as complex traffic that includes higherlayer content or extension headers. It also provides a good way to evaluate the impact on performance of advanced features (access lists, for example) enabled on the DUT. A blackbox approach to testing allows for a clear one-to-one comparison of the results obtained in each of these cases. It also allows for meaningful comparisons between IPv4 and IPv6 throughput 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 a router:

•

Interface-to-interface throughput refers to measuring the NDR by sending bidirectional traffic through two same-type interfaces of the DUT.

•

System throughput refers to measuring the NDR by sending bidirectional traffic through all interfaces of 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 forwarding performance 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 only factor 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 sections highlighted some of the IPv6-specific challenges faced by a router’s control and forwarding planes. Ultimately,

The Right Router for the Job

423

a router’s performance is determined by its implementation of the control and forwarding functions as well as its integration of the IPv6 protocol. For this reason, it is important to have an idea of the overall design of the evaluated router when analyzing its performance data.

Router Architecture Overview Routers evolved from mere specialized computers where all processing is software based to sophisticated devices where functionality is shared between software running on powerful CPUs and highly specialized hardware. Routers are becoming more powerful, more reliable, and more scalable; but all this comes at a cost. 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 the other hand, packet forwarding along with some advanced features can be performed by dedicated hardware resources. Based on the implementation of the forwarding plane, routers can be classified as follows:

NOTE

•

Software forwarding router—A device using its main CPU for basic and enhanced packet forwarding; no hardware assistance is available.

•

Hardware Forwarding Router—A device that has hardware assistance for basic or enhanced packet forwarding.

A packet that cannot be handled by the hardware is usually punted to software processing 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 is designed to support a certain set of features, so additional features require its redesign. For this reason, hardwareforwarding-based platforms are generally well positioned in or close to the network core and edge. There the interfaces are high speed, and the focus is on forwarding performance rather than feature richness. Software-forwarding-based platforms are more suited in the access layer, where the 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 and the Cisco Carrier Routing System (CRS-1); layer 3 switches: Catalyst 6500, 3560 and 3750 series

424

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

Centralized Versus Distributed Forwarding A router can take all its forwarding decisions in a centralized manner or it can distribute the function among multiple intelligent subsystems. This design choice separates routers in two categories:

NOTE

•

Centralized forwarding router—Every packet-forwarding decision is made by a central forwarding engine.

•

Distributed forwarding router—Forwarding decisions are made on different forwarding engines that can control a linecard, a port, a section of a chassis, and so on.

All forwarding engines involved in the decision-making process have to support IPv6. If they do not, the router defaults to a centralized mode of operation.

The distributed architectures are particularly important for larger, modular routers that have to scale well with additional linecards. When the forwarding decision making is distributed to these intelligent cards, the router performance is not impacted by an increase in the number of interfaces and modules. This type of router is prevalent at the core and the edge of the network. Examples of distributed, IPv6-capable routers from the Cisco family include the following:

• • • • NOTE

Cisco 7500 series router Cisco 7600 series router with distributed CEF 720 linecards Cisco 12000 series Internet router CRS-1 router

A distributed architecture also allows software forwarding platforms to have a performance close to line rate and that scales linearly as cards are added. This is the case of the 7500 Cisco routers.

The concepts presented in this section represent a high-level overview of router architecture. These concepts can help you classify routers and have certain performance expectations from them based on their design. However, today's routers are complex systems, and there is a lot more to a complete and thorough discussion of their architecture than what is covered in this brief discussion. For more detail on this topic, refer to the book Inside Cisco IOS Software Architecture (CCIE Professional Development) by Vijay Bollapragada, et al.

The Right Router for the Job

425

IPv6 Forwarding Performance of Cisco Routers Armed with an understanding of the various router architectures and the methodology to test their performance, it is time to see the differences between their IPv4 and IPv6 performance. This section presents forwarding performance examples for the two protocol types on Cisco routers that target various segments of a network.

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 are software-based routers, they are easily enabled to support IPv6. The Cisco product line from the 830 series to the Cisco 3800 series can be easily enabled for IPv6 when it is upgraded to one of the supported Cisco IOS software release, such as 12.2T, 12.3, 12.4, 12.3T, and 12.4T. Low-end routers have a centralized architecture.

NOTE

CEF is available for IPv6 (Cisco Expressing Forwarding v6 and distributed Cisco Expressing Forwarding v6) starting with Cisco IOS Release 12.2(13)T. Despite being software platforms, many of the low-end routers use powerful CPUs that enable them to achieve line-rate packet forwarding on their interfaces. To provide encryption services, which are particularly CPU intensive, hardware assistance 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 a low-end router from the Cisco 3700 series. The throughput was determined between two Fast Ethernet interfaces, with bidirectional traffic and no advanced features enabled. The theoretical maximum throughput for the interface type analyzed is also listed for reference. Figure 11-3 is a graphical representation of the 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 Packet Size (Ethernet II)

IPv4 (pps*)

IPv6 (pps)

Maximum (pps)

64 bytes

63,918.5

48,064

148,810

128 bytes

63,431

49,867

84,449

256 bytes

45,290

45,290

45,290

512 bytes

23,492

23,492

23,497

1024 bytes

11,973

11,973

11,973

1518 bytes

8127

8127

8128

IMIX

33,515

33,515

33,515

*Packets per second

426

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

NOTE

IMIX is a 7:4:1 distribution of Ethernet-encapsulated packets of sizes 64, 570, and 1518 bytes. This leads to a 353-byte packet-size average.

NOTE

Sometimes the performance numbers are multiplied by a factor of two when bidirectional traffic is used during testing. For this reason, it is important to fully qualify the test methodology used.

Figure 11-3 Example of IPv4 Versus IPv6 Forwarding Performance of a Low-End Router (Cisco 3725 - FastE)

Throughput (% of Line Rate)

100

80

60

40

20

0

64

128

256 512 Packet Size (Bytes) IPv4 Throughput

1024

1518

IPv6 Throughput

It is worth noting that line-rate forwarding is obtained before the IMIX packet size, which represents a likely packet-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 even more important. Routers in this market segment can be positioned in different roles and have to perform multiple functions from access to distribution/ aggregation and even core at times. The versatility required of the mid-range platforms is reflected in the multitude of router architectures applied to them. Software and hardware forwarding, as well as centralized and distributed architectures, are all present. Leveraging powerful CPUs allows routers with low density of ports to deliver competitive forwarding performance while maintaining the edge in terms of feature richness. Table 11-2 shows the performance data of a Cisco-software-based, centralized forwarding mid-range

The Right Router for the Job

427

platform. The performance is measured with 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 IPv6 throughput 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)

GE–IPv4 (pps)

GE–IPv6 (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

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)

Throughput (% of Line Rate)

100

80

60

40

20

0

64

128

256

512

1024

1518

Packet Size (Bytes) IPv4 Throughput

IPv6 Throughput

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 features enabled such as access control lists (ACLs). This is not always the case with mid-range hardware platforms available on the market. Table 11-3 shows the impact of ACLs on the performance of a Cisco 7200 router with an NPE-G1 processor.

428

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

Unidirectional traffic was used and 100 ACLs were enabled on the ingress interface. The data is graphically represented in Figure 11-5. Table 11-3

Cisco 7200 NPE-G1 Performance Between 2 Gigabit Ethernet Interfaces, Unidirectional, With and Without 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

94,840

94,841

1518 bytes

81,274

81,274

81,274

Figure 11-5 IPv6 Forwarding Performance With and Without ACLs (Cisco 7206)

Throughput (% of Line Rate)

100

80

60

40

20

0

64

256 1024 Packet Size (Bytes) IPv6 Throughput—no ACL

IPv6 Throughput—100 ACLs

1518

The Right Router for the Job

429

NOTE

If a router is evaluated in a role that involves the extensive use of advanced features such as ACLs, it is important 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 to evaluate a router’s performance in this context. Software platforms are well positioned in this case because packet switching is done in software for both native and tunneled IPv6 traffic. Hardware assist for IPv6 over IPv4 tunneling is not generally available. When a mid-range platform is targeted for an aggregation role, a centralized, software forwarding design might be challenged by the high number of interfaces involved. In a distributed architecture, however, the forwarding performance is scaling linearly when interfaces are added to the system. An example of such a platform is the Cisco 7500 that leverages the distributed Cisco Express Forwarding (dCEF) feature. An example of forwarding performance numbers measured for the OC-3 interface of this router is shown in Table 11-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

1024 bytes

18,480

18,480

18,480

1518 bytes

12,422

12,422

12,422

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 as Gigabit 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 on high-end routers, Table 11-5 depicts the differences in performance on a Cisco Catalyst 6500 series switch and Cisco 7600 Series Router for various switching paths.

430

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

Figure 11-6 Example of IPv4 Versus IPv6 Forwarding Performance of a Mid-Range Router (Cisco 7500 – OC3).

Throughput (% of Line Rate)

100

80

60

40

20

0

64

128

256 512 Packet Size (Bytes) IPv4 Throughput

Table 11-5

1024

1518

IPv6 Throughput

Performance of Various Switching Paths on Catalyst 6500 / Cisco 7600 Switching Path

Performance

Process switched mode

10–30 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. Actual performance numbers for another high-end Cisco router that performs IPv6 forwarding in hardware are shown in Table 11-6. Table 11-6

Cisco 12000 Engine 3 POSIP OC-48 HDLC Encapsulation CRC32, Bidirectional, No ACL Packet Size (Layer 2)

OC-48 – IPv4 (Mpps)

OC-48 – IPv6 (Mpps)

Maximum (Mpps)

64 bytes

3.846

3.846

4.103

128 bytes

2.321

2.321

2.321

256 bytes

1.156

1.156

1.156

The Right Router for the Job

Table 11-6

NOTE

431

Cisco 12000 Engine 3 POSIP OC-48 HDLC Encapsulation CRC32, Bidirectional, No ACL (Continued) Packet Size (Layer 2)

OC-48 – IPv4 (Mpps)

OC-48 – IPv6 (Mpps)

Maximum (Mpps)

512 bytes

0.579

0.579

0.579

1024 bytes

0.289

0.289

0.289

1500 bytes

0.198

0.198

0.198

Consult Cisco documentation to identify the routers and router linecards that support hardware forwarding of IPv6.

Figure 11-7 shows the forwarding performance improvement at low packet sizes because of its implementation in hardware. The other advantage of hardware forwarding is that IPv4 and IPv6 traffic will not compete for processor resources. Turning IPv6 on is not going to impact the forwarding of existent IPv4 traffic. Figure 11-7 Example of IPv4 Versus IPv6 Forwarding Performance of a High-End Router (Cisco 12000 – OC48)

Throughput (% of Line Rate)

100

80

60

40

20

0

64

128

256 512 Packet Size (Bytes) IPv4 Throughput

1024

IPv6 Throughput

1500

432

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

Cisco CRS-1 is its flagship of core routers, and it represents the most compelling example of high performance achieved through advanced hardware forwarding design. Independent studies by the European Advanced 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 single chassis configuration is 640 Gbps, although the multichassis configuration is 1.28 terabits per second. It also achieves line rate at these speeds for traffic mixes (85 percent IPv4, and 15 percent IPv6).

6PE Forwarding Performance 6PE and 6VPE are key migration options in the deployment of IPv6. See the section “IPv6 over 6PE” in Chapter 3, “Delivering IPv6 Unicast Services,” and Chapter 7, “VPN IPv6 Architecture and Services,” for details about these technologies. IPv6 forwarding performance through a 6PE environment is an important factor when weighing a certain deployment strategy. A Multiprotocol Label Switching (MPLS)-enabled core has high forwarding performance, close to line rate, of labeled traffic irrespective of the IP version of the packets. It is thus up to the PE routers to avoid reducing the end-to-end forwarding performance of IPv6 in a 6PE deployment. In the case of 6PE and 6VPE, there is a level of asymmetry in terms of forwarding performance. Routers will exhibit a certain performance when traffic flows from the IPv6 side toward the MPLS core (router performs label imposition) and when it flows in the opposite direction (router performs label disposition). For this reason, a simple bidirectional traffic test is not fully revealing because the forwarding performance result is shaped by the lowest of the performances in each individual direction. In this case, the right testing approach is to use unidirectional streams and analyze each direction separately.

NOTE

The same approach should be applied when evaluating the forwarding performance over IPv6 tunnels.

Table 11-7 lists the 6PE forwarding performance data for the OC-48 ISE card of the Cisco 12000. Forwarding is hardware assisted for this platform. The performance in the “label imposition” direction shapes the overall performance on the path. In the Cisco implementation of 6PE, a different label is usually associated with each prefix, 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 is represented graphically in Figure 11-8.

IPv6 Router Performance Evaluation Checklist

Table 11-7

433

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

Figure 11-8 6PE Forwarding Performance in the Label Imposition and Label Disposition Directions (Cisco 12000 – OC48)

Throughput (% of Line Rate)

100

80

60

40

20

0

64

128

256 512 Packet Size (Bytes)

6PE Imposition Throughput

1024

1500

6PE Disposition Throughput

The forwarding performance for 6PE is close to line rate for most (and the relevant) packet sizes. Similar high performance is also available with software-switched platforms, and that certainly qualifies the 6PE solution for large-scale, high-performance deployments.

IPv6 Router Performance Evaluation Checklist For the time being, the IPv6 networks are small compared with IPv4, and the IPv6 traffic most likely represents a fraction of the existent IPv4 traffic. For these reasons, operators would tend to look at IPv6 performance in terms of its impact on the revenue-generating

434

Chapter 11: Network Performance Considerations: Coexistence of IPv4 and IPv6

IPv4 services. As focus moves toward large-scale deployments, router IPv6 performance becomes an important factor in network planning and design. This chapter underlines the relevant aspects of router performance while showing the importance of keeping in balance all the other factors relevant in router selection, such as feature richness and cost. It also discusses the impact of IPv6 protocol specificities on router performance. The chapter provides guidelines on practical and objective evaluation methodologies of router IPv6 performance. From a practical perspective, this information can be summarized in a checklist of major items to be verified when evaluating a router’s IPv6 performance. Table 11-8 shows this list. Table 11-8

IPv6 Router Performance Evaluation Checklist Test Scope

Test Targets

Control plane

Evaluate the CPU impact of targeted IPv6 features. For routers that will operate in dual-stack mode, add the result to the operational CPU values (generated by IPv4) to see whether it will lead to comfortable overall CPUs (typically below 60 percent under regular traffic loads). Evaluate the memory needs for the IPv6 routing tables. For routers that will operate in dual-stack mode, add to IPv4 memory use to see whether it leads to comfortable overall memory use.

Data plane

Measure unicast interface-to-interface and system-level throughput performance for basic IPv6 traffic and no advanced router features enabled. Pay particular attention to the throughput results above the IMIX average packet sizes. Measure unicast interface-to-interface and system-level throughput performance for IPv6 traffic with various extension headers and no advanced router features enabled. Pay particular attention to the throughput results above the IMIX average packet sizes. Measure unicast interface-to-interface and system-level throughput performance for basic IPv6 traffic with advanced router features (the features targeted for the deployment such as ACLs, QoS, and so on) enabled. Pay particular attention to the throughput results above the IMIX average packet sizes. Evaluate the CPU impact of forwarding the expected IPv6 traffic rates. Both central and linecard (where applicable based on the router design) CPU should be measured. Measure IPv6 multicast performance in terms of both forwarding rates and replication.

IPv6 Router Performance Evaluation Checklist

435

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 sizes relevant for most applications. The data presented supports this statement in the case of platforms of various designs that address the entire market spectrum. IPv6 router performance meets the high standards set by IPv4.

PART

II

Deployment Case Studies Chapter 12

Generic Deployment Planning Guidelines

Chapter 13

Deploying IPv6 in an MPLS Service Provider Network

Chapter 14

Deploying IPv6 in an IP Service Provider Network

Chapter 15

Deploying IPv6 in an Enterprise Network

CHAPTER

12

Generic Deployment Planning Guidelines The first part of this book reviews the IPv6 technologies from a deployment and practical perspective. It provides the tools necessary to implement IPv6 in existent or new networks. The second part of the book offers concrete examples on using these tools in different types of environments. These examples go over all the technical details related to designing and deploying scalable and high-performance IPv6-based services. In real 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. This chapter provides planning guidelines and pointers to useful sources of information, and it focuses on the following 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 of the subsequent chapters address business drivers and technical guidelines related to rolling out IPv6 services in different market segments. This chapter deals with more generic challenges that apply to any IPv6 deployment irrespective of context or environment.

Cost Analysis Regardless of network’s age, the full integration of IPv6 services means that an inventory of the existing equipment must be performed to evaluate the cost of the project. This process would help plan the associated budget and project timescale. Although this step is mandatory to budget a deployment, it does not necessary help to evaluate the return on investment (RoI) associated with IPv6. In some cases, a given application or service clearly identifies a need for IPv6 and RoI becomes obvious. This leads to a rather targeted approach. When recognizing that the need for migration is inevitable, another way to integrate this new IP version is just to require products to be IPv6 capable for any new acquisition. In this way, the migration might occur over years as the networking environment gets upgraded to the newest generation of products and applications, but this planned approach will help to control the cost of the integration. The cost analysis includes the upgrade expenses for elements, such as hosts and network devices, but also labor for project planning and execution.

440

Chapter 12: Generic Deployment Planning Guidelines

Host-Related Costs An important requirement for enabling IPv6 on a host is the minimum release of its operating system that supports IPv6. This requirement extends to the capability for any application to run over an IPv6 network layer with full support from a given vendor. For example, Microsoft offered an IPv6 technology preview on Windows 2000, but it did not provide full support. Windows XP Service Pack 1 got a supported IPv6 stack but with a limited subset of supported applications such as Internet Explorer 6.0, Windows Media Player 9.0 and 10.0, and Conference XP 3.2, but no IPv6 support for popular applications such as Exchange, Outlook, or Microsoft Office. It is expected that the next-generation operating system, known as Microsoft Windows Vista, will deliver parity between IPv4 and IPv6 at the application level. Table 12-1 provides an overview of IPv6 stack availability on well-known operating systems at the time of this writing. Table 12-1

IPv6 Support on Various Operating Systems Vendor

Operating System

Reference

Apple

Mac OS X 10.2 and later

http://developer.apple.com/macosx/

BSD

FreeBSD 4.0 and later

http://www.kame.net

OpenBSD 2.7 and later NetBSD 1.5 and later BSD/OS 4.2 and later HP

HP-UX 11i and later Tru64 UNIX V5.1 and later

IBM

http://www.hp.com/products1/unix/operating/ internet/ipv.html

OpenVMS V5.1 and later

http://h18000.www1.hp.com/ipv6/ next_gen.html

AIX 4.3 and later

http://www-306.ibm.com/software/os/zseries/ ipv6/

OS/390 V2R6 eNCS z/OS Rel. 1.4 and later Linux

RH 6.2 and later Mandrake 8.0 and later

http://www.bieringer.de/linux/IPv6/status/ IPv6+Linux-status-distributions.html

SuSE 7.1 and later Debian 2.2 and later Microsoft

Windows XP SP1 and later

http://www.microsoft.com/ipv6

Windows .NET Server 2003 Windows CE .NET (Pocket PC 4.1) and later Novell

NetWare 6.1 and later

SUN

Solaris 8 and later

http://www.sun.com/software/solaris

Symbian

Symbian 7.0 and later

http://www.symbian.com

Cost Analysis

441

After the minimum releases for the targeted operating systems are identified, the cost of deployment will vary with respect to the hardware capability to support the respective software releases. This cost could go from zero in the case of hardware already running the appropriate version to significant amounts if the hardware must be replaced to run the latest operating system version. Table 12-2 provides a summary of the various possible scenarios. Table 12-2

Estimate of Host Upgrade Costs Hardware

Software

Minimal Operation

Cost

Full replacement

Full upgrade

Local intervention

Very high

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 inventory of applications. If the integration of IPv6 per application is considered to quickly take advantage of the protocol, it becomes simpler to classify the applications in categories that indicate the level of priority for a given corporate network (Table 12-3). Table 12-3

Classification of Applications Type of Applications

Priority

Comment

Application must be IPv6 capable

High

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

442

Chapter 12: Generic Deployment Planning Guidelines

Costs associated with applications depend on their licensing scheme and the required upgrades. This can lead to significant costs when thousands of hosts running tens of applications are involved).

Network Elements–Related 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 to specifically list the services mandatory for his network to ensure their IPv6 equivalent is supported. In the case of Cisco IOS release trains, IPv6 features integrated over time are documented in Cisco IOS IPv6 Start Here 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 the deployment guidelines. For this reason, the cost of upgrading nonrouter devices to support IPv6 should be included in the study, too. Providing a generic network equipment industry status on IPv6 support might not be easy. You should instead poll your favorite vendors about the features of interest for your deployment. At the time of this writing, Table 12-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

OK

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.

Cost Analysis

Table 12-4

443

Cisco Equipment IPv6 Support (Continued) Type of Device

Status

Comment

WiFi access point

OK

IPv6 traffic forwarding is generally transparent to WiFi AP.

WiFi access point

Under development

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 amounts depending on the current level of readiness. Table 12-5 summarizes the expected cost of upgrading the network 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

Minimal

Early planning for IPv6 deployment is critical to save some of these costs. Equipmentacquisition policies that mandate IPv6 support or a clear roadmap can lead to improved readiness with every scheduled network upgrade.

Operations-Related Costs The integration of IPv6 in a production network represents a challenge for the operations team in charge of maintaining the integrity of IPv4 services. While working on the new protocol, they need to ensure seamless coexistence and similar service quality to the end users for both protocols. The project of integrating and running 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 and configuration, and day-to-day operation, has to be planned and approved by management before the rollout can begin.

444

Chapter 12: Generic Deployment Planning Guidelines

Configuration of hundreds or thousands of hosts and networking elements (independent of the need for hardware, operating system, or applications upgrade) is time-consuming and has a cost of labor that needs to be budgeted from day one. This must include the tasks associated with the update of the network management system and tasks related to the day-to-day support of the end users, the definition of updated operational processes, and their documentation. Nevertheless, by planning for version-independent IP support through new acquisitions or development of applications, the cost of the upgrade could be integrated in the next rollout of equipment, which decreases the cost 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 leads to certain architecture choices (6PE versus native IPv6), operational cost could remain at its current level.

Address Policies and Registration Process To fully understand the IPv6 addressing model, you must become familiar with the various IETF-related documents as introduced in Chapter 2, “An IPv6 Refresher,” and throughout the first part of this book. The centerpiece is the IPv6 address architecture as defined in RFC 3513. An understanding of the address architecture needs to be complemented by an understanding of the current policies for IPv6 address-space allocation. The IETF defines an IPv6 global unicast address format in RFC 3587. This RFC documents an IPv6 addressing structure that is compliant with the allocation of IPv6 addresses related to policy and to the stewardship of the IP similar to IPv4. The resulting format is an IPv6 global unicast address under the 2000::/3 prefix that is currently being delegated by the Internet Assigned Numbers Authority (IANA). The IPv6 address-management function was formally delegated to IANA in December 1995 as documented in RFC 1881. Table 12-6 presents the IPv6 address-space distribution as documented at http://www.iana.org/assignments/ipv6-address-space. Table 12-6

Cost IPv6 Address-Space Allocation IPv6 Prefix

Allocation

Reference

0000::/8

Reserved by IETF

RFC 3513

0100::/8

Reserved by IETF

RFC 3513

0200::/7

Reserved by IETF

RFC-carpenter-obsolete-1888-01.txt

0400::/6

Reserved by IETF

RFC 3513

0800::/5

Reserved by IETF

RFC 3513

1000::/4

Reserved by IETF

RFC 3513

2000::/3

Global Unicast

RFC 3513

4000::/3

Reserved by IETF

RFC 3513

6000::/3

Reserved by IETF

RFC 3513

Address Policies and Registration Process

Table 12-6

NOTE

445

Cost IPv6 Address-Space Allocation (Continued) IPv6 Prefix

Allocation

Reference

8000::/3

Reserved by IETF

RFC 3513

A000::/3

Reserved by IETF

RFC 3513

C000::/3

Reserved by IETF

RFC 3513

E000::/4

Reserved by IETF

RFC 3513

F000::/5

Reserved by IETF

RFC 3513

F800::/6

Reserved by IETF

RFC 3513

FA00::/7

Reserved by IETF

RFC 3513

FC00::/7

Unique Local Unicast

Draft RFC-ietf-ipv6-unique-local-addr in IETF editor queue

FE00::/9

Reserved by IETF

RFC 3513

FE80::/10

Link-local Unicast

RFC 3513

FEC0::/10

Reserved by IETF

RFC 3879

FF00::/8

Multicast

RFC 3513

The following notes add specific details on addressing architecture: • The “unspecified address,” the “loopback address,” and the IPv6 addresses with embedded IPv4 addresses 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 has been deprecated as of December 2004 by RFC-carpenter-obsolete1888-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 been deprecated as of September 2004 by RFC 3879. • 0000::/96 was previously defined as the “IPv4-compatible IPv6 address” prefix. This

definition has been deprecated by RFC-ietf-ipv6-addr-arch-v4-04.txt. IANA allocates IPv6 prefixes to the five Regional Registries (RIRs) based on their needs:

• • • • •

AFRINIC—http://www.afrinic.net APNIC—http://www.apnic.net ARIN—http://www.arin.net LACNIC—http://www.lacnic.net RIPE—http://www.ripe.net

446

Chapter 12: Generic Deployment Planning Guidelines

The list of IANA prefixes assigned to the RIRs can be found at http://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 be returned to the unassigned address pool when the 6Bone is phased out on June 6, 2006 (see RFC 3701). • 2001:0DB8::/32 has been assigned as a NONROUTABLE range to be used for

documentation purpose 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 respective allocation policies are described at the following websites:

• •

IPv6 anycast address allocation http://www.iana.org/assignments/ipv6-anycast-addresses Global IPv6 multicast address allocation http://www.iana.org/assignments/ ipv6-multicast-addresses

The RIRs allocate, via the Local Internet Registries (LIRs), a ::/32 prefix (formerly ::/35) to Internet service providers (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 prefix from a registry, although there are historical exceptions. This rule, which intended to enforce route aggregation through assignment policies, is a significant departure from the IPv4 address allocation mechanisms. Its impact on network operations has to be clearly understood well before the need for integrating IPv6 becomes imminent. There have been and there continue to be many discussions between experts on the topic of IPv6 address-allocation policies. RFC 3177 documents the current recommendations to the RIRs on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of the following:

•

/48 in the general case, except for large subscribers

Education

• •

447

/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 from these recommendations are possible (discussion about shorter prefix than /48 are still ongoing) because at this level in a network, address assignment depends on the business and design models of each service provider or enterprise. To conclude, there is a need to add to the equipment- and operations-related costs the cost of subscribing an IPv6 prefix. For ISPs, this cost is documented by the RIRs and LIRs. For enterprises and end users, fees associated with IPv6 services from an ISPs can vary from zero dollars (often the case when this is offered as a trial or beta service or the ISP wants to build service references) up to fees similar to IPv4 services. To evaluate the pricing associated with IPv6, contact your local ISP to learn about its capability to deliver the services. (For example, it is also possible to check out the Japanese ISP market from http://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 IPv4 subscription; 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 and associated 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 on IPv6 should leverage the work done within the 6Bone project; however, because technology, policies, and implementations evolved over the nearly 10 years of 6Bone’s existence, it is important to maintain a time perspective when evaluating its deliverables. In the meantime, multiple other projects have been started that have generated a tremendous amount of information about the technology, its deployment, and operation. To help you navigate through this sea of resources, here is a basic and nonexhaustive classification of good material:

•

6Bone(http://www.6bone.net) The 6Bone is an IPv6 test bed and a worldwide informal collaborative project started in the middle of the 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 IPv6 transport. It will be phased-out in June 2006. The initial 6Bone focus was on testing standards and implementations; the current focus is more on testing the transition and operational procedures. The 6Bone 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 ISPs are shaping the IPv6 Forum, with a clear mission

448

Chapter 12: Generic Deployment Planning Guidelines

to promote IPv6 by dramatically improving the market and user awareness of IPv6. Global and regional IPv6 Forum summits are regularly hosted in member 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 opportunity for local industry, education, and government agencies to shape the adoption of IPv6 in their own region. 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/index.html)

•

Other significant IPv6 projects To develop the IPv6 awareness and disseminate experience within the networking community, several large regional projects are being run or have been run over the years. Their work groups have delivered 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 European Union. The project aims to promote widespread adoption of IPv6 by providing IPv6 training and knowledge transfer in developing regions. — 6NET (http://www.6net.org) 6NET was a three-year European project to demonstrate that continued growth of the Internet can be met using new IPv6 technology. The project built a native IPv6-based network connecting 16 countries to gain experience of IPv6 deployment and migration from existing IPv4based networks. It concludes by moving IPv6 to full production services for the academic community in Europe. — Euro6IX (http://www.euro6ix.org) The goal of the Euro6IX project was to support the rapid introduction of IPv6 among ISPs in Europe. 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 Force network pilots worldwide. Taking place across the United States at multiple locations, the Moonv6 project is a large, permanently deployed multivendor IPv6 network.

Education

449

— Network exchange points for IPv6 (http://www.napv6.net) A site with a list of several IPv6 exchanges known worldwide.

•

Dedicated IPv6 websites Several websites are dedicated to the promotion, education, and smooth adoption of IPv6. To start with, you could access the following sites: — Caida (http://www.caida.org) — IPv6.org (http://www.ipv6.org) — IPv6 Style (http://www.ipv6style.jp/en/index.shtml) — Sixxs (http://www.sixxs.net)

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:

• •

IPv6 Foundations (Introduction to IPv6, e-Learning)

•

IPv6 Security (e-Learning)

Designing & Deploying IPv6 Networks (Advanced IPv6, five-day instructor-led session (ILS) or e-Learning, integrated remote labs)

ILS is available through Cisco Learning Partners. Partners with a certain status can directly access most of the e-Learning on the Partner e-Learning Connection (PEC). The material is generally available to customers at a fee via the Cisco Learning Connection (CLC).

• •

PEC: http://www.cisco.com/warp/public/10/wwtraining/pec/peclogin.html CLC: http://www.cisco.com/en/US/learning/le31/le46/learning_customer_elearning_connection_tool_launch.shtml

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 projects—for example, 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 ISP educating a large staff will need a budget. That budget can range from low, in the case of reading and e-Learning, to high, for ILS. For example, at $1000 per person per class, the training expenses can quickly add up. A large enterprise or ISP can reduce this cost by applying a “train a trainer” strategy, where a couple of senior 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 to estimate the cost of deploying and operating IPv6 services in their network. Most important, however, these steps 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 Provider Network The first part of this book provided the tools and the knowledge necessary to design and operate IPv6 networks and services. Because you now have an understanding of the technology, we shift our focus to the system perspective of a deployment. IPv6 features are put together in the context of an existent IPv4 network to provide scalable, high-performance, and valuable services. These exercises intend to provide practical design examples for some of today’s network types and to put the accumulated IPv6 knowledge into the end-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 using Multiprotocol Label Switching (MPLS) in its core. It is a rather common network type in today’s major service provider market. The IPv6 deployment is based on the 6PE/6VPE features that leverage the existent MPLS infrastructure. (See Chapter 3, “Delivering IPv6 Unicast Services,” and Chapter 7, “VPN IPv6 Architecture and Services,” for details on these features.) This case study covers all aspects of rolling out and operating 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 services—unicast transport and VPN Design and implementation of other features—QoS, 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 in France, 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 to different market segments,

452

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

residential customers, and businesses. Two of these IPv4 services represent the principal revenue generators: layer 3 MPLS VPN and Internet access. Both services are MPLS switched through 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

Level-2 POP

Level-3 POP

IX/Level-1 POP

EuropCom core

Aggregation

Edge

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 the size of the L3 POP. Figure 13-2 presents EuropCom network in a geographical context. In the EuropCom network, Provider Edge (PE) routers are dedicated to either the Internet or layer 3 MPLS VPN access. The EuropCom backbone has the following characteristics:

• •

Highly secure over a dedicated private network.

• •

MPLS-based forwarding for both VPN traffic and Internet traffic.

• • •

Full L1 POP backbone redundancy.

Uses high-bandwidth OC-48 and OC-192 backbone links for L1-L1 POPs connectivity, OC-48 for L2-L1 POPs connectivity, and OC-48 to OC-3 for L3-L2 POPs connectivity. Is overengineered so that QoS is not needed in the core. EuropCom deploys DiffServ in the edge layer only. Uses a single autonomous system. Peers with major Tier 1 carriers.

Network Design Objectives

453

Figure 13-2 EuropCom Geographical Topology

Edinburgh Dublin

London Berlin

Brussels Brest Paris

Munich

Warsaw Prague Vienna Cluj

Milan Lisbon

Bucharest

Nice Madrid

Barcelona

Rome

Athens

EuropCom customer base covers the full range of typical ISP customers:

•

Small businesses—EuropCom provides network access and added-value services such as Internet access 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. Tier 2 ISP—EuropCom offers Carrier Supporting Carrier (CsC) service.

Network Design Objectives In the IPv6 deployment project, the EuropCom objective is to enable transport over its backbone and deliver a range of IPv6 services to its customer base. EuropCom operates under the assumption that in the first 1 to 3 years, the IPv6 traffic in the core of the network will not exceed 20 percent of its total data traffic. However, for the long run, one of the network design goals is to avoid treating IPv6 differently than IPv4 traffic, but rather make it part of the overall QoS strategy currently in place for the IPv4 services.

454

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

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. In the 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 support VPNv4, and IPv6 Internet access on PEs that currently provide IPv4 Internet access. PEs in L1 POPs will be enabled for IPv6 before the service launch. PEs at L2 and L3 POPs will be IPv6 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 and Internet access services: This can be achieved by using 6PE and 6VPE features, and carefully configuring BGP endpoints to match the existing IPv4 ones. This approach allows EuropCom 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 to service providers, enterprises of all sizes, and residential users. It now starts to receive more and more requests for IPv6-based services and IPv6 transport from its institutional customers:

• •

Service providers are interested in having access to the IPv6 Internet. Enterprises would like to interconnect IPv6 clusters in geographically discontiguous locations. They are also interested in interfacing over IPv6 with some of their own customers and having access to the IPv6 Internet. Various members of National Research Networks participating in IPv6-related research projects have also requested IPv6 traffic transport services to interconnect their campuses. For these customers, EuropCom provides just IPv6 traffic transport between sites.

Home users are generally not interested in the means by which services are delivered to them, yet there always are a few that are technology curious/savvy who would like to try new things. They have heard about web pages, radio stations, or game servers accessible over IPv6. EuropCom received multiple enquiries on the availability of IPv6 Internet access services. At the same time, EuropCom sees an IPv6 offering as a service differentiator and an opportunity to establish itself as a leader in this respect. For the most part, the IPv6 service requests received by EuropCom are similar to the existent IPv4 services: Internet access, layer 3 VPN, and DNS. The main challenges posed by these services are technical in nature; it is a matter of deploying them in a scalable manner with minimal 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 an ad-hoc basis with minimum investments. EuropCom understands the benefits and the opportunities offered by IPv6, thus making it part of

Network Design Objectives

455

its development strategy. EuropCom also plans to capitalize on the IPv6 awareness raised by the European Union and deploy new IPv6 services to differentiate itself from the competition. Therefore, it intends to make the most of an IPv6 infrastructure by developing and experimenting with new services. These new services would add to the technical challenges of deployment and the challenges of developing viable business models for them. The IPv6-based services will be kept independent of the IPv4 ones except for the network infrastructure resources that are being shared. Table 13-1 summarizes EuropCom planned offering. The first three service names are considered basic services, although the remaining names are considered value-added services. Table 13-1

EuropCom IP Services Service Name

IPv4 Service

IPv6 Service

Internet access

Yes

Yes

Layer 3 VPN

Yes

Yes

DNS

Yes

Yes

Content delivery

No

Yes

Content hosting

No

Yes

VoIP

Yes

Yes

This section reviews EuropCom’s current and planned services along with some of their requirements. The IPv6 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 transit providers or direct peering:

•

Wholesale access providers and service providers interface with EuropCom through Gigabit or 10 Gigabit Ethernet, OC-3 or OC-48 interfaces.

•

Business customers can choose between various high-bandwidth access options such as: E1 leased lines, 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 reach them:

•

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 the case with businesses.

456

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

•

Service providers are providing wholesale network access to residential users by encapsulating the user 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 and the L2TP tunnels.

In both these scenarios EuropCom Customer Edge (CE) routers represent the layer 3 gateway for the residential customers. This implies the fact that EuropCom is responsible for address assignment and management.

NOTE

The L2TP and PPP IPv6 access options were discussed in Chapter 3. For this case study, however, the focus is 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 EuropCom at 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 Internet access 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 be offered to VPN customers.

Carrier Supporting Carrier The Carrier Supporting Carrier (CsC) mechanism is commonly used by service providers to provide transport services for customer service providers (or carriers). Two types of customers will take advantage of this service:

•

The customer carrier can be an Internet service provider with an IPv6 (or dual-stack) core. It has two sites, 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 customer carrier has two sites. Both the backbone carrier (EuropCom) and the customer carrier use MPLS in their networks.

Network Design Objectives

457

DNS Services EuropCom provides DNS services for its IPv4 customers. This service becomes even more important to support the IPv6 customers; it is more difficult to remember IPv6 addresses than the IPv4 ones. Alongside all its uses with the IPv6 applications, similar to the IPv4 applications, DNS plays a particularly important role in deploying the peer-to-peer applications made available with IPv6. The DNS service is used by all the remaining services discussed in this section. The DNS servers are upgraded in EuropCom data center, and AAAA records are added to the A records as needed.

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 rent larger 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 provide feedback on their gaming experience. Console game manufacturers are also considering trialing their IPv6 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 the necessary infrastructure (Figure 13-3). EuropCom plans to continue experimenting with several other service offerings that leverage its storage resources. It intends to partner with multimedia companies to deliver content such as movies and video for an additional subscription fee.

Voice over IP Residential VoIP has seen lately a significant increase in its rate of adoption. It is now offered commonly as a second-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.

458

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Figure 13-3 Content Hosting/Storage Service

EuropCom

DNS Server

1. Resolve-for-Server

Storage Servers

2. Address-of Server 3. Request 4. Data-Download

Data Center

Access Provider

CE

CE

CE Customer Net

Customer Net

IP

Access Provider

IP

Customer Net

IP

In its trial phase, the VoIPv6 service allows for on-net to on-net calls between IPv6 customers of EuropCom only. The enticing aspect of the service is that customers have the option of purchasing from a EuropCom-authorized vendor video phones. This feature also allows EuropCom to advertise the service to its business customers who could use it for intercampus communication. Such features differentiate the VoIPv6 service 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 service design 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. Figure 13-4 shows the setup of a VoIPv6 call in this environment. The more technical-savvy customers can, of course, set up direct calls between themselves, in which case they leverage 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.

Network Design Objectives

459

Figure 13-4 VoIPv6 Service

DNS Server

2. Resolve-B

EuropCom

SIP Proxy Server

1. Invite

3. B-Address 4. Invite

6. OK

5. OK

Data Center

7. ACK 8. Phone-Call

Access Provider

CE

Access Provider

CE Customer Net

IP

CE Customer Net

IP

Customer Net

IP

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 ready its network for time- and delay-sensitive applications. This enables it to control the quality of the VoIPv6 service provided to businesses. On the other hand,

460

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

EuropCom has no control over the infrastructure used by wholesale 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 monitored as the number of subscribers increases. The adoption of the service will shape EuropCom future plans for expansion. These plans also include the deployment of gateways to the PSTN network that will allow for on-net to off-net calls, thus significantly increasing 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 IPv6 customer base to pay for its investments in the deployment. Part of EuropCom strategy to achieve this is to offer end-to-end solutions that go a bit beyond its IPv4 model. Setting up services such as content delivery or VoIP is an example of this strategy. With the same goal in mind (promoting IPv6 utilization through its core network), EuropCom plans to provide to its customer base guidance and support for applications and services that are transparent to the core network but will drive up IPv6 adoption. Two sets of services/applications are perceived by EuropCom as promising IPv6 enablers: peer-topeer applications, and IPv6 mobility. Peer-to-peer applications are a complex service concept as far as EuropCom is concerned. They are not services that it can offer and charge, and because it does not own the software, it cannot distribute it. At the same time, these applications are expected to drive IPv6 adoption and generate more IPv6 traffic through the EuropCom backbone. EuropCom will promote these applications by testing, referencing, and rating them on its IPv6 website. The current list of EuropCom “Top 4” shows that the most recommended peer-to-peer applications are the following:

•

Apache—A web server software that has full support for IPv6. Given that EuropCom residential IPv6 end 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. General information about Apache can be found at http://httpd.apache.org.

•

ConferenceXP—A shared-source tool from Microsoft Research that provides a conferencing and collaboration platform. ConferenceXP 3.2 supports the IPv6 protocol. General information can be found at http://www.conferencexp.com/.

•

BitTorrent/Bittornado—A peer-to-peer (P2P) file-distribution tool that is IPv6 enabled. General information about BitTorrent can be found at http://www.bittorrent.com/, and information about Bittornado is at http://www.bittornado.com/.

•

Jabber—An IPv6-enabled Instant Messaging and XML routing system. General information about Jabber 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 using these applications.

Network Design

461

Network Design EuropCom is an MPLS-based service provider. It took significant effort to stabilize their IPv4 infrastructure; therefore, they do not want to put it in jeopardy when starting the IPv6 service. Furthermore, operating costs for managing the core are already significant, and EuropCom does not plan to deploy any “service-specific” mechanism in the core that would drive these costs higher. Note that EuropCom considers the introduction of IPv6 as a 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 IPv6 deployment completely transparent to EuropCom infrastructure, this is a layer 2 technology, which was not selected for deploying any of the existing services currently supported by EuropCom, mainly because of scalability concerns.

•

IPv6 over IPv4 tunnels over MPLS—This approach was considered seriously because IPv4 over MPLS LSPs were already in place; enabling IPv6 tunnels over the existing LSP infrastructure sounded like a simple and attractive solution. Testing demonstrated some weakness in terms of configuration (the tunnel types have to be manually setup), traffic overhead (on small packets, the extra IPv4 header was significant), and troubleshooting (tunnel in tunnel proved be very tricky to manage). Performance-wise, this solution was also disappointing on some of 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 an IPv4 MPLS core of both Internet traffic (6PE) and VPN traffic (6VPE). The conclusion 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 troubleshooting VPNv4, which EuropCom is familiar with. In fact, the overall similarity between 6PE/6VPE and VPNv4 allows EuropCom to leverage their experience with VPNv4 in deploying and operating the IPv6 services.

The following list of goals was put in place by EuropCom to build a compelling business case for choosing the 6PE approach:

•

Minimal operational cost and risk. The core routers and related operations are unchanged. This applies to core hardware, software, configuration, list of enabled protocols, network management, QoS, routing and forwarding table size.

• • •

No impact on existing IPv4 and MPLS services.

•

No impact on IPv6 CE routers, other than peering with EuropCom PEs or CEs.

Only PE and CE routers are upgraded. EuropCom can deploy 6PE on existing PE routers or introduce dedicated PEs for IPv6 traffic. This provides a flexible solution depending on EuropCom customer requirements in terms of traffic and isolation.

462

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

6PE will provide IPv6 connectivity over EuropCom core and enable global IPv6 IA. 6VPE will 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 be deployed. With IPv4, PE routers are already dedicated to either VPN customers or Internet access customers: EuropCom plans to keep the same role separation with IPv6. IPv4 IA customers are the primary target for IPv6 IA, and VPNv4 customers for VPNv6 service. To optimize its business model, EuropCom plans to reuse IPv4 IA PEs and CEs for IPv6, and VPNv4 PEs for VPNv6. However, it does not exclude the cases where it might be practical to deploy 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 be separated in two categories:

•

Directly connected—This is the case of other service providers for which EuropCom provides transport or Internet access. Their equipment can be collocated with EuropCom at its various POPs.

•

Indirectly connected—This is the case of enterprises and residential users connecting to EuropCom over an access provider.

Neither of these groups of customers requires an extensive access layer. Figure 13-5 depicts the elements of the access layer. They are independent of the overall design of the POP, and they can be found in various combinations in all EuropCom POPs. The interfaces used at the access layer are summarized in Table 13-3. Table 13-3

Interface Types Used at the Access Layer Interface Type

Speed

Use

E1

2.048 Mbps

Access for enterprises, full or groomed dedicated circuits, Frame Relay

OC-3

155 Mbps

Access for Enterprises over ATM

OC-48

2.5 Gbps

Access to other service providers

OC-192

10 Gbps

Access for content providers

Gigabit Ethernet

1 Gbps

Access for metro Ethernet enterprise customers and for service providers collocated at the same POPs

10 Gigabit Ethernet

10 Gbps

Access for content providers

Network Design

463

Figure 13-5 EuropCom Access Layer

POP P

PE

PE

CE

CE

P

PE

PE

PE

CE

PE

PE

Leased Lines Frame Relay ATM

Internet Access

VPN

Metro-Ethernet Access Provider for Residential Customers

CE CE

CE

Customer Net 10-GigE/OC-192

OC-48

1-GigE

Customer Net

Customer Net

CE Customer Net Service Provider

E1/OC-3/Serial

Both PE and CE routers make up EuropCom access layer within a POP. They all perform access functions depending 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 to terminate layer 2 circuits, PPP sessions, or L2TP tunnels depending on the business model of the access provider connecting EuropCom to its IA customers. In this role, the CEs can also handle customer provisioning for both IPv4 and IPv6 services. In the case of IPv6, this function can be performed 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 to DNS and RADIUS servers.

•

PE routers aggregate multiple CE routers collocated in the POP. They also provide direct access to certain enterprise customers and to service providers. PE routers have limited involvement, if any, in the customer-provisioning functions.

464

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Additional layer 2 devices such as Ethernet switches or ATM switches are also part of the access layer. This section focuses on the access features enabled on these devices. Intermediate System-to-Intermediate System (IS-IS) is the interior gateway protocol (IGP) used within the access layer, between the PE and the CEs managed by EuropCom. In the case of IPv6, considering the lack of depth in the access layer, no hierarchy is necessary in the IGP design. Static routing is used in interfacing with residential and small business customers. eBGP is used between EuropCom and its service provider or large enterprise 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 limited depth 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 in the 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 to Enterprises and other service providers. A typical IX, shown in Figure 13-6, includes the following:

• • • • •

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 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, they also connect some local customers, whether IA customers or VPN customers. One of the characteristics of EuropCom 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, as detailed in the “Inter-AS Design” section.

Network Design

465

Figure 13-6 Level 1/IX POP Design Level-1 PoP/IX EuropCom Hosted Services: DNS Monitoring Hosting VoIP

Network Management Fault Management Performance Management Accounting Management

FireWall EuropCom To IPv6/IPv4 non-VPN Customer Sites

To IPv6/IPv4 VPN Customer Sites

EuropCom

Internet Access

To Other EuropCom POP/IX 6PE

P

EuropCom

ISPx

VPN Service

ISPx Network 6VPE

PE

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 by another regional service provider

•

EuropCom customers connected to another regional service provider’s POP with an inter-service provider agreement (performed in IX)

•

EuropCom customers connected to a EuropCom POP which itself is connected to the EuropCom core over 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-AS support in the context of IPv6, and the fourth bullet requires some CsC IPv6 support. These cases are detailed in the sections “Inter-AS Design” and “Carrier Supporting Carrier Service Design.” Note that in L3 POPs, some routers can play both the role of core Provider routers (P-routers) and Provider Edge (PE) routers.

Core Design The 6PE/6VPE approach has the advantage of minimizing the impact on the network core when enabling IPv6 traffic over it. In particular, P-routers do not need any software or hardware

466

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

upgrade, or any configuration change, 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 IPv4 connectivity within the network core and between PE routers. Because IPv6 routes for both Internet access and VPN will be announced “via” IPv4 PE loopback addresses already distributed by IS-IS, no changes are required 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’s own loopback addresses into IS-IS. So, on both IA PE routers and VPN PE routers, the LSP tail end belongs to 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 addresses configured on new PE routers. These are essentially Route Reflectors (RRs) because EuropCom design choice is to deploy dedicated RRs for 6PE/6VPE peering, while enabling IPv6 on existing PEs. With RRs, IPv4 addresses distributed via IS-IS in the core, PEs, and RRs can establish BGP peering over IPv4 and exchange IPv6 routes. Example 13-1 shows the IS-IS configuration (unchanged) in core router Bruxel-P. Example 13-1 IGP Configuration in the Core Bruxel-P#show running interface Serial0/0 ip address 172.20.4.2 255.255.255.0 ip router isis tag-switching ip ! router isis net 49.0000.0000.0013.00 redistribute connected metric 50 passive-interface Loopback0

MPLS Design Considerations For label distribution, EuropCom runs LDP over IPv4 to establish LSPs between the PE’s IPv4 loopback addresses, on PEs providing Internet access as well as on PEs providing VPN access. P-routers have all their interfaces running LDP and allocating labels for these PE loopback addresses. PE routers have their P-router-facing interfaces also running LDP. Because 6PE and 6VPE are planned to reuse the very same LSPs, LDP is completely transparent to the IPv6 deployment. Note that because both 6PE and 6VPE use the two-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 is therefore required for LDP on the PE-P interfaces.

Network Design

467

Example 13-2 presents the LDP configuration bits, valid for both IPv4 and IPv6 traffic. Example 13-2 LDP Configuration in the Core hostname Bruxel ip cef tag-switching tdp router-id Loopback0 interface Serial0/0 ip address 172.20.4.2 255.255.255.0 tag-switching ip

NOTE

Some service providers might be interested in using distinct LSPs for IPv4 and IPv6 traffic. Dedicated LSP head and tail end can be set up for IPv6 traffic. This is achieved by configuring BGP peering for address families IPv6 and VPNv6 between dedicated IPv4 loopback addresses, distinct from the ones used for IPv4 and VPNv4 peering. Note that, when doing so, the dedicated loopback addresses must be advertised into the core IGP, and be allocated labels by LDP. Some MPLS service provider want to control closely what addresses are being allocated labels. They use mpls ldp advertise-tag for ldp-pe-filter, where ldp-pe-filter is an access list that permits only LSP certain tail-end addresses. 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 bandwidth protection upon link failure within the core, with restoration times equivalent to SONET/SDH APS and greater scalability. Because IPv6 traffic uses the very same LSPs that have been set up and protected against failures 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 the core. Sometimes for legacy reasons, only the VPN traffic is MPLS switched, whereas the other traffic is IP forwarded. In such a deployment model, PE routers are dedicated to either providing VPN access service or IA service. The latter routers are not MPLS enabled. Furthermore, MPLS routers, whether core or edge, are configured 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 PE interfaces facing the MPLS core network must also be MPLS enabled, which involves some core routers reconfiguration. These core routers may also require configuration changes to allocate labels for the new PE addresses. Enabling IPv6 in such a network scenario, not covered in this chapter, leads to bigger impact on the service provider network, including some impact on the core.

468

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

QOS Design Considerations QoS design is detailed in the “Quality of Service Design” section. Overall, EuropCom expects its QoS design to be fully transparent to the IPv6 deployment. All classification has been pushed to the CE. The core is overengineered, so that no QoS mechanism is implemented there. EuropCom edges use the precedence to classify traffic sent to CEs: Precedence is expected to be set the same way for IPv6 and IPv4 (by CEs), to reach 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 send ICMPv6 messages, not even encapsulated in an MPLS stack. The issue is explained in Chapter 3, in the section “IPv6 over 6PE.” Although this is acceptable for EuropCom in the initial phases, it is not sustainable on the long run. Note that this 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 discovering optimal MTU throughout the network (PMTU). None of these two operational aspects is critical, as explained in section “Operating and Troubleshooting the Network.” The EuropCom network has been designed and configured 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 LSP endpoints. EuropCom has chosen to wait for the next scheduled core software upgrade to get a resolution to the challenges just discussed.

Edge Design EuropCom has decided to reuse existing PE routers when deploying IPv6, except for the RRs, which are a critical part of their IPv4 service design. Instead, it is migrating PE routers dedicated to IPv4 IA to 6PE routers (supporting both IPv4 and IPv6 Internet access) and PE routers dedicated to VPNv4 access to 6VPE routers (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 term of node upgrade (hardware/software) and in terms of configuration. PE routers need to be upgraded with images 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 Test program, and on certain Cisco platforms.

Network Design

469

Software upgrade is not a concern: All PEs were upgraded a while ago to a Cisco IOS version that supports IPv6 during a routine maintenance operation. So the current migration envisioned consists essentially of a 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 be referred 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 AS-21114 CE-xx

AS-22200

CE-Cisco[41]

CE-IBM[34]

EuropCom AS-33751 PE-IA[30]

PE-VPN[38]

Edinburgh

PE-VPN_1[36]

PE-IA

PE-VPN_1[29]

PE-VPN[28]

Berlin-POP

London-POP

RR6[48]

Warsaw

RR6_1[49] Paris-POP

Prague Brussels

RR6

RR6[44]

Munich-POP

RR6_1[45]

RR6_1

Vienna Bucharest

IGW[1] RR6[46] Lisbon

Nice-POP Madrid

ASBR[70]

RR6_1[47]

Barcelona

Rome

Milan-POP

PE-IA[26]

PE-VPN[27] PE-IA[61]

PE-VPN[62]

CE-EuropCom[23] CE-IBM

CE-Cisco

AS-20331 CE-a[60] AS-22200 AS-27301 CE-b[61]

AS-17110 CE-c[62]

cpes

AS-21114

Athens

470

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

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

• • •

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 any numeric suffix. If several routers of the same category are deployed in the same location, a numeric suffix 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-facing interfaces 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.

•

BGP IPv6 (and/or VPNv6) peering must be established with remote PEs to which the PEs intend to forward MPLS-encapsulated IPv6 traffic. Note that in the EuropCom design, the IPv6 iBGP peering is always performed through RRs, as detailed in the “Route Reflector Design” section.

Some IPv6 routing protocol (static, IGP, BGP) must be configured/enabled on the CE-facing interfaces to exchange IPv6 routes with CEs.

These three basic configuration tasks enable the network to provide basic IPv6 unicast transport and VPN services. They are reviewed in the sections “PE-CE Interface Design,” “PE-CE Routing Design,” and “PE-PE Routing Design.” EuropCom has chosen to deploy dedicated RRs for 6PE and 6VPE. This is to avoid overloading existing RRs with additional configuration and BGP routes, and keep the potential influence and security concerns distinguished between IPv4 and IPv6. A full

Network Design

471

configuration setup is required for these routers that are added to the 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 the Network.” Before making the network changes mentioned, EuropCom has defined the IPv6 addressing plan for the deployment. This is detailed in the “Addressing” section. It covers both EuropCom’s own addressing plan and the 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 not initially plan to dedicate PEs for IPv6 traffic, but rather to enable IPv6 on interfaces previously connecting IPv4-only customers. 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 IPv6 Refresher,” for the benefits of using link-local). These link-local addresses will not derive from the EUI-64 address of the interface, because extensive BGP reconfiguration would be necessary when the hardware is replaced because of failure or to upgrade. Instead, EuropCom is telling its IPv6 customers to use link-local addresses for CE-PE peering in the form of FE80::ASN:ID, where ASN is the customer autonomous system number, 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), where new configuration (IPv6) is highlighted. Example 13-3 PE-CE Interface Configuration for IA hostname Nice-PE-IA !PE#26 .. !To Nice-CE-a -(AS:20331, 2001:6FC:2124:1) interface Serial1/0 ip address 172.21.7.1 255.255.255.0 ipv6 address FE80::83D7:26 link-local

continues

472

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Example 13-3 PE-CE Interface Configuration for IA (Continued) ! !To Nice-CE-b (AS:27301,2001:6FC:2124:2) interface Serial2/0 ip address 172.21.8.1 255.255.255.0 ipv6 address FE80::83D7:26 link-local ! !To Nice-CE-c (AS:17110, 2001:6FC:2124:3) interface Serial3/0 ip address 172.21.9.1 255.255.255.0 ipv6 address FE80::83D7:26 link-local

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 IPv6 operation 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 on CE-PE interfaces). Example 13-4 illustrates Nice-CE-b configuration. Example 13-4 CE-PE Interface Configuration hostname Nice-CE-b ! Node=61, AS=27301 Prefix=2001:6FC:2124:2::/56 .. interface Loopback0 ip address 100.61.61.1 255.255.255.255 ipv6 address 2001:6FC:2124:2::61/128 ! !to Nice-PE-IA interface Serial0/0 ip address 172.21.8.2 255.255.255.0 ipv6 address FE80::6AA5:61 link-local

A PE used for VPNv6 access, such as Nice-PE-VPN, will have an interface configuration as shown in Example 13-5. Example 13-5 PE-CE Interface Configuration for VPN Access hostname Nice-PE-VPN !PE#27 interface Loopback0 ip address 100.27.27.1 255.255.255.255 ipv6 address 2001:6FC::27/128 ! !to Nice-CE-Cisco interface Serial0/0 vrf forwarding Cisco-Nice ip address 172.21.4.1 255.255.255.0 ipv6 address FE80::83D7:27 link-local ipv6 address 2001:6FC::27/128 ! !to Nice-CE-IBM interface Serial1/0

Network Design

473

Example 13-5 PE-CE Interface Configuration for VPN Access (Continued) vrf forwarding IBM-Nice ip address 172.21.5.1 255.255.255.0 ipv6 address FE80::83D7:27 link-local ipv6 address 2001:6FC::27/128

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 to residential users. The PE-CE interface in that case is configured exactly the same way as customers CEs, with a 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. EuropCom would prefer to use eBGP as much as possible, although some EuropCom customers like the simplicity of static routing, and still others, using OSPFv3 or EIGRPv6, would prefer not to have to operate another protocol such as BGP. In addition, CEs owned by EuropCom (for residential access) will run IS-IS for IPv6 toward the PE.

Static Routing Design Considerations Some of the smallest enterprise customers, which are single homed to EuropCom, are using an IPv6 default route to the PE, which in turn has static routes to the customer site. This configuration is limited to those sites with a small number of routes and no need for any dynamic routing protocol. These enterprises are usually getting a /56 (if they have a single subnet) up to a /48 (multiple subnets) prefix, which end up in a single static entry at the 6PE. Static routing is applicable to both VPN and non-VPN enterprise customers. The following configuration excerpt illustrates the Nice-PE-IA setup, providing static routing toward customers CE-b and CE-c, which have been assigned, respectively, 2001:6FC:1119:1::/56 and 2001:6FC:1119:2::/56. hostname Nice-PE-IA !PE#26 .. !Static routes to Customer sites: CE-b, CE-c ipv6 route 2001:6FC:2124:2::/56 Serial2/0 ipv6 route 2001:6FC:2124:3::/56 Serial3/0

The corresponding CE routers (Nice-CE-b in the following example) use a default route to point to Nice-PE-IA: hostname Nice-CE-b ! Node=61, AS=27301 Prefix=2001:6FC:2124:2::/56 .. !Static route to EuropCom ipv6 route ::/0 Serial 0/0

474

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

In the case of EuropCom’s own CEs interfacing CPEs for providing residential access, static routes are also automatically added when using DHCP Prefix Delegation (DHCP-PD) (a default route ::/0 pointing to the delegating 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 EuropCom network operations team is familiar with BGP, which they like for its flexibility to deal with policies on a per-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 peers over link-local addresses, with the addressing scheme defined in the “Addressing” section. Example 13-6 illustrates the BGP configuration for a 6PE router providing IPv6 IA (Nice-PE-IA). New configuration elements for IPv6 are highlighted. Example 13-6 eBGP Configuration for a PE Router Providing IPv6 IA (Nice-PE-IA) hostname Nice-PE-IA !PE#26 router bgp 33751 neighbor FE80::4F6B:44%Serial1/0 remote-as 20331 neighbor 172.21.7.1 remote-as 20331 ! address-family ipv4 neighbor 172.21.7.1 activate bgp dampening 15 750 3000 60 exit-address-family ! address-family ipv6 neighbor FE80::4F6B:44%Serial1/0 activate bgp dampening 15 750 3000 60 exit-address-family

As a general VPNv4 BGP policy, and to protect PE routers, EuropCom is limiting the number of prefixes received 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 are highlighted. Example 13-7 eBGP Configuration for a PE Router Providing VPNv6 Access (Nice-PE-VPN) hostname Nice-PE-VPN !PE#27 .. router bgp 33751 .. address-family ipv4 vrf Cisco-Nice neighbor 172.21.4.2 remote-as 21214

Network Design

475

Example 13-7 eBGP Configuration for a PE Router Providing VPNv6 Access (Nice-PE-VPN) (Continued) neighbor 172.21.4.2 activate neighbor 172.21.4.2 maximum-prefix 100 bgp dampening 15 750 3000 60 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf IBM-Nice neighbor 172.21.5.2 remote-as 22200 neighbor 172.21.5.2 activate neighbor 172.21.5.2 maximum-prefix 100 bgp dampening 15 750 3000 60 no auto-summary no synchronization exit-address-family ! address-family ipv6 vrf Cisco-Nice neighbor FE80::52DE:33%Serial0/0 remote-as 21214 neighbor FE80::52DE:33%Serial0/0 activate neighbor FE80::52DE:33%Serial0/0 maximum-prefix 5 bgp dampening 15 750 3000 60 no synchronization exit-address-family ! address-family ipv6 vrf IBM-Nice neighbor FE80::56B8:35%Serial1/0 remote-as 22200 neighbor FE80::56B8:35%Serial1/0 activate neighbor FE80::56B8:35%Serial1/0 maximum-prefix 5 network 2001:6FC::27/128 bgp dampening 15 750 3000 60 no synchronization exit-address-family

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. Example 13-8 eBGP Configuration for a CE Router hostname Nice-CE-Cisco !PE#33 .. router bgp 21214 no synchronization bgp log-neighbor-changes neighbor 172.21.4.1 remote-as 33751 neighbor FE80::83D7:27%Serial0/0 remote-as 33751 no auto-summary ! address-family ipv4 neighbor 172.21.4.1 activate

continues

476

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Example 13-8 eBGP Configuration for a CE Router (Continued) neighbor 172.21.4.1 allowas-in 2 redistribute ospf 100 ! address-family ipv6 neighbor FE80::83D7:27%Serial0/0 activate neighbor FE80::83D7:27%Serial0/0 allowas-in 2 network 2001:6FC:1123:1::/52 !site-address aggregate-address 2001:6FC:1123:1::/52 summary-only no synchronization exit-address-family

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. The same considerations for choosing the IPv4 IGP apply to IPv6. However, with Cisco IOS setups, no IGP currently supports IPv6 in a VPN context, so this alternative cannot be offered by EuropCom to its VPNv6 customers. Non-VPN enterprise customers would not want to expose their IGP outside the enterprise, so this is not an attractive alternative for them. Finally, EuropCom-owned CEs need to run an IPv6 IGP with the PE. One possibility would have been for EuropCom to use iBGP between the CE and the PE. Several drawbacks and deployment constraints led EuropCom to abandon this design:

•

With the first approach considered, plain iBGP sessions are set up from the CE to other iBGP speakers. This requires a full mesh of iBGP sessions from that CE to other CEs and 6PEs, a solution that scales poorly.

•

Alternatively, the CE is configured as the RR client of its 6PE router of attachment. This indirectly leads to MPLS being enabled on the CE-PE interface (BGP reflection implies that the BGP sessions share 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 to be advertised all over EuropCom network.

•

Alternatively, confederations could be used. The BGP autonomous system is divided into multiple autonomous systems. In the EuropCom case, that would be one autonomous system for the core, and one autonomous system for PE-CE pairs. These autonomous systems are running eBGP between them, but they exchange routing as if they were using iBGP; next hop, metric, and local preference information 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 would require a significant redesign of the BGP EuropCom infrastructure.

Network Design

477

In the end, EuropCom decided to go for IS-IS between these EuropCom CEs and the PE, as illustrated in Example 13-9. Example 13-9 Using IS-IS on the PE-CE Interface hostname Nice-CE-EuropCom !PE#23 .. !to Nice-PE-IA interface interface Serial0/0 ip address 172.21.23.2 255.255.255.0 ipv6 address FE80::52DE:23 link-local ipv6 router isis EuropCom23 ! router isis EuropCom23 net 49.0001.0000.0000.0023.00

PE-PE Routing Design Peering between 6PEs and between 6VPEs is similar to the currently deployed VPNv4 PE-PE peering. It is using iBGP, with RRs to limit the number BGP sessions. Because EuropCom plans to deploy dedicated RRs for handling iBGP IPv6 route distribution, the iBGP sessions 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 addresses 100.56.56.1 and 100.57.57.1, respectively. The IPv6 RRs have addresses 100.46.46.1 and 100.47.47.1. The RR 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 implicit in the configuration, and IPv4, where BGP does not transport a label when advertising prefixes). This is achieved 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) hostname Nice-PE-IA !PE#26 .. router bgp 33751 bgp log-neighbor-changes !For IPv4 Internet access to Milan-RR4 neighbor 100.56.56.1 remote-as 33751 neighbor 100.56.56.1 update-source Loopback0 neighbor 100.57.57.1 remote-as 33751 neighbor 100.57.57.1 update-source Loopback0 ! !For IPv6 Internet access to Milan-RR6 neighbor 100.46.46.1 remote-as 33751

continues

478

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Example 13-10 i BGP Configuration for a PE Router Providing IPv6 IA (Nice-PE-IA) (Continued) neighbor 100.46.46.1 update-source Loopback0 neighbor 100.47.47.1 remote-as 33751 neighbor 100.47.47.1 update-source Loopback0 ! address-family ipv4 neighbor 100.56.56.1 neighbor 100.57.57.1 exit-address-family ! address-family ipv6 neighbor 100.46.46.1 neighbor 100.46.46.1 neighbor 100.47.47.1 neighbor 100.47.47.1 exit-address-family

activate activate

activate send-label activate send-label

Example 13-11 illustrates an iBGP configuration on a PE router providing VPNv6 access. Example 13-11 BGP Configuration for a PE Router Providing VPNv6 Access (Nice-PE-VPN) hostname Nice-PE-VPN !PE#27 .. router bgp 33751 bgp log-neighbor-changes !For VPNv4 to Milan-RR4 neighbor 100.56.56.1 remote-as 33751 neighbor 100.56.56.1 update-source Loopback0 neighbor 100.57.57.1 remote-as 33751 neighbor 100.57.57.1 update-source Loopback0 !For VPNv6 to Milan-RR6 neighbor 100.46.46.1 remote-as 33751 neighbor 100.46.46.1 update-source Loopback0 neighbor 100.47.47.1 remote-as 33751 neighbor 100.47.47.1 update-source Loopback0 ! address-family vpnv4 neighbor 100.56.56.1 activate neighbor 100.56.56.1 send-community extended neighbor 100.57.57.1 activate neighbor 100.57.57.1 send-community extended bgp dampening 15 750 3000 60 exit-address-family ! address-family vpnv6 neighbor 100.46.46.1 activate neighbor 100.46.46.1 send-community extended neighbor 100.47.47.1 activate neighbor 100.47.47.1 send-community extended bgp dampening 15 750 3000 60 exit-address-family

Network Design

479

Route Reflector Design To scale its IPv4 IA service and its VPNv4 service, EuropCom leveraged RRs in its network design. It makes a 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 drastically reducing the number of BGP sessions. One RR usually peers with many iBGP speakers, preventing a full mesh of BGP sessions. Because both IA traffic and VPN traffic are MPLS switched, RRs are not part of the LSP and can potentially be located anywhere in the network. IPv4 RRs are deployed only at L1 POPs, and dedicated for peering with IA PEs and VPN PEs. PEs peer with RRs based on their geographical proximity. RRs peer together in a full-mesh topology. EuropCom plans to follow a similar design for IPv6 RRs and deploy IPv6 RRs at L1 POPs. Prefix aggregation can be done more aggressively with IPv6, which will keep the number of routes under better control. With this in mind, EuropCom does not expect the IPv6 BGP table size to get more than a few hundred entries per VPN for the next two to three years. As far as the IA, EuropCom considered the total number of allocated IPv6 prefixes worldwide (on 17/10/2005, it was 1322) and the number of BGP IPv6 routes currently deployed in IPv6 core BGP routers (700 entries in October 2005 according to http://www.cidr-report.org and evolving linearly). EuropCom expects the total number of BGP IPv6 routes to stay below 2000 entries by 2008, well below the current 150,000 IPv4 entries it is experiencing. Therefore, unlike IPv4 RRs, IPv6 RRs will be shared between IPv6 IA and IPv6 VPN. EuropCom will monitor any change in the RIRs address allocation strategy: If the RIRs agree to allocate /32 prefix to large corporations for provider-independent prefixing, BGP IPv6 tables could quickly reach tens thousands of entries. Variation in the pace of the IPv6 prefix allocation, as well as service growth and customer needs, will dictate the expansion of the RR infrastructure and the possible specialization of RRs to each of the two services. The deployment strategy for RR is different from the one for PE routers. EuropCom wants to separate IPv6 RRs from IPv4 RRs. If anything unexpected happens with IPv6, only PEs servicing IPv6 will be affected and only from the IPv6 service perspective. Because EuropCom plans to deploy IPv6 access incrementally, this strategy will dramatically lower the risk on business-critical services such as IPv4 IA and VPNv4. PEs (6PE and 6VPE) will be connected to RRs based on geographical proximity, exactly like the VPNv4 RRs. For redundancy 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 the P-routers and PE routers. It will then configure BGP peering to PEs in the L1 POP, as well as PEs in L2 POP and L3 POP attached to it. Figure 13-8 illustrates the peering points between the RR in L1 POP, and the set of RR clients.

480

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Figure 13-8 EuropCom RR Design RR6

Other EuropCom L1-POPs

RR6

RR6

Route-Reflector of Other Service Provider(s) Route-Reflector xxx-RR6

Route-Reflector xxx-RR6_1

Internet Gateway xxx-IGW

xxx-PE-VPN

L1-POP xxx xxx-PE-IA

zzz-PE-IA

Provider Edge Routers

zzz-PE-VPN yyy-PE-IA

L3-POP

yyy-PE-VPN

L2-POP

VPNv6 (6VPE) + IPv6 (6PE) Peerings IPv6 (6PE) Peering

The following list of BGP RR clients must be configured in IPv6 RR (xxx-RR6 and xxx-RR6_1) routers at each 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. This includes both VPNv6 (6VPE) peering for interconnecting customer sites, and IPv6 peering (6PE) for providing IA to VPN customers.

•

PE routers (yyy-PE-IA, zzz-PE-IA) of the L2 POPs and L3 POPs (underneath this L1 POP) providing IPv6 IA to EuropCom customers. This is IPv6 (6PE) peering.

•

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 IPv6 Internet.

Network Design

481

•

RRs from other service providers. This is to provide inter-AS connectivity, and it includes both IPv6 and 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 families enabled, as shown in Figure 13-9

Figure 13-9 Topology of the IPv6 and VPNv6 Route Reflection

London Brussels Paris

Munich Vienna

Full Mesh VPNv6 and IPv6

Madrid

Barcelona

Milan

Rome

Example 13-12 illustrates the Milan-RR6 configuration, with regard to peering with Milan PEs (providing IA and VPN access) and Nice PEs (L2 POP attached to Milan). It also includes peering with Milan’s Internet gateway (Milan-IGW). It does not show peering with L3 POPs, peering with RRs in other L1 POP, or peering with RRs of other service providers. Example 13-12 RR Configuration Example hostname Milan-RR6 !RR#46 router bgp 33751 !6PE peering for providing Internet access address-family ipv6 !Peering with Internet Gateway Milan-IGW neighbor 100.1.1.1 activate

continues

482

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Example 13-12 RR Configuration Example (Continued) neighbor 100.1.1.1 route-reflector-client neighbor 100.1.1.1 send-label !Peering with Nice Internet access router Nice-PE-IA 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. The VRF 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, route distinguisher (RD), and route target. Enabling them for IPv6 is a matter of service enhancement and service coexistence 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

Network Design

483

The concept of Multiprotocol VRF (MP-VRF) was detailed in Chapter 7, and it suits perfectly EuropCom strategy. Only a fraction of the actual VPNv4 design needs to be revisited. The remaining parts are a migration task, from an IPv4 service to a dual-stack service. Out of the six steps defined above, Steps 1, 2, and 3 are handled by the migration of IPv4 VRF(s) into MP-VRF(s). VRF names, route targets, and RDs already defined for VPNv4 service apply seamlessly to VPNv6 service wherever MP-VRF is enabled. The VRF migration can be done automatically and without disrupting VPNv4 VRF operations (including forwarding) by executing the following commands: Nice-PE-VPN(config)#service internal Nice-PE-VPN(config)#vrf upgrade-cli multi-af-mode common-policies [vrf ]

EuropCom plans to use this command, one VRF at a time (the command can do all VRF at once, but the migration will be driven by individual customer requests). Example 13-13 illustrates how the migration works in router Nice-PE-VPN. Example 13-13 Migrating IPv4 VRF to MP-VRF Nice-PE-VPN(config)#do show running hostname Nice-PE-VPN !#27 .. ip vrf Cisco-Nice rd 21214:1 route-target export 21214:1 route-target import 21214:1 ! interface Serial0/0 ip vrf forwarding Cisco-Nice ip address 172.21.4.1 255.255.255.0 .. Nice-PE-VPN(config)#service internal Nice-PE-VPN(config)#vrf upgrade-cli multi-af-mode common-policies vrf Cisco-Nice Nice-PE-VPN(config)#do show running hostname Nice-PE-VPN !#27 .. vrf definition Cisco-Nice rd 21214:1 route-target export 21214:1 route-target import 21214:1 address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family ! interface Serial0/0 vrf forwarding Cisco-Nice ip address 172.21.4.1 255.255.255.0

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” for that particular VRF, and on all interfaces that belong to it.

484

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Step 4 requires configuring the VPNv6 interaction with the backbone control plane. The interaction with the backbone control plane requires some design and configuration work and was described in the “PE-PE Routing Design” section. Step 5 is partly covered by the migration to MP-VRFs (the VRF bound to the interface that was IPv4 only became IPv4 and IPv6). The remaining part is to configure IPv6 (addressing and routing) in the interface. Step 6 does not need to be revisited because the same QoS policies apply to IPv6. The existing QoS design is expected to map onto VPNv6 and IPv6 IA traffic seamlessly. This is described in the “Quality of Service Design” section.

NOTE

With MP-VRF, an interface can only belong to one VRF, and a VRF is uniquely identified by a single name and a single RD. On a given VRF interface, IPv4 and IPv6 can be enabled together or separately, but they cannot be put in different VRFs. The enabling of each protocol is done at two levels: The protocol is enabled in the VRF definition, and then activated on a VRF interface by assigning an address (IPv4 or IPv6) to the interface. It is a VRF design choice to share a route target between IPv4 and IPv6, or to keep them distinct. EuropCom chose to keep them identical, to minimize the redesign of VRF when deploying IPv6, and to minimize operation costs. However, that does not prevent it from enabling IPv4 only on certain sites of a given VPN, in which 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 VPNv4 traffic, 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 that a complete LSP is set up end to end. In this scenario, ASBRs are not VPN aware; only RRs are VPN aware. For VPNv4, the following setup/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 the remote service provider location. — VPN RRs are leaking one loopback address (/32) for enabling interprovider (inter-RR) eBGP peering.

Network Design

•

485

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. The next 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, a Tier 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 the configuration at Nice-PE-IA, Nice-PE-VPN, Milan-RR6, and Milan-ASBR routers. Note that for Milan-ASBR, the configuration upgrade decision is driven by the new Milan-RR6 (see “Route Reflector 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 PE routers Nice-PE-IA and Nice-PE-VPN (providing IPv6 IA and VPN access, respectively) to the xxCom network. Figure 13-10 BGP Peering Points for Enabling Inter-AS in Nice POP

xxCom

Milan L1-POP

Route-Reflector xxCom_RR6 Route-Reflector Milan_RR6

AS Boundary Router xxCom-ASBR

AS Boundary Router Milan-ASBR

VPNv6 (6VPE) + IPv6 (6PE) Peerings IPv6 (6PE) Peering IPv4 + Label Peering

Nice L2-POP Nice-PE-IA

Nice-PE-VPN

486

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

The following list of additional BGP peerings is necessary to enable inter-AS (Scenario C) communication from 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 points between the same pair of routers already described in the section “Route Reflector Design.” These BGP 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 (MilanASBR). This is also for 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 autonomous systems, to exchange IPv6 and VPNv6 routes, respectively.

The BGP peering (IPv4 with label) between boundary routers (Milan-ASBR and xxCom-ASBR) was already set 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-AS Scenario 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 hostname Nice-PE-VPN !PE#27 router bgp 33751 address-family ipv4 neighbor 100.46.46.1 activate neighbor 100.46.46.1 send-label network 100.27.27.1 255.255.255.255

The RR in Milan is configured to peer with the xxCom RR, for both address families IPv6 and VPNv6, as illustrated in Example 13-15. Example 13-15 Inter-AS: IPv6 and VPNv6 Peering from Milan-RR6 to xxCom hostname Milan-RR6 !PE#46 router bgp 33751 neighbor 200.43.43.1 remote-as 16531 !to XXCom RR .. address-family vpnv6 !VPNv6 interAS neighbor 200.43.43.1 activate neighbor 200.43.43.1 send-community both neighbor 200.43.43.1 next-hop-unchanged allpaths ! address-family ipv6 !IPv6 IA interAS neighbor 200.43.43.1 activate neighbor 200.43.43.1 send-label neighbor 200.43.43.1 next-hop-unchanged allpaths

Network Design

487

The RR in Milan is also peering with the ASBR (Milan-ASBR) and with each PE (Nice-PE-IA and Nice-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#46 router bgp 33751 .. address-family ipv4 neighbor 100.70.70.1 activate !Peering to Milan-ASBR neighbor 100.70.70.1 send-label neighbor 100.26.26.1 activate !Peering to Nice-PE-IA neighbor 100.26.26.1 send-label neighbor 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 hostname Milan-ASBR !PE#70 router bgp 33751 .. neighbor 100.46.46.1 remote-as 33751 !to Milan-RR6 neighbor 90.1.1.2 remote-as 16531 !to xxCom ASBR ! address-family ipv4 neighbor 100.46.46.1 activate neighbor 100.46.46.1 send-label neighbor 90.1.1.2 activate neighbor 90.1.1.2 send-label

In summary, to enable interprovider access to xxCom, EuropCom performed the steps listed in Table 13-4. Table 13-4

Inter-AS Deployment Task List Node

EuropCom Task

6PE

IPv4 with label MP-iBGP peering to RRs Leak loopback address (network 100.x.x.1 mask 255.255.255.255) (6PE peering with RRs done outside this task)

6VPE

IPv4 with label MP-iBGP peering to RRs Leak loopback address (network 100.x.x.1 mask 255.255.255.255) (6VPE peering with RRs done outside this task) continues

488

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Table 13-4

Inter-AS Deployment Task List (Continued) Node

EuropCom Task

IPv6 RR

IPv4 with label MP-iBGP peering to each 6PE and 6VPE IPv4 with label MP-iBGP peering to ASBR Leak loopback address (network 100.x.x.1 mask 255.255.255.255) IPv6 with label MP-eBGP peering to xxCom IPv6 RR VPNv6 MP-eBGP peering to xxCom IPv6 RR (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)

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 VPN customers. Carrier’s Carrier is another IPv6 service that EuropCom is offering to other ISPs.

Global IPv6 Internet Access Design and Implementation The EuropCom infrastructure must be first enabled to provide IPv6 over MPLS connectivity from PEs to IPv6 Internet gateways. The IPv6 Internet gateways are typically located at each EuropCom IX (L1 POP). PEs located in the L1 POP interface the Internet gateway over native IPv6 (routing and forwarding). IS-ISv6 is used to exchange routes between the PE to the IGW. PEs located in L2 and L3 POPs interface with the IGW of their closest L1 POP. The peering in that case is performed over 6PE (IPv6 over MPLS), and routes are exchanged using iBGP peering via RRs. The IGW is also a 6PE with regard to providing IA to those remote 6PEs/CE. From the BGP configuration standpoint, the IGW (for instance Milan-IGW) is just another PE, peering with the RRs, as described in the section “Route Reflector Design.” Table 13.5 reviews the tasks taking place to provide IPv6 IA to a new EuropCom customer.I

Basic Services Design and Implementation

Table 13-5

489

A Deployment Task List EuropCom Task

Customer Task

In L1 POP, enable PEIGW IS-ISv6 peering. Note that this is done prior to service deployment. In L1 POPs, enable RRIGW iBGP peering. Note that this is done prior to service deployment, for the benefit of L2/L3 POP’s PEs. Enable L2/L3 POP’s PERR iBGP peering. Note that this is done once, 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 numerous available mechanisms (native, tunnels, and so on).

1) Enable the PE-CE interface by configuring link-local in the following form:

1) Enable the CE-PE interface by configuring link-local in the following form:

ipv6 address FE80::ASN:ID link-local

ipv6 address FE80::ASN:ID link-local

2) Configure a global address on the loopback interface in the following form:

2) Configure a global address on the loopback interface in the following form:

ipv6 address 2001:6FC::node#/128

ipv6 address 2001:6FC:P::node#/128

3) Protect the global address against denial-ofservice (DoS) attacks using access control lists (ACLs).

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.

Layer 3 MPLS VPN Service Design and Implementation Before enabling IPv6 VPN service for its VPNv4 customers, EuropCom has set up its infrastructure to establish 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 RRs are 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.

490

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

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 RRIGW iBGP peering. Note that this is done prior to service deployment, for the benefit of L2/ L3 POP’s PEs. Enable L2/L3 POP’s PERR 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, and so on).

Migrate the IPv4 VRF to MP-VRF using vrf upgrade-cli command. 1) Enable the PE-CE interface by configuring linklocal in the following form:

1) Enable the CE-PE interface by configuring link-local in the following form:

ipv6 address FE80::ASN:ID link-local

ipv6 address FE80::ASN:ID link-local

2) Configure a global address on the loopback interface in the following form:

2) Configure a global address on the loopback interface in the following form:

ipv6 address 2001:6FC::node#/128

ipv6 address 2001:6FC:P:site#::node#/128

2) Configure a global address on the each PE-CE interface in the following form:

3) Protect the global address against DoS attacks using ACLs.

ipv6 address 2001:6FC::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 will need to access the IPv6 Internet. The design of this service is similar to global IA service. 6VPE routers located in a L1 POP access the Internet gateway natively, whereas 6VPE routers located in L2 and L3 POPs access the IGW (in their closest L1 POP) over 6PE.

Basic Services Design and Implementation

491

In the latter case, core design (essentially setup of 6VPE/RR/IGW iBGP peering) took place before any customer request for a few locations, but is a preliminary task for enabling other locations, based on customer request. 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. Example 13-18 VPN IA Configuration hostname Nice-PE-VPN !PE#27 .. router bgp 33751 bgp log-neighbor-changes .. !For VPNv6 to Milan-RR6 address-family vpnv6 neighbor 100.46.46.1 activate neighbor 100.46.46.1 send-community extended neighbor 100.47.47.1 activate neighbor 100.47.47.1 send-community extended bgp dampening 15 750 3000 60 exit-address-family !Peering to Route-Reflector Milan-RR6 for providing Internet access address-family ipv6 neighbor 100.46.46.1 activate neighbor 100.46.46.1 send-label neighbor 100.47.47.1 activate neighbor 100.47.47.1 send-label network 2001:6FC:1123:1::/52 network 2001:6FC:1124:1::/52 network 2001:6FC::27/128 bgp dampening 15 750 3000 60 exit-address-family

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 and 2001: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 the VRF to access global resources, and to allow responses from global resources to enter the VRF. This requires a default route in the VRF, pointing to the IGW, and a route in the default table pointing to the VRF (for prefixes owned by this VRF’s customer). Example 13-19 at Nice-PE-VPN illustrates the static routing configuration setup for EuropCom customers Cisco and IBM.

492

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

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-IGW ipv6 route vrf Cisco-Nice ::/0 2001:6FC::1:0:0:1 nexthop-vrf default ipv6 route vrf IBM-Nice ::/0 2001:6FC::1:0:0:1 nexthop-vrf default !Routes for inbound traffic from Milan-IGW to VRF ipv6 route 2001:6FC:1123:1::/52 Serial0/0 nexthop-vrf Cisco-Nice ipv6 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 (PEPE) 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: address-family ipv6 network 2001:6FC:P:site#::/n Configure a static route from VRF to IGW:

Configure a default route to 6VPE:

ipv6 route vrf ::/0 2001:6FC::1:0:0:1 nexthop-vrf default

ipv6 route ::0/0

Configure a static route from default to VRF: ipv6 route 2001:6FC:P:site#::/n nexthop-vrf

Note that no configuration is necessary at the IGW, other than peering with RRs over 6PE iBGP (done once at core design phase) and leaking a single loopback IPv6 address. This is shown in Example 13-20. Example 13-20 IGW Configuration Example hostname Milan-IGW !#1 .. router bgp 33751 bgp log-neighbor-changes .. address-family ipv6 neighbor 100.46.46.1 activate neighbor 100.46.46.1 send-label network 2001:6FC:0:0:1::1/128

Quality of Service Design

493

Example 13-20 IGW Configuration Example (Continued) ! neighbor 100.47.47.1 activate neighbor 100.47.47.1 send-label network 2001:6FC:0:0:1::1/128

Carrier’s Carrier Service Design This service provides VPN access to a customer service provider, so this service needs to exchange routes and send traffic over the EuropCom MPLS backbone. The only difference from a regular PE is that it provides MPLS-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 between CsC-CE and CsC-PE is performed over link-locals, using the previously defined address format. Example 13-21 illustrates the CsC-6VPE to CsC-CE peering, between EuropCom and yyCom, using IPv6 CsC. Example 13-21 CsC 6VPE Configuration Example hostname Paris-CSC-PE !PE#77 .. router bgp 33751 .. address-family ipv6 vrf yyCom neighbor FE80::866C:99%Serial0/0 neighbor FE80::866C:99%Serial0/0 neighbor FE80::866C:99%Serial0/0 neighbor FE80::866C:99%Serial0/0

remote-as 34412 activate send-label maximum-prefix 500

For CsC-6PE, the main difference is the lack of VRFs configured, and the fact that MP-BGP peering is using address family IPv6 with label, as illustrated in Example 13-22. Example 13-22 CsC 6PE Configuration Example router bgp 33751 .. neighbor FE80::916C:100%Serial1/0 remote-as 37228 address-family ipv6 neighbor FE80::916C:100%Serial1/0 activate neighbor FE80::916C:100%Serial1/0 send-label neighbor FE80::916C:100%Serial1/0 maximum-prefix 500

Quality of Service Design The QoS provided by EuropCom to its IPv4 enterprise customers is a key feature of its service marketing. The demand for guaranteed levels of service has risen because most EuropCom VPN customers have migrated their mission-critical applications, including

494

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

voice and video, over IP/MPLS. A primary constraint of EuropCom IPv6 deployment is to prevent any impact on IPv4 QoS. At the same time, many IPv6 applications are IPv4 applications migrating to IPv6 (critical data, voice, and video). EuropCom customers expect 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-based processing of IPv4 traffic

•

Impact of IPv6 QoS configuration on the network edge layer, its interaction with IPv4 QoS

•

Operation costs introduced by IPv6 QoS

The EuropCom MPLS backbone is overengineered and can accommodate the IPv4 as well as the additional IPv6 traffic. IPv6 traffic growth forecasts for the next two to three years justify maintaining the current core design for two major reasons:

•

IPv6 adoption by EuropCom enterprise customers is expected to be slow in the next few years, and most of the early adopters will run trials with limited number of end users long before they will engage in full-scale deployments.

•

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 a slow pace. Besides a small overhead (IPv6 header is 20 extra bytes), the IPv6 traffic growth due to such applications should therefore have a limited impact on core links utilization.

Overengineering the backbone has saved EuropCom from implementing differentiated services (DiffServ) in the core network. For this reason, it does not care about mixed classes received from customer CEs and has not configured any QoS mechanism at the ingress PE. For IPv6, the same strategy applies, and no QoS mechanism/configuration needs to take place on the ingress interfaces. Note that EuropCom customers can configure QoS 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 in the 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, the customer-CE can police IPv6 traffic without any configuration change. Example 13-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

Quality of Service Design

495

Example 13-23 QoS Configuration of CE Router Nice-CE-Cisco (Continued) ! .. 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 configuration is unchanged when IPv6 is activated.

•

The customer CE classifies traffic, polices it, and marks the Precedence field for PE-CE DiffServ on the remote EuropCom edge. Classification on the CE can get very complicated, and involves deep packet inspection. In simple cases, the source/ destination addresses and ports are used to distinguish between real-time, high-priority, and Best Effort traffic. Examples of classification and DSCP marking are provided in Chapter 5, “Implementing QoS.”

On the egress side, some EuropCom customers have requested DiffServ to be activated on the PE-CE interfaces. Because QoS is not activated at the ingress or in the core, the Precedence field set in packets received from the customer network is carried transparently up 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-8 on the PE-CE interface. Table 13-8

NOTE

Precedence-to-PHB Mapping Precedence Value

PHB

Type of Traffic

0,1,2,3

BE

Best Effort traffic

4,6,7

AF41

High-priority traffic

5

EF

Real-time traffic

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 the Selective Packet Discard (SPD) mechanism. IPv6 control traffic must also be marked with precedence 6, to avoid being dropped by SPD under congestion conditions.

When enabling VPNv6 on the egress PE, no change is expected in the QoS configuration. Example 13-24 illustrates Nice-PE-VPN QoS configuration.

496

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

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 7 class-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 is controlled by customer precedence set at the ingress CE (or application). The customer can decide to use the same classification policy for IPv4 and IPv6.

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), and transport. It sees IPv6 as a new service deployment rather than a replacement for IPv4. Therefore, it will be managed as a service (service monitoring, IPv6 traffic management, and so on), although the network itself will still be managed with the current IPv4 tools. Configuration management and topology management, 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 dual stack, and none will be IPv6 only.

• • • •

The core routers are IPv4 only.

•

The IPv6 RRs have no IPv6-enabled interface, and no IPv6 addresses configured.

The ASBRs are IPv4 only. The IPv4 RRs are IPv4 only. Many edge routers, especially in L3 POPs, are IPv4 only, and will remain that way until the first customer using such POP requests an IPv6 access.

Operating and Troubleshooting the Network

497

Service and Traffic Monitoring All the IPv6 services management will be performed over MPLS 6PE (all the IPv6 enabled devices have 6PE connectivity). Service availability will be monitored using Nagios (IPv6 ping) and IPv6 traffic management using Cisco Network Analysis Module (NAM). See Chapter 10, “IPv6 Network Management,” 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 (see Chapter 12, “Generic Deployment Planning Guidelines,” for details on deployment planning), as illustrated in Table 13-9. The prefix allocated to EuropCom is 2001:6FC::/32. The EuropCom addressing plan is in full compliance with RFC2373. Table 13-9

EuropCom Addressing Plan Descriptor

Description

network:ID:

NET-EUROPCOM

network:Network-Name:

EUROPCOM

network:IP-Network:

2001:6FC::/32

network:Org-Name:

EuropCom

network:Street-Address:

1701 Nice street

network:City:

London

network:State:

UK

network:Postal-Code:

17203

network:Country-Code:

44

network:Tech-Contact:

[email protected]

network:Updates:

20050505

network:Updated-By:

[email protected]

network:Class-Name:network:

network

EuropCom will keep 2001:6FC::/48 to use for its own infrastructure. It will assign up to /48 to large enterprise customers, and up to /56 to small business customers, out of its 2001:6FC::/32 block. Residential customers will each get a /64 prefix. Note that there is no fundamental difference whether the customers are VPN customers 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 abc identifies the customer. Small enterprise customers will get 2001:6FC:2abc:defg::/56, where abc:defg identifies the customer (defg > 0).

498

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

EuropCom does not intend to “enforce” a routing policy that would require a customer to follow the preceding rule, other than making sure VPNv6 customers will not advertise more than a certain number of prefixes per PE.

Link-Local Addresses On PE-CE interfaces, EuropCom will use link-local addresses for peering with the CE, in the form FE80::83D7:ID, where 83D7 is EuropCom ASN (33751) in hexadecimal format and the ID is a 16-bit numeric value, starting at 1, reusable from link to link, and from PE to PE. Note that because most PE-CE links 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 and management (could not ping the interface from remote devices, for instance), and for any router application required to locally generate packets (including ICMPv6, Telnet, and so on), each side should assign a global address on the PE-CE interface, from its own prefix. Typically, EuropCom customers will choose a small block (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 should be 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 and 6VPE (in each vrf). These global addresses will be advertised to all EuropCom 6PEs, but will never cross the autonomous system boundaries.

Using Unique-Local Addresses EuropCom is not really concerned about unique-local addresses, which could be used for intra-site or inter-site communication. Because unique-local addresses are not publicly routable, a customer using unique-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, while treating them as regular global addresses when exchanged between sites of a VPN. In practice, 6PE routers will have the configuration shown in Example 13-25. Example 13-25 Filtering Unique Local Addresses router bgp neighbor a.b.c.d remote-as neighbor a.b.c.d update-source Loopback0 ! address-family ipv6

Operating and Troubleshooting the Network

499

Example 13-25 Filtering Unique Local Addresses (Continued) neighbor a.b.c.d activate neighbor a.b.c.d send-label neighbor prefix-list Unique-Local out ! .. ipv6 prefix-list Unique-Local seq 10 permit 2001:6FC::/32 le 56

The preceding prefix list will prevent unique-local or anything else outside the EuropCom prefix range to be advertised to the IGW. The leaking of addresses from a VPN site to the Internet is closely controlled by EuropCom, so no prefix list is required on 6VPE routers.

Inter-Provider Communications For connecting IX and POPs together, EuropCom is using IPv4, and therefore does not have to create a specific 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 not use 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 more specific than /35 (other than within its own 2001:6FC::/32 range) spreading over its core routing tables. In order for such multihoming configuration to be enabled, it will take case-by-case negotiations between EuropCom, an EuropCom customer and the other provider. Whenever possible, EuropCom will rather implement a multihoming solution based on RFC2260 and RFC3178, and establish a tunnel between the Customer Edge router and the Provider Edge router facing this customer, via the secondary service provider.

•

Connected to two EuropCom PEs. In that case, EuropCom will assign 2001:6FC:1abc::/ 48, and the CE will advertise back chunks of it (2001:6FC:1abc:WXYZ::/s) to each CE, where WXYZ is a multihomed 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 smaller chunks to each site, (2001:6FC:1abcd:WXYZ::/s), like in the multihomed case.

500

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

MTU Discovery Initially, no backbone routers will be upgraded to software images that can send ICMPv6 messages. So P-routers cannot send “packet-too-big” ICMPv6 messages back to the source. Unlike IPv4, transit routers cannot fragment IPv6 packets with a size that does not fit the outgoing link MTU. If MTU design is not tuned up 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 to core interfaces, consistent with the core MTU. That way, packets can be fragmented at the edge of the network 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) as VPNv4. The difference is that instead of fragmenting IPv6 packets, the edge routers (6PE and 6VPE) will send 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 be smaller than the one configured in the core. In this case, the PE will send back an ICMPv6 too-big message over the MPLS core.

Security An important aspect of the IPv6 deployment planning and design is that of assessing the security risks it would introduce in EuropCom network. The analysis was performed based on the guidelines mentioned in Chapter 9, “Securing IPv6 Networks,” and it was decided that as a general rule, all IPv4 security policies will be matched for IPv6. At the same time, EuropCom had to consider several IPv6- and 6PE-specific security policies.

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 filters defined 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 prevents spoofing attacks sourced by EuropCom customers.

EuropCom interfaces directly with only a subset of its customers. In these cases, it considers implementing protective measures for its routers against floods of control message such as Router Solicitations, Neighbor Solicitation, and MLD traffic. Example 13-26 shows how an interface is configured to police all Neighbor Solicitation and “All Routers” messages.

Operating and Troubleshooting the Network

501

Example 13-26 Configuring Control-Plane Protection ipv6 access-list DOS-acl permit icmp any any nd-ns permit ipv6 any host FF02::2 class-map match-all DOS-class match access-group name DOS-acl policy-map prevent-attack class DOS-class police 70000 1500 1500 conform-action transmit exceed-action drop ! interface GigabitEthernet1/1 service-policy input prevent-attack

When implementing the policies shown in Example 13-26, consideration should be given to their impact on the router operation. They should be implemented on a large scale only on interfaces that support the functionality 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 it to attacks. A few security measures have to be enforced to protect the MPLS because of the 6PE/VPNv6 overlay:

•

The global addresses of the loopback interfaces should not be advertised outside the EuropCom network because they can allow attackers to target a PE router over IPv6 and in the process impact the IPv4 services supported by that PE. Traffic destined for these management prefixes can be easily blocked because, based on EuropCom addressing plan, they all belong to the prefix range 2001: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 traffic has to be particularly blocked at EuropCom border. As it was seen in the traceroute example of a previous section, in this case the path would reveal the IPv4 addresses of the P-routers. This information can be used to attack the network core over IPv4.

•

ACLs can be implemented on PE routers to protect bandwidth, buffer, and processing resources in case 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 be used for EuropCom CE routers as well, is the control-plane protection. If the policy prevent-attack in Example 13-26 is modified to include all ICMP traffic, it could be used to protect the router resources used for control purposes. control-plane service-policy input prevent-attack

Most network elements that support EuropCom IPv6 service are dual stack. The IPv4 side of these routers is already secured based on the best practices recommendations.

502

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

Troubleshooting Being able to easily troubleshoot network anomalies with regard to the new deployed service is a key element of 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 their learning curve. In fact, very few of the tools and commands used to troubleshoot 6PE and 6VPE are specific to IPv6. In the vast majority of the cases, the troubleshooting methodology is the same for IPv4 and IPv6, and the commands and tools vary by one keyword.

Routing The deployed solution (6PE/6PE) involves principally BGP, which EuropCom has been already operating for IPv4 services. The same set of commands EuropCom is already familiar with can be used (with different set of 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 summary For address family: IPv6 Unicast BGP router identifier 100.26.26.1, local AS number 33751 BGP table version is 15, main routing table version 15 12 network entries using 1692 bytes of memory 22 path entries using 1672 bytes of memory 5/4 BGP path/bestpath attribute entries using 580 bytes of memory 14 BGP rrinfo entries using 336 bytes of memory 2 BGP AS-PATH entries using 48 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 4328 total bytes of memory Dampening enabled. 0 history paths, 0 dampened paths BGP activity 13/1 prefixes, 23/1 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 100.46.46.1 4 33751 991 983 15 0 0 16:26:21 10 100.47.47.1 4 33751 991 983 15 0 0 16:26:22 10 FE80::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 unicast BGP table version is 15, local router ID is 100.26.26.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin 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 ..

Operating and Troubleshooting the Network

503

IPv6 routing tables can be displayed, to identify each routing protocol contributor to routable entries, as shown in Example 13-29. Example 13-29 Dumping IPv6 Routing Table Nice-PE-IA#show ipv6 route IPv6 Routing Table - default - 13 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, 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 2 B 2001:500::/48 [200/0] via 100.1.1.1%Default-IP-Routing-Table, indirectly connected B 2001:6FC::1/128 [200/0] via 100.1.1.1%Default-IP-Routing-Table, c LC 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 traceroute ipv6 are used to validate data-plane connectivity and detect traffic black-holing. Commands such as traceroute mpls 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 the recursive 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 a resolution breakage.

PE-CE Connectivity The IPv6 ping and traceroute are useful to check connectivity from a PE to a CE, whether locally attached, or remote over the MPLS backbone. When locally attached, EuropCom uses IPv6 ping with the CE link-local address (used for eBGP peering), as illustrated here (pinging Nice-CE): Nice-PE-IA#ping FE80::4F6B:44%Serial1/0 Type 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

504

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

The same command can be used to test remote PE or CE reachability, but only IPv6 global addresses can be used (link-locals are not advertised beyond the link): London-PE-IA# ping 2001:6FC:1120:1::44 Type 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 CE configures 2001:6FC:prefix:CE#/128 and announces it as part as their less-specific prefix (2001:6FC:prefix::/n). Reachability of remote PEs and CEs can be tested by using traceroute. EuropCom has configured all its PEs with no mpls ip propagate-ttl forwarded, so when traceroute is executed from a CE, it will only show the IPv6 nodes: Nice-CE#traceroute 2001:6FC::1 Type escape sequence to abort. Tracing the route to 2001:6FC::1 1 2001:6FC::26 [AS 33751] 32 msec 32 msec 20 msec 2 2001:6FC::1 [AS 33751] [MPLS: Label 73 Exp 0] 20 msec 20 msec 20 msec 3 2001:6FC::1 [AS 33751] 28 msec 20 msec 20 msec

After the P-routers have been upgraded with images that support ICMPv6, the same command executed on the PE router (TTL is then propagated) will also show P-routers responses, as illustrated here: Nice-PE-IA#traceroute 2001:6FC::1 Type escape sequence to abort. Tracing the route to 2001:6FC::1 1 ::FFFF:172.20.25.1 [MPLS: Labels 38/73 Exp 0] 40 msec 32 msec 32 msec 2 ::FFFF:172.20.10.1 [MPLS: Labels 30/73 Exp 0] 60 msec 32 msec 32 msec 3 2001:6FC::1 [MPLS: Label 73 Exp 0] 32 msec 32 msec 16 msec

When run from a 6VPE router, both ping and traceroute commands accept a vrf argument, exactly as in the case of VPNv4. Note that the traceroute command is useful for evaluating the path across the MPLS backbone, but not for troubleshooting data-plane failures. The P-routers are IPv6 unaware (like they are VPNv4 unaware), so the ICMPv6 messages that they generate in response to the traceroute command are forwarded to the egress PE using the received label stack. It is the egress PE that can route the ICMPv6 message to the source of the traceroute. When the MPLS path is broken, it is also broken from the ICMP message, which cannot reach the egress 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 start from is the Cisco Express Forwarding (CEF) show ipv6 cef command. You can either display the forwarding table with label stacks used for each destination prefix, as shown in Example 13-30, or display details for a specific entry, to analyze how the destination was resolved and the label stack computed, as shown in Example 13-31.

Operating and Troubleshooting the Network

505

Example 13-30 Dumping IPv6 Forwarding Table Nice-PE-IA# show ipv6 cef 2001:500::/48 nexthop 172.20.25.1 Serial0/0 label 38 72 2001:6FC::1/128 nexthop 172.20.25.1 Serial0/0 label 38 73 2001:6FC::26/128 attached to Loopback0, receive ..

Example 13-31 Details on an IPv6 Entry in the Forwarding Table Nice-PE-IA# show ipv6 cef 2001:500::/48 internal 2001:500::/48, epoch 0, RIB[B], refcount 4 sources: RIB .. recursive via 100.1.1.1[IPv4:Default] label 72, fib 0252B1F8, 1 terminal fib 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 be tracked 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::/48 BGP routing table entry for 2001:500::/48, version 2 Paths: (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/72 LDP (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 remote binding: lsr: 100.19.19.1:0, label: 38 Nice-PE-IA#show mpls ldp bindings 172.20.25.0 24 lib entry: 172.20.25.0/24, rev 2 local binding: label: imp-null remote binding: lsr: 100.19.19.1:0, label: imp-null

506

Chapter 13: Deploying IPv6 in an MPLS Service Provider Network

PE Disposition Path The disposition path can be looked at and troubleshot by displaying the MPLS forwarding table. Example 13-33 illustrates the output at Milan-IGW. Example 13-33 Dumping the MPLS Forwarding Table Milan-IGW#show mpls forwarding-table Local Outgoing Prefix Label Label or VC or Tunnel Id 16 Pop Label 100.14.14.1/32 17 26 100.46.46.1/32 .. 72 No Label 2001:500::/48 73 Aggregate 2001:6FC::1/128

Bytes Label Switched 0 0

Outgoing interface Se0/0 Se0/0

Next Hop

63121 24123

Se1/0

point2point

point2point point2point

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::/48 BGP routing table entry for 2001:500::/48, version 2 Paths: (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 to troubleshoot LSPs are more than ever useful to detect data-plane failures that would lead to IPv6 traffic black-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/128 Routing 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

Design Lessons

507

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 verbose Tracing MPLS Label Switched Path to 100.1.1.1/32, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request 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 6 R 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 commands can prove useful, although the number of messages (factor of the activity on the wire) can annihilate the usability of such tool (debug ipv6 cef, debug mpls packet, debug ipv6 packet for the forwarding path; debug bgp 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 a low-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) will benefit IPv6, too.

•

Link-local peering for eBGP PE-CE session is a useful and safe approach that simplifies the addressing plan—even though it does not save the need to configure at least one global address in each box 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 IPv6 RRs 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 not differentiate between IPv4 and IPv6. QoS MQC commands such as match precedence are useful because they apply to both protocols.

•

A consistent MTU configuration that pushes PMTU management responsibility to the edges is a must for IPv6 deployment, unless P-routers are ICMPv6 capable.

CHAPTER

14

Deploying IPv6 in an IP Service Provider Network This chapter continues the series of case studies by presenting the design of the IPv6 services and their deployment for an IP wholesale access provider. Unlike the example in Chapter 13, “Deploying IPv6 in an MPLS Service Provider Network,” the provider network in this case does not deploy MPLS in support of its IPv4 services. The IPv6 deployment strategy matches the IP forwarding-based design of the network. This case study covers all aspects of rolling out and operating IPv6-based services, including the following:

• • •

Existent IPv4 network environment and IPv4 services overview

• • •

Design and implementation of basic IPv6 unicast transport services

Review of planned IPv6 service offering IPv6 deployment design objectives, design options, and the reasons for the final design selections 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 in the United States. It started by providing access services to its residential and business customers over dialup and ISDN. Today, most of its customers are provided broadband access over 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’s network design. Its backbone is structured in three levels of points of presence (POPs) (Figure 14-1). Level 1 (L1) POPs form the backbone of the network. They service large metropolitan areas and they provide the interface to various ISPs. Originally the L1 POPs were not interconnected and RTPCom’s network was not contiguous. As its footprint and customer base grew, RTPCom could justify owning the OC-192 lines that currently connect its L1 POPs.

510

Chapter 14: Deploying IPv6 in an IP Service Provider Network

The L1 POPs connect to L2 (L2) POPs over OC-192 or OC-48 links depending on the size of the L2 POP. The later provide access services in areas of the metropolitan domain serviced by the L1 POP or in other smaller cities. L2 POPs aggregate L3 (L3) POPs over OC-48 or OC-3 links. Figure 14-2 presents RTPCom’s network in geographical context. Figure 14-1 RTPCom POP Architecture

Level-2 POP Level-3 POP

Level-1 POP RTPCom Core

Aggregation/Edge

Access

Figure 14-2 RTPCom Network—Geographical Topology Seattle

New York

Chicago

Denver San Francisco

Atlanta

Houston

Miami

Network Environment and IPv4 Services

511

The link and media types used to interconnect RTPCom’s POPs are summarized in Table 14-1. Table 14-1

Backbone Interface Types Interface Type

Speed

Use

OC-192/10Gig

10 Gbps

L1-L1 and L1-L2 POPs

OC-48 POS

2.5 Gbps

L1-L2 and L2-L3 POPs

OC-3 POS

155 Mbps

L2-L3 POPs

Gigabit Ethernet

1 Gbps

L1-L3 and L2-L3 POPs

The design of each POP type is emphasizing the need for aggregation and redundancy. The differences revolve 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 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 the customers. The de-encapsulated traffic is then handed over to the ISP selected by those customers. Each LNS router supports the customers of a single ISP and it connects over dedicated VLANs to two edge routers that provide 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 the PPP sessions are maintained by the corresponding ISP and are not shown in this figure. All routers in the L1 POPs belong to OSPF area 0. The L1 POPs peer via iBGP with the L2 POPs. A dedicated IGP is used between the LNS and the edge routers to implement layer 3 redundancy and load balancing. 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 be used by themselves in smaller markets. They rely on OC-48 Dynamic Packet Transport (DPT) rings to aggregate the access layer across the covered area or L3 POPs. The same design would have applied to a Resilient Packet Ring (RPR, 802.17) infrastructure, too. Figure 14-4 presents the structure of an L2 POP.

512

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Figure 14-3 Level 1 POP Design and Backbone Topology L1-POP-Seattle

L1-POP-New York

L1-POP-Chicago

L1-POP-Denver

OSPF–Area 0

L1-POP-Atlanta

L1-POP-Miami L1-POP-San Francisco

Core Router

Core Router

Aggregation Routers

iBGP

LNS

ISP

OC-192/10Gig

L2 POPs

L2 POPs

L1-POP-Houston

OC-48

L2 POPs peer via interior Border Gateway Protocol (iBGP) with the L1 POPs. They run OSPF with the ring in area 0 and each aggregated location, a local access layer or L3 POPs, connecting to the ring in an area of its own as shown in Figure 14-4. The last building block in RTPCom’s network design presented here is the L3 POP. It services small markets or remote locations. It is basically made of the access layer and an aggregation layer that provides connectivity to L2 POPs (Figure 14-5).

Network Environment and IPv4 Services

Figure 14-4 Level 2 POP Design L1 POP

L1 POP

iBGP

iBGP

OSPF–Area 1

OSPF–Area 3

L3 POPs

Access Layer

OSPF–Area 0 L3 POPs

OSPF–Area 2

Access Layer

L2-POP OC-192/10Gig

OC-48

Figure 14-5 Level 3 POP Design L2 POP

L2 POP

OSPF–Area x

Access Layer L3 - POP 1Gig

OC-48/OC-3

513

514

Chapter 14: Deploying IPv6 in an IP Service Provider Network

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 main characteristic is scalability needed to handle a large number of customers (Figure 14-6). Figure 14-6 RTPCom Access Layer LNS

ISP

L2-POP

PPPoE

L2TP

L1-POP

L3-POP

Access Layer

LAC

FTTH

ADSL

WiFi

CPE CPE

In terms of physical and link layers, RTPCom owns the entire last-mile infrastructure for all access types it offers: ADSL, FTTH, and WiFi.

IPv6 Deployment Plans

NOTE

515

RTPCom does not offer any services over cable. If it were to offer services, extending IPv6 access over such an infrastructure would complicate the deployment. As mentioned in Chapter 3, “Delivering IPv6 Unicast Services,” the cable specification (DOCSIS) does not support IPv6, so tunneling is the only mechanism available for transporting the IPv6 traffic. RTPCom is currently evaluating WiMAX as an access technology but no service is yet provided as this would require a license subscription.

For the IPv4 service, RTPCom aggregates the customer-initiated PPP over Ethernet (PPPoE) sessions and bundles them through Layer 2 Tunneling Protocol (L2TP) tunnels to the edge of its network. LNS routers in L1 POPs terminate the PPPoE sessions, de-encapsulate the traffic, and forward it to ISPs. The operation of this service is also exemplified in Figure 14-6. Through this wholesale model, RTPCom is not responsible for managing the global IPv4 addresses used by these customers, because they are managed by their ISP. RTPCom only provides transport for the 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 also aggressively developing its small office/home office (SOHO) customer base. RTPCom would like to expand its service offering into the Triple Play (data, voice, video) arena. Although the wholesale model used for the IPv4 unicast-based services can easily support Voice over IP (VoIP), it does not support in a scalable manner content delivery (CD)-based on multicast. All RTPCom’s customers have a virtual point-to-point link to their gateway (LNS) across a large portion of the network (L3, L2, and nearest L1 POP). Because the LNS is the only device that can do traffic replication for all the end users, RTPCom’s network is flooded with multiple replicas of the same packets for each customer subscribed to a given content channel. This inefficient use of network 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 nextgeneration infrastructure that would allow the company to increase its customer reach, and most important, to diversify its service offering. In particular, RTPCom intends to increase its revenue from existent broadband subscribers by providing an infrastructure

516

Chapter 14: Deploying IPv6 in an IP Service Provider Network

for value add services such as CD. Its expansion plans in this sense are limited by the scalability problems faced with enabling multicast in its current network. The potential to leverage IPv6 services as service differentiator in a competitive market did not escape RTPCom’s planning. Nevertheless, RTPCom sees IPv6 as an enabler, as well as an opportunity to reinvent its own infrastructure.

Targeted IPv6 Services Despite deciding to expand its service portfolio, RTPCom does not intend to significantly change 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 the service providers. Table 14-2 summarizes the services RTPCom customers will be able to receive over IPv4 and IPv6. Table 14-2

IP Services Available to RTPCom’s Customers Service Name

IPv4 Service

IPv6 Service

Internet access

Yes

Yes

DNS service

Yes

Yes

Mail service

Yes

Yes

Multicast-based CD

No

Yes

Content hosting/storage

No

Yes

VoIP

Yes

Yes

Mobile IP

No

Yes

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 are handled 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, therefore the 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

IPv6 Deployment Plans

517

can communicate with any other RTPCom subscriber without going through the ISP. In fact, in the trial phase of the service offering, the subscribers will not be able to access the IPv6 Internet. The emphasis is placed on peer-to-peer communication and services such as VoIPv6.

Internet Access In a second phase of the deployment, IPv6 subscribers are offered Internet access services. The subscription is similar 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 of limited 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 to communicate 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 servers are upgraded to dual stack and they can be reached via both IPv4 and IPv6. The AAAA records are added to all servers.

Mail Services The IPv6 ISP provides e-mail services similar to the ones offered to IPv4 users. Dual-stack servers are installed that share the disk resources used for the IPv4 e-mail services. This makes the e-mail services accessible over IPv4 or IPv6.

Content Hosting/Storage Content hosting and content storing is also a service offered and managed by RTPCom. These services are viewed as initial incentives to its customers to try IPv6 service. They are also viewed as a means to develop the internal (RTPCom subscribers) community of users. This service is completely new to RTPCom, so further 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.

Voice over IP Another new service for RTPCom is VoIPv6, which is viewed as an experiment. The intent is to stimulate customer interest and adoption through features, such as video telephony,

518

Chapter 14: Deploying IPv6 in an IP Service Provider Network

even though there are no service providers that expressed interest in offering the service. For this reason, RTPCom is providing exclusively on-net to on-net calls between its subscribers. The service will be expanded to provide off-net calls only through partner service providers. The business potential of a VoIP service is well understood by RTPCom’s management. A aggressive plan to deploy the service over IPv4 is being developed. Despite being well proven in recent years, VoIP is a new endeavor for RTPCom. For this reason, the VoIPv6 service is seen as a precursor of the larger-scale service rollout 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 of service provided and in particularly in support of VoIPv6, RTPCom will have to implement QoS to meet current and future service level agreement (SLA) requirements.

Content Delivery—Multicast CD promises to be a profitable service. The large bandwidths already available with broadband access make it possible to deliver video and audio streams to residential subscribers in parallel with Internet access. Service adoption can in turn increase demand for bandwidth, which results in an increase in business for access providers such as RTPCom. Video and audio content can be delivered on demand or on scheduled basis. On-demand services rely on unicast transport and therefore are less scalable and more expensive. On the other hand, scheduled programs can be delivered with the help of multicast in a scalable manner. Each program is a multicast stream corresponding to one or multiple (S,G). The programs can be received on PCs or set-top boxes provided by the access provider or the service provider. Subscribers can join the ongoing program and they can be charged on a monthly subscription basis or on time spent as a listener for the various multicast streams. The business model 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 calls for allowing content providers (CPs) to offer various programming to its customers. The set-top boxes will be provided by RTPCom to allow its customers to switch easier between CPs. In the first phase, the accounting for the service would be done trough monthly subscriptions for program packages. The current wholesale design of the IPv4 infrastructure is not capable of supporting a large scale multicast service. This is one of the reasons why RTPCom accelerated the deployment of IPv6, because it enables it to role out the multicast-based services.

IPv6 Deployment Plans

519

Mobile IPv6—Communities of Interest The improvements made to mobility in IPv6 make the service better positioned for deployment. Chapter 8, “Advanced Services—IPv6 Mobility,” describes in detail the MIPv6 operation, support, and configuration on Cisco routers. While the protocol continues to evolve, service models are being developed to leverage this feature. RTPCom realistically assessed MIPv6 as a long-term opportunity, but it formed a task force that is charged with developing a market for this feature. After a thorough market research and participation in several seminars on the topic, RTPCom’s MIPv6 task force attempted its first service trial of a Cisco-proposed business model called community of interest. This concept, described in Chapter 8, applies differently to different types of businesses. In the case of a service provider, it basically refers to a group of mobile users that share a common interest. All these users have a home prefix that identifies them. They can move around the service provider network or even the IPv6 Internet if the service is available to that extent, and yet be virtually on the same network. These users can be simple mobile nodes or they can be mobile routers. They can share resources on the home prefix accessible only to them. Configuring such a service is not difficult; it requires nothing more than the information presented in Chapter 8. The concept clearly is powerful, so the only thing left is to define a service around it. The RTPCom MIPv6 task force decided to trial one particular service model that targets business customers in major metropolitan areas. Companies that operate within a metropolitan area and have mobile assets, such as a truck fleet or distribution representatives, need to provide its field people with order, pick-up, and delivery information. This information is not updated real time, but rather every 15 to 20 minutes. The necessary amount of information cannot 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 CI service. RTPCom installs and manages a router at the main offices of the customer. This router is enabled for MIPv6 (see Chapter 8). The laptops on each of the trucks and the laptops or handhelds of the sales force all bind to this home agent. When out in the field during the regular work day, all these mobile devices access RTPCom’s network through its WiFi access points (APs) that are spread throughout the city for RTPCom’s wireless service. They then connect to the home agent at the main offices and download the relevant data from information servers. The APs can be found at coffee shops, fast-food restaurants, or other public places, so coverage is not an issue. To summarize, the company used in the above example represents a “community of interest,” and it is using RTPCom’s infrastructure for its own communication needs. The main reason why RTPCom can lock the customers in is that this service is available

520

Chapter 14: Deploying IPv6 in an IP Service Provider Network

only when roaming its network and not a competitor’s. The mobile device can actually be a mobile router in the case of a truck containing multiple IP devices on different prefixes.

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 its network. 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 source of revenue in itself.

This trial has proven to be successful, so RTPCom is considering ways to expand it by identifying new customers, new “communities of interest.”

Design Goals Recognizing the benefits of offering multiple types of services such as voice, video, and data (Triple Play) to broadband subscribers, RTPCom decided to prepare its network to support such services in a scalable and high performance manner. It also sees IPv6 as a good opportunity to investigate and trial new network designs that would not see some of the shortcomings of its current PPP/L2TP-based model for the IPv4 Internet access service. In particular, one of the design goals is to support multicast-based services over IPv6. Nevertheless, RTPCom does not intend to build a separate infrastructure for IPv6 but rather to enable the existent one to support the new services in parallel with the existent IPv4 ones. This planned coexistence leads to an important 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 of IPv6.

•

The IPv6 services should be easy to enable across RTPCom’s entire network when a customer request is 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 multicastbased services in a scalable 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.

IPv6 Deployment Plans

521

It is expected that at first the IPv6 traffic will be minimal. RTPCom operates under the assumption that in the first one to two years the IPv6 traffic in the core of the network will not be larger than 20 percent of its total data traffic. On the other hand, at the access layer, it is expected that the IPv6 multicast will dramatically change the traffic profiles.

Design Options With the deployment targets and guidelines identified, RTPCom set off to investigate its options with respect to enabling IPv6 in its network. Based on the service provider deployment recommendations made by the IETF IPv6 Operations work group (see RFC 4029 and Internet Draft ISP IPv6 Deployment Scenarios in Broadband Access Networks), the guidelines found in documents such as the IPv6 Promotion Council of Japan (see http:// www.v6pc.jp/pdf/041007_v6trans_guideline.pdf) and deployment experiences recorded by 6NET project deliverables (see http://www.6net.org/), RTPCom ended up considering two service deployment options:

• •

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 of RTPCom’s IPv6 deployment. RTPCom does not intend to postpone infrastructure investments related to the IPv6 deployment at the expense of a less-scalable and lower-performance service. Training its operations staff on a temporary solution based on IPv6 tunneling mechanisms would also be a waste of capital. Native deployment is considered on a case-by-case basis as an option in some POPs where routers can be dedicated to support the IPv6 service exclusively. Routers replaced during regular network upgrades can be used to provide 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 would initiate IPv6 PPPoE sessions that are bridged by the access router into an L2TP tunnel that is set up between the access router and the LNS located in the data center of L1 POPs (see Figure 14-7). The PPP sessions are terminated 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 Chapter 3 of this book. The most important thing to notice is that with this approach, RTPCom has the option to use L2TP tunnels set up over IPv4; therefore, it could avoid the need to enable IPv6 in the core of its network.

522

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Figure 14-7 PPP/L2TP-Based Service Model

LNS

IPv6

ISP L1-POP

L2TP over IPv4

IPv4

L2-POP

L3-POP

Access Layer

LAC

CPE

PPPoE-IPv4 PPPoE-IPv6

IPv6

IPv4

IPv4

IPv6 Deployment Plans

523

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 in the same way as its IPv4 counterpart. RTPCom does not have to be concerned with customer IP provisioning 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 of the network that has to be made IPv6 aware is the access layer, the LNSs in the data center and the routers that interface with the service providers.

•

No major training required for the operations staff—This deployment model is sufficiently similar to the IPv4 ones and the IPv6 transport sufficiently encapsulated for the operations staff to manage it without 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 scalability problem 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 phased deployment 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 native forwarding. As expected, the impact of such an approach is significant because all routers in its network will have to be configured for IPv6. In this case, RTPCom is responsible for the IP provisioning of its customers and it will switch their traffic at layer 3 all the way to their service providers. The customer traffic is no longer characterless to RTPCom. Figure 14-8 presents the operation of the IPv4 and IPv6 services in this scenario. The advantages of this deployment option are as follows:

•

It positions RTPCom for the future IPv6 network structure—Despite the added management burden, the knowledge of the customer traffic and needs enables RTPCom to adapt to them and to new services while taking advantage of IPv6’s larger address space.

•

Enables RTPCom to deploy a scalable multicast service—By being aware of the customer traffic at IP layer, RTPCom can leverage the IPv6 multicast control plane for a more optimal distribution of the traffic. It can replicate the multicast traffic as close to the listeners as possible; therefore, it resolves the problems faced by the PPP/L2TP-based design.

•

It can deploy mobile services with MIPv6—In a network that relies on native forwarding throughout its footprint, the access provider can easily leverage the IPv6 implementation of the mobility services.

524

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Figure 14-8 Dual-Stack Service Model

LNS

ISP

IPv4

L1-POP

L2TP over IPv4

IPv6

L2-POP

L3-POP

Access Layer

CPE PPPoE-IPv4 IPv6

IPv6

IPv4

IPv4

Basic Services Design and Implementation

525

The disadvantages of this approach reflect its departure from the model used currently by RTPCom:

•

It might require the upgrade of some of the routers in the network—Through the scheduled network updates, most routers run software that supports the necessary IPv6 features. However, an inventory will 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-based approach, 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 responsible for user provisioning and additional management and security.

•

A more intensive training process is required for the operations staff—The personnel in charge of the upgraded 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 network for 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 to deploy a dual-stack IPv4-IPv6 network.

NOTE

Equipment-related costs for rolling out a dual-stack IPv6 service returned numbers lower than originally expected. This is particularly because most of RTPCom’s network elements already support the targeted IPv6 features. The deployment will be implemented in phases with service offered initially in large metropolitan areas and then expanded throughout RTPCom’s network. The largest expense of the IPv6 service rollout is that of training the operations team, provisioning the services and updating the network management procedures.

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 now shapes the design of all IPv6 services. The foundation of the deployment is the addressing plan.

526

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Addressing Plan RTPCom secured the 2600:A000::/24 prefix from the American Registry for Internet Numbers (ARIN) for its IPv6 nationwide deployment. It made a strong business case for 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. Table 14-3

RTPCom Address-Allocation Record network:ID:

NET-RTPCom

network:Network-Name:

RTPCOM

network:IP-Network:

2600:A000::/24

network:Org-Name:

RTPCom Corporation

network:Street-Address:

4704 Davis Drive

network:City:

Research Triangle Park

network:State:

NC

network:Postal-Code:

27709

network:Country-Code:

US

network:Tech-Contact:

[email protected]

network:Updates:

20050505

network:Updated-By:

[email protected]

network:Class-Name:network:

network

In designing the addressing structure of the IPv6 deployment and service, RTPCom decided to use the following 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 are reserved to identify each L1 POP in each area. Four bits are reserved to identify the L2 POPs, and the subsequent 6 bits are used to identify the L3 POPs. Table 14-4 summarizes the addressing scheme that will be implemented by RTPCom. Table 14-4

RTPCom Address Design Admin Significance

Bits

RTPCom

1–24

RTPCom–East

25

Count

Prefix 2600:A000::/24

1

2600:A000::/25

Basic Services Design and Implementation

Table 14-4

527

RTPCom Address Design (Continued) Admin Significance

Bits

Count

Prefix

25

1

2600:A080::/25

L1 POP ID East

26–28

8

2600:A010::/28–2600:A070::/28

L1 POP ID West

26–28

8

2600:A090::/28–2600:A0F0::/28

L2 POP ID East

29–32

16

2600:A01X::/32

L2 POP ID West

29–32

16

2600:A09X::/32

L3 POP ID East

33–38

64

2600:A01X:Yy00::/38

L3 POP ID West

33–38

64

2600:A09X:Yy00::/38

L3 POP Router ID East

39–44

64

2600:A01X:YyZ0::/44

L3 POP Router ID West

39–44

64

2600:A09X:YyZ0::/44

Customer Prefix East

45–56

4096

2600:A01X:YyZP:PP000::/56

Customer Prefix West

45–56

4096

2600:A09X:YyZP:PP000::/56

RTPCom–West

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

528

Chapter 14: Deploying IPv6 in an IP Service Provider Network

The first prefix in both East (2600:A000::/28) and West (2600:A080::/28) ranges was reserved for infrastructure purposes. The 2600:A000::/28 prefix is used in the manner described in Table 14-6. Table 14-6

RTPCom Infrastructure Addressing Scheme Use

Bits

Prefix

L1 POP Routers

29–32

2600:A00(L1):0000:XX00::/56

L2 POP Routers

33–36

2600:A00(L1):(L2)000:XX00::/56

L3 POP Routers

37–44

2600:A00(L1):(L2)(L3)(L3)0:XX00::/56

The 2600:A080::/28 is reserved for further growth needs. These prefixes will be protected against outside reach.

Unicast Connectivity Unicast connectivity between customers and between customers and the ISP provides the underlying service upon which all other services are built. As it was mentioned earlier, RTPCom decided to deploy IPv6 in dual-stack mode, unlike the PPP/L2TP-based model used for the IPv4 service. RTPCom will switch the customer IPv6 traffic at layer 3 throughout its network, 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 are identified based on the naming convention in Figure 14-9. RTPCom’s addressing scheme presented earlier provides the prefixes relevant to the routers identified in Figure 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)

Basic Services Design and Implementation

Figure 14-9 Example of Router-Naming Convention Within the New York L1 POP

NY-D-0-3

Data Center

3

ISP

L1-POP (New York) NY-D-0-2

NY-0-0-1 NY-10-0-1 1

2

L2-POP (10)

NY-10-12-1 1

2

L3-POP (12) 14

15

16 NY-10-12-16

529

530

Chapter 14: Deploying IPv6 in an IP Service Provider Network

These prefixes are used for service purposes, while the 2600:A002:A::/36 prefix range is used for infrastructure purposes. From a routing perspective, the IPv6 deployment matches the IPv4 for the most part. The same routing protocols are operating in the same areas of the network. There is, however, a significant difference in that the IPv4 infrastructure is not aware of prefixes outside of it. RTPCom provides virtual pipes between the ISPs and the customers over its self-contained infrastructure. RTPCom’s network is aware of the customer’s IPv6 traffic, so it will have to carry prefixes used for the services provided by the content or Internet service providers.

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 bridges the customer initiated PPPoE sessions into an L2TP tunnel, although for IPv6, the access router represents the layer 3 gateway for the customer. Implementing this hybrid access model is straight forward on the FTTH interfaces. On the ATM interfaces, the access router has to know to bridge the IPv4 traffic and to route the IPv6. 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 two mechanisms:

NOTE

•

For single-network customers, provide a /64 prefix through Router Advertisements. The user is instructed to obtain the other provisioning parameters via stateless DHCP (resources being provided by RTPCom). The stateful DHCPv6 option was not selected because it is not implemented in most host stacks.

•

Customers that manage multiple networks on their site through a CPE router are provided a /56 prefix via DHCP-PD based on the DUID of their CPE router (see Chapter 3). On the link between the access router and the CPE, no prefix is assigned.

RTPCom considered a PPP-based solution at the access layer where PPPoE sessions initiated by the customer would be terminated by the access router and the traffic IP switched through the rest of the network. The advantage of this approach is that it allows RTPCom to leverage PPP for authenticating and authorizing the customer with the help of a RADIUS server. This would simplify provisioning by centralizing it in the RADIUS server. RTPCom decided, however, to keep the deployment simple and avoid the additional encapsulation even if that might imply more involved provisioning.

Basic Services Design and Implementation

531

Router NY-10-12-16 in Figure 14-9 provides ADSL access and has the relevant configuration shown in Example 14-1.

Example 14-1 ADSL Access Router Configuration hostname NY-10-12-16 ! ipv6 unicast-routing ipv6 cef ipv6 dhcp pool DHCP-Customers prefix-delegation 2600:A02A:30F0:6400::/56 00030001000BBFAA7400 dns-server 2600:A002::1/64 domain-name RTPCom.com ! interface ATM1/0 no ip address load-interval 30 atm pvp 0 70000 atm pvp 1 70000 no atm ilmi-keepalive ! interface ATM1/0.10 point-to-point atm route-bridged ipv6 pvc 0/42 encapsulation aal5snap protocol pppoe ! ipv6 address 2600:A02A:30F0:A01::1/64 ipv6 enable ipv6 nd other-config-flag ! interface ATM1/0.100 point-to-point atm route-bridged ipv6 pvc 0/132 encapsulation aal5snap ! ipv6 dhcp server DHCP-Customers ipv6 enable ipv6 nd other-config-flag !

NOTE

The DUID of subscriber 100 CPE is 00030001000BBFAA7400 and 2600:A002::1/64 is the address of the DNS server in the New York L1 POP.

532

Chapter 14: Deploying IPv6 in an IP Service Provider Network

No routing protocol is running between the access router and the CPE while OSPFv3 is running between the L3 POP routers. The following three points have to be considered:

•

For the single-network customers, the assigned /64 prefix is directly connected, so directly connected prefixes have to be redistributed.

•

For the multiple-network customers, a static route is installed by the access router for each /56 prefix assigned. 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) to minimize 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 enable ipv6 ospf 100 area 10 ! interface GigabitEthernet6/2 no ip address ipv6 address 2600:A002:A0C0:F002::2/64 ipv6 enable ipv6 ospf 100 area 10 ! ipv6 router ospf 100 router-id 2.10.12.16 log-adjacency-changes summary-prefix 2600:A02A:30F0::/44 redistribute connected redistribute static

Interfaces GigabitEthernet6/1 and 6/2 link the access router NY-10-12-16 to the routers that connect this L3 POP 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 is NY-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 in that respective order.

•

The OSPFv3 prefixes should be redistributed into iBGP.

Basic Services Design and Implementation

533

• •

The iBGP prefixes should be redistributed into OSPFv3.

•

OSPFv3 should summarize the prefixes to the L2 POP boundary (2600:A02A::/32).

A loop avoidance mechanism should be implemented for the redistribution between OSPFv3 and iBGP because of the redundancy in the design.

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-routing ipv6 cef ! interface SRP1/1 no ip directed-broadcast ipv6 address 2600:A002:A000:1::1/64 ipv6 enable ipv6 ospf priority 3 ipv6 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 bgp log-neighbor-changes neighbor 2600:A002:A000:1100::1 remote-as 1600 neighbor 2600:A002:A000:1100::1 update-source TenGigabitEthernet9/1 neighbor 2600:A002:A000:1200::1 remote-as 1600 neighbor 2600:A002:A000:1200::1 update-source TenGigabitEthernet9/2 ! address-family ipv6 neighbor 2600:A002:A000:1100::1 activate neighbor 2600:A002:A000:1200::1 activate no synchronization redistribute ospf 100 match external 2 route-map OSPF-to-BGP exit-address-family ! ipv6 router ospf 100 router-id 2.10.0.1

continues

534

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Example 14-3 L2 POP Router NY-10-0-1 Configuration (Continued) log-adjacency-changes summary-prefix 2600:A02A::/32 redistribute bgp 1600 tag 1600 ! ! route-map OSPF-to-BGP deny 10 match tag 100 ! route-map OSPF-to-BGP permit 20 !

The TenGigabitEthernet9/1 and 9/2 interfaces provide the uplink to L1 POP, while the SRP1/1 interface provides 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 is redistributing 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 the IPv6 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 affect IPv6. 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 assumed for IPv4, as well). Based on its operational experience with the current infrastructure, RTPCom is comfortable with this design. It is also studying the option of deploying dedicated RRs in each L1 POP. Considering the redundancy in the RR design, a migration to this alternate design would not imply a downtime for RTPCom’s network. The L1 routers are running OSPFv3 in area 0 for IGP. At the same time, the L1 routers that provide access to the core for the L1 POP data centers and for the L2 POPs are all part of the iBGP infrastructure shown in Figure 14-10.

Basic Services Design and Implementation

535

Figure 14-10 RTPCom Backbone iBGP Design L1-POP-Seattle

L1-POP-New York

L1-POP-Chicago

Top-RR

Top-RR

L1-POP-Denver

L1-POP-Atlanta

OSPF–Area 0

Top-RR

Top-RR

L1-POP-San Francisco

L1-POP-Miami Core Router

RR

Core Router

RR

iBGP

RR

iBGP

Aggregation Routers L2 POPs

iBGP

iBGP

L2 POPs

L1-POP-Houston

ISP eBGP

RR

eBGP

eBGP

The L1 routers providing access for the L1 POP data centers and for the L2 POPs are also acting as route reflectors for the IPv6 service. They in turn peer with the two pairs of second-level Top-RRs in L1-Denver and L1-Atlanta. This hierarchical RR design provides scalability for RTPCom’s network core. The prefixes in the 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.

536

Chapter 14: Deploying IPv6 in an IP Service Provider Network

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 bgp router-id 2.10.0.1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 2600:A002:A000:1100::2 remote-as 1600 neighbor 2600:A002:A000:1100::2 update-source TenGigabitEthernet9/1 neighbor 2600:A002:A000:1200::2 remote-as 1600 neighbor 2600:A002:A000:1200::2 update-source TenGigabitEthernet9/2 neighbor 2600:A001:0:F000::2 remote-as 1600 neighbor 2600:A001:0:F000::2 update-source Loopback0 neighbor 2600:A00A:0:F000::2 remote-as 1600 neighbor 2600:A00A:0:F000::2 update-source Loopback0 ! address-family ipv6 neighbor 2600:A002:A000:1100::2 activate neighbor 2600:A002:A000:1100::2 route-reflector-client neighbor 2600:A002:A000:1200::2 activate neighbor 2600:A002:A000:1200::2 route-reflector-client neighbor 2600:A001:0:F000::2 activate neighbor 2600:A00A:0:F000::2 activate no synchronization redistribute 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-Denver and L1-Atlanta POPs in addition to the existent IPv4 RRs. RTPCom considers the investment in the additional equipment worthwhile for the benefit of further minimizing the interaction between the IPv4 and IPv6 services. With the above configuration in place, RTPCom established unicast connectivity between its customers and some 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 based on its subscription. With the basic IPv6 unicast service, the user can reach other RTPCom customers but should not

Basic Services Design and Implementation

537

have access to the Internet. To enforce this policy, RTPCom applies an IPv6 filter on the subscriber line at the access layer, as shown in Example 14-5. Example 14-5 User Access Control Configuration interface ATM1/0.10 point-to-point atm route-bridged ipv6 pvc 0/42 encapsulation aal5snap protocol pppoe ! ipv6 address 2600:A02A:30F0:A01::1/64 ipv6 enable ipv6 traffic-filter Basic-Access in ipv6 nd other-config-flag ! ipv6 access-list Basic-Access deny ipv6 any 2600:A000::/28 deny ipv6 any 2600:A080::/28 permit ipv6 any 2600:A000:/24

Access list Basic-Access blocks access to the infrastructure address space (2600:A000::/28 and 2600:A080::/28), and allows access to the other RTPCom customers but not beyond that. This filter is modified 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 access layer based on customer demands. RTPCom’s deployment will precede demand in the major metropolitan areas where the service will be aggressively advertised. The service rollout steps are summarized in Table 14-7. Table 14-7

Unicast Connectivity Service Rollout Checklist RTPCom Task 1

Customer Task

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. continues

538

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Table 14-7

Unicast Connectivity Service Rollout Checklist (Continued) RTPCom Task 2

Customer Task

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. Customer requests basicaccess 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 virtual circuit (PVC or VLAN).

The customer is provided with the prefixes that will be assigned to him. If a CPE is used, configure it as a DHCPPD client. This might be the responsibility of RTPCom if it manages the CPE.

Configure the service control ACL Basic-Access.

Steps 2 and 3 can be repeated for other L2 and L3 POPs based on customer demand for service. By the time the 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 unicast service enables the IPv6 customers to reach these resources and take advantage of these two services. The DNS server addresses are provided to users via DHCP. The addresses for the content hosting/storage servers are available on RTPCom’s service web pages where subscribers are provided with all the information necessary to use these services.

Basic Services Design and Implementation

539

Internet Access To provide its customer with Internet access service, RTPCom partnered with USInternet, an ISP similar to EuropCom described in Chapter 13. USInternet will provide IPv6 Internet access in addition to its existent IPv4 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 two routers collocated with RTPCom’s edge routers in the data centers of the L1 POPs. These two routers aggregate the LNS routers that are dedicated to USInternet. Open Shortest Path First (OSPF) is used for routing 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 global addresses and its autonomous system for the service. RTPCom can be viewed as merely a virtual access layer for the ISPs it partners with. In the IPv6 service design, RTPCom plays a more involved role. It now routes the customer traffic throughout its network, it is responsible for providing addresses to customers and have them globally routed under its own autonomous system number. In this case, the use of just and IGP is not feasible. For this reason USInternet peers with the RTPCom at its L1 POPs through eBGP and the following constraints shape the configuration of NY-D-0-3:

• •

RTPCom’s autonomous system number is 1600.

• •

Dampening is used to minimize external impact on RTPCom’s network.

It peers with USInternet and also with the routers that provide the data center with access to the core. 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 router bgp 1600 bgp router-id 2.0.255.1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 2600:A002:D0:1100::1 remote-as 1600 neighbor 2600:A002:D0:1100::1 update-source TenGigabitEthernet1/1 neighbor 2600:A002:D0:2100::1 remote-as 1600 neighbor 2600:A002:D0:2100::1 update-source TenGigabitEthernet1/2 neighbor FE80::200:FF:FE01:F remote-as 500 neighbor FE80::200:FF:FE01:F update-source GigabitEthernet2/1 ! address-family ipv6 neighbor 2600:A002:D0:1100::1 activate neighbor 2600:A002:D0:2100::1 activate neighbor FE80::200:FF:FE01:F activate neighbor FE80::200:FF:FE01:F route-map Block-Infra out

continues

540

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Example 14-6 IPv6 eBGP Configuration of Router NY-D-0-3 (Continued) bgp dampening 15 750 3000 60 no synchronization exit-address-family ! ipv6 prefix-list Infra seq 5 permit 2600:A000::/28 ipv6 prefix-list Infra seq 10 permit 2600:A080::/28 ! route-map Block-Infra deny 10 match ipv6 address prefix-list Infra ! route-map Block-Infra permit 20 !

The addresses of the data center RRs are 2600:A002:D0:1100::1 and 2600:A002: D0:2100::1. USInternet’s autonomous system number is 500. The eBGP peering is done through the link-local addresses on the link between RTPCom and the USInternet. Route map Block-Infra is used to stop the infrastructure prefixes 2600: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, “An IPv6 Refresher,” describes the benefits of using this option. The important thing is to have a set of rules that make the link-local addresses of the peer deterministic. The details of how the link-local addresses are being assigned 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 its customers 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 to his service subscription, the access list applied to its access line is changed from Basic-Access to Internet-Access: ipv6 access-list Internet-Access deny ipv6 any 2600:A000::/28 deny ipv6 any 2600:A080::/28 permit ipv6 any any

In the first phase of the IPv6 deployment, the services offered are contained within RTPCom’s network or within a data center on USInternet’s premises (e-mail services, for example). This way the services are easier to manage, and the corresponding business model is not complex. The Internet access service is turned on in a subsequent phase of the deployment when interest for it becomes relevant.

Advanced Services Design and Implementation

541

The Internet access service rollout steps are summarized in Table 14-8. Basic connectivity is assumed to add Internet access. Table 14-8

Internet Access Service Rollout Checklist RTPCom Task 1

Customer Task

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 now increase and refine its service offering. It can enable its network to support IPv6 multicast for content distribution and it can optimize its network to better support time-sensitive applications such as voice and video through QoS. Both of these technologies are new to RTPCom because neither has been used with its current IPv4 service. They will imply additional costs in terms of deployment, operation and training. The business models for the services they enable will most likely see further development and improvement. Nevertheless, RTPCom is committed to building a multi-service-capable network that supports near term opportunities such as Triple Play as well as longer-term ones that will be created by IPv6.

Content Distribution—IPv6 Multicast RTPCom considers CD as one of the most promising growth strategies. It will imply a one time, minimal charge for enabling its infrastructure to support multicast while being able to easily increase revenue per-access line thereafter. This revenue increase is developed in collaboration with the content provider by offering more video and music premium channel packages. RTPCom expects that the popularity of these services will lead to an increase in its customer base. This scheduled programming is offered through Video and Audio streams, each mapped to an (S,G) multicast group. The content will use various digital compression mechanisms that

542

Chapter 14: Deploying IPv6 in an IP Service Provider Network

have different bandwidth requirements. The applications deployed by RTPCom and its partner content providers will have the following characteristics (Table 14-9). Table 14-9

Bandwidth Requirements for Multimedia Streams Content Type

Encoding

Bandwidth

Video

MPEG4

1.5 Mbps

Video

MPEG2

2 Mbps (can be 1 Mbps to 15 Mbps)

Audio

20–200 Kbps

The bandwidth consumption is particularly relevant at the access line level. Users register to one or multiple multicast available groups based on their service subscription. The number of channels that can be accessed simultaneously does depend on the downstream bandwidth available on the access line. RTPCom will shape the customer traffic based on two profiles: basic and premium. The basic profile is part of the regular subscription, whereas the premium profile comes at an additional cost. These aspects of bandwidth management 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 will have to be adapted to bandwidth availability. Some DSL (IDSL, for example) services will not be able to support some or even all video streams.

IPv6 Multicast Service Design Three major elements are relevant to deploying this service:

• • •

Content management Content transport Customer interface

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 from dedicated servers that are located in RTPCom’s L1 POP data centers. This approach simplifies the multicast deployment because all the relevant elements, sources, and listeners are contained within this single domain.

Advanced Services Design and Implementation

543

RTPCom assigns to each content provider a set of multicast groups and a prefix for its servers. With this information the content provider puts together a programming mapping that it delivers to RTPCom. As an example, content provider X was assigned:

• •

2600:A00(L1):00DD:X000::/64 prefix for its servers in each L1 POP FF3E:X::1—FF3E:X::F multicast group addresses

Table 14-10 shows the way content provider X mapped its programs to the (S,G) groups.

NOTE

The group addresses used for the multicast service do not have to be globally unique because the service is contained within RTPCom’s domain. Source Specific Multicast (SSM) group addresses are used because of the deployment model selected (see the “Content Transport” subsection).

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 National 1–16 Premium 1 National Channels Premium 1.1–Premium 1.100 Premium 2 National Channels Premium 2.1–Premium 2.100 Premium 3 National Channels Premium 3.1–Premium 3.100 Local Channels Local Channel 1–100

Audio Programs

Basic National Channels National 1–16 Premium 1 National Channels

FF3E:X::1 2600:A002:00DD:X000::101–10F FF3E:X::2 2600:A002:00DD:X000::201–264 FF3E:X::3 2600:A002:00DD:X000::301–364 FF3E:X::4 2600:A002:00DD:X000::401–464 FF3E:X::5 2600:A002:00DD:X000::501–5C8 FF3E:X::A 2600:A002:00DD:X000::1001–100F FF3E:X::B continues

544

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Table 14-10 Programming to (S,G) Mapping for Content Provider X in the New York Area (Continued) Content Provider X Programming Profile Premium 1.1—Premium 1.100 Premium 2 National Channels Premium 2.1–Premium 2.100 Premium 3 National Channels Premium 3.1–Premium 3.100 Local Channels Local Channel 1–100

2600:A002:00DD:X000::2001–2064 FF3E:X::C 2600:A002:00DD:X000::3001–3064 FF3E:X::D 2600:A002:00DD:X000::4001–4064 FF3E:X::F 2600:A002:00DD:X000::5001–50C8

For redundancy purposes:

•

Local programs are multicasted simultaneously from two servers within the same L1 POP and with subsequent source addresses. For example, local program NewYork1 is available on the following multicast 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 connected to the same access router and interested in a given program will join a single (S,G). Otherwise the content stream would be duplicated, unnecessarily wasting bandwidth throughout the network. If the first source is not available, the second one is selected. When switching between the primary and the backup source, the subscriber will encounter some delay as the multicast tree is built and the traffic makes its way to the access layer. RTPCom decided to configure static joins for all (S,G) in every L2 POP. This way, the portion of the multicast tree left to be built when a user joins a channel is much smaller and so is the delay in receiving the traffic. This is 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 source addresses. For example, national program National1 is available at least on the following multicast groups: (2600:A001:00DD:X00::101, FF3E:X::1) and (2600:A002:00DD:X00::101, FF3E:X::1).

Advanced Services Design and Implementation

Note

545

RTPCom decided to install servers in each L1 POP for the national programs to avoid having significant multicast traffic crossing the backbone. The multicast traffic of these programs is not routed between L1 POPs. However, this is not a strict requirement; it represents an optimal way to use the network core resources.

Gigabit or 10 Gigabit Ethernet links are available between RTPCom’s data centers and the content providers to facilitate fast content updates. RTPCom deployed the Cisco MDS9000 series multilayer SAN switches in the data center for intelligent storage-management. The MDS900 supports IPv6 starting with release 3.0 of the SAN-OS.

NOTE

Table 14-10 shows an example of program to (S,G) mapping that was built based on the available addresses and some redundancy considerations (dual servers in the same L1 POP for local programs or a server in each L1 POP for national programs). This approach does not take into consideration the need to load balance the multicast traffic (see Chapter 6, “Providing IPv6 Multicast Services”). RTPCom can make recommendations to the content providers regarding the server address selections based on an engineering study of load 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 the users at the access layer. The appropriate and simplest way to deploy this multicast service is in a Source Specific Multicast (SSM) model as described in Chapter 6 of this book. Figure 14-11 depicts the operation of the service. The multicast group addresses assigned to the content providers are SSM specific FF3E:X::1—FF3E:X::F. The multicast routing protocol used is PIM-SSM and this implies minimal provisioning requirements. BGP and OSPFv3 provide unicast reachability of the multicast servers. With the content servers hosted by RTPCom, the multicast domain coincides with its network. This makes it easy 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. RTPCom provides one or multiple set-top boxes to service subscribers and they are

546

Chapter 14: Deploying IPv6 in an IP Service Provider Network

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 all information pertinent to their profile. Figure 14-11 Multicast Service Operation in RTPCom’s Network

ISP

Data Center

L1-POP (New York)

L2-POP

L3-POP

Multicast Traffic

Advanced Services Design and Implementation

NOTE

547

Enforcing the use of MLDv2 provides RTPCom with some level of control over the types of customer devices used to access the multicast service. At the time of this writing, there are few stacks on the market that support MLDv2. For this reason, it is likely that RTPCom’s customers will be able to request multicast streams only through the set-top boxes it provides. The manufacturer of these devices used a BSD implementation of MLDv2.

The other important aspect of the customer interface is the method of controlling access only to subscribed services. RTPCom decided to roll out the service with the help of the MLD access control feature. Customers are charged monthly for the programming package they signed up for. The subscription provides them full access to all video and audio channels in the package. At the same time RTPCom is evaluating the MLD AAA feature for its potential to simplify the provisioning process. MLD AAA also provides a mechanism to charge the 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 multicast forwarding, PIM-SSM and MLDv2 on all IPv6 interfaces. These are most of the protocols and features needed in the deployment.

NOTE

At layer 2, MLD snooping is a feature that could be enabled to optimize the service on the access layer switches. In the case of RTPCom, this is not generally applicable since it is using dedicated VLANs for each subscriber and there are no listeners connected to aggregation switches.

The second step in implementing the multicast service is that of making the server addresses available throughout the network for Reverse Path Forwarding calculation. To advertise the prefixes for this purpose from the Data Centers to the L2 POPs, the IPv6 multicast address family has to be added to the existent BGP configuration. For the New-York data center in Figure 14-9, the relevant addition to the configuration of router NY-D-0-2 is shown in Example 14-7. Example 14-7 IPv6 BGP Multicast Configuration of Router NY-D-0-2 ! router bgp 1600 ! address-family ipv6 multicast neighbor 2600:A001:0:F000::2 activate

continues

548

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Example 14-7 IPv6 BGP Multicast Configuration of Router NY-D-0-2 (Continued) neighbor 2600:A00A:0:F000::2 activate network 2600:A002:00DD:1000::/64 network 2600:A002:00DD:2000::/64 network 2600:A002:00DD:3000::/64 exit-address-family !

The two neighbors are the TOP-RRs in the Denver and Atlanta L1 POPs. Prefixes 2600:A002:00DD:1000::/64, 2600:A002:00DD:2000::/64, and 2600:A002:00DD:3000::/64 are advertised for the three existent content providers. The same address family is configured on all L1 POP routers that provide access to the network backbone, on all RRs and on all L2 POP routers that are the gateways to the network backbone. 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 will control user access to programming. For example, one of the profiles (Premium1) offered by content provider 3 to users is shown in Table 14-11. The subscriber has access to all basic national and local programs and all Premium 1 national channels, both audio and video. Table 14-11 Programming Offered by Content Provider 3 with the Premium1 Package Content Provider 3—Premium1 Programming Video Programs

Basic National Channels National 1–16 Premium 1 National Channels Premium 1.1–Premium 1.100 Local Channels Local Channel 1–100

Audio Programs

Basic National Channels National 1–16 Premium 1 National Channels Premium 1.1–Premium 1.100

FF3E:3::1 2600:A002:00DD:3000::101–10F FF3E:3::2 2600:A002:00DD:3000::201–264 FF3E:3::5 2600:A002:00DD:3000::501–5C8 FF3E:3::A 2600:A002:00DD:3000::1001–100F FF3E:3::B 2600:A002:00DD:3000::2001–2064 continues

Advanced Services Design and Implementation

549

Table 14-11 Programming Offered by Content Provider 3 with the Premium1 Package (Continued) Content Provider 3—Premium1 Programming Local Channels Local Channel 1–100

FF3E:3::F 2600:A002:00DD:3000::5001–50C8

The access list reflecting this profile is CP3-Premium1, as shown in Example 14-8. Example 14-8 IPv6 Multicast Access Control Configuration for the CP3-Premium1 Package ipv6 access-list CP3-Premium1 permit ipv6 any host FF3E:3::1 permit ipv6 any host FF3E:3::2 permit ipv6 any host FF3E:3::5 permit ipv6 any host FF3E:3::A permit ipv6 any host FF3E:3::B permit ipv6 any host FF3E:3::F deny ipv6 any any

When a user subscribes to the Premium1 package provided by content provider 3, this ACL is used with MLD to 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 interface ATM1/0.10 point-to-point atm route-bridged ipv6 pvc 0/42 encapsulation aal5snap protocol pppoe ! ipv6 address 2600:A02A:30F0:A01::1/64 ipv6 enable ipv6 traffic-filter Basic-Access in ipv6 mld access-group CP3-Premium1 ipv6 nd other-config-flag

RTPCom configures the ACLs for all profiles on an access router as soon as it receives the first multicast service request from a subscriber on that router. The profiles are applied to access lines based on subscriptions.

NOTE

After IPv6 multicast routing is enabled on the access routers, MLDv2 is already running on all interfaces, so a subscriber can potentially join a multicast group if he knows the (S,G) addresses. For this reason, the default state of the access lines should block MLD joins. After multicast is enabled on an access router a Block-mcast ACL denying all traffic should be configured and used with MDL access control on all customer facing interfaces. When a user subscribes to the multicast service, the access control is modified according to the user profile.

550

Chapter 14: Deploying IPv6 in an IP Service Provider Network

The steps that are followed in deploying IPv6 multicast are summarized in Table 14-12. Table 14-12 Multicast Service Rollout Checklist RTPCom Task 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 the ones that link RTPCom network to the outside world.

Customer Task

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 is sufficient 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 the offered multicast service to leave its network, and it does not want other multicast traffic to enter it. The easiest way to enforce this policy is to not enable IPv6 multicast processes on the data center routers that provide connectivity to the outside world. This approach eliminates in principle the need for other multicast traffic control measures. Access lists could be used on the outbound links to reinforce this policy. They are rather straightforward because they would block all multicast traffic in or out. However, care has to be taken to make sure that link-local multicast traffic is allowed through for basic operation of IPv6. Multicast address scoping makes it easier to differentiate between link-local and other types of multicast traffic. This simplifies the ACLs. Another item to consider in terms of optimizing the deployment is the possible need to improve subscriber’s perception about channel zapping. Channel zapping refers to the rapid switching between channels that inpatient and bored users are inclined to do. When the customer base is significant, statistically there is a good chance that most of the popular

Advanced Services Design and Implementation

551

channels are drawn down to the access layer by registered listeners. In this case, there is little delay when switching between channels. In the early phases of the deployment, however, it is likely that a user’s channel selection would have to trigger a set of PIM join messages toward an L1 POP data center, which might imply a longer delay. RTPCom is addressing this issue by “drawing” the multicast streams to a convenient layer of the network (L2 POPs, for example) with the help of static joins. This will reduce the delay of joining a channel and therefore the delay during channel zapping. This optimization would come 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 an access layer design that is characterized by clear oversubscription, RTPCom’s customers and their typical use of the access service (Internet access over IPv4) do not complain of relevant bandwidth constraints. At the current levels of subscription, the FTTH service is particularly less prone to resource contention. The xDSL service 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 expensive 5-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 layers are over engineered so they will not require changes. On the other hand, the access layer has to be enabled to handle the various types of traffic based on their specific requirements. For this reason, RTPCom decided to deploy 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

Low latency

IPv6—multicast

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 three classes reflecting the types identified in Table 14-13. It will be marked and

552

Chapter 14: Deploying IPv6 in an IP Service Provider Network

handled based on its specific requirements. Table 14-14 presents the QoS classes (see Chapter 5) deployed, their mapping to traffic, and where 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 phones—no 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.

Class-based weighted fair queuing will be used on the access interfaces to control outbound traffic based on class membership. Fixed bandwidth will be reserved for the content traffic. Two profiles are made available to the 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 service comes with an additional 1 Mbps. This provides RTPCom with another revenue opportunity that is stimulated by 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 the servers 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 Content match protocol ipv6 match access-group name Multicast ! policy-map Content class Content set dscp af11 ! interface TenGigabitEthernet1/1 service-policy input Content ipv6 address 2600:A002:00DD:3000::1/64 ipv6 enable ! ipv6 access-list Multicast permit ipv6 any FF3E::/16 !

Advanced Services Design and Implementation

553

The same policy is applied inbound on all interfaces that connect to content servers throughout RTPCom’s network. In a similar manner, the IPv6 traffic received from USInternet is marked for Best Effort handling. RTPCom has no visibility (or much interest) in the IPv4 traffic which is wrapped inside the PPP and L2TP encapsulations. For this reason, it will not need to mark it, as it will be placed into default class. For the IPv6 Internet 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) class-map match-all Internet-Access match protocol ipv6 ! policy-map Internet-Access class Internet-Access set dscp default ! interface GigabitEthernet2/1 service-policy input Internet-Access ipv6 address FE80::83D7:77 link-local ipv6 enable !

The next step in implementing QoS is the definition of the traffic classes based on Table 14-14 (next to these three classes, one has to remember the existence of the default class), the policy definition and their application to the access lines. The relevant configuration for access router NY-10-12-16 is shown in Example 14-12. Example 14-12 QoS Configuration of Access Router (NY-10-12-16) ! class-map match-all Content match dscp af11 class-map match-all Voice match dscp ef class-map match-all Basic class-map match-all Premium ! policy-map Child-Premium class Voice priority 300 police 300000 class Content bandwidth 4000 police 4000000 class class-default

continues

554

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Example 14-12 QoS Configuration of Access Router (NY-10-12-16) (Continued) policy-map Child-Basic class Voice priority 150 police 150000 class Content bandwidth 2000 police 2000000 class class-default policy-map Parent-Premium class Premium shape average 5000000 service-policy Child-Premium policy-map Parent-Basic class Basic shape average 3000000 service-policy Child-Basic ! interface ATM1/0.10 point-to-point atm route-bridged ipv6 pvc 0/42 encapsulation aal5snap service-policy output Parent-Basic protocol pppoe ! ipv6 address 2600:A02A:30F0:A01::1/64 ipv6 enable ipv6 traffic-filter Basic-Access in ipv6 mld access-group CP3-Premium1 ipv6 nd other-config-flag !

The classification is done based on the DSCP bits relying on the fact that all traffic is properly marked by the time it reaches the access layer. Two policies are shown for the two service profiles: basic and premium. The characteristics 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

Operating and Troubleshooting the Network

555

The parent policies shape the overall traffic for the subscriber. They are applied outbound under the PVC configuration for xDSL customers or under the subinterface for FTTH customers. Inbound policies can also be 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 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 Task

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 RTPCom network 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. New protocols and new services open new doors to possible attacks. These attacks could endanger both IPv4 and IPv6 infrastructures.

Securing the IPv6 Network Until its expansion into IPv6 under the design presented so far, RTPCom was relatively protected from security threats. In the case of IPv4 service, RTPCom is not concerned at all with the customer traffic at layer 3, it is all encapsulated in PPP and L2TP. RTPCom has

556

Chapter 14: Deploying IPv6 in an IP Service Provider Network

minimal provisioning responsibilities and user protection against attacks, if any is provided by the ISPs. In this context, RTPCom’s infrastructure is not exposed to outside traffic and attacks. The IPv6 service deployment changes completely the service model and with that it changes the security challenges. RTPCom is now switching the customer traffic at layer 3 throughout its network. This mode of operation exposes its infrastructure to attacks from the Internet as well as attacks sourced by its own customers. RTPCom is now responsible for customer provisioning and also for protecting him to a certain extent. 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 as well as the IPv4 ones. RTPCom’s main concern is to secure its infrastructure. It will secure its access layer from attacks originated by its customers and it will secure its Edge from attacks originated by Internet hosts. Another area of concern is the data center in each L1 POP. It contains resources that are vital to the proper operation of various services and their management.

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 or impair 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 its own customers

The important thing to remember is that in RTPCom’s case, IPv4 facilitates IPv6 attacks sourced through its customers. IPv6 over IPv4 tunnels set up through the IPv4 service are invisible to RTPCom. Such tunnels can prove 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 was already 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 (or subinterfaces) as shown in Chapter 9, “Securing IPv6 Networks.”

Operating and Troubleshooting the Network

557

•

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. The router 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 to transport their multicast traffic for that matter. RTPCom could filter out customer traffic with multicast destinations. The ACL might turn out to be rather complex as it will have to permit link-local multicast as well as some of the well known control-plane multicast groups. A simpler way would be to disable PIM on all customer interfaces. The later approach does rely on the assumption that the CPE router does not need to use PIM to provide multicast service to hosts behind it. This is a reasonable assumption for the time being. Considering the limited resources of such devices, it is expected 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-DOS permit icmp any any nd-ns permit ipv6 any host FF02::2 ! class-map match-all Access-mcast-DOS-class match access-group name Access-mcast-DOS ! policy-map prevent-mcast-attack class Access-mcast-DOS-class police 70000 1500 1500 conform-action transmit exceed-action drop ! interface ATM1/0.10 point-to-point service-policy input prevent-mcast-attack atm route-bridged ipv6 pvc 0/42 encapsulation aal5snap service-policy output Parent-Basic protocol pppoe ! ipv6 address 2600:A02A:30F0:A01::1/64 ipv6 enable ipv6 verify unicast reverse-path ipv6 traffic-filter Basic-Access in ipv6 mld access-group CP3-Premium1 ipv6 nd other-config-flag no ipv6 pim !

558

Chapter 14: Deploying IPv6 in an IP Service Provider Network

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) routing header while the Type 2 (MIPv6) RH are allowed for Mobile IPv6 service. This security policy is implemented 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 threats are better understood.

Securing the Edge At the network edge, RTPCom peers with various ISPs. In their case, link-local attacks are less likely, even though they still are possible. On the other hand, attacks in a global scope are significant because of the exposure 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 of adding the following final touches:

•

While implementing the IPv6 Internet access service, RTPCom specifically blocked the infrastructure prefixes from being advertised outside its network. This policy will also be supported with inbound ACLs 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 the routers that provide access to the outside world. RTPCom can complement this measure with explicit filters applied inbound to its edge router interfaces.

•

Despite being less likely, link-local attacks are still possible if the network of its institutional partner with whom it is sharing the link was compromised. As a measure of precaution, RTPCom can apply the policing methods used at the access layer.

The practical implementation of these policies is straightforward based on the examples already given for the access layer.

Securing the Data Center A third area of security concern in RTPCom’s network is the data center that hosts resources critical to its service offering. A first level of defense is provided by the perimeter

Operating and Troubleshooting the Network

559

security policies implemented at the access and edge layers. On the other hand, these resources require specific protection beyond layer 3, too. To prevent attacks on the data center servers, RTPCom leverages PIX Firewalls upgraded to release 7.0 for IPv6 support. It also deploys the standard host protection policies on each of the servers. For more details on these mechanisms, see Chapter 9 of this book. The multicast servers require particular attention because they can be accessed by the content providers. This is done over dedicated circuits to an access router connecting to server interfaces different than the ones used to transmit the multicast traffic. RTPCom has to treat the server as an unsecured resource. For this reason it will have to control the unicast traffic it receives from the servers. The same ACLs used at the access layer can be applied in this case. RTPCom will have to continuously update its security policies based on the experiences learned operating IPv6. The dynamic character of these policies is also driven by the evolution of the existent IPv6 services and the 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 mostly over IPv4. The CiscoWorks NMS currently in use is upgraded to the latest release to leverage its IPv6 capabilities. NetFlow will be particularly used to monitor the traffic while Cisco IP SLA will be used for performance management. NetFlow captured data is sent to the collectors located in the data centers over IPv4. For topology mapping and IPv6 connectivity, the NOC team is testing Nagios. See Chapter 10, “IPv6 Network 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 for troubleshooting and resolving most common problems. IPv6’s characteristics and the design of the services deployed require new troubleshooting methodologies that are significantly different from the ones used for the IPv4 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 is verified to be up, the first step in gaining access is to acquire the prefixes assigned. The investigation of the proper completion of this step should be at the top of the list when troubleshooting customer connectivity.

560

Chapter 14: Deploying IPv6 in an IP Service Provider Network

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’s host. For NY-10-12-16 on the ATM1/0.10 interface where the customer is using stateless autoconfiguration: NY-10-12-16#show ipv6 neighbors IPv6 Address 2600:A02A:30F0:A01:20D:29FF:FEE1:4DC0 FE80::20D:29FF:FEE1:4DC0

Age Link-layer Addr State Interface 116 000d.29e1.4dc0 STALE ATM1/0.10 116 000d.29e1.4dc0 STALE ATM1/0.10

The MAC address of the user is 000d.29E1.4DC0.

• •

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 troubleshooting steps:

• •

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 is provisioned for DHCP-PD: NY-10-12-16#show ipv6 dhcp interface ATM1/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 binding Client: 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.

NOTE

•

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.

Debugs are a last resort troubleshooting tool on production routers because of their impact on the router’s performance. It is also recommended that the debugging output is sent to the log rather than the console or terminal.

Operating and Troubleshooting the Network

561

With the prefix assigned to the clients, the only thing left to verify is that they are reachable via ping from the access router.

Unicast Routing and Forwarding Troubleshooting IPv6 unicast routing and forwarding is similar to troubleshooting IPv4. Each routing protocol can 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 summary BGP router identifier 2.10.0.1, local AS number 1600 BGP table version is 73, main routing table version 73 72 network entries using 9576 bytes of memory 72 path entries using 5184 bytes of memory 7 BGP path attribute entries using 392 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 15176 total bytes of memory BGP activity 73/0 prefixes, 73/0 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2600:A002:A000:1100::1 4 1600 11852 11854 73 0 0 1w1d 71 2600: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 unicast BGP table version is 73, local router ID is 2.10.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin 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 ?

562

Chapter 14: Deploying IPv6 in an IP Service Provider Network

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 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, as shown in Example 14-17. Example 14-17 IPv6 Routing Table of Router NY-10-0-1 NY-10-0-1#show ipv6 route IPv6 Routing Table - 77 entries Codes: 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 2 B 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 to troubleshoot 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 forwarding one. In the case of NY-10-0-1 and prefix 2600:A010::/28, the CEF information is as follows: NY-10-0-1#show ipv6 cef 2600:A010::/28 detail 2600:A010::/28 RIBfib nexthop FE80::20F:34FF:FEB2:FA40 TenGigabitEthernet9/1 nexthop FE80::20F:34FF:FEB2:F980 TenGigabitEthernet9/2

Operating and Troubleshooting the Network

563

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 experienced RTPCom 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 preparation for this deployment, they went through technology training. Chapter 6 provides the technology details alongside a practical example of how troubleshooting is done. Routers rely on the underlying unicast routing protocols to make multicast control or forwarding plane decisions. For this reason, the first step in troubleshooting multicast should the verification that the network is converged an operational from the unicast perspective. In the case of the L2 POP routers connecting to the backbone, it is worth specifically checking the prefixes advertised via BGP for IPv6 multicast (NY-10-0-1), as shown in Example 14-18. Example 14-18 IPv6 BGP Information for the Multicast Address Family on Router NY-10-0-1 NY-10-0-1#show bgp ipv6 multicast BGP table version is 2, local router ID is 2.10.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin 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 the involved protocols (MLD and PIM). The relevant information on router NY-10-12-16 is shown in Example 14-19. Example 14-19 MLD Information on Access Router NY-10-12-16 NY-10-12-16#show ipv6 mld interface ATM1/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

continues

564

Chapter 14: Deploying IPv6 in an IP Service Provider Network

Example 14-19 MLD Information on Access Router NY-10-12-16 (Continued) 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 interface Interface PIM Nbr Hello DR Count Intvl Prior Gi6/1 on 1 30 1 Address: FE80::20F:35FF:FE3F:441A DR : FE80::20B:60FF:FEA7:D81A Gi6/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 control protocol shown operational, it is time to move on to verify the multicast topology, as shown in Example 14-20. Example 14-20 PIM Information on Access Router NY-10-12-16 NY-10-12-16#show ipv6 pim topology IP PIM Multicast Topology Table Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info Entry 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 Connected Interface state: Name, Uptime, Fwd, Info Interface 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) 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-16 and if customers subscribed to it (interface ATM1/0.10). The forwarding information in Example 14-21 can further 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 verbose IP Multicast Forwarding Information Base Entry Flags: C - Directly Connected, S - Signal, Internet access - Inherit A flag, AR - Activity Required, D - Drop

Deployment Lessons

565

Example 14-21 Multicast Forwarding Information on Access Router NT-10-12-16 (Continued) Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second Other counts: Total/RPF failed/Other drops Interface Flags: A - Accept, F - Forward, NS - Negate Signaling IC - Internal Copy, NP - Not platform switched SP - Signal Present Interface 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 troubleshooting commands, review Chapter 6 of this book. Debugs are useful tools in troubleshooting the dynamic aspects of problems. However, they should be used with care because of their impact on the network equipment resources. Other tools, such as sniffers, can prove useful 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 deploying IPv6 in RTPCom’s network:

•

RTPCom justifies the significant undertaking to migrate its network to dual stack by the pressing need to enable it for new, scalable services. In particular, the support of multicast services is fundamental to its strategic plans of offering multimedia content to customers. RTPCom’s long-term commitment to IPv6 made the idea of a one-step migration more palatable, it has to be done so might as well do it right from the start.

•

Although IPv6 has all the features necessary to implement service models similar to the one used for IPv4, RTPCom decided to take advantage of this migration and use a new design. This design encompasses all the improvements it wanted it could do on its IPv4 infrastructure and all the elements necessary to support new services such as multicast.

566

Chapter 14: Deploying IPv6 in an IP Service Provider Network

•

RTPCom planned the IPv6 adoption well in advance and in that context it purchased and upgraded equipment with IPv6 support in mind. The few scheduled upgrades it went through up to the point of deploying IPv6 refreshed enough its network for RTPCom to require minimal investments in upgrades specific for the deployment.

•

User provisioning remains a concern for RTPCom. Although stateless autoconfiguration and DHCP-PD are practical mechanisms, they require a lot of provisioning done on the router. The problems could have been eliminated with the use of PPP; however, RTPCom decided to avoid the additional encapsulation. It also thinks that it can manage this issue in these initial phases of the deployment but will continue to investigate alternative options.

•

One immediate limitation experienced with this design is the fact that it is difficult to offer more than one ISP for the Internet access services. In the case of IPv4 the customer traffic is tunneled to the resources (LNS) dedicated to the ISP it selected with its subscription. In the case of IPv6, this is difficult because all subscribers are using RTPCom’s address space. One possible way to solve this issue is to reserve a few bits in the addressing scheme that would identify the ISP selected by the customer. 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. This mechanism can also be provisioning intensive, but it is considered a manageable problem compared with the benefits provided by running the service. As the customer base for the content delivery service 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 services independent of the IP version used for transport. In the case of RTPCom this approach was not a good fit. The existent infrastructure did not have QoS enabled so the IPv6 deployment could not benefit from a preexistent QoS service. On the other hand, the suite of IPv6 services is a superset of the IPv4 ones, so it is natural to have some IPv6 traffic types (for instance, multicast) treated in a specific manner.

•

Security became a more prominent concern for RTPCom with the deployment of IPv6. With the new service model used, RTPCom’s network elements are more exposed to attacks. The new services and the specifics of IPv6 itself create new kinds of vulnerabilities. For these reasons RTPCom makes security 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 already looking at the next phase in network development. They are planning

Deployment Lessons

567

the migration to an IPv6-only network. In fact, its IPv4 service design positions RTPCom for a rather simple and straightforward migration. The PPPoE sessions of its IPv4 customers currently encapsulated in L2TP tunnels over IPv4, could be encapsulated in L2TP tunnels over IPv6 instead. As soon as its network management systems can operate in IPv6-only mode and the LNS routers are upgraded to dual stack, RTPCom is ready to completely remove IPv4 from most of its network. However, RTPCom’s operations team understands well the importance of taking time to let changes settle and of getting familiar with the new protocol. For now, there is plenty of room 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 it in your own environment. Chapter 13, “Deploying IPv6 in an MPLS Service Provider Network,” and Chapter 14, “Deploying IPv6 in an IP Service Provider Network,” apply this knowledge to examples of IPv6 deployments in service provider networks. This chapter focuses on the main steps to integrate IPv6 services in an enterprise network. It is not an exhaustive list because drivers, requirements, and scenarios vary 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 of running an IPv6 trial on an enterprise infrastructure followed by basic guidelines to go through the process of designing, implementing, and moving the IPv6 services to full production. The topics covered include the following:

• • • • • •

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 on innovation that delivers the best set of agricultural products and services. Producing and delivering new products, growing through acquisitions, and licensing goods around the world 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 North America, Latin and Central America, Asia, Europe, and Africa/Middle East. Each region

570

Chapter 15: Deploying IPv6 in an Enterprise Network

has its set of local headquarters, listed in Table 15-1, linked through dedicated circuits from provider T-World, which was selected for its global presence. Table 15-1

AC Headquarters Locations Region

Headquarters

Africa and Middle East

Johannesburg, Dubai

Asia and Pacific

Hong Kong, Sydney, Tokyo

Europe

Budapest, Paris

Latin and Central America

Buenos Aires, Mexico City

North America

Atlanta, Montreal, San Francisco

T-World also provides the peering for Internet access (IA) in the different regions. Smaller branches and storage areas take advantage of local broadband access and VPN technologies to connect to their nearest regional headquarters in a cost-effective communications solution. Figure 15-1 shows the global coverage of the AC intranet worldwide. Figure 15-1 AC Geographical Network Map

Over the years, e-Commerce became a leading market-coverage expansion strategy for AC. This drives the IT department 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)

AC Network Environment

571

events, the IT team decided to evaluate IPv6’s potential. The evaluation considered possible business drivers for IPv6 integration in the AC corporate network, including competitive advantages regarding 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 than 10 people to large sites for the main and regional headquarters. One of the IT department’s objectives is to standardize and reduce the variety of technologies, equipment, and architecture deployed globally (because management and operations are mostly remote). The life span for networking hardware is around three to five years. Support was a key factor in the selection and partnership with T-World provider, which offers a strong presence worldwide.

AC Network Infrastructure For years, LAN switching and Ethernet technologies—from 10 Mbps to 10 Gbps—have been selected and deployed by AC at the company headquarters. More recently, IEEE 802.11 (WiFi) was added to the headquarters, 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 Class B address is registered through the Registry, but private address space is also used for services such as recently deployed IP telephony. Class B addressing and private address space were basically defined with a subnet mask of 255.255.255.0, enabling 254 hosts per subnet. IPv4 address assignment is not really structured for 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 its intranet and must be validated on every configuration where it makes sense. Deviation from those must clearly 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 of broadband access links, which are configured with static routes. The original criteria that led to the selection of EIGRP included its simple setup and enhanced feature set, including multiprotocol 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-hop router redundancy.

572

Chapter 15: Deploying IPv6 in an Enterprise Network

— 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 to communicate with the Internet. — QoS—Mandatory for sites where IP telephony is implemented. — Multicast—Optional as an experimental service for audio and video streaming—IGMP snooping and 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 do support 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, enabling well-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 branch office.

Headquarters Although the 12 headquarters—main and regional—are different with respect to their location, number of users, size of the campus and data center, bandwidth, and external connectivity, their infrastructure tends to follow the same design rules. The campus consists of core layer 3 switches—Cisco Catalyst 6500 series—which aggregate stackable switches configured as layer 2 or layer 3 switches, such as Cisco Catalyst 3550 and 3750 series (depending on their intended role). The backbone technology is actually Gigabit Ethernet, but two locations have already been upgraded to 10 Gigabit Ethernet. Each region connects to the Internet through a peering with T-World to ensure the best regional access. This requires a demilitarized zone (DMZ) to be set on each of these campuses. Deployed routers are either Cisco 7200 or, more recently, Cisco 7600 series (which replace the old Cisco 7500 series). WAN access connectivity evolves rapidly because technology and pricing are regularly debated and negotiated between AC and T-World. Previously based on OC-3 ATM or SONET/SDH access, they evolved to Gigabit Ethernet.

AC Network Environment

573

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 Routers Reachable via Leased Lines

Data Center

Si

WAN

Si

GE or 10GE Si

Si

Regional Headquarters Firewall Branch Offices Routers Reachable via VPN Si

Internet DMZ Public Servers

Si

T-World Router

Branch Offices The network of small branch offices is made of a couple stackable LAN switches, such as Cisco Catalyst 3550 and 3750 series. Wide-area connectivity is typically done through the Cisco 1700 or 2600 series, with a planned evolution to Cisco 1800 and 2800 series. Depending on the branch location and size, the connection to the nearest regional headquarters is either achieved through leased lines configured with PPP or through broadband access—depending on its aggressive price point in many countries—taking advantage of the latest VPN technology. The sites reachable via a broadband connection get an IPv4 static address from the local ISP and then are set up with private addresses behind Network Address Translation (NAT). There is no direct IA from a branch office, because security is enforced from the headquarters.

574

Chapter 15: Deploying IPv6 in an Enterprise Network

Cisco EIGRP is the routing protocol configured between headquarters and branch offices. The offices linked through a VPN tunnel over their broadband access just have a static route configure toward the IPsec tunnel.

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 end users 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 looks into IPv6 for its currently available and upcoming products and features as advertised by vendors. It maps them 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 benefits of integrating it, and evaluate the pros and cons. Evaluate the potential cost of deployment. In this aspect, IPv6 differs from other new network technologies because it impacts all aspects of networking: applications, operating systems, routers and switches, firewall, management, and so on.

•

Identify the actual missing pieces, either from the technology or its implementation—if any—to gauge the potential limitations of its integration and define the rules and timing of deployment. This includes areas such as multihoming, security, and management policies.

•

Ensure AC competitiveness in countries where the deployment of IPv6 is a nationwide initiative. One of the successes of the AC Corporation was its early adoption of e-Commerce with partners and customers. Fast adoption of IPv6 in some countries must not take AC by surprise and change its business flow.

•

Take advantage of basic IPv6 features such as larger address space and autoconfiguration for usages such as the following: — Addressing devices with multiple embedded access technologies (Ethernet, WiFi, and so on). Proliferation of networking access technologies on newgeneration PCs generates an increase in the IP address consumption on a campus network configured with DHCP. Devices with multiple wireless and fixed networking interfaces are a growing trend. The support team was 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 interface ID. — AC regularly acquires and merges small businesses at a local level. Renumbering is always problematic when resources must be shared but may have been configured with private addresses overlapping with those already used in AC network. The AC IT team wants to understand the benefit of IPv6 addressing and renumbering to ease and avoid renumbering conflicts.

Learning the Technology

575

— Override the setup of private address space and NAT by allocating a global IPv6 address space (as explained in draft-ietf-v6ops-nap) to remote locations. Today, those locations must use NAT because of the broadband service conditions. This would enable the deployment of externally reachable application servers and ease remote support of hosts that are not always working transparently through NAT, through applications such as remote assistance. The AC IT 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 such as the following: — Transportation—Expanding Internet connectivity in AC trucks and ships to take advantage of the 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 latest wireless 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 phones and PDAs. — Industrial tracking of goods with the networked evolution of sensors. An example is the use of radio frequency identification (RFID) to monitor and track the goods managed by the AC Corporation.

•

Keep the AC infrastructure secure. The AC IT team realizes that many IPv6 over IPv4 tunnels are available on dual-stack operating systems. It does not want its network security to be jeopardized by end users or applications that might configure such mechanisms. One might want to forbid and disable such features, but the AC IT team prefers to understand and manage a technology (not just disable things that might be bypassed later). They also understand that IPv6 cannot be integrated if it is not at least as secure as IPv4.

Learning the Technology While visiting Japan (refer to http://www.v6pc.jp/en/showcase/showroom/index.html and http://www.ipv6style.jp/en/action/20030328/index.shtml for details), the CEO saw a demonstration of IPv6. Back from his trip to Asia, he asks the IT team to study the impact of this new technology. He is interested in the potential application of some of the new industrial and consumer devices, such as IP video surveillance cameras and industrial 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 budget has been planned for any IPv6-related activity. It is decided to open a trial with several tasks to

576

Chapter 15: Deploying IPv6 in an Enterprise Network

educate the team about IPv6 in real life and evaluate the integration of the technology 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 of IPv6 Internet connectivity, including security setup

Configuration and management of IPv6 hosts on a single site with a defined set of applications 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. Initial project tasks consist of the following:

•

Provisioning the appropriate equipment — Routers Cisco 2821 routers—named R7 and R5, as shown on Figure 15-3— with 256 MB of memory and 64 MB of Flash, integrated 10/100/1000 Mbps Ethernet interfaces, loaded with Cisco IOS 12.4(2)T Advanced Enterprise Services image. — Hosts IPv6-enabled laptops running Microsoft Windows XP SP1 will be used. Other operating systems can be selected for evaluation, too. If both Microsoft 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 mean all applications can benefit from the IPv6 network layer. At the time of this writing, several websites (for instance, the 6NET Project, at http:// www.ipv6.org/v6-apps.html 193.55.253.34/WP5Apps/Applications.html) provide a list of software, either commercial or experimental, that can be installed to evaluate IPv6. The AC IT team will start the testing with the following well-known basic applications: — Ping—Available from all implementations; basic requirement to check the connectivity between devices.

Learning the Technology

577

— Traceroute—Available from all implementations; basic requirement to verify the Internet connectivity. — Web browser—Such as Internet Explorer 6.0 and Mozilla Firefox 1.0.4 to access well-known IPv6 websites as well as the IPv6 video camera. — Multimedia streaming—For instance, Videolan Client 0.8.1 as its client version allows generating a network stream using IPv6 unicast and multicast or Microsoft Windows Media & Server version 9.0 or 10.0.

•

Define an IPv6 addressing scheme for the trial. — To meet the objectives of the different tasks and get full IPv6 Internet connectivity during the trial, an addressing scheme must be selected. It can be either a production prefix assigned by a provider, or 6to4 prefixes as introduced in Chapter 3, “Delivering IPv6 Unicast Services” (RFC 3056). It is decided to go with 6to4 because of the simplicity of the mechanism, no dependency on a service provider because each site with a global IPv4 address can configure these prefixes, and the 6to4 tunneling is commonly available on various platforms. — The test bed will be expanded later to include ISATAP and manually configured tunnels; the IPv6 addressing scheme is planned for these extensions as shown in Table 15-2. — It is well understood by the AC IT team that this addressing scheme is a temporary solution defined for this trial. Mechanisms such as 6to4 and ISATAP have inherent limitations (for instance, the lack of IPv6 multicast support or the mandatory need to keep an IPv4 address to build the IPv6 address or prefix). This may not be suitable for a production deployment.

Table 15-2

Addressing Scheme for the IPv6 Trial

6to4 Prefix 2002::/16

Public IPv4 address (82.121.150.27) from R7 interface Lo0

Subnet ID

Interface ID

2002

5279:961B:

0001

Can be EUI-64 or manual or privacy (hosts)

Router R5 ISATAP

2002

5279:961B:

8888

ISATAP value

Routers R7 and R5 configured tunnel link

2002

5279:961B:

0003

Can be EUI-64 or manual

Site Router R7 6to4 router Native IPv6 on VLAN2

578

Chapter 15: Deploying IPv6 in an Enterprise Network

With all the equipment now ready, the trial can begin with a setup as shown in Figure 15-3. Routers and hosts are attached on a layer 2 switch configured with two VLANs, one for the IPv6 test segment, the other to enable external IPv4 connectivity on the DMZ segment. For security reasons, the initial setup does not permit communications between the IPv6 segment and AC internal network. Figure 15-3 Initial Test Bed Network Diagram 6to4 Relay’s with Anycast Address 192.88.99.1 - 2002:c058:6301::1

Internet R5 R7

T-World Router Gig0/1.1 VLAN1

Gig0/1.2 VLAN2

AC Intranet AC Edge Router IPv6 prefix used on VLAN 2 IPv6 Hosts

2002:5279:961B:1::/64

Derived from Lo0 IPv4 address -

82.121.150.27

A first router, a Cisco 2821 (router R7 in Figure 15-3), is set up for a basic IPv6 configuration, as shown in Example 15-1, which consists of the following:

•

Enabling IPv6 routing on Cisco IOS routers through the ipv6 unicast-routing command, and IPv6 Cisco Express Forwarding (CEF). Note

IPv6 CEF requires IP CEF to be configured to enable fast processing of IPv6 packets.

•

An interface GigaEthernet 0/1.2 configured for native IPv6 to act as gateway on VLAN2, where the IPv6 hosts will be attached

•

An interface Tunnel0 configured as a 6to4 tunnel with the IPv6 address of the interface GigaEthernet 0/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

Learning the Technology

579

Example 15-1 IPv6 Configuration of Router R7 R7#show running ip cef ipv6 unicast-routing ipv6 cef ! interface Tunnel0 no ip address no ip redirects ipv6 unnumbered GigabitEthernet0/1.2 tunnel source Loopback0 tunnel mode ipv6ip 6to4 ! interface Loopback0 ip address 82.121.150.27 255.255.255.255 ! interface GigabitEthernet0/1.2 description === IPv6 vlan === encapsulation dot1Q 2 ipv6 address 2002:5279:961B:1::/64 eui-64 ! ipv6 route 2002::/16 Tunnel0 ipv6 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 interface GigabitEthernet0/1.2 is up, line protocol is up Description: === 6to4 vlan === IPv6 is enabled, link-local address is FE80::20D:BDFF:FE99:F5F9 Global 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 seconds Hosts use stateless autoconfig for addresses.

continues

580

Chapter 15: Deploying IPv6 in an Enterprise Network

Example 15-2 IPv6 Interface Status on Router R7 (Continued) Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::5279:961B Interface is unnumbered. Using address of GigabitEthernet0/1.2 No 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 route IPv6 Routing Table - 6 entries Codes: 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 2 S ::/0 [1/0] via 2002:C058:6301::1 S 2002::/16 [1/0] via ::, Tunnel0 C 2002:5279:961B:1::/64 [0/0] via ::, GigabitEthernet0/1.2 L 2002:5279:961B:1:20D:BDFF:FE99:F5F9/128 [0/0] via ::, GigabitEthernet0/1.2 L FE80::/10 [0/0] via ::, Null0 L 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 is done on Microsoft Windows XP SP1. Hosts will get their IPv6 address through the stateless autoconfiguration. The IPv6 address is built after receiving Router Advertisement messages. There are three IPv6 addresses set on the interface:

• • •

Link-local Global permanent Global temporary (privacy address as defined in RFC 3041)

Learning the Technology

581

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 ipconfig commands can also be used, as shown in example 15-4. Example 15-4 Checking IPv6 Configuration on Microsoft Windows XP C:\>ipv6 install C:\>ipconfig Windows IP Configuration Ethernet adapter Wireless Network Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 10.87.94.8 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : 2002:5279:961b:1:f86e:7f1e:e4b3:6aa9 IP Address. . . . . . . . . . . . : 2002:5279:961b:1:202:8aff:fead:a836 IP Address. . . . . . . . . . . . : fe80::202:8aff:fead:a836%4 Default Gateway . . . . . . . . . : 10.87.94.254 fe80::20d:bdff:fe99:f5f9%4 C:\WINDOWS\system32>netsh netsh>interface ipv6 netsh interface ipv6>show address Querying active state... Interface 4: Wireless Network Connection Addr Type DAD State Valid Life Pref. Life Address --------- ---------- ------------ ------------ ----------------------------Temporary Preferred d23h34m50s 23h33m14s 2002:5279:961b:1:f86e:7f1e:e4b3:6aa9 Public 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 named www.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.org Pinging 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=415ms Reply from 2001:7f9:1000:1::103: bytes=32 time=379ms Reply from 2001:7f9:1000:1::103: bytes=32 time=388ms Reply from 2001:7f9:1000:1::103: bytes=32 time=407ms Ping 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

582

Chapter 15: Deploying IPv6 in an Enterprise Network

Example 15-6 Verifying Operation with IPv6 Traceroute C:\>tracert www.ipv6tf.org Tracing route to www.ipv6tf.org [2001:7f9:1000:1::103] over a maximum of 30 hops: 1 2 ms 2 ms 2 161 ms 162 ms 3 223 ms 223 ms 4 323 ms 323 ms 5 317 ms 314 ms 6 314 ms 314 ms 7 397 ms 507 ms 8 396 ms 385 ms Trace complete.

2 ms 2002:5279:961b:1:20d:bdff:fe99:f5f9 160 ms 3ffe:c15:c002:5000::2 223 ms 3ffe:c00:8023:29::2 321 ms us-nyc02a-re1-fe-0-0.ipv6.aorta.net [2001:730:0:4::1] 315 ms nl-ams06d-re1-t-9.ipv6.aorta.net [2001:730::1:61] 314 ms telianet-gw1.nl.ipv6.aorta.net [2001:730::1:35] 406 ms 2001:6c0:800:2009::2 384 ms 2001:7f9:1000:1::103

Then, an IPv6 video camera is attached to the IPv6 LAN segment. Bidirectional access— reception of the images, transmission of zoom commands—of the IPv6 video camera can be demonstrated as shown in Figure 15-4. Figure 15-4 IPv6 Video Camera View and Control

Other applications such as web browsing or video streaming can now be installed and verified on an IPv6 network layer.

Learning the Technology

583

Expanding the Test Bed After successfully being able to communicate between the AC isolated IPv6 LAN segment and the IPv6 Internet, 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 IPv6 deployment. 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 with the new AAAA record type, which contains the address of the IPv6 hosts. Then (optionally but recommended), the IPv6 network layer needs to be supported on the DNS servers and clients. DNS servers on the AC network are currently running BIND version 9.3.1, so the task is limited to the configuration 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 DNS Resolver 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 the decision to prefer one over the other to the operating system. Failure to resolve DNS for one stack can potentially lead to a fallback to the other IP stack. Experience shows that it does not always work (perhaps because of a stack or a network connectivity issue). For this reason, AC would start the deployment with a specific naming for IPv6 resources: www.ipv6.ac.com to avoid impacting end users. It is also a way to control the deployment of IPv6 applications, because, generally, names are preferred over IPv6 addresses by end users 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

584

Chapter 15: Deploying IPv6 in an Enterprise Network

Example 15-7 DNS Lookup to Resolve a Name and IPv6 Address C:\WINDOWS\system32>nslookup Default Server: dns-sjk.cisco.com Address: 171.68.226.120 > set type=all > ipv6.hs247.com Server: dns-sjk.cisco.com Address: 171.68.226.120 Non-authoritative answer: ipv6.hs247.com AAAA IPv6 address = 2001:1638::4:2 hs247.com nameserver = ns1.rdns.de hs247.com nameserver = ns2.rdns.de ns2.rdns.de internet address = 84.200.3.7 > > www.hs247.com Server: dns-sjk.cisco.com Address: 171.68.226.120 Non-authoritative answer: www.hs247.com AAAA IPv6 address = 2001:1638::4:2 www.hs247.com internet address = 82.211.48.7 hs247.com nameserver = ns2.rdns.de hs247.com nameserver = ns1.rdns.de ns2.rdns.de internet address = 84.200.3.7 > > ipv4.hs247.com Server: dns-sjk.cisco.com Address: 171.68.226.120 Non-authoritative answer: ipv4.hs247.com internet address = 82.211.48.7 hs247.com nameserver = ns1.rdns.de hs247.com nameserver = ns2.rdns.de ns2.rdns.de internet address = 84.200.3.7 >

ISATAP Router 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 end users selected to participate in this evaluation is too small to justify an upgrade of all layer 3 switches on the campus. Nevertheless, to meet the objectives of its increasing number of users, the AC IT team set up—on the intranet—a second Cisco 2821 (R5)—shown in Figure 15-5—as an ISATAP router for use by internal AC users with manual configuration of the service. It is decided not to declare the ISATAP router into DNS to avoid the potential use of IPv6 through automatic tunneling. The IT team intends to keep the support costs and the test participants under control.

Learning the Technology

585

Figure 15-5 ISATAP Router in the AC Network R5 ISATAP router: 10.151.151.7 ISATAP IPv6 address 2002:5279:961B:8888:0:5EFE:5279:961B

IPv4 Campus Backbone

10.149.4.60/24

10.149.1.60/24 10.149.2.60/24

10.149.3.60/24

2002:5279:961B:8888:0:5efe:10.149.2.60

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 cef ipv6 unicast-routing ipv6 cef ! interface Tunnel100 no ip address no ip redirects ipv6 address 2002:5279:961B:8888::/64 eui-64 no ipv6 nd suppress-ra tunnel source Loopback0 tunnel mode ipv6ip isatap ! interface Loopback0 ip address 10.151.151.7 255.255.255.255 !

After configuring router R5, you can check the status of interface Tunnel100, which is the ISATAP tunnel, as shown in Example 15-9. Example 15-9 Displaying ISATAP Tunnel Status R5# show ipv6 interface Tunnel100 Tunnel100 is up, line protocol is up IPv6 is enabled, link-local address is FE80::5EFE:5279:961B Global unicast address(es): 2002:5279:961B:8888:0:5EFE:5279:961B, subnet is 2002:5279:961B:8888::/64 [EUI]

continues

586

Chapter 15: Deploying IPv6 in an Enterprise Network

Example 15-9 Displaying ISATAP Tunnel Status (Continued) 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 seconds Hosts use stateless autoconfig for addresses.

After an ISATAP router is operational, you can enable ISATAP on Windows XP. You do so with the following 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 in Example 15-10. Example 15-10 ISATAP Status on Windows XP C:\>ipv6 if 2 Interface 2: Automatic Tunneling Pseudo-Interface {48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE} does not use Neighbor Discovery uses Router Discovery routing preference 1 EUI-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 C:\>

NOTE

This ISATAP router can later benefit the remote users connecting to the headquarters sites via VPN using the Cisco VPN Client 4.x. They can set up an ISATAP tunnel to R5 over the established IPv4 VPN (see Chapter 7, “VPN IPv6 Architecture and Services”).

Learning the Technology

587

IPv6 Internet-to-Campus Connectivity After the ISATAP router R5 is operational, the overall campus has local IPv6 connectivity. To complete the trial and enable the connection with the IPv6 Internet through the 6to4 router (R7), additional configurations are required:

•

To enable the communication between routers R7 and R5, which are on different sides of an IPv4-only firewall, the firewall must be configured to enable protocol 41 forwarding between the IPv4 addresses of both router R5 and R7. This particular setup blocks any other tunneled IPv6 connection not going through these two IT-controlled routers. Configuration of the firewall is not shown because it depends on the type of device installed to perform the functions. Moreover, this configuration involves only IPv4-related settings.

Note

•

After the IPv4-only firewall is set up to allow protocol 41 to go through, a tunnel can be manually configured between R5 and R7 routers, as shown in Figure 15-6. This provides the campus with access to the IPv6 Internet. Optionally, a dynamic routing protocol can be enabled to pass IPv6 routing information through the tunnel (for example, RIPng).

Figure 15-6 Expansion of the IPv6 Test Bed 6to4 Relay’s with Anycast Address

Other 6to4 Sites

192.88.99.1 - 2002:c058:6301::1

Internet R7

Gig0/1.1 VLAN1

T-World Router

IPv4 Campus Backbone

Gig0/1.2 VLAN2

Port 41 Enabled AC Edge for R7–R5 Traffic Router IPv6 Hosts

R5

Manually Configured Tunnel Between R5–R7

The manually configured tunnel setup between routers R7 and R5 is shown on interfaces Tunnel10 in Example 15-11. RIPng is also enabled on the interfaces to exchange routing information.

588

Chapter 15: Deploying IPv6 in an Enterprise Network

Example 15-11 Manually IPv6 Configured Tunnel Setup on Routers R5 and R7 On router R7 R7# ip cef ipv6 unicast-routing ipv6 cef ! ipv6 router rip v6 ! interface Tunnel10 no ip address ipv6 address 2002:5279:961B:3::1/64 ipv6 rip v6 enable tunnel source GigabitEthernet0/1.1 tunnel destination 172.16.2.1 tunnel mode ipv6ip ! interface GigabitEthernet0/1.2 description === IPv6 vlan === encapsulation dot1Q 2 ipv6 address 2002:5279:961B:1::/64 eui-64 ipv6 rip v6 enable ! interface GigabitEthernet0/1.1 encapsulation dot1Q 1 ip address 172.16.1.1 255.255.255.252 R7# On Router R5 R5# ip cef ipv6 unicast-routing ipv6 cef ! ipv6 router rip v6 ! interface Tunnel10 no ip address ipv6 address 2002:5279:961B:3::2/64 ipv6 rip v6 enable tunnel source GigabitEthernet0/1 tunnel destination 172.16.1.1 tunnel mode ipv6ip ! interface GigabitEthernet0/1 ip address 172.16.2.1 255.255.255.252

•

The IPv6 access to AC must be fully secured before opening the IPv6 IA to its users. Generally, the firewall does not inspect IP in IP traffic. It requires the IPv6 traffic to be filtered on R5 or R7 before it can be encapsulated in the manually configured tunnel. This can be done by setting reflexive ACLs or the via the Cisco IOS Firewall

Learning the Technology

589

IPv6 feature set (see Chapter 9, “Securing IPv6 Networks”). Note that 6to4 tunnels can only be secured, by setting IPv4 IPsec between 6to4 routers, if used in a close environment that does not reach the IPv6 Internet through 6to4 relay.

Expanding the IPv6 Intranet Testing With the ISATAP router up and running, all sites may now have active IPv6 end users. Nevertheless, the solution is not optimal for the remote sites because it creates a single IPv6 subnet that connects all IPv6 hosts in an overlay of the IPv4 infrastructure. An easy alternative to expand the test bed to remote locations is to set manually 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 opportunity to test a dual-stack configuration over a PPP connection. Routers on both ends of the links are upgraded 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 VPN IPsec-encrypted tunnel. An alternative is to create a secure 6to4 tunnel (see Chapter 3), but that would mean 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 good enough. Nevertheless, it is easy to turn on a routing protocol such as RIPng over the tunnels, as shown between 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 all the prerequisite releases of software are installed. At the same time, it is clear that there is a need for more IPv6-capable applications. Evaluated operating system releases have a really limited set of applications able to run over an IPv6 network layer. It is an expected that the Microsoft next-generation operating system and Linux evolutions will result in all applications becoming more IP version agnostic. Based on the technology evaluation, the following guidelines were set:

•

Better to focus on IPv6 deployment by beginning with one or more applications that can run over IPv6 and is either benefiting to the enterprise business or could lower the cost of support when run over 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.

590

Chapter 15: Deploying IPv6 in an Enterprise Network

•

Transition mechanisms such as 6to4 or ISATAP are easy to configure but they have some inherent limitations in terms of feature capabilities: — Do not correspond to an IPv6 global prefix as allocated by the Registries and are not optimized 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 IPv6 topology to identify a problem

For the preceding reasons, summarized in Table 15-3, on a long-term basis AC will prefer a dual-stack infrastructure when cost is not an issue. Table 15-3

Lessons Learned from Trialing Tunnels 6to4

ISATAP

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 in conjunction with SNMP, a common feature on networking devices and network management stations. Real production traffic, however, was flowing over AppleTalk, DECnet, IPX, or SNA. Then, the integration of a free TCP/IP stack on most operating systems accompanied by a large set of applications, including the emergence of the World Wide Web, favored a transition from these legacy protocols to IPv4. Today, IPv4 and the Internet are deeply part of our life and not anymore reserved to IT departments. New generations of appliances appear every year that implement IP. The importance of the protocol makes it critical for businesses to stay in sync with the rapid evolution of the technology. An upgrade of the IP protocol is a significant evolutionary step, so it has to be addressed accordingly. AC has to evaluate the costs of versus the urgency and benefits of such an upgrade.

Design and Setup

591

Cost Analysis Regardless of the AC network’s age, the full integration of IPv6 services means that an inventory—similar to what was done for Y2K—of the existing equipment must be performed to evaluate the cost of the project. This process would help plan the associated budget and project timescale. In some cases, an enterprise clearly identifies a need for IPv6 to support a given application, as described later in this section. But it is expected that in many cases the integration of this new IP version will occur over years as the networking environment gets upgraded to the newest generation of products and applications. The cost analysis of such a project must include 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 all new 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 must complete the following:

•

Training—An AC team leader and two senior engineers will subscribe to a Cisco IPv6 class through a learning partner. Upon completion, they proceed to teach their colleagues. As a Cisco customer with CCO Learning Connection access, AC people get access to the available e-Learning Cisco IOS IPv6 class.

•

Negotiation with T-World—Fees associated with IPv6 services vary between Internet service provider as for IPv4. Because AC was T-World’s first customer to request a worldwide IPv6 deployment, they negotiated a free offering for the next two years based on the agreement that T-World can use AC as a customer reference.

Then AC could start the full integration of IPv6 with the setup of the networking equipment as soon as the design phase is complete. Configuration will be done remotely and gradually, depending on the readiness of the devices. When a local intervention is required, IPv6 will be planned in conjunction with another site intervention. Global deployment of IPv6 hosts will be complete for several years because new version of operating systems and applications must be certified by the IT department. Nevertheless, by mandating the IPv6 support through new acquisitions or development of applications, the cost of the upgrade could be integrated 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 management approval for an IPv6 integration project. As with any networking project, there are several steps to go through before advertising IPv6 as a production service. One initial step is to develop a

592

Chapter 15: Deploying IPv6 in an Enterprise Network

design of the IPv6 intranet and issue AC policies before the start of the rollout. This section does not indicate the amount of time required to achieve each phase. It is assumed that several months would be needed, depending on parameters such as IT department workload, cost control, and the availability of stable and 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

•

Planning of IPv6 services to be set up, compliant with the requirements defined by the AC IT department: — Security—Must provide a level of security equivalent with to that for IPv4 from day one for every site that is updated. Must also cope with the specifics of IPv6, including new services such as IP mobility. — Network management—Integration of the IPv6 configuration and traffic management in the actual IPv4 NMS system is mandatory. Optionally, SNMP and management applications could run over an IPv6 network layer. Networking devices must support Management Information Bases (MIBs) for IPv6 statistics. — Multicast—IPv4 multicast is an experimental service on the AC network. The operational side of dealing with multicast through NAT to cover the remote site was seen as too complex. IPv6 multicast service should become the de facto production service for multicast. AC expects to decrease the cost of operations and ease the full deployment 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 and expand Internet connectivity in the AC fleet of vehicles. — QoS—The goal is to ensure optimal operation of applications independently of the network layer protocol. Same QoS rules must apply to both IP versions.

NOTE

Because of the large number of options when designing an enterprise or commercial intranet, this section is not an exhaustive list of actions. You should tailor these guidelines 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. The next section introduces the AC plans for prefix and host address assignments.

Design and Setup

593

Prefix-Assignment Scheme At the time of this writing, the Registries only allocate an IPv6 prefix—a ::/32 or greater address space—to ISPs, NRNs, and government agencies, meaning an enterprise must get an IPv6 prefix (::/48) from its ISP. Part of the IPv6negotiation with T-World was the 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 based on the scheme shown in Table 15-4. Table 15-4

AC Corporation IPv6 Addressing Scheme Region ID (3 Bits)

Headquarters and Attached Sites (5 Bits)

Link ID per Site (8 Bits)

North America (000)

San Francisco (00000)

00-FF

Atlanta (00100) Montreal (10000) Europe (001)

Budapest (00000)

00-FF

Paris (00100) Asia-Pacific (010)

Hong Kong (00000)

00-FF

Sydney (00100) Tokyo (10000) Africa and Middle East (011)

Dubai (00000)

00-FF

Johannesburg (00100) Latin and Central America (100)

Buenos Aires (00000)

00-FF

Mexico City (00100) Reserved for future (101–111)

Reserved for future

00-FF

Address Configuration Rules Although IPv6 specifications define the support of stateful and stateless autoconfiguration mechanisms to assign an IPv6 address to a host interface, as discussed in Chapter 3, most of the host implementations only support the stateless option. This means there are only two modes of IPv6 address allocation that can be practically 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 can be selected. It can be manually configured, it can be derived from the MAC address following the EUI-64 rules, or it can be built using the “privacy extensions” defined in RFC 3041 (as described in Chapter 2, “An IPv6 Refresher”). Remember that an IPv6 host interface may have a set of unicast addresses in use.

594

Chapter 15: Deploying IPv6 in an Enterprise Network

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. For resources not to be known from the Internet (for instance, NMSs), it is recommended to not set an obvious 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.

•

Networking devices can use EUI-64 as the interface ID, but at least one interface— typically loopback—must have an address with the interface ID manually configured for network management purposes. This eliminates the device reachability dependency on its hardware information. A complete swap of hardware can take place in case of failure, and the device will remain reachable by the NMS after the device configuration is reloaded.

•

On point-to-point links, the 2001:0DB8:ACAC:nnnn::/64 prefix will be preferred to keep the configuration simple and aligned with the IPv6 address architecture (RFC 3513). For more information, refer also to RFC 3627.

•

Hosts actually configured through DHCP for IPv4 get their IPv6 address through stateless autoconfiguration.

•

Hosts supporting “privacy extensions” interface IDs must have a default value of 24 hours. Privacy extensions is a new capability, and its impact on traceability and managing DDoS threats may not be fully understood. Nevertheless, the basic policies related to the use of privacy extensions are as follows: — 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 a dual-stack approach. After running a network inventory, the needs to upgrade some hardware and software releases are known by the AC IT team and adequately budgeted in association with other programs for the next fiscal year. On campus LANs, layer 3 switches will be configured to run native IPv6—for instance, Catalyst 6500 series with supervisor engine 720 and native Cisco IOS 12.2(18)SXE release or Catalyst 3750 series and Cisco IOS 12.2(25)SEA release as minimum.

Design and Setup

595

Remote sites connected through leased lines will get their router software releases updated to support dual-stack operation. To reduce the labor costs, this upgrade will be associated with the update program to the Cisco 1800 and 2800 series. The minimum release to match AC service needs is Cisco IOS 12.4(2)T. Table 15-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

12.2(18)SXE

SUP-720

12.2(25)SEA

Cisco 3750 Remote sites’ WAN router

Cisco 1800

12.4(2)T

Cisco 2800

12.4(2)T

Remote sites connected via broadband access will have an IPv6-configured tunnel setup. Because IPv4 is the primary service and is already protected via the VPN tunnel between site-to-site routers to one of the main AC campuses, there is no local access security concern about adding IPv6 services. The configured tunnel allows the allocation of global IPv6 prefixes in accordance with AC rules. The addition of a global IPv6 prefix to those sites that are configured with a single static IPv4 address on the WAN link and private address on LAN ease the potential deployment of multicast and peer-to-peer applications. The IPv6 manually configured tunnels do not have to be terminated on the same device as the IPv4 IPsec VPN tunnel. When possible, they will get terminated on a Catalyst 6500 supervisor engine 720 that does support this tunnel mechanism in hardware.

Routing Protocols To keep the learning curve and operational process at a minimal level, similar routing protocols will be deployed for IPv6 and IPv4, meaning EIGRP for IGP and MP-BGP4 for peering with T-World (see Chapter 4, “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 the operational and management tasks as simple as possible, it is decided to align the IPv4 and IPv6 topologies for all routers and links in the network. The routing protocol parameters are configured to get all traffic flowing through similar paths. This decision is taken to ease the operational support, to avoid complex troubleshooting where communications between two nodes could work for a given IP version but not the other because different paths followed through the network.

596

Chapter 15: Deploying IPv6 in an Enterprise Network

First-Hop Router Redundancy IPv6 hosts on a broadcast link learn about the presence of one or more gateways by receiving Router Advertisements (RAs) sent using the IPv6 Neighbor Discovery Protocol (see Chapter 2). The Router Advertisements are periodically sent via multicast at a rate high enough to ensure that hosts learn about the routers in the span of a few minutes, which therefore removes the need to set a “default gateway” (as in the case of IPv4). The selection of a given router depends on the host IPv6 stack implementation. On the other hand, by default, RAs are not sent frequently enough to rely on the absence of the router advertisement to detect router failures. Therefore, there is a need for tuning the ND process and leveraging additional protocols to improve the availability of first-hop routers:

• • •

NOTE

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)

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 of sending Neighbor Solicitations, the messages are only sent to neighbors to whom the node is actively sending traffic and only after there has been no positive indication that the router is up for a period of time. Using the default parameter—ipv6 nd reachable-time—it will take a host about 30 seconds to learn that a router is unreachable before it will switch to another router. This delay would be noticeable to users and can cause some 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 a useful alternative. Setting of the ipv6 nd reachable-time parameter to a more aggressive value allows the speedup 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 to determine the reachability of their gateways). A good tradeoff between potential ND bursts and switchover times 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.

Design and Setup

597

Example 15-12 ND Reachable Timer Configuration R1# ! interface GigabitEthernet0/1 ipv6 address 2001:DB8:ACAC:1::/64 eui-64 ipv6 nd reachable-time 15000 !

NOTE

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 firsthop redundancy mechanisms 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 routers available on a LAN through the ND RA mechanism. It is the responsibility of the hosts to maintain a default router list from which one is selected for forwarding traffic to off-link destinations. The selection for a destination is then cached, and the implementation of selecting gateways can be round robin or “always the same.” 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 provide equivalent, but not equal-cost, routing). Policy may dictate that one is preferred. These are two relevant examples: — “Accidentally” deploying a new router before it has been fully configured could lead to hosts adopting it as a default router and traffic being blackholed. Management may want to indicate that some routers are more preferred than others. — Multiple routers that route to distinct sets of prefixes. Redirects (sent by nonoptimal routers for a destination) mean that hosts can choose any router and the system will work. But traffic patterns may mean that choosing one of the routers would lead to considerably fewer redirects.

•

The IPv6 router selection IETF Internet Draft (draft-ietf-ipv6-router-selection) defines two optional extensions to ND RA messages: — Default Router Preferences (DRP)—A coarse preference metric for default routers. This is an extremely simple extension—just the definition of a few unused bits in existing RA messages to address the first example mentioned above.

598

Chapter 15: Deploying IPv6 in an Enterprise Network

— More-Specific Routes (MSR)—An option to allow routers to specify routes more specific than the default route, together with a lifetime; a coarse preference metric for each such routes to address the second case mentioned above. Both are backward compatible with the existing RA mechanism and host behavior. DRP can be implemented without implementing MSR.

NOTE

At the time of this writing, Cisco IOS software only implements the DRP function. On the host side, the feature 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 returns the configuration to the default value. On AC LANs, the routers managed by the IT will be set to high to avoid 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 Release 12.4(2)T. Example 15-13 Router Preference Setup R1# ! interface Ethernet0/0 ipv6 address 2001:DB8:ACAC:10::/64 eui-64 ipv6 nd reachable-time 15000 ipv6 nd router-preference High !

Example 15-14 shows the command to check the configuration of both ND reachable timer and router preference. Example 15-14 Display of ND Reachable Timer and Router Preference Setup R1#show ipv6 inter e0/0 Ethernet0/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: 1 ND reachable time is 15000 milliseconds ND advertised default router preference is High

Design and Setup

599

Enabling Cisco HSRP for IPv6 A first-hop redundancy protocol, such as Cisco HSRP, can provide a much faster switchover to an alternate router than can be obtained using standard ND procedures. Using HSRP, a backup router can take over for a failed default router in about 10 seconds using default parameters, or less than 1 second if millisecond HSRP timers are used. This is done without any interaction with the hosts, and with a minimum amount of HSRP traffic. Most IPv4 hosts have a single router IP address configured as the default gateway. When Cisco HSRP is set up, 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 address—block different from the Cisco HSRP one for IPv4—that is derived from the HSRP group number. A virtual IPv6 link-local address is also derived, by default, from the HSRP virtual MAC address. NOTE

The Cisco HSRP for IPv6 virtual MAC address block—0005.73A0.0000 through 0005.73A0.0FFF—UDP port number 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 virtual MAC address. The EUI-64 is formed as shown in Chapter 2. For the MAC address 0005.73A0.0001, the interface ID is 00-05-73-FF-FE-A000-01, and the IPv6 link-local address is FE80::5:73FF:FEA0:1. Note that the U/L it is set to 0, indicating local significance. Periodic RAs are sent for the HSRP virtual IPv6 link-local address when the HSRP group is active. These RAs stop after a final RA is sent when the group leaves the active state. No restrictions occur for the interface IPv6 link-local address other than that mentioned for the RAs. Other protocols continue to receive and send packets to this address. In the case of IPv4, simple load sharing may be achieved by using two HSRP groups and configuring half the hosts with one virtual IP address and half the hosts with the other virtual IP address. In contrast, on IPv6 this happens by default. If there are two HSRP IPv6 groups on a link, the hosts learn of both through IPv6 ND RA messages. They are either multicast periodically, or solicited by hosts. Then a host chooses to use one—depending on the IPv6 stack implementation—such 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 IPv6 hosts. It is therefore decided that on AC LANs, when several routers are available on a given links for IPv6 hosts, HSRP for IPv6 will be configured as shown in Figure 15-7.

600

Chapter 15: Deploying IPv6 in an Enterprise Network

Figure 15-7 High Availability on AC LANs

Data Center R1

R2 Si

Si

Si

Si

HSRP Group Router Preference = High

Example 15-15 shows a configuration for routers R1 and R2 that requires a Cisco IOS Release 12.4(4)T as minimum: Example 15-15 Cisco HSRP for IPv6 Configuration Router R1 R1# ! interface Ethernet0/0 ipv6 address 2001:DB8:ACAC:10::/64 eui-64 ipv6 nd reachable-time 15000 ipv6 nd router-preference High standby version 2 standby 0 ipv6 autoconfig ! R1# Router R2 R2# ! interface Ethernet0/0 ipv6 address 2001:DB8:ACAC:10::/64 eui-64 ipv6 nd reachable-time 15000 ipv6 nd router-preference High standby version 2 standby 0 ipv6 autoconfig ! R2#

Design and Setup

601

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 R1 R1#show standby Ethernet0/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 R2 R2#show standby Ethernet0/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 Cisco IOS 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 use of network resources. Then, additional configuration options, such as Enhanced Object Tracking, can be turned 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 similar and potentially new challenges. By default, IPv4 security policies will be applied to IPv6 as well on the AC intranet. The IPv6 deployment will also benefit from all the underlying security mechanisms already in place for IPv4 (for example, AC has already secured the layer 2 access of its network with the wireless infrastructure).

602

Chapter 15: Deploying IPv6 in an Enterprise Network

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 support must be planned. The IPv4 configuration of the firewalls has to be updated to block uncontrolled IPv6 over IPv4 tunnels from being set up across the AC network perimeter. Devices performing intrusion detection system (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 the operation team in the AC network. With regard to security challenges raised by the new services deployed over IPv6, multicast and Mobile IP have to be addressed. The most important aspects of securing the multicast service relate to multicast domain management. The control and data multicast traffic has to be contained at the boundaries and blocked from entering the network. The RPs have to also be protected against possible DDoS. For the experimental deployment of MIPv6, an extended ACL will be edited to filter on the routing header Type field, permitting type = 2 (MIPv6) and denying type = 0 (source route) as available on Cisco IOS Release 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, adding IPv6 connectivity to the Cisco VPN Client users—not be confused with the VPN tunnels configured on broadband 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 stream audio and video files from headquarters to the rest of the world for scheduled training on new AC products and services as well as internal management broadcasts. In reality, the IPv4-based service is supported only at a limited number of locations (because of its operational challenges). The service trial shows it to be too complex to manage IPv4 multicast across the NAT/PAT devices. AC expects to decrease the cost of operations for the service by running it over IPv6. The same commercial applications as in the case of IPv4 multicast 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 supported by a Source Specific Multicast (SSM) model. However, AC plans to roll out collaborative applications, which means the multicast sources might not always be located in the AC’s data centers and with a well-known address. 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’s worldwide network is segmented into three areas, which represent independent multicast domains. This approach also provides the three regions with a certain level of independence that allows them to tailor content to the respective markets. Each domain is outfitted with content servers at a headquarters location as described in Table 15-6. It was also decided not to support the multicast traffic of other applications in crossing the boundaries of these domains.

Design and Setup

Table 15-6

603

Multicast Server Distribution in AC’s Network Region

Served by Multimedia Server

Africa and Middle East

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 the other two locations over night. Each data center is responsible to stream the multimedia content in its respective region. The service in each region will be similarly designed and will follow the guidelines and examples shown in Chapter 6, “Providing IPv6 Multicast Services.” It will also rely on the existent IPv6 IGP for routing information 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 the network 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 the service design. The independent domain approach chosen for this deployment would warrant an elegant and dynamic solution based on BSR as described in Chapter 6. The concern, however, is with the multiple remote locations present within each multicast domain that connect to the main campuses over smaller bandwidth pipes and use lower-end network elements with limited resources. To limit the impact of BSR flooding and the state maintained for it, AC decided to select an embedded RP approach.

•

Although MLDv2 is supported by default on the Cisco routers, at the time of planning the deployment most 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 on all layer 2 switches deployed on AC LANs. This policy refers in particular to the Cisco Catalyst 6500 with supervisor engine 720 and Catalyst 3750 or 3560 series installed on all sites. The feature is enabled 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 local headquarters serving each region. A prefix is allocated for these multicast

604

Chapter 15: Deploying IPv6 in an Enterprise Network

resources in each data center, and it is 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 domain. A second prefix is used to identify these RPs. For this prefix, bits 57 through 64 are set to DF. The loopback interfaces of the RPs are assigned this prefix with the interface ID set as ::F. In the case of an embedded RP-based deployment, the multicast group addresses derive from the RP unicast address, as described 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:

2001:DB8:ACAC: 00DD::/64

2001:DB8:ACAC:DF:: F/128

FF75:F40:2001:DB8: ACAC:DF:G

2001:DB8:ACAC:DF:: F/127

- Where G is the 32 bits group ID

2001:DB8:ACAC: 24DF::F/128

FF75:F40:2001:DB8: ACAC:24DF:G

2001:DB8:ACAC: 24DF::F/127

- Where G is the 32 bits group ID

2001:DB8:ACAC: 80DF::F/128

FF75:F40:2001:DB8: ACAC:80DF:G

2001:DB8:ACAC: 80DF::F/127

- Where G is the 32 bits group ID

- North America - Latin and Central America Paris: - Africa and Middle East

2001:DB8:ACAC: 24DD::/64

- Europe Hong Kong: - Asia-Pacific

2001:DB8:ACAC: 80DD::/64

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 !

Design and Setup

605

The two segment gateways provide a certain level of redundancy for the RP functionality. The primary RP has the loopback address configured with the longer prefix /128, whereas the backup has its configured with the same address but the /127 prefix length. This means that as long as the primary is active, the longer prefix match 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 source re-registration upon RP failure. An important aspect of implementing the multicast design described is the multicast domain control. All types of multicast traffic, other than that with link-local scope, have to be blocked from traversing the border between 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 easily done 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. This embedded-RP design simplifies significantly to service, making its support much easier than the alternative BSR-based design.

Network Management A complex aspect of running a dual-stack network is its management. Hopefully, the new IP version is an addition to existent IPv4 services on the AC intranet so that there is no need to natively manage the equipment over an IPv6 network layer. Nevertheless, the NMS is upgraded to dual stack as well and configured with a manual IPv6 address to follow AC addressing rules. Other steps to update the management infrastructure to support IPv6 include the following:

•

Releases of HP OpenView and Cisco Network Management applications are upgraded to the most recent versions, which include IPv6 applications as described in Chapter 10, “Managing IPv6 Networks.”

• •

Additional scripts are written to handle IPv6 configurations on networking devices.

•

Network Analyzer modules already deployed in AC’s network will be updated to handle IPv6 protocols.

The user-tracking application available from Cisco LMS 2.5 is leveraged to monitor the hosts configured with “privacy extension” addresses.

Overall, the NM policies and procedures have to be updated to reflect the specificities of IPv6.

606

Chapter 15: Deploying IPv6 in an Enterprise Network

Mobility One of AC management’s expectations about the integration of IPv6 is the deployment of new appliances supported through IP mobility. New generations of smart phones and PDAs, allocated to employees enabled with various wireless access technologies, should provide easy access intranet resources. The recent development of mobile router, such as Cisco MAR 3200, would also enable the AC fleet of vehicles to stay connected while being outfitted with a multitude of data collection and data delivery devices. Applications such as video security, maintenance, and tracking represent an opportunity to optimize resources. Because the implementations are still in their infancy, the AC IT team will begin an experimental service to learn the technology and validate the design. In the beginning, only the San Francisco headquarters will be configured for MIPv6. If the experiment is deemed successful, the service will be expanded to other regional headquarters. Minimum steps to be achieved 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 Services—IPv6 Mobility,” for details about the MIPv6 protocol.

Example 15-18 Router MIPv6 Home Agent Basic Setup MIPv6# ipv6 mobile home-agent ! interface GigabitEthernet0/0 ip address 10.151.1.7 255.255.255.0 ipv6 address 2001:0DB8:ACAC:00FF::/64 EUI-64 ipv6 mobile home-agent preference 1 ipv6 mobile home-agent ! Checking the Mobile IPv6 Home Agent availability MIPv6#show ipv6 mobile home-agents Home 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/64 No Discovered Home Agents MIPv6#show ipv6 mobile globals Mobile IPv6 Global Settings: 1 Home Agent service on following interfaces: 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

Design and Setup

•

607

A laptop with WiFi and 3G interfaces loaded with Microsoft Windows XP SP1 and Mobile IPv6 technology preview acts as Mobile Node. Example 15-19 are the commands and displays from the Windows 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 IPv6 C:\> ipv6 gpu MIPv6Security off Manual HA Configuration C:\> ipv6 hau C:\>ipv6 hau 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 Display MIPv6 Home Agent configuration C:\>ipv6 ha Home Address: 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c Home Agent: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 ESPTunnelSPI: 0 ESPTunnelSPD: 0 C:\> Display MIPv6 Binding Updates C:\> ipv6 bu Home Address: 2001:DB8:ACAC:00FF:20c:29ff:feb9:8d7c Host: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 CoA : 6/2006:1::20c:29ff:feb9:8d7c 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 AC subnet or any external location. Example 15-20 shows a Ping6 when the Mobile Node is away from its home network sent toward a node sitting on the home network shown in Figure 15-8. Example 15-20 MIPv6 Testing Ping6 command C:\> ping6 -t 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b Pinging 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b from 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=137ms Reply from 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b bytes=32 time=137ms Ping 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 = 128ms Ctrl+C C:\> Display of MIPv6 Binding Cache during ping6 C:\> ipv6 bc Home Address: 2001:DB8:ACAC:FF:20c:29ff:feb9:8d7c Host: 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b CoA : 6/2006:1::20c:29ff:feb9:8d7c Expires : 27s

continues

608

Chapter 15: Deploying IPv6 in an Enterprise Network

Example 15-20 MIPv6 Testing (Continued) BU_Rexmits : 2 RRState : AWAIT_ACK SEND_BU Host: 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9 CoA : 6/2006:1::20c:29ff:feb9:8d7c Expires : 39s Comments : HOME_AGENT RRState : NO_RR ACTIVE

Figure 15-8 Mobile IPv6 Test Bed MIPv6–Home Agent 2001:DB8:ACAC:FF:20F:35FF:FE2D:38C9

WinXP-MN

Home Network

AC Branch Office Router

Host 2001:DB8:ACAC:FF:20d:60ff:fefa:e15b

AC Intranet Cisco2821

Internet Mobile Node Home Address 2001:DB8:ACAC:FF:20c:29ff:feb9:8d7c

Mobile Node Care of Address 2006:1::20c:29ff:feb9:8d7c

This section gave a basic example of IP mobility configuration. Real production deployment with a large number of devices will present more challenges than a single mobile-node test. AC will continue the experimentation with more complex settings and challenges, such as the following:

•

Adding multiple mobile nodes with various implementations of MIPv6 for a largescale evaluation: Microsoft Mobile PC 2003 and its Mobile IPv6 Technology Preview and Linux MIPv6.

•

Adding a Mobile Router—Cisco MAR 3200—as MIPv6 client. An IPv6 video camera will be attached to one of the MAR 3200 Ethernet interfaces to demonstrate video surveillance in a truck.

Design and Setup

609

•

At the time of writing, MIPv6 implementation on Cisco IOS does not include an authentication mechanism such as IPsec or Light Authentication. This will be validated when available on a commercial Cisco IOS release. Note that Microsoft Mobile IPv6 Technology Preview allows disabling the IPsec authentication.

•

Security rules to protect the AC intranet from attacks when IP mobility is a production service. To begin with, extended ACLs to differentiate routing option header type 2 (MIPv6) from type 0 (source routing) are set on access routers.

Although there is still a long way to go before running an IP mobility production service, this represents a strong opportunity for innovation, helping AC to keep its technology leadership with its market through 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 and limit the throughput of the experimental IPv4 multicast traffic over the WAN links. Packets sent over both versions of IP consume the same resources, meaning that if one application is considered mission critical, its traffic has to be protected whatever the network layer version. With the assumption in mind that applications should be protocol agnostic, the AC network team decided that all QoS rules must be applied the same way to both versions of IP. This eases the integration of IPv6capable applications because no further action is needed 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 IP telephony 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 the Internet 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 and must be preserved through the intranet.

•

Management traffic—DSCP=7 The default value is intact for the network management traffic, (for example, routing protocol) that generates by default packets with such a value.

On Cisco IOS routers supporting IPv6 QoS through the Modular QoS CLI (MQC), the default action for QoS is to apply the same rules for both IPv4 and IPv6.

610

Chapter 15: Deploying IPv6 in an Enterprise Network

On AC LANs, the IP QoS to 802.1Q/p CoS correspondence is enabled to guarantee the bandwidth of the IP telephony. On Catalyst 6500 running Cisco IOS Release 12.2(18)SXE and higher, the correspondence between 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 the match 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.

Troubleshooting As introduced in this chapter, the deployment of IPv6 in an enterprise infrastructure touches most of its networking equipment and their configured feature sets. Troubleshooting such environments is similar for IPv4 and IPv6. At the same time, it calls for in-depth knowledge of IP version 6, equipment command-line interfaces (CLIs), the inherent topology and configured features, and basic (such as ping and traceroute) to advanced (such as network analyzer, network management applications) tools. Previous chapters include examples of Cisco IOS CLI output for debug commands; these examples apply to this chapter for similar troubleshooting needs. It should be added that that although IPv6 is a distinctly identified at layer 2, by the Ether Type 86 DD, the procedures to troubleshoot an IPv6 network with tools such as a LAN analyzer do not change from their IPv4 counterpart.

Future Evolutions Over the past 10 years, the evolution and growth of the commercial Internet tied to other technological developments 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 by these developments. It can quickly evolve in step with them, and it can therefore maintain leadership in its market. Nevertheless, the AC Corporation acknowledges that IPv6—as a live protocol—still requires further developments from standardization, product, application, and deployment experience perspectives. As a result of the initial deployment, several topics of interest have been identified to be monitored and evaluated for their 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

Future Evolutions

611

Prefix Selection, Assignment Policies and Multihoming The addition of IPv6 services on AC’s worldwide network is done with the collaboration of the service provider T-World, which has global presence and support. The IPv6 addressing scheme applied on the AC network is built from the 2001:0DB8::/32 prefix registered by T-World to its Registry, and it in turn assigned the 2001:0DB8:ACAC::/48 prefix to the AC Corporation. It follows the current allocation policies defined by the Registries with the goal of enabling the service provider to aggregate its routing table when peering with other providers. Nevertheless, competitiveness and business drivers may require the AC Corporation to require regional connectivity from several ISPs. At the time of this writing, Registry policies do not permit an IPv6 multihoming solution. A model similar to IPv4 where a customer may ask an ISP to announce a prefix belonging to another ISP is not allowed, neither is there an IPv6 address space assigned for provider-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 the Registries to create a provider-independent address space are still under discussion, but are unavailable now for 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 the Registries to deliver a solution to the market. The IETF IPv6 working group–defined unique local unicast IPv6 addresses were also evaluated for use in the AC intranet for local resources, such as printers and storage servers (which do not need to be accessible from the Internet). Because the draft defining this type of addresses is still evolving and no real deployment 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 greater flexibility. Experiments involving new addressing schemes, including renumbering on a large scale and security rules, will be welcomed by AC, as will guidelines on network management when several sets of addresses (global and unique local) are overlapped in an intranet. Recommendations to roll out a large number of mobile devices that reach the Intranet through external connections are another area of expertise that still has to be mastered.

Security Security is a must for an enterprise when it connects to the Internet, regardless the version of the IP protocol used. AC wants to connect to the IPv6 Internet and get some of its public servers reachable via IPv6. This is important for the business in regions where IPv6 promotion is active and to allow the IP mobility experimentation. After the initial security rules are in place, AC plans to continuously monitor the evolution of security processes and potential security alerts that may impact a dual-stack type of network. Hopefully,

612

Chapter 15: Deploying IPv6 in an Enterprise Network

organizations such as CERT, and vendors, such as Cisco, are concerned about IPv6 and are publishing alerts relevant 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 was mostly built around a centralized model, with firewalls as the key player. IPv6 specifications mandate the implementation of IPsec. Although not widely available through the stack implementations, this would lead to a distributed model where security is done on each host. This may be acceptable in some contexts, but the AC team believes the evolution should lean toward an integration of both the centralized and distributed model with policy servers to exchange information between hosts and security devices, keeping management centralized. 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. Existing applications such as e-mail, FTP, and web servers will be enhanced over time to run on IPv6. This enhancement will enable those public servers to be reachable via this protocol in regions where IPv6 becomes a must have for e-Business. This upgrade can realistically be done without risks and at a low cost. But, the real expectations from AC management, are as follows:

•

Complete the deployment of—previously run for experimentation only—service such as IP multicast for all 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 business capabilities and enhance its coverage.

Experimentation, planning, and deployment of IPv6 in an enterprise infrastructure will mostly be driven by business 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 associated applications 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 fine over IPv4 today.

•

When applicable, it is always better to run native IPv6 together with IPv4 in a dualstack approach. This guarantees the best performance and full IPv6 feature set availability for services such as multicast. The IPv6 deployment can also leverage IPv4 for certain functions (for example, network management). If not possible, review the IETF transition mechanisms to select the most appropriate ones.

Future Evolutions

613

•

All recent operating system releases are dual stack and support the libraries to make an application transparent to the IP version. As an investment protection, it is recommended to only consider the acquisition or development of applications that are protocol agnostic.

•

Some aspects of the IPv6 deployment are still in their infancy and mandate additional development—either from the standardization standpoint or product, application, and experience perspectives. 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 a day 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 the actual protocol implementations do not allow planning for a full transition. The focus is to leverage the protocol for new applications and services, and to prepare for the possibilities.

INDEX

Numerics 6Bone, 417, 446–447 6DISS, 448 6NET, 448 6PE routers forwarding performance, 432–433 MPLS DiffServ, 191–194 overview, 135–139 RSVP-TE, 194–199 security, 347 6to4 addressing, 128–131 6VPE forwarding in, 264–266 label stack, building, 262, 264 MP-BGP features, 272 MPLS DiffServ, 191–194 next hop, 261–262 router forwarding performance, 432–433 routing protocols, 260–261 RSVP-TE, 194–199 scaling, 270–271 virtual routing and forwarding, 267–269

A AAA (authentication, authorization, and accounting), 360–361 AAAA records, 105 access edge/core, 532–537 global IA (Internet access), 488–489 media types, 107–109 MPLS networks, 462–464 native access, 109 bridged, 109–110 PPP-encapsulated, 110–115 routed, 109 virtualized, 115–120 overview, 530–532 remote access enterprise networks, 589 IPsec VPNs, 254–255 tunnels, 120–121 brokers, 122

ISATAP, 123–124 manually configured, 121–122 servers, 122 Teredo, 122–123 unauthorized, 334–336 WiFi access points, 443 access control lists. See ACLs access layer media types, 107–109 native access, 109 bridged, 109–110 PPP-encapsulated, 110–115 routed, 109 virtualized, 115–120 overview, 106–107 QoS for IPv6 deployment, 201 tunnels, 120 ACLs (access control lists) example, 355–356 extended, 353 IP packet fragmentation, 354–355 MIPv6, 303–304 overview, 352 stateful filtering, 353–354 time-based, 354 addressing 6to4, 128–131 address-space allocation, 444–447 anycast, 446 architecture, 445 enterprise networks, 577, 592–594 global multicast, 446 IPv4, 6–8 loopback, 445 MPLS networks, 497–499 multicast, 208–215 NAT, 11–14 overview, 6, 526–528 policies, 444–447 public versus private, 8–9 registration, 444–447 renumbering, 10–11 RIRs, 446 SSM, 543 static vs. dynamic, 9–10

616

addressing

unicast, 445, 528–530 unspecified, 445 VPNs, 18, 252–253 address-resolution attacks, 341–342 ADVERTISE messages, 94 AF (Assured Forwarding) PHB, 183 AFRINIC, 445 aggregated home networks, 314 AH (Authentication Header), 12 Any Source Multicast. See ASM anycast addresses, 446 filtering traffic, 335 application layer attacks, 346 application classification, 441–442 architecture addressing, 445 routers, 423–424 ARIN, 445 ARPNIC, 445 AS_PATH attribute, 162 ASM (Any Source Multicast) intradomain versus interdomain, 231–232 multicast deployment example, 239–247 SSM, versus, 230–231 Assured Forwarding (AF) PHB, 183 attachment router selection, 324 authentication AAA, 360–361 CHAP, 112 RADIUS, 112 Authentication Header (AH), 12 autoconfiguration, stateless, 100 autonomous systems, 145

B backbone networks 6PE, 135–139 6to4, 128–131 GRE, 127–128 IPv4, 127 IPv6, 126 layer 2 circuits, 132–134 MPLS, 131–132 IPv4 tunnels over MPLS, 134 native MPLS, 139–140 overview, 125–126

BE (Best Effort) PHB, 183 Bellman-Ford algorithm, 146 Best Effort (BE) PHB, 183 BGP (Border Gateway Protocol) configuring, 168–169 next hops, 166–168 overview, 161–165 peering, 165–166 BGP-MPLS VPNs, implementing basic topology, 274–277 dual stack topology, 278–279 forwarding in, 264–266 hub-and-spoke topology, 280–282 Internet access topology, 282–284 interprovider topology, 285–289 label stack, building, 262–264 MP-BGP features, 272 next hops, 261–262 overview, 255–257 route reflector topology, 279–280 routing protocols, 260–261 routing table segregation, 257–260 scaling, 270–271 virtual routing and forwarding, 267–269 Binding Acknowledgment message, 296 binding databases, 102 Binding Error message, 296 Binding Refresh Request message, 296 Binding Update message, 296 bindings, 294 black hole routes, 100 bootstrap router (BSR) configuring, 240–241 overview, 226–227 Border Gateway Protocol. See BGP bridged access, 109–110 broadcast-amplification attacks, 343 brokers, tunnel, 122 BSR (bootstrap router), 226–227 configuring, 240–241 business drivers, enterprise network deployments, 574–575

C Care-of Test Init message, 296 Care-of Test message, 296

deployment

CBTS (COS-based TE tunnel selection), 198–199 CE (customer edge)-based VPNs) IPsec VPNs, implementing, 254 deploying, 255 example, 273–274 remote access, 254–255 routing protocols, 255 tunnel alternatives, 255 overview, 251–252 security, 253–254, 347–348 centralized forwarding routers, 424 CHAP (Challenge Handshake Authentication Protocol), 112 CIDR (Classless Inter-Domain Routing), 7 Cisco HSRP protocol, 599–601 Cisco IOS Firewall, 357–359 Cisco Learning Connection (CLC), 449 Cisco Network Registrar (CNR), 93 Cisco SAFE Blueprint, 20 classification, 176 Classless Inter-Domain Routing (CIDR), 7 CNR (Cisco Network Registrar), 93 communities of interest, 321, 519–520 Compressed Real Time Protocol (cRTP), 181 congestion avoidance, 176 congestion management, 176 connectivity continuous, 291 Internet-to-campus, 587–589 unicast, 6–14 VPNs, 18 content delivery, 518 content distribution multicast, 542, 547–551 content management, 542–545 content transport, 545 customer interface, 545–547 overview, 541–542 content hosting/storage, 517, 538 continuous connectivity, 291 control plane router forwarding, 417–419 traffic rate limiting, 363–364 core layer, 201 correspondent nodes, 311 COS-based TE tunnel selection (CBTS), 198–199

cost analysis applications, 441–442 hosts, 440–442 network elements, 442–443 operations, 443–444 overview, 439 cRTP (Compressed Real Time Protocol), 181 customer edge-based VPNs IPsec VPNs, implementing deploying, 255 example, 273–274 remote access, 254–255 routing protocols, 255 tunnel alternatives, 255 overview, 251–252 security, 253–254, 347–348 customer interfaces, 545, 547

D DAD (Duplicate Address Detection), 94, 296 data plane, 419–420 Default Router Preferences (DRP), 597 Delegating Routers, 101–102 deployment addressing, 526–532 edge core, 528–537 content distribution, 541–551 content hosting/storage, 538 design, 520–521 design options dual stack, 523–525 PPP/L2TP, 521–523 DNS, 538 Internet access, 539–541 network environment, 509–515 plans, 515–516 QoS, 551–555 service rollout, 537–538 targeted services communities of interest, 519–520 content delivery, 518 content hosting/storage, 517 DNS services, 517 Internet access, 517 mail services, 517 MIPv6, 519–520

617

618

deployment

unicast connectivity, 516 VoIP, 517–518 unicast, 89 design goals dual stack options, 523–525 overview, 520–521 PPP/L2TP options, 521–523 destination option, 297 DHAAD (Dynamic Home Agent Address Discovery), 295–298, 303 DHCP (Dynamic Host Configuration Protocol), 9, 94–95 binding databases, 102 DHCP-PD, 96–98 DUID (DHCP Unique Identifier), 97 prefix pools, 101–102 protocol description, 96–98 provisioning, 93 RRs (Requesting Routers), 98–101 stateless, 103–104 dialup, 509 DiffServ (differentiated services), 15, 176, 181–194 diffusing update algorithm (DUAL), 150 distance vector routing protocol, 146–147 distributed forwarding routers, 424 distributed home networks, 316–317 DNS (Domain Name System) AAAA records, 105 deployment, 538 enterprise networks, 583–584 ip6.arpa domain, 105 overview, 11, 103–104 query messages, 105–106 Resource Records, 105 Doors protocol, 318 DoS attacks. 343 DRP (Default Router Preferences), 597 DSL (Digital Subscriber Line), 9 DUAL (diffusing update algorithm), 150 dual stack, 523–525 dual-stack networks enterprise networks, 594–595 managing, 605 overview, 103 VPNs, 278–279 DUID (DHCP Unique Identifier), 97 Duplicate Address Detection (DAD), 94, 296

Dynamic Home Agent Address Discovery (DHAAD), 295–298, 303 Dynamic Host Configuration Protocol. See DHCP

E ECN (explicit congestion notification), 183 edge policies MPLS service provider networks overview, 468–478 PE router design, 470–471 PE-CE interface design, 471–473 PE-CE routing design, 473–476 PE-PE routing design, 477–478 overview, 202 edge/aggregation layer, 201 edge/core access, 532–537 education, 447–449 EF (Expedited Forwarding) PHB, 183 EGPs (exterior gateway protocols), 145 EIGRP (Enhanced Interior Gateway Protocol) configuring, 152–153 IPv6 support, 151–152 overview, 150–151 embedded RP, 227–229, 244–247 Encapsulating Security Payload (ESP), 12 encryption, 442 Enhanced Interior Gateway Protocol. See EIGRP enterprise networks, IPv6 deployments addressing, 577, 592–594 business drivers, 574–575 default router, configuring, 597–598 DNS, 583–584 dual-stack approach, 594–595 equipment overview, 576 first-hop router redundancy, 596–601 future evolutions, 610–613 host configuration, 580–581 infrastructure, 571–574 Internet-to-campus connectivity, 587–589 IP Mobility, 606–609 ISATAP router configuration, 584–586 managing, 605 market expansion, 612–613 moving IPv6 to production, 590–591 multicast services, 602–605

hub-and-spoke topology, PE-based VPNs

QoS, 609–610 remote site configuration, 589 routing protocols, 595 security, 601–602, 611–612 troubleshooting, 610 ESP (Encapsulating Security Payload), 12 Ethernet MPLS, 133 Euro6IX, 448 Expedited Forwarding (EF) PHB, 183 explicit congestion notification (ECN), 183 extended home networks, 313–314 extension headers, 179 exterior gateway protocols (EGPs), 145

F faster roaming, 323 filtering stateful, 353–354 traffic, 334–335 firewalls Cisco IOS Firewall, 357–359 overview, 356, 442 PIX Firewall, 359–360 fish problem, 195 fleet in motion, 309–310 flooding attacks, 343, 346 flow label, 179 forwarding in BGP-MPLS IPv6 VPNs, 264–266 multicast, 215–225 router performance, measuring 6PE/6VPE environments, 432–433 black-box testing, 420–422 centralized versus distributed forwarding, 424 control plane, 417–419 data plane, 419–420 evaluation checklist, 433–435 high-end routers, 429–432 low-end routers, 425–426 mid-range routers, 426–429 overview, 415–417

software versus hardware forwarding, 423 fragmentation, IP packets, 337–338, 354–355

G GARP (Generic Attribute Registration Protocol), 214 general prefixes, 98 global addresses, 253 global IA (Internet access), 488–489 global multicast, 446 GRE (Generic Routing Encapsulation), 127–128 group multicast addresses, 209–215

H hardware forwarding routers, 423 upgrade costs, 441 headers AH (Authentication Header), 12 extension, 179 Mobility, 295–297 security threats, 336–337 high-end router forwarding performance, 429–432 home gateways, 306 home networks, 313 Home Test Init message, 296 Home Test message, 296 host-initialization attacks, 341–342 hosts cost analysis, 440–442 deployment, 300–304 mobility destination option, 297 DHAAD, 297–298 Mobility header, 295–297 overview, 292–295 route optimization, 298 security, 299–300 hotspots, 305 hub-and-spoke topology, PE-based VPNs, 280–282

619

620

IANA

I IANA, 446 IA-PD (Identity Association Prefix Delegation), 97 ICMP traffic filtering and, 335–336 IGMP (Internet Group Management Protocol), 209 IGPs (interior gateway protocols), 145, 148 EIGRP configuring, 152–153 IPv6 support, 151–152 overview, 150–151 IS-IS configuring, 159–161 IPv6 support, 158–159 overview, 157 OSPFv3 configuring, 155–157 IPv6 support, 154–155 overview, 153–154 RIPng configuring, 149–150 IPv6 support, 148–149 overview, 148 integrated services (IntServ) IPv4, 176 overview, 15, 189–190 interdomain routing BGP next hop, 166–168 BGP peering, 165–166 overview, 164–165 interior gateway protocols. See IGPs Intermediate System-to-Intermediate System. See IS-IS Internet Group Management Protocol (IGMP), 209 Internet-enabled cars, 307–308 interprovider VPNs, 285–289 Intra-Site automatic Tunnel Addressing Protocol (ISATAP), 123–124 Integrated Digital Services Network (ISDN), 9, 509 IntServ (integrated services), 189–190 IPv4, 176 IP Mobility, 606–609

IP packet fragmentation, 337–338, 354–355 ip6.arpa domain, 105 IPsec communication, securing, 348–352 VPNs, implementing deploying, 255 example, 273–274 remote access, 254–255 routing protocols, 255 tunnel alternatives, 255 IPSs, 442 IPv4 addressing, 6–8 coexistence with IPv6, 204–205 mobility, 293 multicast, 17 QoS, 15, 179–181 services, 509–515 IPv6 coexistence with IPv4, 204–205 EIGRP support, 151–152 IS-IS support, 158–159 OSPFv3 support, 154–155 RIPng support, 148–149 See also MIPv6 IPv6 Form, 447 IPv6 Task Force, 448 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol), 123–124 configuring routers for enterprise networks, 584–586 ISDN (Integrated Digital Services Network), 9, 509 IS-IS (Intermediate System-to-Intermediate System) configuring, 159–161 IPv6 support, 158–159 overview, 157

L L2TP networks, 521–523 access aggregation, 116–120 label stack, building for 6VPE, 262–264 LACNIC, 445

MP_REACH_NLRI attribute

layer 2 circuits, 132–134 multicast protocols, 214 QoS, 180 layer 3 QoX, 179–180 spoofing attacks, 338–341 layer 4 spoofing attacks, 338–341 LFI (link fragmentation and interleaving), 181 link-efficiency mechanisms, 180–181 link-local addresses, 498 link-state vector routing protocol, 147–148 load balancing servers, 322 load sharing, 169–170 Local Mobility Management (LMM), 301 loopback addresses, 445 low-end router forwarding performance, 425–426

M mail services, 517 man-in-the-middle attacks, 346 marking, 176 MBGP (Multiprotocol BGP), 217–218 MDTs (multicast distribution trees), 215–216 MFIB (Multicast Forwarding Information Base), 225 mid-range router forwarding performance, 426–429 MIP (Mobile IP), 21–22, 292 MIPv4, 293 MIPv6, 21–22, 294–295, 519–520 deployment, 300–304 destination option, 297 DHAAD, 297–298 Mobility header, 295–297 route optimization, 298 security, 299–300 MLD (Multicast Listener Discovery) protocol, 209–214 mobile ad-hoc networking, 324 mobile home networks, 314–316 mobile network node (MNN), 311 mobile nodes, 292 mobile routers, 311

621

mobility deployment, 300–304 future attachment router selection, 324 faster roaming, 323 integration with mobile ad-hoc networking, 324 movement detection, 323 multihoming, 325 route optimization for NEMO, 325–326 hosts destination option, 297 DHAAD, 297–298 Mobility header, 295–297 overview, 292–295 route optimization, 298 security, 299–300 IPv4, 293 NEMO, 22 network aggregated home networks, 314 distributed home networks, 316–317 enterprises on the move, 305 extended home networks, 313–314 fleet in motion, 309–310 home gateways, 306 home networks, 313 Internet-enabled cars, 307–308 mobile home networks, 314–316 object model, 311 operations, 311–313 PANs, 306–307 sensor networks, 308–309 terminology, 311 virtual home networks, 317 nonmobile scenarios community of interest, 321 IPv4 to IPv6 transitioning, 318 route projection, 321–322 overview, 317–318 server load balancing, 322 topology hiding, 319–321 Mobility header, 295–297 mobiquity, 291, 327 Moonv6, 448 More-Specific Routes (MSR), 598 movement detection, 323 MP_REACH_NLRI attribute, 166

622

MP-BGP (multiprotocol BGP) extensions

MP-BGP (multiprotocol BGP) extensions next hop, 166–168 overview, 164–165 peering, 165–166 VPNv6 features, 272 MPLS (Multiprotocol Label Switching), 131–132 DiffServ, 190–194 Ethernet, 133 forwarder, 138 IPv4 tunnels, 134 multicast deployments, 233–234 overview, 17, 139–140 service provider deployments access design, 462–464 addressing, 497–499 core design, 465–468 CsC-CE configuration, 493 design objectives, 453–460 edge design, 468–478 global Internet access design and implementation, 488–489 inter-AS design, 484–487 MTU discovery, 500 POP design, 464–465 QoS design, 493–496 route reflector design, 479–481 security, 500–501 troubleshooting, 502–507 VPN IA service design and implementation, 490–492 VPN service design and implementation, 489–490 VRF design, 482–484 traffic engineering, 195 MPLS-TE, 190 MSR (More-Specific Routes), 598 MTU discovery, 500 multicast distribution trees (MDTs), 215–216 Multicast Forwarding Information Base (MFIB), 225 Multicast Listener Discover (MLD) protocol, 209–214 multicast services, 16–17, 207–208 addressing, 208–215 deployment, 225 ASM model, 230–232, 239–247 domain control, 225–226 enterprise networks, 602–605

MPLS infrastructures, 233–234 RP mapping and redundancy, 226–229 service models, 229–232 SSM model, 213, 230–239 tunneling mechanisms, 232 filtering traffic, 336 implementation, 547–551 IPv4, 17 layer 2 protocols, 214–215 routing and forwarding, 215–225, 563–565 multicast VPN (MVPN), 17, 233 multihoming MPLS networks, 499 overview, 169–170, 325 multiprotocol BGP extensions (MP-BGP) next hop, 166–168 overview, 217–218, 164–165 peering, 165–166 Multiprotocol Label Switching. See MPLS MVPN (multicast VPN), 17, 233

N NAT (Network Address Translation) elimination of, 348 NAP, versus, 12–13 overview, 7–14, 140 security, 12 NAT-PT (Network Address Translation–Protocol Translation), 140–143 Neighbor Discovery (ND), 291, 596 Neighbor Solicitation messages, 596 Neighbor Unreachability Detection (NUD), 596–597 NEMO (NEtwork MObility) standards, 22, 304 network access. See access Network Architecture Protocol (NAP), 12–13 network mobility aggregated home networks, 314 distributed home networks, 316–317 enterprises on the move, 305 extended home networks, 313–314 fleet in motion, 309–310 home gateways, 306 home networks, 313 Internet-enabled cars, 307–308 mobile home networks, 314–316

protocols

operations, 311–313 PANs, 306–307 sensor networks, 308–309 terminology, 311 virtual home networks, 317 NEtwork MObility (NEMO), 22, 304 next hops 6VPE, 261–262 BGP, 166–168 BGP-MPLS, 261–262 NEXT_HOP attribute, 162 NUD (Neighbor Unreachability Detection), 596–597

O operating systems, 440–441 operations cost analysis, 443–444 ORF (outbound route filtering), 270 OSPFv3 (Open Shortest Path First version 3) configuring, 155–157 IPv6 support, 154–155 overview, 153–154 outbound route filtering (ORF), 270

P PANs (personal-area networks), 306–307 Partner e-Learning Connection (PEC), 449 path vector routing protocol, 147 PE (provider edge)-based VPNs BGP-MPLS VPNs, implementing basic topology, 274–277 dual stack topology, 278–279 forwarding in, 264–266 hub-and-spoke topology, 280–282 Internet access topology, 282–284 interprovider topology, 285–289 label stack, building, 262–264 MP-BGP features, 272 next hops, 261–262 overview, 255–257 route reflector topology, 279–280 routing protocols, 260–261 routing table segregation, 257–260 scaling, 270–271

623

VRF (virtual routing and forwarding), 267–269 overview, 252 security, 253–254, 347–348 peering, BGP, 165–166 penultimate hop popping (PHP), 137, 266 performance, router forwarding 6PE/6VPE environments, 432–433 centralized versus distributed forwarding, 424 control plane, 417–419 data plane, 419–420 evaluation checklist, 433–435 high-end routers, 429–432 low-end routers, 425–426 measuring, 420–422 mid-range routers, 426–429 overview, 415–417 software versus hardware forwarding, 423 PHP (penultimate hop popping), 137, 266 PIM traffic forwarding, 243–244 PIM-Bidir, 220, 225 PIM-SM, 220–229 PIM-SSM, 220, 224–225 Ping command, 581 PIX Firewall, 359–360 policy function, 176 POP design, 464–465 PPP (Point-to-Point Protocol), 521–523 PPP over ATM (PPPoA), 111–113 PPP over Ethernet (PPPoE), 113–115 PPP-encapsulated access overview, 110 PPPoA, 111–113 PPPoE, 113–115 PPVPNs (provider-provisioned VPNs), 251 prefixes, 445 delegation, 95–103 general, 98 pools, 101–102 RIR, 446 private addresses public addresses, versus, 8–9 VPN IPv4 sites, 253 protocols multicast, 207–208 routing BGP-MPLS VPNs, 260–261

624

protocols

enterprise networks, 595 IPsec VPNs, 255 See also specific protocols provider edge (PE)-based VPNs. See PE (provider edge)-based VPNs provider-provisioned VPNs (PPVPNs), 251 provisioning, 91, 559–561 host addresses, 91–93 prefix delegation Delegating Routers, 101–102 overview, 95–96 protocol description, 96–98 RRs, 98–101 stateful DHCP, 93–95 public addresses, 8–9

Q–R QoS (quality of service), 14–15, 175–178, 551–552 enterprise network deployments, 609–610 implementation, 552–555 IPv4, 15 IPv6 deploying, 200–205 DiffServ-based deployment, 181–189 IntServ-based deployment, 189–190 IPv4, versus, 179–181 IPv6 over MPLS, 190–199 overview, 15, 178 MPLS, 493–496 radio technologies, 301 RADIUS authentication, 112, 360–361 Rapid Commit, 97 rate limiting, 363–364 RBE (Routed Bridged Encapsulation) feature, 109 Real Time Protocol (RTP), 181 reconnaissance, 332–334 recursive name serves, 103 redundancy first-hop router, 596–601 multihoming, 169–170 registration, addresses, 444–447

remote access enterprise networks, 589 IPsec VPNs, 254–255 rendezvous points. See RPs renumbering addresses, 10–11 VPNs, 18 REPLY messages, 94 Requesting Routers (RRs), 96 resolvers, 104 Resource Records, 104–105 return on investment (ROI) hosts, 440–442 network elements, 442–443 operations, 443–444 overview, 439 reverse routability, 298 reverse-path forwarding (RPF), 216–219 RGMP (Routing Group Management Protocol), 214 RIBs (Routing Information Bases), 149 RIPE, 445 RIPng configuring, 149–150 IPv6 support, 148–149 RIRs (Regional Registries), 445 roaming, 323 rogue devices, 346 rollout, service, 537–538 route flapping, 343 route optimization, 295, 298 route optimization for NEMO, 325–326 route projection, 321–322 route reflectors MPLS networks, 479–481 PE-based VPNs, 270–271, 279–280 route refresh, PE-based VPNs, 270–271 routed access, 109 Routed Bridged Encapsulation (RBE) feature, 109 Router Group Management Protocol (RGMP), 214 routers, 442 architecture, 423–424 first-hop redundancy, 596–601 forwarding performance 6PE/6VPE environments, 432–433

service provider deployments (MPLS)

centralized versus distributed forwarding, 424 control plane, 417–419 data plane, 419–420 evaluation checklist, 433–435 high-end routers, 429–432 low-end routers, 425–426 measuring, 420–422 mid-range routers, 426–429 overview, 415–417 software versus hardware forwarding, 423 mobile, 311 VRF-aware commands, 269 routing, 14 attacks, 343–344 multicast, 215–225 Routing Information Bases (RIBs), 149 Delegating Routers, 102 routing protocols, 145 BGP-MPLS VPNs, 260–261 deploying network access, 172–173 network core, 170–172 network distribution/edge, 172 distance vector routing, 146–147 enterprise networks, 595 IPsec VPNs, 255 link-state vector routing protocol, 147–148 path vector routing protocol, 147 See also specific protocols RPs (rendezvous points), 215 embedded RP, 227–229, 244–247 PIM-Bidir, 225 PIM-SM, 224 PIM-SSM, 224–225 RPF (reverse-pathforwarding), 216–219 RPs (Rendezvous Points), 17 RRs (Requesting Routers), 96–101 RSVP-TE, 194–199 RTP (Real Time Protocol), 181

S scaling PE-based VPNs, 270–271 SEAMOBY (seamless mobility, for context and micro-mobility routing), 311

625

security 6PE, 347 access, 556–558 best practices, 364–365 Cisco SAFE Blueprint, 20 data center, 558–559 edge, 558 enterprise network deployments, 601–602, 611–612 MIPv6, 21, 299–300, 345 MPLS, 500–501 NAT, 12 overview, 20–21, 329–332 threats address-resolution attacks, 341–342 application layer attacks, 346 broadcast-amplification attacks, 343 flooding attacks, 346 header manipulation, 336–337 host-initialization attacks, 341–342 IP packet fragmentation, 337–338, 354–355 man-in-the-middle attacks, 346 reconnaissance, 332–334 rogue devices, 346 routing attacks, 343–344 sniffing, 346 spoofing, 338–341 transition-mechanism attacks, 344–345 unauthorized access, 334–336 viruses, 344 worms, 344 tools AAA (authentication, authorization, and accounting), 360–361 ACLs (access control lists), 352–356 firewalls, 356–360 IPsec, 348–352 overview, 348 traffic rate limiting, 363–364 uRPF (Unicast Reverse Path Forwarding), 341, 361–363 VPNs, 19, 253–254, 347–348 sensor networks, 308–309 server load balancing, 322 service level agreements, 15 service provider deployments (MPLS) access design, 462–464

626

service provider deployments (MPLS)

addressing, 497–499 core design, 465–468 CsC-CE configuration, 493 design objectives, 453–460 edge design, 468–478 global Internet access design and implementation, 488–489 inter-AS design, 484–487 MTU discovery, 500 POP design, 464–465 QoS design, 493–496 route reflector design, 479–481 security, 500–501 troubleshooting, 502–507 VPN IA service design and implementation, 490–492 VPN service design and implementation, 489–490 VRF design, 482–484 service providers, 16 services advanced, 541–542 multicast, 542–551 rollout, 537–538 targeted, 516–520 shaping function, 176 shortest path trees (SPTs), 215–216 SIP (Session Initiation Protocol), 12 smurf attacks, 343 sniffing, 346 software forwarding routers, 423 upgrade costs, 441 SOLICIT messages, 94 Source Specific Multicast. See SSM spoofing attacks, 338–341 uRPF (Unicast Reverse Path Forwarding), 341, 361–363 SPTs (shortest path trees), 215–216 SSM (Source Specific Multicast) ASM, versus, 230–231 overview, 543 SSM mapping for MLDv1, 213 SSM mapping for MLDv2, 234–239 Start Here manual, 442 stateful DHCP, 91–95 stateful filtering, 353–354

stateless autoconfiguration address renumbering, 92–93 operation, 92 stateless DHCP, 103–104 static addresses, 9–10 storage, 443 switches, 442

T TACACS+ (Terminal Access Controller Access Control System Plus), 361 targeted services communities of interest, 519–520 content delivery, 518 content hosting/storage, 517 DNS services, 517 Internet access, 517 mail services, 517 MIPv6, 519–520 overview, 516 unicast connectivity, 516 VoIP, 517–518 Teredo tunnels, 122–123 TIB (Tree Information Base), 219 topology hiding, 319–321 Traceroute command, 581 traffic conditioning, 176 traffic engineering, 195 traffic filtering, 334–335 traffic forwarding, PIM, 243–244 traffic rate limiting, 363–364 training, 447–449 transitioning, 318 transition-mechanism attacks, 344–345 translation mechanisms, 140–143 Tree Information Base (TIB), 219 troubleshooting enterprise network deployments, 610 MPLS service provider networks, 502–507 multicast routing/forwarding, 563–565 overview, 555 provisioning, 559–561 securing networks access, 556–558

worms 627

data center, 558–559 edge, 558 overview, 555–556 unicast routing/forwarding, 561–563 tunnels 6to4, 128–131 brokers, 122 GRE, 127–128 IPsec VPNs, 255 IPv4, 127, 134 ISATAP, 123–124 layer 2 circuits, 132–134 manually configured, 121–122 multicast deployments, 232 overview, 120–121 servers, 122 Teredo, 122–123

U ULAs (unique local addresses), 253, 498–499 unauthorized access, 334–336 unicast, 6 access layer media types, 107–109 native access, 109–115 virtualized, 115–120 address space, 445 addressing IPv4, 6–8 NAT, 11–14 public vs. private, 8–9 renumbering, 10–11 static vs. dynamic, 9–10 connectivity, 516, 528–530 deployment mechanisms, 89 routing, 14, 561–563 forwarding, 561–563 service rollout, 537 tunnels brokers, 122 ISATAP, 123–124 manually configured, 121–122 servers, 122 Teredo, 122–123 Unicast Reverse Path Forwarding (uRPF), 341, 361–363

unicast routing/forwarding, 561–563 unique local addresses (ULAs), 253, 498–499 unspecified addresses, 445 upgrade costs hosts, 440–441 network elements, 442–443 operations, 443–444 overview, 439–442 uRPF (Unicast Reverse Path Forwarding), 341, 361–363

V vendor-specific attributes (VSAs), 360–361 virtual home networks, 317 virtual routing and forwarding. See VRF virtualized access layer L2TPv2 access aggregation, 116–119 L2TPv3 access aggregation, 119–120 overview, 115 viruses, 344 VLSM (variable-length subnet mask), 7 VoIP, 517–518 VPNs (virtual private networks) addressing, 18, 252–253 benefits, 18 cost savings, 18 extended connectivity, 18 overview, 18–19, 249–251 privacy, 19 renumbering, 18 security, 19, 253–254, 347–348 services, 18 VRF (virtual routing and forwarding) associating to an interface, 269 configuring, 268 MPLS networks case study, 482–484 overview, 267 VRF-aware router commands, 269 VSAs (vendor-specific attributes), 360–361

W websites, 449 WiFi access points, 443 worms, 344

Cisco Press Learning is serious business. Invest wisely.

ciscopress.com

Cisco Press

3 STEPS TO LEARNING STEP 1

STEP 2

STEP 3

First-Step

Fundamentals

Networking Technology Guides

STEP 1

First-Step—Benefit from easy-to-grasp explanations. No experience required!

STEP 2

Fundamentals—Understand the purpose, application, and management of technology.

STEP 3

Networking Technology Guides—Gain the knowledge to master the challenge of the network.

NETWORK BUSINESS SERIES The Network Business series helps professionals tackle the business issues surrounding the network. Whether you are a seasoned IT professional or a business manager with minimal technical expertise, this series will help you understand the business case for technologies. Justify Your Network Investment.

Look for Cisco Press titles at your favorite bookseller today. Visit www.ciscopress.com/series for details on each of these book series.

Cisco Press

Your first-step to networking starts here Are you new to the world of networking? Whether you are beginning your networking career or simply need a better understanding of technology to gain more meaningful discussions with networking experts, Cisco Press First-Step books are right for you.

➤ No experience required ➤ Includes clear and easily understood explanations ➤ Makes learning easy Check out each of these First-Step books that cover key networking topics:

■

Computer Networking First-Step ISBN: 1-58720-101-1

■

Network Security First-Step ISBN: 1-58720-099-6

■

LAN Switching First-Step ISBN: 1-58720-100-3

■

Routing First-Step ISBN: 1-58720-122-4

■

TCP/IP First-Step ISBN: 1-58720-108-9

■

Wireless Networks First-Step ISBN: 1-58720-111-9

Visit www.ciscopress.com/firststep to learn more.

What’s your next step? Eager to dig deeper into networking technology? Cisco Press has the books that will help you move to the next level. Learn more at www.ciscopress.com/series. ciscopress.com

Learning begins with a first step.

Cisco Press

FUNDAMENTALS SERIES ESSENTIAL EXPLANATIONS AND SOLUTIONS

1-57870-168-6

When you need an authoritative introduction to a key networking topic, reach for a Cisco Press Fundamentals book. Learn about network topologies, deployment concepts, protocols, and management techniques and master essential networking concepts and solutions.

Look for Fundamentals titles at your favorite bookseller 802.11 Wireless LAN Fundamentals ISBN: 1-58705-077-3

Network Security Fundamentals ISBN: 1-58705-167-2

Cisco CallManager Fundamentals: A Cisco AVVID Solution ISBN: 1-58705-008-0

Storage Networking Fundamentals ISBN: 1-58705-162-1

Cisco LAN Switching Fundamentals ISBN: 1-58705-089-7 Cisco Unity Fundamentals ISBN: 1-58705-098-6 Data Center Fundamentals ISBN: 1-58705-023-4

Voice over IP Fundamentals ISBN: 1-57870-168-6

Coming in Fall 2005 Cisco CallManager Fundamentals: A Cisco AVVID Solution, Second Edition ISBN: 1-58705-192-3

IP Addressing Fundamentals ISBN: 1-58705-067-6 IP Routing Fundamentals ISBN: 1-57870-071-X Visit www.ciscopress.com/series for details about the Fundamentals series and a complete list of titles.

Learning is serious business. Invest wisely.

Cisco Press

NETWORKING TECHNOLOGY GUIDES MASTER THE NETWORK Turn to Networking Technology Guides whenever you need in-depth knowledge of complex networking technologies. Written by leading networking authorities, these guides offer theoretical and practical knowledge for real-world networking applications and solutions.

Look for Networking Technology Guides at your favorite bookseller Cisco CallManager Best Practices: A Cisco AVVID Solution ISBN: 1-58705-139-7 Cisco IP Telephony: Planning, Design, Implementation, Operation, and Optimization ISBN: 1-58705-157-5

Cisco Wireless LAN Security ISBN: 1-58705-154-0 End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs ISBN: 1-58705-176-1

1-58705-139-7

Cisco PIX Firewall and ASA Handbook ISBN: 1-58705-158-3

Network Security Architectures ISBN: 1-58705-115-X Optimal Routing Design ISBN: 1-58705-187-7 Top-Down Network Design, Second Edition ISBN: 1-58705-152-4 Visit www.ciscopress.com/series for details about Networking Technology Guides and a complete list of titles.

Learning is serious business. Invest wisely.

Cisco Press

CISCO CERTIFICATION SELF-STUDY #1 BEST-SELLING TITLES FROM CCNA® TO CCIE®

Look for Cisco Press Certification Self-Study resources at your favorite bookseller Learn the test topics with Self-Study Guides

1-58705-142-7

1-58720-046-5

Gain hands-on experience with Practical Studies books

Practice testing skills and build confidence with Flash Cards and Exam Practice Packs

Visit www.ciscopress.com/series to learn more about the Certification Self-Study product family and associated series.

1-58720-079-1

1-58720-083-X

Prepare for the exam with Exam Certification Guides

Learning is serious business. Invest wisely.

Cisco Press

CCIE PROFESSIONAL DEVELOPMENT RESOURCES FROM EXPERTS IN THE FIELD

1-57870-041-8

CCIE Professional Development books are the ultimate resource for advanced networking professionals, providing practical insights for effective network design, deployment, and management. Expert perspectives, in-depth technology discussions, and real-world implementation advice also make these titles essential for anyone preparing for a CCIE® exam.

Look for CCIE Professional Development titles at your favorite bookseller Cisco BGP-4 Command and Configuration Handbook ISBN: 1-58705-017-X Cisco OSPF Command and Configuration Handbook ISBN: 1-58705-071-4

Troubleshooting IP Routing Protocols ISBN: 1-58705-019-6 Troubleshooting Remote Access Networks ISBN: 1-58705-076-5

Coming in Fall 2005

Inside Cisco IOS® Software Architecture ISBN: 1-57870-181-3

Cisco LAN Switching, Volume I, Second Edition ISBN: 1-58705-216-4

Network Security Principles and Practices ISBN: 1-58705-025-0

Routing TCP/IP, Volume I, Second Edition ISBN: 1-58705-202-4

Routing TCP/IP, Volume I ISBN: 1-57870-041-8

Visit www.ciscopress.com/series for details about the CCIE Professional Development series and a complete list of titles.

Learning is serious business. Invest wisely.

ciscopress.com

Cisco Press

NETWORK BUSINESS SERIES JUSTIFY YOUR NETWORK INVESTMENT Understand the business case for technologies with Network Business books from Cisco Press. Designed to support anyone searching for optimal network systems, Network Business titles help you justify your network investments.

Look for Network Business titles at your favorite bookseller The Business Case for E-Learning Kelly / Nanjiani • ISBN: 1-58720-086-4 The Business Case for Network Security Paquet / Saxe • ISBN: 1-58720-121-6 The Business Case for Storage Networks Williams • ISBN: 1-58720-118-6

1-58720-121-6

The Case for Virtual Business Processes Young / Jude • ISBN: 1-58720-087-2 IP Telephony Unveiled Brown • ISBN: 1-58720-075-9 Power Up Your Small-Medium Business Aber • ISBN: 1-58705-135-4 The Road to IP Telephony Carhee • ISBN: 1-58720-088-0 Taking Charge of Your VoIP Project Walker / Hicks • ISBN: 1-58720-092-9

Coming in Fall 2005 The Business Case for Enterprise-Class Wireless LANs Castaneda / Alasdair / Vinckier • ISBN: 1-58720-125-9 MPLS for Decision Makers Sayeed / Morrow • ISBN: 1-58720-120-8 Network Business Series.

Justify Your Network Investment.

Visit www.ciscopress.com/netbus for details about the Network Business series and a complete list of titles.

Cisco Press

SAVE UP TO 30% Become a member and save at ciscopress.com!

Complete a user profile at ciscopress.com today to become a member and benefit from discounts up to 30% on every purchase at ciscopress.com, as well as a more customized user experience. Your membership will also allow you access to the entire Informit network of sites. Don’t forget to subscribe to the monthly Cisco Press newsletter to be the first to learn about new releases and special promotions. You can also sign up to get your first 30 days FREE on Safari Bookshelf and preview Cisco Press content. Safari Bookshelf lets you access Cisco Press books online and build your own customized, searchable electronic reference library. Visit www.ciscopress.com/register to sign up and start saving today! The profile information we collect is used in aggregate to provide us with better insight into your technology interests and to create a better user experience for you. You must be logged into ciscopress.com to receive your discount. Discount is on Cisco Press products only; shipping and handling are not included.

Learning is serious business. Invest wisely.

Cisco Press Learning is serious business. Invest wisely.

THIS BOOK IS SAFARI ENABLED INCLUDES FREE 45-DAY ACCESS TO THE ONLINE EDITION The Safari® Enabled icon on the cover of your favorite technology book means the book is available through Safari Bookshelf. When you buy this book, you get free access to the online edition for 45 days. Safari Bookshelf is an electronic reference library that lets you easily search thousands of technical books, find code samples, download chapters, and access technical information whenever and wherever you need it.

TO GAIN 45-DAY SAFARI ENABLED ACCESS TO THIS BOOK:

• • •

Go to http://www.ciscopress.com/safarienabled Complete the brief registration form Enter the coupon code found in the front of this book before the “Contents at a Glance” page

If you have difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail [email protected].

SEARCH THOUSANDS OF BOOKS FROM LEADING PUBLISHERS Safari® Bookshelf is a searchable electronic reference library for IT professionals that features more than 2,000 titles from technical publishers, including Cisco Press.

With Safari Bookshelf you can ■

Search the full text of thousands of technical books, including more than 70 Cisco Press titles from authors such as Wendell Odom, Jeff Doyle, Bill Parkhurst, Sam Halabi, and Karl Solie.

■

Read the books on My Bookshelf from cover to cover, or just flip to the information you need.

■

Browse books by category to research any technical topic.

■

Download chapters for printing and viewing offline.

With a customized library, you’ll have access to your books when and where you need them—and all you need is a user name and password.

TRY SAFARI BOOKSHELF FREE FOR 14 DAYS! You can sign up to get a 10-slot Bookshelf free for the first 14 days. Visit http://safari.ciscopress.com to register.