"Tony Hain" <[EMAIL PROTECTED]> wrote:
|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.
I used to believe this, but I recently came to the realization that isolation
from provider address policy is a single issue. Attempting to pigeonhole
each aspect of that isolation (and offer limited solutions) encourages a
divide-and-sweep-under-the-rug attack. Unfortunately, even those who are
strongly supportive of what they see as an important aspect of policy isolation
often ignore aspects that are important to others. N.B. I'm not saying that
NAT defines the model for isolation. Most NAT implementations combine most
(or even all) of the required address policy isolation with a number of other
features.
|The internal app address stability issue is what the whole SL discussion is
|about, so refer to those threads for details.
Umm, yes, I think I participated enough in those threads that I do not need
to refer to them again...
|The access control feature is something any router can implement, so
|mangling the header is not the requirement for isolation.
I agree that access control is not a part of address policy isolation.
|Concerns about tracability are dealt with by RFC 3041 addresses.
I have my doubts about this; it may backfire. If you tell your ISP that you
need more privacy it may be happy to oblige by increasing the frequency with
which your single valid address changes. Be careful what you wish for.
|That leaves address stability for external application use,
It also leaves address rental cost, and limitations on number of addresses
available regardless of what you may be willing to pay (at least within a
class of service). It probably leaves other things that I am forgetting. I
think this is a good illustration of the pigeonhole pitfall. If you fail
to address any one aspect of isolation and that aspect is important to enough
people, a NAT solution will appear to fill the void. That solution will likely
include all the "bad" features of NAT as well simply because it's easy and
people already understand the model.
The core issue appears to be that any comprehensive solution to the isolation
problem would disenfranchise the address allocation hierarchy (just as simple
PI allocation would), and we aren't prepared to do that. This rules out
obvious solutions like source routing (aka identifier/locator separation). It
also lobbies against overlay networks and similar work-arounds. Site-locals
as originally defined could have been tweaked to remove ambiguity and support
a large overlay network (there were plenty of bits) while the replacements we
are hearing about (if they come to exist at all) will likely have sufficient
punitive semantics to block such use on any interesting scale.
In some sense, the elimination of site-locals (and scoping in general) may
be a good thing. Remember, the question being discussed was whether IPv6
can provide a substitute for IPv4+NAT. At least this way the answer is
unambiguous, and deployers will be able to plan accordingly.
|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.
Absolutely. It's a very hard problem to solve. And (although I've asked
repeatedly during the site-local debates) I've yet to hear any assurance
from the application folks that they are even going to try. I fear that
complaints of application failure due to address fluctuations will be met
with suggestions to use a different ISP and/or send your ISP more money.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
