let us switch to tech-net.

> >> Can you please defer chagne the inpcb6* to an struct socket*, until
> >> after that review?
> >	sorry no, i will change it to struct socket * now.  
> Then I reserve the right to revert to passing inpcb6* at some later
> date, shuold that be the appropriate thing to do.
 
	i don't think so.  it is you who first committed things ignoring
	others' comment.

> 	with your commit
> >	you *broke* KAME IPsec policy checking for the case where IPv4 mapped
> >	address is used on AF_INET6 socket.
> Can you explain just how the code is ``broken''?  The previous code
> took an in6pcb, followed the pointer to the struct socket*, and passed
> the struct socket* via the set_socket() kludge.  The code I checked in
> simply passes the same in6pcb* which the KAME code started with to
> ip6_output() as an explicit argument. Then, ip6_output() immediately
> follows the *VERY SAME* pointer, to obtain the struct socket* it used
> to receive via the aux-mbuf/packet-tag.

	for instance in tcp_output we pass "so" directly to ip6_output
	or ip_output by ipsec_setsocket().  therefore we can support TCP over
	both IPv4/v6 cases.  with your change which passes in6pcb to ip6_output
	and NULL to ip_output, TCP over IPv4 (via IPv4 mapped address) will
	not use IPsec policy on in6pcb.

> Interally, ip6_output() and the KAME ipsec code continues to use the
> struct socket *.  There is effectively change to the struct socket*
> seen by the KAME-code internals. I dont see how that will break
> anything, which wasn't already broken before.

	if you did not comment out ipsec_getsocket(), i wouldn't object this
	vocally.

> Why do you think the code needs to be changed immediately?
> Is there a corner case which I missed?

	see above.

itojun