Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

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

> The fallback is to only hash over addresses.

Hashing over addresses+flow-label is fine too. If the flow label
is zero, it's the same thing. If the flow label is set properly,
it's a better hash.

I believe this is covered in the various relevant RFCs already
(6437, 6438 and 7098).

Regards
   Brian

On 28/07/2018 10:38, Tom Herbert wrote:
> On Fri, Jul 27, 2018 at 11:54 AM, Fernando Gont <[e-mail]> wrote:
>> Tom,
>>
>> On 07/27/2018 07:20 PM, Tom Herbert wrote:
>> [....]
>>>>
>>>> For example, what happens with EHs has a lot to do with engineering:
>>>> they could be made to work (e.g., remove performance impact), but
>>>> devices would probably be more expensive. Folks buying gear wouldn't pay
>>>> for something that its not used in practice, and vendors wouldn't just
>>>> "improve" the boxes for free. -- yeah, you could argue that "hey, there
>>>> shouldn't be penalties for EHs, since they are part of the core IPv6
>>>> spec" -- but, while probably correct, that will not change reality.
>>>>
>>> Fernando,
>>>
>>> The irony is thatxtension headers (and alternative protocols as well),
>>> including fragmentation, aren't supposed to have to "be made to work"
>>> in intermediate devices. With the exception of Hop-by-Hop options they
>>> are supposed to be ignored by design, and even in the case of
>>> Hop-by-Hop options RFC8200 relaxed the requirements so that they can
>>> be ignored. Extension headers are considered problematic only because
>>> of ad hoc assumptions made for "value add", non-standard features
>>> implemented in intermediate devices.
>>
>> Please see:
>> <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03>
>>
>> theory != practice. And no matter how right you might be, that doesn't
>> make the theory a reality.
>>
>>
>>
>>>> Not that I like the situation, but... I think the least we can do is to
>>>> do a reality check wrt how things are supposed to work vs. how they
>>>> actually work.
>>>>
>>>> For this particular case, this I-D makes that point for fragmentation: I
>>>> I think we all agree that fragmentation is fragile -- making that point
>>>> clear at least raises awareness of the problem, and might trigger some
>>>> action on the topic (whether to correct the issue, or to circumvent it).
>>>>
>>> Right, but I still think that we should be more clear about the root
>>> origin of problems and blunt in requesting that non-conformant
>>> implementations get fixed.
>>
>> That is certainly not going to happen. From the pov of the folks
>> operating the networks, there's nothing broken.
>>
>>
>>> For instance, as I mentioned the ECMP
>>> hasing problem with fragmentation is entriely solvable if only
>>> intermediate devices will use flow label instead of trying to find
>>> ports for a hash.
>>
>> Yes and no. There was at least a time in which the flow label wasn't set
>> at all, or even was mistaenly set (e value during 3WHS, a different
>> value afterwards). That means that you cannot really rely on it. If you
>> cannot rely on it, you need a back-up mechanism. And that mechanism is
>> inspecting the trasnport port numbers -- from that point of view,
>> there's not much sense in dong ECMP with the FL if you cannot rely on it
>> and somehow you'd have to be prepared to do it based on addresses and
>> port numbers.
> 
> The fallback is to only hash over addresses. Hashing over ports is not
> reliable and can be problematic in itself. For instance, wrt
> fragmentation, some middleboxes will use ports in the first fragment
> but fall back to hashing over addresses for rest of fragments. This
> mean the first fragment almost always takes a different path which can
> wreak havoc on down stream devices that aren't expecting that. So
> maybe it's another recommendation in this draft that middleboxes don't
> use port information from first fragment to do load balancing. This is
> another relatively easy fix.
> 
> Tom
> 
>>
>>
>>> Fixing devices to support this reasonable and should
>>> be low cost.  IMO, use of flow label for ECMP should be a strong
>>> recommendation made in this draft.
>>
>> I wouldn't mind. However, that doesn't change the fact that
>> fragmentation is fragile.
>>
>> That said, if you look at RFC7872, t all looks like anything that is EHs
>> is dropped to some extent (while not included in the RFC, I also mesured
>> IPsec, and you get similar numbers). So besides the issues that are
>> specific to fragmentation, anything that is EHs gets dropped here an
>> there. -- and ding ECMP with the FL will not change that.
>>
>> (Again: not that I'm happy with the situation... but being unhappy will
>> not change reality anyway :-) )
>>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>