[IPv6]Re: Fwd: New Version Notification for draft-ietf-6man-eh-limits-17.txt

[Tom Herbert <[e-mail]>]

On Tue, Dec 10, 2024 at 11:06 AM Templin (US), Fred L
<Fred.L.Templin=[e-mail]> wrote:
>
> Tom, answering my own message, RFC9673 seems to allow end systems to ignore HBH options
> even if they set a bit indicating a packet containing an unrecognized option should be dropped.
> I do not see the "eh-limits" draft changing that behavior in any way. What this means is that the
> IP Parcels and Advanced Jumbos facilities cannot be supported out of HBH options alone - they
> also need support from UDP option processing.
>
> What I would like to propose is the following: UDP/IP Parcels and Advanced Jumbos set UDP
> Length to 8 to indicate that no UDP payload octets immediately follow the UDP header but
> rather the UDP surplus area (containing zero or more options) immediately follows the UDP
> header. Then, if an EOL option appears before the end of the surplus area, the remainder of
> the surplus area is interpreted as a Parcel Buffer (format TBA). This would have non-zero
> data following the EOL option and extending to the end of the surplus area. Or, if that
> would not be palatable, define a new 1-octet UDP option such as "PBJ" to have the
> same meaning as EOL but with the difference that a Parcel Buffer and not an all-0's
> block immediately follows.
>
> This would still be done in consultation with the HBH option when the option includes
> an extended payload length field. This would allow for surplus areas that are longer
> than can be expressed in a 16-bit length field. The format of a UDP/IP parcel would
> then be similar to the format of a TCP packet, which begins with an IP header followed
> by TCP/UDP header followed by options followed by protocol data.
>
> Anyway, if this idea is liked then we may need to get some changes into the
> UDP options draft.
>

Fred,

Why not use a Destination Option? Destination options are not allowed
to be ignored by a receiving host, works with any protocol, and are
supported on the Internet and implementations.

Tom

> Thank you for your thoughts,
>
> Fred
>
> > -----Original Message-----
> > From: Templin (US), Fred L <Fred.L.Templin=[e-mail]>
> > Sent: Monday, December 09, 2024 10:39 AM
> > To: Tom Herbert <tom=[e-mail]>; 6man <[e-mail]>
> > Subject: [IPv6]Re: Fwd: New Version Notification for draft-ietf-6man-eh-limits-17.txt
> >
> > Tom, I read the -17 but can't see where it refers to:
> >
> > - Add allowance for a receiving host to ignore HBH options to be
> > consistent with RFC9673
> >
> > Can you point to the draft text this bullet refers to?
> >
> > Thank you - Fred
> >
> >
> > > -----Original Message-----
> > > From: Tom Herbert <tom=[e-mail]>
> > > Sent: Friday, December 06, 2024 2:03 PM
> > > To: 6man <[e-mail]>
> > > Subject: [IPv6]Fwd: New Version Notification for draft-ietf-6man-eh-limits-17.txt
> > >
> > > Hello,
> > >
> > > I have posted -17 of the eh-limits drafts. This addresses comments
> > > from the TSVART, SECDIR, and ARTART reviews.
> > >
> > > Changes include:
> > > - Replace "specification" with "document"
> > > - Remove some unnecessary supporting text
> > > - Add a reference to RFC9000, QUIC's limit on extension headers
> > > - Refer to RFC9673 instead of the I-D
> > > - Add appendix describing rationale on limiting EH number and ordering
> > > - Add allowance for a receiving host to ignore HBH options to be
> > > consistent with RFC9673
> > > - Change "SHOULD drop" to "MUST drop" if a host doesn't process all
> > > Destination Options of EHs. Similarly, for intermediate nodes for
> > > DestOpts before the Routing Header and EHs through the Routing Header
> > > - Add a description of the changes to RFC8504 requirements on hosts and EHs
> > > - Add reference to RFC9098 when discussing routers that need to process L4
> > > - Remove reiteration of requirements in the appendix
> > > - Added appendix action about limits on extension header ordering and
> > > number of occurrences
> > >
> > > Thanks, Tom
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: <[e-mail]>
> > > Date: Fri, Dec 6, 2024 at 1:50 PM
> > > Subject: New Version Notification for draft-ietf-6man-eh-limits-17.txt
> > > To: Tom Herbert <[e-mail]>
> > >
> > >
> > > A new version of Internet-Draft draft-ietf-6man-eh-limits-17.txt has been
> > > successfully submitted by Tom Herbert and posted to the
> > > IETF repository.
> > >
> > > Name:     draft-ietf-6man-eh-limits
> > > Revision: 17
> > > Title:    Limits on Sending and Processing IPv6 Extension Headers
> > > Date:     2024-12-06
> > > Group:    6man
> > > Pages:    19
> > > URL:      https://www.ietf.org/archive/id/draft-ietf-6man-eh-limits-17.txt
> > > Status:   https://datatracker.ietf.org/doc/draft-ietf-6man-eh-limits/
> > > HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-limits
> > > Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-eh-limits-17
> > >
> > > Abstract:
> > >
> > >    This document defines various limits that may be applied to
> > >    receiving, sending, and otherwise processing packets that contain
> > >    IPv6 extension headers.  Limits are pragmatic to facilitate
> > >    interoperability amongst hosts and routers, thereby increasing the
> > >    deployability of extension headers.  The limits described herein
> > >    establish the minimum baseline of support for use of extension
> > >    headers on the Internet.  If it is known that all communicating
> > >    parties for a particular communication, including destination hosts
> > >    and any routers in the path, are capable of supporting more than the
> > >    baseline then these default limits may be freely exceeded.
> > >
> > >
> > >
> > > The IETF Secretariat
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > --------------------------------------------------------------------