Re: [v4tov6transition] [Softwires] 6a44 MTU issues

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 14 October 2010 13:00 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 9B7E63A6A3F; Thu, 14 Oct 2010 06:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.057
X-Spam-Level:
X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 FjX8cYlZPh4A; Thu, 14 Oct 2010 06:00:25 -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 786093A6868; Thu, 14 Oct 2010 06:00:25 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o9ECeJOK027465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Oct 2010 05:40:19 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o9ECeIQI029609; Thu, 14 Oct 2010 07:40:19 -0500 (CDT)
Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o9ECeIY3029589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Oct 2010 07:40:18 -0500 (CDT)
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; Thu, 14 Oct 2010 05:40:18 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
Date: Thu, 14 Oct 2010 05:40:16 -0700
Thread-Topic: [Softwires] [v4tov6transition] 6a44 MTU issues
Thread-Index: ActrbrcaemY+jAkPTJ6gHWuHABVE2QALRIAA
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59BDE877@XCH-NW-01V.nw.nos.boeing.com>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><E1829B60731D1740BB7A0 626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com><E1829B60731D1740BB7A06 2 6B4FAF0A65C59B79491@XCH-NW-01V.nw.nos.boeing.com><AANLkTik0_9CRSfi_O53MChgt 5QH+-=aR8HO7v+fHiLwY@mail.gmail.com><D8BB9123-C611-4476-AFA1-D0ADEEDB6270@ f ree.fr><E1829B60731D1740BB7A0626B4FAF0A65C59B797F3@XCH-NW-01V.nw.nos.boeing .com><279A3292-A291-4BC0-8FCF-53120066931E@free.fr><E1829B60731D1740BB7A06 2 6B4FAF0A65C59B7982A@XCH-NW-01V.nw.nos.boeing.com><E1829B60731D1740BB7A0626B 4FAF0A65C59B79898@XCH-NW-01V.nw.nos.boeing.com><0DD3B2BD-0200-4CC9-A78F-9A B 9F574FA3A@free.fr><E1829B60731D1740BB7A0626B4FAF0A65C59BDE54A@XCH-NW-01V.nw .nos.boeing.com> <6500B1FF-20D9-4311-977F-85890A29634C@free.fr> <E1829B60731D1740BB7A0626B4FAF0A65C59BDE714@XCH-NW-01V.nw.nos.boeing.com> <92BE7681-D0A1-4842-B0C6-BE7DE70FEDCE@free.fr>
In-Reply-To: <92BE7681-D0A1-4842-B0C6-BE7DE70FEDCE@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <softwires@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Subject: Re: [v4tov6transition] [Softwires] 6a44 MTU issues
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: Thu, 14 Oct 2010 13:00:26 -0000

Hi Remi, 

> -----Original Message-----
> From: Rémi Després [mailto:remi.despres@free.fr] 
> Sent: Thursday, October 14, 2010 12:09 AM
> To: Templin, Fred L
> Cc: Softwires; v4tov6transition@ietf.org
> Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues
> 
> 
> Le 13 oct. 2010 à 22:04, Templin, Fred L a écrit :
> >>>> ...
> >>>> If IPv6 packets longer than 1280 would be accepted by 6a44 
> >>>> servers, hosts could receive them in fragmented IPv4 datagrams.
> >>> 
> >>> Or they might be reassembled in the NAT(s) in front of
> >>> the host.
> >> They would indeed.
> >> But they would then be forwarded across the customer network.
> >> There, they may somewhere be fragmented to fit into fragments 
> >> shorter than the ISP MTU + 28.
> >> This happens for example if the ISP IPv6 MTU would be 1500-28 
> >> and that of some link in the customer site would be 1500-40 
> >> (say, for an IPv4 in IPv6 tunnel). 
> >> Right?
> > 
> > The fact of life is that we have the ISP managed network
> > domain and the end user network unmanaged network domain,
> > whether the ISP controls the CPE or not. The managed domain
> > should be well-behaved, but any manner of MTU irregularities
> > is possible within the unmanaged domain. For example, I can
> > login to my Linksys home router and manually set the MTU to
> > any value I want.
> > 
> > Anything that can be configured can be mis-configured, and
> > the ISP has no control of any misconfigurations that might
> > occur in the end user network. As far as the ISP can tell,
> > the end user network is just a black hole that silently
> > consumes packets. 
> 
> The point isn't about misconfigurations.
> It is that stateless tunnels (i.e. without SEAL ...) are 
> legitimate within customer sites.
> They can lead some intra-site IPv4 PMTUs that are less than 
> 1500, and even less than 1500 - 28.

No; the point is that (without a deterministic MTU discovery
scheme) you can't control the few end user networks that set
a 1308 MTU so the vast majority of end user networks that
set a 1500+ MTU are made to suffer.

Fred
fred.l.templin@boeing.com

> Then, because the 6a44 design privileges robustness, it is 
> better to avoid more constraints on intra-site PMTUs than 
> those that are absolutely mandatory.
> In order to statelessly support IPv6/UPD/IPV4 packets 
> intra-site IPv4 PMTUs of 1280 + 8 + 20 = 1308 octets IS the 
> obligation (one that should be satisfied with all realistic 
> stateless tunnels in customer sites).
> 
> RD
> 
> 
> 
>