specifying min_ipv6_mtu by module parameter

[tadokoro]

specifying min_ipv6_mtu by module parameter

[ydahhrk]

Not saying that we're planning to oppose resistance to this patch, but could you please tell us why do you need it?
From what I can tell, the default minimum IPv6 MTU (1280) should work on all situations because IPv6 demands nodes to support at least that.
(It doesn't work at the moment because Jool doesn't let other nodes know the MTU (in Packet too Big ICMP errors) because of issue #79.)
Increasing the minimum IPv6 MTU should do nothing aside from increasing performance (as far as I know), and once issue #81 has been fixed, it will always be editable from the userspace application, so making it one of the modprobe parameters feels a little excessive.

Still, it would be great to hear your opinion.
Thanks

[tadokoro]

Because I came across the funny site which is accessable with MTU 1500 but not with 1280 (this might be the result of #79), I wanted to set the MTU 1500.
However, setting the MTU 1500 automatically on boot with the userspace application seems to need extra settings.
I thought it was easy to use parameter.

I think what you say is exactly right, and I agree with you.
Thank you (^^)!

[ydahhrk]

The problem you're describing is odd; I'm not sure if it will be fixed along with #79.
I don't seem to be allowed to reopen this issue, but could you please tell us the site you're having problems with? I'd like to monitor it and see if we have more work to do.

[tadokoro]

I am very grateful to your response.

In my deep research with tcpdump, I found that this may happend at any site.
I experimented under the following environment, and tcpdumped in the client, nat64, router, and the server.

client <-> nat64 <-> router <-> ... <-> http server

I found whenever client gets /, the http server responds with 1500 bytes packets,
then nat64 drops them via "Packet is too big" path in translate_packet.c because 1500 is bigger than MTU 1280.
However, jool cannot send fragmentation needed error due to #79.
So http server sends packets again and again and the nat64 drops them again and again, and finally the server gives up.

I have found the two ways to avoid this problem.
One is to execute "jool -z --minMTU6=1500" in the nat64.
The other is to execute "ip link set dev eth0 mtu 1280" in the client.

If my thought is mistaken, could you please tell me some hints?
Or, is there anything that needs to be more examined?

[ydahhrk]

You are not mistaken; my fears of this being a sign of another bug were unfounded.
This should indeed be fixed along with #79.

[ydahhrk]

This is still being investigated in the form of issue #89.