Re: Responding to Ron's comment about removing fragmentation

[Jeroen Massar <[e-mail]>]

On 2014-11-14 22:24, Carsten Bormann wrote:
> I just sent Jeroen a message privately that I think could help
> framing the discussion about active measurement of MTUs.  See also
> the discussion about multi-MTU later in intarea.

Yep, was reading through it ;)

Keeping it on list is a better idea indeed. Lot more brain power here
next to a lot more experienced people who can give backing reasons why
something would and would not work.

> One related draft is: 
> http://tools.ietf.org/html/draft-bormann-intarea-alfi-04.txt
>
> We haven’t managed to find a way to make this work (except for “5.
> Another way of doing it”, and you be the judge whether this is the
> desirable way forward).

The biggest problem with having a MTU that is allowed to very small is a
spoofing attack that causes a host to start sending for instance 80
bytes packets

It does not matter if the signaling of that small MTU is done with PMTUD
or in a variable somewhere dubbed the MUALTU. If one is able to tell
another host "send very small packets" you got an attack on your hands.


I am thus of the opinion that our semi-random (anybody know how that
number came to be?) minimum MTU of 1280 is a great number as it gives us
a comfortable amount of data to be sent per packet, while not losing too
much (~18% of data given a IPv6+TCP header) on standard Ethernet of 1500
which is the norm.

Of course the real problem here is that attackers can spoof. And we all
know how hard the operator community is not deploying the advised
measures against that...

> There are a number of very good uses for a way to collect information
> on the current path, and PMTUD is just the most pressing one (see RFC
> 4782 for a more esoteric one).

4782 is way too complex and is very focused on TCP, there is more than
that out on the Internets, this magic UDP thing and SCTP for instance.

Just starting sending at 1280 while noting the MTU in the IPv6 header
(instead of this useless Flow Label thing) allows routers to indicate,
in the packet flow, what the MTU is and voila, problem solved, you can
scale your MTU to whatever you want.

Keeping routers simple and stupid is the best plan we have and one of
the best ideas backing IPv6.

> We can’t put all of them in the flow
> label.  Hop-by-hop options are the architecturally correct way, but
> these seem to be irretrievably damaged by current deployment.

Hop-By-Hop options are useless for routers because it requires parsing
after the first 40 bytes of the header. Routers should not have to
bother with that (looking behind the first 40 bytes of a packet) at all.

As an example, sixxsd does not look behind the first 40 bytes unless it
is a locally addressed packet. For forwarding it thus is really fast:
 - check src address is correct for the interface it came in on
 - update hop limit (ICMP Unreach when 0)
 - lookup egress interface based on destination address
 - check MTU and send PTB if needed
 - send packet on egress interface

(ignoring things like 'is that interface up' etc)
But it is a really fast process. The SHA1 verifies of AYIYA are the
heavy weights in the process, not the actual process of forwardings.

Also, one cannot add an option in the middle of a path as that option
might not fit. (eg sending a 1280 byte packet when the MTU is 1280).

Greets,
 Jeroen