Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

From: "C. M. Heard" <[email-masked]>
Date: Wed, 27 Jun 2018 12:41:25 -0700

On Tue, 26 Jun 2018 04:34:54 +0000, Suresh Krishnan wrote:

> The reason header insertion was not allowed in RFC8200 was because the
> proponents of header insertion could not describe how to do header
> insertion safely on the internet and were not willing to scope the header
> insertion to private networks. I do not have a religious position on this
> and I summarized my position in a mail to the 6man list on this issue (
> https://www.ietf.org/mail-archive/web/ipv6/current/msg27336.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_ipv6_current_msg27336.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=c0q9R673pxJFQtApvfYaAgkBdWTLaVGLE0njCE2DVl8&s=Y8OnjtPK9mZSD4B6zvXu932dgzCwYYfIMBwB1PJXwzQ&e=>
> )..
>
> "I have heard from several persons being concerned about the possibility
> of new text in 2460bis being blindly used to block header insertion work in
> the future. I just want to confirm that header insertion work can be
> considered in the future, and that it should be judged on its own merits
> and not be blocked solely based on the header insertion related text in
> 2460bis."
>
> When the ippm work hits the IESG, I (if I am still on it :-)) will hold
> that work to the same standard. There is some work ongoing (albeit very
> slowly) in 6man to specify safe header insertion
>
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion-2D03&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=c0q9R673pxJFQtApvfYaAgkBdWTLaVGLE0njCE2DVl8&s=bHo-N2I44qQUiGNT3deL8lrmvmBLV0hGN_SNBYU4OOo&e=>
>
> and hopefully this work will complete before the in-situ OAM work will hit
> the IESG. If not, I see encapsulation and tight scoping as the only way
> forward on this issue.
>
> [...]
>
> Given that safe header insertion/deletion is a
> hard problem that has not been solved, I would remove this text or
> significantly augment it to describe potential issues that may occur due to
> header insertion/deletion (similar to the sections related to 6lowpan and
> translation).
>
> [acm]
> I think we would be glad to cite several references to cover
> the potential issues that you provide, but this bullet point has real
> value to the measurement community.
>
>
> Yep. That would be a good way to address this DISCUSS point, because I
> will clear right away as long as the issues are put forth just like the
> extensive work you have done in Section 5 for the other *similar*
> transforms.
> *[acm]*
> *As I said above, we need some help here. We have already cited:*
>
>    The topic of IPv6 Extension Headers brings current controversies into
>    focus as noted by [RFC6564 <https://tools.ietf.org/html/rfc6564>] and [
> RFC7045 <https://tools.ietf.org/html/rfc7045>].
>
> *in the sentences leading to this bullet list. If you (or others)*
> *can provide additional references that describe the issues, then*
> *it’s completely appropriate to include them, IMO. At the same*
> *time, I hope you are not asking that we research and summarize*
> *all discussions on Extension Header Insertion issues in this memo.*
> *That’s well beyond our scope, and would seem to be better positioned*
> *if the issues were cataloged in the Internet Area literature.*
>
>
> Sounds good. I will propose some text here. If that works for you, we can
> move past this.
>

Since nothing else had yet appeared on the mailing lists, may I suggest the
following if something better has not surfaced in the meantime:

OLD:

   The topic of IPv6 Extension Headers brings current controversies into
   focus as noted by [RFC6564 <https://tools.ietf.org/html/rfc6564>]
and [RFC7045 <https://tools.ietf.org/html/rfc7045>].  However,
measurement use
   cases in the context of the IPPM framework like in-situ OAM
   [I-D.ietf-ippm-ioam-data
<https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-05#ref-I-D.ietf-ippm-ioam-data>]
in enterprise environments can benefit from
   inspection, modification, addition or deletion of IPv6 extension
   headers in hosts along the measurement path.

NEW:

   Currently, the IPv6 base specification [RFC8200] does not allow

insertion or deletion of extension headers by intermediate nodes,

   and except for Hop-by-Hop Options, does not allow modification.

   However, work in progress such as
[I-D.voyer-6man-extension-header-insertion
<https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion>]

   may result in extensions to [RFC8200] that allow insertion or
   or deletion of extension headers in controlled environments,

   and measurement use cases such as in-situ OAM in enterprise
   environments [I-D.ietf-ippm-ioam-data
<https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-05#ref-I-D.ietf-ippm-ioam-data>]
 may employ such extensions.

and then farther down:

OLD:

   o  Extension Header insertion or deletion: Although such behavior is
      not endorsed by current standards, it is possible that Extension
      Headers could be added to, or removed from the header chain.  The
      resulting packet may be standard-formed, with a corresponding
      Type-P.

NEW:

   o  Extension Header insertion or deletion: Although such behavior is
      not endorsed by current standards, future standards may allow
      Extension Headers to be added to, or removed from the header chain.
      The resulting packet may be standard-formed, with a corresponding
      Type-P.

Mike Heard