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