RE: End System PMTUD behavior question

"Hemant Singh (shemant)" <> Thu, 22 January 2009 22:36 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AE5A628C17F; Thu, 22 Jan 2009 14:36:15 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE15828C17F; Thu, 22 Jan 2009 14:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.941
X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mlkWVckr+6CS; Thu, 22 Jan 2009 14:36:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 975BC3A68F4; Thu, 22 Jan 2009 14:36:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,308,1231113600"; d="scan'208";a="34631134"
Received: from ([]) by with ESMTP; 22 Jan 2009 22:35:49 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id n0MMZnhn016391; Thu, 22 Jan 2009 17:35:49 -0500
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id n0MMZnb7019953; Thu, 22 Jan 2009 22:35:49 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 17:35:48 -0500
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: Thu, 22 Jan 2009 17:35:47 -0500
Message-ID: <>
In-Reply-To: <3C6F21684E7C954193E6C7C4573B762701D3DD69E6@IMCMBX1.MITRE.ORG>
Thread-Topic: End System PMTUD behavior question
Thread-Index: Acl7+fSDtCRQmHdATNy7UebOW+92QAACmYbgAASrC5AAK66ZwA==
References: <3C6F21684E7C954193E6C7C4573B762701D3DD67DA@IMCMBX1.MITRE.ORG> <> <3C6F21684E7C954193E6C7C4573B762701D3DD69E6@IMCMBX1.MITRE.ORG>
From: "Hemant Singh (shemant)" <>
To: "Dunn, Jeffrey H." <>
X-OriginalArrivalTime: 22 Jan 2009 22:35:48.0876 (UTC) FILETIME=[C60964C0:01C97CE1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1327; t=1232663749; x=1233527749; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=20End=20System=20PMTUD=20behavior=20quest ion |Sender:=20 |To:=20=22Dunn,=20Jeffrey=20H.=22=20<>; bh=Qzoi189D6imjvqRk++mdfuCQgwFrFC9omNmNjcd5JOY=; b=Z4DK5i5XNny7d/ptLA/pVPKBOdliEtHb5zAgQfM7e3AFjU1P+ciPDMFTIh 3IddZdg0Uf7qXzM2qfo7rLW4sXv5sQM94t6xc7cuetcn0I8jCMbNN1MykC/T NQL1IRto1c;
Authentication-Results: rtp-dkim-2;; dkim=pass ( sig from verified; );
Cc:, "Sherman, Kurt T." <>, 6man mailing list <>, "Liou, Chern" <>,, "Huang, Frank" <>,, "Grayeli, Parisa" <>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: Jeffrey,

Both IPv4 and IPv6 standards recommend not to fragment.  So the first
impact on the system behavior for host receiving an PTB message is to
try and not fragment.  I have not paid attention to older RFC's.  I am
working off of RFC 4821 that recommends a host keep "conceptual"
variables in cache at the IP layer and all other layers of code on the
host may access this cache to get the current value of the MTU to be
used by host.  See following text from RFC 4821.

[Furthermore, the natural mechanism to 
share Path MTU information between concurrent or subsequent connections 
is a path information cache in the IP layer. The various 
Packetization Protocols need to have the means to access and update 
the shared cache in the IP layer. This memo describes PLPMTUD in 
terms of its primary subsystems without fully describing how they 
are assembled into a complete implementation.]

Also see section 5 of RFC 4821.

What UNH has tested for current host behavior and so have you is because
host are following older PMTU RFCs like 1981.  Also, I agree with you on
RFC 1981 that host may fragment if there is no easy means for the host's
layers to pass MTU information back and forth.  My 2 cents is for new
hosts to follow RFC 4821 and not fragment packets.



IETF IPv6 working group mailing list
Administrative Requests: