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 [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
