[ippm] Erik Kline's Discuss on draft-ietf-ippm-ioam-ipv6-options-09: (with DISCUSS and COMMENT)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-ippm-ioam-ipv6-options-09: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

# Internet AD comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @ekline

* Thanks to 6MAN chairs Bob, Ole, and Jen for their last-minute
  "IPv6 Directorate" reviews.  Some of their comments are reflected below.

* There was kind of leaning toward concluding that the rewriting of a
  Hop-by-Hop option's size was both against the spirit of RFC 8200 and
  not actually against the letter.  I'm not sure that's actually the case
  and so my biggest DISCUSS is this point (more below).

## Discuss

### S4

* I don't think the Incremental Trace Option is something that can be
  supported by current text in RFC 8200.  While is makes sense to have this
  behavior described in RFC 9197, I don't think IPv6 HbH can support it.

  My rationale for seeing this as a protocol violation is as follows.

    - RFC 8200 S4.2 says this about the on-path mutability bit and the
      expectations that result:

      """
      The third-highest-order bit of the Option Type specifies whether or
      not the Option Data of that option can change en route to the
      packet's final destination.  When an Authentication header is present
      in the packet, for any option whose data may change en route, its
      entire Option Data field must be treated as zero-valued octets when
      computing or verifying the packet's authenticating value.
      """

    - Specifically, only the Option Data (not Option Length) is allowed to
      change.  Any AH header, for example, would still have processed the
      entire option with only the Data being zeroed -- the existence of the
      option and the length of it would still have been part of the AH
      computation.

  Unless there's some misunderstanding here I think this option would need
  removing from the document.

* I think text needs to be added to make it clear that whatever options are
  used they MUST be added, though not necessarily "filled in", by the
  originator of the packet (the node bearing the interface assigned the
  outermost Source Address).

  The reasoning here again is the defined behavior of AH processing.  Any
  options, even on-path mutable ones, MUST be present in the Hop-by-Hop
  option when an AH is computed.


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


## Comments

### S5.1

* In C2: "domain SHOULD ensure that the addition of OAM information does not
  lead to fragmentation of the packet"

  This should probably be rephrased to be more IPv6-compatible (as there is
  no on-path fragmentation).  Perhaps:

  "does not lead to an ICMP Packet To Big error message being sent to the
  originator and the packet being dropped"

  or something to that effect.

* Also in C2: "exceeds the packet size beyond PTMU" in the domain, etc.

  It may be worth noting that any single node can only know the configured
  MTU of its outgoing links, and that this is why it MUST be a domain-managed
  parameter.

* C3 appears to create a requirement for some very deep packet inspection on
  IOAM domain egress.

  Also, if there's going to be talk of ICMPv6 you probably need to add a
  reference to RFC 4443.

* With respect to C4, I'd defer to the other IESG comments.

* C5: this seems like it might be important for a Standards Track feature?

  If it were Experimental, perhaps, then there could be text saying that
  learning how this might best be done was an expected outcome of the
  experiment?