Right. Thanks, David. > On 13 Nov 2017, at 11:16, David Schinazi <[email protected]> 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 <[email protected]> wrote: >> >> >> Yoav Nir <[email protected]> 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 <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
