>	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.



>	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.

Anyway, as someone already observed: its premature.  For no, I will to
keep working on the inet6/ipsec code I already have. We can re-open
the topic once it's done.

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?

As soon as one starts asking those questions (and I know I am not the
first to pose them), then I think there's really very little technical
grounds for defending the status-quo-ante.  If we address those, using
a common prefix for inpcb/in6pcb is virtually a no-op.