> On Aug 24, 2022, at 04:28, Lars Eggert <l...@eggert.org> wrote:
>
>>> ### Section 3.1, paragraph 0
>>> ```
>>> 3.1. ECN Support
>>> ```
>>> There is a lot more nuance to this, as described in RC6040. This document
>>> needs
>>> to follow that existing standard rather than define another variant.
>>
>> We reference RFC3168 which talks directly to handling ECN with IPsec
>> security associations. We are not defining a new variant. I see that RFC6040
>> updates the RFCs we reference so we perhaps should add that reference here
>> as well?
>
> It's not just adding the reference. RFC6040 specifies how ECN applies to
> tunnels, including this tunnel, so it needs to be followed here (or there
> needs to be a solid rationale/discussion about which aspects are not being
> followed and why.)
I've changed the ECN section text on marking to:
[[RFC3168]] and [[RFC4301]] define behaviors for marking ECN for based on the
ingress and egress inner packet. These RFCs were later updated by
[[RFC6040]]. The methods defined in [[RFC6040]] SHOULD be followed with the
addition that if multiple inner packets are being encapsulated in an
AGGFRAG mode outer packet the ECN value from a congestion indicating
packet should be the source of the copied value.
Thanks,
Chris.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
