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

Rémi Després <remi.despres@free.fr> Tue, 12 October 2010 07:24 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 D4B4E3A67B6; Tue, 12 Oct 2010 00:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.429
X-Spam-Level:
X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, 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 C2--LAzci07P; Tue, 12 Oct 2010 00:24:32 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id AD6DA3A6405; Tue, 12 Oct 2010 00:24:31 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 491207000086; Tue, 12 Oct 2010 09:25:44 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id BC5557000081; Tue, 12 Oct 2010 09:25:43 +0200 (CEST)
X-SFR-UUID: 20101012072543771.BC5557000081@msfrf2421.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65C59B79898@XCH-NW-01V.nw.nos.boeing.com>
Date: Tue, 12 Oct 2010 09:25:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DD3B2BD-0200-4CC9-A78F-9AB9F574FA3A@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> <E1829B60731D1740BB7A0626B4FAF0A65C59B7982A@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65C59B79898@XCH-NW-01V.nw.nos.boeing.com>
To: Fred L Templin <Fred.L.Templin@boeing.com>, Washam Fan <washam.fan@gmail.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: Tue, 12 Oct 2010 07:24:32 -0000

Fred and Washam,

I reacted too fast to previous remarks when I proposed to modify the accepted IPv6 MTU in 6a44 draft.
If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could receive them in fragmented IPv4 datagrams.
This would be contrary to the objective of simplicity (datagram reassembly would have to be include in 6a44 clients) and to the objective of security (a new door would be open to dos attacks).
No change on this point will therefore appear in the next version of the draft. 
Some additional explanations may be appropriate, but preferably after a consensus on what has to be said.

Then the MTU issue of IPv6 in IPv6 tunnels that Fred underlines remains as is.
If the PMTU of such a tunnel is unknown, or known to be less than 1280+40, tunnel endpoints have to tunnel 1280-octets external packets in two pieces, using a fragmented IPv6 datagram for this. 
Reassembly at the other end is then necessary. 
It can be facilitated if the tunnel is treated as only one flow, with packets in general kept in sequential order. 

Regards,
RD
  

>>>> Actually, the 6a44 specification should, instead of 1280, 
>>>> require IPv4 MTU - 28 octets, both for hairpinning and 
>>>> traversal cases.
>>> 
>>> How can you be sure that IPv4 PMTUD will work in
>>> the traversal case?
>> 
>> In the to-host direction, because the ISP network is all what 
>> is left to traverse before reaching the CPE.
> 
> In what you call the to-host direction, any ICMPv4
> returned from the ISP network might not have enough
> information for stateless translation to ICMPv6.

1. Could you be more specific?
Do yout see a significant difference with what happens with 6to4,


>> In the from host direction, one can't be sure, but doesnt' need to.
>> If a smaller PMTU is encountered further downstream, a PTB 
>> ICMPv6 error message will be returned from there.
> 
> In the from-host direction, any ICMPv4 returned from
> the ISP network might not be delivered to the tunnel
> endpoint due to NAT filtering,

2. Then the IPv6 service is somewhat damaged concerning fault diagnosing, like the underlying IPv4 service.
But at least packets that should be delivered are delivered.


> and might not have
> enough information for stateless translation to ICMPv6.

3. Same as 1. above.


>>> In the to-host direction, because the ISP network is all what 
>>> is left to traverse before reaching the CPE.
>> 
>> In what you call the to-host direction, any ICMPv4
>> returned from the ISP network might not have enough
>> information for stateless translation to ICMPv6.
> 
> I should also say, any ICMPv4 returned from within
> the end user network (where MTUs might not be so well
> managed) might not be delivered to the tunnel endpoint
> in the ISP network.

4. Same as 2. above.
(Since IPv4 fragments rather than returning packet-too-big ICMP messages, this cannot concern MTUs).

Yet, there remains another problem with the replacement of 1280 by "IPv4 MTU - 28" (I proposed it too quickly) because it creates risks of fragmentation ...