IP Address Management: Principles and Practice (IEEE Press Series on Network and Service Management) - Hardcover

Rooney, Timothy

 
9780470585870: IP Address Management: Principles and Practice (IEEE Press Series on Network and Service Management)

Synopsis

This book will be the first covering the subject of IP address management (IPAM). The practice of IPAM includes the application of network management disciplines to IP address space and associated network services, namely DHCP (Dynamic Host Configuration Protocol) and DNS (Domain Name System). The consequence of inaccurately configuring DHCP is that end users may not be able to obtain IP addresses to access the network. Without proper DNS configuration, usability of the network will greatly suffer as the name-to-address lookup process may fail. Imagine having to navigate to a website or send an email or an instant message by IP address instead of by name! It's equally important that these DHCP and DNS configurations be based on a common IP address plan, which maps out the IP address hierarchy, subnets, address pools, and domains.

IPAM applies management disciplines to these core services, including configuration, change control, auditing, reporting and so on, and they are necessary given the absolute requirement for properly managing IP space and DHCP and DNS servers. The linkages among an IP address plan, DHCP server configuration and DNS server configuration are inseparable; a change of an IP address will affect DNS information and perhaps DHCP as well. These functions provide the foundation for today's converged services IP networks, so they need to be managed using a rigorous approach.

Today, there is no single book that covers the management of these linkages and services they provide; IP Address Management Principles and Practice will fill that gap. While several books are available for leading vendors' DHCP and DNS services implementations, few exist for IP address planning, and none exist that unifies these three topics.

To obtain a free copy of the IPAM Configuration Guide please send an email to:

ieeeproposals@wiley.com

"synopsis" may belong to another edition of this title.

About the Author

TIMOTHY ROONEY has worked with IP technologies in various capacities over the last sixteen years, including systems engineering and development. He has an extensive background not only in IP, but also in telecommunications, wireless services, and software, having worked at Bell Laboratories, AT&T Wireless, Lucent Technologies, and BT. In his current role as Director of Product Management with BT Diamond IP, Rooney is responsible for the overall BT Diamond IP product life cycle, managing product features and releases, as well as supporting sales and marketing.

From the Back Cover

A hands-on resource for rigorous, state-of-the-art management of today's IP networks

Effective IP address management (IPAM) is a key ingredient in an enterprise or service provider IP network management strategy. The practice entails the application of network management disciplines to Internet Protocol (IP) address space and associated network services, namely Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS).

As a natural follow-up to the author's previous book, Introduction to IP Address Management, this resource uniquely unifies all three foundational IP address management technologies, fully addressing their interrelationships and their cohesive management. It also describes the relevant protocols, configuration examples for the market-leading reference implementations from the Internet Systems Consortium (ISC), and techniques that can be employed to structure, monitor, secure, and manage them.

The first part of the book provides a detailed overview of IPv4, IPv6, and IP allocation and subnetting techniques. In the second, DHCP for IPv4 and IPv6 is reviewed, with explanations of applications that rely on DHCP (such as VoIP device provisioning, broadband access provisioning, and PXE client initialization), DHCP server deployment strategies, and DHCP and relevant network access security. The third part reviews the DNS protocol, DNS applications (such as name resolution, services location, ENUM, anti-spam techniques via black/white listing, and Sender ID), deployment strategies and associated configurations, and security.

Finally, the text brings together the preceding parts, discussing techniques for cohesively managing IP address space, including impacts to DHCP and DNS. Everyday IP address management functions are described including IP address allocation and assignment, renumbering, inventory assurance, fault management, performance monitoring, and disaster recovery as are coexistence strategies.

IP Address Management Principles and Practice utilizes realistic scenarios throughout to further enhance the learning process. It will educate readers responsible for managing IP address space and DHCP and DNS server configurations, such as IP network planners, engineers, and managers, including those who need to deploy IPv6 networks. It is also ideal for those responsible for managing an IP network with over 5,000 IP nodes, several DNS or DHCP servers, mixed DHCP and DNS vendor deployments, or IPv4 and IPv6.

From the Inside Flap

A hands-on resource for rigorous, state-of-the-art management of today's IP networks

Effective IP address management (IPAM) is a key ingredient in an enterprise or service provider IP network management strategy. The practice entails the application of network management disciplines to Internet Protocol (IP) address space and associated network services, namely Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS).

As a natural follow-up to the author's previous book, Introduction to IP Address Management, this resource uniquely unifies all three foundational IP address management technologies, fully addressing their interrelationships and their cohesive management. It also describes the relevant protocols, configuration examples for the market-leading reference implementations from the Internet Systems Consortium (ISC), and techniques that can be employed to structure, monitor, secure, and manage them.

The first part of the book provides a detailed overview of IPv4, IPv6, and IP allocation and subnetting techniques. In the second, DHCP for IPv4 and IPv6 is reviewed, with explanations of applications that rely on DHCP (such as VoIP device provisioning, broadband access provisioning, and PXE client initialization), DHCP server deployment strategies, and DHCP and relevant network access security. The third part reviews the DNS protocol, DNS applications (such as name resolution, services location, ENUM, anti-spam techniques via black/white listing, and Sender ID), deployment strategies and associated configurations, and security.

Finally, the text brings together the preceding parts, discussing techniques for cohesively managing IP address space, including impacts to DHCP and DNS. Everyday IP address management functions are described—including IP address allocation and assignment, renumbering, inventory assurance, fault management, performance monitoring, and disaster recovery—as are coexistence strategies.

IP Address Management Principles and Practice utilizes realistic scenarios throughout to further enhance the learning process. It will educate readers responsible for managing IP address space and DHCP and DNS server configurations, such as IP network planners, engineers, and managers, including those who need to deploy IPv6 networks. It is also ideal for those responsible for managing an IP network with over 5,000 IP nodes, several DNS or DHCP servers, mixed DHCP and DNS vendor deployments, or IPv4 and IPv6.

Excerpt. © Reprinted by permission. All rights reserved.

IP Address Management: Principles and Practice

By Timothy Rooney

John Wiley & Sons

Copyright © 2011 the Institute of Electrical and Electronics Engineers, Inc.
All right reserved.

ISBN: 978-0-470-58587-0

Chapter One

THE INTERNET PROTOCOL

1.1 HIGHLIGHTS OF INTERNET PROTOCOL HISTORY

The Internet Protocol (IP) has changed everything. In my early days at AT&T Bell Laboratories in the mid-1980s when we used dumb terminals to connect to a mainframe, the field of networking was just beginning to enable the distribution of intelligence from a centralized mainframe to networked servers, routers, and ultimately personal computers. Now that I've dated myself, a little later, many rival networking technologies were competing for enterprise deployments with no clear leader. Deployment of disparate networking protocols and technologies inhibited communications among organizations, until during the 1990s the Internet Protocol, thanks to the widespread embrace of the Internet, became the world's de facto networking protocol.

Today, the Internet Protocol is the most widely deployed network layer protocol worldwide. Emerging from a U.S. government sponsored networking project for the U.S. Department of Defense begun in the 1960s, the Transmission Control Protocol/Internet Protocol (TCP/IP) suite has evolved and scaled to support networks from hundreds of computers to hundreds of millions today. In fact, according to Internet Systems Consortium (ISC) surveys, the number of devices or hosts on the Internet exceeded 730 million as of early 2010 with average annual additions of over 75 million hosts per year over each of the past 6 years (see Figure 1.1). The fact that the Internet has scaled rather seamlessly from a research project to a network of over 730 million computers is a testament to the vision of its developers and robustness of their underlying technology design.

The Internet Protocol was "initially" defined in 1980 in Request for Comments (RFC) 760 (1) and 791 (2), edited by the venerable Jon Postel. We quote "initially" because as Mr. Postel pointed out in his preface, RFC 791 is based on six earlier editions of the ARPA (Advanced Research Projects Agency, a U.S. Department of Defense agency) Internet Protocol, though it is referred to in the RFC as version 4 (IPv4). RFC 791 states that the Internet Protocol performs two basic functions: addressing and fragmentation. While this may appear to trivialize the many additional functions and features of the Internet Protocol implemented then and since, it actually highlights the importance of these two major topics for any protocol designer. Fragmentation deals with splitting messages into a number of IP packets so that they can be transmitted over networks that have limited packet size constraints, and reassembly of packets at the destination in the proper order. Addressing is of course one of the key topics of this book, so assuring unique addressability of hosts requiring reachability is critical to basic protocol operation.

The Internet has become an indispensable tool for daily personal and business productivity with such applications as email, social networking, web browsing, wireless access, and voice communications. The Internet has indeed become a key element of modern society. And in case you're interested, the term "Internet" evolved from the lower case form of the term used by the early developers of Internet technology to refer to communications among interconnected networks or "internets."

Today, the capitalized "Internet," the global Internet that we use on a daily basis, has become a massive network of interconnected networks. Getting all of these networks and hosts on them to cooperate and exchange user communications efficiently requires adherence to a set of rules for such communications. This set of rules, this protocol, defines the method of identifying each host or endpoint and how to get information from point A to point B over a network. The Internet Protocol specifies such rules for communication using the vehicle of IP packets, each of which is prefixed with an IP header.

1.1.1 The IP Header

The IP layer within the TCP/IP protocol suite adds an IP header to the data it receives from the TCP or UDP transport layer. This IP header is analyzed by routers along the path to the final destination to ultimately deliver each IP packet to its final destination, identified by the destination IP address in the header. RFC 791 defined the IP address structure as consisting of 32 bits comprised of a network number followed by a local address. The address is conveyed in the header of every IP packet. Figure 1.2 illustrates the fields of the IP header. Every IP packet contains an IP header, followed by the data contents within the packet, including higher layer protocol control information.

Version. The Internet Protocol version, 4 in this case.

Header Length (Internet Header Length, IHL). Length of the IP header in 32-bit units called "words." For example, the minimum header length is 5, highlighted in Figure 1.2 as the lightly shaded fields, which consists of 5 words x 32 bits/ word = 160 bits.

Type of Service. Parameters related to the packet's quality of service (QoS). Initially defined as ToS (type of service), this field consisted of a 3-bit precedence field to enable specification of the relative importance of a particular packet, and another 3 bits to request low delay, high throughput, or high reliability, respectively.

The original ToS field has been redefined via RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Header" (177). The DS field, or differentiated services field, provides a 6-bit code point (DSCP, differentiated services code point) field with the remaining 2 bits unused. The code point maps to a predefined service, which in turn is associated with a level of service provided by the network. As new code points are defined with respective services treatment by the Internet authorities, IP routers can apply the routing treatment corresponding to the defined code point to apply higher priority handling for latency-sensitive applications, for example.

Total Length. Length of the entire IP packet in bytes (octets).

Identification. Value given to each packet to facilitate reassembly of packet fragments at the receiving end.

Flags. This 3-bit field is defined as follows:

• Bit 0 is reserved and must be 0. • Bit 1—Don't Fragment—indicates that this packet cannot be fragmented. • Bit 2—More Fragments—indicates that this packet is a fragment, though this is not the last fragment.

Fragment Offset. Identifies the location of this fragment relative to the beginning of the original packet in units of 64-bit "double words."

Time to Live (TTL). A counter decremented upon each routing hop; once the TTL reaches zero, the packet is discarded. This parameter prevents packets from circulating on the Internet forever!

Protocol. The upper layer protocol that shall receive this packet after IP processing, for example, TCP or UDP.

Header Checksum. A checksum value calculated over the header bits only to verify that the header is not corrupted.

Source IP Address. The IP address of the sender of this packet.

Destination IP Address. The IP address of the intended recipient of this packet.

Options. Optional field containing zero or more optional parameters that enable routing control (source routing), diagnostics (trace route, maximum transmission unit (MTU) discovery), and more.

It's ok if you find this IP header detail a bit droll. It's only to provide some context, but now let's focus our attention to the source and destination IP address fields and the IP addressing structure.

1.2 IP ADDRESSING

The IPaddress field is comprised of 32bits. The familiar dotted decimal notation for an IP address reflects the splitting of the 32-bit address into four 8-bit octets. We convert each of the four octets to decimal, and then separate them with decimal points or "dots." This is certainly easier than calculating these 32 bits as one huge number! Consider the 32-bit IP address in Figure 1.3. We simply split this into four octets, convert each octet to decimal, and then separate the decimal representation of each octet by "dots." Hence, the term "dotted decimal."

1.2.1 Class-Based Addressing

RFC 791 (2) defines three classes of addresses: classes A, B, and C. These classes were identified by the initial bits of the 32-bit address as depicted in Figure 1.4. Each class corresponded to a particular fixed size for the network number and local address fields. The local address field could be assigned to individual hosts or further broken down into subnet and host fields, as we'll discuss later.

The division of address space into classes provided a means to easily define different sized networks for different users' needs. At the time, the Internet was comprised of certain U.S. government agencies, universities, and some research institutions. It had not yet blossomed into the de facto worldwide backbone network it is today, so address capacity was seemingly limitless. The other reason for dividing address space into classes on these octet boundaries was for easier implementation of network routing. Routers could identify the length of the network number field simply by examining the first few bits of the destination address. They would then simply look up the network number portion of the entire IP address in their routing table and route each packet accordingly. Computational horsepower in those days was rather limited, so minimizing processing requirements was another consideration. A side benefit of classful addressing was simple readability. Each dotted decimal number represents one octet in binary. As we'll see later when discussing classless addressing, this is not typically the case today.

Examining this class-based addressing structure, we can observe a few key points:

• Class A networks * Class A prefixes begin with binary 0 ([0]2) plus 7 additional bits or 8 network bits total. * The network address of all 0s is invalid. * The network address of [01111111]2 = 127 is a reserved address. Address 127.0.0.1 is used for the "loopback address" on an interface. * This leaves us with a class A network prefix range of [00000001]2 to [01111110]2 = 11-26 as the first octet. * The local address field is 24 bits long. This equates to up to 224 = 16,777,216 possible local addresses per network address. Generally, the all 0s local address represents the "network" address and the all 1s is a network broadcast, so we typically subtract these two addresses from our local address capacity in general to arrive at 16,777,214 hosts per class A network. Thus, 10.0.0.0 is the network address of 10.0.0.0/8, and 10.255.255.255 is the broadcast address to all hosts on the 10.0.0.0/8 network. • Class B networks * Class B networks begin with [10]2 plus 14 additional bits or 16 network bits total. * The range of class B network prefixes in binary is [10000000 00000000]2 to [10111111 11111111]2 or networks in the range of 128.0.0.0 to 191.255.0.0, yielding 16,384 network addresses. * The local address field is 16 bits long for 65,536 - 2 = 65,534 possible hosts per class B network. • Class C networks * Class C networks begin with [110]2 plus 21 additional bits or 24 network bits total. * The range of class C network prefixes is [11000000 00000000 00000000]2 to [11011111 11111111 11111111]2 or networks in the range 192.0.0.0 to 223.255.255.0, yielding 2,097,152 networks. * The local address field is 8 bits long for 256 2 254 possible hosts per class C network. • Class D networks (not illustrated in Figure 1.4) * Class D networks were defined after RFC 791 and denote multicast addresses, which begin with [1110]2. Multicast is used for streaming applications where multiple users or subscribers receive a set of IP packets from a common source. In other words, multiple hosts having a common multicast address would receive all IP traffic sent to the multicast group or address. There is no network and host portion of the multicast network as members of a multicast group may reside on many different physical networks. * The range of class D networks is from [11100000 00000000 00000000 00000000]2 to [11101111 11111111 11111111 11111111]2 or the 224.0.0.0 to 239.255.255.255 range, yielding 268,435,456 multicast addresses. • Class E networks (not illustrated in Figure 1.4) * Networks beginning with [1111]2 (class E) are reserved.

1.2.2 Internet Growing Pains

With seemingly limitless IP address capacity, at least as it seemed through the 1980s, class A and B networks were generally allocated to whomever asked. Recipient organizations would then subdivide or subnet their class A or B networks along octet boundaries within their organizations. Keep in mind that every "network," even within a corporation, needed to have a unique network number or prefix to maintain address uniqueness and maintain route integrity.

Subnetting provides routing boundaries for communications and routing protocol updates. Each network over which IP packets traverse requires its own IP network number (network address). As more and more companies sought to participate in the Internet by requesting IPaddress space, Internet Registries, the organizations responsible for allocating IP address space, were forced to throttle address allocations. Those requesting IP address space from Internet Registries soon faced increasingly stringent application requirements and were granted a fraction of the address space requested. In having to make do with smaller network block allocations, many organizations were forced to subnet on nonoctet boundaries.

Whether on octet boundaries or not, subnetting is facilitated by specifying a network mask along with the network address. The network mask is an integer number representing the length in bits of the network prefix. This is sometimes also referred to as the mask length. For example, a class A network has a mask length of 8, a class B of 16, and C of 24. By essentially extending the length of the network number that routers need to examine in each packet, a larger number of networks can be supported, and address space can be allocated more flexibly. This is illustrated in Figure 1.5.

Routers need to be configured with this mask length for each subnet that they serve. This allows them to "mask" the IP address, for example, to expose only the indicated network and subnet bits within the 32-bit IP address to enable efficient routing without relying on address class. Based on this extended network number, the router can route the packet accordingly.

The network address and mask length were originally denoted by specifying the 32-bit mask in dotted decimal notation. This notation is derived by denoting the first n bits of a 32-bit number as 1s and the remaining 32 – n bits as 0s, and then converting this to dotted decimal.

For example, to denote a network mask length of 19 bits, you would

• create the 32-bit number with 19 1s and 13 0s: 111111111111111111100000000 00000

• separate into octets: 11111111.11111111.11100000.00000000

• convert to dotted decimal: 255.255.224.0

For example, the notation for network 172.16.168.0 with this 19-bit mask is 172.16.168.0/255.255.224.0.

Thankfully, this approach was superseded by a simpler notation: the mask is now denoted with the network address as /. While the notation is easier to read, it does not save us from the equivalent binary exercise! For example, the 172.16.0.0 class B network would be represented as 172.16.0.0/16. The "slash 16" indicates that the first 16 bits, in this case the first two octets, represent the network prefix.

(Continues...)


Excerpted from IP Address Management: Principles and Practiceby Timothy Rooney Copyright © 2011 by the Institute of Electrical and Electronics Engineers, Inc.. Excerpted by permission of John Wiley & Sons. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

"About this title" may belong to another edition of this title.