Interesting discussion. Keith is hitting all the nails on the head. Phillip seems to suggest that consumers buy NATs out of choice. They don't have any choice. I surveyed my final years students last month. Just four have a static IPv4 allocation for their home network, and only one has more than a /32 for use internally. ISPs just don't give you a choice (unless you are prepared to pay a non-negligible fee). If you deply IPv6 NAT, you may as well stay with IPv4. The first ISPs offering IPv6 are offering /48's here. The allocations to FT etc (they have a /19) are clearly made on the basis of end site /48's. See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt We have deployed IPv6 in our enterprise (throughout). We're seeing some early benefits from (student) driven new services. Students are also using transition mechanisms to enable simpler use of applications between homes (rather than battling a NAT out and a NAT in on communication paths). No regrets from deploying, no significant issues either for the existing IPv4 service. And there's more than just address space to take advantage of, like embedded RP for multicast applications. Tim On Tue, Mar 28, 2006 at 12:48:13AM -0500, Keith Moore wrote: > >In this case the benefit to running NAT on my home network is that it saves > >me $50 per month in ISP fees, means I have wireless service to the whole > >house and means that guests can easily connect. > > one immediate benefit to my running IPv6 on my home network is that I > can access any of my machines from anywhere else on the network (via > 6to4), as long as I'm not behind a NAT. my home network also has a v4 > NAT, so it's not as if they're mutually exclusive. > > >I have never seen a coherent, rational argument as to why the network > >numbering on my internal network should be the same as the network > >numbering > >on the Internet. > > obviously you've never tried to write a distributed application in a > NATted network. and presumably you never tried to do anything with UUCP > mail (which had naming conflicts) or a large DECnet (which had address > conflicts). the problems are immediately obvious to those of us who > have had to deal with those disasters. > > in brief: one reason is so that apps can have the same view of the > network regardless of whether they're hosted on your internal network, > or on an external network, or on a combination of the two. it's MUCH > simpler if apps don't have to worry about the fact that host A has > address A1 from network X and address A2 from network Y. particularly > since in a network with scoped addresses, hosts don't really have any > way of knowing which network they're on. > > there are other reasons also: routing, coherent network management, DNS > consistency. a network with scoped addressing is like a city where all > of the streets have the same name. it becomes pretty difficult to navigate. > > >People will still want to do NAT on IPv6. > > true. people do all kinds of evil things that break the net. our > protocols will only work to the extent that people follow the > specifications. when people start breaking things, the protocols and > applications start failing. NAT is a good example. > > in ipv6, we can provide better ways of solving the problems that people > think they're solving with NATs. if we fail to do that, or if people > insist on using NATs anyway, we're screwed. but that's not a reason to > give up without trying. > > either do something to help or get out of the way. > > Keith > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf -- Tim/::1 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf