Hi Brian,
Could you elaborate a bit on the definition of "accidentally escaping packets" ?
The fundamental issue with original Suresh suggestion I see is that his proposed text kills ability to have 2460bis as normative reference in any other draft describing or defining extension headers. And effectively stops any work which needs to be based on 2460bis till 2460bis is updated.
Kind regards
R.
On Mar 30, 2017 10:11, "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx> wrote:
On 31/03/2017 02:11, Jeff Tantsura wrote:No, I wouldn't. I might even help; hence my suggested tweak to 2460bis. Note that the tricky bit (in reality and in the text) is a crisp definition of what the domain boundary is and what happens when packets with inserted headers accidentally escape. We did hit that difficulty when trying (and failing) to define local-use rules for stateful use of the flow label. But we were trying to do that in a generic document (in effect, an extension of RFC2460) and failed for essentially the same reasons that led Suresh to his decision on 2460bis.
> Brian,
>
> if I understand you correctly:
>
> If properly worded (improved) draft-voyer explicitly states – the intention is to change the 2460(bis) behavior and to allow header insertion within a controlled domain, and given there’s a valid justification of why encap wouldn’t’ meet the need, you wouldn’t oppose?
https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis- shows some remnants of that attempt.01
Brian
>
> Thanks!
>
> Cheers,
> Jeff
>
> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <ietf-bounces@xxxxxxxx on behalf of brian.e.carpenter@xxxxxxxxx> wrote:
>
> On 30/03/2017 15:59, Leddy, John wrote:
>
> ...
> > If this insert/delete of an SRH is prematurely prohibited; What is a recommended solution to the Real World problem above. Not use case, we are implementing.
> >
> > Again; I’m worried we are eliminating a tool that may prove very helpful, preclude its use in future IETF work and shutdown a path for Innovation in Networking,
>
> I've tried to say this before but I'm not sure people are getting it:
>
> RFC2460bis, if approved as is, draws a line in the sand *for interoperability across the whole Internet*. There are reasons for this - PMTUD in any form, any future replacement for the unsuccessful IPsec/AH, and all the problems of deploying extension headers that are understood by some nodes and not by others.
>
> There is no reason why a subsequent standards-track document cannot allow header insertion (and removal) within finite domains where the above issues do not apply. In fact, an improved version of draft-voyer-6man-extension-header-insertion-00 could become exactly that.
>
> There doesn't need to be a tussle here.
>
> Brian Carpenter
>
>
>
>
>
------------------------------------------------------------ --------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
------------------------------------------------------------ --------