Paul Wouters writes: > 3.3.1. Proposal Substructure > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 (last) or 2 | RESERVED | Proposal Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Proposal Num | Protocol ID | SPI Size |Num Transforms| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ SPI (variable) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ <Transforms> ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Proposal Substructure > > o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the > last Proposal Substructure in the SA. This syntax is inherited > from ISAKMP, but is unnecessary because the last Proposal could be > identified from the length of the SA. The value (2) corresponds > to a payload type of Proposal in IKEv1, and the first four octets > of the Proposal structure are designed to look somewhat like the > header of a payload. > > > It's a little confusing to me whether the first octet should be > interpreted as a "flags" field with two (of eight) bit flags assigned > or as a single octet that can have two values (0 or 2) and it will never > get updated to contain other values.
It is one octect, and it used to have name called Next Payload, but as we use that already in the IKEv2 we do not want to reuse it here. The text quite clearly says "1 octect", which indicates it is not bitfield or flags, but one byte having values of 0 or 2. > Are we ever planning on having values other then 0 or 2 ? No. > If a byte, could we give this byte a "name" like we have done for the other > proposal pieces? 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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
