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

[Ole Troan <[e-mail]>]

>>> 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.

I don't think these are conflicting goals.
You can remove Jumbo support from implementations, while still leaving RFC2675 as is.

If and when Jumbos see usage, your guess is as good as mine if those implementations would need the transport layers as we know them, and certainly if they would reuse the implementations in common OSs.

Best regards,
Ole