3.1.5 Message Processing Events and Sequencing Rules
The NKPU Protocol exchange consists of a client request followed by either a server reply or a time-out failure. In case of a failure on one transport, a client SHOULD retry the request on another supported transport. The first request SHOULD use DHCPv6 as the transport, providing that the client supports DHCPv6. If the client does not support DHCPv6 as a transport or there is a failure or no response with DHCPv6 as the transport, the client SHOULD then try DHCPv4 as the transport, providing that it supports DHCPv4.
On DHCPv4, clients process DHCP messages as specified in [RFC2131] sections 3 and 4, with additional behavior as specified therein.
On DHCPv6, clients process DHCP messages as specified in [RFC3315], with additional behavior as specified therein.
If the data or the data length of the field for any of the options in a DHCP message received by clients implementing this protocol is inconsistent, the client MUST discard the message and take no further action.
A client implementing this protocol MUST also ignore the following:
All DHCPv4 message types except BOOTREPLY [RFC2131].
All DHCPv6 message types except DHCPv6 Reply [RFC3315].
Any BOOTREPLY message that does not contain a DHCPv4 Vendor Specific Information Option, a DHCPv4 Vendor-Identifying Vendor-Specific Information Option, and a Vendor Class Identifier Option, as specified in section 2.2.1 of this specification.
Any DHCPv6 Reply message that does not contain a DHCPv6 Vendor Class Option and a DHCPv6 Vendor Specific Information Option, as specified in section 2.2.1 of this specification.