From owner-freebsd-net@FreeBSD.ORG Sun May 12 07:53:12 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 07AEC2EE for ; Sun, 12 May 2013 07:53:12 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id DC882F3D for ; Sun, 12 May 2013 07:53:11 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5EAC8C9432; Sun, 12 May 2013 07:53:05 +0000 (UTC) (envelope-from jinmei@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368345191; bh=ydLomxmMEkP7/xr87Mxf1NJQ2Ddh7rozc2Cl6yYHjK0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GWzRDDrSfOS+G7dj03PyPGXLmqYNJdEry09WyL3ZEC+89//W3vRZZgypk+cCG1KYx xMgo7iFndWMj2OVKrexOJJgLHtqvTh2KbgOyz6k71jRAOERaFfF0j39btSrtwTokBT ePfl0mVFGBa2BLtzKTaNe87xzKUoIMXcjOG8Sx4c= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Sun, 12 May 2013 07:53:05 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 23031216C40; Sun, 12 May 2013 07:53:05 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Sun, 12 May 2013 00:53:03 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kevin Oberman Subject: Re: IPv6 tunnel MTU of 1480 not effective In-Reply-To: References: <518B5F51.8020804@b0rken.org> <20130509.110631.74720486.sthaug@nethelp.no> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: jason@b0rken.org, sthaug@nethelp.no, 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: Sun, 12 May 2013 07:53:12 -0000 At Sat, 11 May 2013 22:09:49 -0700, Kevin Oberman wrote: > > > 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. [...] > I complained about this at least a couple of years ago and was told by the > developer (I don't recall exactly who any more) that it was right and would > not be changed. I really would love to see this reconsidered before IPv6 > becomes much more popular as it will simply cause confusion, but I, too, > fear that it is a lost cause. What's "this" (to reconsider)? That ping6 fragments outgoing packets at 1280 octets (by default)? Or, more in general whether any outgoing IPv6 packet can initially honor the interface MTU? If it's the former, I personally believe the default behavior makes more sense because IPv6 doesn't have the concept of "don't fragment bit", so any packet/fragment larger than 1280 octets could be dropped at an intermediate router. In theory, we could recover from that situation if that router sent an ICMPv6 packet too big message and the kernel performed path MTU discovery (which in my understanding is not the case for non connected sockets like the one ping6 uses), but even if PTMU discovery worked, some initial echo requests would still be lost. As a user, I wouldn't like to bother to wonder the reason for the packet loss if my main concern is reachability check (that would be my primary purpose for using ping6). The same argument applies to non connected UDP sockets, and, in fact, DNS server implementations behave exactly like ping6 in that sense (fragmenting large DNS responses at 1280 octets), and exactly for that reason. If it's the latter, I thought at least TCP (if not also for other connected sockets) honors the best possible MTU, starting from the MTU of the outgoing interface. If it doesn't, I agree with you; it should be fixed, and I don't think it's a lost cause. --- JINMEI, Tatuya Internet Systems Consortium, Inc.