Re: [v4tov6transition] [Softwires] 6a44 MTU issues

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

Fred and Washam,

I reacted too fast to previous remarks when I proposed to modify the accepted IPv6 MTU in 6a44 draft.
If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could receive them in fragmented IPv4 datagrams.
This would be contrary to the objective of simplicity (datagram reassembly would have to be include in 6a44 clients) and to the objective of security (a new door would be open to dos attacks).
No change on this point will therefore appear in the next version of the draft. 
Some additional explanations may be appropriate, but preferably after a consensus on what has to be said.

Then the MTU issue of IPv6 in IPv6 tunnels that Fred underlines remains as is.
If the PMTU of such a tunnel is unknown, or known to be less than 1280+40, tunnel endpoints have to tunnel 1280-octets external packets in two pieces, using a fragmented IPv6 datagram for this. 
Reassembly at the other end is then necessary. 
It can be facilitated if the tunnel is treated as only one flow, with packets in general kept in sequential order. 

Regards,
RD
  

>>>> Actually, the 6a44 specification should, instead of 1280, 
>>>> require IPv4 MTU - 28 octets, both for hairpinning and 
>>>> traversal cases.
>>> 
>>> How can you be sure that IPv4 PMTUD will work in
>>> the traversal case?
>> 
>> In the to-host direction, because the ISP network is all what 
>> is left to traverse before reaching the CPE.
> 
> In what you call the to-host direction, any ICMPv4
> returned from the ISP network might not have enough
> information for stateless translation to ICMPv6.

1. Could you be more specific?
Do yout see a significant difference with what happens with 6to4,


>> In the from host direction, one can't be sure, but doesnt' need to.
>> If a smaller PMTU is encountered further downstream, a PTB 
>> ICMPv6 error message will be returned from there.
> 
> In the from-host direction, any ICMPv4 returned from
> the ISP network might not be delivered to the tunnel
> endpoint due to NAT filtering,

2. Then the IPv6 service is somewhat damaged concerning fault diagnosing, like the underlying IPv4 service.
But at least packets that should be delivered are delivered.


> and might not have
> enough information for stateless translation to ICMPv6.

3. Same as 1. above.


>>> In the to-host direction, because the ISP network is all what 
>>> is left to traverse before reaching the CPE.
>> 
>> In what you call the to-host direction, any ICMPv4
>> returned from the ISP network might not have enough
>> information for stateless translation to ICMPv6.
> 
> I should also say, any ICMPv4 returned from within
> the end user network (where MTUs might not be so well
> managed) might not be delivered to the tunnel endpoint
> in the ISP network.

4. Same as 2. above.
(Since IPv4 fragments rather than returning packet-too-big ICMP messages, this cannot concern MTUs).

Yet, there remains another problem with the replacement of 1280 by "IPv4 MTU - 28" (I proposed it too quickly) because it creates risks of fragmentation ...