Re: [v6ops] PMTUD forever, was: MTUs on the general Internet

[Jeroen Massar <[e-mail]>]

On 2014-12-05 12:00, Philip Homburg wrote:
> In your letter dated Fri, 05 Dec 2014 11:56:01 +0100 you wrote:
>> On 2014-12-05 11:38, Philip Homburg wrote:
>>> Another way forward is to have to 'internet facing' side of the tunnel forward
>>> large packets fragmented.
>>
>> Only end hosts do fragmentation in IPv6.
> 
> I was talking about tunnels. In general, tunnel endpoints are hosts.
> 
> In case it wasn't clear, I meant fragmenting the outer (IPv4) packet,
> not the inner (IPv6) packet.

Not only tunnels have a lower MTU. Just adding an extension header
somewhere and you already lower the payload size.


Doing fragmentation means sending at least two packets, maybe one gets
lost, what to do, resend, wait? Note that most tunneling protocols do
not resend data (unless they run over TCP and then TCP handles it).

It also pushes the burden of refragmentation towards the receiver of the
packet, which suddenly becomes open to a fragmentation attack, which is
likely not what they will want to see happening (enough crap gets send
to those boxes already because someone is misbehaving on IRC).


Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe
to use for tunneling and other constructs where one does not have a full
Ethernet MTU.

Just sticking everywhere to 1500 is not a solution. Unless one wants to
define the minimum MTU for IPv6 as 1500. It is still a minimum and there
are speakers out there that do 9000 with ease, just not intra-AS, and
intra-AS is where these kind of PTB and ICMP ratelimiting problems
exist: in somebody elses network.


As for implementations doing fragging of tunneled packets, check:
http://backreference.org/2013/07/23/gre-bridging-ipsec-and-nfqueue/

Which gives a nice overview why that further is a bad idea and why it
typically will not work anyway unless getting very hacky.

Oh, and do apply that to every deployed host on the Internet please.


Search also for frag/mtu/df/PMTUDISC in:
 https://github.com/torvalds/linux/blob/master/net/ipv6/sit.c

yes there is a magic 'pmtudisc' option for tunnels, but not enabled per
default and it does not work as expected.

For some fun reason, only custom TTLs get a frag_off filled and thus
possibility to not frag. Thus if one does not specify a TTL at creation
time (advised anyway as the default used to be 255 or actually 'TTL from
the tunnel device') the DF flag does not get set...

Also check how often the MTU is forced to the IPv6 minimum MTU. Fun also
that that code is so well commented on why certain pieces of code are
there let alone what they do.

These:
https://github.com/freebsd/freebsd/blob/master/sys/netinet/in_gif.c
https://github.com/freebsd/freebsd/blob/master/sys/netinet/ip_output.c
read sooo much better than the Linux equivalent... comments, what a
useful mechanism for documenting why things are done.

As gif does not set ip_off, DF is not set and thus ip_output will
fragment here.


Or summary on those two platforms:
 FreeBSD	fragments packets (DF not set)
 Linux 		fragments normally (DF not set), but most configs
		define TTL and thus DF gets set and packets get dropped
                need to optionally add hack to drop DF bit.


I am quite sure that at least in the SixXS userbase nobody uses this
feature, as sixxsd does not do reassembly for proto-41 packets...
(and the default MTU is 1280 as mentioned before).

Greets,
 Jeroen