RE: Transmission of IPv6 Jumbograms as Atomic Fragments

Bob, what I want is exactly the Identification field that is found in the Fragment Header
while simply leaving the rest of the fields of that header set to 0 - there is no cause for
defining a new IPv6 extension header. And, a quick scan of my draft shows how very
minor the updates to RFC2675 really are.

Again, jumbos are part of the architecture (which you helped establish!) and allowing IPv6
packets of all varieties to include an Identification (jumbos included) is how we move the
architecture into the future.

Thanks - Fred

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Wednesday, November 17, 2021 4:41 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments
> 
> Fred,
> 
> > On Nov 17, 2021, at 3:39 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Let me add a bit more clarity, then. IPv6 made a bit of a mistake when it presumed that the
> > only reason a packet might need an Identification value was to support the fragmentation
> > and reassembly process.
> 
> If what you want is some sort of identification field, it would be easier for you to propose an extension header that does that and see if you
> can build a consensus around that.
> 
> In my view, trying to do that by modifying IPv6 Jumbograms (that I don’t know of anyone uses these days) to include a fragment header,
> makes little sense to me.
> 
> Bob
> 
> 
> 
> > Hence, the Identification was strictly tied to the Fragment Header.
> > But, it turns out there are other reasons to include an unpredictable ID with an IPv6 packet
> > (jumbos included) that have nothing to do with fragmentation. Since the only way to get
> > an Identification in IPv6-land is to include a Fragment Header, then that is just what we are
> > going to have to do. – again, jumbos included.
> >
> > Thanks - Fred
> >
> > From: David Farmer [mailto:farmer@umn.edu]
> > Sent: Wednesday, November 17, 2021 3:27 PM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Cc: 6man <ipv6@ietf.org>; Brian E Carpenter <brian.e.carpenter@gmail.com>
> > Subject: Re: [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic Fragments
> >
> > While I see no reason to depreciate RFC2675, without evidence of actual active use of jumbograms or at least an intent to use them, but
> for the issue you describe prevents it, I see no reason to advance the update you propose.
> >
> > Even in the R&E networking community where we make regular use of data grams larger than 1500 bytes, I’m not aware of the use of, or
> even a desire to use, jumbograms.
> >
> > Thanks
> >
> > On Wed, Nov 17, 2021 at 16:45 Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > Brian, I came through the supercomputer lab at NASA Ames in Mt View CA in 1996/7
> > where HiPPI was heavily used. I didn't spend much time there, but enough to get a
> > rough read that large packets are plausible.
> >
> > At some time not long after that, I had the good fortune to meet Dave Borman and
> > asked him about RFC2675 with a "YMBK" pre-disposition toward the concept. Dave
> > assured me that the document was serious, and I do not see evidence that it has
> > been deprecated.
> >
> > So, do I know of any such mega-links? Not offhand, but AFAICT RFC2675 is still part
> > of the IPv6 architecture and needs to be honored as such.
> >
> > Thanks - Fred
> >
> > > -----Original Message-----
> > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > > Sent: Wednesday, November 17, 2021 1:39 PM
> > > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; 6man <ipv6@ietf.org>
> > > Subject: [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic Fragments
> > >
> > > EXT email: be mindful of links/attachments.
> > >
> > >
> > >
> > > Fred,
> > >
> > > Is there any evidence of usage of jumbograms? To my knowledge, even the high energy phsyics community, one of the main proponents
> of
> > > jumbograms back in the days when HIPPI seemed important, doesn't use them, despite extensive use of IPv6 for bulk data.
> > >
> > > Regards
> > >     Brian
> > >
> > > On 18-Nov-21 06:54, Templin (US), Fred L wrote:
> > > > Here is a new draft that may be of interest. It is a quick read (~2pgs) and proposes to
> > > > update RFC2675 by permitting transmission of IPv6 jumbograms as atomic fragments.
> > > >
> > > > Please post comments to the list.
> > > >
> > > > Fred
> > > >
> > > > -----Original Message-----
> > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> > > > Sent: Wednesday, November 17, 2021 9:09 AM
> > > > To: i-d-announce@ietf.org
> > > > Subject: I-D Action: draft-templin-6man-jumbofrag-00.txt
> > > >
> > > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > >
> > > >
> > > >          Title           : Transmission of IPv6 Jumbograms as Atomic Fragments
> > > >          Author          : Fred L. Templin
> > > >     Filename        : draft-templin-6man-jumbofrag-00.txt
> > > >     Pages           : 4
> > > >     Date            : 2021-11-17
> > > >
> > > > Abstract:
> > > >     Internet Protocol, Version 6 (IPv6) provides a service for
> > > >     transmission of IPv6 packets larger than 65,535 octets known as
> > > >     "jumbograms".  Such large packets are not eligible for fragmentation,
> > > >     and the current specification forbids the inclusion of a fragment
> > > >     header of any kind.  However, some implementations may wish to
> > > >     include an Identification value with each jumbogram; hence this
> > > >     document proposes the transmission of IPv6 jumbograms as "atomic
> > > >     fragments".
> > > >
> > > >
> > > > The IETF datatracker status page for this draft is:
> > > > https://datatracker.ietf.org/doc/draft-templin-6man-jumbofrag/
> > > >
> > > > There is also an htmlized version available at:
> > > > https://datatracker.ietf.org/doc/html/draft-templin-6man-jumbofrag-00
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > >
> > > > _______________________________________________
> > > > I-D-Announce mailing list
> > > > I-D-Announce@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > Internet-Draft directories: http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > --
> > ===============================================
> > David Farmer               Email:farmer@umn.edu
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE        Phone: 612-626-0815
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------