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

[Fernando Gont <[e-mail]>]

On 10/31/2012 06:00 PM, Joe Touch wrote:
>>> 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?
> 
> The fragment header is not required to be the first header; it's
> required to come after the HBH and before the E2E ones.
> 
> So "must drop IPv6 fragments" implies parsing ALL HBH headers that come
> before the frag header (or you'd never know the frag header was there).

That's why it's very likely that IPv6 packets with extension headers
(whether Frag Header, Dst pts header, or some other one9 will be unreliable.


>>> 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...?
> 
> I'm not sure what bug you're implying above ("we're working on fixing
> that one"), but it's not that the entire chain is split among the
> fragments.

Please see: draft-ietf-6man-oversize-header-chain. I wouldn't call it a
"bug" but rather a pathological case that, while non-existent in
practice, was still allowed by the current specs.

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