Re: Next steps on advancing core IPv6 specifications to full Internet standard

[Hemant Singh <[e-mail]>]

I agree with Jinmei.  It's not just SR in the Linux kernel.  The Linux user
space also has one implementation that adds/deletes the EH.  See

https://mailarchive.ietf.org/arch/msg/ipv6/sYxrnN45cEu1PyqftDICQ-Yl3Rg

 Inband OAM uses Add/delete of EH in the FD.io implementation which runs in
the Linux user space.    I was told  "Inband OAM especially is not possible
with encapsulation since we want the source and destination to not change."

Why not preserve the original source and destination IPv6 addresses in
another IPv6 option and use encapsulation.

Hemant


On Wed, Nov 16, 2016 at 2:18 PM, 神明達哉 <[e-mail]> wrote:

>
>
> Assuming so, I'd like to say I still have a serious concern with this
> text in that it's as "ambiguous" to the extent the original RFC2460
> was ambiguous regarding whether the protocol intends (intended) to
> allow such extension header insertion.  I'm concerned about this
> because such ambiguity can lead to casual violation of the intent (we
> know the intent was to not allow it) and casually dismissing the
> stated problems and other issues that are not explicitly noted in the
> text.  The existence of segment routing implementation for the Linux
> kernel (a general purpose operating system) suggests it's not just an
> imaginary concern: http://www.segment-routing.org/index.php/SR/SR-IPv6
>
>
>
>