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.
+