Preserve congestion feedback across the GRE shim
06RFC 9601 updates GRE’s treatment of Explicit Congestion Notification (ECN), the two congestion-signaling bits in an IP header.
Separate legacy/unknown-egress case: if possible, configure outer ECN00 (Not-ECT), while preserving the incoming inner ECT(0). DSCP remains a separate six-bit field.
Source for this drawing: RFC 9601 · Read RFC section 6.1.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RFC 9601 brings GRE IP tunnels within the clarified RFC 6040 ECN scope and adds safe configuration requirements for operators.
Read the updated RFC section ↗A GRE shim between two IP headers does not remove the need to propagate ECN safely.
- RFC 9601 section6.1.2 RECOMMENDS RFC 6040 ECN support for GRE IP tunnel endpoints. Its section6.1.2.1 requires operators to follow the safe configuration requirements in section4.
- For the default RFC 6040 normal ingress mode, a known-capable egress allows the incoming ECN field to be copied to the outer IP header; the inner field remains unchanged. ECT(0) means ECN-Capable Transport; CE means Congestion Experienced.
- Under the default RFC 6040 egress table, inner ECT(0) plus outer CE yields CE in the forwarded IP header. Inner Not-ECT plus outer CE MUST be dropped; Not-ECT means the inner transport is not ECN-capable.
- RFC 9601 section4 says that, if possible, ingress MUST be configured to zero outer ECN when egress behavior is unknown/non-ECN, or when an inner IP header might be hidden in a non-IP payload that ingress does not inspect. It MUST NOT change the arriving inner ECN field.
- Diffserv’s six-bit DSCP (Differentiated Services Code Point) and the two ECN bits MUST NOT be configured as one eight-bit field. The example does not claim that zeroing every outer ECN value alone is full RFC 6040 compliance.
These are bounded default IP-in-IP ECN examples from RFC 6040 sections4.1–4.3 as scoped by RFC 9601. IPv4 header checksum changes accompany ECN changes in a real implementation. Full ECN negotiation, L4S/PCN experiments, non-IP payload inspection and outer-fragment reassembly rules are outside this teaching helper.
Read RFC 9601 section 6.1.2 ↗