Re: [v4v6interim] Fragmentation Options in NAT6 presentation

" Rémi Denis-Courmont" <remi.denis-courmont@nokia.com> Tue, 07 October 2008 07:48 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F983A6999; Tue, 7 Oct 2008 00:48:18 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A423A6973 for <v4v6interim@core3.amsl.com>; Tue, 7 Oct 2008 00:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KjN4mTcoieLe for <v4v6interim@core3.amsl.com>; Tue, 7 Oct 2008 00:48:16 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7F70A3A6850 for <v4v6interim@ietf.org>; Tue, 7 Oct 2008 00:48:16 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m977lWX7024526; Tue, 7 Oct 2008 10:48:06 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 10:47:57 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 10:47:56 +0300
Received: from esdhcp04196.research.nokia.com ([172.21.41.96]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 10:47:56 +0300
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Organization: Maemo Software - Nokia Devices R&D
To: v4v6interim@ietf.org
Date: Tue, 07 Oct 2008 10:47:56 +0300
User-Agent: KMail/1.9.10
References: <B2FE551A-5BA9-4D46-B619-EF694015D5AF@tahi.org> <48E6AEBD.9090205@gmail.com> <BB56240F3A190F469C52A57138047A03011DB57C@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <BB56240F3A190F469C52A57138047A03011DB57C@xmb-rtp-211.amer.cisco.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200810071047.56810.remi.denis-courmont@nokia.com>
X-OriginalArrivalTime: 07 Oct 2008 07:47:56.0568 (UTC) FILETIME=[03110980:01C92851]
X-Nokia-AV: Clean
Subject: Re: [v4v6interim] Fragmentation Options in NAT6 presentation
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

On Monday 06 October 2008 19:34:51 ext Wes Beebee (wbeebee), you wrote:
> I do agree that RFC 4821 is the right solution, and should be used in
> recommendations in IETF documents.
>
> However, how many stacks actually implement RFC 4821?

There are really two separate categories:

For TCP (and SCTP), this needs to be supported by the IP stack. The widespread 
use of TCP MSS clamping makes it obvious that many if not most IP stacks do 
not support this as yet.

For UDP, this needs to be implemented directly into the application-layer, 
with some additional support from the IP stack (to allow sending too large 
packets with DF bit). As yet, Linux is the only IP stack that explicitly 
supports this via some "proprietary" socket API options. As for applications, 
it is difficult to gather meaningful data. But considering the lack of 
support from lower layers, it is likely that this is mostly not implemented. 
I empirically believe that most applications simply have a "safe" hard-coded 
MTU for UDP, e.g. 1400 bytes or whatever.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim