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

[Brian E Carpenter <[e-mail]>]

On 31/10/2012 18:58, Joe Touch wrote:
> 
> 
> On 10/31/2012 11:34 AM, Fernando Gont wrote:
>> On 10/31/2012 04:11 PM, Joe Touch wrote:
>>> Yes, but the whole point of the IPv6 option architecture was to avoid
>>> the issues seen with IPv4 options.
>>
>> 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.

No. The only extension header that *needs* to be parsed by intermediate
routers is the hop-by-hop options header, and that is the first one (if
present).

(You can legitimately argue that the hbh header and the routing header
are effectively useless, but that doesn't break fundamental connectivity.)

IPv6 routers should have nothing to do with fragmentation.

The problem is due to middleboxes that break the IPv6 spec by inspecting
any part of the packet beyond the hop-by-hop header and discarding what
they don't understand.

    Brian
> 
> 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?
> 
>> 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.
> 
> The non-HBH options can be split across fragments, but not the HBH ones.
> 
>> 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. But then so does IPsec.
> 
> Yes, IPv6's chained header structure is not DPI-friendly. But this isn't
> news, is it?
> 
>>> Consider that:
>>>
>>>      - routers don't like fragments because they can't inspect them
>>>
>>>      - so we tunnel and fragment in a higher level protocol
>>>
>>>          the router now needs to implement the higher protocol
>>>          and still fragment or else we cannot have tunnels
>>>
>>>          the routers on the path still cannot inspect the
>>>          higher-level fragments
>>>
>>> So we're back to the reason this all breaks - routers doing something
>>> that we simply cannot support in the architecture.
>>
>> 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
> 
>     IPv6 options are part of the architecture
>         DPI isn't meaningful anymore
> 
>> 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.
> 
> Joe
>