• Solaris 7 Implementation Details
  • Configuration and Management
  • Windows NT Server 4.0 Implementation Details
  • Windows 2000 Server DHCP Implementation Details
  • Rouge DHCP Server Detection
  • White Paper Abstract

    Download 0.84 Mb.
    Hajmi0.84 Mb.
    1   ...   6   7   8   9   10   11   12   13   ...   32

    Dynamic Host Configuration Protocol (DHCP)

    The Dynamic Host Configuration Protocol(DHCP) is the IETF’s standard for centrally managed TCP/IP network addressing and host configuration. For the purpose of this review, each operating system will be reviewed on its ability to provide an IETF-compliant DHCP implementation, as well as its value-added services to ease DHCP service implementation and management.

    Solaris 7 Implementation Details

    Solaris 7 provides full support for the DHCP protocol as specified by the IETF’s latest specifications. The Solaris 7 DHCP implementation supports the following IETF RFCs for the DHCP protocol:

    • RFC 2131 – Dynamic Host Configuration Protocol.

    • RFC 2132 – DHCP Options and BOOTP.

    Solaris 7 also provides support for the BOOTP protocol (a predecessor of DHCP that allocated IP addresses only without any configuration information). The following RFC standards are supported:

    • RFC 1497 – BOOTP Vendor Information Extensions.

    • RFC 1534 – Interoperation Between DHCP and BOOTP.

    • RFC 1542 – Clarifications and Extensions for the Bootstrap Protocol.

    Configuration and Management

    Configuration and management is handled by a number of command line tools (such as dhtadm – the DHCP configuration table management utility). Capabilities are little more than the ability to configure the server service and the address pool, and turn the service on or off.


    Finally, no fault-tolerance features are provided as part of the Solaris Easy Access Server DHCP implementation. Consequently, if a server goes down and all leases expire, users will be unable to obtain network connectivity until the DHCP service is restored.

    Sun Enterprise Server, on the other hand, includes Sun Cluster. With Sun Cluster, you can configure failover support for DHCP.

    Windows NT Server 4.0 Implementation Details

    Windows NT Server 4.0 provides full compatibility with the DHCP protocol as specified by the IETF’s original specification for DHCP. The Windows NT Server 4.0 DHCP implementation is fully compliant with the following IETF RFCs:

    • RFC 1533 – DHCP Options and BOOTP Vendor Extensions.

    • RFC 1534 – Interoperation Between DHCP and BOOTP.

    • RFC 1541 – Dynamic Host Configuration Protocol.

    • RFC 1542 – Clarifications and Extensions to the Bootstrap Protocol.

    Configuration and Management

    On Windows NT Server 4.0, DHCP is managed as its own Windows NT Service. A graphical DHCP Manager utility is provided for DHCP administration. The administration utility must be run on the server console – remote DHCP server administration is not supported. Configuration information itself is stored in a Microsoft Jet-derived database. Command line utilities are provided for the backup and maintenance of this database.

    DHCP support has existed on Windows NT Server since the product’s inception with Windows NT Advanced Server 3.1. Because the implementation has remained largely unchanged, upgrades from prior versions are a non-issue for Windows NT Server customers.


    No fault-tolerance features are provided with the Windows NT Server 4.0 DHCP implementation. Consequently, if a DHCP server fails and all leases expire, users will be unable to obtain network connectivity until the DHCP service is restored.

    Windows 2000 Server DHCP Implementation Details

    Windows 2000 Server improves on the Windows NT Server 4.0 DHCP implementation It supports all of the latest IETF specifications for the protocol. At the most basic level, full support for the following IETF RFCs is provided:

    • RFC 2131 – Dynamic Host Configuration Protocol.

    • RFC 2132 - DHCP Options and BOOTP Vendor Extensions.

    • RFC 1534 – Interoperation Between DHCP and BOOTP.

    • RFC 1542 – Clarifications and Extensions to the Bootstrap Protocol.

    For those unfamiliar with the current status of DHCP, RFC 2131 officially supercedes RFC 1541, which was used as the basis of the Windows NT Server 4.0 DHCP implementation.

    Additionally, for Windows 2000 Server, many new features have been added to the DHCP service support. Most important is the addition of enhanced monitoring and statistical reporting capabilities to the DHCP manager utility. Specifically, the DHCP server will now provide notification when IP addresses are running below a user-defined threshold. For example, an alert could be triggered when 90 percent of the IP addresses available have been assigned. A second, escalated alert could then be triggered when the available IP address pool is exhausted.

    Configuration and Management

    The DHCP Manager now provides graphical display of statistical data. This helps administrators monitor DHCP system status, such as the number of available versus depleted addresses, or the number of leases being processed per second. Additional statistical information includes the number of messages and offers processed. It also includes the number of requests, acknowledgements, declines, negative acknowledgements (NACKs), and releases received. The total number of scopes and addresses on the server, the number used, and the number available are also displayed. These statistics can be provided for a particular scope or at the server level, showing the aggregate of all scopes managed by that server.

    Vendor Specific Options

    Vendor specific options and user class support has also been added in Windows 2000 Server DHCP implementation. Vendor classes are defined by specific vendors and are triggered by data bits that determine whether a given option class is standard or vendor-specific. Once identified as vendor-specific, DHCP looks up the configuration as specified, enabling compelling custom applications for enterprise networks to be introduced quickly. Vendor class and vendor options are currently undergoing evaluation by the IETF and are described in RFC 2132.

    User Class Support

    User class support is also provided as part of the Windows 2000 Server DHCP implementation. This allows DHCP clients to specify the type of client they are, allowing for customized configurations to be easily dispatched. This provides the systems administrator with a greater degree of flexibility than available in either the Solaris 7 or Windows NT Server 4.0 DHCP implementation. For example, laptop clients could be assigned shorter leases than desktop clients. If user class settings are left unused, default settings are assigned.

    Multicast Support

    Multicast addresses can now be assigned, in addition to unicast addresses, by the DHCP service in Windows 2000 Server. A proposed IETF standard is used as the basis for multicast address allocation. This benefits systems administrators by allowing multicast addresses to be assigned and managed in the same fashion as unicast addresses, allowing for complete leverage of the existing DHCP infrastructure. Multicast support is composed of two parts. The first is the server component, where multicast scopes and IP address ranges are created and managed just as if they were unicast addresses. The second component is a set of customizable client-side APIs, which are used within the customer’s application to request, renew, and release multicast addresses. This provides a considerable benefit to customers developing multicast applications, such as streaming media-based solutions.

    Rouge DHCP Server Detection

    Rogue DHCP server detection support has been added in Windows 2000 Server. With this feature, rogue or inadvertently configured DHCP servers will be unable to create address assignment conflicts on customer’s networks. This feature is implemented through the Active Directory service. A list of authorized servers in Active Directory is maintained. If an unauthorized server comes online, it will not receive an authorization from the directory and will not allow itself to process client requests. If a server comes up that is in a workgroup rather than being a domain member, the server will send out a DHCPINFORM broadcast. If a registered DHCP server is online and acknowledges the workgroup DHCP server, the workgroup DHCP server will treat itself as rogue and not process client requests. If no registered servers are online when the workgroup DHCP server comes online, DHCPINFORM broadcasts are automatically sent every five minutes. This allows the workgroup DHCP server to be classified as rogue and stop servicing requests if a registered server comes online.


    Windows 2000 Server Clustering Services, available in Windows 2000 Advanced Server, provide the foundation for fully redundant, fault-tolerant DHCP services. Clustering Services, when used with DHCP, can provide for significantly higher availability, easier manageability, and greater scalability than would otherwise be available. The DHCP server service can now be run natively as an application on top of Clustering Services, with the DHCP configuration database stored on the cluster’s shared disk array. If a failure occurs on the first node in the cluster, the name space and all services are transparently moved to the second node. This means that there will be no changes for the client, which will see the same IP address for the clustered DHCP server. Unlike Windows NT Server 4.0 or Solaris 7 implementations, DHCP services will remain totally uninterrupted in the event of a system failure.

    DHCP Client Support

    DHCP client support has also been improved in Windows 2000 Server. Previously, if a client were brought online and a DHCP server were unavailable, the machine would not have the TCP/IP protocol configured. With Windows 2000, the DHCP client service uses a two-step process to configure the client, ensuring that the TCP/IP stack is fully initialized. When a machine is booted, it will first attempt to locate a DHCP server. If this fails, it will automatically configure itself with a selected IP address. If the client had a previously obtained lease, the client will try to ping the default gateway listed in the lease. If it is successful, it assumes that the client has not been moved and continues to use that same lease. The client will then continue to try to renew the lease until a DHCP server becomes available. If the ping fails, the client assumes that there are no DHCP services available and automatically configures itself. It will then automatically keep trying to reconfigure itself every five minutes until a DHCP server comes online.

    DHCP Summary

    The Windows 2000 Server implementation of DHCP contains true monitoring and statistical analysis capabilities, making it easy to track for the system administrator. Many other benefits are added, including vendor and user classes, rogue DHCP server detection, fault tolerance via Clustering Services, and automatic client configuration. Such features are , unequaled in Windows NT Server 4.0 or Solaris 7. For the enterprise customer where availability is paramount, rogue DHCP server detection and support for Clustering Services are extremely important. These two features virtually guarantee protection from either rogue servers or system failures.

    The Solaris 7 DHCP implementation lacks many of the features found in Windows 2000. However, by offering the Dynamic BOOTP feature in addition to basic DHCP services, it provides a more full-featured solution than Windows NT 4.0. Dynamic BOOTP will prove to be of considerable use in environments where not every client is DHCP-enabled and where systems administrators manage the network via central IP address allocation.

    Of the three implementations, Windows NT Server 4.0 DHCP service is the most dated. It offers nothing in the area of fault tolerance and no features beyond basic RFC compliance. Additionally, because Windows NT Server 4.0 shipped an entire generation before Windows 2000 Server, it is only compliant with the original DHCP specifications, rather than the current specifications.

    1   ...   6   7   8   9   10   11   12   13   ...   32

    Download 0.84 Mb.

    Bosh sahifa

        Bosh sahifa

    White Paper Abstract

    Download 0.84 Mb.