RE: End System PMTUD behavior question

"Dunn, Jeffrey H." <> Wed, 21 January 2009 22:36 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id E25613A6937; Wed, 21 Jan 2009 14:36:06 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5252D3A6937; Wed, 21 Jan 2009 14:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.102
X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3xrtEdvRTP4V; Wed, 21 Jan 2009 14:36:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6384D3A692D; Wed, 21 Jan 2009 14:36:04 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.1/8.13.1) with ESMTP id n0LMZlc3016137; Wed, 21 Jan 2009 17:35:47 -0500
Received: from imchub1.MITRE.ORG ( []) by (8.13.1/8.13.1) with ESMTP id n0LMZlkI016132; Wed, 21 Jan 2009 17:35:47 -0500
Received: from IMCMBX1.MITRE.ORG ([]) by imchub1.MITRE.ORG ([]) with mapi; Wed, 21 Jan 2009 17:35:47 -0500
From: "Dunn, Jeffrey H." <>
To: "Hemant Singh (shemant)" <>
Date: Wed, 21 Jan 2009 17:35:46 -0500
Subject: RE: End System PMTUD behavior question
Thread-Topic: End System PMTUD behavior question
Thread-Index: Acl7+fSDtCRQmHdATNy7UebOW+92QAACmYbgAASrC5A=
Message-ID: <3C6F21684E7C954193E6C7C4573B762701D3DD69E6@IMCMBX1.MITRE.ORG>
References: <3C6F21684E7C954193E6C7C4573B762701D3DD67DA@IMCMBX1.MITRE.ORG> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: Hemant,

I do not understand your answer to question 1.  How would the purpose of a user sending ICMPv6 echo requests bear on system behavior? Also, unless the operating system has a facility to pass the PMTU size to the application, e.g., the MMS_S value mentioned in RFC 1981, AND the application can make use of the information. There is no expectation that the application, e.g., DNS, or the layer above IPv6, e.g., UDP, can make use of the information in RFC 1981; therefore your assertion that the host should be sending packets within the PMTU is unreasonable.

Many thanks for pointing out RFC 4821 in answer to question 2. I had forgotten about that and, interestingly, it does not appear in the NIST IPv6 profile, which we are using to guide our testing. 

Best Regards, 
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Hemant Singh (shemant) [] 
Sent: Wednesday, January 21, 2009 3:35 PM
To: Dunn, Jeffrey H.;;; 6man mailing list
Cc: Sherman, Kurt T.; Liou, Chern;; Huang, Frank; Grayeli, Parisa
Subject: RE: End System PMTUD behavior question

> The following questions occurred to us:

>  1. Should the hosts re-transmit the ICMPv6 echo request(s) in

If the ICMPv6 echo reqs were being used for PMTUD, the answer should be
a No.  The host just received an Indication of Too Big that also said
the PMTU is 1280, so the host should be sending any subsequent packets
keeping PMTU of 1280 in mind without have to fragment. Then my question
is, if ICMPv6 is not being used for PMTUD, then for what purpose is
ICMPv6 being used such that an ICMPv6 req of 1500 is needed when a req
of size 1280 can be sent?

>  2. If not, should the host that sent two echo requests have waited
for a response in support of PMTUD? 

PMTUD does recommend a host send a probe and wait for a timeout interval
before sending another probe. The RFCs recommend five times larger
timeout value that the normal timeout of the protocol/app being used to
probe.  So, say, the ICMPv6 timeout being used in your test is 2 secs,
then the host should wait for 10 secs for a reply.  See RFC 4821 for
timeout recommendations for how long to wait for a probe reply.  In your
test case, I have got to believe, the Too Big error reached the host in
10 secs of sending the ICMPv6 req - the first hop router is most likely
to catch the Too Big condition and respond to the probe.


IETF IPv6 working group mailing list
Administrative Requests: