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

[Tom Herbert <[e-mail]>]

On Fri, Jul 27, 2018 at 9:25 AM, Fernando Gont <[e-mail]> wrote:
> On 07/27/2018 05:15 PM, Tom Herbert wrote:
>> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont <[e-mail]> wrote:
>>> Hi, Joe,
>>>
>>> On 07/26/2018 04:14 AM, Joe Touch wrote:
>>>> Hi, all,
> [....]
>>>
>>> Side coments:
>>>
>>> It would all seem that there are two operating environments:
>>> * Controlled environments, where you can somehow make all this work
>>> * Public internet, which is more of a "fingers crossed" thing (if anything).
>>>
>>> I'm not saying that I'm happy with the outcome, but rather that I think
>>> that from an engenering point of view, it all looks like this ship has
>>> sailed, and we should probably figure out how to deal with those cases
>>> where fragmentation is actually needed.
>>>
>> Fernado,
>>
>> Couldn't that same line of thinking be applied to several other
>> protocol features?
>
> Yes, indeed.
>
>
>> So has the ship sailed for out ability to ever use
>> extension headers or any protocol other than TCP (and sometimes UDP)?
>
> It would seem that that's the case, yes.
>
>
>> Maybe documents that recommend operational workarounds should
>> distinguish problems that inherent in the protocol from those that
>> have arisen because of non-conformant implementation. It's true that
>> calling implementations that probably won't help to fix what is out
>> there, but maybe this could help prevent new instances of
>> non-conformance.
>
> I kind of agree with you. That path from spec to implementation is what
> you'd call engineering (or what others might call "taking shortcuts", etc.).
>
> 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.

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

Tom

> Thanks,
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>