IPv6 Deployment and Management E-Book

Michael Dooley

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Serie: IEEE Press Series on Network Management
• Sprache: Englisch

Seitenzahl: 346

Veröffentlichungsjahr: 2013

Beschreibung

With the announcement in 2011 that the current Internet Protocol (IP), IPv4, has nearly run out, interest in IPv6 -- the latest IP version -- has grown substantially. This book describes IPv6 technology and its repercussions on organizations, including strategies and techniques for assessing the impact of deploying IPv6 on a network, discovering current IP assets, assessing network readiness, creating a plan to deploy IPv6 while retaining IPv4 connectivity, and for managing a dual protocol IPv4-IPv6 network. It is a must read for IP network engineers, managers, and those who work in IT.

Leseprobe

Contents

Cover

Title Page

Copyright

Dedication

Acknowledgments

Introduction

Chapter 1: IPv6 Deployment Drivers

1.1 The Internet: A Success Story

1.2 Emerging Applications

1.3 IPv6 Business Case

Chapter 2: IPv6 Overview

2.1 IPv6 Key Features

2.2 The IPv6 Header

2.3 IPv6 Addressing

2.4 IPv6 Address Autoconfiguration

2.5 Mobile IPv6

2.6 Reserved Subnet Anycast Addresses

2.7 Required Host IPv6 Addresses

2.8 IPv6 Routing

Chapter 3: IPv4/IPv6 Co-Existence Technologies

3.1 Dual Stack

3.2 Tunneling Approaches

3.3 Translation Approaches

3.4 Application Support of IPv6

3.5 Service Provider IPv4/IPv6 Co-Existence

3.6 Addressing and DNS Considerations

Chapter 4: IPv6 Readiness Assessment

4.1 Putting a Plan in Place

4.2 IP Network Inventory

4.3 IPv6 to do List

4.4 IPv6 Readiness Assessment Summary

Chapter 5: IPv6 Address Planning

5.1 Internet Registries

5.2 IPv6 Address Planning

5.3 IPv6 Address Allocation Methods

5.4 Defining Your IPv6 Address Plan

5.5 Multihoming and IP Address Space

5.6 IP Address Planning Summary

Chapter 6: IPv6 Security Planning

6.1 The Good News: IP Is IP

6.2 The Bad News: IPv6 Is Not IPv4

6.3 Update Your Security Policy

6.4 Network Perimeter Monitoring and Intrusion Prevention

6.5 Extension Headers

6.6 Internal Network Protection

6.7 Network Device Security Considerations

6.8 Mobile IPv6 Security

6.9 IPv4/IPv6 Coexistence Measures

6.10 Summary

Chapter 7: IPv6 Network Management Planning

7.1 Management Model

7.2 Network Management Scope

7.3 The Simple Network Management Protocol (SNMP)

7.4 Methods and Procedures

7.5 Summary

Chapter 8: Managing the Deployment

8.1 Integrating Plans

8.2 Project Management

8.3 Testing Deployment

8.4 Production Deployment

Chapter 9: Managing the IPv4/IPv6 Network

9.1 Common Network Management Tasks

9.2 Configuration Management

9.3 Fault Management

9.4 Accounting Management

9.5 Performance Management

9.6 Security Management

9.7 Disaster Recovery/Business Continuity

Chapter 10: IPv6 and the Future Internet

10.1 Technology Enablers

10.2 The Internet's Dark Side

10.3 The Internet's Bright Future

10.4 Conclusion

Appendix

Bibliography

Index

Copyright © 2013 by The Institute of Electrical and Electronics Engineers, Inc.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey. All rights reserved.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permission.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Rooney, Tim.

IPv6 deployment and management / Timothy Rooney, Michael Dooley.

pages cm

ISBN 978-1-118-38720-7 (pbk.)

1. TCP/IP (Computer network protocol) 2. Internet addresses. I. Title.

TK5105.585.R66 2013

004.6'2068—dc23

2012041248

Michael would like to dedicate this book to his parents

Timothy would like to dedicate this book in memory of his mother, Kathryn “Kitty” Rooney

Acknowledgments

We would both like to thank Vint Cerf for the introduction to this book; we are humbled and honored. We would also like to thank Thomas Plevyak, our series editor at IEEE Press, as well as Michael Vincent and Jeff Schmidt for their time spent reviewing drafts of this book and providing extremely useful feedback and comments.

From Michael: I would also like to thank my family, my wife Suzanne, my son Michael, and my daughter Kelly, for all their love and support and allowing me not to be distracted at home while I was working on this book. And I can't forget my puppy Bailey as well, who nudged me at every opportunity to pet her instead of letting me write. I would also like to thank the following individuals who are my friends and coworkers. I have had the pleasure to work with some of the best and brightest people in the world, and I am truly blessed. In no particular order, I thank Karen Pell, Steve Thompson, Greg Rabil, John Ramkawsky, Alex Drescher, Brian Hart (aka Billy Bond), Bob Lieber, David Cross, and Al Hilton. I would also like to acknowledge the original Quadritek leadership team that I had the privilege to work with as we helped to define and create the IP Address Management market back in the early years, specifically including Arun Kapur, Keith Larson, and Leah Kelly. And a special thanks to Joe D'Andrea whose leadership has had a profound impact on my life and my career.

From Timothy: I would also like to thank my family, my wife LeeAnn, and my daughters Maeve and Tess, for their love and support during the development of this book! I would also like to thank the following individuals with whom I have had the pleasure to work and from whom I have learned tremendously about communications technologies and IPv6: Greg Rabil, John Ramkawsky, Andy D'Ambrosio, Alex Drescher, David Cross, Marco Mecarelli, Brian Hart, Frank Jennings, and those I have worked with at BT Diamond IP, INS, and Lucent. From my formative time in the field of networking at Bell Laboratories, I thank John Marciszewski, Anthony Longhitano, Sampath Ramaswami, Maryclaire Brescia, Krishna Murti, Gaston Arredondo, Robert Schoenweisner, Tom Walker, Ray Pennotti, and especially Thomas Chu.

Introduction

Nearly 14 years have passed since RFC2460 was published, specifying the IPv6 packet format. Authored by Steve Deering and Bob Hinden, this document represented nearly 8 years of debate beginning in the early 1990s over how the Internet's 32-bit IPv4 address space could be expanded. There were four proposals for what was called “IPng” for IP next generation. I won't catalog them here except to say they varied dramatically in their functionality. There was even a fifth proposal to adopt the OSI connectionless networking protocol format (CLNP) that provoked howls of outrage from many passionate engineers in the Internet Engineering Task Force (IETF) where this problem was near the top of the agenda.

After all the debate, the cochairs of the IPng Working Group, Deering and Hinden, recorded the results in December 1998 and submitted them as RFC 2460 to the Internet Engineering Steering Group (IESG) for release to the RFC editor. Many of us hoped there would be an immediate effort to implement this protocol. There was great concern that the rate of consumption of the Internet address space was accelerating during the period now known as the “dot-boom.” New Internet companies were popping up like mushrooms after a spring rain. But at the same time that the IPng debates were taking place, another effort to restrain IPv4 address consumption, through reinterpretation of the bits of the address structure, was in full swing. The so-called classless interdomain routing system made much more efficient use of address space by allowing any bit boundary in the address structure to mark the dividing line between “network” and “host.” In addition, the concept of autonomous system (AS) was introduced through which to associate indicators (masks) illustrating where this boundary lay. The Border Gateway Protocol was revised to take into account the masks marking network and host extents in the address format. Together with rules to guide very conservative IPv4 address allocations by the Regional Internet Registries, the rate of consumption of IPv4 address space was substantially curtailed. So much so that the pressure to implement IPv6 generally dissipated.

Network address translation (NAT) functionality was also introduced to allow multiple devices using private IP address numbering to share a single public address space. Port numbers were used in the NAT boxes to map to/from public addresses and the private addresses associated with individual devices in a local network. This practice attracted cable and telecommunications providers who were offering Internet service because they could now maximize the number of devices that could share one “public” IP address. This improved the absolute number of customers they could sign up to be subscribers to their Internet service.

These various practices actually stretched the use of IPv4 addresses until February 2011 when the Internet Assigned Numbers Authority (IANA), operating under the auspices of the Internet Corporation for Assigned Names and Numbers, announced that it had exhausted the supply of IPv4 addresses at the source of its allocation. The Regional Internet Registries (ARIN, LACNIC, RIPE-NCC, AFRINIC, APNIC) still had allocations but APNIC soon exhausted its supply in April 2011 and RIPE-NCC has announced that it has exhausted its supply in September 2012. A market for IPv4 address space has formed but it cannot possibly solve the real need.

The “Internet of Things” is upon us. Mobiles using LTE for data transfer will need end-to-end communication capability. The same may be said for set-top boxes, sensor devices, Internet-enabled automobiles, countless household and office appliances, and, eventually, personal devices that may even be embedded or attached in some way to our bodies. The only sensible solution is to implement IPv6 addressing capability in parallel with IPv4. We cannot simply “throw a switch” to convert every device on the Internet from IPv4 to IPv6 addressing. The transition will take years.

This long transition leads to the need for very thoughtful design and implementation of control and management systems that can deal with both IPv4 and IPv6 operating concurrently in the network and in many devices. We cannot even try to form enclaves that are IPv4 only or IPv6 only for “simplicity.” Devices that are mobile or portable will regularly encounter both IPv4 and IPv6 and mixed environments. There is also a very good chance that areas of the Internet will be IPv6 only for lack of IPv4 address space. Complex environments involving NATted IPv4 and end-to-end IPv6 will also be encountered. It is no wonder that a book of this kind, written by Michael Dooley and Timothy Rooney, will be needed on every Internet engineer's bookshelf (or in his laptop or pad or mobile, cloud client, and digital reader).

Configuration and network management are hard. Dealing with them in a mixed IP packet format environment is even harder. Error messages will be generated for both protocols even if a common fault, for example, a fiber cut, is the proximate cause. Network management systems will need to become much smarter about filtering, correlating, and sorting various error and status or warning messages emerging from a mixed IP addressing environment. The mere fact that the packet headers are potentially larger in IPv6 will create the potential for fragmentation or at least complicate the discovery of the minimum packet size needed to avoid fragmentation of blockage. These are just a few of the questions that need answering. Any system architect preparing to cope with a dual-stack environment will find this book a useful companion and source of advice.

It is not too late to start implementation but it is surely timely. The rest of this decade will see major changes and extensions to the Internet in many dimensions, not the least of which is a massive increase in the number of devices that can be attached and referenced in the system.

Some ISPs have been heard to say “customers are not asking for IPv6” as an excuse to delay implementation. From where I sit, customers should have to know nothing about IPv6. They should have a reasonable expectation that their ISPs will implement dual stack without their asking. It is irresponsible not to move rapidly to deployment of dual stack before there is no more IPv4 address available, even through NAT mechanisms. We must complete the transition to a fully connected IPv6 network as soon as possible. This does not mean we have to abandon the use of IPv4, only that we need connectivity as complete with IPv6 as we have had with IPv4—and we need it now.

Vint Cerf

VP and Chief Internet Evangelist Google

Chapter 1

IPv6 Deployment Drivers

1.1 The Internet: A Success Story

The Internet has come a long way. Invented in the late 1960s as a resilient interconnected network of networks for the U.S. Department of Defense, it has evolved into a global communications phenomenon. With the invention of the World Wide Web by Tim Berners-Lee, defining the hypertext linking of information over a network such as the Internet through the use of a web browser, this innovation of simple point-and-click user interface brought the Internet out of government and science laboratories and into ordinary people's lives. Email was the second key Internet application that contributed to the widespread adoption of Internet services during the mid-1990s. Today's Internet users generally find this ubiquitous availability of wide variety of information and applications indispensable in their day-to-day lives. If popular Internet applications like Facebook, YouTube, Twitter, Google, Blogger, shopping, and news sites, and even good old email were suddenly rendered unavailable, most people would not know what to do with themselves!

But the abundance of information and applications on the Internet is not universally available worldwide today. Figure 1-1 illustrates the statistics reported by Internet World Stats indicating the penetration of Internet users as a percentage of overall population in various regions of the world as of mid-2012. Just over one-third of the world's population has access to and use the Internet from work, home, mobile, or wireline. Penetration in North America is highest among the measured regions at more than 78% with Europe second at 63%. Among the Asian population, penetration is only about 28%.