
<html><head></head><body>Thank you for testing the scenario and confirming our findings.  For now, we're going to run ipv6 in ipv6.  The only reason I was trying to use ipv4 for the tunnel is because many of the server providers we've contacted, especially in South America and Asian locations, do not provide any SLA on ipv6.<br>

<br>

Thanks,<br>

James<br><br><div class="gmail_quote">On November 14, 2015 2:51:19 PM MST, Tuomo Soini <tis@foobar.fi> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">On Sat, 14 Nov 2015 13:03:50 +0900<br />Paul Wouters <paul@nohats.ca> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> You can try esp=aes_gcm128-null which is the fastest good crypto algo<br /> to use but I'm not sure if that is your real problem <br /></blockquote><br />I don't think that's the problem. There is some huge performance<br />bottleneck in kernel when running ipv6 in ipv4 with xfrm/netkey ipsec<br />stack. On my quick test it show exactly same type of performance<br />problem.<br /></pre></blockquote></div></body></html>