IPv6 inflight fragmentation

[PMc]

What I read in some documents, fragmentation of IPv6 packets on an intermediate router should not happen or cannot happen or does not work (or whatver?).

Fact is, it definitely can happen, because FreeBSD does it. Only these packets then seem not to get answered from destination.

This is the router:

vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500                                                                      
tun0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1492

Intranet is ethernet, extranet is PPPoE, so MTU must change.

And this is the IPv6 inflight fragmentation:
Incoming on vtnet0:

IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222.20487 > 2a00:1450:4001:67::8.443: Flags [.], seq 0:1428, ack 1, win 1035, options [nop,nop,TS val 2061109754 ecr 739209924], length 1428                                                   
IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222.20487 > 2a00:1450:4001:67::8.443: Flags [.], seq 0:1428, ack 1, win 1035, options [nop,nop,TS val 2061113154 ecr 739209924], length 1428

Outgoing on tun0:

IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (0|1440) 59241 > 443: Flags [.], seq 0:1408, ack 1, win 1035, options [nop,nop,TS val 2312762048 ecr 739149759], length 1408                                 
IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (1440|20)
IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (0|1440) 59243 > 443: Flags [.], seq 1:1409, ack 1, win 1035, options [nop,nop,TS val 3069543472 ecr 739199972], length 1408
IP6 2003:e7:1740:a7e0:41d:92ff:fe01:222 > 2a00:1450:4001:67::8: frag (1440|20)

It seems this happens only when there is a dummynet pipe/queue (or a divert) in the outgoing rules. If there is no such thing present, then ICMPv6 type-2 messages ("packet too big") are sent back to the origin.

 

[ct85711]

From my understanding, the nodes are supposed to inform each other on what size is allowed without fragmenting. The catch being, there is nothing saying if anyone actually listens to it (or bothers to let anyone else know of the packet size). Then to muddy it even worse, you still have the control flag of do not fragment the packets and also have the jumbo packets to throw into the mix(not everything accepts jumbo packets). Then you have the issue of who will split the packet into fragments or if they just drop the packet all together.

 

[PMc]

From my understanding, the nodes are supposed to inform each other on what size is allowed without fragmenting. The catch being, there is nothing saying if anyone actually listens to it (or bothers to let anyone else know of the packet size). Then to muddy it even worse, you still have the control flag of do not fragment the packets and also have the jumbo packets to throw into the mix(not everything accepts jumbo packets). Then you have the issue of who will split the packet into fragments or if they just drop the packet all together.

I see. Well then, IF the "packet too big" gets sent back, then everything works well. So it seems only dummynet does not implement it correctly. (And divert ist known to lack some ipv6 support, anyway.)

 

[ct85711]

It isn't a case of, the packet is being sent back. Looking at a blog, it looks like packets that are too large are intended to be straight out dropped; and a ICMP PTB (Packet Too Big) message is suppose to be sent back. The reasoning, is that it seems IPv6 packets is intended to have the Do Not Fragment flag stuck on at all times. As with IPv4, ICMP is frequently are killed by firewalls, and doesn't help IPv6 uses ICMP more heavily (and is still a popular attack vector for script kiddies and hackers).

https://blog.apnic.net/2016/05/19/fragmenting-ipv6/
https://labs.ripe.net/author/gih/evaluating-ipv4-and-ipv6-packet-fragmentation/