Le 13 oct. 2010 à 17:17, Templin, Fred L a écrit : > Hi Remi, > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Rémi Després >> Sent: Tuesday, October 12, 2010 12:26 AM >> To: Templin, Fred L; Washam Fan >> Cc: Softwires; [email protected] >> Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues >> >> 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. > > 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?
> >> 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. > > Right. > >> If the PMTU of such a tunnel is unknown, or known to be less >> than 1280+40, > > Actually, 1280+40+IPsec headers and trailers in the case > of VPN. I was only discussing the direct IPv6 in IPv6 case. But, yes, it is in general 1280 + the encapsulation header, whatever its size. >> tunnel endpoints have to tunnel 1280-octets >> external packets in two pieces, using a fragmented IPv6 >> datagram for this. > > OK, so steady-state IPv6 fragmentation and reassembly between > VPN tunnel endpoints is expected as normal operation in this > model. Yes. (A consequence of privileging connectivity and stateless operation). >> Reassembly at the other end is then necessary. >> It can be facilitated if the tunnel is treated as only one >> flow, > > Can you say more about what you mean by this? I mean that, because packets are almost always kept in sequence for a flow (otherwise TCP efficiency would be in general very poor) reassembly can be limited to consecutive fragments of only one datagram (the one being currently reassembled). A packet permutation that interleaves fragments of two different datagrams leads in this case to a loss (but with low enough a frequency for it to be acceptable). This is significantly simpler than in the case where fragments of many datagrams my be interleaved. > >> with packets in general kept in sequential order. > > In-order delivery is not a strict requirement for > correct IPv6 reassembly - but the fact that steady-state > IPv6 frag/reass is required seems onerous. See just above. Regards, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
