FYI:
Text from the page 8 of the divi-pd draft (individual submission for the
stateless double transation, which is renamed to MAP-T, before the WG
adoption) http://www.ietf.org/archive/id/draft-xli-softwire-divi-pd-01.txt
Due to the differences between the IPv4 header and the IPv6 header,
the dual stateless IPv4/IPv6 translation cannot be entirely lossless
[RFC6145], for example the IPv4 options are lost. The experimental
data shows that the IPv4 packets which contain options are very few
(10e-6) and causes no harm. Another corner case is the fragmentation
handling. For IPv4 packets with DF=1 and MF=1, the dual stateless
translation will results in DF=0. The experimental data shows that
the IPv4 packets with DF=1 and MF=1 are very few (10e-5) and causes
no harm.
Additional information:
The CERNET BR/CPE code has a configuration function which has the
feature of
"For the packets contains DF=1&MF=1, MAP-T MAY encapsulate the packets
using RFC2473, and this will make MAP-T compatible with ICMP-based PMTU
discovery."
Frankly speaking, we never turn this option on in the real services,
since the users cannot tell the difference between on/off of this
configuration function.
Regards,
xing
.
Rémi Després ??:
Hi Xing,
15 nov. 2014 12:33, Xing Li <[email protected]
<mailto:[email protected]>> :
This is a very corner case (DF=1&MF=1), and it has been discussed in
page 8 (DF=1&MF=1) in
http://www.ietf.org/proceedings/83/slides/slides-83-softwire-11.pdf
Showing a statistic where use of MF=DF=1 has been very limited doesn’t
change that MF=DF=1 is what is recommended in RFC4821 for deployment
of Path MTU Discovery. The RFC does say:
/"All hosts SHOULD use IPv4 fragmentation in a mode that mimics IPv6
functionality. All fragmentation SHOULD be done on the host, and all
IPv4 packets, including fragments, SHOULD have the DF bit set such
that they will not be fragmented (again) in the network."/
and if people really want to address this corner case (DF=1&MF=1),
MAP-E can be used (only for the packets with DF=1&MF=1) without any
problem, as shown in (the mixed mode)
page 6 of
http://www.ietf.org/proceedings/84/slides/slides-84-softwire-5.ppt
I didn’t understand that the "Mixed MAP-T/MAP-E" mode was included in
available drafts.
Anyway, be it included or not, it remains that any use of MAP-T breaks
the DF=MF=1 combination of RFC4821, and therefore ICMP-independent
Path MTU discovery.
Regards,
xing
ps. Pretty much everything on the internet is incompatible with
ICMP-based PMTU discovery, unfortunately.
As already answered to Ted, the PMTU discovery of RFC4821 is precisely
that which is designed not to depend on ICMP.
That’s why breaking is in no way negligible.
Regards,
RD
15 nov. 2014 01:40, Ted Lemon <[email protected]> :
On Nov 14, 2014, at 12:22 PM, Rémi Després <[email protected]> wrote:
If this is acceptable to whoever wants to deploy MAP-T, in due knowledge of its experimental status, it is not AFAIK acceptable in a standard.
I do hear your point, Rémi.
Understanding in what MAP-T is incompatible with IPv4 PMTU discovery is then
progressing.
But, as shown below, your understanding of the point isn’t complete yet.
However, the problem actually exists in RFC 6145, not in this document, and RFC 6145 is a standards track document.
Misunderstanding of yours: the problem does not exist in RFC6145:
- With the single translation of RFC6145, an IPv4 packet which is sent with DF=1
(as needed for PMTUD of RFC4821) will never be fragmented (neither before nor
after translation). This is simply because IPv6 routers never fragment packets.
=> RFC4821 isn’t broken by RFC6145
- That is double translation that brings the problem: an IPv4 packet sent with
DF=1 (as needed for RFC4821) can be fragmented after being translated back to
IPv4. => RFC4821 is broken by MAP-T.
Also, this is a topic that the working group discussed and considered addressed
long before the coin toss.
It is clear that real understanding of this point isn’t widely shared. (Even in
your case, you needed to ask a number of clarifications).
That’s what makes this contribution worth doing: decisions have to be made with
consciousness of significant facts.
So I think this counts as re-raising an issue that was previously addressed,
and not as an issue that would have any bearing on the current discussion.
IMHO, a clear explanation of this contradiction between MAP-T and PMTU discovery of RFC4821 should be present in the draft itself.
If I stopped spending energy to try and get it, it is because I felt a strong preference of MAP-T authors for keeping it concealed, and I had to move to other activities.
Why then does the issue comes now?
Because it is now that a proposal comes to promote MAP-T from experimental to standard.
I am sorry that this contribution goes against a smooth and easy acceptance of
an IESG goof faith proposal, but significant facts need to be known.
Regards,
RD
PS: As this discussion continues, and as you didn’t answer my question about
when the IESG should be informed, I hope you won’t find inappropriate my
opening the channel now.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
