Right. Thanks, David. > On 13 Nov 2017, at 11:16, David Schinazi <dschin...@apple.com> wrote: > > 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 >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
