Opera Unite - NAT Traversal Stategies

EARLY DRAFT


These are possible scenarios, not necessarily planned implementations
Opera Software ASA
Luca Venturi

Table of Contents
Communication Diagram
Common Opera Unite P2P Session

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.

Communication Diagram
1 - Directly connected to Internet

Documentation

In this scenario, the server is not behind a NAT device, so it appears to be directly connected to Internet.

Communication Diagram
2 - UPnP Enabled IGD Case

Documentation

This is the typical home scenario, where the server is behind a UPnP enabled device, like an ADSL router.

Communication Diagram
3 - UDP Full Cone NAT - Opera Only

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.

Communication Diagram
4 - UDP Restricted Cone NAT - Opera Only

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.

Communication Diagram
5 - Symmetric NAT (Opera Only) or UPnP Disabled

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.

Communication Diagram
6 - Local 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.

Communication Diagram
7 - Reverse Connection

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

Communication Diagram
8 - Services Discovery on Intranet

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.

Communication Diagram
Corner Case A: serial IGD devices

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.

Communication Diagram
Corner Case B: parallel IGD devices

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.

Sequence Diagram
UPnP Discovery Process

Documentation

This is the algorithm used during the UPnP Discovery phase, when the server tries to find a UPnP enabled IGD device

Sequence Diagram
UPnP Port Opening Process

Documentation

This is the algorithm used to try to open a port in a UPnP enabled IGD device

State Machine Diagram
UPnP Network Changes Discovery

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.

State Machine Diagram
NAT traversal strategy

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.