Address IPv6 jumbo grams

[jtouch]

Fred Templin noted:

Hello, if I understand this draft correctly the UDP options occupy the space beyond the end of the payload portion indicated by the “UDP Length” field and continuing up to the end of the remaining payload indicated by the “IP {Total, Payload} Length” field. However, RFC2675 states:

  “When sending a UDP packet, if and only if the length of the UDP
  header plus UDP data is greater than 65,535, set the Length field
  in the UDP header to zero.”

Since RFC2675 is still considered a part of the IPv6 standard, I think the UDP options draft should cite it and say exactly what should be done if UDP Length is 0. For example, nodes should not consider all octets of a packet with IP length greater than 65,535 and UDP length 0 as the surplus area for UDP options.

This doc (UDP options) should note:

• RFC2675 exists as a Standard, though it does not actually update RFC768
• RFC2675 defines "UDPlength == 0" as indicating an IPv6 jumbogram ---- in an IPv6 with jumbo length, the jumbo length and IP options are used to compute the UDP length, so there's no way to indicate the start of a separate surplus area and UDP options are not available ---- in an IPv6 without a jumbo length, the IPv6 payload length and IP options are used to compute the UDP length, so there's no way to indicate the start of a separate surplus area and UDP options are not available ----- this RFC does NOT define what happens with an IPv4 packet with UDP length==0, so there is no similar problem there
• UDP options are not compatible with RFC2675

It's unfortunate that RFC2675 was shortsighted in assuming use of UDPlength==0 to indicate jumbo UDP datagrams, especially given the information is already indicated by the presence of the IP jumbo length option. We might have used the field either to indicate the surplus length directly (which would still default to 0 and have been compatible here).

Joe

[jtouch]

And here's the proposed text:

"Note: UDP options cannot be supported when a UDP packet is has no independent UDP Length. The only known such case is when UDPlength==0 in IPv6, intended for (but not limited to) IPv6 jumbograms. See [RFC2675] for details, although note that this technique is “Standard" but did not “update" RFC768."

[Mike-Heard]

And here's the proposed text:

"Note: UDP options cannot be supported when a UDP packet is has no independent UDP Length. The only known such case is when UDP Length==0 in IPv6, intended for (but not limited to) IPv6 Jumbograms. See [RFC2675] for details, although note that this technique is “Standard" but did not “update" RFC768."

I concur with the text, modulo minor edit (I tried to bold these, but it did not seem to work).

[jtouch]

Thanks. I realize it needed minor wordsmithing.

Joe

On Dec 21, 2023, at 5:13 PM, Mike-Heard @.***> wrote:

work).

—

[Mike-Heard]

Actually, now that I re-read the text -- isn't UDP Length == 0 specified in RFC 2675 specifically limited to Jumbograms?

“When sending a UDP packet, if and only if the length of the UDP header plus UDP data is greater than 65,535, set the Length field in the UDP header to zero.”

If so, perhaps the text should become

"Note: UDP options cannot be supported when a UDP packet has no independent UDP Length. The only known such case is when UDP Length==0 in IPv6, intended specifically for IPv6 Jumbograms. See [RFC2675] for details, although note that this technique is “Standard" but did not “update" RFC768."

There is also a typo fix above: s/is has/has/. I missed that too during the first pass yesterday.

Thanks.

[jtouch]

Although RFC2675 initially says: When sending a UDP packet, if and only if the length of the UDP header plus UDP data is greater than 65,535, set the Length field in the UDP header to zero.

It also says, unfortunately:

  In the unexpected case that the UDP Length field is zero but no
  Jumbo Payload option is present (i.e., the IPv6 packet is not a
  jumbogram), use the Payload Length field in the IPv6 header, in
  place of the Jumbo Payload Length field, in the above calculation.

So this issue is NOT specific to the IPv6 jumbo gram option use. I described this (though I didn't quote the text) in my first post here on Github. So my original text with your two typo fixes should be used:

"Note: UDP options cannot be supported when a UDP packet has no independent UDP Length. The only known such case is when UDP Length==0 in IPv6, intended for (but not limited to) IPv6 Jumbograms. See [RFC2675] for details, although note that this technique is “Standard" but did not “update" RFC768."

[Mike-Heard]

Fair enough 👍

I wonder, though, how many implementations of UDP over IPv6 that do not support Jumbograms actually follow that rule, given that RFC 2675's update to the base UDP spec isn't exactly well-documented. Ironically, the errant middleboxes found by the Aberdeen group that use the IP payload length in place of UDP Length for checksum calculations would be doing the correct thing in this case, albeit by accident.

[jtouch]

This is why I think a stand-alone update is warranted. Depending on how widely use this is, maybe even a change that might allow UDP options (as I noted above, e.g., to indicate the surplus length directly, which would still default to 0 when not used). I can't see a way to do that which does not impact existing installs, though.

[Mike-Heard]

This is why I think a stand-alone update is warranted. Depending on how widely use this is, maybe even a change that might allow UDP options (as I noted above, e.g., to indicate the surplus length directly, which would still default to 0 when not used). I can't see a way to do that which does not impact existing installs, though.

Yes, a stand-alone update that is not part of the UDP Options spec) is the way to go. Making RFC2675 Historic, as suggested in https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-change-status-of-rfc-2675-to-historic-00 might be the least disruptive way to go, given the level of deployment. But I digress.

[jtouch]

In -29, text added to Section 22 (interactions with other RFCs). Suggest the WG revive draft-jones-6man-historic-rfc2675 ASAP (included a ref until that occurs).

[Mike-Heard]

The fix in -29 looks good except for a minor typo:

The technique has been for deprecation [Jo19].

should probably say

The technique has been proposed for deprecation [Jo19].

[jtouch]

Will fix in 30On Mar 4, 2024, at 11:15 AM, Mike-Heard @.***> wrote: The fix in -29 looks good except for a minor typo:

The technique has been for deprecation [Jo19].

should probably say

The technique has been proposed for deprecation [Jo19].

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[jtouch]

Fixed in -30.