blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
1.6 Design goals Connected: An Internet Encyclopedia
1.6 Design goals

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2131
Up: 1. Introduction
Prev: 1.5 Terminology
Next: 2. Protocol Summary

1.6 Design goals

1.6 Design goals

The following list gives general design goals for DHCP.

  • DHCP should be a mechanism rather than a policy. DHCP must allow local system administrators control over configuration parameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired.

  • Clients should require no manual configuration. Each client should be able to discover appropriate local configuration parameters without user intervention and incorporate those parameters into its own configuration.

  • Networks should require no manual configuration for individual clients. Under normal circumstances, the network manager should not have to enter any per-client configuration parameters.

  • DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP relay agents.

  • A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance reliability and increase performance.

  • DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations.

  • DHCP must interoperate with the BOOTP relay agent behavior as described by RFC 951 and by RFC 1542 [21].

  • DHCP must provide service to existing BOOTP clients.

The following list gives design goals specific to the transmission of the network layer parameters. DHCP must:

  • Guarantee that any specific network address will not be in use by more than one DHCP client at a time,

  • Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request,

  • Retain DHCP client configuration across server reboots, and, whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism,

  • Allow automated assignment of configuration parameters to new clients to avoid hand configuration for new clients,

  • Support fixed or permanent allocation of configuration parameters to specific clients.


Next: 2. Protocol Summary

Connected: An Internet Encyclopedia
1.6 Design goals

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609