[e2e] using p2p overlays to overcome recursive NATs/realms

[David P. Reed]

Man do I hate NATs.  I'm prototyping a really neat collaborative real-time 
platform that really wants UDP packets that are not connection-like at all 
(yes, I've got some interesting ideas for adaptation that allows the 
ensemble to respond helpfully to congestion - in fact, theoretically you 
should be able to manage congestion better by coordinated ensemble action 
than by pairwise-independent TCP-like cong.ctrl. - another thesis topic for 
the grad student iconoclast).

Most NATs handle UDP as if it is TCP-like.  That is, if you as party A are 
behind the NAT, the mapping works such that you can't send a packet out to 
party  B which has a UDP port that will work for parties C, D, ... to send 
a packet back to you.  THis is one of the problems that was pointed out in 
the original NAT RFC, back when NATs were being proposed as a serious 
alternative to V6.

But UDP wasn't developed for pair-wise connections like this.  It was 
developed so that apps that don't have a sensible notion of pairwise 
connections can work.

Yes I can and will do "overlay" level UDP routing as a workaround, but that 
is wrong, because it creates special nodes that cannot fail, or a need for 
highly dynamic overlay routing that can cope with loss of individual 
"overlay routers".  If you are building a scalable system that creates a 
shared environment for thousands of peers, you don't want to have to create 
a special class of fixed overlay routers.

Any solution to the NAT problem is good.  Applying a clue-by-4 to the boxes 
themselves, and their vendors, would be the best solution.  That ain't 
gonna happen.
At 10:19 AM 2/8/2002 +0000, Jon Crowcroft wrote:

>so the problem with most the proposed solutions to workign around nats
>is that they really assume there are only 2 realms -
>the great unwashed internet, and the poor deprived natted user.
>
>the real situation is that packets might traverse multiple natted realms 
>(c.f. realm
>specific ip) - in this scenario, discovering the mapping involves 
>discovering a path of
>several mappings-
>
>soluton might be to start a p2p service, which propgates mappings - take 
>the ideas from
>stun, turn, rsip etc, and use them repeatedly...where multicast is 
>available use it
>
>where one can infer the infernal internal algorithm used by a nat, use it.
>
>if the p2p service thus built (we might call it an InterNAT) has either 
>dynamic DNS update, or
>uses ipv6 itself, then to provide global reachability is quite simple...
>
>  cheers
>
>    jon