Margaret Wasserman [mailto:[EMAIL PROTECTED] wrote:
> Hi Jeroen, > > >In IPv6 every enduser should have enough IP's simply > >because of the simple rule [...] > > > >Nevertheless customers should never have any need whatsoever for NAT. > >If there once is a need for it IPv6 'failed' as it didn't get up to > >the primary need for IPv6: More addressspace so that > everything can be > >e2e. > > Unfortunately, there is another reason why enterprises use > NAT that has not been addressed in IPv6: provider independence. > > Enterprises do not want to be "held hostage" to a particular ISP based > on their address usage -- they want it to be cheap to move > between ISPs to gain rate advantages, and they don't want to be adversely affected > by ISP closures, mergers, etc. By using internal addresses inside of > their network, and using NAT to reach the global Internet, only a few > systems need to be renumbered when ISP-provided global addresses change. These enterprises apparently don't want/require/need global reachability for their hosts. Otherwise they would not NAT. IMHO the real solution to this and some other problems we are currently seeing in IPv6 is really one thing which must be solved before anything else: IPv6 Multihoming Another solution could be a good document outlining all the problems along with possible solutions when a network gets renumbered. IP renumbering isn't that much of a problem but renumbering the configuration items which contain IP's is. > So, if we don't come up with a way to allow > provider-independent address > allocation in IPv6, we will probably get IPv6<->IPv6 NAT. We don't want PI because that would also imply a routingtable explosion. PI thus is not the answer. <SNIP> > In the meantime, though, I wouldn't object to a statement in the IPv6 > node requirements that says that you MUST NOT translate source or > destination addresses in forwarded packets... even though I don't > think that it will actually stop anyone. I do agree for the fact that this would overcome a NAT. But I see one quite legit reason for rewriting the source/destination. Though it could quite probably be solved in a different way: loadbalancers. A loadbalancer can easily rewrite the destination IPv6 IP and then route it to the destination back-end which won't notice that it's held behind a loadbalancer. On outgoing the loadbalancer rewrites the source IP to that of the loadbalancer. The boxes behind the loadbalancer can simply be on a /64 which is not routeable to the internet or even easier: link local Thus the loadbalancer is simply a NAT which spreads incoming connects evenly over the backends which are alive. Note that I would really like to see a loadbalancer which sports both IPv4 and IPv6, as this would make many sites which actively use loadbalancers actually start providing theirselves over IPv6. Taking a, imho, good application like the above in view NAT should not be forbidden... (Then again, the loadbalancer could just also have all the backends configured with the global IP and just forward the packets to the correct box... hmmm ;) Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
