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

From: "Michel Py" <[email-masked]>
Date: Sun, 2 Apr 2006 18:07:25 -0700

> Iljitsch van Beijnum wrote:
> you can make it do IPv6 NAT. Simple client-server protocols
> such as HTTP worked without incident as expected. However,
> I also tried FTP, which really isn't that bad as NAT-breaking
> protocols go. It didn't work because the server saw an illegal
> EPRT request. In IPv4 with NAT that wouldn't have happened
> because:
> 1. The FTP client would have used EPSV in order to be
> NAT-friendly, or
> 2. The FTP ALG would have intercepted the private address
> and rewritten it

No surprise here; exact same happened with NATv4 in the early stages. We
all know that NAT requires ALGs.

> Moral of the story: do IPv6 NAT at your peril.

Was the same with NATv4 too.

> Now of course it's possible to argue all of the stuff that
> makes IPv4 NAT work to the degree that it does today can also
> be added to IPv6, and that is true, strictly speaking.

Especially with the experience of doing it with v4.

> But will the vendors bother, and will the customers
> require it? I don't think so.

That's were you're wrong, IMHO. First, the vendors will do whatever the
customers want to buy, and customers are not always smart and will have
a great tendency to do just the same that worked for them with v4.

Second, vendors might try to do it just to see if it sells or not. Given
the existing NATv4 code base, it won't cost too much to implement NATv6
on an IPv6 capable "router". These guys have sold millions of NATv4
boxes, you can bet that if they eventually release a v6 product it will
have NATv6, the rationale being:

- If the customer wants to use NATv6, good because then they sell the
product while the competitor that does not have NATv6 does not. Just a
few percent makes a difference.
- If the customer does not want to use NATv6, all it costs was a few
weeks of coding, well worth the risk.

> As Tim said: if you can live with NAT, why not stay with IPv4?
> That saves you several headaches and it only costs you a few
> IPv6 nice-to-haves such as stateless autoconf that haven't been
> able to get people to IPv6 anyway.

Oh, I agree; but what we think might not be what the market picks. The
market might pick the "why not stay with IPv4" part without knowing why.

Maybe to accelerate the deployment of IPv6 we should advertise: It has
the same wonderful NAT you like so much in IPv4 :-D
<running for cover>

> The interesting thing is that even though ISDN doesn't amount
> to much in the US and it's mainly used for businesses in Europe,
> GSM which is the biggest mobile phone technology, uses ISDN
> Q.9xx signalling, so ISDN was never a waste of time.

But was a waste of money, at least in the US. Many telcos have invested
much money into ISDN that has not brought ROI. This is one of the many
reasons IPv6 does not take off in the US, because some people don't want
to repeat the financial ISDN fiasco and are reluctant to invest money in
technologies that they don't perceive being embraced by customers any
time soon.

There is a slight difference between what we do in here for the greater
good of humanity and what telcos and vendors do for the greater good of
their shareholders.

> The trouble is that if you use IPv4-compatible IPv6 addresses (in
> the loose sense of the word, not thinking of any RFC) for instance
> by having the first 96 bits of the IPv6 be zero, you get to
> translate between v6 and v4 transparently, but you still never
> get to use addresses that are longer than 32 bits,

Not at the beginning, but the point is a) getting ready for it and b)
backwards compatibility. In the initial stage, everyone is basically
wasting bandwidth and memory to carry/store all these useless zeroes.
Later on, when islands begin to implement the extended bits, they can
use them internally and tunnel if the backbone is not ready.

Imagine that you want to develop a high-quality audio CD. Today with
IPv6, you need to have both the good old CD and the new standard. Since
they are no high quality CDs available on the market and good old CD
works good enough for 99% of the people, it does not take off.

In this situation, the only way to market is to build a high quality
audio CD reader that reads the old CDs just as good and promises to read
the new ones when they eventually become available. Backward
compatibility.

Note that I'm not saying we should do anything about this; it's either
too late or too early. I have the feeling though that the protocol that
will replace v4 is not v6 but something that will feature seamless
backward compatibility.

> BTW, Michel, you said you were about to return from the dark
> side in true Star Wars fashion. What gives?  :-)

And now, ladies and gentlemen, for your entertainment:

                      .-.
                      |_:_|
                     /(_Y_)\
                    ( \/M\/ )
 '.               _.'-/'-'\-'._
   ':           _/.--'[[[[]'--.\_
     ':        /_'  : |::"| :  '.\
       ':     //   ./ |oUU| \.'  :\
         ':  _:'..' \_|___|_/ :   :|
           ':.  .'  |_[___]_|  :.':\
            [::\ |  :  | |  :   ; : \
             '-'   \/'.| |.' \  .;.' |
             |\_    \  '-'   :       |
             |  \    \ .:    :   |   |
             |   \    | '.   :    \  |
             /       \   :. .;       |
            /     |   |  :__/     :  \\
           |  |   |    \:   | \   |   ||
          /    \  : :  |:   /  |__|   /|
          |     : : :_/_|  /'._\  '--|_\
          /___.-/_|-'   \  \
                         '-'

I think I found the IPv6 killer app:
telnet towel.blinkenlights.nl
We need more of these examples where the v6 version is better than the
v4 version.

But, back to priorities. I want PI; all of this time wasted on
re-numbering should have been spent in fine-tuning the Quake aiming
proxy, this is unacceptable. I want PI.

[RFC4193] and here it is! We could not route RFC1918 on the public
internet because addresses were ambiguous, but now that we have dropped
the scoped architecture and that these addresses are reasonably unique,
problem solved. All that we need is a little financial incentive to ISPs
so they forget to read the RFC and therefore forget to filter FC00::/7;
unless site-locals there are no technical difficulties or special
handling issues. From the ISPs point of view, it's a no-brainer in the
short term: more money, less work. At the current rate of IPv6 adoption
the size of the global IPv6 routing table is not going to be a problem
any time soon.

Besides, I own shares of a large router vendor, and they're not doing as
good as they used to. Allowing everybody to advertise their FC00 prefix
on the public internet is a unique opportunity to provide router vendors
with an excuse to roll out yet another forklift upgrade. As always they
will manage to produce routers that have limited expansion capabilities,
making them obsolete fast enough to maintain a healthy forklift upgrade
cycle of two to three years, which is great for the bottom line. Wall
Street will like it, and the timing will be perfect for me to cash out
these shares at their peak just before I retire. How could we ignore
such a business opportunity?

Now that the PI problem is solved, I want private addresses. It's a lot
easier to design the v6 network by copying the v4 design, and I need my
brainpower to focus on the Quake protocol to produce a better aiming
proxy so I can frag my buddies and win all the time.

> You can still use FEC0::/10 even though the special case handling
> will be removed from future implementations

Absolutely not. First, FEC0 addresses are ambiguous (/10 not big enough,
which is why /7 was picked for RFC4193), and I don't want to fall into
the renumbering business again when merging companies. Second, I'm
worried about some remains of special handling. Therefore, it is much
better to hijack any unicast address. It's actually a lot easier than
what we did prior to RFC1597: since addresses are plentiful, someone
will quickly come up with something similar to http://wiana.org/
allowing me to register my hijacked address and insuring its uniqueness.

And finally of course, I need NATv6 to allow my unique hijacked private
IPv6 address to be translated into a publicly routed FC00 address, and
my design is complete. I do need to keep NAT under strict control in
order to maintain continued employment, but unique addresses both inside
and outside ensure that I will be able to maximize office hours to
finish pet projects instead of doing real boring work. Besides, as
everyone knows NAT is evil, and I need a scapegoat in case something
goes wrong.

Iljitsch, come with me to the dark side. I will show you the true nature
of the force. Together, we will defeat the emperor and rule the
Internet. It is your destiny.

Michel.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 5 Apr 2006 15:32:37 +0200

> From: Michel Py [mailto:[email-masked]]
> Unfortunately some protocol purity zealots still have to realize
> that Linksys, Netgear, Belkin and consorts don't sell NAT boxes
> because they think NAT is good, they sell NAT boxes because
> consumers want to buy them. 

I do not think consumers in general want to buy NAT boxes, but
they are forced to do so by ISP's who do not give them a choice.

When not even those of us who can differentiate between different
Internet connections by other means then "speed" can manage to get
a proper Internet connection (e.g. with multiple fixed addresses),
how can we expect regular users to ask for such "advanced" features?

Myself, I am stuck with a telco-ISP that do not even provide
the option to buy extra IP-addresses (or fixed addresses). This
means I am forced to run a NAT at home, and do the tricks to 
make applications work in this environment (including making
servers work, which of course "is not allowed", but why should I
care).

At several occasions, friends have asked me why some of their
communications applications do not work although they have "a
premium Internet connection", which meant they had purchased
the highest "speed" available. Unfortunately, they have all
been fooled by the ISPs that the only difference between different
Internet connections is the maximal throughput, and they have
ended up in a crappy NETed home environment.

But why should ISPs be honest and explain to regular users 
that there could be better alternatives and that what they are
currently selling is a restricted Internet connection? For ISPs,
these restricted connections means users have problems running
some applications, which reduces the traffic they generate, but
the problems users have are not attributed to limitations in what
the ISP provides. Only some ISP's openly declare the details of
the Internet connections they provide, such as whether IP addresses
are fixed or dynamic, if one can get multiple addresses, if IPv6
can be provided, etc. However, some do, and therefore I still
believe there is hope, but it is hard for regular users to
understand what different alternatives would mean (especially
when ISPs are not honest with these matters).

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Apr 2006 13:24:52 -0700

At 11:23 AM -0700 4/5/06, Michel Py wrote:
>  > John C Klensin wrote:
>>  It is simply not possible to configure those devices
>>  to support use of static public addresses for hosts
>>  on the LAN side.
>
>First, this is totally false, see below.

No, it is *partially* false, but unfortunately true in many cases. 
Some SOHO devices allow to use the outside IP addresses on the 
inside, and some don't.

More importantly, some that say they allow you to turn off the NAT 
don't actually work. In the VPNC test lab, we have found some SOHO 
systems (from more than one vendor, based on code from more than one 
OEM) where turning off the NAT using the GUI didn't do anything: the 
NAT was still in force. The vendors had to fix their software before 
they could continue with our testing because we explicitly do not 
test with NATs (except for our upcoming testing of IPsec 
NAT-traversal interop).

The VPNC members were fairly happy to have discovered sooner rather 
than later that their NAT configuration was not what they thought it 
was. They were not happy to have to fix their code, of course, but it 
is better to have to do so early in the shipping cycle before the 
customer support calls come. On the other hand, one vendor who has a 
series of boxes that cannot have their NATs turned off said that they 
essentially never get complaints about it, even though the 
always-NAT-no-matter-what "feature" is not listed on the box.

Assuming that the system documentation is correct in this area is not 
a good idea, at least from the hands-on experience in our lab.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Michel Py" <[email-masked]>
Date: Wed, 5 Apr 2006 16:54:25 -0700

> John Calcote wrote:
> I'll just jump in here for a second and mention also that vendors
> offer what they have to, not what they can. They want to provide
> the most "bang for the buck", so to speak. These companies don't
> offer the multiple-static-ip-address option today because most
> ISP's don't offer it to home users and home (SOHO) users represent
> the target market. That said, they *would* offer these features
> if SOHO users were constantly frustrated about the fact that they
> can't make use of the multiple static addresses that their ISP
> provides them because of limitations in their router equipment...

Exactly. As I said many times: vendors sells what the market wants to
buy, and IETFers do not make the market.

John,

> John C Klensin wrote:
> "spreading disinformation" is a rather strong claim; not
> one I would choose to make without actually examining the
> devices and their manuals, not just the marketing
> descriptions you cite below.

I have personally configured non-NAT on a least a dozen different of
these boxes.

> At least part of the problem are some constraints that,
> as a simplification, I didn't mention.

I can see that now, but your original text said nothing.

> The two most recent ISPs I've dealt with personally, and two
> more I've deal with on behalf of friends I was trying to set
> up, all insist on owning control of the front-end CPE
> "modem"/ "router" equipment. They do not permit (by Ts&Cs,
> password control, etc.) the customer to reconfigure that
> equipment to, e.g., operate it in bridge mode.

Common issue, then ask the ISP to reconfigure it in bridge mode
themselves. If the contract says you get public IPs this means these IPs
available for your hosts, not for their router. I never had an ISP
refuse to do this, it's quite easy at time of installation to call the
sales droid and tell it that if they don't configure their stuff to
deliver your public addresses on the LAN side they can stick it. Sales
droid wants his commission, sales droid talks to the techs.

Other method: spend $20 on eBay for a DSL "modem/router" that you have
control of. It is not illegal to swap their modem for yours, and if you
ever have to call their support (you know, the guys that ask for 1/2
hour if the power is on and if the lights are green) just plug their
modem back for the time of troubleshooting and the put yours back when
done. For this very reason I kept the Alcatel aDSL modem that PacBell
sold me 7 years ago although I have used at least 4 different ones.

FYI, in the latest AT&T (formerly SBC formerly Pacific Bell) aDSL
self-install kits that they ship, the password to admin the NAT box is
on a sticker underneath the box. Before, techies still knew that it was
the MAC address or the serial number of the box. They actually want you
to try to configure the box, mess it up, and send you a tech and bill
$200 to fix it. Also, they were tired of people clogging their support
to ask how to make this of that work. New method: if it does not work,
see your software vendor.
ISPs that survive and grow provide what their customers ask for, and
admin access to the CPE device to open ports is one of these demands.

> The number of static addresses available or in use is
> quite small, typically a /28 or even a /29.

In my experience, /29 is good enough for a typical home and /28 for a
typical small office. If you need more you fall into the medium business
category and allegedly have the $$$ that go with it.

> Finally, I need a device with the ability
> to specify port priorities

Your requirements are way over the typical user. If you have
requirements that represent 1% of the demand, you will not be able to
use the canned solution that fits the masses. Possibly not because of
technical reasons but for business reasons: vendors might think that if
you have such requirements you have the money to pay for them (which is
partially justified by higher support costs). If you don't find what you
need in el-cheapo mass-produced consumer stuff it's not because vendors
are trying to screw you but because your business does not represent
enough money for them to take action.

> and to supply some firewall capability.

There is no cheap firewall solution unless you call "firewall" what
comes with a $20 NAT box.

> In the case of the Linksys device, the documentation is
> fairly clear that the address space on the WAN-side
> needed to be disjoint from the address space on the LAN-side.

This is the case also for many others even "high-end" ones such as the
Cisco PIX firewall (last time I checked). Your requirements are
different than the masses, you have to use the box that fits your
requirements. The fact that very few firewalls support bridging is
simply due to the lack of demand.

> A solution to this is that either the ISP-supplied CPE
> or the internal router device operate in bridge mode.

Indeed and I do acknowledge that many firewalls do not, which I found
myself to be a pain. But you still have two avenues:

1. A router/firewall that bridges. Besides the sonicwalls, the D-link
DFL-600 has a non-NAT DMZ capability; I think that the Netgear FVX538
and the Trendnet TW100-BRV304 do the same but have never used them.

2. A CPE device that bridges and has good enough firewall capabilities.
There are many you could also use, pick the one that fits. Also, (for
aDSL) consider a Cisco 857 (less than $300). Never configured one
without NAT, but the IOS subset is decent.

> It is that "bridge" mode that is critical. As I indicated
> above, neither the Linksys nor the Netgear devices provide
> it.

Because they are not CPE devices. What's the purpose of a NAT box if you
don't use NAT?

> running the ISP's interface device in bridge mode,
> which many (although perhaps not all) ISPs prohibit

You're not talking to the right person at your ISP. Or you need to
switch ISPs.

> This sounds a lot like "NAT doesn't really break anything".

For 95% of the users and for users that are behind a firewall especially
a stateful one, where things might be broken before they reach NAT
anyway.

> If I pretend I'm a regular user for a minute, I can tell
> you this is not the case. When I used NAT for my Powerbook

Powerbook: 2% of the market. You are not what I call a regular user.
Vendors are not going to double the dev and support cost of a $25 NAT
box to support everything man ever invented. Macs just don't have enough
of a market share to be in the radar of the el-cheapo NAT box.

> Given the market place realities the IETF should be careful to
> make its protocols interoperate with NAT whenever possible, but
> don't think for a minute that adding NAT workarounds solves the
> problem completely.

I don't.

> Here in the Netherlands ISPs generally give out a single real IP
> address to their customers, but most customers use a DSL or
> cable modem with NAT or an additional NAT router or wireless base
> station so they can connect more than one computer. Despite some
> individual reports to the contrary, I believe the same is true for
> most IP users.

So do I. At least in Europe and North America.

> However, some ISPs already perform NAT for their customers in
> their network, and that's only going to increase as IPv4 addresses
> become more scarce and eventually run out completely.

In some countries.

> At that point, many people will be behind two layers of NAT.

Predictable. Works to check email and surf the web; more difficult to
host services.

> Also, reserving ports will be very hard because many systems
> share one real IP address. Maybe it's just me, but I don't see
> the IETF or anyone else for that matter coming up with something
> that allows communication between two people who are both behind
> two layers of NAT with any modicum of reliability.

Matter of money once again: Pay 5 bucks a month to have your public IP
or pay nothing to have 16 ports forwarded to your private IP behind NAT.
When configuring apps you just have to use these 16 ports instead of
picking randomly in the high range. It's el-cheapo crap solution but
still would deliver enough for 95% of the demand. Frankly, half of my
relatives would not need more than this.

> So in addition to supporting NAT where reasonably possible, the
> IETF should also continue to plan for a future where there is
> enough address space to make NAT unnecessary. However, universal
> reachability isn't coming back even if NAT is out of the picture
> because people love to run firewalls that break way more stuff
> than intended.

Which is partly why there are few non-NAT firewalls, as the firewall
already breaks mostly the same things NAT does, which makes NAT a lot
less inconvenient than alone. No market, as people who can deal with a
firewall can likely deal with NAT at the same time.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 11 Apr 2006 10:14:56 -0700

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