Page MenuHomeFreeBSD

Remove support for RFC2675
Needs ReviewPublic

Authored by thj on Apr 18 2019, 5:05 PM.

Details

Reviewers
kristof
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 OK
Unit
No Unit Test Coverage
Build Status
Buildable 23749
Build 22707: arc lint + arc unit

Event Timeline

thj created this revision.Apr 18 2019, 5:05 PM
thj updated this revision to Diff 56359.Apr 18 2019, 5:13 PM

Diff against correct tree

bz resigned from this revision.Apr 18 2019, 5:18 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.

jtl added a subscriber: bz.Apr 18 2019, 7:48 PM

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?

bz added a comment.Apr 18 2019, 8:16 PM

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

bz added a comment.Apr 18 2019, 8:17 PM
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 ...

tuexen added a subscriber: tuexen.Apr 18 2019, 8:21 PM
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.

bz added a comment.Apr 18 2019, 9:37 PM

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

bz added a comment.Apr 18 2019, 9:40 PM

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

jtl added a comment.Apr 18 2019, 10:30 PM
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.

thj added a comment.Apr 19 2019, 6:56 AM

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 ?