[153365] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Jimmy Hess)
Tue Jun 5 14:20:52 2012
In-Reply-To: <B0C922CF-AC23-45EF-9F0B-EF2F24011334@delong.com>
Date: Tue, 5 Jun 2012 12:15:26 -0500
From: Jimmy Hess <mysidia@gmail.com>
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 6/5/12, Owen DeLong <owen@delong.com> wrote:
[snip]
> But that's a whole lot more packets than working PMTU-D to get there and
> you're also waiting for all those round trips, not just the 4 timeouts.
> The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at
> 100ms is 2.2 seconds. That's a long time to go without first data packet
I'm only suggesting probing to discover the MTU between neighboring
endpoints directly connected to the same subnet -- Layer 2
interconnect. PTMU doesn't work, because devices know the MTU of
_their link_, but not necessarily the MTU of every intervening bridge
or L2 tunnel, Not for IP end-end-to-end MTU discovery.
The "too big packet" forwarded is just discarded by the L2 bridge,
there's no ICMP packet that can result from that, the L2 bridge might
not even have an IP address to source one from, so the PMTU method
which relies on ICMP alone cannot possibly work.
The router after discovering the local MTU constraints to its
neighbors would then be responsible for sending TooBig messages as
needed or passing on the MTU constraint.
You've got an issue if there are 100ms between two peers on your LAN.
You're right, you don't need to probe for possible MTUs below 1280.
--
-JH
