RFC 6040: Tunnelling of Explicit Congestion Notification
In plain English — editorial summary, not part of the RFC
This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]
Document record
- Document ID
- RFC6040
- Published
- November 2010
- Authors
- B. Briscoe
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- wit
- Pages
- 35
- Also known as
- —
- Updated by:
- RFC 9601
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9599Guidelines for Adding Congestion Notification to Protocols that Encapsulate IPCurrent
August 2024
- RFC 9768More Accurate Explicit Congestion Notification (AccECN) Feedback in TCPCurrent
April 2026
- RFC 6660Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)Current
July 2012
- RFC 2401Security Architecture for the Internet ProtocolObsoleted
November 1998
- RFC 4835Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)Obsoleted
April 2007
- RFC 4306Internet Key Exchange (IKEv2) ProtocolObsoleted
December 2005
- RFC 4305Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)Obsoleted
December 2005
- RFC 4303IP Encapsulating Security Payload (ESP)Current
December 2005
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?