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] and [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] 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] 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]) 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.
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,"
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 via https://datatracker.ietf.org/ doc/draft-ietf-ippm-2330-ipv6/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/ No IPR declarations have been submitted directly on this I-D.ballot/
