Re: [Softwires] map-t to proposed standard rather than experimental

Hi Xing,

15 nov. 2014 12:33, Xing Li <xing@cernet.edu.cn>  :

> 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 <Ted.Lemon@nominum.com> :
>> 
>>   
>>> On Nov 14, 2014, at 12:22 PM, Rémi Després <despres.remi@laposte.net> 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
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
>> 
>>   
> 