35 lines
1.6 KiB
Plaintext
35 lines
1.6 KiB
Plaintext
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.
|
|
|