Re: [tsvwg] [EXTERNAL] Re: Comment on "draft-ietf-tsvwg-udp-options-28"

["[e-mail]" <[e-mail]>]

Fred,

RFC2675 is operational. If there is a decouple-able update, it should be issued.

If you’re proposing IP parcels will upend RFC2675 to get to parcels, you may be asking too much IMO.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 21, 2023, at 10:51 AM, Templin (US), Fred L <[e-mail]> wrote:
> 
> Joe, the parcels draft updates RFC2675 and will come along hopefully in the
> very near future – there is no rush or emergency for a minor RFC2675 update
> in the even nearer future.
>  
> Everyone should read and understand what IPv6 Parcels and Advanced Jumbos
> is offering – it covers all parcel/jumbo sizes ranging from the very small to the
> very large. – and, the small(ish) ones should be able to use UDP options.
>  
> Fred
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, December 21, 2023 10:45 AM
> To: Templin (US), Fred L <[e-mail] <mailto:[e-mail]>>
> Cc: Tom Herbert <[e-mail] <mailto:[e-mail]>>; Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; TSVWG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [tsvwg] [EXTERNAL] Re: Comment on "draft-ietf-tsvwg-udp-options-28"
>  
> Hi, Fred,
>  
> I was speaking of a more modest 1-for-1 update of RFC2675.
>  
> Parcels is a lot more than that, and whether that flies or not, it seems like it can/should be decoupled from such a 1-for-1.
>  
> Joe
>  
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Dec 21, 2023, at 10:33 AM, Templin (US), Fred L <Fred.L.Templin=[e-mail] <mailto:Fred.L.Templin=[e-mail]>> wrote:
>  
> > IMO, the IPv6 jumbogram RFC should be revised:
>  
> Here is the revision:
>  
> https://datatracker.ietf.org/doc/draft-templin-6man-parcels/
>  
> Folks seem keen on breaking UDP options so they won’t work properly under the new revision;
> please don’t do that.
>  
> Fred
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, December 21, 2023 10:16 AM
> To: Tom Herbert <[e-mail] <mailto:[e-mail]>>
> Cc: Templin (US), Fred L <[e-mail] <mailto:[e-mail]>>; Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; TSVWG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [tsvwg] [EXTERNAL] Re: Comment on "draft-ietf-tsvwg-udp-options-28"
>  
> EXT email: be mindful of links/attachments.
> 
>  
> FWIW
>  
> YES:
> UDP options Updates 768 because it allows the UDPlength to not match the IP packet and sets bounds for that (i.e., it can’t be longer than the IP packet end).
> RFC2675 should have updated RFC768 because it defines what would otherwise be illegal values for the UDPlength **AND** because it redefines how the UDP checksum is computed (to use length derived from the IP header).
>  
> NO:
> UDP options won’t be defining length=0. That happened in RFC2675 and ONLY in the context of IPv6 
> though it DID do so regardless of whether jumbograms were used or not - in a non-backward compatible way
> RFC768 doesn’t need to define other values for UDPlength; they’re all intrinsically invalid except as overriden by RFC2675
> UDP options do NOT preclude the use of IP jumbograms
> Just the way IPv6 jumbograms “warp” UDP per RFC2675
>  
> IMO, the IPv6 jumbogram RFC should be revised:
> To update RFC768
> To confine the meaning of UDPlength==0 to only when the jumbo length IP option is present
> And, preferably (if possible), to update that mechanism to support UDP options
> I think UDP options are useful enough that this change might be important
> I have a few ideas for this, but the key IMO is to keep the changes local to UDP, e.g., to use the last 4 bytes of the IP payload to indicate the true UDP length.
>  
> Joe
>  
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> 
> On Dec 21, 2023, at 8:54 AM, Tom Herbert <tom=[e-mail] <mailto:tom=[e-mail]>> wrote:
>  
>  
>  
> On Thu, Dec 21, 2023 at 7:19 AM Templin (US), Fred L <Fred.L.Templin=[e-mail] <mailto:[e-mail]>> wrote:
> Sorry Mike, there is no reason for ‘draft-ietf-tsvwg-udp-options’ to go looking down into intarea
> space to try to capture all of the ways lower layers might represent a length greater than 65535.
> This draft needs to tell what UDP Length = 0 means from the UDP perspective, and leave intarea
> matters to intarea. RFC768 says:
>  
> “Length  is the length  in octets  of this user datagram  including  this
> header  and the data.   (This  means  the minimum value of the length is
> eight.)”
>  
> This means that RFC768 is in need of an update that tells what the values 0-7 mean if
> they appear in the UDP Length. ‘draft-ietf-tsvwg-udp-options’ should be the document
> that updates RFC768 at least as far as defining what the value 0 means, and without
> reference to any intarea documents.
>  
> Fred,
>  
> RFC2675 clearly defines alternative semantics for UDP length == 0, so RFC2675 did update RFC768 even if it didn't explicitly state that. I believe that omission could be rectified with an errata for RFC2675. draft-ietf-tsvwg-udp-options is not changing any semantics or UDP requirements so I don't believe it updates RFC768. IMO it is sufficient to just say UDP options are not sent when Jumbograms are used with a reference to RFC2675, and UDP options are not present in received packets when UDP Length is less than eight.
>  
> Tom
>  
>  
> Fred
>  
> From: C. M. Heard <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, December 20, 2023 2:49 PM
> To: Templin (US), Fred L <[e-mail] <mailto:[e-mail]>>
> Cc: Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; TSVWG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [tsvwg] Comment on "draft-ietf-tsvwg-udp-options-28"
>  
> Fred,
>  
> I don't buy that.
>  
> No standards-track RFC other than RFC 2675 ever endorsed the notion that Length == 0 in the UDP header mean that the true UDP length is encoded in some other way.
>  
> And even if we accept that notion in general, an implementation has no recourse except to consider Length == 0 in the UDP header as invalid unless it knows what that "other way" is.
>  
> For this reason, we can give useful advice on what to do when Length == 0 in the UDP header only in the case of IPv6 Jumbograms as specified in RFC 2675.
>  
> Thad advice could take the form of the following text, or something similar, placed at the end of draft-ietf-tsvwg-udp-options-28 Section 7: 
>  
> "Note: UDP options cannot be supported when a UDP packet is transmitted inside an IPv6 Jumbogram since there is no independent UDP Length in that case. See [RFC2675] for details."
>  
> Mike Heard
>  
> P.S. RFC 2675 does not state that it updates RFC 768, not is RFC 2675 listed in the RFC 768 datatracker entry as  being updated by RFC 2675. Are these omissions worthy of errata?
>  
> On Wed, Dec 20, 2023 at 12:06 PM Templin (US), Fred L wrote:
> Mike, at the UDP layer, we know that if the length of the UDP header plus UDP data
> exceeds 65535 then it cannot be represented in the 16-bit UDP Length field and so
> 0 should be written into that field instead and UDP options cannot be used.
>  
> This presumes that the true length is *somehow* encoded at the IP layer and
> although RFC2675 specifies one way of doing that, there may be future alternative
> ways of doing it also. Therefore, this transport-area document should focus UDP
> layer considerations *only* without being overly proscriptive about the IP layer
> which is within the purview of intarea.
>  
> Fred
>  
> From: C. M. Heard <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, December 20, 2023 11:34 AM
> To: Templin (US), Fred L <[e-mail] <mailto:[e-mail]>>
> Cc: Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; TSVWG <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [tsvwg] Comment on "draft-ietf-tsvwg-udp-options-28"
> Fred,
>  
> I think that text would be confusing to many readers. You may be keenly aware of IPv6 Jumbograms and how it is possible for the the length of a UDP datagrams can exceed 65535 octets, but I would bet that many (maybe most) folks would simply scratch their heads and say "huh?" And what is the objection to citing RFC 2675? Isn't it presently the only standardized means for doing so? Is any another means of doing so documented somewhere?
>  
> Mile
>  
> On Wed, Dec 20, 2023 at 11:24 AM Templin (US), Fred L <[e-mail] <mailto:[e-mail]>> wrote:
> Mike, I would favor not being overly proscriptive and not even including a reference
> to RFC2675 at all. Instead, have the draft simply say something like:
>  
>       “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 and do not include UDP options.”
>  
> I would not be in favor of saying anything explicit about the Jumbo Payload option
> itself. RFC2675 provides current guidance for the Jumbo Payload option, but future
> specs may update RFC2675.
>  
> Thank you - Fred
>  
> From: C. M. Heard <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, December 20, 2023 11:05 AM
> To: Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; Templin (US), Fred L <[e-mail] <mailto:[e-mail]>>
> Cc: TSVWG <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] Re: [tsvwg] Comment on "draft-ietf-tsvwg-udp-options-28"
>  
> EXT email: be mindful of links/attachments.
> 
>  
> On Wed, Dec 20, 2023 at 10:06 AM Gorry Fairhurst wrote:
> On 20/12/2023 17:44, Templin (US), Fred L wrote:
> 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.
>  
> Fred
>  
> This would apply I think if you had an Dest Ext Header carrying the option?
> 
> Personally, I'd rather the IETF make RFC2675 Historic ;-), since I don't think there is deployment at scale, but that's another story (akahttps://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-change-status-of-rfc-2675-to-historic-00) !
> 
> Gorry (as an individual)
> 
> According to RFC 2675, one has a jumbo UDP payload if, and only if, all of the following conditions apply:
>  
> - the IPv6 Payload Length field is zero and the link layer framing indicates octets beyond the IPv6 header;
> - there is a Hop-By-Hop Options header containing the Jumbo Payload Option;
> - the final Next Header in the chain of extension headers indicates UDP; and
> - the UDP payload length is set to zero (indicating that the UDP payload length is not present).
>  
> That last condition implies that there is no longer a redundant length field to define where the UDP payload ends and the surplus area (aka options trailer) begins.
>  
> Therefore, support for UDP options is not possible for UDP datagrams that have a jumbo payload.
>  
> Fred is correct that RFC 2675 is still a standard, and it is not within the remit of TSVWG to change that. Nor, IMO, would it be appropriate to further delay UDP options to do so.
>  
> What we could do is add a statement to the effect that UDP options are not supported in in UDP datagrams with jumbo payloads and add a reference RFC 2675.
>  
> Note that there is a corner case where the IPv6 Payload Length is non-zero and the Jumbo Payload option is present; this would indicate the presence of a normal UDP payload and a jumbo surplus area. In principle, this could be allowed, but I find it implausible that this would actually be useful, even if the Jumbo Payload option actually enjoyed real-world deployment.  I have no opposition to allowing consenting implementations to support it if they want to do so, as long as we can craft a very brief description that does not pollute the UDP options specification with lengthy and in practice irrelevant text.
>  
> Would it be appropriate to open an issue for this in the github tracker?
>  
> Mike Heard