For the record, Fred, I do not agree with that. IP Parcels should have a new protocol number (once again, see pont #3 here <https://mailarchive.ietf.org/arch/msg/tsvwg/QPVVjD0sGhMz9Xw86Xb_Z3EL6Yc/>). One is needed for safety and correctness, as there is NEVER any guarantee that despite all efforts something intended to be confined to a limited domain won't escape, despite your arguments to the contrary. A new protocol number assures that parcel-unaware endpoints will simply drop an IP packet containing parcels. Yes, I know, that complicates the parcels spec somewhat, but the onus for correctness in all domains is on those who may use IP Parcels, not the Internet in general. We've seen a variant of this movie before with Segment Routing, I think.
Thanks Mike Heard On Tue, Nov 19, 2024 at 4:09 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Lloyd, the parcel/AJ behavior is indicated by a new IPv6 HBH option that > must be present, just the same way that the Jumbo Payload HBH option must > be present in UDP jumbograms. The presence of the HBH option indicates the > arrangement of the multi-segment UDP datagram that follows with no need to > a new IP protocol number. > > Thank you - Fred > > > -----Original Message----- > > From: lloyd.w...@yahoo.co.uk <lloyd.wood=40yahoo.co...@dmarc.ietf.org> > > Sent: Tuesday, November 19, 2024 3:58 PM > > To: C. M. Heard <he...@pobox.com>; to...@strayalpha.com > > Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk>; int-area <int-area@ietf.org>; > 6man <i...@ietf.org>; TSVWG <ts...@ietf.org> > > Subject: [EXTERNAL] [tsvwg] Re: UDP options [was IP Parcels and Advanced > Jumbos (AJs)] > > > > These proposed changes to UDP are thoughtprovoking. > > > > When UDP-Lite (RFC3828) was proposed, it was eventually shunted to its > own IP protocol number, rather than risk messing up existing UDP > > implementations and semantics for even a very minor change. I gather > that move to a different port was done very late in the process. > > > > The changes proposes in UDP options and in parcelling seem much much > larger. Surely they should be treated as UDP-Lite was, and as UDP- > > alike but not as UDP, and given their own IP protocol number? > > > > thanks > > > > > > Lloyd Wood > > lloyd.w...@yahoo.co.uk > > > > > > > > > > > > > > On Wednesday 20 November 2024 at 05:12:00 GMT+11, to...@strayalpha.com < > to...@strayalpha.com> wrote: > > > > > > > > > > > > Hi, all, > > > > I have not investigated this issue. Any new UDP option proposal would > need to be evaluated in detail AND would need to follow the design > > requirements in the UDP options doc. > > > > Further, I would urge any option that is per-IP packet to be an IP > option; UDP options are intended for user endpoints, not the (existing) > > protocol subsystem per se. I don’t yet understand whether the proposed > parcel parameters should be an IP option or UDP option, but UDP > > options are NOT intended as a place you can put info that you don’t want > to or can’t put in IP options per se. IP options are per IP packet; UDP > > options are per UDP message. We’d need to understand why parcels are > fiddling with UDP option space - which may already be used by the > > UDP endpoints. > > > > Joe > > > > > > — > > Dr. Joe Touch, temporal epistemologist > > www.strayalpha.com > > > > > > > On Nov 14, 2024, at 4:54 PM, C. M. Heard <he...@pobox.com> wrote: > > > > > > Fred and WG participants, > > > > > > I have finally freed up some cycles to > read draft-templin-6man-parcels2-14, and I have found some issues with it > that need to be addressed > > with respect to its handling of UDP. > > > > > > The big one -- if I have correctly understood what I have read -- is > that it's possible for a single parcel of a parcellated UDP packet to be > > turned into a stand-alone UDP packet (see Section 7.1) and delivered to > an end system as such (see Section 7.4). That packet would contain > > a Parcel Parameters UDP Option to tell the endpoint host that the packet > is a parcel and not a complete UDP datagram, but the option kind is > > taken from the SAFE option space (KIND = 127; see > draft-ietf-tsvwg-udp-options#section-10). Legacy endpoints that do not > understand UDP > > options will ignore that SAFE option and will deliver the parcel as if > it were a complete UDP datagram. That, to my mind, is completely > > unacceptable. Unlike TCP, which is a byte-stream protocol in which > segment boundaries have no meaning for the upper layer, UDP is a > > datagram protocol in which message boundaries are meaningful to the > upper layer. The protocol has a contract with the upper layer to deliver > > a message as it was submitted or not at all. Delivering a parcel in a > manner that can be misinterpreted as a complete datagram violates that > > contract. > > > > > > It is possible to repair this defect by making the Parcel Parameters > Option, or something with equivalent functionality, into an UNSAFE > > option. My suggestion would be to define an UNSAFE version of the > existing FRAG option (see draft-ietf-tsvwg-udp-options#section-11.4) -- > > let's call it UFRAG -- that would allow for packet sizes greater than > 65,535 bytes. The same option could be used to send singleton advanced > > jumbo packets as atomic fragments. This would avoid any need to modify > the base UDP and UDP Options specifications. > > > > > > Additionally: during the review of draft-ietf-tsvwg-udp-options, Joe > Touch correctly pointed out that RFC 2765 (and its predecessor RFC > > 2147) failed to note that it updated RFC 768. Similar concerns apply to > TCP. If this draft foes forward, it should note that it updates the UDP > > and TCP specifications, and it should get buy-in from TSVWG and TCPM. > > > > > > Thanks and regards, > > > > > > Mike Heard > > > > > > > > > > > > > > > > > > On Sun, Sep 29, 2024 at 3:51 PM C. M. Heard <he...@pobox.com> wrote: > > >> Fred, > > >> > > >> I currently hold the editing pen for the changes to the UDP Options > draft that have been requested prior to the shepherd report, and my > > intention is to remain silent about how, if at all, IP Parcels and > Advanced Jumbos (AJs) will support UDP Options. > > >> > > >> I'll provide comments on the IP Parcels and Advanced Jumbos work at a > later date, when I have spare intellectual cycles to fully > > comprehend the contents of draft-templin-6man-parcels2. At this point I > must confess that, like Brian, I do not understand how a receiver will > > locate the options trailer in the case of an IP Payload Length exceeding > 65535. Like Joe, I think it would be better to put the options just after > > the UDP header and make a new UNSAFE option to delimit the position > where the options end and the user data begins.. But that discussion > > (and the corresponding update to the UDP options draft) can occur when > it is ripe; IMO that is not the case at this time. > > >> > > >> Respectfully, > > >> > > >> Mike Heard > > >> > > >> On Sun, Sep 29, 2024 at 3:07 PM Templin (US), Fred L <Fred.L.Templin= > 40boeing....@dmarc.ietf.org> wrote: > > >>> > > >>> > > >>> IP parcels and Advanced Jumbos (AJs) of all sizes ranging from 1 to > 2^32 are now eligible > > >>> for using UDP options. This is just one way in which they offer a > better service than RFC2675 > > >>> Jumbograms, but there are also many others. > > >>> > > >>> Joe, you can either note this in your draft or just leave it be and > let my draft do an > > >>> “updates UDP options”. > > >>> > > >>> Thank you - Fred > > >>> > > >>> > > >>> > > >>> > > >>> From: Brian Carpenter <brian.e.carpen...@gmail.com> > > >>> Sent: Saturday, September 28, 2024 2:20 AM > > >>> To: Gorry (erg) <go...@erg.abdn.ac.uk> > > >>> Cc: Joe Touch <to...@strayalpha.com>; Templin (US), Fred L < > fred.l.temp...@boeing.com>; Tim Chown <tim.ch...@jisc.ac.uk>; > > Internet Area <Int-area@ietf.org>; IPv6 List <i...@ietf.org>; tsvwg > IETF list <ts...@ietf.org> > > >>> Subject: [EXTERNAL] Re: [tsvwg] Re: UDP options [was IP Parcels and > Advanced Jumbos (AJs)] > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> EXT email: be mindful of links/attachments. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> That works for me.. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> (via tiny screen & keyboard)Regards, Brian Carpenter > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Sat, 28 Sept 2024, 19:08 Gorry (erg), <go...@erg.abdn.ac.uk> > wrote: > > >>> > > >>> > > >>>> See below> On 28 Sep 2024, at 04:05, Brian E Carpenter < > brian.e.carpen...@gmail.com> wrote:> > Joe,> On 28-Sep-24 03:13, > > to...@strayalpha.com wrote:>>>> On Sep 27, 2024, at 7:58 AM, Templin > (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > > wrote:>>> >>>> Indeed. But if sendmsg() and recvmsg() can and do > generate RFC2675 packets, it means that any discussion of obsoleting > > RFC2675 should be>>>> off the table.>>> >>> No one that I know of has > suggested obsoleting RFC2675 - my documents do not say > > "obsoletes" (nor even "updates”).>> That approach to UDP jumbo grams is > incompatible with UDP options.>> And yes, there was a proposal to > > move that RFC to historic:>> Jones, T., G. Fairhurst, "Change Status of > RFC 2675 to Historic," draft-jones-6man-historic-rfc2675, May 2019.>> > > We COULD have a new option with a longer length, but that’s not in our > baseline draft.> > Wouldn't that be tricky, because the options follow > > the whole payload as I understand it? So a JumboUDPgram has to be > received in full, however big it is, before the option saying that it's a > > jumbo can be received and interpreted.> > Where the udp-options draft > says:> >>> The technique has been proposed for deprecation [Jo19].> > > > I think you'd better change it to something like:> > The technique is > known to be in active use in special situations, so cannot reasonably be > > deprecated. However, users of this technique cannot simultaneously use > UDP options.> > Brian> I do not think the I-D needs to say anything > > about the deployment status of jumbograms, that another topic.I suggest > if people wish, we just say that users of this technique can or cannot > > simultaneously use UDP options.Gorry > > > > >>>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > > > >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
