If you have a full IPv6 network, using all the protocols, like dns registration, DHCP-V6 for assigning networks to routers, Neighbor Discovery both directions, so that DNS delegations can be automated, then as long as you reference everything by host name, it should all just work. It's been working that way for me, with the only having to update nameserver helper records once and a while.
 
If you happen have your own address space, and with to managed it downstream, all the services can also be implmented easy so that your down streams don't have to do anything to make all the auto address assignment, and DNS work.
 
If you're going to use IPv6, set up the infrastructure FIRST, so managing it doesn't get out of hand. If done right at all layers it just works, when you use names.
 
--Dave

From: Scott [mailto:8f27e956@gmail.com]
To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]
Sent: Mon, 24 Dec 2012 16:14:03 -0800
Subject: Re: [Freeswitch-users] NAT traversal - the final say..!

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.

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.

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.

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.

IMO, NAT will NOT BE DEAD in an IPv6 universe.  PAT may be n-stage, but not NAT.



On 22 December 2012 23:19, Tim St. Pierre <fs-list@communicatefreely.net> wrote:
Just throwing this out there -

As it's clear how many problems NAT causes, why don't we all step up the pressure on phone
manufacturers and ISPs to provide working IPv6 implementations so we can put NAT behind us
  as soon as possible.

Just saying -

-Tim


Cal Leeming [Simplicity Media Ltd] wrote:
> *Any and all feedback on this thread would be much welcomed.*
>
> Hello,
> *
> *
> There seems to be a large number of discussions surrounding NAT
> traversal, as well as lots of documentation, but with no concrete answers.
>
> The NAT related wiki documentation is tedious, and depending on the
> outcome of this thread, I'd like to spend some time cleaning it up.
>
> The most common problem (the same as ours) was having a router with
> broken ALG and a softphone that does not seem to work with STUN.
>
> The following REGISTER is sent from a phone.
>
> REGISTER sip:1.2.3.4:5060 <http://1.2.3.4:5060> SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport
> Max-Forwards: 70
> Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513>
> To: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>>
> From: "foxx"<sip:2000@1.2.3.4:5060
> <http://sip:2000@1.2.3.4:5060>>;tag=83311448
> Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.
> CSeq: 7 REGISTER
> Expires: 120
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY,
> REFER, INFO, MESSAGE
> Supported: replaces
> User-Agent: 3CXPhone 6.0.25732.0
> Content-Length: 0
>
> As you can see, the client's public IP is not specified
> anywhere. FreeSWITCH offers several ways around this, the main ones being;
>
> * NDLB-connectile-dysfunction
> * NDLB-force-rport
> * apply-nat-acl
> * sip-force-contact
>
> The one that has worked in our case was "NDLB-connectile-dysfunction"
> (otherwise known as NAT HACK), however there seems to be a lot of
> negative comments about using this.
>
>  From what I can tell, the general argument is that NAT HACK is
> considered a non RFC compliant hack, and the SIP phones should be doing
> a better job of keeping to the RFCs.
>
> In principle, this is a fair argument - but in practise, it's not a
> reasonable assumption that all phones are RFC compliant, and (imho) not
> a reasonable argument to have this functionality disabled by default.
>
> So, I'd like to present the following arguments;
>
> * Are there any other negative aspects about
> using NDLB-connectile-dysfunction, other than it is a non compliant RFC
> hack?
>
> * Why is NDLB-connectile-dysfunction not enabled by default when certain
> conditions are met? In the event that FreeSWITCH receives a REGISTER
> from a phone specifying a Contact/Via as 192.168.0.0/16
> <http://192.168.0.0/16>, but received on a public IP, then it should be
> obvious that NAT is broken and automatically try to circumvent it.
>
> * People seem to get confused between server side and client side NAT
> problems, and that they both need to be resolved in a different way. The
> documentation doesn't seem to reflect this clearly.
>
>
> ------------------------------------------------------------------------
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org