>>	SCTP pcb has multiple pair of addresses, therefore inpcb cannot support
>>	it.  i guess i made it clear in the previous message.  could you tell
>>	me how you would support SCTP with your approach?
>
>I have not seen your stcp code, and its been some while since I saw
>Randy et al.'s. But I would start (as I said) by having a *common
>prefix* in the pcb's of all transport layers that require IPsec; and
>move common header fields and the IPsec-relevant state variables into
>that common header.
>
>The SCTP addresses themselves can be obtained from the packet.
>
>Again, what I proposed Friday (and since) is in fact, a common prefix.
>Objections to using the  current struct inpcb as-is are a strawman.

	how can you associate sctp_pcb (which contains multiple pair of
	addresses) with multiple cached policies for each pairs?  i guess
	you can't.

>>	i beg to differ.  unfortunately we use layer 4 information (inpcb or
>>	sctp_pcb) to hold ipsec policy information, therefore, there needs
>>	to be some information grabbed by IPsec code from there.  
>
>>	to pass pointer to such layer 4 information, socket * is better.
>
>No, again, this is just plain wrong.  Retreating all the way to the
>socket layer, to find transport-level-specific state which, in turn,
>is needed by IPsec, is bad style.
>
>If the lower-layer (here, IPsec) needs to have state in common across
>different higher-level protocols, then its *better* to make that state
>actually be shared.

	this point we can't seem to find an agreement.

>Soon, though, I propose to ask the question the other way round:
>from a NetBSD perspective, why *not* clean up the bogosity in the
>current struct in6pcb? Why *not* use a hash-table for v6?  Why *not*
>use <sys/queue.h> for lists (&c) of in6pcbs?

	i will fix this issue soon, however, remember it will increase my pain
	on kame-and-netbsd synchronization substantially.

itojun