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

From: "Michel Py" <[email-masked]>
Date: Wed, 5 Apr 2006 11:23:21 -0700

> 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. Second, if you want to use
public IPs on the LAN side you just have to plug your hosts directly in
the back of the {DSL|whatever} modem. Or use the firewall of your
choice.

> This situation would somewhat contaminate the results
> of the survey you suggest above.

Not at all, see above. Plus, read below also.

> It is worth noting in this context that many of the Router
> products that are sold for SOHO use (including the high-end
> products from the first two vendors listed above) (Linksys,
> Netgear) do not provide any support for multiple static
> addresses except via one-to-one NAT.

This is simply NOT true. Large numbers of SOHO "routers" can operate
with or without NAT and yes including the high-end products from the
first two vendors listed above.

Linksys RV042: http://tinyurl.com/zf7o8
Netgear FVG318: http://www.netgear.com/products/details/FVG318.php
And this is the norm. The one I use right now:
http://www.broadxent.com/products/8120.asp
and many more:
http://www.sonicwall.com/totalsecure/ts10.html
http://www.netopia.com/equipment/routers/routers_models.html
I have seen some of the speedstreams too and they all had an option to
run with or without NAT. Many of them also have the option to have a
"bridge" mode allowing the customer to provide their own router/firewall
solution.

> These are not ISP-imposed limitations, but limitations
> imposed by commercially-available products.

Please stop spreading disinformation. The proof is in the pudding, just
click on the links above. Maybe actually looking at what's out there
would help too.

Michel.

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Apr 2006 15:57:26 -0400

--On Wednesday, 05 April, 2006 11:23 -0700 Michel Py
<[email-masked]> wrote:

> First, this is totally false, see below. Second, if you want
> to use public IPs on the LAN side you just have to plug your
> hosts directly in the back of the {DSL|whatever} modem. Or use
> the firewall of your choice.

Michel, "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.   That said, I did somewhat oversimplify the
problem I described.  More detail, and a pair of partial product
reviews, follows below.  If I owe the vendors an apology, I will
apologize, but I will do so only in the presence of either
vendor documentation of how to do what is needed (user manual,
knowledge base article, or the equivalent) or a user-level
description of how to do it that the vendors will support.  See
below.

> This is simply NOT true. Large numbers of SOHO "routers" can
> operate with or without NAT and yes including the high-end
> products from the first two vendors listed above.
> 
> Netgear FVG318:
> http://www.netgear.com/products/details/FVG318.php And this is
> the norm.

Our experience differs, but this is not disinformation.  I'm
running an RV082 (the 042's bigger and more capable sibling)
here and consigned an FVG318 to the parts closet before getting
the RF082.    In both cases, I bought the products at retail and
struggled for some weeks, reading manuals and using the vendor's
customer support mechanisms and, in the RV082 case, taking
advantage of some additional support resources before reaching
the conclusions that I reached.

At least part of the problem are some constraints that, as a
simplification, I didn't mention.  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.
The number of static addresses available or in use is quite
small, typically a /28 or even a /29.  Finally, I need a device
with the ability to specify port priorities and to supply some
firewall capability.

One implication of this is that there is a little problem of
router co-existence: the customer-supplied device has to be
plugged into the LAN side of the ISP-supplied device, using one
of those static addresses as its WAN-side but supplying the
others to devices on the actual LAN.  In principle, it ought to
be possible to do that by setting up static routes, but (i)
neither vendor was able to specify how to do it and (ii) some,
if not all, of the ISPs configure their interface devices to
require that different addresses appear on the different ports
they supply.

For both of these vendors "can use static addresses" in
marketing literature apparently mean that one can use a static
address on its WAN side and can turn DHCP off, or run DHCP with
MAC-mapped addresses, on the LAN side.  Both support those
capabilities; the problem is where the addresses come from.
Actual experience with trying to set the devices up with a
static /29 pool of public addresses used on the LAN side of the
device and with the same pool presented to and used from the
public Internet were unsuccessful.

Disclaimer about the Netgear box: I haven't tried to use it with
static, public addresses for well over a year.  Perhaps new
firmware and documentation has been released and it has been
changed to better support these functions.  I doubt it somehow,
but perhaps.

In the case of Netgear, there is not a hint in any of the
documentation, or in their knowledge base as of a year or so
ago, that use of public addresses is possible.  After an
extended discussion with their technical support operation (and
an escalation or two), I was told that the device would not
support what I needed (i.e., public addresses on the LAN
identical to the public addresses by which the Internet saw
those hosts, with no NAT function of any sort) and that, if I
could trick it into doing what I was asking for, they would not
support it.   That led to a discussion about how they could
claim support for static, public, addresses, but that discussion
didn't lead anywhere.

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.  The
configuration software is even more clear: the options are
one-one NAT or some other device.  There has been a fairly
recent software release that permits the mapping between
internal (LAN) addresses and external (public) ones to be
exposed sufficiently on the LAN side that, if a device is
referenced from the LAN by its public address, the right things
will happen (after having the device running for slightly over
three months that way, I'm not convinced it works in all cases,
but the intent is clear).  But the LAN-side addresses are
required to be either private or user-supplied public ones, but
not the addresses that are presented on the public side of the
device.  In any event, that works, but it works by virtue of 1-1
NAT.

A solution to this is that either the ISP-supplied CPE or the
internal router device operate in bridge mode.  But the ISP
devices often cannot be configured into that mode (see above,
with no claim about other ISPs and what they will or will not
permit), and neither the Netgear nor the Linksys boxes can be
operated as bridges.  

> The one I use right now:

I have no firsthand experience with this device.

> http://www.sonicwall.com/totalsecure/ts10.html

As far as I know, all of the SonicWall devices, including one I
have used actively for some years, will operate as bridges.  But
they are significantly more expensive than the devices cited
above, are intended to be used on a monthly subscription basis,
and, at least in the units I have used, offer only the weakest
capabilities for e.g., port prioritization.

> I have seen some of the speedstreams too and they all had an
> option to run with or without NAT. Many of them also have the
> option to have a "bridge" mode allowing the customer to
> provide their own router/firewall solution.

It is that "bridge" mode that is critical.  As I indicated
above, neither the Linksys nor the Netgear devices provide it.
The SonicWall does, but raises other, unrelated, issues.  I
carefully did not address any devices I haven't actually used.
That leaves us in a state in which it is necessary to handle
static public IP addresses by either 

	* running the ISP's interface device in bridge mode,
	which many (although perhaps not all) ISPs prohibit
	
	* running the router devices as one-one NATs

which is what my note indicated.

> Please stop spreading disinformation. The proof is in the
> pudding, just click on the links above. Maybe actually looking
> at what's out there would help too.

See above.

     john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Apr 2006 22:24:12 +0200

On 5-apr-2006, at 21:57, John C Klensin wrote:

>> they all had an

> 	* running the router devices as one-one NATs

It occurs to me that there is nothing that prevents this exact same  
issue from coming up in IPv6. Even with an unpronouncable number of  
addresses, if you provide your own box that performs routing (which  
is generally a requirement for any kind of firewalling), the ISP has  
set up an address range to communicate with that box, and another  
address range that it forwards to that box for use behind it.

I.e., if the ISP provides a CPE box under their control and I have my  
own router/firewall, then I need a subnet between the two and at  
least one more subnet on another port of my router/firewall where my  
hosts reside. The first issue is that this makes getting a single /64  
from the ISP useless, and the second issue is that either there needs  
to be some manual configuration or there needs to be some kind of  
address provisioning protocol to be run between the CPE and the  
customer router/firewall, such as DHCPv6 prefix delegation.

(Note by the way that PPP can do address provisioning for a single  
address in IPv4 but it can't do this for IPv6, making stuff like IPv6  
over dial-up extremely hard to do.)

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Apr 2006 17:57:57 -0400

--On Wednesday, 05 April, 2006 22:24 +0200 Iljitsch van Beijnum
<[email-masked]> wrote:

> It occurs to me that there is nothing that prevents this exact
> same  issue from coming up in IPv6. Even with an
> unpronouncable number of  addresses, if you provide your own
> box that performs routing (which  is generally a requirement
> for any kind of firewalling), the ISP has  set up an address
> range to communicate with that box, and another  address range
> that it forwards to that box for use behind it.
> 
> I.e., if the ISP provides a CPE box under their control and I
> have my  own router/firewall, then I need a subnet between the
> two and at  least one more subnet on another port of my
> router/firewall where my  hosts reside. The first issue is
> that this makes getting a single /64  from the ISP useless,
> and the second issue is that either there needs  to be some
> manual configuration or there needs to be some kind of
> address provisioning protocol to be run between the CPE and
> the  customer router/firewall, such as DHCPv6 prefix
> delegation.

This was part of the point I was trying to make before the
"totally false" assertion arose.  The boxes can't magically a
small-address-range single subnet work because making it work is
tricky to do and trickier to support.  If the subnet is big
enough that one can plausibly throw half of it away (as might be
the case with an IPv6 /64), then there is an obvious trick with
subnet masks... but I believe that at least some of these
router/firewall boxes won't support it.  And neither many
hardware vendors nor many ISPs are particularly anxious to
support configurations that are tricky-- they cause (expensive
for the vendor/ ISP) support calls.

> (Note by the way that PPP can do address provisioning for a
> single  address in IPv4 but it can't do this for IPv6, making
> stuff like IPv6  over dial-up extremely hard to do.)

More of the same.

>From my perspective, parts of this discussion, in its many
repetitions and many forms, have become pointless to the level
of uninteresting.   Some of us believe that NATs are bad news
and harmful.  Others believe that NATs fall somewhere on the
scale between "harmless" and "actually good".  That debate has
turned into a religious war and cannot be settled -- presumed
facts presented by either side are simply ignored, or rejected
with claims stated in strong language, by the other.

By contrast, the question of whether IPv6, by itself, will
"solve" or eliminate NATs is one that is susceptible to
engineering evaluation and, IMO, suggests work that the IETF
ought to be doing.  Whether we like NATs or not, we need to
understand the forces that drive them and to understand that
those forces are not all about address space.  And, on that
basis, we need to look, again IMO, at both protocols and
policies to be sure that we have provided the tools for
permitting those who wish to get rid of NATs to do so.  If we
don't know how to build, and inexpensively support, a
router/firewall without address mapping, then we had better
figure it out.  If ISPs like NATs because they can't
economically handle the perceived higher support costs of every
end-user LAN having a slightly different topology, then we had
better figure out how to solve the underlying problem rather
than assuming that IPv6 will eliminate the NATs.  If, as
Iljitsch suggests, PPP (as now defined) isn't quite suitable for
supporting IPv6 over dialup, then someone better be looking at
fixing that -- and looking at strange-to-me setups such as PPoE
in the process.  And, if "everyone gets a /64" really doesn't
work because of outside-firewall and inside-firewall issues, we
had best either figure out how to change that restriction or
turn the allocation rule into "everyone gets two /65s", or do
something else to deal with the issues that can be standardized
and built into both equipment and user manuals.

Until that work is done, we, I believe, should keep our
expectations about IPv6 deployment to end-user LANs very modest.

    john