>> Each option SHOULD NOT occur more than once in a single UDP
datagram, the only exceptions being NOP, EXP, and UEXP. If an option
other than these occurs more than once, a receiver MUST interpret
only the first instance of that option and MUST ignore all others.
Section 24 provides additional advice for DOS issues that involve
large numbers of options, whether valid, unknown, or repeating.
>> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more
than once using the same ExID (see Sections 11.10 and 12.3).
The "first instance only" rule is not respected in the existing instructions on what to do with per-fragment instances of MDS, MRDS, REQ, RES, and TIME (see sections 11.5 through 11.8). The instructions for MDS and MRDS recommend reporting the minimum value received; the instructions for REQ and RES recommend reporting the the most recent i.e., last) value received; and the instructions for TIME recommend reporting the minimum and maximum values without specifying what value should be reflected to the remote end (if the values in question are TSVALs). And none of these instructions are explicit about what to do if one of these options is received both in a fragment and in the surplus area of the corresponding reassembled UDP packet.
The main use that I see for allowing MDS, MRDS, REQ, RES, and TIME on UDP fragments (including atomic ones) is "to provide limited support for UDP options in systems that have access to only the initial portion of the data in incoming or outgoing packets," as noted near the end of Section 11.4. For that use case, it would IMO suffice to stipulate that the first instance received is the one reported to the upper layer, thus sustaining the text quoted above, and I recommend that the per-frag text in sections 11.5 through 11.8 be modified accordingly.
In Section 10 I see;
The "first instance only" rule is not respected in the existing instructions on what to do with per-fragment instances of MDS, MRDS, REQ, RES, and TIME (see sections 11.5 through 11.8). The instructions for MDS and MRDS recommend reporting the minimum value received; the instructions for REQ and RES recommend reporting the the most recent i.e., last) value received; and the instructions for TIME recommend reporting the minimum and maximum values without specifying what value should be reflected to the remote end (if the values in question are TSVALs). And none of these instructions are explicit about what to do if one of these options is received both in a fragment and in the surplus area of the corresponding reassembled UDP packet.
The main use that I see for allowing MDS, MRDS, REQ, RES, and TIME on UDP fragments (including atomic ones) is "to provide limited support for UDP options in systems that have access to only the initial portion of the data in incoming or outgoing packets," as noted near the end of Section 11.4. For that use case, it would IMO suffice to stipulate that the first instance received is the one reported to the upper layer, thus sustaining the text quoted above, and I recommend that the per-frag text in sections 11.5 through 11.8 be modified accordingly.