Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proxy Servers vs IP Masquerade



Patrick McManus wrote:
> * l4 switches are a massive layering violation.
> 
> * the l3 end-to-end design of the network is impt.
>... 
> a more interesting question in my mind is why would you want
> transparent servicing/redirection of any kind of protocol? I can only
> think of one answer: automatic client configuration. Frankly there are
> much better ways to do service discovery and I certainly hope that it
> becomes the norm for this class of problem.

I'm not sure I follow your argument.  IP masquerading (the Linux-ish term
for NAT, which is now appearing in a wide range of commercial products) is
obviously a kludge grafted on top of IP4 in ways the original designers
would never have imagined.

But the concept is sound:  why assign every IP-addressable device on
the planet its own externally-reachable "phone number" given the constraints
of routing table size and address length?

NAT is an interim method of setting up hierarchical addressing and
routing.  The IP4 genie was out of its bottle for a long time before
anyone asked questions of scalability (remember when ARPAnet was just
an R&D project, and the Fortune 500 didn't understand what it could do).
I.e., it was too late to set a "flag hour" for cutting everyone over
from IP4 to IP6, so it'll take incredible market forces and engineering
ingenuity to motivate an Internet-wide IP6 conversion.

Meanwhile, NAT is probably the single most effective technology for
reducing pressure on routing tables and address space.  Proxy never
came close.  I'll wager some of the tricks learned during NAT
deployment wind up being important components of future IP6 products.

Patrick--how did service discovery come into the equation?  I think
I must've missed a point made earlier.

-rich
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org