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

["Templin (US), Fred L" <[e-mail]>]

Tom, I refactored while adopting the Destination Option – please take another look.
In the new draft, the Parcel Payload Destination Option shares the same option code
as the Parcel Payload HBH Option that I already have. The draft now places only HBH
information in the HBH option and places only E2E information in the Destination option.

What is nice about this approach is the Destination option can be used without the
HBH option allowing parcels and AJs to travel over existing Internetworking pathways.
But, the HBH option can be included in conjunction with the Destination Option over
paths that recognize it to engage the new link model the document describes.

Thank you - Fred

From: Templin (US), Fred L <Fred.L.Templin=[e-mail]>
Sent: Tuesday, December 10, 2024 3:13 PM
To: Tom Herbert <tom=[e-mail]>
Cc: 6man <[e-mail]>
Subject: [IPv6]Re: Fwd: New Version Notification for draft-ietf-6man-eh-limits-17.txt

Hi Tom,

>> I would view eight bytes as inconsequential cost for the benefits of using a protocol mechanism that is defined in an Internet Standard and has >> deployment. You could always define alternative methods and see which one wins.

This seems like sound advice – thank you.

Fred


From: Tom Herbert <tom=[e-mail]<mailto:tom=[e-mail]>>
Sent: Tuesday, December 10, 2024 2:28 PM
To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>
Subject: Re: [IPv6]Re: Fwd: New Version Notification for draft-ietf-6man-eh-limits-17.txt


On Tue, Dec 10, 2024, 4:43 PM Templin (US), Fred L <Fred.L.Templin=[e-mail]<mailto:[e-mail]>> wrote:
Hi Tom,

> -----Original Message-----
> From: Tom Herbert <tom=[e-mail]<mailto:[e-mail]>>
> Sent: Tuesday, December 10, 2024 12:10 PM
> To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
> Cc: 6man <[e-mail]<mailto:[e-mail]>>
> Subject: [EXTERNAL] Re: [IPv6]Re: Fwd: New Version Notification for draft-ietf-6man-eh-limits-17.txt
>
> EXT email: be mindful of links/attachments.
>
>
>
> On Tue, Dec 10, 2024 at 11:06 AM Templin (US), Fred L
> <Fred.L.Templin=[e-mail]<mailto:[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.

Sorry, I didn't mean UDP options *instead of* a HBH option; I meant *in addition to*
a HBH option which is still needed in some cases. There would only be a few octets
needed in UDP options whereas a Destination Option starts out at a minimum of 8
octets and goes up in increments of 8 octets from there - a Destination Option would
just seem like a lot of wasted space, and the packaging within the UDP surplus area
would make for a very neat presentation of the parcel buffer that would be less likely
to cause unwanted surprises. TCP option packaging is also in scope, so both UDP and
TCP would have well architected solutions.

Fred,

I would view eight bytes as inconsequential cost for the benefits of using a protocol mechanism that is defined in an Internet Standard and has deployment. You could always define alternative methods and see which one wins.

Tom



Thank you - Fred

>
> Tom
>
> > Thank you for your thoughts,
> >
> > Fred
> >
> > > -----Original Message-----
> > > From: Templin (US), Fred L <Fred.L.Templin=[e-mail]<mailto:[e-mail]>>
> > > Sent: Monday, December 09, 2024 10:39 AM
> > > To: Tom Herbert <tom=[e-mail]<mailto:[e-mail]>>; 6man <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> > > > Sent: Friday, December 06, 2024 2:03 PM
> > > > To: 6man <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> > > > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > > > --------------------------------------------------------------------
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > > --------------------------------------------------------------------