Thus spake "Mark Smith" <[EMAIL PROTECTED]>
Thinking about this a bit more, this could probably be fairly easy to
achieve by creating a "onlink-MRU" or "interface-MRU" option for ND
Neighbour Advertisements. There'd need to be some logic in how a
sending node selects the size of the packets that it sends to a
neighbour, based on comparing the values of its own local interface
MTU, the link's MTU as announced in the RA(s) and the target
neighbours announced onlink-MRU, if it announces one.
...
If there aren't any big holes in what I'm suggesting, I'm willing to
spend some time co-authoring an Internet draft on this.
The hole is that there may be an L2 device in the middle which has a lower
MTU than the end hosts. The neighbor MTU is an upper bound, but it's not
guaranteed to work -- you need to probe to see what really works.
Just like PMTUD, you need to periodically probe and adjust to changing
network conditions, including detecting "black holes". Fred Baker suggested
the host send both minimum MTU (576 for v4 and 1280 for v6) and maximum MTU
frames in a given burst and track what gets through. Obviously if the
larger frames work you go with that, but if not you need to ratchet the max
MTU down until things work (while using the min MTU so the session doesn't
stall).
The most perverse scenario I can envision is a network where one host has an
MTU of 9k, another has 8k, one network path has 10k, another path has 3k,
and the path varies every few minutes (and isn't necessarily symmetric).
Obviously it needs to be stated that MTU changes need to be communicated up
to TCP for MSS adjustments -- darn layer violations.
One thing we probably need to decide is if it's "correct" for the above
hosts to (a) fall back to 1500, (b) use 3k all the time, or (c) alternate
between 3k and 8k. I'm leaning towards all three being legal with a
recommendation for the second option
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
