Dan Lanciani wrote: > Keith Moore <[EMAIL PROTECTED]> wrote: > ... > |NAT isolates customer networks from upstream address policies > only by severely > |limiting their functionality. > > ... do you really think it is reasonable to > demand that everyone give up what they need to have what you think they > should want?
A quick look at the archives for this list will show that he does (along with several others). That said, there are multiple parts to the isolation issue, and even though most NAT implementations combine them, the discussion will be more constructive to keep them separate. The internal app address stability issue is what the whole SL discussion is about, so refer to those threads for details. The access control feature is something any router can implement, so mangling the header is not the requirement for isolation. Concerns about tracability are dealt with by RFC 3041 addresses. That leaves address stability for external application use, in both a 'provider might change it' and multi-homing case. While a 'well written (tm)' app would not be aware of the mundane details of transport addresses, there are very few of those in the wild. Usually due to a belief that the app programmer can do a better job than the stack & remote infrastructure. I agree with you that getting apps to deal with addresses that might change under them is a bigger task than scoping, or even the effort to port to IPv6 in the first place. That by itself does not necessarily lead us to IPv6-NAT, but if IPv6-NAT looks like the lowest cost route to acheive address stability, it will happen. Said another way, removing one of the required attributes of stable addresses makes IPv6-NAT more likely, not less. The sad part is we have the tools to provide a lower cost & higher feature path for all but the multi-homed case (and a couple of proposals to deal with that as well), but can't get past the irrational fear of & trusting dependence on NAT. Until we get some applications to lead a few sample network deployments that show all of the isolation issues are dealt with in ways that don't require an IPv6-NAT, we will be stuck in an endless debate. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
