>> Did you try apache with IPv6 patch? In that case, IPv6 patch
>> in the apache and the modssl part can interact in strange ways.
>> it is not supposed to work.
>do you mean intentionally? it is intentionally not working? Or is it
>just about modssl requiring an IPv6 patch? My guess is that modssl
>is doing some AF dependent stuff somewhere. It may be just the
>virtual host stuff ... is that working allright with the v6 patched
>Apache?
apache code from apache project (like stock 1.3.11) supports IPv4 only.
there are IPv6 patches for 1.3.11, from ftp.kame.net for example.
however, for IPv6 support, we made certain changes to internal
data structures. it is required because of IP address size differences
for example (4 byte field -> 16 byte field).
mod_perl assumes internal data structures present in normal IPv4-only
apache. so, mod_perl cannot coexist with IPv6 patch.
>> If you would like to try IPsec, please be sure to upgrade to freebsd
>> 4.1 or more recent KAME kits (not the integrated one in 4.0).
>> if you use the suggested software, it should work without too much
>> trouble.
>Aha, thanks for the hint. I have been using IPsec already on 4.0 for
>some tests. But will upgrade to 4.1 as soon as it is released ...
>should be any day now. I am still afraid of tracking the stable
>branch, since it may one day break anyway... or not?
I believe freebsd 4.1 should be fine. 4.1 is already out of the door,
and available via ftp mirrors.
>But I have done some more comparison, an SSH tunnel that hops from
>localhost:5250->SSH[aurora->prometeus]->localhost:5251 is with
>3des-cbc almost as fast as IPsec with 3des-cbc (SSH about 5-10%
>slower.) But using the blowfish-cbc cipher the outcome inverts!
>IPsec with blowfish compares terrible against the SSH tunnel (IPsec
>about 20% slower.) Something must be wrong with the blowfish
>implementation used in KAME or the SSH blowfish cheats. But,
>I also found the RC5 is performing best among the strong ciphers
>(even better than 1DES, especially at higher transfer buffer sizes.)
blowfish performance drawback is due to some implementation
inefficiency in the past in KAME side. freebsd 4.1 code uses KAME code
prior to the update. you may want to check KAME PR 229 on KAME PR
database, accessible via www.kame.net, for details.
>Would always use RC5, but unfortunately if you set up IPsec tunnels
>to CISCO routers, you are bound to 1DES, isn't it true?
I can't speak for cisco. do they do IPsec IPv6 yet?
>I did not quite understand the setkey function. I tried to use
>ipcomp but could not get it to work (always complains about the
>-C deflate option that I choose.) What I wanted to try is to
>increase throughput by compression before encryption. I have
>calculated that theoretically it should improve throughput, since
>the compression leaves less data to choke on for the encryption.
>But I can't test it with IPsec. Is that possible at all to use
>ipcomp/deflate before ESP-ing?
that is possible. after setting up enough SAs, you can setup policy
for ip compression, like:
spdadd ::1 :: any -P out ipsec ipcomp/transport//use esp/transport//use;
the tricky thing is that, ipcomp kicks in only when we can compress
the packet - for short packets ipcomp will not be useful and will
not come into effect.
>How come racoon is not part of the FreeBSD release in usr.sbin?
>I found it in ports. Is something wrong with it that it can't be
>trusted yet?
because it is still under development and we expect to have tons
of improvements, and config syntax changes. with freebsd 4.1, racoon
is supplied as a "ports".
itojun
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
