Erik Nordmark wrote:
Currently, routers can advertise an MTU for a link. That's nice. But what we really need is a way for hosts to find out the MTU each individual neighbor can handle. 100 Mbps and slower ethernet interfaces can typically handle only the standard 1500 byte ethernet MTU, while gigabit ethernet interfaces usually support a much larger MTU.
However, in most cases hosts with different MTUs are present on the same subnet, so simply advertising a larger MTU wouldn't solve this. (Not that this would work anyway as hosts are instructed to only listen to MTU advertisements where the MTU is between 1280 and 1500 (for ethernet).)
But if hosts can tell each other the MTU they support, each set of two hosts is always able to use the largest possible MTU between them. (This would also require a new link MTU option that conveys the maximum MTU the lower layer equipment supports. Switches have their own MTU and even some hubs start doing strange things when a larger than expected MTU is used.)
This might be useful when the L2 doesn't have any MTU limitations.
For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16 bit length field (if I don't misremember). Thus a pair of nodes can agree to use
e.g. 37.5k MTU.
HiPPI is another example of a link with a 16-bit length field. So, you can get up to 64KB MTUs but that might be too much for constrained nodes to accept at high packet arrival rates. If IPv6 ND provided a new option for nodes to send per-neighbor (not per-link) MTU values, the situation for constrained nodes on large links would be greatly improved.
But for links where the L2 has tigher limits things are quite a bit more
difficuly. Taking Ethernet as an example. Having two hosts say that they want to use a 9k MTU over Ethernet is fine as long as the bridges/switches
on the path all support that. But how can the hosts know that?
Even if the hosts can determine this (send a 9k packet and see if it gets
through?), what happens when an addition Ethernet switch or wire comes up
(or goes away) and spanning tree changes the L2 path between those
two hosts so that the packets no longer go through the same set of
bridges/switches?
If you are probing to determine the initial PMTU, the answer is to send periodic additional probes, of course. Routes are going to flap, and paths are going to change - a once-probed MTU cannot be expected to remain stable for any set length of time.
The IEEE transformation obviously just isn't going to happen. Even if itIf one would want to pursue this I think the best way would be for IEEE 802 to define a "frame size discovery" protocol at L2 so that hosts can robustly determine the frame size a given destination MAC address and be notified when it changes. But since Ethernet jumboframes are non-standard (even though more and more commonly used it seems) and there is concern about the coverage of the Ethernet CRC for larger frames, the IEEE has been unvilling to look into this.
somehow did, we would have the entire legacy Internet infrastructure to
overhaul and (as I said to Pekka) I just can't see waiting for an L2 transition
before we move forward seriously with the IPv6 transition.
Once you have such L2 capability then a ND option for "I can receive packets with this MTU" allowing the a larger value than the default link MTU, would make sense to me. But without the L2 capability it doesn't seem very useful.
Disagree here. See my earlier examples on peer-to-peer wireless networking and constrained nodes on large MTU media.
Fred [EMAIL PROTECTED]
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
