Gert,

Gert Doering wrote: Maybe I should be more precise on that. We're talking for example about the address space to be used by the RIPE NCCs DNS servers, doing reverse delegation for 6.0.1.0.0.2.ip6.{int,arpa}. The NCC is multi-homed to about 90 ISPs today, many of which are now starting to offer IPv6 services, natively delivered over the AMS-IX exchange. People want to see this service so that they can do v6-only stuff, without the need to go to ns.ripe.net's IPv4 address.

I understand this.

6to4 is not an answer in this scenario,

For the specific example of DNS roots, it is definitely not the best. Your original post did say anything about that.

neither are "use a /48 from each of the upstreams"

Why not? All of the upstreams is probably overkill, but from three or four big ones? What you are looking at here, in terms of redundancy, compared to the prefix leak, is _some_ resolution failures when one of these "five nines" upstreams is down, opposed to a total failure if the one ISP you choose to leak the prefix has a major routing issue. Large operators will lose a pop from time to time, I can remember some tier-1 losing the entire North American frame relay for 24 hours, can happen to anyone. By using one PA address, you still are vulnerable to some forms of single ISP failure.

"get a globally unique prefix" (because that network is *not* special enough to warrant an exception from "end sites do not get an allocation")

Agree.

Which leaves "leak more-specific", which would solve that problem quite well.

As of today, I think that "use a /48 from each of the upstreams" is a less risky option than "leak more-specific". This is debatable; I predict that you will have a hard time convincing people that "leak more-specific" brings enough short-term gains (especially given the fact that it still is having most of your eggs in the same basket) to justify the precedent of breaking the aggregation. At the risk of giving people bad ideas, let me tell you what will hear a lot should that happen: "You guys did leak your prefix in the DFZ to multihome your DNS. Your DNS is no more important than my business, and since you have shown the example I will cut a deal with my upstreams so they leak my prefix in the DFZ, too; if you're not happy about it you, though. You should not have started it in the first place". For the same reasons that apply to 'that network is *not* special enough to warrant an exception from "end sites do not get an allocation"', that network is not special enough to warrant an exception to filtering policies that will lead to a huge mess.

there are stronger arguments for "PA leaking" vs. "using PI and keep that forever".

I might be mistaken, but I do not think that either one is an open option at this time. Still the basic issue is unchanged - some people do not want to rely

on just one upstream, and for others (like the NCC) it doesn't make sense to confine their service to just one upstream. So what exactly are you talking about?

I am talking about locally unique, provider-independent, aggregatable addresses.

Any implementations out there that I could look at?

Go here http://arneill-py.sacramento.ca.us/ipv6mh/ and look at MHAP. There is no running code per say but simulations are under way. I suggest you refrain from posting "it does not work" before you read and understand it.

I'm doing my best to help developing policies and techniques that follow the pragmatic approach of "make it work today and avoid doing irrevocable damage in the progress".

This is very close to our line of thinking. However, breaking aggregation of PA space _does_ irrevocable damage in the sense that people will begin to build multihomed setups based on it. The argument "We can do it, but not end-sites" will not hold. Save for ISPs that receive a global allocation, any kind of "multihomed" setup you create today, DNS related or not, will need to be scrapped when IPv6 multihoming is deployed [if you want to undo the damage].

From a business standpoint, if I can get my business multihomed by cutting a deal with secondary ISPs to announce my primary's PA block, and if my business makes it to revenue-generating production, the only thing I want to do is continue paying my secondary ISPs to continue leaking my prefix in the DFZ. And they will do, because they want to keep me as a customer.

Allowing people to leak specific prefixes in the DFZ is pretty darn close to giving them their own. ISPs will not filter because they don't want to risk losing revenue, end-sites will not allocate resources to clean what's not broken on their end (the DFZ's routing table). Exactly the same mess situation we have with v4. Once a /48 leaks into the DFZ and is used for revenue-generating production, would you explain us what are you going to do to take it away? Michel.