In fact, hole punching as we implement it cannot possibly work if most
port restricted NATs use a different port for each connection. I was
under the impression that the difference between port restricted and
symmetric was precisely this - that a symmetric NAT would allocate a
new port for every { source port, source IP, dest port, dest IP },
whereas a port restricted cone will usually reuse the port, and just
ignore packets coming from IPs other than ones we have sent packets to?It looks increasingly likely that we will need to employ one of our SoC students on this stuff... On Sat, Mar 10, 2007 at 08:57:46PM +0000, Matthew Toseland wrote: > On Sat, Mar 10, 2007 at 01:37:01AM +0000, Michael Rogers wrote: > > Matthew Toseland wrote: > > > That's another interesting point: port rewriting. Right now we don't > > > take any steps to identify our external port number, apart from using it > > > as well as our real port number if we hear it from successful connectees. > > > > STUNT uses the following trick, based on the fact that most NATs > > increase the external port number by 0, 1 or 2 for successive mappings > > with the same internal address and port number: > > > > * Contact first STUNT server, learn external port p1 > > * Contact second STUNT server, learn external port p2 > > * Predicted port for next connection = p2 + (p2 - p1) > > * Peers exchange their predicted ports out of band, then try to connect > > For a symmetric NAT? Nice. > > > > This might also work with STUN - I'm not sure whether UDP mappings are > > allocated in the same way but I don't see why they wouldn't be. However, > > the predicted port doesn't stay fresh for very long unless p1 = p2 (full > > cone), so it might not be very useful unless the peers have a > > low-latency channel to exchange predicted ports (eg a mutual friend's node). > > p1 = p2 on anything except symmetric iirc. > > > > Cheers, > > Michael > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070310/dcb1f180/attachment.pgp>
