Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

[Fernando Gont <[e-mail]>]

Bruno,

On 11/12/19 14:48, [e-mail] wrote:
[....]
>>>> If you think a document on tunnels rules how IPv6 operates, and its
>>>> end-to-endianness, then you have a huge problem reading specs.
>>>>
>>>> So I will not enter that game, because it would be accepting to be
>>>> mocked at.
>>>>
>>>> I'll wait for a few days for our INT AD's response (Suresh), a response
>>>> from the spring chairs (if any), and a response from the RTG AD(s).
>>>
>>> I'm not sure what response to what question you expect from spring chairs.
>>
>> A number og wg participants are letting the chairs and ADs aware that a
>> wg document contains an outright violation of an Internet Standard
> 
> That point is noted.
> But given that a number of wg participants are saying the opposite, we need to go a bit deeper in the discussion. That's what I've tried to initiate and I believe that we have made progress.

Filling an errata somehow warrants that a clarification on the topic is
about to come (in the event it was ever needed).


> 
> My understanding is that you are saying that
> PSP and USP, as defined in [1] and more specifically "Pop the SRH"  contradict with [2] and more specifically 
> "   Extension headers [...]  are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node [...] identified in the Destination Address field
>    of the IPv6 header."
> 
> 
> More specifically, your point is that " the Destination Address field of the IPv6 header" is to be understood as " final destination node"
> https://mailarchive.ietf.org/arch/msg/ipv6/Ku-kKBE-vG5QGdT2DvqLxMQpRik

My point is that according to RFC8200, which does not specify any
routing header types, the destination cannot contain anything else other
than the final destination of the packet.

The spirit of what the text means is also well known  to all of us 6man
participants as we discussed the topic while working on what eventually
became RFC8200.


[...]
>> that
>> spring is not in a position of changing.
> 
> 6man consensus is written in RFC 8200. I can read it as any other one. Actually you are the one trying to modify that text.
> But to your point, believe me, I'll be more than happy to give that ball to someone else. E.g. to my AD then IESG and flagging that point in the shepherd report.
> I'll also monitor your above errata, to see if it's been accepted or rejected. That will typically be a strong input in the balance. 

Agreed on this last item. -- that was part of the motivation of
submitting it.




> 
>> I deem that as a major issue, and I'm curious how you might possible
>> ignore it, declare consensus, and ship and request publication of this
>> document.
> 
> Noted.
> I'm not ignoring it. Quite the contrary I'm the one engaging the discussion with you in order to understand the real technical point that you want to make.

The esensce of my technical point is that IPv6 does not support
inserting headers or deleting them on the packets delivery path. And PSP
requires exactly that, violating RFC8200.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492