Date: Wed, 04 Dec 2002 02:05:15 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Tony Finch <dot@dotat.at> Cc: wacky@ns1.vrx.net, hackers@freebsd.org, net@freebsd.org Subject: Re: jail: multiple ip's Message-ID: <3DEDD35B.A1E7638E@mindspring.com> References: <E18JVwz-0003Hh-00@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Note: Cross-post and "Reply-To:" of freebsd-net! Tony Finch wrote: > wacky@ns1.vrx.net (Mike Ghunt) wrote: > > Has anyone hacked the jail code to support more than one ip? > >Would it be wise to hack at the code to add such a feature? > > Probably the best way to address this issue is to incorporate the > network stack virtualization patch, then change the jail ID from > an IPv4 address into a network stack ID. I'm really tempted to say that the network virtualization patch is special purpose, and introduces a lot of overhead that would not be there without the network virtualization patch. It's the type of thing, IMO, that should be possible for an experimenter, but not integrated into the FreeBSD kernel itself. I'm also alarmed at the mbuf header bloat, in general, for some very specific and not very common uses, including the pushing up of the full Ethernet packet. The only use I can see for that particular trick is supporting VIPs on cards in promiscuous mode, which normally would not support VIPs (e.g. the Intele Gigabit ethernet car supports 16 of them) and did not support abusing the multicast mask to obtain VIPs (e.g. the FXP driver method). Finally, with the integration of the IPSEC stuff from OpenBSD that Sam Leffler has been doing, I worry that the IPSEC implementation is not going to be fixed. Specifically, the IPSEC data is cloned per socket opened in IPv4, if IPSEC is in the kernel at all, and it bloats the per connection memory cost considerably, even if the IPSEC is never used, or the security association never varies from the default. It's all well and good to have an IPSEC axe to grind (8-)) relative to the SSL stuff, but it's not a good idea to grind it against people's memory footprint unnecessarily. Note that Sam did not introduce this problem, KAME did, with the poor IPSEC integration into IPv4 (it looks very much like an afterthought), but his addition to the code perpetuates it. There are some things it's important to integrate/fix so that they are always there, there are some things which should be optioned, and there are some things which should remain in academia, until they are standardized, forcing them on everyone. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DEDD35B.A1E7638E>