|
Hi Mike, Please see in-line replies, Al From: C. M. Heard [mailto:heard@xxxxxxxxx]
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] [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
[ non-controversial stuff elided ]
[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.
[cmh] Correct, 8250 does not involve extension header insertion/deletion/modification along the path. [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: 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. 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), 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. [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: 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.
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. [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 …] Section 4, page 7, next-to-last paragraph says: [...] Path MTU Discovery
for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU
Discovery (PLPMTUD, [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. [acm]
Your deletion WFM, it’s in our working copy now. 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 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," [acm]
again WFM, Thanks. Mike Heard |
