| 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
| ||
|
Date: Thu, 01 Apr 2010 10:27:44 +1030 From: Glen Turner <gdt@....id.au> To: Andi Kleen <andi@...stfloor.org> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: UDP path MTU discovery On Sun, 2010-03-28 at 10:41 +0200, Andi Kleen wrote: > It means though that all IPv6 UDP applications essentially have > to implement path mtu discovery support (which is non trivial) It is trivial from the applications point of view to let the kernel find the UDP Path MTU. We just need more information from the kernel as to when it would like to see those packets (ie, for performance we'd like to feed in the packet to re-send as soon as the ICMP Packet Too Big arrives for the previous packet). > Will be likely a long time until they're all fixed. There's no need to make that assumption. We'd very much like transactional UDP protocols to work well in advanced networks. The other choices -- holding down millions of TCP sockets, or using new protocols (and there are competing proposals) -- don't exactly fill our operations teams with confidence. We'd very much like to use UDP were we can and something else where we must. > Seems like a big hole not considered by the IPv6 designers? Yeah. The sockets API for IPv6 required an additional feature that the IETF did not foresee. -- Glen Turner www.gdt.id.au/~gdt -- 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
Powered by blists - more mailing lists