netdev - RE: UDP path MTU discovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Mar 2010 16:38:49 -0700
From:	"Templin, Fred L" <Fred.L.Templin@...ing.com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	Rick Jones <rick.jones2@...com>
CC:	"Edgar E. Iglesias" <edgar.iglesias@...il.com>,
	Andi Kleen <andi@...stfloor.org>, Glen Turner <gdt@....id.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: UDP path MTU discovery



> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On Behalf Of Eric Dumazet
> Sent: Monday, March 29, 2010 2:29 PM
> To: Rick Jones
> Cc: Edgar E. Iglesias; Andi Kleen; Glen Turner; netdev@...r.kernel.org
> Subject: Re: UDP path MTU discovery
> 
> Le lundi 29 mars 2010 à 14:01 -0700, Rick Jones a écrit :
> 
> > I would get the alphabet soup completely garbled, but the DNS folks are talking
> > about EDNS (?) message sizes upwards of 4096 bytes - encryption/authentication
> > and other angels being asked to dance on the head of the DNS pin are asking for
> > more and more space in the messages.
> >
> > So, someone will have to blink somewhere - either DNS will have to go TCP and
> > *possibly* take RTT hits there depending on various patch streams, or the IEEE
> > will have to sanction jumbo frames and people deploy them widely, or it will
> > have to become feasible to actually do the occasional IPv6 datagram
> > fragmentation and get a timely retransmission out of a UDP application on a PMTU
> > hit.
> >
> 
> 1) 4096 bytes UDP messages... well...
> 2) Using regular TCP for DNS servers... well...
> 
> I believe some guys were pushing TCPCT (Cookie Transactions) for this
> case ( http://tools.ietf.org/html/draft-simpson-tcpct-00.html )
> 
> (That is, using an enhanced TCP for long DNS queries... but not only for
> DNS...)

IPv4 gets by this by setting DF=0 in the IP header, and
lets the network fragment the packet if necessary. IPv6 can
similarly get by this by having the sending host fragment
the large UDP packet into IPv6 fragments no longer than
1280 bytes each.

But wait! IPv4 hosts are only required to reassemble 576 bytes
at a minimum, and IPv6 hosts are only required to reassemble
1500 bytes at a minimum. Indeed, RFC2460 says:

   "An upper-layer protocol or application that depends on IPv6
   fragmentation to send packets larger than the MTU of a path should
   not send packets larger than 1500 octets unless it has assurance that
   the destination is capable of reassembling packets of that larger
   size."

but it is not clear how the sender can get such "assurance".
In the end, perhaps IPv6 should just do what IPv4 does;
turn off PMTUD and hope for the best?

Fred
fred.l.templin@...ing.com 
 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html