Search RFCs

RFC Editor

File formats:

Status:

PROPOSED STANDARD

Updates:

RFC 3168,RFC 4301,RFC 4774

Updated by:

RFC 9601

Author:

B. Briscoe

Stream:

IETF

Source:

tsvwg (wit)

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC6040

Discuss this RFC: Send questions or comments to the mailing listtsvwg@ietf.org

Other actions:Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 6040

Abstract

This document redefines how the explicit congestion notification(ECN) field of the IP header should be constructed on entry to andexit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301IPsec ECN processing. On decapsulation, it updates both RFC 3168 andRFC 4301 to add new behaviours for previously unused combinations ofinner and outer headers. The new rules ensure the ECN field iscorrectly propagated across a tunnel whether it is used to signal oneor two severity levels of congestion; whereas before, only oneseverity level was supported. Tunnel endpoints can be updated in anyorder without affecting pre-existing uses of the ECN field, thusensuring backward compatibility. Nonetheless, operators wanting tosupport two severity levels (e.g., for pre-congestion notification --PCN) can require compliance with this new specification. A thoroughanalysis of the reasoning for these changes and the implications isincluded. In the unlikely event that the new rules do not meet aspecific need, RFC 4774 gives guidance on designing alternate ECNsemantics, and this document extends that to include tunnellingissues. [STANDARDS-TRACK]

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.