Dear ex-softwires WG, dear int-area WG,
Mikael Abrahamsson filed an erratum https://www.rfc-editor.org/errata/eid5847
in August 2019 (after the softwires WG closure) and, as the past responsible AD
for softwires, I would like to fix this erratum but as Mikael I have no idea
about the correction.
My own take is that the normative text in RFC 6333 indeed violates RFC 2473 for
when the IPv4 DF is set... RFC 2473 appears to me as sensible and I would
prefer to keep this behavior, i.e., see my suggestion below.
Than you in advance for your comments and suggestions,
Regards
-éric
-- Existing text in RFC 6333 –
Section 5.3 says:
However, as not all service providers will be able to increase their
link MTU, the B4 element MUST perform fragmentation and reassembly if
the outgoing link MTU cannot accommodate the extra IPv6 header. The
original IPv4 packet is not oversized. The packet is oversized after
the IPv6 encapsulation. The inner IPv4 packet MUST NOT be
fragmented. Fragmentation MUST happen after the encapsulation of the
IPv6 packet. Reassembly MUST happen before the decapsulation of the
IPv4 packet. A detailed procedure has been specified in [RFC2473]
Section 7.2.
-- Comment by erratum submitter –
I do not have a corrected text. The above text doesn't say what RFC2473 section
7.2 says, so... what should it be? RFC2473 7.2 says to use the DF bit and
decide whether to inner fragment or drop+send ICMP error. The above text seems
to make normative statements that counter at least the DF=1 case in RFC2473
7.2. Also the text above says "Fragmentation MUST happen after the
encapsulation of the IPv6 packet.". The IPv6 packet isn't encapsulated, so that
sentence should be changed?
-- Section 7.2 of RFC 2473 ---
When an IPv4 original packet enters a tunnel, if the original packet
size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
entry-point and the tunnel exit-point, minus the size of the tunnel
header(s)), it is handled as follows:
(a) if in the original IPv4 packet header the Don't Fragment -
DF - bit flag is SET, the entry-point node discards the
packet and returns an ICMP message. The ICMP message has
the type = "unreachable", the code = "packet too big", and
the recommended MTU size field set to the size of the
tunnel MTU - see sections
6.7<https://datatracker.ietf.org/doc/html/rfc2473#section-6.7> and
8.3<https://datatracker.ietf.org/doc/html/rfc2473#section-8.3>.
(b) if in the original packet header the Don't Fragment - DF -
bit flag is CLEAR, the tunnel entry-point node encapsulates
the original packet, and subsequently fragments the
resulting IPv6 tunnel packet into IPv6 fragments that do
not exceed the Path MTU to the tunnel exit-point.
-- Suggested new text by Éric Vyncke –
However, as not all service providers will be able to increase their
link MTU, the B4 element MUST perform fragmentation and reassembly if
the outgoing link MTU cannot accommodate the extra IPv6 header. The
original IPv4 packet is not oversized. The packet is oversized after
the IPv6 encapsulation. The detailed procedure specified in [RFC2473]
Section 7.2 MUST be executed by the B4 element.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
