ietf
[Top] [All Lists]

Re: Stupid NAT tricks and how to stop them.

2006-04-05 14:58:16


--On Wednesday, 05 April, 2006 22:24 +0200 Iljitsch van Beijnum
<iljitsch(_at_)muada(_dot_)com> wrote:

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

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

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



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