Dan Lanciani wrote: > ... Attempting to pigeonhole > each aspect of that isolation (and offer limited solutions) encourages a > divide-and-sweep-under-the-rug attack.
Recent evidence around the IETF supports this claim, but in the real world where NAT is seen as the single solution to all the problems, we need to break them down to show the alternative solutions to each. > 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. If I missed something it was only for lack of awareness. Please send details off line. > ... > Umm, yes, I think I participated enough in those threads that I > do not need > to refer to them again... Just trying to be complete without rehashing ;) > ... > |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. If a provider is going to offer me a single address, I will insist on a globally routable IPv4 one, then push their service down a layer with the other (irrelevant to the end user) lower layer wrapper technologies. If they do the right thing and provide a prefix, there is no need for them to know about the site privacy policies. My point was targeted more at those that claim nat obscures the origin host, therefore provides some degree of privacy isolation. > > |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). Current policies are fed by the resource scarcity, which over the short term is artifical, but over the long term is real. We haven't gotten the correct version at the nav6tf web site yet, but a paper there will show that we will need well over 400 additional /8's to get a single address to 20% of the population outside the countries that already have one or more for 20% of theirs. This is for an HD ratio of 90% which is well in excess of the pain threashold documented in RFC3194. Taking that down to current practice of 85% more than triples the number of /8's required to well over 1300. And again, that is only to provide one address to 20% of the population in those countries that don't already have that many. Take scarcity off the table, and it will be difficult to maintain per address costs if there is any competition in the environment. > 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. I agree, so we need to be documenting all the cases we can find for why network managers will demand isolation from SP provided addresses. > > 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. I agree that some approaches will disenfranchise some historical institutions, but I don't think that is what is holding us back. There is also an irrational fear of policy intervention (read that as ITU), which would make the PI approaches like mine or the city focused ones tractable to the routing system. > 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. That is why I have lobbied that we need to be solving both the local use & the PI problems at the same time. They solve different problems, but if we only provide one, it will be abused to solve the other. > > 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. Well just because the IETF buries its collective head in a dark place does not mean network managers will do away with scoping. After all the IETF definition is just a formalization of the hacks they were already doing. > > |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. I really don't care if the ISP gets more money, as long as those responsible for the lack of alternatives are the ones footing the bill. It is good to have a financially healthy ISP to rely on, just not at my expense ... Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
