52-20-32 DATA COMMUNICATIONS MANAGEMENT IP ADDESS CONSEVATION STATEGIES Cliff iggs INSIDE IP Version 6 (FC 2460); Variable-Length Subnet Masking (FC 1812) and Classless Interdomain outing (FC 1519); Private Address Space (FC 1918); Network Address Translation (FC 3022); Dynamic Host Configuration Protocol; Unnumbered Serial Interfaces; Case Study INTODUCTION On September 1, 1981, John Postel published the final version of the Internet Protocol Version 4 (IPv4). This protocol is responsible for addressing the units of data (i.e., packets) used to transmit information from one point to another over the Internet. The Internet at that time consisted of only several thousand hosts. It is a tribute to the design of both IP and its companion, TCP, that 20 years later, the Internet has grown to an astounding 120 million hosts. To send information across the Internet, each of these hosts needs an IP address. Because of this phenomenal growth, the 4.3 billion addresses created by IPv4 have come under increasing strain. In the mid-1990s, the Internet Engineering Task Force (IETF) introduced some guidelines to slow the scarcity of IP addresses until a newgeneration IP could be developed. The IETF meant to allow us to use the addresses that currently exist in a more efficient manner. This article focuses on these improvements and is meant for the network administrator or the manager of an information technology (IT) department. It explores how best design practices can be incorporated into new network design or an existing network. IP VESION 6 (FC 2460) In the mid-1990s, there was a scare that the Internet was running out of addresses. The Internet Protocol PAYOFF IDEA The Internet Protocol Version 4 (IPv4) is responsible for addressing the units of data (i.e., packets) used to transmit information from one point to another over the Internet. In the mid-1990s, the Internet Engineering Task Force (IETF) introduced some guidelines to slow the scarcity of IP addresses until a new-generation IP could be developed. The IETF meant to allow us to use the addresses that currently exist in a more efficient manner. This article focuses on these improvements and explores how best design practices can be incorporated into new network design or an existing network.
Version 6 (IPv6) was the long-term solution to this problem. By increasing the address space from 32 to 128 bits, the addressing problem would no longer exist. IPv6 is an improvement on IPv4 addresses in many ways other than increasing the number of IP addresses available for assignment. Despite these improvements, most networks are still using IPv4 addresses. Why? To begin with, the migration from IPv4 to IPv6 would require an upgrade in the networking software of every host connected to the Internet. This alone, similar to the Y2K issue, would be a phenomenal undertaking. Furthermore, the interim fixes to IPv4 have proven so successful that the existing address space will be sufficient for at least another ten years. Eventually, IPv6 will be here. European and Asian nations that have not been as liberally blessed with IPv4 address space as the United States have already begun implementations. As mobile Internet users begin to outnumber the traditional landline node, major carriers will be forced to adopt IPv6 in their backbones as well. Once this has taken place, widespread adoption of IPv6 will begin. Until that time, the network administrator is forced to rely on the other methods of allocating addresses developed by software vendors and the IETF. VAIABLE-LENGTH SUBNET MASKING (FC 1812) AND CLASSLESS INTEDOMAIN OUTING (FC 1519) To a computer, an IP address is a string of 32 bits. Because humans find exchanging information in this way cumbersome, these 32 bits can be broken down into four groups of eight and represented in decimal form (e.g., 192.168.1.1). Computers divide that string of 32 bits into two parts: the network portion and the host portion. A subnet mask is a way for a computer to tell which of those 32 bits is the network and which of those 32 bits is the host portion of the IP address. For example, 192.168.1.1, with a 16- bit subnet mask represented with the notation /16 tells the computer that 192.168 the first 16 bits is the network portion of that address. The remaining bits, represented by 1.1, is the host ID of a machine on that network. One of the major issues related to the early organization of IP addresses was that of classes. The 32-bit address space was divided into five classes referred to as classes A, B, C, D, and E. The latter two classes are for multicast traffic and experimental use, respectively, and are not typically assigned on a permanent basis to hosts on production networks. Exhibit 1 shows the division of the remaining addresses not assigned to class D and E address space. The original rationalization was that there would generally be very few large organizations that needed IP addresses. Hence, the class A space represented a mere 126 networks. Although
EXHIBIT 1 Classfull IP Addresses Class First Octet Value Bits epresenting Network Bits epresenting Hosts Default Mask Hosts per Subnet Class A 1 126 (e.g., 16.96.152.9) Class B 128 191 (e.g., 130.45.0.15) Class C 192 223 (e.g., 207.106.53.9) Class D 224.0.0.0 239.255.255.255 Class E 240.0.0.0 255.255.255.255 8 24 255.0.0.0 16 million 16 16 255.255.0.0 64,000 24 8 255.255.255.0 254 Multicast group addresses Experimental there were few networks, each network was allowed a total of 16 million hosts. Class B networks were more numerous at approximately 16 thousand, each with approximately 65,000 hosts on each network. Finally, just over two million class C networks were allocated, each with only 254 hosts on each network. Class C networks were designed for the many small organizations that would no doubt wish to connect to the Internet. In the days of classfull IP addresses, the subnet mask was fixed upon during the initial design of the network. The inefficiencies of this scheme were many. The largest subnet of every organization ended up sizing all other subnets. Every time more networks were created, the number of hosts on each network decreased at the same time. Some links (e.g., point-to-point links), which would never have more than two hosts on them by definition, would waste entire subnets. As a result, many of the early networks wasted a great many IP addresses. To combat this problem, the concept of the variable-length subnet mask (VLSM) was introduced. VLSM essentially gave the network designer the ability to create subnets of variable sizes and place them into the network as appropriate. The network could now be broken into subnets, but each subnet could be sized for the number of hosts on the subnet instead of requiring each subnet to be the same size. PIVATE ADDESS SPACE (FC 1918) The scarcity of IP addresses is compounded by inefficient allocation, loss of IP addresses to subnets, and one of the golden rules of IP addressing: each host connected to the Internet must have a unique IP address that is, once 200.1.1.20 is assigned to a particular machine, it cannot be applied anywhere else. To solve this problem, the IETF introduced FC 1918, which, among other things, outlines a range of addresses known as a private address
EXHIBIT 2 Table of Private Addresses per FC 1918 Class A 10.0.0.0 10.255.255.255 10.0.0.0/8 Class B 172.16.0.0 172.31.255.255 172.16.0.0/12 Class C 192.168.0.0 192.168.255.255 192.168.0.0/16 space (see Exhibit 2). Private networks are free to use these addresses as long as they are kept internal to the network. Thus, network A could use the range 172.16.0.0/16 (64,000 addresses) and, across the street, network B could be using the same range. As long as the two networks are never connected, each host on networks A and B has what it believes to be a unique address. The primary advantage of this class of private address space for private networks is that each of these address spaces can be used over and over again. This reuse creates the effect of a virtually unlimited supply of IP addresses. The downfall is that no traffic to these addresses is possible over the Internet. Still, this is an attractive solution for many companies and should be used wherever possible. Networks that consume information instead of provide it find this implementation especially attractive. That is, machines that surf the Web are the perfect choice for the private address range. Servers that serve this Web content, however, are not a good choice. NETWOK ADDESS TANSLATION (FC 3022) Private, reusable IP addresses go a great deal of the way in solving the global shortage of IP addresses, while still allowing network administrators to avoid the pain of actually upgrading to IPv6. Yet the problem remains of how to take an unroutable address used in the private network and get it to work on the public Internet. The answer to that problem is network address translation (). As the name implies, it is possible to create a device that receives a packet with a private address as the source and have it rewrite the address as a public address. Each device, typically a router or firewall, is configured with a pool of addresses in the public range. For example, assume the range is 200.1.1.10 to 200.1.1.20. These ten IP addresses are then used to re-address the source of packets received from the local area network (LAN). When user Mary makes a request from her computer on the LAN to a Web server on the Internet, the device intercepts her packet addressed with the source IP of her machine (192.168.1.45) and rewrites the source as 200.1.1.10. The packet is then routed to the Web server. When the Web server responds, it responds to the 200.1.1.10 address, which makes its way back to the device. This device has kept track that a packet coming from the wide area network (WAN) addressed
EXHIBIT 3 Example of Internet Server IP 200.0.0.1 IP Destination: 202.2.2 Source: 200.0.0.1 3 Server receives packet and replies. 2 device intercepts packet and changes IP header. IP Destination: 200.0.0.1 Source: 202.2.2.2 1 Packet sent. Public IP Address 202.2.2.2 4 Inbound packet intercepted by device and IP header changed. IP Destination: 192.168.1.1 Source: 202.2.2.2 IP Destination: 200.0.0.1 Source: 192.168.1.1 to 200.1.1.10 really is intended for 192.168.1.45. It then rewrites the destination address of the packet and sends it on its way back to Mary s machine. When Mary has finished downloading the Web page, Bob is now free to use the same address, or another from the pool, to create a connection to the Internet. In Exhibit 3, the ten addresses in the pool can be used to represent any number of host machines configured with private IP addresses. The limitation, however, is that because there are only ten IP addresses in the pool, only ten hosts can be using the network at any given time. This limitation is not an issue if there are only 20 people in the office using the pool, and then only to check e-mail or occasionally do some research on the Web; but it becomes a problem if those 20 people are heavy Internet users or if the office grows to 100 people. Instead of allocating more public addresses for the pool to increase the ratio of users/ip addresses, network administrators can take advantage of the fact that although each TCP/IP connection gets to its destination using an IP address, it also uses a TCP port to uniquely identify each connection between hosts. Just as traditionally works on IP addresses, port address translation (PAT) now includes the TCP port number in each connection. With PAT enabled in addition to, both
Mary and Bob can now access the Internet using the 200.1.1.10 address at the same time. This time, the device not only remembers the private address and where it is headed to but also remembers which TCP ports are involved in the translation. Because there are just over 65,000 TCP ports available, suddenly, very few public IP addresses can be used to represent a great many private IP addresses. The technique discussed thus far is known as dynamic. When a LAN host needs an IP address, it is assigned one from the pool as it passes through the device. When the connection is finished, that assignment is returned back to the pool. Because each client can never be guaranteed the same IP address, dynamic is not suitable for machines that must initiate connections (e.g., severs). To create the ability to use on a private LAN yet still allow access from the WAN to the servers, static is an option and can be used in conjunction with dynamic. In addition to the pool of addresses for host workstations, a separate list can be included that reserves a mapping for one private IP address to one public IP address. For example, the mail server with private address 192.168.1.100 will always be translated to 200.1.1.100. Any incoming requests to 200.1.1.100 will automatically be forwarded to the mail server at 192.168.1.100. While is beneficial in that it allows companies to spare large numbers of public IP addresses, some of today s more popular IP applications, specifically voice over IP (VoIP) and, can have problems working with. The crux of the problem is that both of these technologies contain information about the host IP address and ports used inside the IP data packet. and PAT are only smart enough to look at and change the IP packet header, not the data inside the packet. Thus, VoIP and fail if used on a normal device. However, two solutions to the problem exist. The first is to use a device that can look into the packet. Fortunately, this capability is offered on many commercial firewalls and routers, but check the vendor s documentation before making any design decisions. If this is not applicable to a specific network design, the second solution involves strategically placing the device or VoIP gateway to eliminate the incompatibility between and VoIP and (see Exhibit 4). DYNAMIC HOST CONFIGUATION POTOCOL Using and private IP addresses will allow a great deal of flexibility and a reduction in the number of public IP addresses required for any network. Because the private IP address space represents about 18 million IP addresses, organizations are unlikely to run out of IP addresses, for a single location. However, for reasons such as application incompatibility, private addresses might not be suitable. In this case, the network designer will have a difficult time allocating IP addresses if only public addresses are available.
EXHIBIT 4 Placement of Devices for Translation Tunnel Internet Data Perform on Outbound Traffic Prior to Tunnel The Dynamic Host Configuration Protocol (DHCP) is currently in use on most networks. DHCP is used to assign IP addresses dynamically; important configuration information such as gateways, subnet masks, and other network-specific parameters can also be assigned to client host machines. This protocol prevents network administrators from having to manually configure each of hundreds of machines for network access. Furthermore, if there is a change in the address range or other networkspecific parameters (e.g., the default gateway), such a change can be configured on the DHCP server and can be automatically reflected in client machines. DHCP in some instances can also be used to help conserve IP addresses. A pool of IP addresses, much like the pool used in, is entered into the DHCP server. Each time a client boots up on the network, it
sends a request to the server. The DHCP server then leases an IP address from this pool to the client for the duration of its connection to the network. When the client logs off, the IP address is returned to the pool. For groups that are not always connected to the network, DHCP allows a small pool of IP addresses to represent a much larger group similar to the way ISPs allocate dial-in ports. An ISP that has 10,000 subscribers does not have 10,000 ports always available. It may have 1000, or even 500, ports and count on not all subscribers wishing to access the Internet at the same time. DHCP will thus allow a pool of 64 public IP addresses to represent 100 to 200 actual users. This is not very helpful in a typical office environment that is fully staffed each day, but some offices might have portions of the network where a certain percentage of the workforce, such as a salesforce, is absent from the office at any given time. In this case, the DHCP pool can be sized to fit the average number of network users at any given time rather than the entire possible network. UNNUMBEED SEIAL INTEFACES One of the advantages to VLSM (variable-length subnet mask) is that serial interfaces, which never use more than two IP addresses, can be given a subnet of just two hosts. However, because each subnet also needs a virtual address for the network itself and one for the broadcast address of the network, even a point-to-point link will need a total of four IP addresses. While this approach is preferable to allocating a greater number of IP addresses, it is still wasteful. There is a better solution. Because each point-to-point serial link always only connects to its partner, it makes sense not to waste an IP subnet on them at all. Why not program the routers with software that allows point-to-point IP connections without using any IP addresses? Unnumbered serial interfaces do exactly this. outers using unnumbered serial interfaces simply borrow an address from a LAN port that the network administrator designates, such as an Ethernet interface. Used on several serial links, the saved IP addresses per link soon add up to considerable savings. Virtually any interface that creates the appearance of a point-to-point link, such as Frame elay permanent virtual circuits (PVC), are suitable for this technique. In Exhibit 5, each Ethernet port is addressed but the serial links are not. CASE STUDY To put the preceding techniques into action, consider a simple example. A fictional company, Bump, Inc., has recently grown to be a company of 1000 employees. To account for its increasing reliance on E-commerce and the use of the Internet as a communications medium, the company has expanded from one Internet T1 connection to a second. To facilitate this change, the company has had to change its address space from one
EXHIBIT 5 Two outers Connected via a Serial Link Passing IP Data Between Them outers 1 and 2 form a virtual router using the Ethernet interfaces for the serial link endpoints outer 1 outer 2 IP Address 130.45.0.15 IP Address 207.106.53.9 provider to another. As a result of this change, Bump, Inc. now has at its disposal the network 200.1.1.128/25, meaning that it has 128 IP addresses to allocate among 1125 devices user workstations, routers, printers, and servers that need IP addresses. Bump, Inc. has several networks that must be represented using the new IP addresses. It has a collection of 18 servers that must be accessible from the Internet, and this number is anticipated to grow by at least another ten servers within the next two years. Bump, Inc. also has five floors totaling approximately 200 employees in its main office. A network of its own represents each floor. Also on the internal network is another server farm of 15 servers, which might double in size within the next two years as the company expands. To facilitate ad hoc networks in its five conference rooms, the network administrators of Bump, Inc. also wish to create separate networks in each conference room using a combination of workgroup switches and wireless access points. These separate networks will enable distinct security rules to be placed on each of the conference-room to ensure privacy for the conference rooms LAN participants and for the rest of the Bump, Inc. network. Bump, Inc. also has five remote offices. Two of these remote offices are connected via Frame elay links to one of the Bump, Inc. egress routers. The other three offices have independent networks that connect to Bump, Inc. via an tunnel. Each office has between 15 and 35 hosts, including printers and client workstations that might need to access the Internet at some point. Each of the three offices with VPN connections also hosts a pair of servers that relay e-mail and act as a proxy server for World Wide Web (WWW) content, respectively. The first design decision regarding IP address allocation is to employ the use of VLSM. and strategically placed gateways can overcome most of the IP address shortages, but to assign the pools to translation devices in a manner that facilitates efficient usage still requires VLSM. To support this, Bump, Inc. must use a routing protocol that sup-
ports VLSM. For performance reasons, Bump, Inc. has decided to use OSPF because it is an open standard, is easily scalable for the growth needs of the future, supports security, and supports VLSM. Once Bump, Inc. chooses a routing protocol that supports VLSM, it is time to break up the network block. To do this properly, the network administrators of Bump, Inc. must determine what size blocks it will need for each site. Generally, when subnetting networks, first examine the largest subnet that will be needed. In this case, it is the server farm for the externally accessible servers. Because there are 18 servers already, with plans to go to 28 servers within two years time, a block of 30 IP addresses should be adequate. For the remote sites that connect to the main office using a VPN, a block of six IP addresses should be sufficient. Although they have a couple of dozen hosts, because they only have two servers at each site, as long as and PAT is occurring at the WAN edge of the network, there will be enough translated addresses to allow Internet connectivity for the client machines. The simplest solution is to use on the entire portion of the network that only supports the clients and servers not intended to be accessible from the Internet. In most cases, this is done quite simply. All of the private IP addresses are placed behind a single device on the network (most likely a router) and are then treated as an independent network from the point of view of placement of servers and routers. The Bump, Inc. network using this solution is illustrated in Exhibit 6. While viable and certainly conserving IP addresses, this solution suffers from a single point of failure. Were the router performing to fail, the entire private IP addresses space would be unable to contact the Internet, thus effectively eliminating the redundancy hoped for by using a multi-homed WAN connection. As a slightly more complex yet robust solution, two routers can serve as the gateway between the private network and the public network (Exhibit 7). In this case, separate pools are configured on each router, reflecting independent subnets of the Bump, Inc. public IP address space. Thus, if in the previously presented solution the 200.1.1.128/28 network were the pool assigned to the router, those 14 usable IP addresses would be divided into two /27 networks, each representing six usable IP addresses. One /27 network (e.g., 200.1.1.128/27) would be applied to one gateway, and another /27 network (e.g., 200.1.1.136/27) would be applied to the pool on the other gateway router. Traffic from the private network would choose the gateway closest via the OSPF metric and would use for the journey to the Internet and back. While the serial interfaces for the remote sites connected to the Bump, Inc. network could use unnumbered interfaces, and thus conserve IP addresses, this is not required. Because the private address space is being used, it is assumed that sufficient subnets exist.
EXHIBIT 6 The Simple Solution for Bump, Inc. Internet Private Addresses Public Addresses emote VPN Offices Public Servers Private Address emote Frame elay Links To ease the administration of the large number of client machines, the network administrators of Bump, Inc. decide to use DHCP on all host machines. To eliminate the failure of the servers if the DHCP server becomes inoperable, the servers use statically assigned public or private IP addresses. From a global perspective, Bump, Inc. now has a network design that facilitates its growth for the foreseeable future. Although it was only assigned 128 IP addresses for a company of over 1000 hosts, through the use of VLSM and, all major design objectives have been met for the company regarding IP addresses.
EXHIBIT 7 More Complex Yet obust Solution for Bump, Inc. Internet Private Addresses Public Addresses emote VPN Offices Private Addresses Public Servers Serial Unnumbered emote Frame elay Links CONCLUSION The address shortages forecast in the mid-1990s have not materialized. While the total number of IP addresses has not increased, thanks to the efforts of the IETF, we have learned to use those existing addresses more efficiently. While this has allowed networks and the Internet itself to continue to grow over the last half-decade, the address allocation methods described in this article have become so efficient that the impetus to move to the real solution IPv6 has slowed somewhat. Thus, network administrators will be expected to make use of the strategies listed above to enable their network to maintain Internet connectivity during the near future.
Some helpful references for determining the operation of these protocols are listed below. IPv6: IPv6 FC 2460 is a good start for the technically curious. It can be found, among other places, at ftp://ftp.isi.edu/in-notes/rfc2460.txt. For information on the latest news concerning IPv6, link to http://www.ipv6forum.com/. IP Addressing and subnetting: If you are concerned that you have lost your edge on the ins and outs of IP addressing, then you need look no further than the best reference on the subject found anywhere: http://www.3com.com/solutions/en_us/ncs/501302.html. VLSM: FC 1812, equirements for IP outers, at ftp://ftp.isi.edu/in-notes/rfc1812.txt The Private IP address space: FC 1918, Address Allocation for Private Internets, at ftp://ftp.isi.edu/in-notes/bcp/bcp5.txt : FC 3022, Traditional Network Address Translation, at ftp://ftp.isi.edu/in-notes/rfc3022.txt DHCP FC 2131, Dynamic Host Configuration Protocol, at ftp://ftp.isi.edu/in-notes/rfc2131.txt Cliff iggs, CCDP, CCNP, MCSE+I, is a member of the technical staff at Hill Associates, an internationally recognized telecommunications training company, has a master s degree in education and specializes in IP routing and security issues for Hill Associates. He can be reached via e-mail at criggs@hill.com.