Planning for TCP/IP Implementation

By Ronald Nutter MCSE/MCNE

Published in TechRepublic's Windows NT Administrator Report

Having TCP/IP present on a network has become almost commonplace in the past couple of years. TCP/IP has gone from being used almost exclusively at universities and large corporations to becoming the protocol of choice in networks of any size. With more networks connecting to the Internet on a daily basis, planning for implementation of TCP/IP while allowing for growth into the future is increasingly important. This article will guide you through the steps of planning for TCP/IP use on your network.

On This Page

Public vs. private IP addresses
Subnetting
Duplicate DHCP servers
Conclusion

Public vs. private IP addresses

There are two types of IP addresses: public and private. Public addresses are assigned to you by the ISP you're using to connect to the Internet. These addresses are doled out to ISPs by Internic, based on the particular ISP's demonstrated needs. Getting a full IP network range is almost impossible even for the largest of companies. Compound this with an unknown rollout date for Ipv6 (the next version of IP addressing with a larger address space range to work with), and suddenly using private IP addresses—with the protection they provide from network hacking—start to become a viable option. The following recognized private IP address ranges are specified by Internet Request for Comments (RFC) 1918:

• 10.0.0.0 – 10.255.255.255

• 172.16.0.0 – 172.31.255.255

• 192.168.0.0 – 192.168.255.255

One of the features that comes with using the private IP addresses as specified in RFC1918 is that the major router vendors and users agree that requests going to or from these addresses are discarded. When using private IP addresses, you'll use some type of proxy or Network Address Translation (NAT) server to convert the private IP address range(s) on your local network to a public IP address that can be routed.

To learn more about RFC, visit https://www.cis.ohio-state.edu/hypertext/information/rfc.html. RFC1918 is available at https://www.cis.ohio-state.edu/htbin/rfc/rfc1918.html.

Subnetting

Subnetting is the process of taking one TCP/IP network address range and splitting it into two or more ranges that can be used on as many network cards. Table A (courtesy of https://www.dc.net/) shows the effects of subnetting IP addresses.

Table A Subnet expansion

Subnetting, although becoming more common, should be done with careful consideration. One thing you'll quickly learn when taking the Microsoft TCP/IP exam is that Microsoft (hence NT) is strictly RFC compliant when it comes to subnetting and the amount of useable addresses it provides. Because some of the addresses ranges created by subnetting will start with either all ones or all zeros, you must remember that the first and last network address ranges are unusable by NT for routing purposes. One disadvantage to using a subnet mask other than the default for that IP class is that it adds a layer of complexity to troubleshooting when a workstation or other network device has a communication problem.

I like my IP addresses as short as possible and with the simplest subnet mask to minimize errors caused by mistyping. A project I worked on last year involved installing networks in more than 30 states. The customer elected to use the 10.0.0.0 range with a 255.255.255.0 subnet mask. The second octet was used to specify the state the network was running and the third octet designated the office. In cases where multiple network segments were required at a given location, we used additional address ranges from the third octet part of the IP addressing scheme. Don't subnet unless you have to, and then try to plan for future use as much as possible to avoid problems with having to change the IP configuration at a later time.

Assigning addresses

There's no one right or wrong way to use the IP addresses for a given subnet. I prefer to use .1 of the fourth octet of the address range (that is, 10.10.1.1) to identify the default route to and from a particular segment. Depending on how many devices will be present on a particular subnet, I like to assign addresses to those devices that shouldn't need to change or can't change for some reason.

Devices such as network printers or communications gateways usually need to have a fixed address. If a dhcp address release isn't renewed in time and expires, thereby causing a new address to be assigned to the device, the other devices or services talking to the particular device won't understand how to change to the new address.

In the example I cited earlier of the multistate WAN, I used .1 to .49 for the fixed IP address assignment, .50 to .149 for the primary DHCP scope, and .150 to .249 for the redundant DHCP scope. To provide for flexibility when bringing new workstations onto the network and for moving workstations from one segment to another, DHCP helps streamline the process of assigning addresses, subnet masks, DNS addresses, and so on, without requiring a visit to each workstation.

Duplicate DHCP servers

To provide for uninterrupted operation of the network, it's worthwhile to consider implementing more than one DHCP server for a given segment. Doing so prevents a problem from occurring if an IP address lease expires at a device and isn't able to renew. The trick to using more than one DHCP server for a given segment is that an address given out by one DHCP server can't be given out by another DHCP server. If this dual assignment of an address were to happen, and more than one device were to claim the same IP address, think of the problems that would occur when routers started getting confused as to where a particular package should be routed. When you create redundant DHCP scopes (Microsoft terminology for more than one DHCP server), you'll need to enable bootp forwarding on a given segment so that if the local DHCP server can't respond, the request for address assignment can be forwarded to the DHCP server that can answer the request.

Conclusion

There's no one right way to plan and implement TCP/IP addressing for a network. The key thing is to decide on a plan that will work best for you and follow through on that plan. No plan should be considered set in stone, so you may need to make an occasional revision and grant some implementation exceptions as necessary.

Ronald Nutter is a senior systems engineer in Lexington, Kentucky. He's an MCSE, Novell Master CNE, and Compaq ASE. Ron has worked with networks ranging in size from single servers to multiserver/multi-OS setups, including NetWare, Windows NT, AS/400, 3090, and UNIX. He's also the Help Desk Editor for Network World. You can reach Ron at Rnutter@ix.netcom.com.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.