Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Mark Smith <[e-mail]>]

Hi,


>________________________________
> From: Fernando Gont <[e-mail]>
>To: Lorenzo Colitti <[e-mail]> 
>Cc: Mark Smith <[e-mail]>; V6 Ops <[e-mail]> 
>Sent: Friday, 26 October 2012 11:51 PM
>Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 
>On 10/25/2012 10:53 PM, Lorenzo Colitti wrote:
>> For example, I personally think that fragments are more trouble than
>> they're worth, they don't work in today's Internet (IPv4 *or* IPv6),
>> create security issues (see e.g., Fernando's issues with fragmented RAs,
>> plus an history of security issues in fragment-handling code) and that
>> applications are much better off implementing their own fragmentation
>> above UDP or whatever else they may use. 
>
>I'd mostly say "+1" with everything you've said above.
>

I don't really disagree with that either, it's more that fragmentation is a

current capability of IPv6, so I think the IETF's recommendation should be
that it is enabled by default on the Internet. I think that recommendation
fits the robustness principle too - "..., be liberal in what you accept
from others".

If the IETF recommends against forwarding fragments, then I think that

creates the obligation to provide advice and methods on what do instead,
which might include specifying a standardised UDP fragmentation method,
and provide alternative methods for protocols that utilise IP layer
fragmentation.

Fragments may still be in use, however they may not used much at the

application layer. OSPFv2 and OSPFv3 uses them instead of implementing
it's own fragmentation mechanism (and that may be across multiple hops
in the case of a OSPF virtual link), and they are likely to be commonly
used in IPsec and GRE tunnels (PMTUD across the tunnel path and having
the tunnel MTU adjusted to it is a more advanced capability). My memory
is vague, however I also seem to remember seeing them being sent by load
balancers on the Internet too. At a residential ISP, this was no issue,
as we didn't perform any stateful firewalling at the edge of our network.


I think another thing to bare in mind is a lot of peoples' common approach

of taking a shortcut by just doing what the "experts" say. While
people like us might be interested in the details and pros and cons
of fragmentation, I think a lot of people just want the experts to say
"enable them" or "disable them", so they can move onto working on something
else on their list of things to do. If we don't provide that advice,
then people will default to what they believe is the safe position, and
their safe position is "if in doubt, switch it off". I think this is the
explanation as to why people have disabled all ICMPv4, breaking PMTUD -
they've heard that "ICMP is used by ping, and ping is bad security wise"
(i.e. the topology/host topology argument), so rather than investigating
the details, just universally disable ICMP. As they themselves rarely see
the consequences of PMTUD failing, they think what they've done is fine -
and give that advice to others if they're asked. That approach has propagated
to the point where MSS hacking on all subscribers is necessary in a broadband
scenario if you have a dumbell MTUs situation (i.e. PPPoE between cust LAN and
Internet)


>
>> Unfortunately, it doesn't seem
>> likely that this working group will reach consensus on such a
>> recommendation.
>
>Okay, how about:
>
>Plan A: Try to sense whether we can agree on advice
>Plan B: If we can't, just document the facts
>
>Cheers,
>-- 
>Fernando Gont



Regards,
Mark.