RE: End System PMTUD behavior question

Pekka Savola <pekkas@netcore.fi> Fri, 23 January 2009 06:04 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipngwg-archive@lists.ietf.org
Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DC53A68C4; Thu, 22 Jan 2009 22:04:33 -0800 (PST)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C8F3A689C for <ipv6@core3.amsl.com>; Thu, 22 Jan 2009 22:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level:
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599]
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 RmxT-iyoN4rz for <ipv6@core3.amsl.com>; Thu, 22 Jan 2009 22:04:30 -0800 (PST)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 0AA753A6801 for <ipv6@ietf.org>; Thu, 22 Jan 2009 22:04:29 -0800 (PST)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n0N63JwZ005027; Fri, 23 Jan 2009 08:03:19 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n0N63Ir8005023; Fri, 23 Jan 2009 08:03:18 +0200
Date: Fri, 23 Jan 2009 08:03:18 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Peter.Hunt@nokia.com
Subject: RE: End System PMTUD behavior question
In-Reply-To: <808F2ECE7425024994976AC3D44BDCF4C8B900@vaebe108.NOE.Nokia.com>
Message-ID: <alpine.LRH.2.00.0901230751120.4544@netcore.fi>
References: <3C6F21684E7C954193E6C7C4573B762701D3DD67DA@IMCMBX1.MITRE.ORG><B00EDD615E3C5344B0FFCBA910CF7E1D0632C176@xmb-rtp-20e.amer.cisco.com><3C6F21684E7C954193E6C7C4573B762701D3DD69E6@IMCMBX1.MITRE.ORG> <B00EDD615E3C5344B0FFCBA910CF7E1D0632C194@xmb-rtp-20e.amer.cisco.com> <808F2ECE7425024994976AC3D44BDCF4C8B900@vaebe108.NOE.Nokia.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1135482102-1232690599=:4544"
X-Virus-Scanned: ClamAV 0.94.2/8893/Thu Jan 22 22:18:43 2009 on otso.netcore.fi
X-Virus-Status: Clean
Cc: csliou@mitre.org, ipv6@ietf.org, ksherman@mitre.org, steve_eiserman@uscourts.gov, fhuang@mitre.org, v6ops@ops.ietf.org, pgrayeli@mitre.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools.

On Fri, 23 Jan 2009, Peter.Hunt@nokia.com wrote:
> For example, if a user does a "ping -s 1500" to a destination whose PMTU is 1280, the only way to avoid IP fragmentation is for the ping
> application to split the data into multiple messages, or for IPCMPv6 to do so. Either way, you have to introduce some way to identify them
> as "ping fragments" and reassemble them in order. That will require changes to the ICMPv6 protocol, I think. Furthermore, you're no longer
> really doing a "ping 1500", but two pings of 1280 and 220 bytes, respectively.

FWIW, what Remi said, different ping programs probably do this 
differently.  And good ones allow you to do exactly what you want 
(this is from Linux)

        -M hint
               Select Path MTU Discovery strategy.  hint may be either _do_ (prohibit fragmentation, even local one), _want_ (do PMTU
               discovery, fragment locally when packet size is large), or _dont_ (do not set DF flag).

When I use ping to figure out Path MTU issue, I usually have to run 
tcpdump on the side to be 100% sure how ping is actually behaving, 
because additionally, there's also PMTU caching on the local host. 
Some older versions also didn't support '-M do' properly for IPv6.

So there are quite a few things that could lead to non-deterministic 
behaviour.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------