ietf
[Top] [All Lists]

RE: RE: Stupid NAT tricks and how to stop them.

2006-04-11 10:15:30
John Loughney wrote:
We're over-analyzing things.

I don't think so. The Internet is no longer this thing for researchers
and geeks it used to be. Now it is a global commercial product. As long
as we keep producing protocols designed by researchers and geeks for
researchers and geeks with total disregard to mass-market
considerations, we will keep having these discussions about why crap
gets deployed instead of the good stuff.


My DSL provier offers me 5 DHCP address for free
(consumer grade connection)

Then you don't need a router; if you don't NAT there is no address space
you could route your DHCP addresses to/from. You need a bridge, just
connect only the LAN side of your combo box and you'll be able to have
your DHCP addresses over the WiFi. The wireless-to-wired bridge works
regardless of the configuration of the WAN side of the combo box.
Ironically, it is probably cheaper to buy a combo box than a pure
wireless bridge, but that's another story.

What you might want is a real firewall that could bridge, and as
discussed earlier there are not many consumer grade offerings as of
today. There few offerings because there is very little demand, and
there is little demand because such firewalls have many of the
inconveniences of NAT.


Vendors have turned NAT on by default because it is easier for them;
not because the market has asked them to.

I do not agree. It was not easy at the beginning; it is easier now
because it has become a more mature product. The market buys products,
and the vendors react by producing the gear that the market wants to
buy, for cheap because it's a competitive environment. When a product is
new, vendors more or less guess what it could/will be, but when a
product is mature such as NAT now, vendors design products based on what
sells and recurse with small changes. In mass-market products vendors
have little influence over the market. Marketing and advertising can
somehow change what the market wants to buy, but in the end consumers
often buy what is cheap or whatever their buddies have, and the fact
that something is "superior" might not make any difference.


As for reference, my local paper started, computer stores started
advertising "NAT firewalls" around 1998-99.  When NATs first came to
the
market, the marketing message was that NATs provided a security
feature.

At that time, NAT did provide some security. It was very common then to
see PCs directly connected to the Internet with a public IP, with all
the NetBios ports open to all would-be hackers in the world. The
"nothing in unless initiated inside" is not perfect, but it was a heck
of a lot better than an unprotected PC sitting directly on a public IP. 


I don't think it is really intellectually honest to say the market
has chosen NATs because it is what they wanted - it is a band-aid
fix for a couple of different problems, which it kind of solved

I disagree with this as well. The market chose NAT. The market probably
does not know it's a band-aid, nor does it care. But it knows it's cheap
and it works good enough. The market chose cars that rust over stainless
steel ones too (remember these cool DeLorean cars). The stainless steel
car is superior to the regular car, but the inconvenience of the car
rusting was not worth the difference in price and consumers did not
embrace it. Same for light bulbs and neon tubes: light bulbs blow
regularly and are not efficient; neons produce low-quality light. There
are technologies that last long, are efficient and produce good quality
light. Look around you.....

Same applies to NAT: if we want to get rid of it, instead of forever
whining that it sucks we have to provide the market with a better
alternative for about the same price, which we don't have today. Better
meaning not what we deem as technically superior but what the market
would consider worth implementing.

Michel.


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>