IPv6 pings being fragmented for unknown reason

My hosted FreeBSD server is configured to use an IPv6 tunnel provided by Hurricane Electric. The tunnel interface is set up as follows:
Code:
gif0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu [red]1480[/red]
        tunnel inet 31.193.132.199 --> 216.66.80.26
        inet6 fe80::be30:5bff:feda:b396%gif0 prefixlen 64 scopeid 0x6 
        inet6 2001:470:1f08:84f::2 --> 2001:470:1f08:84f::1 prefixlen 128 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        options=1<ACCEPT_REV_ETHIP_VER>
The MTU of the outer IPv4 connection is 1500, so this tunnel interface's MTU of 1480 should be fine. However, when I attempt to ping6(8) the peer at the other end of the tunnel with a ping packet that should be exactly 1480 bytes in length, the outgoing request is chopped into two fragments:
Code:
# ping6 -c 1 -s 1432 2001:470:1f08:84f::1
PING6([red]1480[/red]=40+8+1432 bytes) 2001:470:1f08:84f::2 --> 2001:470:1f08:84f::1
1440 bytes from 2001:470:1f08:84f::1, icmp_seq=0 hlim=64 time=1.491 ms

--- 2001:470:1f08:84f::1 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.491/1.491/1.491/0.000 ms
Code:
(tcpdump output)
13:37:09.892415 IP6 2001:470:1f08:84f::2 > 2001:470:1f08:84f::1: frag (0|1232) ICMP6, echo request, seq 0, length 1232
13:37:09.892424 IP6 2001:470:1f08:84f::2 > 2001:470:1f08:84f::1: frag (1232|208)
13:37:09.893870 IP6 2001:470:1f08:84f::1 > 2001:470:1f08:84f::2: ICMP6, echo reply, seq 0, length 1440

Does anyone know the reason for this?

T.I.A.
 
My MTU is set to 1280. Something I never changed myself. And looking at the point your packets are broken up on 1280 seems more appropriate.

Code:
dice@maelcum:~> ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 62.195.66.250 --> 216.66.84.46
        inet6 fe80::216:aff:fe04:b9fe%gif0 prefixlen 64 scopeid 0x9
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        options=1<ACCEPT_REV_ETHIP_VER>
 
Further investigation suggests that this issue is due to a per-route MTU, which overrides the interface MTU:

Code:
# route -n get -inet6 default                                                                                             
   route to: ::
destination: ::
       mask: default
    gateway: 2001:470:1f08:84f::1
  interface: gif0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1280         1         0

I can't seem to work out how to modify this route MTU.
 
An MTU of 1280 is the minimum in IPv6, but if the link can carry more then it should be possible to configure it that way. It's configured to 1480 at the he.net end and the ping reply is coming back in one piece.
 
I've configured my gif0 interface to be created with an MTU of 1480, and corresponding IPv6 routes are also created with a per-route MTU of 1480, but outgoing ping requests are still being chopped into two pieces, as if the MTU was 1280. Replies are still coming back in one piece.

Code:
% ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu [red]1480[/red]
        tunnel inet 31.193.132.199 --> 216.66.80.26
        inet6 fe80::be30:5bff:feda:b396%gif0 prefixlen 64 scopeid 0x6 
        inet6 2001:470:1f09:84f::1fc1:84c7 prefixlen 64 
        inet6 2001:470:1f09:84f::5e4c:dad4 prefixlen 64 
        inet6 2001:470:1f09:84f::5e4c:dad5 prefixlen 64 
        inet6 2001:470:1f08:84f::2 --> 2001:470:1f08:84f::1 prefixlen 128 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        options=1<ACCEPT_REV_ETHIP_VER>

% route -n get -inet6 default                                                                                     
   route to: ::
destination: ::
       mask: default
    gateway: 2001:470:1f08:84f::1
  interface: gif0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      [red]1480[/red]         1         0

Code:
15:37:19.359413 IP6 2001:470:1f08:84f::2 > 2001:470:1f08:84f::1: frag (0|1232) ICMP6, echo request, seq 8, length 1232
15:37:19.359430 IP6 2001:470:1f08:84f::2 > 2001:470:1f08:84f::1: frag (1232|208)
15:37:19.360832 IP6 2001:470:1f08:84f::1 > 2001:470:1f08:84f::2: ICMP6, echo reply, seq 8, length 1440

I'm wondering if this might be a bug.
 
A post to the freebsd-net mailing list got me my answer:

This is a "feature" (i.e. it's documented). See the ping6 -m option:

-m By default, ping6 asks the kernel to fragment packets to fit into
the minimum IPv6 MTU. The -m option will suppress the behavior
in the following two levels: when the option is specified once,
the behavior will be disabled for unicast packets. When the
option is more than once, it will be disabled for both unicast
and multicast packets.

In my opinion this behavior badly breaks POLA, and should be removed
(i.e. the current -m behavior should be the default).

I have no great hope in getting this changed, though...

Steinar Haug, Nethelp consulting
 
Back
Top