[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "RFC 2461bis" issue: MTU handling

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 
>>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

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.

>If 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.
The IEEE transformation obviously just isn't going to happen. Even if it
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 
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.


>   Erik
>IETF IPv6 working group mailing list
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6