| |||||||||||||
Kernel Summit: Network summit summary
The networking folks have a long "to do" list, but few of the items on that list call for major changes. In the IPv6 area, there is a need for better load balancing and use of equivalent routes, and multicast routing still needs to be done (in a cleaner manner than it was done for IPv4). There is also still a major lack of useful performance data for the IPv6 stack; the developers have little idea of whether they perform well or not. There are plans in the works to support mobile IPv6, a protocol which lets you plug in anywhere and communicate over a tunnel back to your ISP. The tunneling code needs work in general to communicate tunnel status back to user space, and to provide a more generic tunneling capability. The networking layer increasingly needs to work with long timeouts, which will drive a push toward using 64-bit timers in the kernel. There is also, we were warned, a big reshuffle coming for the network portion of the kernel source tree. In the security area, there are plans to drop CIPE altogether and use the OpenVPN standard. The crypto support layer needs improvement, including crypto hardware support and an asynchronous mode suited to use in bottom half handlers. Netfilter needs some performance work, perhaps extending to the creation of a "grand unified flow cache" which would minimize the number of passes required on each packet. Nonlinear SKBs do not fit well with the netfilter way of looking at things, and performance suffers accordingly. Things are coming together in the area of 802.11 stacks; Jeff Garzik's new development tree centered around HostAP will help in that area. UDP fragmentation suffers from an "ID wrapping" problem which could lead to security issues; it needs to be fixed. RDMA is an area of increasing interest; believe it or not, the networking developers think that using TCP offload capabilities on network adaptors may be appropriate for this case. Some cards also offer "receive collation offload," essentially the reassembly of incoming TCP streams; the Linux stack may eventually take advantage of that. Asynchronous I/O support was discussed; it may be added for the transmit side, but few people see a need for it when reading from network sockets. There is continued work in TCP congestion control; a few algorithms have been added to the kernel, but nobody has yet figured out which ones actually perform well. Future work may include the implementation of TCP BIC 1.1. The format of nonlinear SKBs may change; the various fragments will be stored in the same sort of "scatterlist" used elsewhere in the kernel; this will require a driver API change, however. More IPSec work is needed. MPLS support is on the list. And there is talk of moving away from the route cache. (Log in to post comments)
OpenVPN standard? Posted Jul 22, 2004 10:30 UTC (Thu) by rl (subscriber, #2336) [Link] In the security area, there are plans to drop CIPE altogether and use the OpenVPN standard.When did OpenVPN become a standard? And how does it relate to the kernel, being a pure user-space solution? It certainly makes sense to tell people to use OpenVPN instead of CIPE. As much as it sucks, though, the VPN standard is IPsec.
OpenVPN standard? Posted Jul 23, 2004 5:28 UTC (Fri) by rise (guest, #5045) [Link] I think this refers to discussion regarding the line "Integrate CIPE somehow, maybe even a 2.6.x task" under the heading "Misc. and CRAZY ideas" in David S. Miller's 2.7.x Networking talk. My best guess is that it was brought up in terms of integrating a simpler VPN than IPSec and it was immediately pointed out that CIPE was insecure and OpenVPN was a better starting point.
|
|||||||||||||