Hi Washam, > -----Original Message----- > From: Washam Fan [mailto:[email protected]] > Sent: Monday, October 11, 2010 7:38 PM > To: Templin, Fred L > Cc: Rémi Després; Softwires; [email protected] > Subject: Re: [v4tov6transition] IPv6 VPNs configured over > 1280 MTU tunnels > > Hi, > > If 6a44 deployed in a managed ISP network, the 6a44 client could be > configured with IPv4_MTU-28 for its IPv6 MTU.
My understanding is that the 6a44 server is in the managed ISP network, and the 6a44 client is in the UNmanaged end user network. > For inbound direction, > 6a44 server would reject any IPv6 packets whose size exceeds > IPv4_MTU-28 with a ICMPv6 PTB message, so no ICMPv6-ICMPv4 translation > needed. Huh? How does the server have any idea what MTU the client set on its tunnel interface? The client is behind a NAT in an unmanaged end user network. Are you expecting the server to probe the path MTU to the client and maintain state? (An IRON server might be in position to do something like that, but I was assuming the 6a44 server would be stateless, right?) > For outbound direction, 6a44 server would encapsulate any > ICMPv6 PTB messages it received in UDP in IPv4, and then forward to > the 6a44 client, so no NAT filtering worried. Correct, but no one has suggested an MTU problem for what happens to IPv6 packets *beyond* the tunnel; we are only discussing the case of MTU issues *within* the tunnel. Fred [email protected] > Thanks, > washam > > 2010/10/12 Templin, Fred L <[email protected]>: > > Remi, > > > >> -----Original Message----- > >> From: Rémi Després [mailto:[email protected]] > >> Sent: Monday, October 11, 2010 10:05 AM > >> To: Templin, Fred L > >> Cc: Washam Fan; Softwires; [email protected] > >> Subject: Re: [v4tov6transition] IPv6 VPNs configured over > >> 1280 MTU tunnels > >> > >> > >> Le 11 oct. 2010 à 18:42, Templin, Fred L a écrit : > >> > >> >> ... > >> >> 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. > > > >> 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, and might not have > > enough information for stateless translation to ICMPv6. > > > > Fred > > [email protected] > > > >> RD > > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
