Re: "RFC 2461bis" issue: MTU handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "RFC 2461bis" issue: MTU handling
Erik Nordmark wrote:
No, the existing option is only usable for lowering the MTU used within
a subnet to a value lower than what the "IP over ..." RFC prescribes.
We also need a way to convey the maximum packet size that layer 2
equipment can handle. I think this should be an option that is similar
to, but different from the existing MTU option.
Just to restate what you are saying differently so that others might understand
it. Today with have a MTU specified in the IPv6 over foo documents.
We have an MTU option in router advertisements that can be used to
lower that number - which is useful(?) for the last century problem of
bridging Ethernet and FDDI together with half-broken fragmenting
bridges - can get the FDDI attached nodes to use 1500.
These are what I referred to as "transluscent bridges" in an earlier
message. Perhaps that term (circa 1988/89) was only used within
certain limited enclaves, e.g., Digital Equipment Corporation.
What Iljitsch is sayin is that if the L2 might support a larger MTU
e.g. by ensuring that all the switches support Ethernet jumboframes
one could add an option (which he calls "MAX MTU" - "maximum L2 packet size"
might be a more differentiated term).
I don't agree that ensuring that all switches support Ethernet
jumboframes is a pre-requisite for routers to advertise a larger
Max_MTU. Even if only *some* of the switches support the
jumboframes, it should be OK as long as...
But if the routers advertised this option, it still wouldn't mean
that a given host was capable of receiving L2 packets of that size.
Hence the need for each host to advertise their MRU in NS/NA type
packets.
...as long as the hosts *also* do this.
I think this works as long as the network admin can ensure that all the
switches in an L2 in fact support the larger size.
Well, I just don't see this as realistic except in certain constrained
enclaves. So, even if we have each host advertising its MRU (e.g.,
in NS/NA type packets) we still have to verify that packets of
that size actually arrive and w/o incurring harmful levels of L2
fragmentation. Also, since L2 paths can fluctuate, we would need
to re-verify periodically.
Whether it is important to solve this using additional protocol mechanisms,
or whether it is sufficient to have folks hand-craft VLANs containing
the hosts that support the larger size, is hard to tell.
I fall on the side of the former. Even if folks hand-craft the
VLANs, they can still get instances of link MTU reductions
in the L2 path between any pair of hosts unless they have
complete assurance that all of the switches in the path support
the larger MTU - and, that the L2 paths can't fluctuate such
that links with smaller MTUs are incorporated.
Fred
ftemplin@iprg.nokia.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.