Subject: Re: [ippm] Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC

From: "C. M. Heard" <[email-masked]>
Date: Sat, 14 Apr 2018 11:54:04 -0700

Greetings,

I have some last call comments on this document. Most (but not all) focus
on aspects that do not respect RFC 8200 and RFC 8201.

The Abstract says:

   [...] Exemplary use cases include,
   but are not limited to IPv4-IPv6 translation, NAT, protocol
   encapsulation, IPv6 header compression, or use of IPv6 over Low-Power
   Wireless Area Networks (6LoWPAN).

These last two use cases, however, are explicitly excluded in Section 4:

   [...] Because of these reasons we
   consider ROHC and 6LowPAN packets to be out of the scope of this
   document.

On that basis, it seems that the last two use cases in the Abstract should
be removed. Other places in the draft that IPv6 header compression also
need to be looked at.

Section 3, page 3, next to last paragraph, has a reference "Diffserv
[RFC2780]" -- shouldn't that be "Diffserv [RFC2474]"?

Section 3, page 4, third paragraph, says:

   [...] For example, the packet length will
   change if IP headers are converted to the alternate version/address
   family, or if optional Extension Headers are added or removed. [...]

Adding or removing extension headers contravenes RFC 8200. Since this is
just an example, I would recommend deleting the controversial second clause.

Section 4, page 6, last paragraph, and page 7, first paragraph, say:

   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 in
   enterprise environments or IPv6 Performance and Diagnostic Metrics
   (PDM) Destination Option measurements [RFC8250
<https://tools.ietf.org/html/rfc8250>] can benefit from
   inspection, modification, addition or deletion of IPv6 extension
   headers in hosts along the measurement path.

   As a particular use case, hosts on the path may store sending and
   intermediate timestamps into dedicated extension headers to support
   measurements, monitoring, auditing, or reproducibility in critical
   environments.  [RFC8250 <https://tools.ietf.org/html/rfc8250>]
endorses the use and manipulation of IPv6   extension headers for
measurement purposes, consistent with other   approved IETF
specifications.

These two paragraphs are very problematic and IMNSHO need a complete
rewrite before publication.

As noted in a review by Fred Baker on 2016-07-14 of an earlier version (see
https://mailarchive.ietf.org/arch/msg/ippm/8sgikiZbSiD4v2VeKK_FA7TkjmM),
the first sentence of the first paragraph above dates the document, and in
fact these controversies have largely been put to rest by RFC 8200.
Specifically, insertion or deletion of extension headers by intermediate
nodes is forbidden by RFC 8200. So is modification of extension headers
other than modifiable options contained within the Hop by Hop Options
Header. An IPv6 hop-by-hop option somewhat along the lines of the IPv4
timestamp option could, in principle, be defined, but so far none has been.
The option defined in RFC 8250 is a destination option and is not allowed
to change in flight, and I see nothing in RFC 8250 that discusses the
storing of intermediate timestamps by nodes (note, nodes, not hosts) on the
path. If this is wrong, I would appreciate a pointer to the text in RFC
8250 that says otherwise.

Section 4, page 7, fifth paragraph says:

   o  Extension Header insertion or deletion: 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.

This paragraph gives the impression that insertion or deletion of extension
headers is sanctioned by IETF standards, which is not true. If instead of
"It is possible ..." it said something like "Despite the fact that such
behavior does not comply with RFC 8200, it is possible ..." I would not
find it objectionable.

Section 4, page 7, next-to-last paragraph says:

   [...] Path MTU Discovery
   for IP version 6 (PMTUD, [RFC8201
<https://tools.ietf.org/html/rfc8201>]) or Packetization Layer Path
MTU
   Discovery (PLPMTUD, [RFC4821
<https://tools.ietf.org/html/rfc4821>]) is recommended to prevent
   fragmentation (or ICMP error messages) as a result of IPv6 extension
   header manipulation.

The trailing clause "(or ICMP error messages) as a result of IPv6 extension
header manipulation" should be removed, as it is just plain wrong. PMTUD
relies on ICMP Packet Too Big messages for proper operation, and in-flight
increases in packet length due to insertion of extension headers actually
break PTMTUD.

Section 5, page 8, next-to-last paragraph says:

   o  Modification or addition of headers or header field values in
      intermediate nodes.  As noted in Section 4
<https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-04#section-4>
for IPv6 extension
      header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header
      compression mechanisms may result in changes of the measurement
      packets' Type-P, too.  Consequently, hosts along the measurement
      path may treat packets differently because of the Type-P
      modification.  Measurements at observation points along the path
      may also need extra context to uniquely identify a packet.

If the changes I recommend above are implemented, it will be necessary to
remove the clause "As noted in Section 4 for IPv6 extension header
manipulation,"

Mike Heard

On Wed, 11 Apr 2018 06:21:43 -0700, The IESG <iesg-secretary at ietf.org
> wrote:

> The IESG has received a request from the IP Performance Measurement WG (ippm)
> to consider the following document: - 'IPv6, IPv4 and Coexistence Updates for
> IPPM's Active Metric Framework'
>   <draft-ietf-ippm-2330-ipv6-04.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2018-04-25. Exceptionally, comments may be
> sent to iesg at ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>    This memo updates the IP Performance Metrics (IPPM) Framework RFC
>    2330 with new considerations for measurement methodology and testing.
>    It updates the definition of standard-formed packets in RFC 2330 to
>    include IPv6 packets, deprecates the definition of minimum standard-
>    formed packet, and augments distinguishing aspects of packets,
>    referred to as Type-P for test packets in RFC 2330.  This memo
>    identifies that IPv4-IPv6 co-existence can challenge measurements
>    within the scope of the IPPM Framework.  Exemplary use cases include,
>    but are not limited to IPv4-IPv6 translation, NAT, protocol
>    encapsulation, IPv6 header compression, or use of IPv6 over Low-Power
>    Wireless Area Networks (6LoWPAN).
>
> The file can be obtained viahttps://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/
>
> IESG discussion can be tracked viahttps://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/ballot/
>
> No IPR declarations have been submitted directly on this I-D.
>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 15 Apr 2018 13:43:26 +0000

Thanks for your review, C.M.

please see below [acm],
Al

From: C. M. Heard [mailto:[email-masked]]
Sent: Saturday, April 14, 2018 2:54 PM
To: IETF <[email-masked]>
Cc: IPPM <[email-masked]>; 6man <[email-masked]>
Subject: Re: Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC

Greetings,

I have some last call comments on this document. Most (but not all) focus on aspects that do not respect RFC 8200 and RFC 8201.

The Abstract says:

   document.

On that basis, it seems that the last two use cases in the Abstract should be removed. Other places in the draft that IPv6 header compression also need to be looked at.
[acm]
Clarified as follows:
IPv6 header compression and use of IPv6 over
Low-Power Wireless Area Networks (6LoWPAN) are
considered and excluded from the standard-formed packet evaluation.

and later:
Because of these reasons we consider ROHC and
6LowPAN packets to be out of the scope for the
standard-formed packet evaluation.

Section 3, page 3, next to last paragraph, has a reference "Diffserv [RFC2780]" -- shouldn't that be "Diffserv [RFC2474]"?
[acm]
yes, 2474 was intended, thanks.

Adding or removing extension headers contravenes RFC 8200. Since this is just an example, I would recommend deleting the controversial second clause.
[acm]
Understand, see below.

   focus as noted by [RFC6564<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6564&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=qQyZYT0zxt-ClqRU8hIUUNYk5xi5rQvBozAWxjm67os&e=>] and [RFC7045<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7045&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=9I656AjTSjYpQlMstCRImNUaZvenm4kPNq_rI7-VZAg&e=>].  However, measurement use

   (PDM) Destination Option measurements [RFC8250<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8250&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=tw0fik0bS0uC_ifn0S1ue66X-bs70H7Da0xHoQ2ckAA&e=>] can benefit from

   environments.  [RFC8250<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8250&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=tw0fik0bS0uC_ifn0S1ue66X-bs70H7Da0xHoQ2ckAA&e=>] endorses the use and manipulation of IPv6

   extension headers for measurement purposes, consistent with other

   approved IETF specifications

[acm]

This is the end-of-message I received, but I imagine you intended to

point-out that 8200 and 8250 appear to be in conflict over

addition/deletion of extension headers.

From 8200, section 4:

   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.

I wonder why RFC 2119 requirement terms were not used to

express this idea? We certainly have agreements about

requirements language for Standards Track memos in IETF.

RFC8250 does not involve Extension header insertion/deletion

along the path, but other work-in-progress (in-situ OAM) would.

In any case, a measurement framework should be prepared to

handle some unexpected/discouraged behaviors encountered on the path.

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 15 Apr 2018 08:56:10 -0700

Hello Al,

Apologies for the truncated message ... the full version is available at
https://www.ietf.org/mail-archive/web/ippm/current/msg04999.html.  I'll
resend off-list shortly. In the meantime, my responses below are marked
[cmh]

Mike Heard

On Sun, Apr 15, 2018 at 6:43 AM, MORTON, ALFRED C (AL) <[email-masked]

> Thanks for your review, C.M.

 [ non-controversial stuff elided ]

> *[acm] *
>    focus as noted by [RFC6564 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6564&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=qQyZYT0zxt-ClqRU8hIUUNYk5xi5rQvBozAWxjm67os&e=>] and [RFC7045 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7045&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=9I656AjTSjYpQlMstCRImNUaZvenm4kPNq_rI7-VZAg&e=>].  However, measurement use
>
>    (PDM) Destination Option measurements [RFC8250 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8250&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=tw0fik0bS0uC_ifn0S1ue66X-bs70H7Da0xHoQ2ckAA&e=>] can benefit from
>
>    environments.  [RFC8250 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8250&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=tw0fik0bS0uC_ifn0S1ue66X-bs70H7Da0xHoQ2ckAA&e=>] endorses the use and manipulation of IPv6
>
> *[acm] *
*[cmh]*
RFC 2119 language is not strictly required, and the 6man WG decided not to
introduce it in the transition from 2460 to 8200.

I didn't agree with that decision, but I was "in the rough."

> *[cmh]*
Correct, 8250 does not involve extension header
insertion/deletion/modification along the path.

Thus, the wording of the latter two highlighted sentences above needs to be
reworked.

The first highlighted sentence is now dated (as predicted by Fred Baker in
https://mailarchive.ietf.org/arch/msg/ippm/8sgikiZbSiD4v2VeKK_FA7TkjmM),
but there is ongoing discussion in 6man about updating RFC 8200 to permit
insertion/deletion/modification of extension headers (other than hop-by-hop
options) under certain circumstances. See
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion.

> handle some unexpected/discouraged behaviors encountered on the path.
*[cmh]*
I do not disagree with that; but but might it not be appropriate to change
to Section 4, page 7, fifth paragraph, from:

to something like:

   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.

If that doesn't work for you, perhaps say something to the same effect
could be said in the paragraphs at the bottom of page 6 and the top of page
7.

Note that there were comments on PMTUD in the part of the message that you
didn't get; hopefully those will get to you in the re-send coming shortly.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Sun, 15 Apr 2018 09:15:47 -0700

On Sun, Apr 15, 2018 at 6:43 AM, MORTON, ALFRED C (AL)
<[email-masked]> wrote:
> Subject: Re: Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and
> Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC
>
>
>
> Greetings,
>
>
>
> I have some last call comments on this document. Most (but not all) focus on
> aspects that do not respect RFC 8200 and RFC 8201.
>
>
>
> The Abstract says:
>
>
>
> be removed. Other places in the draft that IPv6 header compression also need
> to be looked at.
>
> [acm]
>
> Clarified as follows:
>
>    focus as noted by [RFC6564] and [RFC7045].  However, measurement use
>
>    (PDM) Destination Option measurements [RFC8250] can benefit from
>
>    environments.  [RFC8250] endorses the use and manipulation of IPv6
>

Alfred,

That is not what this draft is doing. It is advocating header
extension insertion even though that is contrary to RFC8220. (it is
also advocating processing and modification or destination option by
middleboxes which is also contrary to RFC8200). From the draft:

"Destination Option measurements [RFC8250] can benefit from
inspection, modification, addition or deletion of IPv6 extension
headers in hosts along the measurement path."

That ignores the negative protocol implications of extension header
insertion. draft-voyer-6man-extension-header-insertion proposed
updating RFC8200 to allow extension header insertion. The draft got
significant push back and in the 6man discussion a list of problem
with extension header were enumerated. AFAICT the authors of that
draft haven't provided answers to any of the issues yet.

Tom

>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 19 Apr 2018 22:42:44 +0000

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: Sunday, April 15, 2018 12:16 PM
> To: MORTON, ALFRED C (AL) <[email-masked]>
> Cc: C. M. Heard <[email-masked]>; IETF <[email-masked]>; 6man
> <[email-masked]>; IPPM <[email-masked]>
> need
[acm] 

You've cited a sentence fragment above, Tom.

Since PDM / RFC8250 exclusively defines measurement based on DOH,
it is a bit out of place with " ...modification, addition or deletion of 
IPv6 extension headers..." (inspection was a possibility, but not 
discussed in RFC8250)

We are proposing to delete PDM/8250 from the sentence:

   The topic of IPv6 Extension Headers brings current controversies into
   focus as noted by [RFC6564] and [RFC7045].  However, measurement use
   cases in the context of the IPPM framework like in-situ OAM [ref] in
   enterprise environments can benefit from
   inspection, modification, addition or deletion of IPv6 extension
   headers in hosts along the measurement path.

please call me Al,
everyone else does

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 19 Apr 2018 22:42:36 +0000

Hi Mike, Please see in-line replies,
Al

From: C. M. Heard [mailto:[email-masked]]
Sent: Sunday, April 15, 2018 11:56 AM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: IETF <[email-masked]>; IPPM <[email-masked]>; 6man <[email-masked]>
Subject: Re: Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC

Hello Al,

Apologies for the truncated message ... the full version is available at https://www.ietf.org/mail-archive/web/ippm/current/msg04999.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_ippm_current_msg04999.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2J2Uwt4fnAeyqXqxbWRacD0soZcfUMDCm3bv_ySNZ9w&s=Hw-I-LklaEoa82ghk2Aqo5L0sh0Wv-dqicd6ajKCQ4g&e=>.  I'll resend off-list shortly. In the meantime, my responses below are marked [cmh]
[acm]
thanks! it was obvious the end was missing...
I’ve appended your PMTUD comments in this message,
at the end (allegedly, we’ll see if they get through).

Mike Heard
…

[acm]

From 8200, section 4:

[cmh]
RFC 2119 language is not strictly required, and the 6man WG decided not to introduce it in the transition from 2460 to 8200.

I didn't agree with that decision, but I was "in the rough."
[acm]
That’s heavy baggage 6man will have to carry, IMO.
“are not” doesn’t translate to a requirement in any SDO I know.

along the path, but other work-in-progress (in-situ OAM) would.
[cmh]
Correct, 8250 does not involve extension header insertion/deletion/modification along the path.

Thus, the wording of the latter two highlighted sentences above needs to be reworked.
[acm]
I discussed this at length with co-authors, and arrived at
a tighter wording. We simply delete the PDM citation in the 2nd sentence,
and then we refer to the chartered work on in-situ OAM only:

We will also delete the first sentence in the second paragraph above,
and delete the words “and manipulation”:

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

The first highlighted sentence is now dated (as predicted by Fred Baker in https://mailarchive.ietf.org/arch/msg/ippm/8sgikiZbSiD4v2VeKK_FA7TkjmM<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ippm_8sgikiZbSiD4v2VeKK-5FFA7TkjmM&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2J2Uwt4fnAeyqXqxbWRacD0soZcfUMDCm3bv_ySNZ9w&s=y3wSRgv_Y4EZ5aBh6uUbxxRTTMcHDpuIYw2nfcWcH0Y&e=>), but there is ongoing discussion in 6man about updating RFC 8200 to permit insertion/deletion/modification of extension headers (other than hop-by-hop options) under certain circumstances. See https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2J2Uwt4fnAeyqXqxbWRacD0soZcfUMDCm3bv_ySNZ9w&s=15z5qksVffY_75SBOZfwpw76NvzJpu18E9LWFvNillM&e=>.
[acm]
Let me know when there is a consensus call,
I will stand with you for using 2119 modal verbs
in the update...

[cmh]
I do not disagree with that; but but might it not be appropriate to change to Section 4, page 7, fifth paragraph, from:

      corresponding Type-P.

to something like:

      Type-P.

If that doesn't work for you, perhaps say something to the same effect could be said in the paragraphs at the bottom of page 6 and the top of page 7.
[acm]
Your text suggestion WFM, it’s in our working copy now.

Note that there were comments on PMTUD in the part of the message that you didn't get; hopefully those will get to you in the re-send coming shortly.

Mike Heard

[ ...  truncated portion follows …]

   [...] Path MTU Discovery

   for IP version 6 (PMTUD, [RFC8201<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8201&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=QmkalCghj2UWXAYbUNBvVzmVYsjZz3QCRNMcCapKLHI&s=wuYf87r5Jd9R1REA97G2-ftjyVl77Myo6qmYQAHE4JU&e=>]) or Packetization Layer Path MTU

   Discovery (PLPMTUD, [RFC4821<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4821&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=QmkalCghj2UWXAYbUNBvVzmVYsjZz3QCRNMcCapKLHI&s=xTmoRZSTUrTKeA0f9Y_gPjyRuOeOQEPtPe2blgphY40&e=>]) is recommended to prevent

   header manipulation.

The trailing clause "(or ICMP error messages) as a result of IPv6 extension header manipulation" should be removed, as it is just plain wrong. PMTUD relies on ICMP Packet Too Big messages for proper operation, and in-flight increases in packet length due to insertion of extension headers actually break PTMTUD.

[acm]
Your deletion WFM, it’s in our working copy now.

      intermediate nodes.  As noted in Section 4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2D2330-2Dipv6-2D04-23section-2D4&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=QmkalCghj2UWXAYbUNBvVzmVYsjZz3QCRNMcCapKLHI&s=OmLE-PPyxr3OLg9q10BoDE4yGhg_E_PNGhibcCMmWWk&e=> for IPv6 extension

If the changes I recommend above are implemented, it will be necessary to remove the clause "As noted in Section 4 for IPv6 extension header manipulation,"

[acm]
again WFM, Thanks.

Mike Heard

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2018 18:35:45 +0200

On 04/20/2018 12:42 AM, MORTON, ALFRED C (AL) wrote:
[....]
> */[acm] /*
> 
> *That’s heavy baggage 6man will have to carry, IMO.*
> 
> *“are not” doesn’t translate to a requirement in any SDO I know.*
> 
>  
> 

Well, it should not. RFC8200 seems to be crystal clear in this respect,
and we burned a sensible number of electrons to get there.

>       resulting packet may be standard-formed, with a corresponding

Strongly disagree, for the reasons stated above.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2018 11:46:54 -0500

Al,

[...]
>    headers in hosts along the measurement path.

Given the discussion in ITF LC/6man regarding EH insertion an
modification, I think the aforementioned text shouldn't be there, or, at
the very least, it should be made crystal-clear that EH insertion or
modification violates current specs (RFC8200).

Unfortunately, I haven't gone through this whole I-D, yet. BUt, when it
comes to using EHs for anything, folks should be made aware about the
issues related to RFC7872.

Thanks!

Cheers,