From owner-freebsd-net@FreeBSD.ORG Thu May 9 09:13:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0449703 for ; Thu, 9 May 2013 09:13:14 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 17FDAA9F for ; Thu, 9 May 2013 09:13:13 +0000 (UTC) Received: (qmail 39309 invoked from network); 9 May 2013 09:06:31 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 May 2013 09:06:31 -0000 Date: Thu, 09 May 2013 11:06:31 +0200 (CEST) Message-Id: <20130509.110631.74720486.sthaug@nethelp.no> To: jason@b0rken.org Subject: Re: IPv6 tunnel MTU of 1480 not effective From: sthaug@nethelp.no In-Reply-To: <518B5F51.8020804@b0rken.org> References: <518B5F51.8020804@b0rken.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 09:13:14 -0000 > However I'm only able to send IPv6 packets from my host that fit an MTU > of 1280 even though I've set the tunnel interface and per-route MTU to > 1480, based on the "outer" ethernet connection having an MTU of 1500. > Hurricane Electric supports this and I've set the MTU to 1480 on their > side as well. > > This issue is evident when I try to send IPv6 pings larger than 1280 > bytes to the remote tunnel peer. The outgoing echo request is chopped > into two fragments, while the response comes back in one fragment, as > follows: > > % ping6 -c 1 -s 1432 2001:470:1f08:84f::1 > PING6(1480=40+8+1432 bytes) 2001:470:1f09:84f::2 --> 2001:470:1f08:84f::1 > 1440 bytes from 2001:470:1f08:84f::1, icmp_seq=0 hlim=64 time=1.514 ms 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, sthaug@nethelp.no