Skip to main content

9.1.1 The Limited-functionality and Full-functionality Options

9.1.1 The Limited-functionality and Full-functionality Options

The limited-functionality option for ECN encapsulation in IP tunnels is to set the not-ECT codepoint in the outer (encapsulating) header, regardless of the value of the ECN field in the inner (encapsulated) header. With this option, the ECN field in the inner header is not changed at decapsulation. The disadvantage of this approach is that the flow has no ECN support for the part of the path using the IP tunnel, even if the encapsulated packet (from the original TCP sender) is ECN-capable. That is, if the encapsulated packet arrives at a congested ECN-capable router, and the router can decide to drop or mark the packet as a congestion indication to the end nodes, the router will not be allowed to set the CE codepoint in the packet header, but must drop the packet instead.

The full-functionality option for ECN encapsulation is that at encapsulation, the inner header's ECN codepoint is copied to the outer header if the inner header is not-ECT or ECT, and the outer header's ECN codepoint is set to ECT(0) if the inner header's ECN codepoint is CE. At decapsulation, if the CE codepoint is set on the outer header, then the CE codepoint is also set on the inner header. Otherwise, the ECN codepoint on the inner header remains unchanged. That is, for full ECN support, the encapsulation and decapsulation processing involves the following: At tunnel entrance, the full-functionality option sets the ECN codepoint in the outer header. If the ECN codepoint in the inner header is not-ECT or ECT, it is copied to the ECN codepoint in the outer header. If the ECN codepoint in the inner header is CE, the ECN codepoint in the outer header is set to ECT(0). At decapsulation at tunnel exit, if the CE codepoint is set in the outer header, the full-functionality option sets the CE codepoint in the inner header. Otherwise, no change is made to this field of the inner header.

With the full-functionality option, flows can take advantage of ECN for the part of the path that may use IP tunnels. From a security perspective, the disadvantage of the full-functionality option is that IP tunnels cannot protect flows from certain modifications to the ECN bits in the IP header within the tunnel. Sections 18 and 19 describe in detail the potential hazards of modifying the ECN bits in the IP header.

(1) IP tunnels MUST modify the processing of the DS field byte at IP tunnel endpoints by implementing either the limited-functionality or full-functionality option.

(2) Optionally, IP tunnels MAY enable the IP tunnel endpoints to negotiate a choice between the limited-functionality and full-functionality options for ECN in tunnels.

The minimum required to make ECN available for IP tunnels is the limited-functionality option, which prevents ECN from being enabled in the outer header of the tunnel. Full support for ECN requires use of the full-functionality option. If there is no optional mechanism for tunnel endpoint negotiation to choose between the limited-functionality or full-functionality options, there can be a pre-existing agreement between tunnel endpoints on whether to support the limited-functionality or full-functionality ECN option.

All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option.

In addition, it is RECOMMENDED that if the tunnel egress point of a tunnel using the limited-functionality option receives a packet with the CE codepoint set in the outer header, or if the tunnel egress point of a tunnel using the full-functionality option but with the not-ECT codepoint set in the inner header receives such a packet, these packets SHOULD be dropped. This is driven by backward compatibility and to ensure that unauthorized modifications to the ECN field do not occur, which will be discussed further in the next section (9.1.2).