Details

Reviewers

kp
jtl
glebius
tuexen
bz

Group Reviewers

transport

Commits

rG069a67374ed9: ip6: Remove support for RFC2675 (Jumbo Payload Option)

Summary

Remove support for RFC2675, the jumbo payload option. This option was intended
to allow deployment of greater than 65k packet sizes, but it has seen very
little deployment. Speaking to one of the authors the original deployments of
the jumbo payload option no longer exist. There are no known devices that can
carry jumbo payloads.

This is a first pass at removing jumbo, there may be more digging to remove all
of its roots.

Test Plan

Because valid traffic requires packet sizes greater than IP6_MAXPACKET I am
unsure how to write test cases for this.

I have run iperf tests with v6 traffic to confirm that nothing else breaks.

Diff Detail

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 23748
Build 22706: arc lint + arc unit

Event Timeline

thj created this revision.Apr 18 2019, 5:05 PM

Herald added a subscriber: ae. · View Herald TranscriptApr 18 2019, 5:05 PM

Harbormaster completed remote builds in B23748: Diff 56357.Apr 18 2019, 5:05 PM

Diff against correct tree

Harbormaster completed remote builds in B23749: Diff 56359.Apr 18 2019, 5:13 PM

I'l resign as a reviewer from this as removing valid RFC support seems counter-intuitive to me just because currently to your best knowledge no device supporting it exists. Someone should write the draft first to deprecate this and see if people stand up and then remove it.

Looking at the code changes seems to make it hide under "burn bridges" or something harder. So I guess if someone wants to resurrect it it'll be in the Attic.

Burn it with fire! This code is not used, and pretty much can't be used, so let's get rid of it.

Many years ago I got confused by this code. Let's save others from that.

I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)

Might a valid way forward be to write a draft, propose it, and see if anyone complains by the next IETF (July) before purging this?

In D19960#429003, @kristof wrote:

Burn it with fire! This code is not used, and pretty much can't be used, so let's get rid of it.

It could be used. I know hardware which could do 1-4 MB at least. It's research and not deployed...

In D19960#429029, @jtl wrote:

I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)

Might a valid way forward be to write a draft, propose it, and see if anyone complains by the next IETF (July) before purging this?

I will happily co-author it though I still believe large packets will be a thing one day ...

In D19960#429029, @jtl wrote:

I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)

Might a valid way forward be to write a draft, propose it, and see if anyone complains by the next IETF (July) before purging this?

Maybe a very short ID to move RFC 2675 to historic... See RFC7805 for a ,much more complex example of such a document.

In D19960#429033, @tuexen wrote:

Maybe a very short ID to move RFC 2675 to historic... See RFC7805 for a ,much more complex example of such a document.

https://tools.ietf.org/html/rfc5095 << good example

That said, there are vendors who list it (maybe not on the forwarding plane) but as RFC compliance supporting it:
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/ipv6.html

In D19960#429052, @bz wrote:

That said, there are vendors who list it (maybe not on the forwarding plane) but as RFC compliance supporting it:
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/ipv6.html

As you hint at, I'm fairly certain that Juniper lists that because of control plane support, and not because they have production hardware that will actually support that on the forwarding plane. However, someone at Juniper might be able to comment more definitively.

I am okay with Jonathan's suggested plan.

We sit on this and write a short draft to move rfc2675 to historic. We get a feel from the ietf (I suggest 6MAN) and act based on that.

@bz I will do a first draft of an ID and circulate.

Looking at https://www.rfc-editor.org/status_changes.php I think an Information document can update that status of a PS. Is that correct @tuexen ?

We wrote an ID:

https://tools.ietf.org/html/draft-jones-6man-historic-rfc2675-00

discussion may appear on this thread:

https://mailarchive.ietf.org/arch/msg/ipv6/FhaFsm9DSMkUfpDbQTPh-RbYybM

So, reading the comments on the 6man WG, it appears that noone has big concerns around making RFC2675 historic?

Will you follow up with the formal process of getting the draft adopted as WG item, and eventually dragged over WGLC?

Can you rebase it?

Herald added subscribers: glebius, melifaro. · View Herald TranscriptJan 21 2026, 11:06 AM

Sure, I've put it on my todo list

emaste added a subscriber: emaste.Jan 22 2026, 2:03 PM

Rebase (well manually port) changes up to CURRENT from 7 years ago.

If doing this I see that we use IPV6_MAXPACKET, but it isn't super clear if
this actually means the maximum packet size (65,575), or the maximum payload
size (65,535).

I don't think there are any links with an mtu to carry 65,575, but if there
ever are I would expect to find some bugs.

Herald added a subscriber: imp. · View Herald TranscriptJan 23 2026, 12:48 PM

Harbormaster completed remote builds in B70070: Diff 170265.Jan 23 2026, 12:48 PM

In D19960#1253517, @thj wrote:

I don't think there are any links with an mtu to carry 65,575, but if there
ever are I would expect to find some bugs.

We could teach if_epair that trick, but my view is still that we should not invest any time in supporting Jumbograms (or even the 'just over 2^16' case) until we have actual users who care. The best way to find those is to take the support out and wait for the complaints. If there are none we know no one uses it.