RFC1661 - часть 27

Since the

Nak'd Option has been modified by the peer, the implementation

MUST be able to handle an Option length which is different from

Simpson [Page 30]

RFC 1661 Point-to-Point Protocol July 1994

the original Configure-Request.

A summary of the Configure-Nak packet format is shown below. The

fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Code | Identifier | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options ...

+-+-+-+-+

Code

3 for Configure-Nak.

Identifier

The Identifier field is a copy of the Identifier field of the

Configure-Request which caused this Configure-Nak.

Options

The Options field is variable in length, and contains the list of

zero or more Configuration Options that the sender is Nak'ing.

All Configuration Options are always Nak'd simultaneously.

5.4. Configure-Reject

Description

If some Configuration Options received in a Configure-Request are

not recognizable or are not acceptable for negotiation (as

configured by a network administrator), then the implementation

MUST transmit a Configure-Reject. The Options field is filled

with only the unacceptable Configuration Options from the

Configure-Request. All recognizable and negotiable Configuration

Options are filtered out of the Configure-Reject, but otherwise

the Configuration Options MUST NOT be reordered or modified in any

way.

On reception of a Configure-Reject, the Identifier field MUST

match that of the last transmitted Configure-Request.

Additionally, the Configuration Options in a Configure-Reject MUST

Simpson [Page 31]

RFC 1661 Point-to-Point Protocol July 1994

be a proper subset of those in the last transmitted Configure-

Request. Invalid packets are silently discarded.

Reception of a valid Configure-Reject indicates that when a new

Configure-Request is sent, it MUST NOT include any of the