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

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

Le 13 oct. 2010 à 22:04, Templin, Fred L a écrit :
>>>> ...
>>>> If IPv6 packets longer than 1280 would be accepted by 6a44 
>>>> servers, hosts could receive them in fragmented IPv4 datagrams.
>>> 
>>> Or they might be reassembled in the NAT(s) in front of
>>> the host.
>> They would indeed.
>> But they would then be forwarded across the customer network.
>> There, they may somewhere be fragmented to fit into fragments 
>> shorter than the ISP MTU + 28.
>> This happens for example if the ISP IPv6 MTU would be 1500-28 
>> and that of some link in the customer site would be 1500-40 
>> (say, for an IPv4 in IPv6 tunnel). 
>> Right?
> 
> The fact of life is that we have the ISP managed network
> domain and the end user network unmanaged network domain,
> whether the ISP controls the CPE or not. The managed domain
> should be well-behaved, but any manner of MTU irregularities
> is possible within the unmanaged domain. For example, I can
> login to my Linksys home router and manually set the MTU to
> any value I want.
> 
> Anything that can be configured can be mis-configured, and
> the ISP has no control of any misconfigurations that might
> occur in the end user network. As far as the ISP can tell,
> the end user network is just a black hole that silently
> consumes packets. 

The point isn't about misconfigurations.
It is that stateless tunnels (i.e. without SEAL ...) are legitimate within customer sites.
They can lead some intra-site IPv4 PMTUs that are less than 1500, and even less than 1500 - 28.

Then, because the 6a44 design privileges robustness, it is better to avoid more constraints on intra-site PMTUs than those that are absolutely mandatory.
In order to statelessly support IPv6/UPD/IPV4 packets intra-site IPv4 PMTUs of 1280 + 8 + 20 = 1308 octets IS the obligation (one that should be satisfied with all realistic stateless tunnels in customer sites).

RD