Re: [[e-mail]: New Version Notification for draft-jones-6man-historic-rfc2675-00.txt]

[Tom Jones <[e-mail]>]

On Wed, May 08, 2019 at 09:34:36PM +0400, Loganaden Velvindron wrote:
> Comment in-line.
> 
> On Wed, May 8, 2019 at 9:08 PM 神明達哉 <[e-mail]> wrote:
> >
> > At Wed, 8 May 2019 18:07:51 +0200,
> > Ole Troan <[e-mail]> wrote:
> >
> > > > We have put this together to change the status of RFC2675 to Historic
> > > > and would like to request discussion in the working group.
> > >
> > > IPv6 jumbograms was intended for some super computer inter connect with a massive MTU.
> > > I don't know of any use of it, but is it harmful if the specification is left there in place?
> > >
> > > I don't expect any implementation supporting it unless they also support data-link layers with an MTU > 64K.
> >
> > FWIW, (most if not all) BSD variants have been supporting jumbograms
> > for many years (admittedly I don't know if it's still working as
> 
> Indeed, according to this
> https://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html#ipv6-jumbo
> 
> You need to re-compile the kernel to get support for it. So it's not
> shipped by default.
> 
> I think that it's worth mentioning it that in the draft.
> 

Ah, I will raise my hand and admit I hadn't seen large MTU support in
FreeBSDs loopback interface.

I have a diff for FreeBSD that removes Jumbogram support:
https://reviews.freebsd.org/D19960

As far as I can tell Jumbogram support is always built into the kernel,
interface support is probably not. 

I think more telling is the text at the bottom of that section:

	"TCP/UDP over jumbogram is not supported at this moment. This is because
	we have no medium (other than loopback) to test this. Contact us if you
	need this.

	IPsec does not work on jumbograms. This is due to some specification
	twists in supporting AH with jumbograms (AH header size influences
	payload length, and this makes it real hard to authenticate inbound
	packet with jumbo payload option as well as AH).

	There are fundamental issues in *BSD support for jumbograms. We would
	like to address those, but we need more time to finalize these. To name
	a few:

	mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it will not hold
	jumbogram with len > 2G on 32bit architecture CPUs. If we would like to
	support jumbogram properly, the field must be expanded to hold 4G + IPv6
	header + link-layer header. Therefore, it must be expanded to at least
	int64_t (u_int32_t is NOT enough).

	We mistakingly use "int" to hold packet length in many places. We need
	to convert them into larger integral type. It needs a great care, as we
	may experience overflow during packet length computation.

	We mistakingly check for ip6_plen field of IPv6 header for packet
	payload length in various places. We should be checking mbuf pkthdr.len
	instead. ip6_input() will perform sanity check on jumbo payload option
	on input, and we can safely use mbuf pkthdr.len afterwards.

	TCP code needs a careful update in bunch of places, of course."

I am not sure how accurate these comments still are. It is not a great
story for Jumbogram support. If we cannot do TCP, UDP or IPSEC there is
a lot of work to do to make support more than a tick in a box.

- Tom