rfc9601v2.txt		rfc9601.txt
	skipping to change at line 269 ¶		skipping to change at line 269 ¶
	| not inspect within the encapsulation.		| not inspect within the encapsulation.
	|		|
	| For the avoidance of doubt, the above only concerns the outer IP		| For the avoidance of doubt, the above only concerns the outer IP
	| header. The ingress MUST NOT alter the ECN field of the arriving		| header. The ingress MUST NOT alter the ECN field of the arriving
	| IP header that will become the inner IP header.		| IP header that will become the inner IP header.
	|		|
	| In order that the network operator can comply with the above		| In order that the network operator can comply with the above
	| safety rules, an implementation of a tunnel ingress:		| safety rules, an implementation of a tunnel ingress:
	|		|
	| * MUST NOT treat the former Type of Service (ToS) octet (IPv4) or		| * MUST NOT treat the former Type of Service (ToS) octet (IPv4) or
	| the former Traffic Class octet (IPv6) as a single 8-bit field,		| the former Traffic Class octet (IPv6) as a single 8-bit field.
	| as the resulting linkage of ECN and Diffserv field propagation		| This is because the resulting linkage of ECN and Diffserv field
	| between inner and outer headers is not consistent with the		| propagation between inner and outer headers is not consistent
	| definition of the 6-bit Diffserv field in [RFC2474] and		| with the definition of the 6-bit Diffserv field in [RFC2474]
	| [RFC3260].		| and [RFC3260].
	|		|
	| * SHOULD be able to be configured to zero the ECN field of the		| * SHOULD be able to be configured to zero the ECN field of the
	| outer header.		| outer header.
	|		|
	| These last two rules apply even if an implementation of a tunnel		| These last two rules apply even if an implementation of a tunnel
	| ingress does not claim to support [RFC6040], [RFC4301], or the		| ingress does not claim to support [RFC6040], [RFC4301], or the
	| full functionality mode of [RFC3168]		| full functionality mode of [RFC3168]
	For instance, if a tunnel ingress with no ECN-specific logic had a		For instance, if a tunnel ingress with no ECN-specific logic had a
	configuration capability to refer to the last 2 bits of the old ToS		configuration capability to refer to the last 2 bits of the old ToS
	skipping to change at line 454 ¶		skipping to change at line 454 ¶
	in the Service Function Chaining (SFC) architecture [RFC7665]. A		in the Service Function Chaining (SFC) architecture [RFC7665]. A
	proposal has been made for the processing of ECN when handling		proposal has been made for the processing of ECN when handling
	transport encapsulation [SFC-NSH-ECN].		transport encapsulation [SFC-NSH-ECN].
	The specification of Geneve already refers to [RFC6040] for ECN		The specification of Geneve already refers to [RFC6040] for ECN
	encapsulation.		encapsulation.
	Section 3.1.11 of [RFC8085] already explains that a tunnel that		Section 3.1.11 of [RFC8085] already explains that a tunnel that
	encapsulates an IP header within a UDP/IP datagram needs to follow		encapsulates an IP header within a UDP/IP datagram needs to follow
	[RFC6040] when propagating the ECN field between inner and outer IP		[RFC6040] when propagating the ECN field between inner and outer IP
	headers. Section 3 updates [RFC6040] to clarify that its scope		headers. Section 3 of the present specification updates [RFC6040] to
	includes cases with a shim header between the IP headers. So it		clarify that its scope includes cases with a shim header between the
	indirectly updates the scope of [RFC8085] to include cases with a		IP headers. So it indirectly updates the scope of [RFC8085] to
	shim header as well as a UDP header between the IP headers.		include cases with a shim header as well as a UDP header between the
			IP headers.
	The requirements in Section 4 update [RFC6040], and hence indirectly		The requirements in Section 4 update [RFC6040], and hence also
	update the UDP usage guidelines in [RFC8085] to add the important but		indirectly update the UDP usage guidelines in [RFC8085] to add the
	previously unstated requirement that, if the UDP tunnel egress does		important but previously unstated requirement that, if the UDP tunnel
	not (or might not) support ECN propagation, a UDP tunnel ingress has		egress does not, or might not, support ECN propagation, a UDP tunnel
	to clear the outer IP ECN field to 0b00, e.g., by configuration.		ingress has to clear the outer IP ECN field to 0b00, e.g., by
			configuration.
	Section 9.5 of [RFC9329] already recommends the compatibility mode of		Section 9.5 of [RFC9329] already recommends the compatibility mode of
	[RFC6040] in this case because there is not a one-to-one mapping		[RFC6040] in this case because there is not a one-to-one mapping
	between inner and outer packets when TCP encapsulates IKE or IPsec.		between inner and outer packets when TCP encapsulates IKE or IPsec.
	6.1. Specific Updates to Protocols under IETF Change Control		6.1. Specific Updates to Protocols under IETF Change Control
	6.1.1. L2TP (v2 and v3) ECN Extension		6.1.1. L2TP (v2 and v3) ECN Extension
	The L2TP terminology used here is defined in [RFC2661] and [RFC3931].		The L2TP terminology used here is defined in [RFC2661] and [RFC3931].
	skipping to change at line 591 ¶		skipping to change at line 593 ¶
	When encapsulating data packets for any sessions created by that		When encapsulating data packets for any sessions created by that
	control connection, the tunnel initiator will then use the		control connection, the tunnel initiator will then use the
	compatibility mode of [RFC6040] to clear the ECN field of the outer		compatibility mode of [RFC6040] to clear the ECN field of the outer
	IP header to 0b00.		IP header to 0b00.
	If the tunnel terminator does not support this ECN extension, the		If the tunnel terminator does not support this ECN extension, the
	network operator is still expected to configure it to comply with the		network operator is still expected to configure it to comply with the
	safety provisions set out in Section 6.1.1.1 when it acts as an		safety provisions set out in Section 6.1.1.1 when it acts as an
	ingress LCCE.		ingress LCCE.
			If ECN support by the ingress and egress LCCEs is configured
			statically, as allowed in Section 6.1.1.2, they both ignore the
			presence or absence of any ECN capability AVP.
	6.1.2. GRE		6.1.2. GRE
	The GRE terminology used here is defined in [RFC2784]. GRE is often		The GRE terminology used here is defined in [RFC2784]. GRE is often
	used as a tightly coupled shim header between IP headers. Sometimes,		used as a tightly coupled shim header between IP headers. Sometimes,
	the GRE shim header encapsulates an L2 header, which might in turn		the GRE shim header encapsulates an L2 header, which might in turn
	encapsulate an IP header. Therefore, GRE is within the scope of		encapsulate an IP header. Therefore, GRE is within the scope of
	[RFC6040] as updated by Section 3.		[RFC6040] as updated by Section 3.
	Implementation of support for [RFC6040] as updated by the present		Implementation of support for [RFC6040] as updated by the present
	specification is RECOMMENDED for GRE tunnel endpoints in order to		specification is RECOMMENDED for GRE tunnel endpoints in order to
End of changes. 4 change blocks.
	14 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.48.