blob: de9af1274a16fc6d610750367eb1bb7de616530f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
The Reality of Network Address Translators
NAT's are ubiquitous in todays Internet, not only built into so-called DSL or
WLAN Routers within customer premises, but also in the corporate environment.
The dream of an end-to-end transparent network has died one NAT at at time.
Unfortunately the IETF missed to recognize this reality for a long time. This
means that there are no up-to-date informations (like best current practice
RFC's) specifying how an implementor should implement Network Address
Translation. This lack of standardization leads to different NAT behaviour
from implementor to implementor.
Tradiditonal IP based protocols are built around the client-server paradigm,
and NAT's are designed for this. However, recently protocols and applications
based on the peer-to-peer paradigm are becomming more and more common. And
this is where NAT's become a major problem, especially since they don't expose
any standardized deterministic behaviour.
Many approaches have been designed, usually with H.323 or SIP as driving force
behind them. FCP, Midcom, NSIS, STUN - just to name a few examples.
None of them works in all, or even the majority of all cases. In fact the
author of this presentation believes it is impossible to solve the problem
without making assumptions on some common behaviour of all NAT implementations.
The recently published draft-audet-nat-behave tries to be a first candidate of
such a behavioral specification. It is scheduled to evolve into a BCP RFC on
NAT behaviour in 2005.
The presentation will present the fundamental problem, look at different
classes of NAT's, their behaviour, and give an overview about the proposed
solutions.
|
