Steven Baker

Most of my columns focus on a single networking topic. However, some subjects simply aren't grist for a full column. So, I collect these ideas, storing them on my computer monitor until there is not enough screen left to do real work. I then compile these snippets, getting them off my monitor and into print. This column is just such a recap of these loose topics.

Baby, Don't Lose That Number

Hindsight is powerful. When I first started writing Net Worth six years ago, it was simple to register a Class B or Class C IP network and receive an official IP address. It also was easy to register any number of interesting names in the Domain Name Service (DNS) for your site. How times have changed! When I tried to get a Class C IP network address six months ago, I found myself in different waters.

The Internet Assigned Number Authority (IANA) delegates responsibility for allocating IP network addresses to various regional Internet Registration (IR) authorities. Currently, IP network address assignment and registration of IP domain names in North America is handled by the InterNIC, which is contracted to Network Solutions Inc. (Herndon, VA). This site operates under the InterNIC Registration Services name (http://rs.internic.net; (703) 742-4777). AT&T has a similar contract to provide data services (http://ds.internic.net) and maintains the main root-level DNS servers and other data (electronic versions of the Requests for Comments (RFCs), for example). Other regional IRs handle IP-address assignment for other parts of the world. The European IR is located at the Réseaux IP Européens Network Coordination Centre (http://www.ripe.net) in Amsterdam, while the Asian Pacific region is handled by the Asian-Pacific Network Information Center (http://www.apnic.net) in Tokyo.

In the past, a user would send a request for an IP network address to the InterNIC via e-mail and receive a response with a new Class C IP address in a week or two. Now, however, network addresses for the current version of the Internet Protocol (IPv4) are running out. Most Class B network addresses (which allow up to 65,534 possible nodes) are already assigned, creating the impetus for the development of IP Next Generation (IPng), also known as IP version 6 (IPv6). With Class B addresses almost gone, requests for large blocks of network addresses are handled by blocks of adjacent Class C addresses (which allow up to 254 nodes per network) that can be managed efficiently by main backbone routers on the Internet.

The protocol that manages these blocks of Class C addresses is called Classless Inter-Domain Routing (CIDR). Under CIDR, blocks of adjacent Class C addresses are aggregated and pointed to a particular endpoint router (an Internet Service Provider (ISP) or large network user). Most router vendors support CIDR using the Border Gateway Protocol (BGP). To reduce the size of routing tables, Class C addresses now are assigned to ISPs in blocks for CIDR.

Users and companies generally must request IP network addresses from their ISP. A significant drawback to getting IP network addresses from your ISP is that if you change to a different service provider you likely will need to renumber all the IP hosts at your site--a rather painful prospect. This is part of the rationale behind the use of the Bootstrap Protocol (BOOTP) or the newer Dynamic Host Configuration Protocol (DHCP) for dynamically assigning IP addresses to nodes at startup.

Getting a Class C IP address directly from the InterNIC is almost impossible. I wanted a permanent IP address for my local research network that would not have to be changed with each new ISP I use. My alternative was to use one of several network IP addresses that can be freely used for private networks as long as you do not connect the networks to the Internet. These IP addresses allow any number of isolated IP networks to have the same IP numbers. IANA has set aside one Class A IP address, 16 Class B addresses, and 256 Class C addresses for this purpose (see Figure 1).

While I negotiated with the InterNIC by e-mail for a Class C IP address, I was told it had adopted new rules that require a minimum of 128 hosts to receive an IP address from the InterNIC. Because you pay for its service, your ISP is likely more flexible in providing you with a Class C IP address from its pool.

Even if I had received a Class C network address from the InterNIC, it would be of limited value. SprintLink has blocks on its main routers for Class C IP addresses not issued by another ISP, so my packets would not have been routed. Apparently, if you don't pay an ISP, Sprint won't bother to carry your traffic.

No-Name Blues

Of course, most users don't care about your IP address. They know your site by a more meaningful name (www.FreeMoney.com, for example). These names are supplied by the Domain Name Service and various DNS servers that can be used to map a hierarchical name (www.sun.com) to an IP address that the low-level IP protocols use.

Registering a domain name is even more difficult than registering an IP address. The problem is finding an unregistered name that meets your needs. The goal is to find a domain name that is short, snappy, and easy for your customers and clients to remember. You may have noticed that domain names in some of the root-level domains such as .com (commercial) have been registered at amazing rates over the last few years (more than 80,000 names a month). Some companies even register names and then sell them to companies or users who want them.

Internet domain names are not treated like copyrights or trademarks, so it was possible for someone other than Microsoft to register windows95.com even though Microsoft owns the Windows 95 moniker. In fact, the irony of the windows95.com Web site (a shareware resource for Windows 95 applications at http://www.windows95.com) was that it initially was hosted on a BSDI UNIX system. The InterNIC maintains a limited dispute policy regarding domain names.

Most three-letter domains (company abbreviations) under com are long gone. Common words in the English language are quickly being exhausted. If you have an uncommon name (Allen Holub of holub.com, for example), you might still be in luck. I spent a week of late nights feeding name ideas to WHOIS before finding a suitable domain name to register. WHOIS is a common network application found on most UNIX systems that queries the InterNIC for information on a registered domain name. Equivalent PC and Macintosh network applications that will query the InterNIC WHOIS database are readily available. If WHOIS does not find a match for TwelveBeagles.com (case is irrelevant), you theoretically could register that DNS name. Otherwise, WHOIS returns information from the InterNIC on who owns the DNS name you queried.

I eventually found a suitable name (lyrical.com), along with a few possibilities that likely are gone by now. The InterNIC charges $50 per year to register a domain name, payable in advance for two years. The InterNIC threatened to charge for DNS registration for several years, but they apparently never sent out bills to preexisting sites with registered DNS names. Times have changed, and now you should expect a bill (they gladly accept credit cards and First Virtual electronic transfers) in order to receive your official DNS name.

To request a DNS name from the InterNIC, you must fill out a form (available via FTP at ftp://rs.internic.net/template/domain-template.txt or via the Web at http://rs.internic.net/cgi-bin/itts/domain/) and e-mail it back to the InterNIC. Most ISPs will fill in the form requesting a DNS name for you for a small fee (typically $50) and provide DNS service and a maildrop. Otherwise, you must find two DNS sites that will provide your domain with DNS service and submit this with other information on your domain-name request form.

Of course, if you do not register under one of the root-level domains (com, edu, gov, net, org, and so forth), your name options should be much greater, and you do not need to deal with the InterNIC at all. This name-usage problem is much more acute under com than, say, net or org. There has been a push to register by location (odoe.state.or.us or TheWell.sf.ca.us), for example). In these cases, you will need to locate who owns (manages) the domain under which you want to register. Local geographic domains usually will gladly register your site without charging a fee. The original spirit of the Internet still lives (at least at the periphery).

Address allocation for private networks is discussed in RFC 1918. Released in November 1996, RFC 2050 discusses the current policies for allocating IP addresses on the Internet. Documentation on CIDR is available in a series of RFCs: 1517, 1518, 1519, 1520, and 1817. RFCs are available at ftp://ds.internic.net/rfc/. If you have thought about registering a domain name, do it now. IPv6 will resolve the shortage of addresses, but it won't deal with a lack of meaningful names.

Costly Credentials

In my last column, I discussed securing Web transactions using several possible schemes, including the Secure Sockets Layer (SSL) or Secure HTTP (S-HTTP). SSL was developed by Netscape Communications (Mountain View, CA) and is supported by its family of browsers and servers. SSL also is supported by Microsoft's Internet Explorer and most major Web server software. S-HTTP was developed by a consortium headed by Electronic Integration Services (EIS; San Jose, CA) and is supported by many Web servers but fewer Web browsers. These Web security schemes are based on public-key cryptography and depend on a higher authority to work properly.

This higher body is the Certification Authority (CA) that must maintain a highly protected site on the Internet containing sensitive security information to vouch for the credentials (authenticate) and provide the public keys needed for secure communications between Web servers and clients (a signed digital certificate). The default CA supported by most Web software is Verisign (http://www.verisign.com). The U.S. Postal Service has indicated a strong interest in acting as a Certification Authority but is yet to have a CA online.

A site setting up a secure Web server pays a fee to the CA to register a digital certificate and a public key. Verisign charges $290 per year for a Class 3 certificate that might be used by a Web server. The price of multiple certificates issued to the same company is $100 per year. The CA must research the owner of the Web server site using conventional means (Dunn and Bradstreet, other fiscal information, DNS records, and so forth) to determine that the person or company is who or what it says it is. Only then does the CA issue a digital certificate to vouch for the site. These CA certificates last for one year and can be terminated by the CA.

A Web browser consults its list of accepted CAs and queries one of these sites to request authentication for a particular Web server site (http://www.microsoft.com, for example). The CA sends back verification of the server site to the Web browser in the form of a digital certificate containing a public cryptographic key. The Web server has a copy of its private cryptographic key (generated when the digital certificate was requested from the CA) that works with this public key. These keys pass a private-session key between browser and server for encrypting and decrypting Web communication.

There are several problems with this method as implemented by most Web browsers and servers. First, what happens if you have a private intranet and you want to secure communication between Web browser and server? The few CAs that do exist reside on the Internet. Even if you connect your intranet hosts temporarily to the Internet for generating cryptographic keys (requesting and ordering digital certificates from a CA), the CA would not be reachable when you severed this temporary connection. You need a CA (which is kept highly secure) located on your private intranet to handle authentication.

The second problem is more of an inconvenience and can quickly get expensive. The private cryptographic keys generated by the Web server (and those that might be generated by a Web browser) and the digital certificate received from the CA usually are further scrambled, secured by a password, and hidden in some local file. Different Web browsers and servers create and maintain this information in unique ways that are kept private and undocumented (if someone knows how these private keys are stored, the entire security scheme can be compromised). If you install a different Web server on the same machine, you are forced to generate new keys and request a new digital certificate from the CA. Even installing a newer version of the same Web browser or server can inadvertently wipe out the security data in this file and force you to send more money to your favorite CA. So, if you want to test both Microsoft's Internet Information Server and Netscape's Commerce Server on the same Windows NT machine, you need to purchase two separate digital certificates. You also need to purchase separate certificates for SSL and S-HTTP, if both are to be used or tested.

Before the rollout of an intranet or software and during the testing and setup phase, it is common to install a Web client or server several times. This process normally includes executing the procedures needed to generate cryptographic keys, requesting digital certificates from your preferred CA, and installing this information on the local machine. At $100 each (after the first $290/year certificate), this can become an expensive habit.

Netscape has released a beta version of a Certificate Server that could come in handy in this situation. A local Certificate Server might be used during the development and testing of a site. After decisions have been made, new keys would be generated and digital certificates requested and purchased from a widely respected public CA. On private networks, the local CA would become the authenticator, requiring appropriate security and diligence.

Windows 95 Woes

Although software-compatibility issues have plagued Microsoft's Windows 95, at least the networking functions properly. My biggest complaint with Windows 95 is that I consider it unmaintainable. Microsoft has yet to document the Windows 95 Registry in a way comparable to the documentation for Windows NT so a system administrator can fix problems. The Windows 95 and Windows NT Registries are large binary databases that store most configuration and system information for the operating system and applications. The release rate of patches and bug fixes to Windows 95 has been unacceptable--one patch release and a few other files over an 18-month period fixed only a few of the well-known bugs documented in Windows 95. I suppose if Microsoft waits long enough, it can sell users a new version rather than provide free patches to the existing product.

Our focus next month will be PCNFS software on Windows NT, Microsoft's powerful 32-bit operating system designed for the enterprise. Until then, I leave you to brainstorm names for your next domain.

Steven Baker works for the Oregon Department of Energy, coaxing energy conservation from state buildings. He was the editor of Programmer's Journal and one of the authors of Extending DOS, published by Addison-Wesley. He can be reached at msbaker@cs.uoregon.edu.

IP Addresses Assigned To Private Intranets

This article first appeared in the April 1997 issue of UNIX Review.

Home | Top | Editor's Choice

Copyright © 2000 UnixReview.com ,UnixReview.com's Privacy Policy,
Comments: rreames@cmp.com
SDMG Web Sites: C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, Sys Admin, SD Expo, SD Magazine, UnixReview.com, Windows Developer's Journal