IPv6 is NOT a NAT cure all (it may look like it remedies IPv4 PORT-address-translations (PAT, not NAT) issues, but IPv6 brings its own issues to the table.<br><br>The intrinsic structure of the IPv6 address favors carriers/providers. Today, you get a global IPv4 WAN address and, typically, you then use a 10/8, 172/12, 192.168/16 LAN address schema. WITH IPv6 and WITHOUT IPv6-NAT (or NAT64), as an end user topology, the network portion of your carrier/provider IPv6 WAN address is, all other things being equal, propagated into LAN addresses schema on down to the deepest end points. If you subsequently change carrier/provider, then the network portion changes and, in this use case, ALL your LAN addressing MUST change accordingly. Things like statically addressed servers and router/switch ports, et al, ALL have to be re-configured.<br>
<br>WITH IPv6 and WITH IPv6-NAT (and/or NAT64), you can utilize an internal IPv6 LAN address schema that can then be 1:1 IPv6-NAT'ed to anything your carrier/provider throws at you, regardless of whether you change C/P or the C/P periodically changes your addresses. This true NETWORK-address-translation (NAT) affords a 1:1 address mapping, which eliminates the shortfalls of the current IPv4 PORT-address-translations (PAT, not NAT). Other reasons for inside-outside translations include topology hiding (security), et cetera.<br>
<br>Anyone with medium to large addressable end-points in their installations really needs to look at implementing IPv6 WITH -- repeat WITH -- IPv6-NAT (and/or NAT64) in the mix. <br><br>IMO, NAT will NOT BE DEAD in an IPv6 universe. PAT may be n-stage, but not NAT.<br>
<br><br><br><div class="gmail_quote">On 22 December 2012 23:19, Tim St. Pierre <span dir="ltr"><<a href="mailto:fs-list@communicatefreely.net" target="_blank">fs-list@communicatefreely.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just throwing this out there -<br>
<br>
As it's clear how many problems NAT causes, why don't we all step up the pressure on phone<br>
manufacturers and ISPs to provide working IPv6 implementations so we can put NAT behind us<br>
as soon as possible.<br>
<br>
Just saying -<br>
<br>
-Tim<br>
<br>
<br>
Cal Leeming [Simplicity Media Ltd] wrote:<br>
> *Any and all feedback on this thread would be much welcomed.*<br>
><br>
> Hello,<br>
> *<br>
<div class="im">> *<br>
> There seems to be a large number of discussions surrounding NAT<br>
> traversal, as well as lots of documentation, but with no concrete answers.<br>
><br>
> The NAT related wiki documentation is tedious, and depending on the<br>
> outcome of this thread, I'd like to spend some time cleaning it up.<br>
><br>
> The most common problem (the same as ours) was having a router with<br>
> broken ALG and a softphone that does not seem to work with STUN.<br>
><br>
> The following REGISTER is sent from a phone.<br>
><br>
</div>> REGISTER sip:<a href="http://1.2.3.4:5060" target="_blank">1.2.3.4:5060</a> <<a href="http://1.2.3.4:5060" target="_blank">http://1.2.3.4:5060</a>> SIP/2.0<br>
<div class="im">> Via: SIP/2.0/UDP<br>
> 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport<br>
> Max-Forwards: 70<br>
> Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513><br>
</div>> To: "foxx"<<a href="http://sip:2000@1.2.3.4:5060" target="_blank">sip:2000@1.2.3.4:5060</a> <<a href="http://sip:2000@1.2.3.4:5060" target="_blank">http://sip:2000@1.2.3.4:5060</a>>><br>
<div class="im">> From: "foxx"<<a href="http://sip:2000@1.2.3.4:5060" target="_blank">sip:2000@1.2.3.4:5060</a><br>
</div>> <<a href="http://sip:2000@1.2.3.4:5060" target="_blank">http://sip:2000@1.2.3.4:5060</a>>>;tag=83311448<br>
<div><div class="h5">> Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.<br>
> CSeq: 7 REGISTER<br>
> Expires: 120<br>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY,<br>
> REFER, INFO, MESSAGE<br>
> Supported: replaces<br>
> User-Agent: 3CXPhone 6.0.25732.0<br>
> Content-Length: 0<br>
><br>
> As you can see, the client's public IP is not specified<br>
> anywhere. FreeSWITCH offers several ways around this, the main ones being;<br>
><br>
> * NDLB-connectile-dysfunction<br>
> * NDLB-force-rport<br>
> * apply-nat-acl<br>
> * sip-force-contact<br>
><br>
> The one that has worked in our case was "NDLB-connectile-dysfunction"<br>
> (otherwise known as NAT HACK), however there seems to be a lot of<br>
> negative comments about using this.<br>
><br>
> From what I can tell, the general argument is that NAT HACK is<br>
> considered a non RFC compliant hack, and the SIP phones should be doing<br>
> a better job of keeping to the RFCs.<br>
><br>
> In principle, this is a fair argument - but in practise, it's not a<br>
> reasonable assumption that all phones are RFC compliant, and (imho) not<br>
> a reasonable argument to have this functionality disabled by default.<br>
><br>
> So, I'd like to present the following arguments;<br>
><br>
> * Are there any other negative aspects about<br>
> using NDLB-connectile-dysfunction, other than it is a non compliant RFC<br>
> hack?<br>
><br>
> * Why is NDLB-connectile-dysfunction not enabled by default when certain<br>
> conditions are met? In the event that FreeSWITCH receives a REGISTER<br>
> from a phone specifying a Contact/Via as <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a><br>
</div></div>> <<a href="http://192.168.0.0/16" target="_blank">http://192.168.0.0/16</a>>, but received on a public IP, then it should be<br>
<div class="im">> obvious that NAT is broken and automatically try to circumvent it.<br>
><br>
> * People seem to get confused between server side and client side NAT<br>
> problems, and that they both need to be resolved in a different way. The<br>
> documentation doesn't seem to reflect this clearly.<br>
><br>
><br>
</div>> ------------------------------------------------------------------------<br>
<div class="HOEnZb"><div class="h5">><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>