Page MenuHomeFreeBSD

Remove support for RFC2675
Needs ReviewPublic

Authored by thj on Apr 18 2019, 5:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 5:06 AM
Unknown Object (File)
Dec 15 2023, 7:34 AM
Unknown Object (File)
Dec 14 2023, 9:12 PM
Unknown Object (File)
Dec 10 2023, 6:13 PM
Unknown Object (File)
Oct 10 2023, 5:56 PM
Unknown Object (File)
Aug 15 2023, 7:48 AM
Unknown Object (File)
Aug 11 2023, 1:32 PM
Unknown Object (File)
Jun 24 2023, 12:59 AM

Details

Reviewers
kp
jtl
bz
Group Reviewers
transport
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 23749
Build 22707: arc lint + arc unit

Event Timeline

Diff against correct tree

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.

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 ?

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?