--On Wednesday, 05 April, 2006 22:24 +0200 Iljitsch van Beijnum
<iljitsch@xxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf