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.