Hi Robert,
On 31/03/2017 04:31, Robert Raszuk wrote:
Hi Brian,
Could you elaborate a bit on the definition of "accidentally escaping
packets" ?
There was concern that configuration errors are always possible, so a
a host might send packets with stateful flow labels to an external
destination (first error) and the border router might fail to block
them (second error). I think your case is a bit different.
(I have a meeting this afternoon with some people who want to
define a local use of flow labels compatibly with RFC6437. These
arguments span many years.)
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.
No, that's a misunderstanding of how RFC spaghetti is constructed. What we'd
do is produce (I'm making this up) draft-ietf-6man-extension-header-insertion
which includes an Updates: 2460bis header. If approved, it becomes a Proposed
Standard that updates an Internet Standard. And it says, quite explicitly,
something like:
"Within a network domain defined as in Section N, there is an additional
exception to the following rule in Section 4 of [RFC2460bis]:
<blockquote>
With one exception, extension headers are not examined, processed,
inserted, or deleted by any node along a packet's delivery path,
until the packet reaches the node (or each of the set of nodes, in
the case of multicast) identified in the Destination Address field of
the IPv6 header.
</blockquote>
The exception is that..."
That's what I meant about 2460bis being a line in the *sand* in
another message. Not carved in stone.
Brian
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
--------------------------------------------------------------------