{"draft":"draft-ietf-tsvwg-ecn-tunnel-10","doc_id":"RFC6040","title":"Tunnelling of Explicit Congestion Notification","authors":["B. Briscoe"],"format":["ASCII","HTML"],"page_count":"35","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Transport and Services Working Group","abstract":"This document redefines how the explicit congestion notification\r\n(ECN) field of the IP header should be constructed on entry to and\r\nexit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168\r\nto bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301\r\nIPsec ECN processing.  On decapsulation, it updates both RFC 3168 and\r\nRFC 4301 to add new behaviours for previously unused combinations of\r\ninner and outer headers.  The new rules ensure the ECN field is\r\ncorrectly propagated across a tunnel whether it is used to signal one\r\nor two severity levels of congestion; whereas before, only one\r\nseverity level was supported.  Tunnel endpoints can be updated in any\r\norder without affecting pre-existing uses of the ECN field, thus\r\nensuring backward compatibility.  Nonetheless, operators wanting to\r\nsupport two severity levels (e.g., for pre-congestion notification --\r\nPCN) can require compliance with this new specification.  A thorough\r\nanalysis of the reasoning for these changes and the implications is\r\nincluded.  In the unlikely event that the new rules do not meet a\r\nspecific need, RFC 4774 gives guidance on designing alternate ECN\r\nsemantics, and this document extends that to include tunnelling\r\nissues.  [STANDARDS-TRACK]","pub_date":"November 2010","keywords":["[--------]","Congestion Control and Management","Congestion Notification","Information Security","Tunnelling","Encapsulation","Decapsulation","Protocol","ECN","IPsec"],"obsoletes":[],"obsoleted_by":[],"updates":["RFC3168","RFC4301","RFC4774"],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC6040","errata_url":null}