RINA - scott whaps at the nanog hornets nest :-)

George Bonser gbonser at seven.com
Sat Nov 6 17:14:12 CDT 2010

> As long as the implementations are few and far between:
>     https://www.psc.edu/~mathis/MTU/
>     http://www.ietf.org/mail-archive/web/rrg/current/msg05816.html
> the traditional ICMP-based PMTUD is what most of use face today.
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no

It is already the standard with currently shipping Solaris and on by
default.  It ships in Linux 2.6.32 but is off by default (sysctl I
referred to earlier).  It ships with Microsoft Windows as "Blackhole
Router Detection" and is on by default since Windows 2003 SP2.  The
notion that it isn't widely deployed is not the case.  It has been much
more widely deployed now than it was 12 months ago. 

And again, deploying 9000 byte MTU in the MIDDLE of the network is not
going to change PMTUD one iota unless the rest of the path between both
end points is 9000 bytes since the end points are already probably 1500
hundred anyway.

Changing the MTU on a router in the path is not going to cause the
packets flowing through it to change in size.

It will not introduce any additional PMTU issues as those are end-to-end
problems anyway, if anything it should REDUCE them by making the path
9000 byte clean in the middle, there shouldn't BE any PMTU problems in
the middle of the network and things like reduced effective MTU from
tunnels in the middle of networks disappears.

For example, if some network is using MTU 1500 and tunnels something
over GRE and doesn't enlarge the MTU of the interfaces handling that
tunnel, and if they block ICMP from inside their net, then they have
introduced a PMTU issue by reducing the effective MTU of the
encapsulated packets.  I deal with that very problem all the time.
Increasing the MTU on those paths to 9000 would enable 1500 byte packets
to travel unmolested and eliminate that PMTU problem.  In fact, many
networks already get around that problem by increasing the MTU on
tunnels just so they can avoid fragmenting the encapsulated packet.
Increasing to 9000 would REDUCE problems across the network for end
points using an MTU smaller than 9000.

More information about the NANOG mailing list