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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
