Solved where is host-specific mtu/mss stored? (IPv6 related)

When I ping a neighbor system via plain Ethernet (or emulated ng_eiface), I can ping with -6 -u -s 1452 unfragmented, and only with -s 1453 fragmentation appears. (correct: 40 byte IPv6-hdr + 4 byte ICMP hdr + 4 byte ICMP echo req. hdr = 1500)

When I ping a remote system (thru that same neighbor system), I see this instead:
Code:
frag (0|1440) ICMP6, echo request, seq 0, length 1440
frag (1440|13)
Only with -s 1444 does the fragmentation stop. This is also correct, because that remote system goes via PPPoE, and that needs another 8 byte header, so fragmentation must appear 8 byte earlier. But: how can the local system know this??

Fragmentation is done on the sending system itself, as required in IPv6. And ping is ICMP is connectionless, so there cannot be a kind of MSS negotiation or PMTU discovery. Somewhere on the system must be a storage for recently received "fragmentation needed" messages, or something similar. I would like to know this storage (and be able to flush it when needed).

The other point is that fragmented packages do never reach a destination - but that is certainly related to my lots of ipfw and nat/nptv6 and divert instances, and I am going to debug that now. But in order to be successful, I need to fully understand how this works. I don't find a hint in sysctl and no idea where else to look.
 
I don't think the network variables are stored on disk except via /etc/rc.conf.
They are assigned by rc.d scripts at boot. When you run service netif restart the settings are changed.
Now where these variables are stored while booted is a mystery.
Not anywhere in /var/db/ which is where dhcp leases end up.
Not in kenv.
What about env? Nope.
/etc/netstart gives some clues....
If I was abetting man I would say /etc/devd.conf and /etc/rc.d/netif have clues.
It really looks like rc.conf is where the setting is stored.
There must be driver defaults when no MTU is specified.
/etc/defaults/rc.conf contains nothing regarding MTU so it must be in the drivers.
 
But: how can the local system know this??
netstat -i ? Surly it is a more programmatic approach but these variables are available.

sysctl -a | grep mss
Code:
net.inet.tcp.mssdflt: 536
net.inet.tcp.v6mssdflt: 1220
net.inet.tcp.v6pmtud_blackhole_mss: 1220
net.inet.tcp.pmtud_blackhole_mss: 1200
net.inet.tcp.minmss: 216
 
I don't think the network variables are stored on disk except via /etc/rc.conf.
Ah, it's not about these variables. I searched sysctl already, didn't find much useful about mtu discovery there.
If my machine knows that the neighbouring machine has mtu=1500 (that one is obvious, it's the mtu on the interface), but some other machine 5 hops away then has mtu=1492, there must be a table where ip addresses and corresponding mtu values are stored.

One such place is the routing table. It can be used for that, but I didn't find the respective hosts there. In any case it must be a fast storage in memory.

But then also, the thing that is done with such information appears to be fragmentation - and I get more and more into doubt if we want this at all. TCP doesn't need fragmentation, it has MSS negotiation and PMTU discovery and such. And UDP fragmentation can be hacked, as I just read about.
 
I recently turned off ICMP packets at the firewall. I don't need the hassle.
I really suspected something fishy was happening.
Truth is I don't need ping or traceroute that bad.
 
And here it is!
(needed to scroll down quite a lot, but these are very good ressources - thank You!)

Code:
sysctl net.inet.tcp.hostcache.list
net.inet.tcp.hostcache.list:
IP address        MTU  SSTRESH      RTT   RTTVAR     CWND SENDPIPE RECVPIPE HITS  UPD  EXP
2001:470:1f13:11::1:0     0     8405     55ms      7ms    11225        0        0  959   12 3300
# ping -u -s 1460 2001:470:1f13:11::1:0
PING6(1508=40+8+1460 bytes) fd00::4102 --> 2001:470:1f13:11::1:0

07:05:10.377815 IP6 fd00::4102 > 2001:470:1f13:11::1:0: frag (0|1448) ICMP6, echo request, seq 0, length 1448
07:05:10.377836 IP6 fd00::4102 > 2001:470:1f13:11::1:0: frag (1448|20)
07:05:11.394840 IP6 fd00::4102 > 2001:470:1f13:11::1:0: frag (0|1440) ICMP6, echo request, seq 1, length 1440
07:05:11.394868 IP6 fd00::4102 > 2001:470:1f13:11::1:0: frag (1440|28)

# sysctl net.inet.tcp.hostcache.list
net.inet.tcp.hostcache.list:
IP address        MTU  SSTRESH      RTT   RTTVAR     CWND SENDPIPE RECVPIPE HITS  UPD  EXP
2001:470:1f13:11::1:0  1492        0      0ms      0ms        0        0        0    8    1 3600
 
I recently turned off ICMP packets at the firewall. I don't need the hassle.
I really suspected something fishy was happening.
Truth is I don't need ping or traceroute that bad.
Hm, that doesn't look like the right approach to me. The idea in IPv6 is that fragmentation is not needed because there is working ICMP. Without ICMP, IPv6 will not work well. The ping above could not switch from 1448 to 1440. You would not know that you need smaller packets to reach my servers, and your requests would timeout.
The correct approach would be to throw away arriving fragments.
 
Sorry for that unhelpful commentary. I only use IPv4 so I had to cut a leaky protocol.
I have suspect gear on my network that likes to chat with the outside over ICMP.
I removed one piece that is probably infected. AP7901 that acts unlike two others with same firmware and settings.
Unfortunately I buy cheap shit from ebay and you need to really watch that gear.
 
Sorry for that unhelpful commentary. I only use IPv4 so I had to cut a leaky protocol.
Yep, in IPv4 it doesn't matter much. There ICMP was never really reliable, and gets filtered at many places.
IPv6, on the contrary, does everything with ICMP. They don't have arp, they do this with ICMPv6. They don't have inflight fragmentation - they expect that ICMPv6 "packet too big" get through from anywhere and is understood.

I have suspect gear on my network that likes to chat with the outside over ICMP.
I removed one piece that is probably infected. AP7901 that acts unlike two others with same firmware and settings.
No idea. A rack power supply getting infected?

Unfortunately I buy cheap shit from ebay and you need to really watch that gear.
Me too. ;)
 
Back
Top