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(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
wrote:
On 31/03/2017 02:11, Jeff Tantsura wrote:
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?
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.
https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some
remnants of that attempt.
Brian
Thanks!
Cheers,
Jeff
On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <
ietf-bounces(_at_)ietf(_dot_)org on behalf of
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------