[Swan-dev] FYI, IKEv2's next payload dance no longer needed;

[D. Hugh Redelmeier]

I've not looked at the code.  But that won't stop me commenting :-)

I think that this change is a good idea.

One advantage of the old code was that the logging of the outgoing payload 
displayed the correct next payload field.  For that reason, I'd only use 
the new mechanism when it saves code (i.e. when the field requires 
computation).  That computation is error-prone since it (usually) 
duplicates, with some chance of error, some other logic.

| ft_mnp:
|     save the message header's next payload field location in the
| message digest, ready for ...

| ft_pnp:
|     find the message digest (it contains the last next payload location)
|     if needed, set the saved (now previous) next payload field to this
| payload's type
|     else check things are somewhat sane
|     save this payload's next payload field location in the message's
| digest, mix, repeat

I think that this state belongs in the pb_stream.  After all, payloads
can nest.  Also there is no requirement for them to be associated with a 
message digest.

| #include rant about how the next payload field in the RFC was such a bad idea

The design was to enable faster parsing by hardware.  I'm guessing it has 
something to do with pipelining.