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

[Rémi Després <[e-mail]>]

14 nov. 2014 20:35, Ted Lemon <[e-mail]> :

> On Nov 14, 2014, at 12:49 AM, Rémi Després <[e-mail]> wrote:
>> - Only MAP-T lacks transparency to the IPv4 DF bit. 
> 
> So your concern is that if fragmentation at the translator results in an IPv6 packet that is larger than the MTU of the IPv6 path between the 4->6 translator and the 6->4 translator, fragmentation will not occur?

The opposite. With a DF=1 according to RFC4821, fragmentation can occur while it shouldn’t.

For instance, if a DF=MF=1 packet traverses a MAP-T domain without being fragmented in it, and is too long for a link MTU further downstream, it will be fragmented. This is contrary to what is required by DF=1. 
Consequently, the packet is accepted, and acknowledged, while il should have  being lost (and not acknowledged).
The transmitter looses the expected warning that it may have to reduce its transmit MTU;

>   This would result in a packet too big ICMP message being sent back to the translator, which would then use a lower MTU in making its fragmentation decision on the next packet.
> 
> So I guess your concern is that the problem is that in this case the specific packet that was dropped due to IPv6 PMTU discovery on the path between the two translators would _not_ result in an ICMP Packet Too Big message being sent to the IPv4 host.   Instead that host would see this as a dropped packet.
> 
> Can you explain why this is bad?   I mean, I can see that there is possibly a small advantage to the DF transparency you are talking about,

> but it doesn't amount to an interop problem
Not an "interop" problem, agreed. 
But it does amount to an operational problem, for whoever is interested in PMTU discovery. 

> and clearly the right thing will happen.   

As explained above, what happens is clearly the wrong thing (and this in some conditions that are needed for PMTU discovery of RFC4821).

> So why is this a blocking issue?

Because, as explained above, it breaks PMTU discovery of RFC4821.

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. 
(In standard-track MAP-E and  lw4over6, are fine because free from such a problem. Also, for those who prefer translation to encapsulation but don’t want to break PMTU discovery, experimental 4rd is available.)


BTW, shouldn't this information be forwarded to the IESG for its understanding the issue?

Regards,
RD