Re: NAT-PMP not honoring requested external port
Re: NAT-PMP not honoring requested external port
- Subject: Re: NAT-PMP not honoring requested external port
- From: james woodyatt <email@hidden>
- Date: Wed, 11 Jun 2008 17:28:14 -0700
On Jun 11, 2008, at 16:52, Jens Alfke wrote:
On 11 Jun '08, at 1:45 PM, Duane Murphy wrote:
At that point, it sounds like you've just about reinvented STUN
<http://
www.ietf.org/rfc/rfc3489.txt>.
No, this is not like STUN. I'm not using UDP, and I'm not trying to
poke a hole through the NAT. This all runs over TCP sockets, and I'm
using NAT-PMP or UPnP to ask the NAT to open a port.
I think what Mr. Murphy meant to say was that you're well on your way
toward reinventing TURN for TCP <http://tools.ietf.org/html/draft-ietf-behave-turn-tcp
>.
If you want to know what I'm doing, this blog post is a good place
to start:
http://mooseyard.com/Jens/2008/04/cloudy-networking/
although the series begins a few posts earlier:
http://mooseyard.com/Jens/2008/04/cloudy-as-buzzwords/
I would add that it looks like you might be trying to reinvent both
APEX [RFC 3340-3343] and SACRED [RFC 3760]. Good luck with that.
The catch is if both ends are behind NAT firewalls, you'll need a
non-
NAT service that can be used to kickoff the NAT port acquisition.
No, I just ask the NAT to open a port for me. (I am willing to
sacrifice compatibility with NATs that don't support this; these
days, most of them seem to. I'd rather not mess with stuff like STUN
or Bryan Ford's TCP-compatible hole-punching technique.)
It won't work for peers behind Comcast's NAT464, which they're now
applying unilaterally to selected victims in North America with plans
to "upgrade" everyone in two years.
--
james woodyatt <email@hidden>
member of technical staff, communications engineering
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden