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

Washam Fan <washam.fan@gmail.com> Sat, 09 October 2010 03:01 UTC

Return-Path: <washam.fan@gmail.com>
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 9AAFD3A677C; Fri, 8 Oct 2010 20:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level:
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599]
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 OyPuX+d3kYa3; Fri, 8 Oct 2010 20:01:02 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 32A2D3A677E; Fri, 8 Oct 2010 20:01:01 -0700 (PDT)
Received: by wwj40 with SMTP id 40so1313487wwj.13 for <multiple recipients>; Fri, 08 Oct 2010 20:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JOGUIvNtmQ58jC7EUDp0PdsnS3r9kAG8chwpao0Z5EI=; b=s7cmTgvudpjTkKBJXRxUYCvuNyC5nNNnjxDtkykk2+L5TAmHGZV5jrhmZnVszKAfD6 SFUv9NTjECXfq08u0jGRSap1ycF3QavCJJm3nhEdRbm63Hl/DoPDxfCvNYZHaRmWrU5T 9mQPAD168Wv/nEnT0AmsSmqpYnPs9Z/qvvFAQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZOtXgh3qEhOsmvOIr2niIDjz7p2tWx4lxBKMPyreon04VBFTXbLJ2HtmzVWVqey/oC d3i5JP6oYaDaQEsCuZNg1rxZsPR6vche1PHkCkFljknKgVF7mvcz4o1BbEDS6uTueAZQ Ql5SXD0PDu92wvvzBgK5inHH3u/0FSPTgLNuc=
MIME-Version: 1.0
Received: by 10.216.91.16 with SMTP id g16mr2983011wef.78.1286593327109; Fri, 08 Oct 2010 20:02:07 -0700 (PDT)
Received: by 10.216.17.206 with HTTP; Fri, 8 Oct 2010 20:02:07 -0700 (PDT)
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com> <E1829B60731D1740BB7A0626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com>
Date: Sat, 9 Oct 2010 11:02:07 +0800
Message-ID: <AANLkTik0_9CRSfi_O53MChgt5QH+-=aR8HO7v+fHiLwY@mail.gmail.com>
From: Washam Fan <washam.fan@gmail.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Softwires <softwires@ietf.org>, "v4tov6transition@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: Sat, 09 Oct 2010 03:01:03 -0000

Hi,

2010/10/9 Templin, Fred L <Fred.L.Templin@boeing.com>om>:
> End systems in end user networks that connect to the
> IPv6 Internet will likely want to configure IPv6 VPNs,
> e.g., so that they can securely connect to their home
> office networks. Those VPN links must present a 1280
> minimum MTU to upper layers, but if they traverse a
> link in the path with a too-small MTU then the end
> system will see an MTU underrun and will need to use
> IPv6 fragmentation.
>
> An IPv6-in-IPv4 tunnel with a fixed static 1280 MTU is

I assume you were refering 6a44. The reason why 6a44 restricts 1280
MTU is IPv6 PMTU performance is not reliable practically, per Remi's
reponse to me. If PMTU could (and I think it should) perform well,
6a44 would permit more larger MTU.

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.

Thanks,
washam

> an example of a link in the path that could cause such
> an MTU underrun for end system VPN links. So, should we
> be concerned that tunnels with a fixed 1280 MTU would
> make life difficult for the common operational practice
> of end systems using VPNs?
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> -----Original Message-----
>> From: v4tov6transition-bounces@ietf.org
>> [mailto:v4tov6transition-bounces@ietf.org] On Behalf Of
>> Templin, Fred L
>> Sent: Friday, October 08, 2010 7:52 AM
>> To: Yiu L. Lee; Brian E Carpenter; Ole Troan
>> Cc: Softwires; v4tov6transition@ietf.org
>> Subject: Re: [v4tov6transition] [Softwires] ISP support of
>> NativeIPv6across NAT44 CPEs -Proposed 6a44 Specification
>>
>>
>> > CPE. This double tunneling tech seems scary.
>>
>> 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?
>>
>> Fred
>> fred.l.templin@boeing.com
>> _______________________________________________
>> v4tov6transition mailing list
>> v4tov6transition@ietf.org
>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>
> _______________________________________________
> v4tov6transition mailing list
> v4tov6transition@ietf.org
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>