On Jun 12, 2012, at 10:47 PM, Masataka Ohta wrote:
Dave Hart wrote:
It is not transparent when you have to negotiate an inbound path for each service.
I mean, for applications, global address and global port numbers are visible.
Showing that you don't actually understand what everyone else means when they say "end-to-end".
UPnP is inadequate for carrier NAT due to its model assuming the NAT trusts its clients.
UPnP gateway configured with purely static port mapping needs no security.
Assuming shared global address of 131.112.32.132, TCP/UDP port 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, ...
No carrier is going to implement that for obvious reasons. Besides, that's not transparent end-to-end, that's predictably opaque end-to-end.
When TCP headers are being rewritten, it's a strong hint that transparency has been lost, even if some communication remains possible.
UPnP provides information for clients to restore IP and TCP headers from local ones back to global ones, which is visible to applications.
But it doesn't work across multiple layers of NAT.
See the following protocol stack.
UPnP capable NAT GW Client +---------+ | public | | appli- | | cation | information +---------+ +------+ for reverse translation | public | | UPnP |-------------------------->|transport| +---------+---------+ +---------+ | public | private | | private | |transport|transport| |transport| +---------+---------+ +---------+ +---------+ | public | private | | private | | private | | IP | IP | | IP | | IP | +---------+-----------------------+-----------------------+ | privatte datalink | private datalink | +-----------------------+-----------------------+
Now, redraw the diagram for the real world scenario: host <-> UPnP NAT <-> Carrier NAT <-> Internet <-> Carrier NAT <-> UPnP NAT <-> host Tell me again how the application signaling from UPnP survives through all that and comes up with correct answers? Yeah, thought so. Owen