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:
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.
NEW:
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 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 protected]] De la part de [email protected]
Envoyé : lundi 10 mai 2021 16:40
À : Eric Vyncke (evyncke) <[email protected]>
Cc : [email protected]; [email protected]
Objet : Re: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite
Broadband Deployments Following IPv4 Exhaustion"
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:
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. 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
_________________________________________________________________________________________________________________________
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.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
