5

I'm experimenting with an IPv6 route that involves a 6rd (6-over-4) router, and I notice that when I use a packet size that is small enough to fit in the segments of the route that run native IPv6 over Ethernet, but large enough to not fit in the segments of the route where IPv6 is encapsulated in IPv4 (that is, somewhere between 1481 and 1500 bytes), the packet (understandably enough) doesn't make it through the route unless it is fragmented. The responding host will start fragmenting its replies once it has received a packet-too-big error from the 6rd router on its side of the route, and then keep doing so for some time.

Since ICMPv6 is stateless, though, this implies to me that Linux has a table somewhere in which it saves the MTU value from the packet-too-big message for the target host for a while. Is this correct? And if it is, can I view this table somehow? I've been looking through the various subcommands of the ip command, but I can't find anything like it. Is this table used for protocols like UDP, or is it something dedicated for ICMPv6?

Improve this question
5
  • Check the IPv6 standard. Packet fragmentation is NOT allowed. Your 6-to-4 router handles the repacking. Commented Dec 16, 2021 at 0:34
  • Since MTU (Maximum Transmission Unit) is a characteristic of the Network, it's only settable on a Network Interface Card basis. Commented Dec 16, 2021 at 0:37
  • @waltinator: Check RFC8200 (the latest revision of the IPv6 spec). Section 4.5 describes fragmentation, and how it is explicitly handled by source nodes rather than routers. Commented Dec 16, 2021 at 0:41
  • @waltinator: Just in case I wasn't clear enough about that in the question, the fragmentation does, in fact, happen, and it happens at the discovered path MTU, rather than the local link's MTU. What I'm asking about is how the kernel knows what the path MTU is, even outside of stateful protocols like TCP, not whether it happens (because that is a known fact). Commented Dec 16, 2021 at 0:52
  • Path mtu discovery can be done. The third item here shows available options. There is also this question which has a command, but the OP says that the command does not work. Also, for TCP, I think it is stored in TCP data structure (well, it stores MSS, not MTU). Commented Dec 16, 2021 at 9:40

2 Answers 2

Reset to default
4

Linux caches MTUs for remote destinations it learns through Path MTU Discovery (RFC 1191), when the discovered MTU is lower than the MTU on the interface that destination is reachable via.

To view the cache you can use "ip route show cache", for example:

me@server:~$ ip -6 route show cache 
1234:8108:1111:111:1111:1111:ff38:57be via fe80::8243:abcd:4216:a4c0 dev eno12399np0 metric 1024 expires 35sec mtu 1280 hoplimit 64 pref medium

me@server:~$ ip route show cache
1.2.3.4 via 192.0.2.1 dev eno12399np0 
    cache expires 154sec mtu 1420
Improve this answer
0

In Linux (and I believe, elsewhere) the MTU is configured for each interface, not for each remote host. Please check by running

ip a

which will show you MTU numbers for each interface:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp6s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 10.0.42.23/24 brd 10.0.42.255 scope global enp8s0
       valid_lft forever preferred_lft forever

In my case lo has a MTU of 65536 bytes, enp6s1 has 1500 bytes.

Improve this answer
5
  • I know that each interface has a MTU setting which is used for packets sent on that interface, but that doesn't help explain how the kernel knows to fragment an echo reply to a specific host at a MTU that has been reported for the route to that host. Commented Dec 16, 2021 at 0:26
  • @Dolda2000 Can you confirm that you have different MTUs on the same interface at the same time, dependent on the target? Commented Dec 16, 2021 at 13:30
  • 2
    Yes, that's the whole point. When responding the echo requests, the system will only fragment packets for the address for which the packet-too-big error was previously received, not for other addresses. Commented Dec 20, 2021 at 1:39
  • Could it be that the MSS (maximum segment size) is adjusted but not the MTU? You sometimes need adjust that in the routing table (e.g. ip route add 10.42.42.0/24 via 10.11.12.1 advmss 1300) to fix certain problems. Commented Dec 22, 2021 at 23:18
  • As far as I'm aware, MSS is strictly a TCP concept, so I don't think it would apply for ICMP. Either way, I don't think that explains where or how to inspect these values, since it's not inserted into the routing table. Commented Dec 23, 2021 at 0:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.