Re: Next steps on Extension Header Insertion

["Stefano Previdi (sprevidi)" <[e-mail]>]

Brian, 


> On Nov 8, 2016, at 3:35 AM, Brian E Carpenter <[e-mail]> wrote:
> 
> Stefano,
> On 08/11/2016 09:05, Stefano Previdi (sprevidi) wrote:
>> 
>>> On Nov 7, 2016, at 8:52 PM, Mark Smith <[e-mail]> wrote:
>>> 
>>> On 7 Nov. 2016 19:37, "Stefano Previdi (sprevidi)" <[e-mail]> wrote:
>>>> 
>>>> 
>>>>> On Nov 7, 2016, at 2:04 AM, Fernando Gont <[e-mail]> wrote:
>>>>> 
>>>>> On 11/02/2016 05:33 PM, [e-mail] wrote:
>>>>>> Mark,
>>>>>> 
>>>>>>>> I'm just trying to point out that we shouldn't blow this issue out of proportion. Whatever we end up doing here, it is hard to see it being particularly important, nor have any big consequences.
>>>>>>> 
>>>>>>> I see it having big consequences and being hard to troubleshoot.
>>>>>>> 
>>>>>>> Currently, the source IP address in a packet identifies the host that
>>>>>>> is entirely responsible for the construction of the packet. The set of
>>>>>>> values in the IP packet that can be changed in the network is limited
>>>>>>> and well known (HC, TC), and the consequences of those changes failing
>>>>>>> is also limited (packet getting higher forwarding preference, being
>>>>>>> dropped or being forwarded more or less hops than it should).
>>>>>>> 
>>>>>>> Allowing EH insertion means the source IP address value isn't true
>>>>>>> anymore - its semantics have changed. It is now only the first
>>>>>>> constructor of the packet, rather than the only one, and any other
>>>>>>> constructors (the EH inserters) are not identified. It's now a
>>>>>>> "multi-source" packet where only the first source is identified.
>>>>>> 
>>>>>> Any text describing of EH insertion could possibly work or "allowing EH insertion" is far out of scope for 2460.
>>>>> 
>>>>> Any text that talks about header insertion introduces a change in
>>>>> RFC2460, because RFC2460 does not allow for header insertion.
>>>> 
>>>> 
>>>> can you point me to the section/paragraph making that statement ?
>>>> 
>>> 
>>> First sentence, second paragraph of "4. IPv6 Extension Headers".
>>> 
>>> "With one exception, extension headers are not examined or processed 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."
>>> 
>>> The one exception is the HBH EH, which appears directly after the IPv6 header if the packet origin host puts it there.
>>> 
>>>> Also, if you think rfc2460 denies header insertion, why would you need new text ?
>>>> 
>>> 
>>> It shouldn't. It does because some people are saying the above is ambiguous.
>> 
>> 
>> Well, as far as I’m concerned, RFC2460 is good for me and I never asked to change anything regarding extension headers. 
> 
> Yes, Stefano, because you interpreted "not examined or processed" to allow insertion.
> Most people here,


I’m not sure if it's a “most” or a “many”.


> I think, interpreted it as forbdidding insertion (since that is
> a form of processing) and of course as forbidding modification. And that was clearly
> the intent when RFC1883 was written, according to the meeting minutes I dug out some
> months ago.


rfc1883 was a little while ago and reality of operational networks may have slightly changed since.

As suggested, we should carefully understand and valuate the experience of EHs prior to make definitive statements.


> So, the *fact* is that the current text is ambiguous, since it has been interpreted
> both ways. As standards writers, we should hate ambiguity.


if there aren’t issues with interoperability, ambiguity is just fine.

Thanks.
s.



> 
> Rgds
>    Brian
>> 
>> This what has been proposed during an IETF meeting (I don’t remember if it was Buenos Airs or Prague) and it is also what I reflected in my vote.
>> 
>> RFC2460 needs not to be amended.
>> 
>> 
>>>> Seriously, nothing is prohibited as long as you understand the consequences.
>>> 
>>> When it isn't allowed by the specification, claiming it is compliant with the specification is prohibited.
>> 
>> 
>> the question is not being compiant or not.
>> 
>> Over time we always see implementations that diverge from the original intend of the specification. This is obvious and natural. 
>> 
>> 
>>> Changing the specification to support a method doesn't make the problems with the method go away.
>> 
>> 
>> I agree and that’s why I do not ask to change any specification. We need more experience and more feedback on network operations. In all ways.
>> 
>> 
>>> If the problems are severe enough, and there are alterative methods that don't have those problems, the other methods should be used and possibly specified.
>> 
>> 
>> and if there are methods who violates specifications but that have the necessary safeguards, this is fine too.
>> 
>> 
>>>> 
>>> As discussed at length, the text should focus on that.
>>>> 
>>> 
>>> I don't think it makes sense to have a part of a specification prohibit something and then have other text later tacitly allow it.
>> 
>> 
>> there are examples where a specification denies something and later, under precise circumstances, another specification allows it.
>> 
>> This is part of operational experience.
>> 
>> s.
>> 
>> 
>> 
>>> 
>>> Regards,
>>> Mark.
>>> 
>>>> s.
>>>> 
>>>> 
>>>>> 
>>>>> Given the discussion, omission of the topic would be a failure on our side.
>>>>> 
>>>>> Thanks,
>>>>> --
>>>>> Fernando Gont
>>>>> SI6 Networks
>>>>> e-mail: [e-mail]
>>>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>> 
>>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------