RFC1661 - часть 26
5.3. Configure-Nak
Description
If every instance of the received Configuration Options is
recognizable, but some values are not acceptable, then the
implementation MUST transmit a Configure-Nak. The Options field
is filled with only the unacceptable Configuration Options from
the Configure-Request. All acceptable Configuration Options are
filtered out of the Configure-Nak, but otherwise the Configuration
Options from the Configure-Request MUST NOT be reordered.
Options which have no value fields (boolean options) MUST use the
Configure-Reject reply instead.
Each Configuration Option which is allowed only a single instance
MUST be modified to a value acceptable to the Configure-Nak
sender. The default value MAY be used, when this differs from the
requested value.
When a particular type of Configuration Option can be listed more
than once with different values, the Configure-Nak MUST include a
list of all values for that option which are acceptable to the
Configure-Nak sender. This includes acceptable values that were
present in the Configure-Request.
Finally, an implementation may be configured to request the
negotiation of a specific Configuration Option. If that option is
not listed, then that option MAY be appended to the list of Nak'd
Configuration Options, in order to prompt the peer to include that
option in its next Configure-Request packet. Any value fields for
the option MUST indicate values acceptable to the Configure-Nak
sender.
On reception of a Configure-Nak, the Identifier field MUST match
that of the last transmitted Configure-Request. Invalid packets
are silently discarded.
Reception of a valid Configure-Nak indicates that when a new
Configure-Request is sent, the Configuration Options MAY be
modified as specified in the Configure-Nak. When multiple
instances of a Configuration Option are present, the peer SHOULD
select a single value to include in its next Configure-Request
packet.
Some Configuration Options have a variable length.