IP ADDRESS CONSERVATION STRATEGIES

13  Download (0)

Full text

(1)

DATA COMMUNICATIONS MANAGEMENT

IP A

DDRESS

C

ONSERVATION

S

TRATEGIES

Cliff Riggs

I N S I D E

IP Version 6 (RFC 2460); Variable-Length Subnet Masking (RFC 1812) and Classless Interdomain Routing (RFC 1519); Private Address Space (RFC 1918); Network Address Translation (RFC 3022);

Dynamic Host Configuration Protocol; Unnumbered Serial Interfaces; Case Study

INTRODUCTION

On September 1, 1981, John Postel published the final version of the In-ternet Protocol Version 4 (IPv4). This protocol is responsible for address-ing 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 astound-ing 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) intro-duced 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 fo-cuses on these improvements and is

meant for the network administrator or the manager of an information technology (IT) department. It ex-plores how best design practices can be incorporated into new network design or an existing network.

IP VERSION 6 (RFC 2460)

In the mid-1990s, there was a scare that the Internet was “running out of addresses.” The Internet Protocol

P A Y O F F I D E A

The Internet Protocol Version 4 (IPv4) is respon-sible for addressing the units of data (i.e., pack-ets) used to transmit information from one point to another over the Internet. In the mid-1990s, the Internet Engineering Task Force (IETF) intro-duced some guidelines to slow the scarcity of IP addresses until a new-generation IP could be de-veloped. The IETF meant to allow us to use the ad-dresses that currently exist in a more efficient manner. This article focuses on these improve-ments and explores how best design practices can be incorporated into new network design or an existing network.

(2)

Version 6 (IPv6) was the long-term solution to this problem. By increas-ing the address space from 32 to 128 bits, the addressincreas-ing 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 assign-ment. Despite these improvements, most networks are still using IPv4 ad-dresses. 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 phenom-enal undertaking. Furthermore, the interim fixes to IPv4 have proven so successful that the existing address space will be sufficient for at least an-other 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, wide-spread 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.

VARIABLE-LENGTH SUBNET MASKING (RFC 1812) AND CLASSLESS INTERDOMAIN ROUTING (RFC 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 address-es was that of classaddress-es. The 32-bit addraddress-ess 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 typi-cally 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 address-es. Hence, the class A space represented a mere 126 networks. Although

(3)

there were few networks, each network was allowed a total of 16 million hosts. Class B networks were more numerous at approximately 16 thou-sand, 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 design-er 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 in-stead of requiring each subnet to be the same size.

PRIVATE ADDRESS SPACE (RFC 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 RFC 1918, which, among other things, outlines a range of addresses known as a private address

EXHIBIT 1 — Classfull IP Addresses

Class First Octet Value

Bits Representing

Network

Bits Representing

Hosts Default Mask Hosts per Subnet

Class A 1–126 (e.g., 16.96.152.9) 8 24 255.0.0.0 16 million Class B 128–191 (e.g., 130.45.0.15) 16 16 255.255.0.0 64,000 Class C 192–223 (e.g., 207.106.53.9) 24 8 255.255.255.0 254 Class D 224.0.0.0– 239.255.255.255 Multicast group addresses Class E 240.0.0.0– 255.255.255.255 Experimental

(4)

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, net-work B could be using the same range. As long as the two netnet-works 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 pri-vate 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 informa-tion instead of provide it find this implementainforma-tion 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.

NETWORK ADDRESS TRANSLATION (RFC 3022)

Private, reusable IP addresses go a great deal of the way in solving the global shortage of IP addresses, while still allowing network administra-tors to avoid the pain of actually upgrading to IPv6. Yet the problem re-mains 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 (NAT). 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 NAT 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-ad-dress 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 NAT device intercepts her packet ad-dressed 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 NAT device. This NAT device has kept track that a packet coming from the wide area network (WAN) addressed

EXHIBIT 2 — Table of Private Addresses per RFC 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

(5)

to 200.1.1.10 really is intended for 192.168.1.45. It then rewrites the des-tination address of the packet and sends it on its way back to Mary’s ma-chine. 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 con-nection to the Internet.

In Exhibit 3, the ten addresses in the NAT pool can be used to repre-sent 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 us-ing the pool, and then only to check e-mail or occasionally do some re-search 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 NAT pool to in-crease 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 iden-tify each connection between hosts. Just as NAT traditionally works on IP addresses, port address translation (PAT) now includes the TCP port number in each connection. With PAT enabled in addition to NAT, both

EXHIBIT 3 — Example of NAT

NAT device intercepts packet and changes IP header.

Server receives packet and replies.

Inbound packet intercepted by NAT device and IP header changed. Destination: 192.168.1.1 Source: 202.2.2.2 IP Destination: 202.2.2 Source: 200.0.0.1 Destination: 200.0.0.1 Source: 202.2.2.2 IP IP Destination: 200.0.0.1 Source: 192.168.1.1 IP Packet sent. Public IP Address 202.2.2.2 4 2 1 3 Server IP 200.0.0.1 Internet

(6)

Mary and Bob can now access the Internet using the 200.1.1.10 address at the same time. This time, the NAT device not only remembers the pri-vate 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 NAT. When a LAN host needs an IP address, it is assigned one from the pool as it pass-es through the NAT device. When the connection is finished, that assign-ment is returned back to the pool. Because each client can never be guaranteed the same IP address, dynamic NAT is not suitable for ma-chines that must initiate connections (e.g., severs).

To create the ability to use NAT on a private LAN yet still allow access from the WAN to the servers, static NAT is an option and can be used in conjunction with dynamic NAT. 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 NAT is beneficial in that it allows companies to spare large numbers of public IP addresses, some of today’s more popular IP appli-cations, specifically voice over IP (VoIP) and IPSec, can have problems working with NAT. The crux of the problem is that both of these technol-ogies contain information about the host IP address and ports used in-side the IP data packet. NAT and PAT are only smart enough to look at and change the IP packet header, not the data inside the packet. Thus, VoIP and IPSec fail if used on a normal NAT device.

However, two solutions to the problem exist. The first is to use a NAT device that can look into the packet. Fortunately, this capability is offered on many commercial firewalls and routers, but check the vendor’s docu-mentation before making any design decisions. If this is not applicable to a specific network design, the second solution involves strategically plac-ing the IPSec device or VoIP gateway to eliminate the incompatibility be-tween NAT and VoIP and IPSec (see Exhibit 4).

DYNAMIC HOST CONFIGURATION PROTOCOL

Using NAT 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 mil-lion IP addresses, organizations are unlikely to run out of IP addresses, for a single location. However, for reasons such as application incompat-ibility, 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.

(7)

The Dynamic Host Configuration Protocol (DHCP) is currently in use on most networks. DHCP is used to assign IP addresses dynamically; im-portant configuration information such as gateways, subnet masks, and other network-specific parameters can also be assigned to client host ma-chines. 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 network-specific parameters (e.g., the default gateway), such a change can be configured on the DHCP server and can be automatically reflected in cli-ent machines. DHCP in some instances can also be used to help con-serve IP addresses.

A pool of IP addresses, much like the pool used in NAT, is entered into the DHCP server. Each time a client boots up on the network, it

EXHIBIT 4 — Placement of IPSec Devices for NAT Translation

Internet IPSec T unnel Data NAT R NAT R Perform NAT on Outbound Traffic Prior to IPSec Tunnel

(8)

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 net-work. 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 work-force, such as a saleswork-force, is absent from the office at any given time. In this case, the DHCP pool can be sized to fit the average number of net-work users at any given time rather than the entire possible netnet-work. UNNUMBERED SERIAL INTERFACES

One of the advantages to VLSM (variable-length subnet mask) is that se-rial 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 ad-dresses. 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 connec-tions without using any IP addresses? Unnumbered serial interfaces do exactly this.

Routers 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 Relay per-manent 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

(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 an-other 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 secu-rity 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 Relay links to one of the Bump, Inc. egress rout-ers. The other three offices have independent networks that connect to Bump, Inc. via an IPSec 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. NAT and strategically placed gateways can overcome most of the IP address shortages, but to assign the NAT pools to transla-tion devices in a manner that facilitates efficient usage still requires VLSM. To support this, Bump, Inc. must use a routing protocol that

sup-EXHIBIT 5 — Two Routers Connected via a Serial Link Passing IP Data Between Them Router 1 Router 2 IP Address 130.45.0.15 IP Address 207.106.53.9 Routers 1 and 2 form a virtual

router using the Ethernet interfaces for the serial link endpoints

(10)

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 ad-ministrators 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 ad-dresses 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. Al-though they have a couple of dozen hosts, because they only have two servers at each site, as long as NAT and PAT is occurring at the WAN edge of the network, there will be enough translated addresses to allow Inter-net connectivity for the client machines.

The simplest solution is to use NAT on the entire portion of the net-work that only supports the clients and servers not intended to be acces-sible from the Internet. In most cases, this is done quite simply. All of the private IP addresses are placed behind a single NAT device on the work (most likely a router) and are then treated as an independent net-work 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 suf-fers from a single point of failure. Were the router performing NAT to fail, the entire private IP addresses space would be unable to contact the In-ternet, 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 ( Ex-hibit 7). In this case, separate NAT 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 NAT router, those 14 usable IP ad-dresses 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 NAT pool on the other gateway router. Traffic from the private network would choose the gateway closest via the OSPF metric and would use NAT 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 ad-dresses, this is not required. Because the private address space is being used, it is assumed that sufficient subnets exist.

(11)

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 be-comes 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 as-signed 128 IP addresses for a company of over 1000 hosts, through the use of VLSM and NAT, all major design objectives have been met for the company regarding IP addresses.

EXHIBIT 6 — The Simple Solution for Bump, Inc.

Internet NAT R R R R R IPSec NAT IPSec NAT IPSec NAT IPSec Public Addresses Private Address Public Servers Remote Frame Relay Links Remote VPN Offices Private Addresses

(12)

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 impe-tus 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.

EXHIBIT 7 — More Complex Yet Robust Solution for Bump, Inc.

Internet NAT R R R R R IPSec NAT IPSec NAT IPSec NAT IPSec Public Addresses Private Addresses Public Servers NAT IPSec Remote Frame Relay Links Remote VPN Offices Private Addresses Serial Unnumbered

(13)

Some helpful references for determining the operation of these proto-cols are listed below.

• IPv6:

– IPv6 RFC 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:

– RFC 1812, Requirements for IP Routers, at ftp://ftp.isi.edu/in-notes/rfc1812.txt • The Private IP address space:

– RFC 1918, Address Allocation for Private Internets, at ftp://ftp.isi.edu/in-notes/bcp/bcp5.txt

• NAT:

– RFC 3022, Traditional Network Address Translation, at ftp://ftp.isi.edu/in-notes/rfc3022.txt

• DHCP

– RFC 2131, Dynamic Host Configuration Protocol, at ftp://ftp.isi.edu/in-notes/rfc2131.txt

Cliff Riggs, CCDP, CCNP, MCSE+I, is a member of the technical staff at Hill Associates, an internationally recog-nized 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.

Figure

Updating...

References