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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 11 October 2010 15:52 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 E9FBF3A6A9B; Mon, 11 Oct 2010 08:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level:
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 5ll8wLvm1XH5; Mon, 11 Oct 2010 08:52:29 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B566D3A6A8F; Mon, 11 Oct 2010 08:52:26 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9BFrW7K005147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Oct 2010 10:53:33 -0500 (CDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9BFrWjJ020040; Mon, 11 Oct 2010 08:53:32 -0700 (PDT)
Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9BFrWP3020036 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 11 Oct 2010 08:53:32 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 11 Oct 2010 08:53:32 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Washam Fan <washam.fan@gmail.com>
Date: Mon, 11 Oct 2010 08:53:31 -0700
Thread-Topic: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
Thread-Index: ActnXl0nC9d3qETYQx6ZhJvi5AtX4wB/Phwg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59B797A9@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><E1829B60731D1740BB7A0 626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com><E1829B60731D1740BB7A0626B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com> <AANLkTik0_9CRSfi_O53MChgt5QH+-=aR8HO7v+fHiLwY@mail.gmail.com>
In-Reply-To: <AANLkTik0_9CRSfi_O53MChgt5QH+-=aR8HO7v+fHiLwY@mail.gmail.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
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: Mon, 11 Oct 2010 15:52:31 -0000

 

> -----Original Message-----
> From: Washam Fan [mailto:washam.fan@gmail.com] 
> Sent: Friday, October 08, 2010 8:02 PM
> To: Templin, Fred L
> Cc: Softwires; v4tov6transition@ietf.org
> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> 1280 MTU tunnels
> 
> 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.

No; I'm referring to any IPv6-in-IPv4 tunnel that sets
a static 1280 MTU. There are more than one of these.

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

Its not about IPv6 PMTUD; its about IPv4 PMTUD. If a
tunnel router in an end user site sends an
IPv6-in-UDP-in-IPv4 packet out though its NAT and into
the ISP network, and if the ISP network needs to drop
the packet and send back an ICMPv4 PTB, then the NAT
could drop the PTB or the PTB might not contain enough
information for stateless translation into an ICMPv6
PTB. That's one profile for an MTU-related black hole. 

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

The point is that if the tunnel router sets a static
1280 MTU on its tunnel virtual interface then VPN
tunnel endpoints behind the tunnel router will see
an MTU underflow. That is double-tunneling, but it
is a fact of life in common operational practice.

Fred
fred.l.templin@boeing.com 

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