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

Rémi Després <remi.despres@free.fr> Thu, 14 October 2010 07:07 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 BBA563A6AA9; Thu, 14 Oct 2010 00:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_20=-0.74, 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 5UQFOc-5Hdf0; Thu, 14 Oct 2010 00:07:54 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id 922463A6AA4; Thu, 14 Oct 2010 00:07:54 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id ACC177000087; Thu, 14 Oct 2010 09:09:12 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 60E037000086; Thu, 14 Oct 2010 09:09:12 +0200 (CEST)
X-SFR-UUID: 20101014070912396.60E037000086@msfrf2309.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C59BDE714@XCH-NW-01V.nw.nos.boeing.com>
Date: Thu, 14 Oct 2010 09:09:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <92BE7681-D0A1-4842-B0C6-BE7DE70FEDCE@free.fr>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com><E1829B60731D1740BB7A0 626B4FAF0A65C59B79387@XCH-NW-01V.nw.nos.boeing.com><E1829B60731D1740BB7A062 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><E1829B60731D1740BB7A062 6B4FAF0A65C59B7982A@XCH-NW-01V.nw.nos.boeing.com><E1829B60731D1740BB7A0626B 4FAF0A65C59B79898@XCH-NW-01V.nw.nos.boeing.com><0DD3B2BD-0200-4CC9-A78F-9AB 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>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.1081)
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 07:07:55 -0000

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.

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