Nick Guenther wrote:
On 6/13/06, Stuart Henderson <[EMAIL PROTECTED]> wrote:
On 2006/06/13 22:07, Nick Guenther wrote:
> What is the prefered method for NAT-traversal these days? The options
> I know are:
> UPnP
I suppose this one doesn't work unless the protocol bends well to it,
and both ends support it too, which means running clunky XML and HTTP
code.....
Sorry that it took so long to answer back. Got very busy.
Anyway, there is many different ways suggested so far to do this.
The current proposals are:
* Universal Plug and Play (UPnP)
* Simple Traversal of UDP Through Network Address Translation devices
(STUN)
* Application Layer Gateway
* Manual Configuration
* Tunnel Techniques
* Automatic Channel Mapping
Some interesting reading is available here:
http://www.newport-networks.com/whitepapers/nat-traversal1.html
http://www.ietf.org/rfc/rfc3489.txt
http://www.voip-info.org/wiki-STUN
Looks like the one that is use the most is the STUN server, but that
doesn't cover all possibility.
> a proxy
> having the in-kernel NAT code do the work itself
Look at how /usr/sbin/ftp-proxy works with anchors - it's a nice
hybrid, keeping L7 work out of the kernel, and bulk-packet-shifting
out of userland.
Ah, thank you! That makes for a lot of reading up to do.
Skimming the code it seems that there's a lot of framework-code shoved
in alongside the proxying, is that right?
I guess my questions are more on the design side of it. I would think
that having it part of PF still was the best way, but may be not. I am
not saying I understand all of this to see the benefit of it other then
having a great piece of software working very well already and built
upon that.
May be to put a STUN server together, it may well be much better to do
it in the ftp-proxy way and tie it with PF.
But then even having a great STUN server proxy wouldn't cover all
possibility.
Any feedback as to the pro and cons of having STUN stand alone, in PF,
or like ftp-proxy tie with PF?
What might be the best approaches here to follow and the less likely to
re write what's already done in PF and at the same time taking advantage
of the current design?
Is the STUN approaches is still the best one and the one that should be
the start of this NAT traversal for SIP VoIP solutions, even knowing the
limitations of it at this time?
Any thoughts at a better idea or angle to take on this?
I am looking at some feedback of good/bad or pitfall not to follow.
I learn a long time ago from OpenBSD that simpler is better, so I am
really looking at the simplest way to do this and feedback on it to
would be greatly appreciated too!
Thanks
Daniel
