* Section 9.4: Agreed text for the (simplest) way to handle options in fragments of a datagram.

[gorryfair]

This topic was raised by Mike Heard

[gorryfair]

Is it actually important to have per-fragments options - this seems like something perhaps we could manage without if it simplifies the design?

[Mike-Heard]

Like #1 and #2, this is also related to

https://mailarchive.ietf.org/arch/msg/tsvwg/D99trU_nsq4rRGT24gNeeDnkfoE/

[Mike-Heard]

Is it actually important to have per-fragments options - this seems like something perhaps we could manage without if it simplifies the design?

This has been discussed at length before . See, for example, the threads starting at:

https://mailarchive.ietf.org/arch/msg/tsvwg/9ZGGJItKmd6GjtEU9vhGJQCCY6c/

https://mailarchive.ietf.org/arch/msg/tsvwg/OLlcbfRtK_YHdeUFljwg_VPOgPk/

For me, the main issue is that if the fragmentation and reassembly machine has to deal with arbitrary options, it tends to undermine the capability to for it to be implemented as a "bump in the stack." In most cases there is no obvious use for per-fragment options. AUTH and UENC could sensibly be used on fragments, but the advantages of providing both per-fragment and per-datagram authentication and/or encryption is not obvious. IPSec doesn't do that. It is applies to reassembled datagrams only.

All that being said, I'd rather ship a spec with per-frag options and have them not be used than have a delay of an additional X months in order to re-litigate the issue.

[auerswal]

It would be nice to have a diagram illustrating UDP Options based fragmentation.

[Mike-Heard]

It would be nice to have a diagram illustrating UDP Options based fragmentation.

https://mailarchive.ietf.org/arch/msg/tsvwg/0RptobbqczCVoOy-B8L_CJaj25w/ has a rewrite of Section 9.4 with such a diagram.

[gorryfair]

Please also revise text around: The "FRAG option of the first segment" - which might be the first fragment.

[Mike-Heard]

Please also revise text around: The "FRAG option of the first segment" - which might be the first fragment.

The text proposed in https://mailarchive.ietf.org/arch/msg/tsvwg/0RptobbqczCVoOy-B8L_CJaj25w/ would resolve this matter by removing the following paragraph in its entirety:

  Note: per packet options can occur either at the end of the
  original user data or be placed after the FRAG option of the
  first segment, with the Reassembled Datagram Option Start (RDOS)
  in the terminal FRAG option set accordingly. This includes its
  use in atomic fragments, where the terminal option is the initial
  and only fragment.

In fact what is stated in the above paragraph does not work. See also Issue #2.

[jtouch]

I agree with the proposed changes and the simplicity to a single overall format (i.e., per-datagram options at the end of the datagram always). Incorporated in -23, with minor tweaks for English flow.

[gorryfair]

Discussed at Interim and closed.