I don't read the list regularly, but somebody asked me to look over this
thread. I'd like to affirm some of what Carlson said, but correct a few
mistakes. (And I also didn't read most of the HTML mail.)
On Configure-Reject:
Implementation of -Reject is mandatory. But it doesn't mean that you
have implemented MRU or anything else. You're just rejecting a raw
option number.
Carlson says (which confuses the issue a bit) it could also mean
"I know what this is, but I don't want it". That's not correct.
When you know what it is, you MUST send -Nak, instead (except in the
case of boolean options; see, it confuses the issue :-).
On Configure-Nak:
Implementation of -Nak is mandatory. In the case at hand, where an
MTU is configured to 4470, the implementation MAY -Nak with MRU 4470:
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.
That doesn't mean that the peer will send a -Request with MRU 4470.
It "MAY"! (see the full text)
On MRU:
Implementation of MRU is optional. But MRU has a default. In most
cases, that default is 1500. (For example, with some kinds of links,
such as Frame Relay, it's 1600. We chose *NOT* to make it larger for
SONET/SDH.)
At the end of a successful negotiation, when all is said and done,
and the peer has not negotiated MRU, it is absolutely prohibited to
send more than 1500 bytes.
The maximum length for the Information field, including Padding,
but not including the Protocol field, is termed the Maximum
Receive Unit (MRU), which defaults to 1500 octets. By
negotiation, consenting PPP implementations may use other values
for the MRU.
[RFC 1661, Page 5]
It doesn't matter than some miscreant operator has accidentally
configured MTU 4470. Sending 4470 into a link with a 1500 MRU is
non-conformant. As you say in your 1st message, it is "wrong".
(And, in every implementation I've ever done, would be discarded.)
Contrary to Carlson's assertion, manual configuration MUST NOT
ignore the PPP negotiation. PPP is intended to be resilient in
the face of operator error.
...
implementor can specify improvements to the default configuration,
which are automatically communicated to the peer without operator
intervention. Finally, the operator may explicitly configure
options for the link which enable the link to operate in
environments where it would otherwise be impossible.
[RFC 1661, Page 2]
In order for an implementor to specify an improvement, or an operator
to configure an option, that option MUST be implemented, and negotiated
with the peer.
The whole point of PPP is the option negotiation. We already knew that
SLIP sucked, as did a host of others (SLFP, cisco HDLC, and on and on),
because they were hard to successfully configure, as the implementors
all had different ideas about what was "best", and the operators made
too many mistakes.
If it doesn't negotiate options, it's not PPP!
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
|
