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

From: Suresh Krishnan <[email-masked]>
Date: Thu, 21 Jun 2018 05:42:20 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-ippm-2330-ipv6-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 4

Since this behavior is clearly forbidden in RFC8200 there is no need to add a
special case for this (as middleboxes perform any number of transformations
that not standards compliant). 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).

   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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 3

Please add RFC6398 as the reference for Router Alert as it provides significant
guidelines regarding usage similar to what RFC7045 does for hop-by-hop options.

* Section 4

I think this text should be removed

   [RFC8250] endorses the use of IPv6 extension headers for measurement
   purposes, consistent with other approved IETF specifications.

as RFC8250 uses a destination option and defining new extension headers has
been explicitly recommended against by section 4.8 of RFC8200.

* Minor

=> The reference for 6lowpan is wrong throughout the document (typo?). It
should be RFC4944 instead of RFC4494 (which is a crypto spec).

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jun 2018 14:23:32 +0000

Hi Suresh,
Thanks for your review.
Please see the discussion below.
We have things to talk about.

Al

...
> Since this behavior is clearly forbidden in RFC8200 
[acm] 
Although much of the IETF community shares your view,
"forbidden" is much too strong a word to describe this 
sentence/statement in RFC8200

   Extension headers (except for the Hop-by-Hop Options header) are not
   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.

"are not" would not translate to "forbidden" in any SDO I know.
I understand that some folks proposed to update the wording to 2119
terms, and were found to be in the rough. Would someone outside IETF
reading RFC8200 interpret this sentence as an absolute requirement?
I won't list the many possible interpretations.

> there is no need to add a
> special case for this (as middleboxes perform any number of 
> transformations that not standards compliant).
[acm] 
Right, but we would want to know those translations happened.
Keep in mind that IPPM is in the measurement business,
and our systems work better if we detect the unexpected.
So, If you are reading the bullet text below as some form of
encouragement to insert/delete headers, it is not. 

> Given that safe header insertion/deletion is a
[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.
 
>       resulting packet may be standard-formed, with a corresponding
[acm] 
OK

> been explicitly recommended against by section 4.8 of RFC8200.
[acm] 
Then how was RFC8250 approved? This RFC was developed in IPPM, too.
We are clearly not on the same page for this topic, and IPPM's 
new charter including In-situ OAM may insert more space between us.

> should be RFC4944 instead of RFC4494 (which is a crypto spec).
[acm] 
OK
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Dq_PPI7bw5x3XowoNQz62vxNvxK8o
> RsRIikvAT5Hv1I&s=84DjJ_D-LNGA7NE1iHRKnpMOHEQ_0VcYNGt9Iq8YpIo&e=

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 21 Jun 2018 15:39:40 +0000

Hi Al,
  Thanks for the quick reply. Please find comments inline.

On Jun 21, 2018, at 10:23 AM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,
Thanks for your review.

Al

...

* Section 4

"are not" would not translate to "forbidden" in any SDO I know.
I understand that some folks proposed to update the wording to 2119
terms, and were found to be in the rough.

Actually, the lack of 2119 language in RFC8200 is completely unrelated to this issue. We, in the IETF, do not require standards track documents to use 2119 language (IMHO, I think this is unfortunate and that we should!). 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).

"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

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.

Would someone outside IETF
reading RFC8200 interpret this sentence as an absolute requirement?
I won't list the many possible interpretations.

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.

* Section 4

RFC8250 defines a new *destination option* and not a new extension header. That is why it was approved :-)

Thanks
Suresh

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jun 2018 16:30:28 +0000

Hi Suresh,
Thanks for your reply. We're getting closer. Let's keep going...

From: ippm [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 21, 2018 11:40 AM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

Hi Al,

Hi Suresh,
Thanks for your review.

Al

...

* Section 4

Actually, the lack of 2119 language in RFC8200 is completely unrelated to this issue. We, in the IETF, do not require standards track documents to use 2119 language (IMHO, I think this is unfortunate and that we should!).
[acm]
Yes, we heard this position on 2119 terms during the exchange
with 6man folks. IMO, it doesn't help to take a fringe/exception position
when stating such an important requirement. As I said,
someone reading this "cold" is not going to see a requirement, and
so the IETF'ers have heavy baggage to carry - to explain this to
everyone who gets it wrong. This is one reason we need to be prepared
to detect this in measurement systems (and that's the relationship,
ambiguous requirement wording will make this error more likely!).

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=>)..

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=>

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.

* Section 4

RFC8250 defines a new *destination option* and not a new extension header. That is why it was approved :-)
[acm]
So, it seems our terminology needs reconciliation, too.
RFC8250 says
3.1.  Destination Options Header

   The IPv6 Destination Options extension header [RFC8200] is used to
   carry optional information that needs to be examined only by a
   packet's destination node(s).  The Destination Options header is
   identified by a Next Header value of 60 in the immediately preceding
   header and is defined in RFC 8200 [RFC8200].

and goes on to define the PDM DOH.

RFC 8200 (sec 4) says:
   A full implementation of IPv6 includes implementation of the
   following extension headers:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication
      Encapsulating Security Payload

What subtlety of RFC8200 are we missing here?

Thanks,
Al

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 26 Jun 2018 04:34:54 +0000

Hi Al,

On Jun 21, 2018, at 12:30 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,
Thanks for your reply. We’re getting closer. Let’s keep going…

Excellent.

From: ippm [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 21, 2018 11:40 AM
To: MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

Hi Al,

Hi Suresh,
Thanks for your review.

Al

...

* Section 4

Actually, the lack of 2119 language in RFC8200 is completely unrelated to this issue. We, in the IETF, do not require standards track documents to use 2119 language (IMHO, I think this is unfortunate and that we should!).
[acm]
Yes, we heard this position on 2119 terms during the exchange
with 6man folks. IMO, it doesn’t help to take a fringe/exception position
when stating such an important requirement. As I said,
someone reading this “cold” is not going to see a requirement, and
so the IETF’ers have heavy baggage to carry – to explain this to
everyone who gets it wrong. This is one reason we need to be prepared
to detect this in measurement systems (and that’s the relationship,
ambiguous requirement wording will make this error more likely!).

OK. Fair enough.

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.

* Section 4

RFC 8200 (sec 4) says:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication

I don’t see any contradiction in RFC8250. It creates an option for use in an existing extension header instead of creating a new extension header. I think the following text change proposal is both accurate and would make the intent clearer.

OLD:

NEW:

[RFC8250] endorses the use of IPv6 destination options for measurement
  purposes, consistent with other approved IETF specifications.

Regards
Suresh

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 26 Jun 2018 18:40:14 +0000

Thanks for continuing our discussion, Suresh.
more below,
Al

From: Suresh Krishnan [mailto:[email-masked]]
Sent: Tuesday, June 26, 2018 12:35 AM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

Hi Al,

Hi Suresh,

Excellent.

Hi Al,

Hi Suresh,
Thanks for your review.

Al

...

* Section 4

OK. Fair enough.

   The topic of IPv6 Extension Headers brings current controversies into
   focus as noted by [RFC6564<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6564&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=iyFtyviGjQYYGbxvughFut9zFcR2fYCaZ_obGTUXszk&s=7K4fEIlZVkpyrJuSMbT45XKZEOSiMiA9V4scx50D3nA&e=>] and [RFC7045<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7045&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=iyFtyviGjQYYGbxvughFut9zFcR2fYCaZ_obGTUXszk&s=54vvcyL4h_RxBHKq5HBVQpw9kuXsb5bhDGJqDPit3Ug&e=>].

Sounds good. I will propose some text here. If that works for you, we can move past this.
[acm]
Great. I think a few more concise references and a sentence to
introduce them might do. We certainly don’t want to wade into
the area of restrictions on EH more than we have, saying now:
o Extension Header insertion or deletion: Although such
behavior is not endorsed by current standards,...

IOW, we prefer not to restate the 8200 statement in some
stronger way (“forbidden to ...”) as part of a
measurement framework. RFC 8200 has to stand on its own.

* Section 4

RFC 8200 (sec 4) says:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication

OLD:

NEW:

[RFC8250] endorses the use of IPv6 destination options for measurement
  purposes, consistent with other approved IETF specifications.
[acm]
Thanks, that’s certainly better than deleting the sentence.
I’ll make that edit in the working draft.

Al

Regards
Suresh

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 29 Jun 2018 20:35:07 +0000

Hi Suresh,

As this week draws to a close, let me provide the current status
on your DISCUSS.

Rather than wait for a text suggestion**, the co-authors exchanged
many messages as we researched the topic from your DISCUSS:
“...describe potential issues that may occur due to header insertion/deletion.”
We proposed that a few concise references and a sentence to introduce
them might be sufficient.

Since this is a topic where consensus is evolving,
the co-authors agreed that we should not propose any
text or references that others might see as controversial
(and move us further from everyone’s goal of approval).

Instead, we sought sources/lists of issues that have been vetted,
such as those published as an RFC or a peer-reviewed conference paper
by someone with a prominent reputation in this field.

We found many Internet Drafts that identify general issues related to EH:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03
https://tools.ietf.org/html/draft-wkumari-long-headers-03
Also, this draft that presents issues specific to the SRH proposal:
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-04#section-4
But Individual drafts that raise issues aren’t agreed at any level.
We looked at many e-mails and other items, too.

OTOH, there is some of evidence of strained EH-compliance
found through measurements:
https://tools.ietf.org/html/rfc7872

We could infer an issue from the RFC 7112 Header Chain limitations:
https://tools.ietf.org/html/rfc7112#section-5
where inserting any new EH at an intermediate node could exceed the PMTU.
But the EH insertion/deletion issue is not discussed in the RFC text.

The current Bullet item reads:

We propose to append:

This point simply encourages measurement system designers to be prepared
for the unexpected, and to notify users when such events occur.
There are issues with Extension Header insertion and deletion,
such as exceeding header chain size limitations, like those
described in [RFC7112], of course.

Let us know what you think,
Al, for the co-authors

** We saw Mike Heard’s suggestion, but we felt it didn’t address your
DISCUSS directly, and didn’t meet our criteria to avoid more controversy.

From: MORTON, ALFRED C (AL)
Sent: Tuesday, June 26, 2018 2:40 PM
To: Suresh Krishnan <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Thanks for continuing our discussion, Suresh.
more below,
Al

Hi Al,

Hi Suresh,

Excellent.

Hi Al,

Hi Suresh,
Thanks for your review.

Al

...

* Section 4

OK. Fair enough.

* Section 4

RFC 8200 (sec 4) says:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication

OLD:

NEW:

Al

Regards
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 30 Jun 2018 17:04:42 +0000

Hi Al,

On Jun 29, 2018, at 4:35 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,

We propose to append:

I was working on text that was along similar lines (expect the unexpected) and I believe your text proposal strikes the right balance in this regard. Thanks! I will clear right away when this new text is added. I would prefer removing the reference to 7112 as it is not directly related to insertion at intermediate points and make the following minor change (but I will leave it to your discretion whether to take this suggestion or not)

OLD:

NEW:
There are issues with Extension Header insertion and deletion,
such as exceeding path MTUs due to insertion, inability of the
original packet initiator to react to ICMPv6 error messages etc.,
of course.

Yep. That I figured it was probably too controversial for you as well.

Regards
Suresh

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 30 Jun 2018 20:48:00 +0000

Hi Suresh, thanks for your Saturday reply!
small suggestion on your revised wording, below.

From: Suresh Krishnan [mailto:[email-masked]]
Sent: Saturday, June 30, 2018 1:05 PM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: Spencer Dawkins at IETF <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-2330-ipv6-05: (with DISCUSS and COMMENT)

Hi Al,

Hi Suresh,

We found many Internet Drafts that identify general issues related to EH:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dgont-2Dv6ops-2Dipv6-2Dehs-2Dpacket-2Ddrops-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=oGtdxvB-rRQROdp6QAlrpK1Pf7eak6QhZlZM79X_YB8&e=>
https://tools.ietf.org/html/draft-wkumari-long-headers-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwkumari-2Dlong-2Dheaders-2D03&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=Ku7IRBA-BcYWZcpyLXeYAPIVgeR4lkPGrJ8I9GgwiRQ&e=>
Also, this draft that presents issues specific to the SRH proposal:
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-04#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion-2D04-23section-2D4&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=Uk4ArKYJMqSuuPqClTWhyr5KslU6lcnl4DjXoGwoxh8&e=>
But Individual drafts that raise issues aren’t agreed at any level.
We looked at many e-mails and other items, too.

OTOH, there is some of evidence of strained EH-compliance
found through measurements:
https://tools.ietf.org/html/rfc7872<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7872&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=kLDaw7VEGngq9JbycuGXq3kGShpFRMGDnbkTE4oQ-0U&e=>

We could infer an issue from the RFC 7112 Header Chain limitations:
https://tools.ietf.org/html/rfc7112#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7112-23section-2D5&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Czq1H91sahX_Xr5bhh1wFAz_6pHVNOlQBXHGVYJ1TRs&s=HwcTmqzzKyOAtb7cvx0PdyzmGxEyBtABsCoLGIyiCdA&e=>
where inserting any new EH at an intermediate node could exceed the PMTU.
But the EH insertion/deletion issue is not discussed in the RFC text.

We propose to append:

OLD:

NEW:
There are issues with Extension Header insertion and deletion,
such as exceeding path MTUs due to insertion, inability of the
original packet initiator to react to ICMPv6 error messages etc.,
of course.
[acm]
I think it’s fine to remove the RFC 7112 reference
(not necessary to infer the MTU issue).
I have the impression that ICMPv6 error messages
only fail to reach the original Source when certain
routing-related EH are activated (SRH in draft-voyer).
So, I’m inclined to retain one general example of
the insertion issue, as we proposed on Friday:

NewNew:
There are issues with Extension Header insertion and
deletion of course, such as exceeding the path MTU due
to insertion, etc.

I’ll submit the draft as above, with all other changes
implemented, and we can iterate one more time if necessary.

thanks!
Al

Regards
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 30 Jun 2018 20:54:43 +0000

Hi Al,

On Jun 30, 2018, at 4:48 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

NewNew:

Excellent. That works for me too. Go for it.

Cheers
Suresh

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 30 Jun 2018 21:18:39 +0000

Thanks for clearing Suresh!

All,
the newly submitted draft is here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/?include_text=1

Al

Sent: Saturday, June 30, 2018 4:55 PM

Hi Al,

NewNew:

Cheers
Suresh