[Nice] What types of NATs can be traversed when one endpoint is symmetric?

[John Selbie]

Thanks Youness.  That is exactly my understanding as well.

>From what I perceive, symmetric NATs are definitely on the decline in the
home. But symmetric NATs are still prevalent in the work place. Although
I've never confirmed it, 3G mobile devices are essentially on symmetric
NATs.

jrs



On Tue, Apr 2, 2013 at 1:12 PM, Youness Alaoui <
youness.alaoui at collabora.co.uk> wrote:

> Hi John,
>
> Yes, in that use case, it will have to go through TURN. The reason is that
> B
> cannot send to A since there is no port mapping for it, and when A sends
> to B,
> while it creates a mapping, B is unable to receive it because it is
> received
> from a different remote port than the one B sent to and so the port
> restricted
> NAT will reject the packet.
>
> If the user B was using a full cone NAT, then what would happen is that A
> would
> be able to send to B, and B would then detect a "peer-reflexive candidate"
> and
> add it to its local list of remote candidates and start new connectivity
> checks
> with the new peer-reflexive candidate containing the port mapping that the
> user
> A just created on his symetric NAT by sending his connectivity check
> request.
> Then when B replies to A, the agent on the A side will see that the other
> side
> found a new port mapping and will add his own local peer-reflexive
> candidate to
> its list and will start connectivity checks with those.
>
> If the user B was behind an address-restricted NAT, the same would happen
> but
> the first packet from A to B would be rejected (depends on who sends
> first),
> then when B sends to A, the router creates the port mapping to allow A
> packets
> coming in. Then when B retransmits his connectivity check packets, the
> router
> will then allow it to go through, and the whole peer-reflexive candidate
> system
> kicks in again and new connchecks start and it all works.
>
> I like to use the diagrams shown here to help me visualize it :
>
> http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation
>
> There is no table/data available on which types of NAT pairings would go
> direct
> vs. TURN (that I know of), but it's simply that every types of NAT would
> work
> with a direct connection unless it's symetric with symetric NAT or
> symetric with
> port-restricted NAT, everything else should just work all the time.
>
> As for the distribution of NAT types, I have no idea, but my understanding
> (maybe it was just a rumor I heard a long time ago, someone said with no
> real
> data to back it and it stayed in my mind) is that 5% of home routers are
> symetric, and that ICE should work generally in about 90% of the cases.
> Maybe you can find some better documentation about that on the net. If you
> do,
> please let me know.
>
> Thanks,
> Youness.
>
> On 04/01/2013 02:33 PM, John Selbie wrote:
> > Assume two hosts using SIP, TURN, and ICE to rendezvous and setup UDP
> based P2P
> > sessions with each other. Assume connectivity to the SIP and TURN
> service is
> > 100% reliable for these hosts.
> >
> > User A  is a a host is behind a "symmetric" NAT - most likely a 3G
> mobile client
> > - or any other NAT that doesn't have a consistent port mapping scheme.
> >
> > User B - The other host is behind a port-restricted NAT.
> >
> > Now A and B want to do a P2P session over UDP with each other.
> >
> > My understanding is that the ICE negotiation will most likely fall back
> to using
> > the TURN relay port in this scenario. Is that correct? Or does the
> connectivity
> > check phase of ICE have some way of  connecting the hosts directly?
> >
> > I'm also certain that if User B were to be behind a Cone Nat, then ICE
> has a
> > much higher chance of succeeding with a direct connection.
> >
> > Is my understanding correct so far?
> >
> > Is there a table or data available showing what NAT-pairings are
> expected to "go
> > direct" vs fallback to TURN relay in an ICE session?
> >
> > Also, does anyone have data or an "off the cuff" idea of how prevalent
> the
> > different NAT types are (cone, port-restricted, symmetric) in the
> consumer/home
> > case. I would guess most off-the-shelf routers these days are
> port-restricted.
> > But that is only a guess based on the fact that mine is.
> >
> > jrs
> >
> >
> >
> >
> > _______________________________________________
> > nice mailing list
> > nice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nice
> >
>
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130402/ba76b4db/attachment.html>