Chapter 15: IP Address Management: Working with IPv4 and IPv6

Introduction

Sustained exponential growth of the Internet and increasing use if TCP/IP technology within Intranets is exhausting the existing IP address space. A separate and far more pressing concern is that the amount of routing overhead will grow beyond the capabilities of Internet Service Providers (ISPs) and the available hardware. Every new IP network added to the Internet requires a new network access point (NAP) routing table entry. A NAP is an Internet hub where national and international ISPs connect with one another. A NAP router has to know about every network on the Internet.

This chapter briefly:

• Introduces some reasons for renumbering network components and briefly discusses some Internet Architecture Board (IAB) recommendations to make renumbering more feasible
• Summarizes some renumbering strategies to consider as you plan your transition to IPv6.
• Very briefly summarizes the use of subnetting as a method for dealing with the shortage of IP addresses. Subnetting consists of taking a block of IP addresses assigned to a network and dividing and spreading out those addresses among separate, often variable length smaller networks.
• Introduces Classless Inter-Domain Routing (CIDR) as a way to consolidate addresses and minimize the number of routing table entries. The CIDR address structure accomplishes this by allowing the aggregation of routes to reduce the pressure on the global Internet routers.
• Describes the use of private networks as a way to reduce the impact of changing the addressing scheme and migrating to IPv6. When you have a private network, the entire network is built from unregistered IP addresses.
• Discusses using the Dynamic Host Configuration Protocol for handling IP addressing for a number of computers using a smaller number of actual address.
• Briefly describes how Vitual Local Area Networks (VLANS) and DHCP effect addressing and routing issues within and across domains.
• Briefly introduces Network Address Translator (NAT) as an alternative method of address management that could help cross the bridge between IPv4 and IPv6. ) Using a NAT implementation for address management allows you to reuse IP addresses when connecting private network hosts to the internet. A NAT implementation also helps with address renumbering issues when changing ISPs or migrating an enterprise to IPv6.
• Provides a short list of companies that have IP address management tools and utilities that you might be able to use.

The internet community is developing and implementing short-term and long-term solutions to these problems. As a result, today network administrators have a number of options for: dealing with the shortage of address space, minimizing the impact on routing overhead as their networks grow in size and complexity, and setting up an IP addressing scheme for their networks so the transition to IPv6 has minimal impact. All these options include renumbering network hosts and routers in one way or another.

These option include the use of:

• Subnetting
• Classless Inter-Domain Routing (CIDR)
• Private networks
• Dynamic Host Configuration Protocol (DHCP)
• Virtual Local Area Networks
• Network Address Translator (NAT)

Minimizing the actual number of IP address that might be needed within an organization could be done by reusing addresses (NAT) or dynamically assigning addresses when a host connects to the network (DHCP). Networks that have a small percentage of hosts that communicate outside their domain at the same time are likely candidates for address reuse.

One of the most important things a network administrator can do now to make the transition to IPv6 smoother is to make sure their networks support and use CIDR addressing. When you convert to CIDR addressing, if at all possible make all your address part of one contiguous block.

The development of IPv6 with its larger addresses provides a long term solution to the IP addressing issues. Organizations could use IPv4-to-IPv6 tunneling for the mid-term and even for the long term when the organization cannot justify the effort to migrate to IPv6.

Renumbering network components

An IP address identifies hosts in an IP network. Routing protocols advertise the, IP address prefixes of subnets. Changing any IP addressing information associated with a host or subnet is known as renumbering. Renumbering or changing the IP addressing information of network components is becoming more and more common. Tools and protocols are needed that make such changes easier to effect.

Renumbering occurs for a variety of reason including:

• Moving an IP host from one subnet to another — This can require renumbering the host.
• Physically splitting a subnet due to traffic overload — This can require renumbering the subnet.
• An organization changes its addressing plan or Internet Service Provider (ISP) — This can require changing the hosts' addresses and the subnet numbers as well.

Renumbering will be needed by organizations that require connectivity with the Internet when the organizatgion does not provide sufficient address information aggregation. The continued use of Classless Inter-Domain Routing (CIDR) is important for the continuous uninterrupted growth of the Internet both during and after IPv6 transition.

CIDR requires the use of addresses belonging to a single large block of address space. ISPs act as aggregators for these addresses. This strategy helps contain the growth of routing information. IP address changes need to occur when an organization changes to a new ISP or an ISP changes to a new and larger block of address space.

When such changes are made and the organization does not renumber then the organization may experience either one or both of the following conditions:

• Limited IP connectivity to the Internet
• Extra cost to offset the overhead associated with the organization's routing information that ISP has to maintain, or both.

Renumbering usually requires advanced planning and the services of experts. Additionally, renumbering can be costly, tedious and prone to errors. There are few tools available to facilitate the task and little or no documentation that describes the procedures. The good news is that this situation seems to be improving somewhat.

Address and name spaces

You can identify individual hosts by the IP address assigned to the network interface on that host. A specific host could have several network interfaces and therefore, several IP addresses. The IP address space is usually associated with the mechanisms of addressing and routing.

The Domain Name System (DNS) associate legible names with IP addresses. The DNS name space and IP address space are independent of each other. DNS names are usually associated with the ownership and function of the host.

Changing a DNS name usually indicates a real change in ownership or function. Changing an IP address usually indicates a technical event. A big advantage to the DNS is that using it eliminates dependence on a centrally-maintained file that maps host names to addresses. Using domain names means you can defer binding between a network entity and its IP address until run time. Deferring the binding helps to avoid the risk of changed mapping between IP addresses and specific network nodes.

Enterprise domain names and fully qualified domain names (FQDNs) are expected to be long-lived, and more stable than IP addresses. A FQDN is a domain name that includes all higher level domains relevant to the specific entity. For example, if you think of the DNS as a tree-structure and each node has its own label, then a FQDN for a specific would consist of its label followed by the labels of all the other nodes between it and the root of the tree.

Reliance on FQDNs instead of IP addresses. localizes to the DNS the changes needed to deal with changing addressing information due to renumbering.

Internet Architecture Board recommendations for easy renumbering

To make renumbering more feasible, the Internet Architecture Board (IAB) recommends designers and developed do the following:

• Minimize the cases in which IP addresses are stored in non-volatile storage maintained by humans, such as configuration files.
• Express configuration information used by TCP/IP protocols in terms of FQDNs rather than IP addresses.
• Avoid hardcoding IP addresses into applications and avoid using files that contain lists of name to address mappings. This recommendation does not apply to lists of name to address mappings that are used as part of DNS configuration.
• Some legacy applications require configuration files with IP addresses. In this case, generate the configuration files from another file that uses Domain Names and substitute the addresses by using lookup in the DNS.
• Avoid using licensing technology that is based upon the IP address of a host system.
• Help with the development and deployment of a toolkit to facilitate and automate host renumbering. Such a toolkit would include such things as the Dynamic Host Configuration Protocol (DHCP), dynamic router discovery, and support for dynamic update capabilities to the DNS.
• Share your experience with renumbering and documenting this sharing within the Internet community.

The PIER (Procedures for Internet and Enterprise Renumbering) working group solicits and organizes input from Internet community. RFC 1916 is the first output from this work. A couple of internet drafts are in the works. There are also other guidelines in the planning stages. PIER encourages and welcomes participation and comments. Send comments to pier@isi.edu.

Some renumbering strategies

Renumbering is the process of changing the IP addresses for a network or administrative domain and all the machines in it. Renumbering your network could be a small task or it could be a very large and complex task. A network administrator might consider renumbering the network: to facilitate newer technologies or growth of a network and to respond to the demands of an upstream entity, such as an ISP to renumber.

Some providers are asking their clients to use addresses already assigned to the ISP. This reduces the number of prefixes in the Internet routing system.

Preparing to renumber checklist

The ability to quickly renumber is important. Collecting techniques and tools for supporting renumbering IP hosts should be considered a part of ongoing network design. The two worst environments for renumbering are flat routing of 32bit prefixes and periodic, dynamic renumbering across the entire address space. Keep in minds the following:

1. Good design facilitates renumbering

• Centralize your network service and use DHCP Servers and routers
• Make sure you implement a solid software distribution method
• Avoid using classfull routing protocols such as RIP
• Make sure your routing protocol implementation provides route advertisements
• Catalog all files that require hardcoded addresses such as NTP configurations and static host list.
• Use names instead of numbers where ever possible.

1. Good techniques facilitate renumbering legacy hosts

• Weigh the cost and benefits renumbering would accrue, making sure at the same time to give yourself plenty of time to actually renumber the network. Keep in mind that some sections of the network might take longer to renumber than other and some large sections might need to be renumbered in a short period of time.
• Decide on a new numbering policy including considering changing subnet masks and the implementation of broadcast and multicast addressing.
• Pay special attention to security issues and access control lists as your renumber your network. Change access control lists as appropriate to your network.
• Consider changing the network topology if you need to
• Implement DHCP, routers, and secondary addresses. Ensure your routers have the new prefixes as secondary or primary addresses. It is possible that deleting a primary address also deletes the secondary address.
• Use DNS as a migration tool but first change timeouts, update the local zone generation scripts, and notify your DNS secondaries.
• Identify any software that uses IP addresses for licensing.

1. Good public relations within and outside the organization makes renumbering easier

• Get management acceptance and buy-in from your users.
• Provide them with a realistic timetable so they can pan their activities accordingly.
• Provide your users with information about the changes, and how those changes might effect the way they do business
• Coordinate your renumber activities with your offsite support services and provides such as DNS secondaries, NNTP feeds, and NTP servers.

Developing the renumbering plan

There are several preliminary steps you should take before you proceed to renumber:

1. Identify the scope of the project.

Each network, each device on that network, and each network to which it connects must be inventoried and designated.

2. Identify the numeric boundaries of the renumbering plan.

After renumbering is completed, you need to know the ranges of IP addresses in use at any time. You could simply need to renumber one block of addresses to another block of addresses. But, you might also need to renumbering a block of addresses into the same block of addresses with a different network topology. In this case, the order in which you renumber can determine success or failure of the project.

3. Identify the new network topology if any.

If there is a change in network topology, make sure you have your plan in place before you make any changes.

4. Identify the components in detail

When developing a renumbering plan you need to identify all the elements on the network and group devices into like groups. The following list is an example of a set of groupings.

• Routers
• Infrastructure Devices such as Bridges, Terminal Servers, Gateways, and Firewalls
• Application Servers such as DNS, Mail Server, News Servers, FTP Servers, WWW Servers, and Network Management Systems
• End User Systems.

Each operating system and hardware platform has distinctions that can help or hinder its ability to renumber gracefully. For example, some routers allow multiple IP addresses on the same interface. This means that the old and new addresses could be in operation at the same time.

5. Create a network IP address map

This is an IP address map between the old and new IP addresses. You can use this map as a aid when renumbering and as a bridge backwards if for any reason there are problems or you need to translate historical data to the current topology.

6. Put as much planning and resources into the project as possible

Updating such things as the operating systems, hardware devices, firmware and cabling might be necessary when you renumber. Plan you new system with growth and flexibility to change in mind.

7. Develop a plan for updating online and offline documentation

Every system on your network has some sort of online documentation. This could simply be referential documentation such as a hosts file, or it could be documentation about a network node along with all its interfaces and services. Whether it simple or complex documentation, it needs to be updated as part of the renumbering process. Note:

• You can usually use a mapping table to convert the information in ASCII documents or documents stored in a database.
• Significant manual intervention may be required when the IP addresses are embedded in a binary document such as a word processor or spreadsheet file.
• Numerous offline documents could contain IP numbers. Scan all offline documents and update hardcoded IP addresses.

You might fined hardcoded IP address in the following types of offline documentation:

• System setup information
• Disaster recovery plans
• End user documentation
• Network maps
• Dialing instructions
• Numbering schemes
• List of network resources such as DNS servers, gateways, and Database servers.

Tips and resources

If you are considering changing to a DHCP/bootp there are a number of DCHP FAQ pages available include a good one at http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html

If, you have extra address and want to turn them back, send email to Hostmaster@InterNIC.net, indicating that you want to return address space.

Subnet addressing

When you apply to the Network Information Center (NIC) for an address, you receive one or more IP addresses. There are actually three parts an IP address, the network part, the subnet part that may or may not exist, and the host part. Note that when many people refer to the "network" part they are actually referring to a combination of the network part and the subnet part. You can assign hosts to the network number in any way that is appropriate for your organization or network design.

For example, lets say the NIC has assigned you the network number 129.46.0.0. In this case you have a class B network number (those in the range of 128.x.y.z to 191.x.y.z.). You are free to do whatever you want with the "y" and "z" portions of the network number but you cannot do anything with the "x" portion of the network number because it belongs to someone else.

Likewise, if you have a class C network number (those in the range of 192.x.y.z to 223.x.y.z), you can do anything you want with the "z" portion of the address. However, you cannot do anything with the "x" or "y" portions of the network address because they belong to somebody else.

In our example we have 16 node number bits which translates into 64,000 node addresses. That is a large network. Most organizations would break up a network of this size into a number of smaller physical networks.

Installing routers rather than bridges on this sample network breaks it up into a number of physical networks. Two or more physical networks connected by routers have to be separate and distinct logical networks. Subnet addressing using a subnet mask allows you to use this one IP network address (129.46.0.0) to define and identify multiple physical/logical networks. A subnet mask tells IP to ignore the standard addressing rules. You extend the network address when you configure an address to use a subnet number.

Configuring a subnet mask

Using our example, the NIC has assigned us a network number of 129.46.0.0. The network number portion of this address uses 16 bits. We want 100 physical networks (subnetwork) with a maximum of 250 host on each subnetwork. We have 16 bits left to use to identify our subnets and hosts on those subnets. Using 8 host bits we can identify 255 hosts on a particular network. This means we only need 8 host number bits to identify a particular host on any one of our subnets and we can use the 8 remaining bits for our subnet numbers. A logical representation of our network address might look like .

When you configure a subnet mask, do the following

• Decide how may bits to use for the subnet number.
• Set the bit position to 1 for every bit position in the IP address that you want to be part of the network or subnet number.
• Set the bit position to 0 for every bit position in the IP address that you want to be part of the host or node

Following this procedure results in a 32-bit number that you can then write in dotted decimal notation. In our example 8 bits represent the subnet number, 8 bits represent a host number, and the subnet mask value would be 255.255.255.0.

shows creating some binary subnet masks and then interpreting the IP addresses.

Classless Inter-Domain Routing overview and issues

Classless Inter-Domain Routing (CIDR) is an addressing consolidation and routing plan for the Internet. CIDR reduces the pressure on the Internet's core routers and provides a more efficient allocation of IP addresses than the old Class A, B, and C address scheme.

CIDR provides for:

• Hierarchically allocating IP address assignment by delegating control of segments of the IP address space to the various network service providers.
• Hierarchical routing aggregation to minimize route table entries

Implementing CIDR assumes the use of variable length subnet masks (VSLM) routing technology for interior (Intranet) routing and CIDR capable routing technology for exterior routing.

Organizations that operate as Internet Service Providers (ISPs) are expected to be able to support VLSM and CIDR capable routing protocols.

NOTE: The Routing Arbiter Project, located at http://www.ra.net, is a collaboration between Merit and ISI provides tools, databases, documentation, and assorted information including methods for determining how a network address is announced by core routers.

Routing protocol support

The interior routing protocols that support CIDR are: OSPF, RIP II, Integrated IS-IS, and E-IGRP.

The exterior routing protocol that supports CIDR is BGP-4. Protocols like RIP I, BGP-3, EGP, and IGRP do not support CIDR.

Domains

You can think of the global Internet as a collection of hosts connected together through transmission and switching facilities. Control of these facilities is distributed among multiple administrative authorities.

Resources under control of a single administration form a domain. Domains that share their resources with other domains are providers or network service providers. Domains that use other domain's resources are subscribers of network services. A given domain can act as a provider and a subscriber simultaneously.

IP address allocation within the Internet effects routing within a routing domain (intra-domain routing) and routing between routing domains (inter-domain routing).

Individual routing domains such as corporate domains, connect to transit domains such as a regional service provider domain. Transit routing domains carry inter domain traffic.

There are two kinds of transit routing domains; direct service providers and indirect service providers. Most of the subscribers of a direct service provider are domains that act solely as service subscribers and carry no transit traffic. Most of the subscribers of an indirect service provider are domains that, themselves, act as service providers. In present terminology a backbone is an indirect service provider. A transit routing domain (TRD) is a direct service provider.

The CIDR protocol

Essential to CIDR is the concept of variable length subnet masks (VLSM) and the decreased use or elimination of classes of network numbers. CIDR provides for delegating pieces of what used to be called network numbers to customers. This makes it possible to utilize the available address space more efficiently. CIDR eliminates the concept of network classes and replaces class A, B, and C networks with an IP prefix.

CIDR also supports route aggregation where a single route can cover the address space of several old-style network numbers. This means a single route can replaces a lot of old routes. This can:

• Save routing table space in all backbone routers
• Reduce rapid changes in routes (referred to a route flapping) in all backbone routers

IP prefixes and addressing in CIDR

Using the old Class A, B, and C addressing scheme the Internet could support:

• 126 Class A networks that could include up to 16,777,214 hosts each
• Plus 65,000 Class B networks that could include up to 65,534 hosts each
• Plus over 2 million Class C networks that could include up to 254 hosts each

Classless Inter-Domain Routing (CIDR) replaces the old process of assigning Class A, B and C addresses with a generalized network prefix referred to as an IP prefix. CIDR addresses reduce the size of routing tables and make more IP addresses available within organizations. With CIDR, you can use a single IP address to designate many unique IP addresses.

A CIDR IP address looks like a normal IP address except that it ends with a slash followed by a number. This is called the IP prefix. An IP prefix consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. The mask length indicates how many addresses the CIDR address covers. The lower the prefix number, the more address it covers.

For example, CIDR address 192.21.01.48/27, the /27 indicates the first 27 bits identify the unique network number that in turn indicates the size of the address space. Put another way, /27 indicates that there are 2²⁷ -2 networks available. The remaining bits identify the specific host.

Instead of limiting network identifiers or prefixes to 8, 16 or 24 bits, CIDR currently uses prefixes anywhere from 1 to 32 bits. You can assign blocks of addresses for networks as small as 32 hosts up to networks with over 500,000 hosts. This allows you to establish address assignments that much more closely fit your organizations specific needs.

TIP: If you are an administrator of an Autonomous System (AS), it is a good idea to announce as few prefixes as possible and to use the address space as much as possible. If you advertise a prefix that covers less address space than a /24 prefix, that prefix will probably not get into the global routing tables. An Autonomous System as a collection of CIDR IP address prefixes under common technical management.

RFC 1878 by T. Pummill and B. Manning lists the variable length subnets from 1 to 32 as shown in . It shows the CIDR representation form (/xx), the Decimal equivalents, the equivalent number of traditional A, B, and C class values, and the equivalent number of classfull addresses represented by the prefix (M = Million, K=Thousand, A,B,C= traditional class values).

Special IPaddress conventions

Some IP addresses are used for special purposes (). In these cases a network or host part containing all 0s means 'this', while all 1s means 'all'.

Variable length subnet masks

When you assign more than one subnet mask to an IP network, the network is considered a network with variable length subnet masks. This is because the extended-network-prefixes have different lengths.

Some routing protocols, such as RIP I, do not provide for variable length subnet masks. If a routing protocol does not provide subnet mask information as part of its routing table update message only a single subnet mask can be used across the entire network-prefix. This means that when you select the mask, you lock the organization into a fixed-number of fixed-sized subnets.

The ability to assign more than one subnet mask to a given IP network number provides several advantages:

• Multiple subnet masks permit more efficient use of an organization's assigned IP address space.
• Multiple subnet masks permit route aggregation. Route aggregation can significantly reduce the amount of routing information at the backbone level within an organization's routing domain.

Route aggregation

The CIDR addressing scheme enables route aggregation in which a single high-level route entry can represent many lower-level routes in the global routing tables. CIDR aggregates blocks of addresses.

A specific ISP serves all the addresses within a block as an Autonomous System (AS). ASs exchange routing information using the BGP routing protocol. Within each AS, routers continue to update one another using traditional routing protocols such as RIP II, OSPF, and IS-IS.

Hierarchical routing aggregation minimizes routing table entries

Currently, the large Internet Service Providers (ISPs) receive big blocks of address. The ISPs then re-allocate portions of their address blocks to their customers.

For example, XYZ net might be assigned a CIDR address block with a prefix of /15 (equivalent to 512 Class C addresses or 131,072 host addresses). XYZ net could then its customers CIDR addresses with prefixes ranging from /27 to /19. Some of these customers could be smaller ISPs. These ISPs would reallocate portions of their address block to their customers.

However, in the global routing tables the single XYZ net route entry represents all these different networks and hosts. Using CIDR addressing significantly reduces the number of routing table entries at each level in the network hierarchy.

Renumbering IP addresses

In the past, when you got a Class A, B, or C address assignments from the InterNIC, you owned the address. You could take the address with you if you changed ISPs.

With CIDR and route aggregation, the recommended source for address assignments is your ISP. Under this scenario, you only rent the address. This means you may have to renumber you IP addresses if you change ISPs. If your addresses came from your original ISPs CIDR block, you will probably have to return those addresses as part of your move to a new ISP.

Renumbering can be a time consuming task. It is important for your address to be aggregated into your ISP’s larger address block and routed under their network address. The smaller your network, the greater your risk of being dropped from the global routing tables.

As an option to physically re-numbering each network device, some organizations use proxy servers to translate old network addresses to their new addresses. Make sure you consider all the potential impacts before using this type of solution.

When to carry the full routing table

Generally you do not need to carry the full Internet routing table. If you have a single connection (single homed) to an ISP point a default route to the ISP and tell your ISP not to send you the full routing table.

If you have connections to more than one ISP (multihomed), you need to know which networks to route through each ISP. Your routing tables only needs to contain a small subset of the Internet routing tables. To accomplish this:

• Request a partial routing table from one ISP that contains the network closest to the ISP.
• Default everything else to the other ISP.

The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, if you connect to public exchange points you will generally need to carry the full routing tables and run without a default route.

User impacts

The Internet is currently a mixture of both CIDR style addresses and old Class A, B and C addresses. Almost all new routers support CIDR and the Internet authorities strongly encourage all users to implement the CIDR addressing scheme. Any new router you purchase should support CIDR.

The conversion to the CIDR addressing scheme and route aggregation has two major user impacts:

• Justifying IP Address Assignments
• Where To Get Address Assignments

Justifying IP address assignments

Even with CIDR, the Internet is growing so fast that address assignments continue to be treated as a scarce resource. As a site, you might be required to document:

• Your projected IP address needs
• Your internal address assignments, particularly when requesting additional addresses.

The current Internet guideline is to assign addresses based on an organizations projected three month requirement with additional addresses assigned as needed.

Where to get address assignments

In the past, you would get a Class A, B or C address assignments directly from the appropriate Internet Registry. You owned the address. If you changed your ISP you kept your address.

With the introduction of CIDR address assignment and route aggregation, you obtain your address assignments from your ISP. In effect, you are only renting the address. If you change ISPs it is strongly recommended that you get a new address from your new ISP and re-number all of your network devices.

While this is can be a time consuming task, it is critical for your address to be aggregated into your ISP's larger address block and routed under their network address. There are still significant global routing table issues and the smaller your network is, the greater your risk is of being dropped from the global routing tables. In fact, networks smaller than 8,192 devices will very likely be dropped. Neither the InterNIC nor other ISPs have control over an individual ISP's decisions on how to manage their routing tables.

As an option to physically re-numbering each network device, some organizations are using proxy servers to translate old network addresses to their new addresses. Make sure carefully consider all the potential impacts before using this type of solution.

CIDR and non-CIDR capable routing

Some organizations and segments of the Internet still use routing technology that does not support CIDR. Existing networks that use a default route for their connection to the Internet might not need to use VSLM capable routing for their internal routing and CIDR capable routing for their external routing.

All sites that do not support VLSM and CIDR capable routing must rely on using a default route for external routing. Using a default route for external routing can result in various degree of suboptimal routing.

ISPs are expected to be able to support VLSM and CIDR.

The Internet Assigned Numbers Authority (IANA) is instructing the Internet Registries to allocate IP addresses out of the former Class A address space (64.0.0.0 through 126.0.0.0). The individual site requirements determine the size of the block of address. Sites, including all ISPs, using these addresses must support CIDR capable routing.

Sites that do not use these addresses would either continue relying on a default route or transition to CIDR capable routing protocols.

Need more information?

For more detailed technical information on CIDR, you can check the following resources:

For CIDR RFCs

• RFC 1517: Applicability Statement for the Implementation of CIDR
• RFC 1518: An Architecture for IP Address Allocation with CIDR
• RFC 1519: CIDR: An Address Assignment and Aggregation Strategy
• RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment

RFC 1338 describes strategies for address assignment of the existing IP address space and a mechanism for the aggregation of routing information.

RFC 1878, Variable Length Subnet Table for Ipv4 provides a standard subnet table that includes subnetting for Class A, B, and C networks, Network Ids, host ranges, and IP broadcast addresses.

For information about variable length subnet masks see RFC 1009. This RFC specifies how a subneted network can use more than one subnet mask.

While not essential to CIDR, RFC 1918 describes private addressing that can be used by enterprises or segments of an enterprise that want to limit connection to the Internet.

Private address space

Enterprises can use private addressing to help minimize the impact of migrating to interim schemes of address management or to IPv6 addressing. An enterprise is an organization that autonomously operates a TCP/IP network. An enterprise determines its own addressing plan and assigns the addresses within that network.

Private addressing scheme in combination with public addressing permits full network layer connectivity between hosts within an enterprise and between public hosts of different enterprises. The cost of using private internet address space is the potentially costly effort to renumber hosts and networks between public and private hosts.

The practice has been to assign globally unique addresses to all hosts within an organization that use TCP/IP. However, many organizations do not need external connectivity for the majority of internal hosts. Such hosts do not need a globally unique IP address but do need a unique IP address within the organization.

Other hosts within an organization might need connectivity to the Internet. Such hosts require a globally unique IP address. We can refer to the first type of host as private, the latter as public.

Class A-, B-, and C address blocks

The Internet Assigned Numbers Authority (IANA) has reserved the three blocks of addresses shown in for private networks.

In pre-CIDR notation:

• The first block, referred to as a 24-bit block is a single class A network.
• The second block, referred to as a 20-bit block, is 16 contiguous class B network numbers.
• The third block, referred to as a 16-bit block, is 256 contiguous class C network number.

You can use these host numbers without officially obtaining them from the IANA or an Internet registry. Be careful, these addresses must be unique within your organization.

Changing the public or private address status of a host

Using private network address numbers does not prevent you from connecting that host to the Internet in the future. To connect a host directly to the Internet without going through an application layer gateway, obtain a global IP address from one of the Internet registries.

Note : Changing the public or private IP address status of a host involves the following changes:

• Change of IP address
• Changes to the appropriate DNS entries
• Changes to configuration files on other hosts that reference the host by IP address

Advantages and disadvantages of using private address space

Using private address within an enterprise helps conserve the globally unique network addresses. By using private addressing, an organization has a great deal of flexibility with its network design because and organization:

• Has more address space is available than the organization could obtain from the globally unique pool
• Can build in an operationally and administratively convenient addressing scheme
• Can provide for an easy growth

Two sites that coordinate their private address space can communicate with each other over a public network by using some method of encapsulation at their borders to a public network. This keeps their private addresses private.

In some cases an organization might assign host IP addresses without getting this space assigned from the IANA. This could create routing problems if the enterprise later connects to the Internet and this address space has already been assigned to other enterprises. IP routing cannot provide correct operations in presence of ambiguous addressing. While ISPs usually use route filters to guard against such occurrences, this does not always happen. Using IANA assigned private address space can help avoid such conflicts once outside connectivity is needed.

The use of private address space could actually reduce an enterprise's flexibility to access the Internet because it might need to renumber part or all of an enterprise when it provides Internet connectivity.

Usually the cost of renumbering can be measured by counting the number of hosts that have to transition from private to public. However, using such tools as DHCP and Network Address Translator (NAT) applications can facilitate renumbering and reduce the time and effort to reconfigure hosts on the network.

Tips for designing private networks

The following list contains some tips to consider when you design a private network.

• Design the private part of the network first then plan public subnets where they are needed and develop the external connectivity scheme. To avoid network disruptions, it is advisable to group hosts with similar connectivity needs on their own subnets.
• If you can use and support subnetting, then use the 24-bit block (class A network) of private address space and make an addressing plan with a good growth path. Use the 16-bit block (class C network) or 20-bit block (class B network) private address space if subnetting is a problem.
• Avoid having both public and private addresses on the same physical medium. Problems can occur with the presence of multiple IP subnets on a common Data Link subnetwork.
• Set up routes that connect to external networks with packet and routing filters at both ends. Also filter any private networks from inbound routing information in order to protect it from ambiguous routing situations.
• To minimize the risk of violating address uniqueness when connecting to another organization, choose the private IP addresses randomly from the reserved pool of private addresses.
• DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise. Run two authority servers for each DNS zone containing both publicly and privately addressed hosts. One server would be reachable from the public address space and the other server would be reachable from the private address space.

The Dynamic Host Configuration Protocol overview and issues

The Dynamic Host Configuration Protocol (DHCP) is an extension of the Bootstrap Protocol (BOOTP). DHCP helps centralize and simplify management tasks involved with network connections. It can assign temporary IP addresses and centralize and automate TCP/IP network configurations. DHCP by itself and in combination with CIDR provides an efficient IPv4 address recycling structure. A DHCP standard for IPv6 is currently under development.

To communicate with other nodes on the IP network temporary connections need IP addresses, subnet masks, default gateways, and other parameters. Conventional configuration methods can be time consuming and mistakes are easily made. Entering such information can create network problems if the system administrator needs to configure each computer individually. Information entered manually is often inconsistent across all devices on the network. The problem multiplies as the number of devices multiplies. Using DHCP helps simplify these management tasks and because IP addresses are reused, reduce the actual number of needed IP addresses.

DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts.

• DHCP defines the mechanisms through which clients can be assigned a network address for a fixed lease. This allows for serial reassignment of network addresses to different clients.
• DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate.

NOTE: A host should not act as a DHCP server unless explicitly configured to do so by a system administrator.

DHCP gives the system administrator complete control over the distribution of configuration parameters to Internet hosts. DHCP consists of two components: a mechanism for allocation of network addresses to hosts and a set of rules for delivering host-specific configuration parameters from a DHCP server to a host.

Design

DHCP supports the concept of a leased IP address where a DHCP server can allocate an IP address to a client for a specified length of time. For example, you could consider using a short lease time if your network had more devices than IP address. This could help keep you from running out of addresses. Conversely, if you have more addresses than devices, you could consider using permanent leases or assign fixed addresses to specific devices.

DHCP has seven messages it can use during lease negotiation. Because addresses can be assigned to the devices on an ad-hoc basis, these message incorporate mechanisms that allow for a broad range of options and error handling conditions.

BOOTP is widely deployed throughout the TCP/IP community, particularly in diskless workstations. BOOTP is a transport mechanism for the collection of configuration information.

Because the DHCP message formation is based on the BOOTP message format, DHCP can capture the behavior of BOOTP relay agents. In addition, DHCP client can interoperate with BOOTP clients.

Existing BOOTP devices can communicate with DHCP servers. DHCP requests can cross routers running BOOTP forwarders. This backward compatibility makes it possible for a system administrator to easily upgrade devices on their network from BOOTP to DHCP on an as needed basis. The system administrator does not have to replace all of the clients at once or have to upgrade all of the routers at the same time.

The DHCP server manages two database to recognize the network status:

• Address Pool database ¾ holds IP addresses and other network configuration parameters
• Binding database ¾ keeps mapping between an Ethernet address and entry of Address Pool.

Major differences between DHCP and BOOTP

BOOTP only supports static allocation of client IP addresses. DHCP supports three methods for allocating client IP addresses.

• Dynamic allocation: Server chooses and allocates an IP address with finite lease.
• Automatic allocation: Server allocates an IP address with infinite lease.
• Static allocation: Server allocates an IP address which has been chosen by the administrator.

lists the major differences between DHCP and BOOTP.

Relay Agents

A DHCP relay agent is simply a UNIX process on an Internet host or router that forwards DHCP packets between the clients and the server. The relay agent passes DHCP messages between DHCP clients and DHCP servers that do not reside on the same IP network or subnet.

DHCP messages have the same format as BOOTP messages. DHCP uses the same relay agent behavior as specified in the BOOTP protocol specification.

A relay agent acts as a third-party agent to transfer BOOTP messages between clients and servers. A relay agent’s task differs from the task performed by an IP router’s normal IP forwarding function. A router normally switches IP datagrams between networks transparently. However, a relay agent receives BOOTP messages as a final destination and then generates new BOOTP messages as a result.

The relay agent functionality is usually located in routers that interconnect the clients and servers. Note that the relay agent could also be connected directly to the client subnet.

A BOOTP or DHCP relay agent can communicate directly with clients and servers without the use of broadcasts. Relay agents also make is possible to handle a subnet which has no server available. Using relay agents eliminates the necessity of having a DHCP server on each physical network segment.

The relay agent works as follows:

1. A DHCP client broadcasts a request message.
2. A relay agent puts the IP address of the network interface from which it received the message into a special field in the message. The relay agent unicasts the request message to a server.
3. The server unicasts back its reply to the relay agent. The reply includes the same special field and its contents as the request sent by the client.
4. The relay agent broadcasts the reply from the interface whose IP address appears in the special field in the message.

The Client ID

The BOOTP protocol identifies each client by it unique Media Access Control (MAC) address that is associated with the clients network adapter card. DHCP defines a new object, the Client ID, to uniquely identify the client to the DHCP server. For most DHCP clients, the Client ID is simply the MAC address. However, some clients use a variation of the MAC address as the client ID. For example, Windows 95 and Windows NT prepend the hardware type to the hardware address and call the combined object the client ID.

The DHCP protocol stipulates that if a client supplies a client ID in the client’s request packet, the server should use the client ID to uniquely identify the client. If the client does not include a client ID in the request then the server should use the client’s MAC address instead to identify the client.

Configuration

DHCP offers a network host a temporary lease rather than an ownership of an IP address. The lease identifies the duration for which the client can safely use the dynamically assigned IP address. Lease lengths depend on the number of network users and the number of available IP addresses the server can assign.

Configuring the DHCP server involves configuring:

• A set of configuration parameters that apply to all clients on the local IP subnet
• A pool of valid IP addresses to assign these clients
• Lease times

Host configuration parameters

DHCP can supply hosts with configuration parameters. After obtaining parameters through DHCP, a host can exchange packets with any other host in the Internet. A client and server negotiate for the transmission of only those parameters required by the client or parameters specific to a particular subnet.

DHCP allows but does not require the configuration of host parameters not directly related to the IP protocol.

DHCP can configure parameters such as default gateway, domain name server and subnet masks for each machine running a DHCP client. The protocol currently describes over 70 parameters that DHCP can configure. DHCP also allows the support of new parameters specific to a particular software platform.

NOTE: DHCP does not address registration of newly configured hosts with the Domain Name System. DHCP is not intended for use in configuring routers.

Configuration information

Of the configuration information that is passed to "client" machines, the most important pieces are:

• IP address
• IP address of the default router for that particular subnet
• Subnet mask such as. 255.255.252.0 for IP addresses in the particular network)
• IP addresses of the primary and secondary name servers

Additional information can include one or more of the following:

Ÿ	Time offset from GMT	Ÿ	The IP address of a time server	Ÿ	The IP address of a boot server
Ÿ	The name of a boot file	Ÿ	The IP domain name for the client

IP address allocation

DHCP provides three methods for IP address allocation.

• Dynamically assigning IP addresses to hosts from a pool of addresses for a limited period of time. Dynamic allocation is useful for assigning an address to a client that will be connected to the network only temporarily.
• Automatically assigning a permanent address to a host
• Manually assigning an IP address to the host by the network administrator and then using DHCP to convey the assigned address to the host.

A network administrator can use any one or combination of these IP address allocation methods depending on the polices implemented for the particular network. A network administrator can also use DHCP to deliver other configuration parameters such as subnet mask and default router id.

Hosts that frequently relocate, such as laptops and notepads, can automatically get new IP addresses for a certain lease period. DHCP offers a network host a temporary lease rather than ownership of an IP address. The lease identifies the duration for which the client can safely use its dynamically assigned IP address. Lease lengths generally depend on the number of network users and the number of available IP addresses that the DHCP server can assign.

Manual allocation of IP addresses allows the system administrator to use DHCP to eliminate the error-prone process of manually configuring hosts with IP addresses. This situation is apt to occur in environments where the system administrator needs to manage IP address assignment outside of the DHCP mechanisms.

Address allocation process

shows what happens when a DHCP client boots and receives an IP address assignment

The address allocation process is basically as follows:

1. The DHCP client attaches itself to the network for the first time and broadcasts a DHCPDISCOVER message. This message asks for any DHCP server on the network to provide the client with an IP address and configuration parameters.
2. A DHCP server on the local segment of the network authorized to configure this client sends a DHCPOFFER message. This message offers the client an IP address along with other information. The offer has an associated lease time. The lease time dictates for how long the IP address is valid.

The server may or may not conduct some preliminary testing prior to offering the address. Such testing might include generating an ARP or an ICMP echo to see if the address is already in use by another node somewhere.

The client decides to accept the IP address or to wait for additional offers from other servers on the network segment.

3. When the client decides on a particular offer , it sends a DHCPREQUEST message to accept the offer made by that server. This message identifies the server and the lease offer.

The client could base its decision on which offer has the longest lease or which offer provides the most information that the client needs for optimal operation. The other servers would notice the explicit DHCPREQUEST message and go on about their business.

4. The server sends back an acknowledgment (a DHCPACK message) finalizing the offered IP address and any other configuration parameters that the client might have requested. The server does not force any parameters on the client. It is up to the client to request the parameters that it is willing to accept.

The IP address the server offers to the client has an associated lease time. The lease time dictates how long the IP address is valid.

If the offer is no longer valid for some reason, the selected server responds with a DHCPNAK message. This causes the client to send another DHCPDISCOVER packet, starting the process over again.

5. Assuming everything is all right, the client starts using the IP address. If there is a problem with the assigned address, its sends a DHCPDECLINE message to the server and restarts from step 1. Clients should test the addresses that have been offered to them by conducting ARP broadcasts. If another node responds to the ARP, the client assumes that the address is in use.

During the lifetime of this lease, the client repeatedly asks the server to renew its lease.

6. The client can finish using a lease prior to its expiration. In this case, the client sends a DHCPRELEASE message, releases the address, and shuts down. The lease can then be made available to other nodes.
1. If the client chooses not to renew the lease or if the client machine shuts down, the lease eventually expires. The server marks the lease as non-renewed and makes it available for other clients to use.

After a lease expires, the server can recycle the IP address and give it to another machine. When the client reboots later, the server could give it the old address if it is still available or a new address. This helps the system administrator manage the IP address space efficiently, especially for networks where there is a shortage of IP addresses.

DHCP messages used during address allocation

list the eight DHCP message types that DHCP uses in exchanges between the client and server during address assignment. Note that BOOTP uses only two message types; BOOTREQUEST and BOOTREPLY.

DHCP message format

A DHCP message takes the format shown in while describes the fields within the message as defined in the DHCP protocol.

Security considerations

DHCP is built directly on UDP and IP. Neither protocol has built in security measures. Using DHCP makes the maintenance of remote hosts and diskless hosts easier. Configuring such hosts with passwords or keys could be difficult. You need to be aware that DHCP in its current form is quite insecure.

Unauthorized DHCP servers

Setting up an unauthorized DHCP server can be easy. An unauthorized DHCP server could send false and potentially disruptive information to clients. An unauthorized server could send clients such things as:

• Incorrect or duplicate IP addresses
• Incorrect routing information (including spoof routers)
• Incorrect domain name server addresses (such as spoof name servers

Once a client has this kind of information, the unauthorized DHCP server further compromise affected systems.

Conversely, a malicious DHCP client could masquerade as a legitimate client and retrieve information intended for the legitimate client. If you use dynamic allocation of resources, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.

DHCP and firewalls

DHCP can also impact the security of IP networks when there is a firewall. DHCP assigns address dynamically from a pool of available addresses. Users lease an address and when they no longer need the address, return it to be lease by another user.

Firewalls associate a specific address with a specific user. If the user of an address changes, the firewall cannot map the DHCP-assigned address back to a specific user. In this case, an unauthorized user could gain access to the network. The address can go beyond the firewall but the user is not authorized to do so.

Developing a DHCP migration strategy

DHCP provides a superset of the functions provided by BOOTP. DHCP provides a mechanism for transmitting messages containing configuration parameters hosts using the TCP/IP protocol suite. The format of DHCP messages is based on the format of BOOTP messages, so that, in certain circumstances, DHCP and BOOTP participants may exchange messages.

There are a number of options available to you to manage you IP address space. The option you choose depends on what you want to manage your clients. Ask yourself the following questions about your clients as you develop your strategy to migrate from BOOTP to DHCP.

• Do you want all your clients to remain as BOOTP clients?
• Do you want all your clients to be DHCP clients?
• Do you want some DHCP clients and BOOTP clients?
• Assuming you are using DHCP, do you want your clients to:
• Always have the same IP address (static addressing)?
• Use an address from the IP address pool (dynamic addressing)?

DHCP messages

The DHCP protocol defines the format of DHCP messages to be compatible with the format of BOOTP messages. This allows existing BOOTP clients to interoperate with DHCP servers.

For example, if a DHCP server receives a client message that contains the DHCP message type option, the server assumes a DHCP client sent the message. If a DHCP server receives messages without the DHCP Message Type option, the server assumes that a BOOTP client sent the message.

Some DHCP implementations allow the system administrator to choose if the DHCP server is to support BOOTP clients. If a DHCP server does not support BOOTP clients and the server receives a BOOTREQUEST message from a BOOTP client, the DHCP server can silently discards the BOOTREQUEST message.

Keeping everything BOOTP-only

Some DHCP implementations let you configure your DHCP server to work exactly like a BOOTP server. In some cases, such as with the Competitive Automation DHCP server, doing so can be as simple as renaming your bootptab file. This strategy assumes that you want to keep everything the same and do not want to convert any of your existing BOOTP clients to DHCP.

Switching to DHCP

You might change your IP addressing strategy if you want to convert some or all of your existing BOOTP clients to DHCP. You might also want to change your IP addressing strategy if you have new DHCP capable clients appearing on your network.

If you configure the DHCP server to support BOOTP clients, you can use:

• A static IP addressing strategy
• A dynamic IP addressing strategy
• A combination of both

Traditional BOOTP uses a static one-to-one mapping between the client Ethernet address (MAC address) and its IP address. Whenever the client requests an address, the server gives it the same pre-determined IP address. The IP address is assigned permanently. This ensures that your DHCP client always gets the same IP address whenever it boots.

There are several reason for using static IP addressing; you might want to:

• Maintain the existing static assignment policy in use in your network
• Continue using devices such as printers or host such as file servers on your network that need to have the same IP address all the time.

DHCP can also use a dynamic addressing scheme where the server allocates an IP address from a pool of IP addresses. Each address has a lease time that determines how long the client can use that IP address. The DHCP server selects the dynamic address to use from its pool of unassigned addresses.

Virtual networks and DHCP

Historically, DHCP has used subnets and routers for logical segmentation of a network. In this arrangement, DHCP relay agents forward DHCP messages from the client's subnet to the server.

However, some organizations use Ethernet or Token Ring switches to reduce LAN network congestion. Switched Networks are sometimes referred to as Flat Networks. Forwarding of DHCP messages breaks down when you use switches instead of routers to logically partition a network. The switches do not:

• Have relay agents
• Partition the network to different subnets

Switches partition an arbitrary group of machines into a virtual network (VLAN) or flat network. For example, a VLAN con be configured so broadcast messages generated within the virtual network stay within the VLAN. This means the broadcast message does not go beyond its broadcast domain.

shows that when a client broadcasts a DHCP message, the broadcast may not get to the server at all.

This figure shows a network that has been logically partitioned into three VLANS using switches. The DHCP server resides on VLAN 1. DHCP clients G, H, and J reside on this VLAN. DHCP clients A, B, and C reside on VLAN 2 and DHCP clients D, E, and F reside on VLAN 3.

In this example, client C on VLAN 2 and client D on VLAN 3 each broadcast a DHCP request that stays within the VLAN on which the client resides. Since the switch does not have a relay agent, it does not modify the DHCP request and forward it to the DHCP server. The broadcast packet is limited to the broadcast domain where the client resides. The switch does not broadcast the DHCP request to the other virtual networks. As a result, the DHCP server does not see the DHCP broadcast request from the clients.

Placing a DHCP server on each VLAN as shown in solves the problem. However, this means administrating additional DHCP servers. If there are a lot of virtual networks in the environment, this could create an administrative problem.

A more effective and manageable method is to put a DHCP relay agent in each VLAN as shown in. Since each relay agent can hear broadcasts within its VLAN, it can relay DHCP broadcast directly to the DHCP server. The relay agent unicasts the DHCP request to the DHCP server instead of broadcasting the request. The relay agent can modify the DHCP request and let the server know which subnet the DHCP client belongs to. Managing a relay agent is considerably easier than managing a DHCP server.

This solution lets you manage a single DHCP server instead one on each VLAN. Some DHCP implementation include a relay agent.

The DCHP FAQ pages available at http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html provides some more information about DHCP and VLANs.

Fault tolerant and redundant server

Since a DHCP server is responsible for the network's IP management, it can also be a potential point of network failure if it becomes unavailable. Unfortunately, there is no server-to-server protocol currently defined for DHCP. Until a server-to-server protocol is defined and implemented as a standard, there is no efficient way to provide fault-tolerance or redundancy.

Limited fault tolerance

One way to provide fault-tolerance in a limited fashion is to use multiple servers with non-overlapping IP address pools. This method can be easily explained by using an example. Imagine we have a simple situation where there are only two DHCP servers with non-overlapping pool of addresses.

• Server A has an address pool of 100 IP addresses.
• Server B has a pool of 50 address that is completely different from Server A's.

When a DHCP client broadcasts for an address, both servers respond, each offering an address from its own distinct pool. Upon receiving both offers, the client chooses one. Typically, the client selects the response that gets to it first.

Suppose the client selects server A's offer. When server B sees the client request message to server A, server B returns its offered address to its own pool. This allows server B to offer this IP address again. If one of the servers is down, the remaining server continues to service the DHCP clients. Instead of seeing two offers, the new client sees only one offer, from the remaining server.

A client that got its lease from the dead server attempts to rebind with it. If the dead server does not come back in time, the client then attempts to get a new address from a new server. The remaining server can then offer an address from its own pool to the client. As a result, even though one server is down, the DHCP client continues to function with the other server.

The two DHCP servers operate without any communications or data sharing between them. Each server works as a standalone server, independent of each other.

Primary and secondary DHPC servers

Having two servers could result in both IP pools being used partially. You could consider having a primary DHCP server with the bulk of the IP addresses. You could have a secondary server with a smaller pool of IP addresses.

One way to accomplish this configuration is to put the secondary server behind a router on a different subnet while the primary server stays on the same segment as the clients. This usually allows the primary server to respond faster than the secondary server.

Network Address Translator (NAT) an alternative addressing solution

A large part of a transition to IPv6 is handling the IP addressing for hosts on your network in an efficient manner. Reassigning IP address if you need to change ISPs, adding IP addresses as your network grows, or redefining host IP addresses as you transition to IPv6 can be an expensive but necessary tedious exercise.

Local hosts must have globally unique address when you attach an existing IP network to the Internet. Unique address allows the Internet backbone routers identify the local hosts.

A Network Address Translator implementation allows you to reuse addresses to minimize the demand for new IP addresses, reduce the impact of changing IP addressing, and ensure globally unique addressing for hosts communicating outside their stub domain. A stub domain is a domain, such as a corporate network, that only handles traffic originated or destined to hosts in the domain.

Only a small Percentage of hosts within a stub domain communicate outside their domain at the same time and some hosts never communicate outside of their stub domain. This means that you might need to translate into globally unique IP address only a subset of the IP addresses inside a stub domain. If you are using a Network Address Translator implementation, you only need to translate the host address into a unique global address when outside communications are needed.

See RFC 1631, The IP Network Address Translator, by K. Egevang, and P. Francis for a description of NAT.

NOTE: Using NAT requires the use of a firewall or router as the NAT box. This means that there is an administrative and equipment cost and sometimes a performance cost associated with using NAT.

Using Network Address Translators to reuse addresses

If the address are not unique, the Internet routes cannot route packets correctly. Packets cannot reach end-users that connect to hosts that have duplicate addresses. In addition, hosts that have duplicate addresses cannot establish application sessions.

A NAT implementation would reuse addresses by placing NAT boxes at the edge of stub domains. NAT is frequently implemented at a firewall (see). The NAT box contains a table with pairs of local and global IP addresses. The local addresses does not need to be globally unique and can be used in other domains. The globally unique addresses are CIDR addresses. You get this pool of "legal" addresses from your Internet provider. Your internal network hosts constantly reuse these addresses.

NAT boxes act as a buffer between the global Internet and IP local networks (subnet). Every time a user starts a new session and routes packets outside the stub domain, NAT replaces the internal corporate address with a temporary Internet address. When the session ends, NAT returns the internet address to the pool where it can be reassigned to another internal network user.

Using Network Address Translators with CIDR

Implementing NAT in combination with CIDR has some advantages. This combination allows an organization with CIDR addresses assigned by one Internet Service Provider to switch service to another ISP without renumbering their internal CIDR addresses. The reuse of addresses in other domains helps solve address depletion problems, and the use of CIDR address allocation helps solve network scaling problems. You can install NAT on your network without changing routers or hosts.

NAT is a router function and usually implemented at the boarder of an autonomous system (AS). An autonomous system as a collection of CIDR IP address prefixes under common management.

You can also think of an autonomous system as set of routers under a single technical administration. An AS uses one or more interior gateway protocol and common metrics to route packets within the AS. An autonomous system uses an exterior gateway protocol to route packets to other autonomous systems. The administration of an AS appears to other autonomous systems to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it.

The Internet Assigned Numbers Authority (IANA) assigns an AS an identifying number between 1 and 65534. It is assumed that interior routing policies and protocols have been established within each AS. Doing so enables the autonomous system to route packets internally. There are three types of autonomous systems:

• Stub autonomous systems ¾ A Stub AS is only connected to one other AS. For routing purposes, you can think of a stub autonomous system as a simple extension of the other AS. A Stub AS can usually have a default route to its parent.
• Transit autonomous systems ¾ A transit AS has connections to more than one other AS. A transit autonomous system allows itself to be used as a conduit for traffic (transit traffic) between other autonomous systems. A transit AS must use default-less routers.
• Multihomed autonomous systems ¾ A Multihomed AS has connections to more than one other AS, but does not allow transit traffic to pass. The interior hosts in a multihomed autonomous system can route traffic through multiple autonomous systems. A Multihomed AS can use a default route to one of its neighbor autonomous systems, but this could result in poor quality routing.

Running BGP in a no-transit configuration is recommended.

Using Network Address Translators with private networks

The use of private networks helps relieve the shortage of IP addresses. Private networks are hidden from the rest of the world behind firewalls or packet filtering routers. You can use a NAT implementation at the firewall to translated the private addresses into public addresses when they're sent to the Internet.

NAT converts the private addresses of the outbound traffic to that of the router or firewall’s external interface. IF the router for firewall has multiple external interfaces, conversion occurs for each interface. Conversion occurs in the opposite direction with inbound traffic.

NAT advantages

• NAT enhances the level of security within the Network by hiding its internal structure from would be hackers.
• Permits an almost unlimited number of users of one class C Network address because global addresses are required only when a user is connected to the Internet.
• When an existing IP Network is attached to the Internet, there is no need to replace the IP address of each and every host on the internal network. A well designed NAT implementation can accomplishes the task.
• NAT pools official IP addresses and distributes them on a priority basis. For example a stations with a higher priority could disconnect a station with a lower priority. When the lower priority makes another request to the Internet, I receives a new IP address.
• When you use a local addressing system, you internal network become invisible to the public. A list of your internal IP address is not available to outsiders.
• When you use NAT you can change your official IP addresses without having to reconfigure your TCP/IP network station-by-station.
• Enables stations with internal IP addresses to access the Internet with a official IP address without any system reconfiguration.

Address management tools

A number of companies offer IP address management tools and have information available at their Web sites including but not limited to:

Process Software Corporation (http://www.process.com)

Competitive Automation (http://join.com)

Cisco (http:// www.cisco.com)

Accugraph Corporation (http://www.Accugraph.com)

Isotro Network Management, Inc. (http://www.isotro.com)

Quadritek Systems, Inc.( http://www.Quadritek.com)

Advanced Computer Communications, Inc. (http://www.acc.com)

American Internet Corp (http://www.american.com)

FTP Software, Inc. (http://www.ftp.com)

MetaInfo, Inc. (http://www.MetaInfo.com/)

Network Safety Corporation (http://www.safety.net)

MVI Networks IntraGuard product (http://www.mvi-net.com)

CYCON Labyrinth (http://www.cycon.com)

Citadel Data Security http://www.oms.co.za

Flying Fox Computer Systems, Inc. (http://www.flyingfox.com)

Most of these companies offer products that help users automate IP address-to-name mappings, and monitor assigned and available addresses.

From here…

This chapter lists some Internet Architecture Board recommendations for easy renumbering, and some mechansims you can use tp prepare for migrating from IPv4 to IPv6 include CIDR addressing, private addressing, and using applications such as DHCP and NAT.

Chapter 16, "Making the Transition to IPv6" introduces some guidelines for migrating to IPv6, discusses IPv6-over-IPv4 tunneling, upgrade dependencies, and OSI NSAP address mapping.

Chapter 8, "IPv6 and Intranetwork Communications"

discusses the internet Group Management Protocol messages and Neighbor Discovery Messages as they apply to IPv6. It also discusses the impact of IPv6 on some routing protocols.

Chapter 18, "Possible Alternative to IPV6 to Handle Addressing" discusses the pros and cons of some alternative addressing schemes including NAT.

Chapter 3, "IPv4 Limitations and Constraints" describes the IPv4 addressing system and introduces IPv6 enhanced address including issues around DHCP, VLANS, IP address/DNS name assignment, and recycling of IP addresses.