(usagi-users 02849) IPsec for an IPv6-in-IPv6 Tunnel

[Brian Buesker <bbuesker@xxxxxxxxxxxx>]

I am using the vanilla 2.6.0 kernel. I want to set up an IPv6-in-IPv6 
tunnel with the ipv6tunnel command, and then specify that all traffic 
over that tunnel should be protected with ESP. IPsec tunnel mode is 
undesirable for the reasons stated in the IETF Internet-Draft at:

http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt

Here is what I am doing to setup the tunnel (with the actual addresses 
replaced with symbolic ones):

ipv6tunnel add vpn remote A local B hoplimit 255 dev ip6tnl0
ip link set dev vpn up
ip addr add D1/64 dev vpn
ip route add C/64 dev vpn preference 1
ip addr add D2/64 dev eth0

The symmetric set of commands are repeated on the remote node. After 
this, I can successfully send packets to and from a node in the D 
network (D2) and a node in the C network. However, I then tried 
specifying that I want IPsec protection for this traffic by using the 
following setkey commands (racoon is already running and configured 
properly):

setkey -c <<EOF
spdadd B/128 A/128 ipv6 -P out ipsec esp/transport//require;
spdadd A/128 B/128 ipv6 -P in ipsec esp/transport//require;
EOF

Upon doing this, if I send a packet from D2 to a node in the C network, 
the IKE negotiation succeeds between A and B and I am able to send a 
packet over the tunnel which gets ESP applied to it. The headers of the 
tunneled packet are the following:

IPv6
Destination Option Header
Encapsulating Security Payload

However, the remote node never receives the packet. It seems that when B 
receives the packet, it will call _decode_session6 to verify that the 
proper security was applied to the packet. However, this function does 
not set the protocol for the flow to anything (it just stays at 0), so 
no policy is matched in __xfrm_policy_check and the packet is dropped.

Has anybody been able to get such a setup to work? If I set the protocol 
value to 0 in the setkey policy, then it prevents the IKE negotiation 
from succeeding due to also matching ICMPv6 neighbor discovery. I did 
find a way specify the policies for ICMPv6 in such a way that does not 
cause racoon to match one of the ICMPv6 policies during negotiation, but 
I would prefer to not have to do this. It'd be best if I could just 
specify that all traffic over the tunnel interface should be protected, 
but there doesn't appear to be a way to do this currently. Any suggestions?

Thanks,
Brian Buesker