On Tue, 29 Oct 2013, Tero Kivinen wrote:
The text quite clearly says "1 octect", which indicates it is not
bitfield or flags, but one byte having values of 0 or 2.
It does say that clearly, but I wanted to confirm it was not a mistake,
Are we ever planning on having values other then 0 or 2 ?
No.
Ok good.
I think the name was explictly removed to make it clear that we do not
assume this to be Next Payload structure of the embedded payloads
having embedded payloads. Same thing with the Transforms substructure.
If bits, could we give this octet a name (proposal flags) and these bits names?
(bit 0 being reserved and MUST be 0, bit 1 being "non-last proposal")
I do not think we want to change this part of the text. The text tells
that this was supposed to look somewhat like the header of the
payload and I think that should make the payload clear enough.
Implementors still need to name that struct. Instead of everyone coming
up with their own name it would be good to have a standard name for it.
For example, the reason I'm looking at this was because the openswan
implementation actually called the struct isap_np and when it failed to
map an IKEv2 next payload type to it, failed. Libreswan is now calling
it isap_lp for "last proposal" and it will no longer accept IKEv1 next
payload types, which openswan was doing.
In a way, I think we did a disservce to implementors by re-using these
values and clunking it into ikev1 values. It may lead to other ikev1
values (eg for Next Payload Type) bleeding into ikev2 by accident by
agile implementors :P
So just naming it in the RFC like we do for the other IKEv2 proposal
fields would be useful. I would suggest "last payload".
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
