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 bytes 
> of a
> Fernando> packet
> Fernando> 
> Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first
> Fernando> 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?



> 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).



> 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: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to