RE: End System PMTUD behavior question

"Dunn, Jeffrey H." <jdunn@mitre.org> Fri, 23 January 2009 04:28 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 76E9F3A6A1D; Thu, 22 Jan 2009 20:28:10 -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 DE2663A6816; Thu, 22 Jan 2009 20:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.094
X-Spam-Level:
X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 qPnrS6DSh5MS; Thu, 22 Jan 2009 20:28:04 -0800 (PST)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 319333A68F7; Thu, 22 Jan 2009 20:28:04 -0800 (PST)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0N4Rkew007704; Thu, 22 Jan 2009 23:27:47 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0N4Rks0007698; Thu, 22 Jan 2009 23:27:46 -0500
Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 22 Jan 2009 23:27:46 -0500
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: "Mark_Andrews@isc.org" <Mark_Andrews@isc.org>, "Peter.Hunt@nokia.com" <Peter.Hunt@nokia.com>
Date: Thu, 22 Jan 2009 23:27:45 -0500
Subject: RE: End System PMTUD behavior question
Thread-Topic: End System PMTUD behavior question
Thread-Index: Acl89idt4hgVSkIuTk67SSBj8+G5bAAHFQyA
Message-ID: <3C6F21684E7C954193E6C7C4573B762701D3DD7186@IMCMBX1.MITRE.ORG>
References: Your message of "Fri, 23 Jan 2009 01:54:39 +0200." <808F2ECE7425024994976AC3D44BDCF4C8B900@vaebe108.NOE.Nokia.com> <200901230101.n0N119J0038463@drugs.dv.isc.org>
In-Reply-To: <200901230101.n0N119J0038463@drugs.dv.isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "ipv6-bounces@ietf.org" <ipv6-bounces@ietf.org>, "Sherman, Kurt T." <ksherman@mitre.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "Liou, Chern" <csliou@mitre.org>, "steve_eiserman@uscourts.gov" <steve_eiserman@uscourts.gov>, "Huang, Frank" <fhuang@mitre.org>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>, "Grayeli, Parisa" <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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org Mark,

Could you elaborate on what you mean by "DNS servers just tell the kernel to fragment at network mtu for UDP/IPv6 and ensure that DF is off for UDP/IPv4."  What is the "network MTU?" Also, to which implementations of DNS server are you referring?

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

-----Original Message-----
From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org] 
Sent: Thursday, January 22, 2009 8:01 PM
To: Peter.Hunt@nokia.com
Cc: shemant@cisco.com; Dunn, Jeffrey H.; Huang, Frank; Sherman, Kurt T.; ipv6@ietf.org; Liou, Chern; steve_eiserman@uscourts.gov; ipv6-bounces@ietf.org; v6ops@ops.ietf.org; Grayeli, Parisa
Subject: Re: End System PMTUD behavior question 


In message <808F2ECE7425024994976AC3D44BDCF4C8B900@vaebe108.NOE.Nokia.com>om>, Pet
er.Hunt@nokia.com writes:
> Hemant,
> =20
> 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.
> =20
> 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.
> =20
> 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.
> =20
> 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.
> =20

	For the record.  DNS servers just tell the kernel to fragment
	at network mtu for UDP/IPv6 and ensure that DF is off for
	UDP/IPv4.

	DNS clients don't usually generate packets big enough to
	be a issue.  If they do need to send a big (> 512) message
	they usually just switch straight to TCP to avoid having
	to probe the server to see how big a UDP message it will
	handle.

> 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.
> =20
> Peter Hunt
> Software Engineer
> Nokia S&S.
> =20
> 
> ------_=_NextPart_001_01C97CEC.C9F8E0DD
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <HTML dir=3Dltr><HEAD><TITLE>RE: End System PMTUD behavior =
> question</TITLE>=0A=
> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
> <META content=3D"MSHTML 6.00.6001.18183" name=3DGENERATOR></HEAD>=0A=
> <BODY>=0A=
> <DIV id=3DidOWAReplyText26585 dir=3Dltr>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#000000 =
> size=3D2>Hemant,</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>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.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>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.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>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.&nbsp;Furthermore,&nbsp;you're no longer really doing =
> a "ping 1500", but two pings of 1280 and 220 bytes, =
> respectively.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>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.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>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.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Peter =
> Hunt</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Software =
> Engineer</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Nokia =
> S&amp;S.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV></DIV></BODY></HTML>
> ------_=_NextPart_001_01C97CEC.C9F8E0DD--
> 
> --===============0174434914==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --===============0174434914==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------