How expensive is it to do a wildcard match? (I honestly don't know.) If it is expensive, it might be worth conditioning this on some global variable that tracks whether this is needed.

I'm thinking of how the kernel will perform in the case where someone floods a device with malicious ICMP messages.

style(9) nit: inp != NULL

Same question about the cost of the wildcard lookup. Also, here, it looks like the lookup is always done instead of only occurring if a local connection is not found.

(We could mimic the v4 behavior by having in6_pcbnotify() return an integer of the number of sockets notified. If that is 0, then we could run this code.)

style(9) nit: inp != NULL

Is there a potential race condition here, using an element of up after unlocking it? (It looks like the same thing happens in the v4 code, as well.)

Well consider that is done every time for any inbound UDP packet it better be cheap :-)

thanks got it.

Hmm but you might just send a notify up to a tunneled socket that is ignored that way. The point
here is we *want* anything going to that port going to the tunneled protocol period. Thus if
the wildcard finds it the ICMP belongs to the protocol thats tunneled.

The lookup costs had better be cheap, take a look inside that lookup function it does a *lot* of lookups.

Thanks got it!

And in all things having to do with tunneling. This is done on purpose since
we cannot hold the lock when we call into the tunneled protocol. I guess
the real question is do these things register/un-register themselves a lot and
if so do we make sure all other protocol state is cleaned up before un-registering?

The answer to that should be yes the state should be all cleaned up so I don't
think there is an issue. If we really felt it was I suppose in all places we could go
back in make a local variable, copy it out and then deref that,... this does work
by the way in all cases ... its being used (at least the non-icmp path) by SCTP in
a *lot* of pounding that Michael T (and myself occasionally) do to SCTP...

Spaces around | are inconsistent.

Two spaces between ) and ||.

Trailing whitespace.

Trailing whitespace.

Got it :-)

fixed in next rev