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

[Fernando Gont <[e-mail]>]

On 10/31/2012 04:58 PM, Joe Touch wrote:
>> The only thing in that IPv6 would avoid is requiring routers to parse
>> *all* options, just to find the ones that need to be processed by
>> routers.
> 
> Yes.
> 
> However, since fragmentation is near the end of the set of possible
> options, that means that ANY recommendations about how IPv6 routers
> handle options will require deep option parsing. How does that help?

mm.. not sure what you mean. Could you elaborate a bit more?



>> While the IPv6 extension header syntax is good in terms of extensibility
>> (in principle, you can include as many options as you want, it also
>> allows for pathological cases in which the header chain is split among
>> multiple fragments (we're working on fixing that one), and also requires
>> any box that wants to find the upper-layer header to parse the entire
>> IPv6 header chain -- something that a large number of devices cannot do
>> at wire speed.
> 
> I thought we were talking more about fragmentation - which defeats
> filtering on upper layer info anyway.

It *currently* does in v6, but not in v4: in v4 the first fragment
always has, at the very least, the IP addresses, upper-layer protocol,
and transport ports. In v6 (with the current specs), that might not be
the case.


> The non-HBH options can be split across fragments, but not the HBH ones.

And...?



>> For filtering purposes, it'd been interesting to have a pointer to the
>> upper-layer header -- although with the original specs, it might simply
>> not be there. With IPv4, at the very least it's trivial to find the
>> upper layer protocol: just skip the first IHL of the packet, and you're
>> there. With IPv6, at leasts in theory, it might be impossible (unless
>> you reassemble-filter-and-refragment).
> 
> In both cases fragmentation defeats DPI. 

Please see above (the situation in v6 is different from the v4 one9.




>> It's probably time to accept that firewalls and routers implementing
>> ACLs are part of the architecture.
> 
> We need to accept one of three things:
> 
>     DPI is part of the architecture
>         either don't use IPv6 options
>         or don't use IPv6

I'd put it as "DPI is part of the architecture. Beware that IPv6 packets
carrying options are not reliable. Use them at your own risk.".



>> One might argue that the use of
>> firewalls couldn't be foreseen with IPv4. But at the time IPv6 was
>> designed, it was already a reality.
> 
> So that means IPv6 was designed to inhibit the use of options, or
> designed to inhibit its own deployment.
> 
> Seems like the latter is coming to fruition.

I'd argue that the problems with v6 deployment have more to do with
what's noted in RFC 1669 than with DPI. But that train has already left.
So we better try to improve v6 to the best of our possibilities, where
necessary.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492