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

[Brian E Carpenter <[e-mail]>]

On 09-May-19 18:29, Tom Jones wrote:
> On Wed, May 08, 2019 at 06:07:51PM +0200, Ole Troan wrote:
>>> Hello 6man,
>>>
>>> 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.
>> Or is that the problem you are trying to solve, that a TCP implementation must handle datagrams larger than 64K?
>> Is there any other solution?
> 
> I came to this from as an operating system maintainer, removing
> Jumbograms is a one time ~350 line diff and it saves us maintaining
> complexity in our v6 stack. 
> 
> Preparing this draft it is clear to me that Jumbograms are being carried
> forward in the RFC series 'just because'.

Yes, just because the original motivation still remains potentially valid.

But since the RFC itself states that support is optional, and only applies where there is a physical interface capable of supporting in, each stack maintainer may freely choose whether to support it.

> Most of the time they are an
> off hand mention, in some cases there are changes to protocol formats to
> handle the protocol. 

I'd have thought there was also work in not supporting it, too, to send the required ICMP errors in reply to a Jumbo Payload option or IPv6 Payload Length == 0. Even if we obsoleted the option, that would remain necessary.
 
> This seems like a lot of work for a protocol with no known deployments
> on the Internet.

There is less work involved in leaving the RFC alone than in obsoleting it.

   Brian