Remove support for RFC2675

[thj]

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.

[thj]

Diff against correct tree

[bz]

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.

[kp]

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]

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]

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

[bz]

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]

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]

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

[bz]

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]

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]

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 ?

[thj]

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

[rscheff]

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?

[bz]

Can you rebase it?

[thj]

Sure, I've put it on my todo list

[thj]

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.

[kp]

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.

sys/netinet6/udp6_usrreq.c

874

m_freem(NULL) is safe, so we could lose the if here.

914–915

Should we MPASS(plen <= IPV6_MAXPAYLOAD) here?

[glebius]

sys/netinet/ip6.h

260–270

Does it make sense to remove reference to Jumbo in the comment?

sys/netinet6/ip6_input.c

772

Let's use uint32_t in the new code.

[thj]

• address review comments