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

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

On 02/11/2012 20:01, joel jaeggli wrote:
> 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.

So, ask your suppliers to implement RFC 6437/6438. It's the best we can do.

   Brian

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