IETF Logo Mail Archive

[v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 08 October 2010 17:16 UTC

Return-Path: <Fred.L.Templin@boeing.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 6B6B43A6927; Fri, 8 Oct 2010 10:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.159
X-Spam-Level:
X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 nWS-2N51BWLX; Fri, 8 Oct 2010 10:16:42 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id EC15C3A6919; Fri, 8 Oct 2010 10:16:41 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o98HHiw4025686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Oct 2010 10:17:45 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o98HHimE006504; Fri, 8 Oct 2010 10:17:44 -0700 (PDT)
Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o98HHfwh006430 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 8 Oct 2010 10:17:44 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 8 Oct 2010 10:17:41 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Softwires <softwires@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Date: Fri, 08 Oct 2010 10:17:40 -0700
Thread-Topic: IPv6 VPNs configured over 1280 MTU tunnels
Thread-Index: ActlqdIGu1dYQTloSA6e+ZVmJnpudwAAPoSQAAPsvTMATz16wAAEJ2Yg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com>
References: <E1829B60731D1740BB7A0626B4FAF0A65C59B78DA4@XCH-NW-01V.nw.nos.bo eing.com><C8D29306.3EDBD%yiu_lee@cable.comcast.com> <E1829B60731D1740BB7A0626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Fri, 08 Oct 2010 17:16:43 -0000

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
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
>

v2.23.0 | Report a Bug | By Email