On Sun, Jul 12, 2015 at 9:29 PM Max Mertens <[email protected]> wrote:
> Hi everyone, > > Hi Max, > > On 11.07.2015 18:16, Max Mertens wrote: > > I suppose that NAT traversal should be possible in all cases except > between two NATs with indeterminable (i.e. random) port allocation (or with > NATs with some weird behaviour). > > I have to correct myself here: I went through the possible NAT type > combinations and considered different "hello" packet sequences for each > combination, and now I have a more thorough understanding of what is > possible and why: > All considerations are easier if you divide the NAT types into the > following categories: > > 1. Not port-restrictive, with a predictable port number¹ (FCN, RCN) > 2. Port-restrictive, with a predictable port number (PRCN, SYMPP, > SYMSP) > 3. Port-restrictive, with an unpredictable port number (SYMRP) > > (There might exist some symmetric NATs with unpredictable port number that > are not port-restrictive, but I don't think this is a typical > implementation.) > With these basic NAT types, the following combinations will work when > implementing NAT traversal techniques: > > Peer1\2 | 1. | 2. | 3. > ========================= > 1. | *yes* | yes | *yes* > 2. | yes | yes | no > 3. | *yes* | no | no > > This is because if either peer (A) is port-restrictive and the other one > (B) has an unpredictable port number, NAT traversal in the direction > (B)->(A) does not work, because you do not know the port number of (B) to > punch a hole in the NAT of (A). > I agree. > The same table expanded into particular NAT types (FCN and RCN is > basically the same, in our regard): > > Peer1\2 | fcn/rcn | prcn | sympp | symsp | symrp > ================================================== > fcn/rcn | *yes* | *yes* | yes | yes | *yes* > prcn | *yes* | *yes* | yes | yes | no > sympp | yes | yes | yes | yes | no > symsp | yes | (yes) | (yes) | (yes) | no > symrp | *yes* | no | no | no | no > > (Note that, despite the number of rows and columns, the RCN and PRCN > implementations are more frequent than symmetric NATs, according to [1].) > The entries marked in bold are already fully working in the current NTS > implementation. The other "yes" entries will be approached next. > The "no" entries cannot work for any NAT traversal implementation without > a relay server. > OK. > > The "(yes)" entries do work, but require port prediction of the > sequentially allocating NAT of a peer already in the team. So the (old) > peer has to connect to another port at the splitter or monitor (ideally 2 > different ports, to get the source port increment step size) to predict the > public source port that it will be using to communicate with the new peer. > This could be an optional task when the other NAT combinations are fully > working. > Good idea. > > > As for the asymmetry I posted this week: I reran the test a few times and > got different results each time. I think the result should be "yes" but > somehow a "hello" packet are lost and therefore the connection fails. So it > seems sending keepalive packets (to open the NAT hole in case the "hello" > packet gets lost) until the peer has joined correctly could improve the > situation. > > Thinking about the PRCN<->SYMPP case again, it seems that the connection > works if the "hello" packets by the two peers are sent in a certain order, > and the hole punching fails in the other case. So there is a 50% chance > that the connection succeeds. This will be working reliably when continuous > (keepalive) "hello" packets are sent until the connection is established. > Yes, I agree. Best regards, Vi. -- -- Vicente González Ruiz Depto de Informática Escuela Técnica Superior de Ingeniería Universidad de Almería Carretera Sacramento S/N 04120, La Cañada de San Urbano Almería, España e-mail: [email protected] http://www.ual.es/~vruiz tel: +34 950 015711 fax: +34 950 015486
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
