diff options
author | Harald Welte <laforge@gnumonks.org> | 2015-10-25 21:00:20 +0100 |
---|---|---|
committer | Harald Welte <laforge@gnumonks.org> | 2015-10-25 21:00:20 +0100 |
commit | fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 (patch) | |
tree | a2011270df48d3501892ac1a56015c8be57e8a7d /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-abstract | 34 |
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. + |