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

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

On 01/08/2018 11:29, Tom Herbert wrote:
> On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan <[e-mail]> wrote:
>> Tom,
>>
>>> How is this story going to be different for IPv6? How do we ensure that non-conformant implementation for IPv4 isn't just carried over so that fragmentation, alternative protocols, and extension headers are viable on the IPv6 Internet?
>>
>> I don’t think the IPv4 implementations are non-conformant.
>> (With regards to the implications of A+P on the IPv4 architecture).
>>
>> For IPv6 one would fear that the same pressures that has led to IPv4 ossification applies.
>> Well, what can we do? Apart from crypto, ensure that popular applications use the features, so they cannot be shut down?
>>
> Ole,
> 
> That's the "use it or lose it" model of protocol features. TCP options
> are firmly established as a required part of TCP protocol so there is
> no way they could be obsoleted by external implemenation; IP options
> on the other were never really required for IP operation so they are
> considered expendable. The problem is that protocol features are often
> defined before the application that would use them is built, so the
> motivation to support all the features from the start isn't there.
> This seems to be the case with extension headers, since only now does
> there seem to be some serious proposals to use that functionality long
> after the mechanism was first defined and IPv6 was deployed. In
> reality, support of protocol features in the Internet is hardly ever
> binary. Plain TCP/IPv4 packets are probably the only combination of
> protocols that is guaranteed to work with probability approaching
> 100%, however pretty much anything else works with some varying of
> probability greater than 0% but less than 100% (like EH success rates
> in RFC7872). To that end, I am wondering if the idea of Happy Eyeballs
> could somehow be generalized to work with these other "non-standard"
> features.

Generalised probing might be an answer, but (especially when there
are multiple address pairs to probe) it can significantly impact
start-up latency for a session. (Some dead work on that topic is at
https://tools.ietf.org/html/draft-naderi-ipv6-probing .)

    Brian