| Opera Unite - NAT Traversal Stategies EARLY DRAFT These are possible scenarios, not necessarily planned implementations |
|
|
| Opera Software ASA |
| Luca Venturi |
|
|
|
|
|
|
|
|
Documentation
Generic abstraction of an Opera Unite session. The server is a Opera Unite Server, the client could be any browser.
There will be different scenarios, depending on the presence of network devices, and on the client browser.
|
|
|
|
Documentation
In this scenario, the server is not behind a NAT device, so it appears to be directly connected to Internet.
|
|
|
|
Documentation
This is the typical home scenario, where the server is behind a UPnP enabled device, like an ADSL router.
|
|
|
|
Documentation
In this case, the server is behind a Full Cone NAT, which is the easiest NAT case.
It is not supposed to be a very common situation.
The client needs to be
an Opera Unite browser.
|
|
|
|
Documentation
In this scenario, the user is behind a "Restricted Cone" or a "Port Restricted Cone" NAT.
It should be a common situation for home users with the UPnP protocol disabled.
The client needs to be a Opera Unite enabled browser.
|
|
|
|
Documentation
This is the only way that basically works in any situation where the Client and the Server are connected to the Internet.
The problem is the bandwidth consumption and the load on the Opera Server. Latency too can have a little impact.
At the beginning, it would be the only way to handle a Symmetric NAT (very common in Enterprises), but if required we could manage some special cases without the proxy. We could even try some "port guessing", and sometimes succeed to connect without the proxy.
|
|
|
|
Documentation
In this scenario, we basically transform a "non Opera Unite" browser in an "Opera Unite Enabled" browser. This can be done thanks to an applet deployed in the Client with the help of the Opera DNS.
Similar results (probably with a better success ratio, but at a higher cost and slower time-to-market) can be achieved, writing a plug-in for every browser that we want to support.
This scenario is only hypothetical, there are no plans to implement it.
|
|
|
|
Documentation
In this case, the Server is behind a Symmetric NAT, but the client is able to receive incoming connections, so the Server can start the Opera Unite Session, and we can avoid to use the proxy
|
|
|
|
Documentation
In this scenario the Client and the Server could even not be connected to the Internet, but they are on the same Intranet (with UDP broadcast enabled), so they can use UPnP services discovery to communicate.
There are several security concerns that needs to be addressed.
|
|
|
|
Documentation
In this corner case, hopefully not so common, we will have a chain of several IGD devices; internal tests have shown that with UPnP we probably will be able to open a port only in the first UPnP router, so we will need to use UDP hole punching or the proxy to allow Opera Unite Sessions.
Theoretically UPnP "should" allow opening a port in this situation, (according to the specifications, IGMP Join messages are required on non-AutoIP addresses, like DHCP ones) but at the moment it is not so clear if it is really useful to try to support this configuration.
|
|
|
|
Documentation
In this case, we have several UPnP devices, probably connected to different networks. We will try to open a port on every device detected.
|
|
|
|
Documentation
This is the algorithm used during the UPnP Discovery phase, when the server tries to find a UPnP enabled IGD device
|
|
|
|
Documentation
This is the algorithm used to try to open a port in a UPnP enabled IGD device
|
|
|
|
Documentation
First implementation of the UPnP port opening. Basically, we try to open a port in every router detected, and when a change in the network configuration is detected. Later we can try to support UPnP events notification too.
|
|
|
|
Documentation
Proposal for the first implementation of the NAT traversal Strategy of Opera Unite.
The starting point is STUN, but depending on what we will decide to support, it could be a lot more complex.