| ★ wanayoo — archive 1999 http://data.com/tutorials/ip_plan.html | Nouvelle recherche | Portail wanayoo |
|
|
|
|
|
|
The subnet mask is the number used to separate the network from the node address--it's the key to efficient packet routing. The DNS maintains the address lookup directory for the network, and it handles the translation of the English mnemonic addresses used by many IP applications into the host addresses of the end devices.
Unfortunately, TCP/IP networks don't automatically perform these configuration chores, the way IPX and Appletalk nets do. Think of the difference between cellular and conventional phones: With cellular phones, users can move around freely and place calls from pretty much anywhere in the country; conventional phones are configured to work in just one physical location. In this analogy, IP networks are like the conventional telephone network.
Confronting the realities of configuration is half the IP addressing battle. Once net managers ge t beyond the idea that it isn't going to happen automatically they can get down to the task at hand.
Manually administering the addresses is an option--but it can be agonizing, involving a lot of trial-and-error. Tracking down the person who has the address that's needed is one problem. Then comes reconfiguration, which takes 5 to 10 minutes per workstation. And it's not a one-time deal. Networks with several thousand users might require a hundred reconfigurations a week, enough to keep someone employed full-time.
That's all assuming everything is done correctly--a rosy scenario at best. Errors have a way of creeping in, given that keeping track of all these addresses means maintaining a list of addresses with their corresponding default gateways. The DNS server also has to be updated.
But take heart. A few configuration and management tools are available that enable some of these chores to be performed automatically (see "IP Address Management: Containing the Chaos," page 71). Moreove r, there are plenty of protocols available for introducing at least a little bit of automation.
There are other options, as well. Take the Bootstrap Protocol (Bootp), a method that's widely implemented in networks consisting mostly of Unix machines. Bootp essentially allows a machine on the network to act as an address server, so that as devices are added to network they can automatically request and be given an address.
Bootp operation is pretty basic: When a machine running the Bootp client code is added to the network, it broadcasts an address request. It reissues the request at periodic intervals until a Bootp server responds by sending one. That's all there is to it.
But simplicity makes for limitations. The standard version of Bootp (which was originally developed in 1985 and is now defined as Internet RFC 951) contains no provision for querying a specific server rather than making an all-points bulletin. These general-purpose broadcasts not only eat up net work bandwidth, but they can also cause conflicts in networks that have DHCP servers. Also, Bootp requests can't cross subnet boundaries unless routers are configured to relay Bootp messages.
But if there's one thing that really illustrates Bootp's limitations in today's TCP/IP nets, it's that there's no way to assign addresses dynamically. Once a client receives an address, it keeps it in perpetuity--exactly what's not wanted when dial-in users are involved, since they're supposed to receive temporary IP addresses that can be reassigned once the connection is broken.
Still, there are some custom Bootp implementations that address these issues. Over the years, vendors have developed extensions that make the protocol more dynamic and flexible. The only problem is that they're proprietary--which means they're of limited use in a multivendor network.
Autoconfiguration options don't end with Bootp. There's also KIP (Kinetics Internet Protocol), an older protocol usefu l in Appletalk networks that have IP addressing requirements. But KIP contains address brokering and temporary address allocation concepts that today are being considered for use over public networks--and for that reason it's worth taking a look at.
KIP is essentially an encapsulation scheme. It calls for a device like a router or gateway to reserve addresses temporarily--or "broker" them--on behalf of the client.
Before the client is added to the network, it's configured for server-based addressing. Thus, when it's first attached to the network, it connects to the broker using the Appletalk protocol. Nested in that protocol is a request for an IP address, which the server acknowledges by assigning an address for that IP session.
The broker also handles protocol translation: Outgoing Appletalk packets are stripped of their header information and sent as IP packets over the IP net. Incoming IP packets are encapsulated within an Appletalk packet by the gateway and forwarded to the client .
But one of the more popular choices for address automation on IP-only nets is DHCP (dynamic host configuration protocol). Developed in 1993 and now standardized as RFC 1541, it's generally associated with Microsoft Corp. (Redmond, Wash.), which has been aggressively promoting the scheme for IP addressing in Windows and Windows NT environments. DHCP fills many of the gaps left by Bootp and KIP--only it presents its own set of complexities in the process.
As with Bootp and KIP, a DHCP solution includes client code that runs in the client's TCP/IP stack and server code that runs in any machine acting as an address server. A network could have several DHCP servers, with one acting as the primary device while the others are configured as backups.
For requesting and receiving addresses, DHCP uses Bootp commands, only the client-server exchange is more complex. Still, DHCP addressing is much easier to manage and control than Bootp addressing, and that's its biggest s elling point.
A client starts the exchange by broadcasting a discover packet--consisting of the client's MAC (media access control) address--to determine which servers are in the neighborhood and to request an address. The server (or servers) then issues an IP address, which could also contain information on how long the address can be used by that client. The server also records the client's MAC address to keep track of who's been given which IP address.
If more than one server responds, the client can choose the address it wants from among the various offers. In other words, it can be configured to pick from a list of preferred servers, rather than simply accepting an address from the nearest server. Contrast this to Bootp, where the initial broadcast is simply a request for an address for whichever server is closest by.
After the client selects a server, it then sends a DHCP prerequest message back to that server. This request could include the client's required lease time, if it di ffers from that initially offered by the server. If the client's request can't be met, the server sends a DHCP negative acknowledgment packet and declines to issue the address. Otherwise, the client gets its address and everything is ready to go.
So, what about those DHCP management strengths? First, it's a good fit for remote access, since it allows addresses to be allocated for a limited amount of time and then be reassigned. Remember, with IP addresses so hard to come by, being able to re-use them is key (see "The Numbers Crunch").
Moreover, the preferred-server feature lets net managers decide which servers are allowed to allocate addresses to which groups of clients. When a router's Bootp relay option is turned on, a DHCP server also can assign addresses across subnets (since the DHCP and Bootp messaging formats are the same). Thus the primary address server can be centrally located and disperse addresses throughout the net.
Meanwhile, some router vendors have added an enhanced DH CP feature for building preferred server lists directly into the box. The dialogue between client and server over which server to use is thus cut back considerably. For instance, routers could keep clients from broadcasting DHCP requests across a WAN link if there's a local server that can fulfill the requests instead.
Those are some of the reasons why DHCP has emerged as a favorite for automatic addressing. But DHCP deployment can be difficult: Overlook the particulars and DHCP can bite back.
Are any devices sending Bootp requests? If so, don't install that DHCP server just yet. Hubs and bridges preconfigured for Bootp are constantly sending out broadcast requests for IP addresses--requests that go unfilled if there isn't a Bootp server residing on their subnets. Since these products don't require IP addresses to operate anyway, the requests could have been made over and over again without anyone noticing.
But stick a DHCP server on the net and those requests will start getting filled, most likely at the expense of other, more legitimate devices. That's because the DHCP and Bootp messaging formats are fundamentally the same--alike enough that those hubs and bridges might end up hording all the available IP addresses. The simple solution: Before installing a DHCP server, identify the Bootp devices and turn off the Bootp client code.
Another issue to keep in mind is addressing hierarchies. Having the ability to choose certain servers for filling certain requests is great, but net managers should think carefully about which devices can and can't hand out addresses. Equal care should be used in deciding on a location for the central DHCP server (if there is one) and which servers should act as backups.
Allocating address ranges to those servers also requires special attention--without it, an address drought could occur in some parts of the network and a deluge in others. Consider again, for instance, the provision of addresses to remote users. Typical ly, DHCP is used. But if DHCP also is being used to allocate addresses throughout the main network, someone will have to decide which will be available for remote users and which for users on the LAN. Otherwise, the server might just allocate all its addresses to those on the LAN.
Of course, it's possible to configure around the problem. Have client software use the remote access server as an address server when coming in locally, and set aside another server for address allocation across the LAN. Writing an "addressing MIB" (management information base) to inform the net management package that a server has run out of available addresses is also an idea worth investigating.
Net managers could also set up the remote access server as a proxy DHCP server--have it pass address requests to the central DHCP server. As long as there are any addresses available at all, there will be enough for remote users.
Proxies present a potential problem, however, and it's a b ig one. There's no way to tell just which addresses have been allocated to outside users and which to internal users--and that poses a major threat to security.
It's a simple enough situation. Once a DHCP server allocates an address, it doesn't automatically notify the DNS where it's been assigned. That's a tantalizing hole to any industrious cyberthief, who could slip in through the remote access server and obtain a legitimate IP address--without being detected. No need wonder where the packets associated with that address are headed--they're going right through the firewall.
Unfortunately, the security safeguards aren't foolproof. Most remote access products are password-protected, but hackers simply resort to so-called password-cracker code when they want to get in.
Still, some vendors are offering third-party tools that manage IP addresses and inform the DNS dynamically when the addresses have been allocated, and net managers will want to look into these. They should also consider application software that monitors this process--something that watches over all IP connections to the internal Web server, for instance. The more information they have, after all, the easier it is to respond to attacks.
Going with a DHCP solution also means thinking about fault tolerance. In big enterprise nets, it's tempting to go with as few DHCP servers as possible, since they add cost and administrative effort. But when the whole network depends on dynamic IP addressing, it's best not to take the easy way out.
The solution has to be 100 percent fault-tolerant. In other words, the nearest DHCP server can't be sitting on the other side of the WAN link. Recall what could happen if the WAN connection goes down: Users might arrive in the morning only to discover their LAN doesn't work, since their machines no longer have IP addresses.
Remember, when DHCP is used addresses can be set up to expire after a certain amount of time. Clients need to communicate periodically with the server to obtain fresh leases, even if they haven't been reconfigured.
The solution? Set up redundant DHCP servers. Another option is to configure routers to work as backup DHCP servers.
As if things weren't already complicated enough, the integration of private networks with public IP services adds a whole new dimension to the addressing crisis. The addressing options discussed above work just fine in private nets, but it's another story when the Internet or some other public IP network is involved.
Also, in spite of vendors' best efforts to develop solutions for public IP addressing, their offerings may not work with the private addressing schemes. In other words, just as users are discovering ways to use the Internet to link up their corporate sites via VPDNs (virtual private data networks), carriers are putting into place IP address management mechanisms that could be incompatible.
It's a matter of needs outrunning solution s. Corporate users looking to gain access to their private networks over the 'Net want to control how the addresses to resources inside get handed out--but none of the solutions discussed so far have provisions for such control. If an ISP (Internet service provider) employs DHCP to assign addresses, a company can't make sure those addresses go only to legitimate users.
Some vendors--Ascend Communications Inc. (Alameda, Calif.), Microsoft, and Cisco Systems Inc. (San Jose, Calif.) among them--are looking to devise a new breed of public or semi-public nomadic addressing solutions. Furthermore, a protocol known as Mobile IP, developed by Internet researchers, touches on some of these issues.
The technology linking these public IP service solutions is tunneling: It essentially refers to the process of "cloaking" a packet inside another packet, then routing it through the network using the address information of the outside packet. Basically, the remote host communic ates with a server (or other device) and negotiates with it to prove its identity. The server then sets up a "tunnel" through the network using its own address, so that addresses aren't handed out indiscriminately.
Tunneling relies on the internetworking devices (routers, comm servers, or the host machines themselves) at entry and exit points that perform encapsulation and de-encapsulation (see Figure 2). It can be carried out at different layers of the protocol stack. In IP encapsulation, for instance, an IP packet is wrapped around another IP packet. Ascend is following this approach in its Ascend Tunnel Management Protocol (ATMP), which uses generic routing encapsulation as defined in RFC 1071 to bore IP tunnels through the network. (ATMP in its current format will not become a standard but rather an informational RFC.)
|
ATMP involves a gateway communications switch that's sometimes also referred to as a network access server (NAS). First, remote users dial into the NAS over a point-to-point protocol (PPP) connection. They are then authenticated by a customer-owned authentication server, or by a proxy operated by the carrier but slaved from the customer's. After the user's identity has been assured, the NAS builds a tunnel across the network to the corporate site, wraps an IP packet around the packet that came from the client, and forwards it through the tunnel.
The advantage of this approach is obvious: Mobile users c an come into the network using IP and IPX. Those running legacy systems can have their protocols encapsulated, enabling them to link non-IP networks through the Internet and back into the corporate intranet. Access to public Netware Directory Services.
The tunnels don't end there. Microsoft and Cisco are jointly developing a scheme they call the Layer 2 Tunneling Protocol (L2TP) which is now designated RFC 1661. It's based on Microsoft's earlier point-to-point tunneling protocol (PPTP) and Cisco's earlier Layer 2 Forwarding (L2F).
L2TP essentially consists of software that resides on the NAS and the host server. The remote device--a Windows 95 or Windows NT machine--sets up a PPP connection to the NAS. The ISP will do a partial authentication of the person dialing via CHAP (challenge handshake authentication protocol) or PAP (password authentication protocol).
L2TP differs from ATMP in that it performs Layer 2 rather than Layer 3 tunneling. This allows the extensi on of PPP sessions all the way to the server side--which means extensions to PPP like ATCP (Appletalk Control Protocol) and LCP (link control protocol) can be taken advantage of so as to support multiple protocols.
Control is the advantage here. It's possible to keep an eye on the IP addresses inside the private network, since it's the server (rather than the NAS) that's responsible for handing them out.
The IETF (Internet Engineering Task Force) has given the nod to both ATMP and L2TP. After its June meeting, it recommended that Ascend and Microsoft/Cisco put together standards-track documents to be presented at the IETF's next gathering, in December.
There's one more scheme net managers may want to keep in mind: Mobile IP. It governs the routing of IP packets across the Internet while freeing the client from having to change the IP address as it changes its point of entry. Each host has a home location (the location where the network expects it to be), and as the host travels around the network, packets are routed to the home location and then sent to the current site.
There's a bit of cloak-and-dagger work needed to accomplish this. Mobile IP defines foreign agents (FAs) and host agents (HAs), which in reality are routers that help locate the mobile host (MH) as it moves around the network. The spec describes modifications in the host agents that allow them to recognize when the mobile host has moved--and to forward packets accordingly.
Upon configuration, each MH is assigned a home network. That's where traffic is normally routed. But when the MH is traveling, an HA on the home network intercepts the packets and forwards them. And it doesn't do so blindly: The MH uses a special registration protocol to set up a care-of address packet that keeps the HA informed of its location. After the care-of address has been registered with the HA, packets arriving for the MH on its home network are encapsulated by the HA and forwarded to the care-of address.
[ Home ]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|||||||||||
|
|||||||||||
|
 |
|
|
