Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

Rémi Després <remi.despres@free.fr> Mon, 11 October 2010 16:28 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC41A3A6A18; Mon, 11 Oct 2010 09:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.438
X-Spam-Level:
X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGy2afTg+qxE; Mon, 11 Oct 2010 09:28:06 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by core3.amsl.com (Postfix) with ESMTP id A04203A6822; Mon, 11 Oct 2010 09:28:06 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 3F2F670000A1; Mon, 11 Oct 2010 18:29:18 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 9F0CD7000081; Mon, 11 Oct 2010 18:29:17 +0200 (CEST)
X-SFR-UUID: 20101011162917651.9F0CD7000081@msfrf2301.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <AANLkTik0_9CRSfi_O53MChgt5QH+-=aR8HO7v+fHiLwY@mail.gmail.com>
Date: Mon, 11 Oct 2010 18:29:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8BB9123-C611-4476-AFA1-D0ADEEDB6270@free.fr>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com> <E1829B60731D1740BB7A0626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com> <AANLkTik0_9CRSfi_O53MChgt5QH+-=aR8HO7v+fHiLwY@mail.gmail.com>
To: Washam Fan <washam.fan@gmail.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <softwires@ietf.org>, v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2010 16:28:07 -0000

Hi Washam and Fred,

Le 9 oct. 2010 à 05:02, Washam Fan a écrit :
> ...
> For this bullet in sec5, draft-despres-softwire-6a44-00
> 
>   o  6a44 Server functions refuse packets received from their IPv6
>      pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6
>      Packet Too Big messages returned to sources as required by
>      [RFC2460].)
> 
> I think it could only apply to the case where the received IPv6
> packets forwarded to the external domain. In the case the 6a44 server
> does the hairpinning, the 6a44 server would refuse packets whose size
> exceed (IPv4 MTU - 28) octets, with ptb ICMPv6 msg.
> ...


>>> -----Original Message-----
>>> From: v4tov6transition-bounces@ietf.org
>>> [mailto:v4tov6transition-bounces@ietf.org] On Behalf Of
>>> Templin, Fred L
>>> ...
>>> More to this point about double-tunneling, how were
>>> folks thinking that IPv6 VPNs would be run over a
>>> 1280 MTU IPv6-in-IPv4 tunnel? That is double-tunneling,
>>> and seems like it would be a quite common case, but the
>>> MTU seems deficient. Should it use IPv6 fragmentation?
>>> ...

Actually, the 6a44 specification should, instead of 1280, require IPv4 MTU - 28 octets, both for hairpinning and traversal cases.
(It is only hosts that should better take 1280 as default MTU if not having reliable PMTU discovery.)
I will check with co-authors to fix it in a later version.

Thanks to both of you for the discussion.
RD