Hi, If 6a44 deployed in a managed ISP network, the 6a44 client could be configured with IPv4_MTU-28 for its IPv6 MTU. 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. 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.
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
