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
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
Regards,
xing
ps. Pretty much everything on the internet is incompatible with
ICMP-based PMTU discovery, unfortunately.
Rémi Després ??:
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
