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
- [v4v6interim] Fragmentation Options in NAT6 prese… Hiroshi MIYATA
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Wes Beebee (wbeebee)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Eric Vyncke (evyncke)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Hiroshi MIYATA
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Brian E Carpenter
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Hiroshi MIYATA
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Wes Beebee (wbeebee)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Eric Vyncke (evyncke)
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Fred Baker
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Rémi Denis-Courmont
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Brian E Carpenter
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Mark Andrews
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Dan Wing
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Magnus Westerlund
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Brian E Carpenter
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Rémi Denis-Courmont
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Iljitsch van Beijnum
- Re: [v4v6interim] Fragmentation Options in NAT6 p… Eric Vyncke (evyncke)