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) [mailto:[email protected]] Sent: Wednesday, January 21, 2009 3:35 PM To: Dunn, Jeffrey H.; [email protected]; [email protected]; 6man mailing list Cc: Sherman, Kurt T.; Liou, Chern; [email protected]; 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 fragments? 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. Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
