RE: End System PMTUD behavior question

<> Thu, 22 January 2009 23:55 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 0070D3A6806; Thu, 22 Jan 2009 15:55:35 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D633D3A6806; Thu, 22 Jan 2009 15:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6JGxB-8QThAZ; Thu, 22 Jan 2009 15:55:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 857E73A677C; Thu, 22 Jan 2009 15:55:32 -0800 (PST)
Received: from ( []) by (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0MNsgw2022833; Fri, 23 Jan 2009 01:54:44 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 01:54:44 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 01:54:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: End System PMTUD behavior question
Date: Fri, 23 Jan 2009 01:54:39 +0200
Message-ID: <>
thread-topic: End System PMTUD behavior question
thread-index: Acl7+fSDtCRQmHdATNy7UebOW+92QAACmYbgAASrC5AAK66ZwAAI127Y
References: <3C6F21684E7C954193E6C7C4573B762701D3DD67DA@IMCMBX1.MITRE.ORG><><3C6F21684E7C954193E6C7C4573B762701D3DD69E6@IMCMBX1.MITRE.ORG> <>
From: <>
To: <>, <>
X-OriginalArrivalTime: 22 Jan 2009 23:54:40.0026 (UTC) FILETIME=[CA0597A0:01C97CEC]
X-Nokia-AV: Clean
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0174434914=="
Errors-To: This is a multi-part message in MIME format.

Forgive me if I've misunderstood, but it sounds like you're saying that we should require protocols or applications above IP to always send data in messages small enough to avoid IP fragemntation.
I agree it makes sense for a higher layer to use the PMTU information in IP's cache when it can. Expecting TCP to use the PMTU is perfectly reasonable, as it's already chopping up a byte stream into packets. For protocols which are already packetized, though, I think it's less advantageous to burden them (or the application using them) with the problem of fragmentation and reassembly, to avoid IP fragmentation.
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.
In the case of an application which sends records in single UDP frames, to avoid fragmentation is must split its messages into MTU-sized chuncks, and come up with a way at the destination to identify and reassemble the chunks in order. This seems a bit unreasonable, given that IPv6 has a perfectly good mechanism to do this already.
So I think the behaviour observed by Thomas during his testing is correct. I don't think ping or ICMPv6 should reduce the ICMP message size to avoid IP fragmentation.
Peter Hunt
Software Engineer
Nokia S&S.
IETF IPv6 working group mailing list
Administrative Requests: