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

[joel jaeggli <[e-mail]>]

On 11/1/12 4:16 AM, Ole Trøan 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.
That horse left the barn when we use L4 headers as part of a 
load-balancing hash key.

While the potential for reordering due to differing path selection is 
superficially irrelevant in the core (I do have four 4 ECMPed 
cross-country paths in the US with about 12ms difference in rtt between 
the shortest and longest), when fronting a stateful device like load 
balancer(s) or firewall(s)  it is not.

Now, if the flow label were reliably immutable and non-zero it might be 
a suitable replacement for the L4 header in the hash calculation.

>>
>> 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.
>
> quite.
> what stops these boxes from filtering IPsec, TLS, or anything that isn't HTTP with a
> whitewashed URL?
So, I'm providing service to an application we are generally inclined to 
limit the service area exposed on  the application, which I think of a 
pretty good fit for L4-leveraging stateless ACLS.
>
> I don't see how we can build protocols to accommodate middle boxes, and
> we have already done RFC3514.
Nor do i think it's likely that we'll come to a great deal of consensus 
on "you absolutely cannot use L4 headers in forwarding filtering 
calculations." it's pretty clear from modern router platforms that 
customers demand those.

What I think we can do is document the observance of the phenomenon, 
acknowledge what gets broken as a result, and perhaps provide advice 
that limits the scope of the damage.
> cheers,
> Ole
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>