[Freeswitch-users] NAT traversal - the final say..!

[Scott]

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 at 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 at 192.168.1.102:57787;rinstance=0c7190b115a36513>
> > To: "foxx"<sip:2000 at 1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>>
> > From: "foxx"<sip:2000 at 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 at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > 
> > 
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121224/58dfd582/attachment.html