[p2p-hackers] Official IETF behavior recommendations forNATrelevant to P2P

[Enzo Michelangeli]

David,

I generally agree with you and Bryan, with the following notes:

----- Original Message ----- 
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Peer-to-peer development.'" <p2p-hackers at zgp.org>;
<ietf-behave at list.sipfoundry.org>
Sent: Friday, May 20, 2005 9:05 AM
Subject: RE: [p2p-hackers] Official IETF behavior recommendations
forNATrelevant to P2P

[...]
> However, I have a complication that shared by all NATs, and that is
> getting a port that complies with RTP.  The RTP standard indicates
> RTP ports should be even-numbered, and the next port (odd-numbered)
> is implied to be open to receive RTCP.

This restriction was substantially relaxed in RFC3550:

   [...] For
   applications in which the RTP and RTCP destination port numbers are
   specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.

The sad truth is that SIP and RTP were never designed with NAT in mind:
the authors were probably thinking that the deployment of IPv6 was going
to happen soon, AND that this would have made NAT unnecessary. After this
scenario failed to become reality, a small army of remedial solutions were
devised: "rport" parameter (RFC3581); Symmetric RTP; STUN; TURN; ICE
(http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-01.html) etc.
In my opinion, the only real solution would be to junk SIP for good and
use IAX2 (http://www.voip-info.org/wiki-IAX), which is also more compact
and efficient: but this is another story, and OT for this list.

> Unfortunately, I as a client have absolutely no control over
> which ports my NAT assigns me, so it's very difficult for me to receive
> RTP in a fully compliant fashion.

Right, although RFC3581 and symmetric RTP may alleviate this problem.

And by the way: I have always found it kind of nutty that in order to know
something local to my router like the NAT mappings I have to bother some
third party on the Internet. As the BEHAVE working group is laying down
guidelines for NAT implementors, wouldn't it be useful to ask for a simple
mechanism to query the NATting device about port mappings? For instance, a
UDP packet sent to a well-known port of the NAT router (or, better,
broadcast to that port, as the application may be unaware of the router's
address) could ask: "tell me which external address/port pair corresponds
to the internal pair 192.168.0.123:4567 UDP, and how long the mapping can
be expected to last". True, this only works if there isn't a second NAT
further ahead on the road, but this is the case in the vast majority of
the cases.

Enzo