Actually, I should think 1280 would be fine for both. The issue tends
to be IPSEC tunnel mode and other tunneling implementations in the
path in between, otherwise I would say "ip data size == 1500". 576
byte frames are a leftover from ARPANET IMPs and Fuzzballs...
The suggestion actually comes from Matt's document, I just pointed it
out and suggested a simple first-burst implementation.
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt
"Path MTU Discovery", Matt Mathis, 22-Feb-05
In context, Max MTU is the max on the local interface. If you're on a
10/100 Ethernet and you're in an end station, you probably don't do
9K byte MTUs, while on a GigE interface you probably do. Depending on
the implementation, you might try to send an 8192 byte ip datagram no
matter what and it might not get out of your system, or you may be
able to read the MTU size.
On Jul 22, 2005, at 11:20 AM, Stephen Sprunk wrote:
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).
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
