Stephane St Hilaire writes:
> > Exactly. However, you're still allowed to have the MRU configured
> > manually to some other value at both ends, and you don't *have* to
> > negotiate it.
>
> It's more frequent to see configuration commands to set the MTU than the
> MRU.
It depends on the implementation. Some implementations (e.g., CMU/ANU
ppp) have controls for both.
> At least that's what I've seen. And I don't think that by configuring
> one MTU, the other side's MRU would be in any way affected.
I don't think I understand that. If you *set* the MTU, then you're
explicitly telling your system that the peer's MRU is at least that
large. If you say it's so, then it must be so.
What else could that possibly mean?
> I mean that I
> wouldn't necessarily equate configuring one side's MTU with configuring the
> other's MRU (which will remain unaffected no matter what commands I enter on
> the other equipment).
That's the whole point of implementing negotiation. Negotiation is a
good thing. It allows you to detect cases where the two
configurations are in conflict and (in some cases) recover from the
problem.
The fact that one or more vendors didn't implement useful negotiation
features is a problem to take up with those vendors. ("Dear Vendor:
Please consider implementing this useful feature from RFC 1661 ...")
> Here's another question.
> Let's say router A has an MRU of 10K and a manually configured MTU of 4K and
> that router B has a MRU of 2K (which it does send during LCP negotiations).
> Is it "acceptable" for router A to send frames bigger than 2 K just because
> it is configured to do so ? I would tend to say no.
That's a configuration error. The administrator failed in setting it
up incorrectly, and the implementations are lacking for failing to
provide helpful negotiation to detect the problem.
> > Conflating "unnumbered mode" operation with IPCP negotiation is an
> > implementation error, in my opinion.
>
> Probably. I just didn't want to go into discussing IPCP at this time and
> focus on the MRU "issue".
That's fine. I was just pointing out that the issue is much broader
and more generic: PPP allows you to negotiate things that were (in
prior protocols) explicitly manually configured on both ends of a
link. PPP doesn't *require* you to do that negotiation (which is why
they're "options"), but it's obviously a very good thing to do so, and
usually requires really good justification to avoid it.
For example, some implementations fail to implement the LCP Magic
Number option. This is clearly a Very Bad Thing because it allows
looped-back interfaces to become established, and because implementing
the option is no skin off anyone's nose: you don't need any additional
hardware support to do it. However, it's still an option, and vendors
are free to make implementation mistakes.
> > The "manual configuration" could be as simple as an implementation
> > constant in my view.
>
> Here I don't agree entirely. I do see a difference between something that is
> manually configured (operator intervention) and a "hard coded" default
> setting.
>From the perspective of the protocol, I don't. You either get the
information from negotiation (the peer tells you its MRU, which then
becomes a limit on the MTU that you may use), or you get it through
some authoritative "external" mechanism. The protocol doesn't (and
can't) care where that external mechanism gets its information -- the
protocol knows nothing of user interfaces, #defines, or other such
matters. That's an implementation matter.
> > In order to do that, I think you should document
> > the system usage something like this: "this equipment will fail to
> > operate properly if the peer doesn't support an MRU of at least 4470
> > octets; sorry about that."
>
> You could always dynamically lower your MTU to the other side's MRU, when it
> is discovered.
Assuming your implementation actually is capable of doing that, then,
yes, I agree that this is the best choice. I can imagine
implementations that might not be able to do this -- e.g., ones that
don't bother supporting IPv4 fragmentation and thus fix the MTU to be
equal to the maximum MRU supported on any other interface. Obviously,
those implementations should still negotiate the value; they'd just
have to fail to bring up the link if the peer's MRU is too small.
(Which is exactly the intent of the option; preventing broken
configurations.)
> > That's why PPP added negotiation of these things; to avoid requiring
> > everyone to synchronize their knobs and implementation constants
> > throughout the universe. It's much better when peers negotiate rather
> > than making assumptions. See RFC 1547 section 2.9 (as well as most of
> > section 4).
>
> Well of course that's exactly right, I'm still at a loss to know why an
> implementation supporting a larger MRU than 1500 (when the exact value
> actually varies from one product line to another) wouldn't send that
> information to it's peer. Is the other end supposed to guess or use some
> sort of PPP ESP-Extensions ?
If you don't implement an option, then human intervention of some kind
is required to handle that feature. If it's a fixed MRU or MTU, then
the human will have to read the supplied documentation to determine if
the link will work.
It's out of PPP's hands at that point. There's no way (or reason) to
"require" the implementation of features that vendors don't want to
implement, at least not by way of the IETF.
--
James Carlson, Solaris Networking <james.d.carlson@xxxxxxxxxxxx>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
|
