From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752709AbbKPU74 (ORCPT ); Mon, 16 Nov 2015 15:59:56 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:40021 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752508AbbKPU7y (ORCPT ); Mon, 16 Nov 2015 15:59:54 -0500 Date: Mon, 16 Nov 2015 15:59:50 -0500 From: Sowmini Varadhan To: "Jason A. Donenfeld" Cc: Jiri Benc , therbert@google.com, David Miller , Netdev , LKML Subject: Re: Routing loops & TTL tracking with tunnel devices Message-ID: <20151116205950.GB27178@oracle.com> References: <20151116203709.GA27178@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Neat. Though, in my case, I'm not actually just prepending a header. > I'm doing some more substantial transformations of a packet. And this > needs to work with v4 too. So I'm not sure implementing a v6 spec will Understood, that spec was just referenced to indicate that there are more issues (mtu reduction etc) with nested encapsulation, and this is actually applicable even without the recursion issue (i.e even if you dont have a tunnelling loop, and even if it is not ipv6, there are some non-trivial problems here. Luckily, nested encaps is somewhat uncommon). --Sowmini