On 19 feb 2008, at 14:20, John C Klensin wrote:

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

Is this important? The external address(es) are still different.

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

There are three options:

1. Port overloading NAT
2. 1-to-1 NAT
3. Stateful firewall
4. Nothing

It looks like you're talking about 1., while most people assume that  
IPv6 requires 3. Also, IF NAT is deployed in IPv6, it's not a given  
that it's 1. rather than 2.

Personally, I'm happy with 4.

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

Untrue. The only problem I've ever had with stateful autoconfiguration  
is a delay when the initial router solicitation wasn't sent or  
received. With DHCP for IPv4, I've had problems on numerous occasions.  
Also, NAT is completely orthogonal to address configuration.

Service discovery still has room for improvement, but generally, it  
works quite well. The IPv6 equivalent of http://192.168.1.1/ to  
configure some piece of equipment isn't fully formed yet, but it  
certainly doesn't require NAT, even if it requires stable addressing  
and more sane service discovery can't be used for some reason.

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

Really? I've never seen such a box. NAT of course completely breaks  
multihoming because your sessions die when there is a rehoming event.  
I'd much rather run shim6, which requires nor supports NAT.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Reply via email to