Re: Meta-issues: On the deprecation of the fragmentation function

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Fernando Gont writes:
> On 06/30/2013 10:42 PM, C. M. Heard wrote:
> > Fernando> So far (and without having read Ron's recent I-D -- shame on me),
>  it
> > Fernando> looks like the main two reasons for deprecating the fragmentation
> > Fernando> function are:
> > Fernando> 
> > Fernando> 1) The inability of middle-boxes to parse past the first XXX
> > Fernando>    bytes of a packet
> > Fernando> 
> > Fernando> 2) Unavailability of the connection-id (five-tuple) in the
> > Fernando>    non-first fragments.
> > 
> > I disagree -- I think Mark Andrews got it (mostly) right in his message of 
> > Wed, 26 Jun 2013: 
> > 
> > Mark> One needs to get the L4 information the firewall/loadbalancer uses in
> > *each* fragment.
> 
> Do you have this in IPv4? -- No.
> 
> Then, why is it that special in v6?

It's not special in IPv6.  It is however easily *fixable* in IPv6
as the IPv6 packet format was designed to extended.  Additionally
IPv6 is the future and we are still very early into the lifetime
of IPv6.

If one wants to extend IPv4 to have similar capabilities go for it.
I just think doing so will be wasted effort but I'm not going to
stand in the way of someone that wants to do it.

> > However, it won't help middle boxes that implement stateless packet
> > filters.  Indeed, such boxes have fundamental problems with non-first
> > fragments irrespective of how many bytes of extension headers they can
> > parse or whether there are sufficient length limits on the extension
> > header chain that guarantee that the L4 header always appears in the
> > first fragment.
> 
> If you want to do stateless filtering, you should focus on filtering the
> first fragment. And have the end nodes (severs or whatever) implement
> sensible garbage collection for queued fragments (as it's usually the case).

Which is what I do but it doesn't help with those that worry about
those non initial fragments filling pipes and reassembly queues to
the point where legitimate fragments that they want get discarded
too soon.

We need to be able to better classify non-initial fragments.  At
the moment we are classifying them to the L4 type (tcp, udp, icmp6,
ipv6, ipv4, etc.)

> > As I see it, the biggest meta-issue in this discussionis for the IPv6
> > WG is to decide out whether middle boxes that implement stateless packet
> > filters with a "default-deny" policy will be a  significant part of the
> > landscape indefinitely, regardless of what the IETF says about their
> > merits or lack thereof.
> 
> Again: Why is this more special in v6 than in v4?
> 
> -- You seem to be ignored the "questions" that I've asked.
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]