Skip to main content

12. Summary of changes required in IP and TCP

12. Summary of changes required in IP and TCP​

This document specifies the use of two bits in the IP header for ECN. The not-ECT codepoint indicates that the transport protocol will ignore the CE codepoint. This is the default value for the ECN codepoint. The ECT codepoint indicates that the transport protocol is willing and able to participate in ECN.

A router sets the CE codepoint to indicate congestion to the end nodes. The CE codepoint in a packet header MUST NOT be reset by a router.

TCP requires three changes for ECN, one setup phase and two new flags in the TCP header. The ECN-Echo flag is used by the data receiver to inform the data sender of the receipt of a CE packet. The Congestion Window Reduced (CWR) flag is used by the data sender to inform the data receiver that the congestion window has been reduced.

When ECN (Explicit Congestion Notification) is used, it is required that congestion indications that arise inside an IP tunnel not be lost at the tunnel egress. We specify minor modifications to the IP protocol's processing of the ECN field during encapsulation and decapsulation to allow flows that are experiencing IP tunnel transit to use ECN.

Two options are specified for ECN in tunnels:

  1. The limited-functionality option, which does not use ECN inside the IP tunnel, by setting the ECN field in the outer header to not-ECT, and not changing the inner header at decapsulation.

  2. The full-functionality option, which sets the ECN field in the outer header to not-ECT or to one of the ECT codepoints, depending on the ECN field in the inner header. At decapsulation, if the CE codepoint is set in the outer header and the inner header is set to one of the ECT codepoints, then the CE codepoint is copied to the inner header.

For IPsec tunnels, this document also defines an optional IPsec Security Association (SA) attribute that enables negotiation of ECN usage within IPsec tunnels, and an optional field in the Security Association Database to indicate whether ECN is permitted in tunnel mode on an SA. The changes needed for IPsec tunnels using ECN modify RFC 2401 [RFC2401], which defines the IPsec architecture and specifies certain aspects of its implementation. The new IPsec SA attribute is an addition to the attributes already defined in Section 4.5 of [RFC2407].

This document obsoletes RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet community. The rest of this section describes the relationship between this document and its predecessor.

RFC 2481 included a brief discussion of the use of ECN with encapsulated packets, and noted that with the IPsec specifications at that time (January 1999), flows could not safely use ECN if they would traverse an IPsec tunnel. RFC 2481 also described the changes that could be made to the IPsec tunnel specifications to make them compatible with ECN.

This document also incorporates work completed after RFC 2481. First was the detailed description of changes to IPsec tunnels, and extensive discussion of the security implications of ECN (now included as Sections 18 and 19 of this document). Second was the extension of the discussion of IPsec tunnels to cover all IP tunnels. Because older IP tunnels are incompatible with flows' use of ECN, the deployment of ECN in the Internet will create strong pressure for older IP tunnels to be updated to ECN-compatible versions, using either the limited-functionality or full-functionality option.

This document does not address the issues of including ECN in non-IP tunnels such as MPLS, GRE, L2TP, or PPTP. An early preliminary document on adding ECN support to MPLS was not advanced.

A third addition after RFC2481 is the description of ECN procedures for retransmitted packets, namely that the ECT codepoint SHOULD NOT be set on retransmitted packets. The motivation for this additional specification is to eliminate a possible avenue of Denial of Service attack to existing TCP connections. Some previously deployed ECN-capable TCPs might not conform to the (new) requirement of not setting the ECT codepoint on retransmitted packets; we believe that this will not cause significant problems in practice.

This document also slightly expands the specification of ECN negotiation using the SYN packet. While some previously deployed ECN-capable TCPs might not conform to the requirements specified in this document, we believe that this will not cause any performance or compatibility problems for TCP connections with TCP implementation combinations of endpoints.

This document also includes the specification of the ECT(1) codepoint, which could be used by TCP as part of implementing the ECN nonce.

Last updated on