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: [email protected] [mailto:[email protected]] Sent: Thursday, January 22, 2009 8:01 PM To: [email protected] Cc: [email protected]; Dunn, Jeffrey H.; Huang, Frank; Sherman, Kurt T.; [email protected]; Liou, Chern; [email protected]; [email protected]; [email protected]; Grayeli, Parisa Subject: Re: End System PMTUD behavior question In message <[email protected]>, Pet [email protected] 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> </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> </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> </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. Furthermore, 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> </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> </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> </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&S.</FONT></DIV>=0A= > <DIV dir=3Dltr><FONT size=3D2></FONT> </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 > [email protected] > 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: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
