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.e.carpenter@xxxxxxxxx>
> 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@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
> --------------------------------------------------------------------
>