Christian Hopps <cho...@chopps.org> writes:
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:
[slight grammar fix] [[RFC3168]] and [[RFC4301]] define behaviors for marking ECN based on the ingress and egress of the 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.
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
