Iljitsch van Beijnum wrote:
On 27-jul-2007, at 13:05, John Heffner wrote:
(Assuming nothing bad happens to the
network gear by sending oversized frames -- as you mentioned, this has
potential to cause some problems on very old ethernet gear.)
Right, that's why I feel it's very important to have a mechanism that
makes it possible to tell all hosts to reduce their MTU with one setting
in one place, rather than have to do this on all hosts individually.
It's a good goal. I'd like to address this in a separate email once
I've given your draft some more careful thought. I think Matt Mathis
has some input on this as well.
(Note, I assume here that MTU==MRU in all cases.) Since the
router does not know the MTU of each host on the subnet, the only
compliant thing for it to do is to use the smallest possible (e.g.,
standard) MTU for that network.
Why is this true for the router but not for other hosts? The issues are
the same, assuming that all hosts (including the one reachable through
the router) implement RFC 4821.
The router is different because it must generate ICMP PTB messages with
the correct next hop MTU. There's no way for the router to do 4821 like
hosts can.
Obviously, that's an "interesting" assumption to make, especially as
there's no obvious way to validate its veracity.
Sorry for the confusion. This assumption is only for simplicity of
language. It doesn't affect the validity of what I was saying.
Hosts sending from outside the router
using 4821 will work fine, but any host outside the router with a larger
MTU (that may be valid on its own network), and still relying on
classical 1122/1982 pmtud, will break.
Right.
In my mind, the question of what the router should do is the most
important in any discussion of mixed-MTU subnets. In order to generate
the correct ICMP PTB messages, a route with a large-MTU interface on a
mixed-MTU subnet would need to know the individual MTUs of each host on
that subnet. Neighbor discovery seems like the place you'd want to do
this. However, I think this is a tricky problem, and I'm not sure your
proposal solves it in full. (Think this over and tell me if I'm wrong
-- I'm not sure I understand your "The MTU detection message"s fully.)
This is extremely simple: put the MTU in neighbor discovery packets so
that nodes learn their neighbor's MTU along with the MAC address.
I wouldn't go so far as to say it's extremely simple. Making the
neighbor discovery work correctly in all cases, in the presence of
switches that don't participate, and without too much overhead, seems
tricky to me. Again, I'll think a bit harder on this and address it in
another email.
One thing to note is that if you imagine a world where the vast majority
of hosts with large MTUs use 4821, it may be operationally acceptable to
deliberately break classical pmtud by not generating ICMP PTB messages.
This may not be totally far-fetched, since classical pmtud is so
fragile in practice that large MTUs are currently quite rare. This is
an imperfect solution, but with some luck it may be just good enough.
Why would you want to do that? Even with full RFC 4821 support regular
PMTUD is still extremely useful because it gives you the exact value of
the path MTU immediately after sending an oversized packet.
It's not what I would want in an ideal world. However, if other
solutions don't materialize, this is one possible avenue of evolution.
Attacking the problem in multiple complimentary ways is always a good
thing. :)
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
