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. |