From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- 2004/nat-ccc2004/extended-abstract | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 2004/nat-ccc2004/extended-abstract (limited to '2004/nat-ccc2004/extended-abstract') 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. + -- cgit v1.2.3