3.1.5.3 Receiving a DHCPACK Message in Response to a DHCPINFORM Message

If the DHCP client's NAP-Capable Server state is set to "Unknown" and the client receives from the server a DHCPACK message that contains the NAP-SoH (section 2.2.1.1) option either of length 3 and data as the string "NAP" or of length greater than 3, it MUST set its NAP-Capable Server state to "Yes". The NAP-SoH (section 2.2.1.1) option is extracted from the DHCPACK message by calling DhcpExtractVendorSpecificOption ([MS-DHCPE] section 3.1.7.2). In addition, the client MUST discard the DHCPACK message and retransmit the DHCPINFORM message with the updated SoH message ([TNC-IF-TNCCSPBSoH]) retrieved by calling DhcpClientGetSoH (section 3.1.7.1) and sending the SoH token in the NAP-SoH option. It MUST also include a NAP-CoID option (section 2.2.1.3) in this message.

The NAP-SoH option and NAP-CoID option are appended to the DHCPINFORM message packet by calling DhcpAppendVendorSpecificOption ([MS-DHCPE] section 3.1.7.1) with appropriate parameters provided as input.

If the DHCP client's NAP-Capable Server state is set to "Unknown" and the client receives a DHCPACK message from the server that does not contain the NAP-SoH option or contains the NAP-SoH option of length 3 or less, but the data as string is not "NAP", the client MUST set its NAP-Capable Server state to "No" and process the rest of the message as if none of the options defined in this specification were present in the message.

If the DHCP client's NAP-Capable Server state is set to "Yes" or "No", the message SHOULD be processed as specified in section 3.1.5.2. However, if the client has its NAP-Capable Server state set to "Yes" and receives a DHCPACK message in response to a DHCPINFORM message, the client MAY<6> ignore the NAP-SoH option and the NAP-IPv6 (section 2.2.1.4) option (if any) and process the message as if they were not present in the message.