This section provides a synopsis of NAP enforcement using DHCP. It illustrates how a client can send system health information to a DHCP server and can be granted either restricted or normal access to the network, based on its health state. The DHCP protocol allows for extensibility by defining new DHCP options. NAP enforcement using DHCP defines new options in order to carry the health state and other control information between the client and server.
The following is an overview of the messages exchanged between the DHCP client and server and the details are explained in later sections.
The DHCP client sends a NAP Statement of Health (NAP-SoH (section 126.96.36.199)) as well as the Correlation ID (NAP-CoID (section 188.8.131.52) within the vendor-specific option ([RFC2132], section 8.4) in a DHCPDISCOVER message to determine whether the DHCP server has NAP enabled.
A server that is NAP-enabled and receives a DHCPDISCOVER message including a NAP Statement of Health (NAP-SoH) will indicate that the server supports NAP by responding with a DHCPOFFER including a NAP-SoH, containing the text "NAP" inside the Vendor-Specific option ([RFC2132], section 8.4).
The client then selects an offer from one of the DHCP servers that responded (typically the first offer received). If the DHCPOFFER message corresponding to the selected server includes a NAP-SoH containing the text "NAP" inside the vendor specific option, then the client can send a DHCPREQUEST message to the selected server, containing the SoH in the NAP-SoH option encapsulated inside the Vendor-Specific option.
The DHCP server sends the SoH token received from the client to the health policy server for validation. If the client is found to be compliant with the policies, the health policy server informs the DHCP server that responds with the network configuration options, as usual, and includes an appropriate SoH-Response (obtained from the health policy server) in the DHCP acknowledgment (DHCPACK) message. If the client is not compliant with the health policies, the DHCP server sends the options to the client that quarantines the client (Section 184.108.40.206.1).
A client that has been quarantined due to noncompliance with the administrator-defined health policies is expected to remedy its health state and trigger a DHCP Renew. In this event, the client sends its updated SoH to the DHCP server as part of the Renew transaction. If the client is found to be compliant with the health policy, the DHCP server grants the client normal network access by sending the default configuration values for the default gateway and the subnet mask.
Figure 1: Client request attempt to remedy quarantine state