--On Monday, 18 February, 2008 16:33 +1300 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
While it is surely a factor, I believe the dominant driver
for NAT is addressing autonomy.
For enterprise networks, certainly, coupled with multihoming.
But absolutely not for SOHO networks, where the dominant driver
is having address space for a LAN.
Brian,
I suggest that it isn't that simple. The following drivers are,
IMO, very important for SOHO networks. I won't try to judge
"dominant" but suggest that the first is very important to those
ISPs who provide connectivity and support to SOHO networks and
that, in many cases, they and not the end-user are the customer
for both equipment and addressing architectures.
(1) With NATs, every SOHO network (or at least every SOHO
network an ISP can claim with a straight face to support) has
exactly the same topology and addressing architecture. That
makes customer support much cheaper because one does not have to
figure out how to parameterize the little scripts from which
people select and read.
(2) Security and address-hiding. While we know that the
advantages of this via NAT are not significant, that hasn't
prevented the marketing hype and the selling on NATs --or NATs
plus a little packet inspection and lightweight versions of
other firewall functions-- on that basis. If one accepts the
belief that any marketing strategy that works is unlikely to be
discontinued, this motivation for NATs won't go away. Worse, if
we figure out how to eliminate it for IPv6, its effectiveness
for IPv4 networks will impede the deployment of IPv6.
(3) LAN configuration. While IPv6 autoconfiguration may be a
better solution, the available user-interface and user-useable
tools for managing LANs with NAT, DHCP, and MAC addresses are
far superior to anything we have available and well-documented
for NAT-less, multiple-address-per-host IPv6. That won't change
until the boundary devices change and due consideration is given
to the knowledge, skills, and patience of the typical "network
manager" of the SOHO network. This is probably a non-issue as
long as all of the machines on the LAN are pure clients but, as
Keith points out, pure-client machines are fairly rare and
becoming more rare. Certainly, as soon as one installs the
first on-LAN file server or printer, one either has to face
configuration issues or resource discovery protocols that tend
to work poorly (or at least to be confusing) as soon as there
are more than one device of a given type.
(4) Multihoming. While it may not be general or obvious yet,
I'm seeing a slowly growing trend toward wanting to attach SOHO
networks to two (occasionally more) ISPs, whether on a
load-sharing or a fallover basis. This is done in the hope that
both ISPs won't be incompetent on the same day and in
recognition that two "residential" connections are typically
still a lot cheaper than one "business" connection, even when
the latter comes with real support and an SLA. There are
relatively inexpensive and relatively easy-to-manage devices on
the market that support dual connections. They all use NATs,
even when the addresses facing one or both WANs are public.
There may be others, and probably are, but dismissing these as
unimportant is a way to become irrelevant, not to either get rid
of NATs or to encourage IPv6 deployment.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf