Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

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

On 13/03/2016 05:53, [e-mail] wrote:
> Brian,
> 
> Let me offer the contrarian view.
> 
>> I disagree with Ole. I think there is is useful factual information here
>> that should be published. "Solicit input from network operators and users
>> to identify operational issues with the IPv6 Internet" and "document IPv6
>> operational experience" are part of the WG charter.
> 
> I've read through the document one more time. Would you be able to cite new and useful information in this document?
> That isn't already described elsewhere...?

The observational data, which for some reason people wanted to push into an Appendix.
For me that's the main point of the document.

> 
> - Parsing EHs is and the consequence of having to walk the extension header chain is a well known problem.
>   If the premise is that we want this to work well for arbitrary middleboxes, the solution space is empty.
> - HBH headers is a well known problem. One draft in 6man as well as changes in 2460bis.
> - The ECMP problem is well known. We tried to solve it with flow label, in practice the IP header has evolved to be 24 / 44 bytes respectively.
> - The MTU attach is already described and resolved in 2460bis, 6145bis, 1918bis
> 
>> The new "Future Work" section is also telling us that we aren't done yet
>> if we want to improve deployability.
> 
> Enforcing a cap on the extension header chain isn't going to make the slightest difference.

I tend to agree on that specific point. But we need that restriction anyway
to reduce security risks.

> Vendors can build whatever you like, but are you willing to pay the price? Especially given that real, deployed applications aren't using EHs.
> This reminds me of the ngtrans/softwires/v6ops/6man saga, where we had the belief that the reason IPv6 wasn't deployed was because we didn't have the right transition mechanism, or the right interface id generation mechanism or at least 3 different ways of assigning DNS recursive resolvers... History has shown us we were wrong.
> 
> Given that EHs are rarely used, all the time already invested into clarifying and tweaking them (we've publish 10+ documents on EHs already), is it really good use of the IETF's time to publish yet another document, that rehashes the same problems?

Again, I believe that publishing the observational data is useful in itself. The rest
of the document is context.

> I think no. I think we should let the EH "problem" rest for a few years and see if it is anything worth revisiting in say 2020.

But then what do we do when people come along proposing to standardise more
extension headers? This document will be helpful, I believe.

I do agree with you that once this and the current drafts in 6man are resolved, there's
little point in doing more for now.

    Brian