Margaret Wasserman wrote: > There is a big difference between IPv6 site-local addresses > (whether "full", "moderate" or "exlusive") and the use of > private addressing behind IPv4 NATs. Without NAT, nodes that > only have an IPv6 site-local address will not be able to > communicate with the global Internet _at all_.
Which some people consider to be a goal. > ... > The one-way reachability (outbound, but not inbound) that is > experienced by users of IPv4 NAT is a side-effect of NAT. No it is not. NAT is the act of mangling the header. One-way reachability is a filtering router. The fact that most common NAT products include filtering does not make filtering a side-effect of header mangling. > So, > if we are successful in avoiding NAT in IPv6, the "security" > models that depend on this one-way reachability won't apply in IPv6. Get real. Filtering WILL apply, because it is one component in a security model that IT managers will insist on. Their jobs are on the line, and they will use the tools they believe help. Filtering is not a complete security solution, but it is a layer that exists and it will continue. Please stop confusing the issue by associating NAT with security. > > >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 > > I'm not sure how IPv6 Multihoming applies here. Could you explain? I am not sure what Jeroen's point is, but one approach to the multihoming problem is to provide sites with PI space. Since this space is stable, the uses of SL space that simply need stability would be covered. > > > > 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. > > The simplest ways to provide PI addresses imply routing table > explosion. There are people (in the IETF, IRTF and > elsewhere) working on mechanisms for provider-independent > addressing that avoid routing table explosion. I certainly > hope that they will be successful, as that would solve a lot > of problems. Don't hold your breath. > > >Taking a, imho, good application like [loadbalancers] 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 ;) > > I don't have any interest in eliminating load balancers, but > are you sure that this is how they work? What happens when > the server passes its IP addresses in FTP, SCTP or SIP > packets (or any other application-layer protocol)? Does the > loadbalancer also translate those addresses to point to the > loadbalancer, or is it assumed that the client node can (and > should) reach the server directly in those cases? While it may not be the most elegant, one way to deal with this type of loadbalancer would be to use MIPv6. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
