On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan <[email protected]> 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. Tom > Cheers, > Ole > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
