summaryrefslogtreecommitdiff
path: root/2004/nat-ccc2004/extended-abstract
diff options
context:
space:
mode:
authorHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
committerHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
commitfca59bea770346cf1c1f9b0e00cb48a61b44a8f3 (patch)
treea2011270df48d3501892ac1a56015c8be57e8a7d /2004/nat-ccc2004/extended-abstract
import of old now defunct presentation slides svn repo
Diffstat (limited to '2004/nat-ccc2004/extended-abstract')
-rw-r--r--2004/nat-ccc2004/extended-abstract34
1 files changed, 34 insertions, 0 deletions
diff --git a/2004/nat-ccc2004/extended-abstract b/2004/nat-ccc2004/extended-abstract
new file mode 100644
index 0000000..de9af12
--- /dev/null
+++ b/2004/nat-ccc2004/extended-abstract
@@ -0,0 +1,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.
+
personal git repositories of Harald Welte. Your mileage may vary