I suspect that there was a typo and Yoav meant to include the flags for proposal 2:
| Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits) | In that case I do prefer option 2 as it doesn't add much complexity and allows fragmentation. David > On Nov 13, 2017, at 10:51, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Yoav Nir <ynir.i...@gmail.com> wrote: >> Proposal #1: >> ========== >> | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| > >> And use IIV only for regular Encrypted Payload, not for Encrypted >> Fragment. The reasoning is that if you use fragmentation you’ve >> already solved the message-too-big issue. > >> The Flags octet includes the I(nitiator) and R(esponse) bits, which >> differentiate the cases that are not related to fragmentation. > >> Proposal #2: >> ========== >> | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 >> bits)| > >> The Fragment Counter is the same as in the RFC 7383 fragment payload, >> or zero if we are using the regular encrypted payload. > > I think that #2 does a better job. > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
