This chapter discussed the issues in designing an efficient addressing, naming, and configuration model for your network. Specifically, the following topics were covered:
Each device on a TCP/IP network must have a unique IP address that universally identifies it. IPv4 provides for several classes of address, but this rigid mechanism is wasteful. IPv6 provides a future-proof addressing scheme but is not widely implemented today.
Decide at the outset if there will be a requirement for public network connectivity, such as the Internet. This will influence your decision on whether to choose a private or public IP addressing model. In either case choose the most appropriate class of IP address to cope with current demands and future growth. Make allowances for the fact that a number of IP addresses have special applications and cannot be used. If you opt for public access, make sure you use registered addresses via your ISP or nearest IANA authority.
A number of organizations may have chosen to implement private addressing schemes to build their intranets. Subsequent changes in those organizations may now force them to provide public interfaces to resources such as the Internet. NAT has a valuable role in network renumbering; it can greatly reduce the amount of renumbering required or even negate it entirely. NAT offers static or dynamic address translation, enabling unregistered private networks to communicate freely with the Internet. NAT, however, is not completely transparent and may not cope with some applications that rely upon embedded IP addresses. Performance overheads mean that NAT may become a bottleneck on large, busy networks.
A hierarchical addressing scheme promotes more efficient routing and salability. Subnetting with Variable-Length Subnet Mask (VLSM) and supernetting with Classless InterDomain Routing (CIDR) are invaluable techniques for designing scalable networks.
Depending on the size and mobility of stations on your network, you may want to make use of dynamic address allocation services to reduce the administrative burden. Dynamic addressing tools such as DHCP and BOOTP have their problems but are an invaluable aid to allocating addresses and configuration data in large networks. BOOTP has been somewhat overshadowed by DHCP in the enterprise, but for legacy environments several enhancements enable interoperability. The approach to automated configuration, address allocation, naming, and device booting has been somewhat fragmented to date. For large internetworks these activities need to be well integrated if network administrators are expected to cope with the increasing scale of modern data networks, the lack of skilled resources, and burdens placed on them. Work is underway within the IETF to provide a more holistic approach.
IP version 6 is the best get-out-of-jail card for resolving the IP address space problem; however, the transition to IPv6 is likely to be painful and costly. There is a huge installed base of IPv4 devices and applications out there. Some of these applications will require redesigning, and this will take time. The migration phase will require the coexistence of IPv4 and IPv6 devices for several years, placing additional burdens on networking devices and services in the interim. Nevertheless, start making preparations for IPv6 now.
Directory services are a key component in the development of intelligent networks through initiatives such as Directory-Enabled Networks (DEN). LDAP, based on OSI's X.500 DAP, is the de facto standard for client access to directory services.
 Internet Numbers, RFC 266, July 1990.
 Internet Protocol, RFC 791, September 1981.
 Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998.
 T. Kenyon, High-Performance Network Design: Design Techniques and Tools (Woburn, MA: Digital Press, 2001).
 Assigned Numbers, RFC 1700, October 1994.
 www.iana.org, IANA home page.
 www.ripe.net, Reseau IP Européens (RIPE NCC) home page.
 www.apnic.net, Asia-Pacific Network Information Center (APNIC) home page.
 www.arin.net, American Registry for Internet Numbers (ARIN) home page.
 Internet Registry IP Allocation Guidelines, RFC 2050, November 1996.
 Address Allocation for Private Internets, RFC 1918, February 1996.
 IPng Requirements of Large Corporate Networks, RFC 1678, August 1994.
 IP Version 6 Addressing Architecture, RFC 1884, December 1995.
 A Compact Representation of IPv6 Addresses, RFC 1924, April 1996.
 Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, April 1996.
 Guidelines for Creation, Selection, and Registration of an Autonomous System (AS), RFC 1930, March 1996.
 ftp://ftp.isi.edu/in-notes/iana/assignments/as-numbers, latest IANA ASN assignments.
 Reverse Address Resolution Protocol, RFC 903, June 1984.
 Dynamic RARP Extensions for Automatic Network Address Acquisition, RFC 1931, April 1996.
 Bootstrap Protocol, RFC 951, September 1985.
 Clarifications and Extensions for the Bootstrap Protocol, RFC 1542, October 1993.
 Bootstrap Loading Using TFTP, RFC 906, June 1984.
 D. E. Comer and D. L. Stevens, Internetworking with TCP/IP, Vol. II: Design, Implementation, and Internals (Englewood Cliffs, NJ: Prentice Hall, 1991).
 DHCP Options and BOOTP Vendor Extensions, RFC 2132, March 1997.
 Dynamic Host Configuration Protocol, RFC 2131,March 1997.
 Interoperation between DHCP and BOOTP, RFC 1534, October 1993.
 Internet Control Message Protocol, RFC 792, September 1981.
 P. Miller, TCP/IP Explained (Woburn, MA: Digital Press, 1997).
 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463, December 1998.
 IP Authentication Header, RFC 2402, November 1998.
 P. Albitz and C. Liu, DNS and BIND. (O'Reilly & Associates, 1997).
 W. R. Stevens, UNIX Network Programming, vol I, 2d ed. (Englewood Cliffs, NJ: Prentice Hall, 1998).
 Domain Names—Concepts and Facilities, RFC 1034, November 1987.
 Domain Names—Implementation and Specification, RFC 1035, November 1987.
 DNS Extensions to Support IP Version 6, RFC 1886, December 1995.
 Domain Name System Structure and Delegation, RFC 1591, March 1994.
 www.iana.org/cctld.html, IANA Web page for registered Top-Level Domains.
 ICMP Domain Name Messages, RFC 1788, April 1995.
 Negative Caching of DNS Queries (DNS NCACHE), RFC 2308, March 1998.
 www.isc.org, The Internet Software Consortium's Web site; contains source for the BIND application.
 Classless Inter Domain Routing (CIDR): An Address Assignment and Aggregation Strategy, RFC 1519, September 1993.
 Dynamic Updates in the Domain Name System (DNS UPDATE), RFC 2136, April 1997.
 Incremental Zone Transfer in DNS, RFC 1995, August 1996.
 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), RFC 1996, August 1996.
 Directory Assistance Service, RFC 1202, February 1991.
 DIXIE Protocol Specification, RFC 1249, August 1991.
 X.500 Lightweight Directory Access Protocol, RFC 1487, July 1993 (obsoleted by RFC 1777).
 Lightweight Directory Access Protocol, RFC 1777, March 1995 (obsoletes RFC 1487).
 Universal Multiple-Octet Coded Character Set (UCS)—Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
 UTF-8: A Transformation Format of Unicode and ISO 10646, RFC 2044, October 1996.
 Lightweight Directory Access Protocol (v3), RFC 2251, December 1997.
 Naming Plan for Internet Directory-Enabled Applications, RFC 2377, September 1998.
 www.novell.com, Novell home page. See Novell Directory Services (NDS).
 www.microsoft.com, Microsoft home page. See Active Directory.
 www.iplanet.com, a powerful alliance offering directory services, including Sun Microsystems, AOL/Netscape, and Innosoft.
 www.openldap.org, LDAP code derived from the University of Michigan.
 The LDAP Application Program Interface, RFC 1823, August 1995.
 www.cisco.com, Cisco home page.
 www.universe.digex.net/~murchiso/den/, Information on the DEN initiative.
 Network Renumbering Overview, RFC 2071, January 1997.
 Router Renumbering Guide, RFC 2072, January 1997.
 The IP Network Address Translator (NAT), RFC 1631, May 1994.
 An Architecture for IP Address Allocation with CIDR, RFC 1518, September 1993.
 Exchanging Routing Information across Provider Boundaries in the CIDR Environment, RFC 1520, September 1993.