Subject: [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 10 May 2021 13:36:29 +0000

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.

---

From: [email-masked]
Date: Mon, 10 May 2021 16:40:00 +0200

Hi Éric,

My reading of the current RFC6333 text is that it is trying to highlight the importance of not fragmenting the IPv4 packet before encapsulation as this will break things. This, combined with ‘… after the encapsulation of the IPv6 packet.’ which should certainly be ‘… of the IPv4 packet.’ Is where the confusion is from.

So, as a minimum, the errata is correct regarding the encapsulated IP version.

Beyond that, I don’t find the remaining text to conflict with RFC2743 section 7.2. The text is only covering how to deal with packets that you will encapsulate and forward (DF=0) - case (b) in the RFC2473 text. Case (a) - DF=1 for received packet, so drop and send ICMP error isn’t discussed as these packets will not be encapsulated and need to be fragmented.

I do agree that this is open to misreading. How about the following wording to preserve (what I think is) the authors intention:

>    fragmented.  For packets forwarded by the B4 element, fragmentation
          MUST happen after the encapsulation of the IPv4 packet.  Reassembly
    MUST happen before the decapsulation of the IPv4 packet.  A detailed
    procedure has been specified in [RFC2473]
>    Section 7.2.

From Mikael’s comment:
"RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or drop+send ICMP error."

I can’t find anything in the Section 7.2 text that would result in inner fragmentation.

Thanks,
Ian

> On 10. May 2021, at 15:36, Eric Vyncke (evyncke) <evyncke=[email-masked]> wrote:
> 
> Mikael Abrahamsson filed an erratum https://www.rfc-editor.org/errata/eid5847 <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.
>  
>              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>.
>  
> _______________________________________________
> Softwires mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>

---

From: Joseph Touch <[email-masked]>
Date: Mon, 10 May 2021 09:27:38 -0700

Hi, all,

Draft-ietf-intarea-tunnels describes the flaws in RFC 2473:

   o  IPv6 tunnels [RFC2473 <https://datatracker.ietf.org/doc/html/rfc2473>] -- IPv6 or IPv4 in IPv6

*      o Treats tunnel MTU as tunnel path MTU, not tunnel egress MTU

       o Decrements transiting packet hopcount (by 1)

       o Copies traffic class from tunnel link to tunnel transit header

       o Ignores IPv4 DF=0 and fragments at that layer upon arrival

       o Fails to retain soft ingress state based on inner ICMP messages
          affecting tunnel MTU

*      o Tunnel ingress issues ICMPs

       o Fragments IPv4 over IPv6 fragments only if IPv4 DF=0
          (misinterpreting the "can fragment the IPv4 packet" as
          permission to fragment at the IPv6 link header)

I’ve starred (*) the points relevant to the discussion below here.

A tunnel is a link, not unlike any other link. It has an MTU - the size of the largest packet that can traverse the tunnel. NOT the largest packet that can traverse the tunnel without fragmentation (or refragmentation, in the case of IPv4 with DF=0). If that were the case, ATM links would have MTUs of 48 bytes, not 9K.

Tunnel ingresses have no business issuing ICMPs. That’s the job of the router or host to which a tunnel is attached. If a packet arrives at a router/host for an interface (tunnel) that is too small, it is the router/host that issues the ICMP before the tunnel should ever see it.

If tunnel specs would “stay in their lane” and stop trying to describe how the router where they attach works, this would all be a LOT simpler.

Joe

> On May 10, 2021, at 7:40 AM, [email-masked] wrote:
> 
> Hi Éric,
> 
>> On 10. May 2021, at 15:36, Eric Vyncke (evyncke) <evyncke=[email-masked] <mailto:evyncke=[email-masked]>> wrote:
>> 
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: <[email-masked]>
Date: Tue, 11 May 2021 06:48:37 +0000

Hi all,

I agree with Ian.

Actually, the document should use a similar wording in both the section mentioned in the errata report and the one in of 6.3. I’m afraid editorial changes are also needed for 6.3 to avoid any confusion.

(1) 5.3:

OLD:

                                                                  ^^^^^^

   ^^^^^^^^^^

   ^^^^^^^^^^^^

   Section 7.2.

NEW:

   fragmented.  Fragmentation MUST happen after the IPv6 encapsulation.

                                                    ^^^^

   Reassembly MUST happen before the decapsulation of the

   of the IPv6 header.  A detailed procedure has been specified in [RFC2473]

   ^^^^^^^^^^^^^^^^^^

   Section 7.2.

(2) 6.3

OLD:

   As noted previously, fragmentation and reassembly need to be taken

   care of by the tunnel endpoints.  As such, the AFTR MUST perform

   fragmentation and reassembly if the underlying link MTU cannot

   accommodate the encapsulation overhead.  Fragmentation MUST happen

   after the encapsulation on the IPv6 packet.  Reassembly MUST happen

                           ^^^^^^^^^^^^^^^^^^

   before the decapsulation of the IPv6 header.  A detailed procedure

   has been specified in [RFC2473] Section 7.2<https://datatracker.ietf.org/doc/html/rfc2473#section-7.2>.

NEW:

   As noted previously, fragmentation and reassembly need to be taken

   care of by the tunnel endpoints.  As such, the AFTR MUST perform

   fragmentation and reassembly if the underlying link MTU cannot

   accommodate the encapsulation overhead.  Fragmentation MUST happen

   after the IPv6 encapsulation.  Reassembly MUST happen^

             ^^^^

   before the decapsulation of the IPv6 header.  A detailed procedure

   has been specified in [RFC2473] Section 7.2<https://datatracker.ietf.org/doc/html/rfc2473#section-7.2>.

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 10 mai 2021 16:40
À : Eric Vyncke (evyncke) <evyncke=[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

Hi Éric,

From Mikael’s comment:

Thanks,
Ian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 17 May 2021 07:50:15 +0000

Thank you Ian, Joe, and Med for your feedback on this errata. I will propose the text fix as proposed by Ian (Med’s suggestion is a paraphrase)

Med, would you mind opening a new errata for the section 6.3, which has the same problem as noticed by Mikael ? Thank you

-éric

From: "[email-masked]" <[email-masked]>
Date: Tuesday, 11 May 2021 at 08:49
To: "[email-masked]" <[email-masked]>, Eric Vyncke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

Hi all,

I agree with Ian.

(1) 5.3:

OLD:

                                                                  ^^^^^^

   ^^^^^^^^^^

   ^^^^^^^^^^^^

   Section 7.2.

NEW:

                                                    ^^^^

   ^^^^^^^^^^^^^^^^^^

   Section 7.2.

(2) 6.3

OLD:

                           ^^^^^^^^^^^^^^^^^^

NEW:

             ^^^^

Cheers,
Med

Hi Éric,

From Mikael’s comment:

Thanks,
Ian

Thank you.