Dear Pekka, I have not seen you on the last RIPE meeting when we had a short update on my policy proposal for anycasted TLD nameservers which is referenced later as the 4th option for the hungarian nameservers.

I would be opposed to option 4.

...

...

4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region?

- I think this is the cleanest solution.

Can we discuss this issue on the working group or mailing lists?

I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html

In my opinion this can solve the problem....

I have not seen any discussions that think it is a bad idea to assign several network resources to TLD administrators which will enable them to operate their nameservers according to RFC3258. When we have reviewed the discussions we felt that your objection against the proposal was because of the size of the assignment. I'm planning to submit revised proposal with a reduced prefix length which better fits with other assignment policies. If you are opposing to the new proposal I would be glad to know as soon as it is submitted. If you are suggesting that .hu should start using IPv6 addresses from carriers to start deploying V6 with some of their nameservers and renumber them later as the V6 infrastructure matures I would agree. Looking at the query rates on V6 interfaces the impact of loosing one nameserver in the V6 cloud is not as crucial as in the V4 world at the moment. However this might change faster than sone people think at the moment making V6 anycasting of TLD nameservers a top priority for their administrators. Regards Andreas Baess -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess@denic.de

Dear Pekka,

Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough;

I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers.

2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended;

In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended?

3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically.

I have not limited my proposal to ccTLDs but includes any TLD.

In addition, a) we have enough address space that allocating a (v6) /32 is not waste.

If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix.

b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a).

I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist.

So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it.

As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess

[...] I am therefore against any proposal about anycast prefix allocations no matter whom and what it concerns. Do whatever you want between your peers if your agreement permits; just don't put the prefix in the dfz. I don't think it belongs there.

Hear, hear! Concisely put. Regards, - Håvard

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Michael.Dillon@btradianz.com Sent: 11. november 2005 15:10

...

I am therefore against any proposal about anycast prefix allocations no matter whom and what it concerns. Do whatever you want between your peers if your agreement permits; just don?t put the prefix in the dfz. I don't think it belongs there.

I think that some anycast prefixes *DO* belong in the dfz. However, I think that it is wrong to give out anycast prefix allocations to organizations whose only intent is to run their own internal services. The .de TLD is proposing that they should get a prefix just for their own anycast services.

We are probably thinking the same but have two different solutions for it. If you have a medium/large international network you can implement anycast without using prefixes assigned to you by the RIR for anycast usage. If you do not have a medium/large international network then you can contact someone who has. If this is a question about money then I am sure some network operator eventually will lower their prices to meet your satisfaction. Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers around the world at their collocation facilities. MCI may then assign DENIC one /64 prefix from their /32 prefix which will be routed to the closest DENIC server in MCIs network. Would this be a suitable solution? This /32 has not been given to MCI by the RIR explicit for anycast purposes. The other solution is that DENIC builds their own international network and do the same - as long as the prefix has not been given to DENIC by the RIR solely for anycast purposes. Cheers, Joergen Hovland

DENIC is providing a public service (namely: DNS for the .de TLD) - and *the whole world* wants to reach their DNS servers. (No different to .com and other large TLDs)

or anywhere else in the dns tree, tends of thousands of servers but i am sure denic is very important randy

Some final comments from me, -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering Sent: 11. november 2005 22:06

Yes. I think we can agree that there are lots of domain service providers that have 2, 3, maybe 5 name servers in their NS set (and those can grow without anycasting), and that there are some that really use up all that you can fit in those small packets, and want to provide even *more* resiliency. Looking at DNS, I see "lots of nameservers" primarily for root, and some gTLD/ccTLD zones. Haven't seen that for "further down" stuff (.co.uk is "sort of ccTLD" stuff).

Gert, you can configure 1000 anycast servers, all with the same IP address, in your own network no matter how small/large your network is. You can place them next to each other on the same rack or you can place 500 of them in your Frankfurt serverhall and 500 in Düsseldorf as long as they are in your network. You do _not_ need an anycast prefix from your RIR for this. Your growth problem is now solved. The next problem is that you want better redundancy(?). Then buy more connectivity. If you for some reason can't afford better connectivity, please look at my MCI example and put your servers elsewhere.

And really - I don't care who they are and what they do, but if they think it's a good thing to have more than 11 different primary name servers for whatever they are hosting, it must be important to them, and at least to whoever is providing the funding.

The second largest DNS zone in the world *does* sound somewhat important to me. I don't have query numbers to compare .com and .de requests/second (which would be more useful than sheer zone size), but I'd assume that there are also plenty of request for .de domains.

If it wasn't for the fact that I do business in Germany I couldn't care less if .de was dead or not. You can only decide what is important to you, not for the rest of the crowd. If you try you will find out that everything is important. To cover everyones needs we would need 42 billion prefixes in the global routing table. Most of it wouldn't make sense anyway, just like this anycast discussion is starting to get. Cheers, Joergen Hovland

That's the point. DENIC isn't doing this for themselves. They do this for *you*

in a peer2peer or client/server world, this statement is fatuous randy

...

...

That's the point. DENIC isn't doing this for themselves. They do this for *you* in a peer2peer or client/server world, this statement is fatuous So we abandon DNS, because it's a model from the last century?

you can if you want to. i did not suggest doing so, so i guess you would like to. whatever rocks your boat. my point was simple, aside from the total end user (ones not running edonkey or having bought sony cds), most hosts provide to others, certainly all interesting hosts. while folk who need to look up in the de namespace appreciate what denic does, i don't think they do it for free. so we'll withold the gold medals if you don't mind. randy

* Gert Doering:

...

Gert, you can configure 1000 anycast servers, all with the same IP address, in your own network no matter how small/large your network is.

That's the point. DENIC isn't doing this for themselves. They do this for *you* (and for me, and even for Randy).

From a technical perspective, there is no reason to give DENIC special treatment. I would even say that DENIC (or even DNS) is merely a red herring.

Has it already been decided that it's a good idea to port the IPv4 anycasting scheme to IPv6? Wouldn't it be better to start over with something which is more sound from a technical perspective? Just because addressing tweaks can solve a perceived problem, it doesn't follow that a solution based on addressing is the best one. This might be simply one of those "IPv6 will really take off when you do X" things. But given that IPv6 among DNS servers is rather widespread (in relative terms, of course), I'm not sure if this move is really necessary.

-----Original Message----- From: Hans Petter Holen [mailto:hph@oslo.net] Sent: 13. november 2005 00:30

What if I want to plan for more disasters than that ? Like MCI going out of business?

Hi, If you honestly believe that all 11 internet service providers which you are running your nameservers with (these 11 also run anycast and have multiple servers each) at the exact same time will go bankrupt and shutdown their network at around the same time then I don't think it is the nameservers we should worry about but the internet itself.

I guess I could agree with MCI to place some servers with their IP addresses outside their network and agree with other providers to carry my more specific routes. In order to have universal access and plan for any network failure I would have to sign such agreement with all ISPs.

Will it not satisfy your needs placing 200 servers at 100 (numbers randomly selected) MCI locations world wide using IP space assigned by MCIs /32? Or is this discussion simply about the fact that the /32 prefix is not yours and you want to use your "own"? Take the following: 1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is assigned from this /32. 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your ip is assigned from this /32. and 1 server at ISP g in London. /32 announced by your ASN through ISP g. It is your /32 1 server at ISP k in Amsterdam. /32 announced by your ASN through ISP k. It is your /32 What is really the difference here? Yes, ISP x, g or k can go bankrupt so you loose that redundancy in the first scenario. Any others? I can't think of any. Either way, there is no difference here network wise? You get exactly the same reachability/redundancy. So, should we alter the address policy because ISP x can go bankrupt and we need redundancy for that? You still have 10 more ISPs you have placed your servers at if you use all 11 IPs.

This could be a business idea for somebody: to set up an "anycast registry" - sign agreement with all the major ISPs to not aggregate my addresses. Then I could offer a guaranteed minimum routability for thoose prefixes.

For medium/large operators that wouldn't make any sense at all since they already have a global network and can do fully redundant anycasting anytime with any IP address. For smaller ones it might. Conclusion: I am against a policy that would let LIRs receive prefixes from RIRs when the intention is to use the prefix for anycast. I have hopefully shown that you don't need a dedicated prefix for that. It is a bad hack to the existing solution and as I see it, would give the same benefits. This bad hack is one thing. I am sure everyone can agree on that it is impossible to decide whom and what services should be granted anycast prefixes if it was accepted. The only solution would be to permit everyone or have some rule saying "you must have more than N anycast servers at Y locations" which basically again means that everyone can and will get a prefix. I am not against 42 billion prefixes in dfz. I am sure we will get there eventually:) I am however against the ones that don't make any sense. Cheers, Joergen Hovland

Hi, -----Original Message----- From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] Sent: 13. november 2005 15:32

In the first scenario you are forced to the routing policies of ISP x and only to the locations of ISP x. In the second example you can co- locate, connect to and IXP and do your own routing decisions as well as be present at locations you choose (without "vasting" or even having to go to 11 servers).

You will always be forced to obey the rules of whatever provider you are using, ISP or IXP. I get the impression that you believe ISP x's routing policies will always be insufficient for you. Nameservers are not the only anycast service so it would be tricky to discuss this in general. But you want your nameserver to be reachable, that I know. Both scenarios will accomplish that with the same amount of redundancy. What kind of routing policies do you mean? Do you want to restrict your reachability? Joergen Hovland

Having listened for a while 'cause I am neither an expert in anycasting nor in running name services for a large zone, I'd like to step back a couple of yards/meters/<put your distance unit here>.

From that perspective I seem to see 2 aspects in the recent discussion:

- you shall not receive address space for builing a service, you are to buy that from some "big-folk". This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities. Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-) - there has been th discussion regarding "anycast" but isnt this just a special(?) case of th PI-topic? I might easily have overlooked something, pls. see my initial disclaimer. Wilfried. Hans Petter Holen wrote:

Jørgen Hovland wrote:

...

The next problem is that you want better redundancy(?). Then buy more connectivity. If you for some reason can't afford better connectivity, please look at my MCI example and put your servers elsewhere.

What if I want to plan for more disasters than that ? Like MCI going out of business?

I guess I could agree with MCI to place some servers with their IP addresses outside their network and agree with other providers to carry my more specific routes. In order to have universal access and plan for any network failure I would have to sign such agreement with all ISPs.

This could be a business idea for somebody: to set up an "anycast registry" - sign agreement with all the major ISPs to not aggregate my addresses. Then I could offer a guaranteed minimum routability for thoose prefixes.

What we are discussing is really to make this mechanism available by addressing policy. Traditionally the RIRs does not set routing policy.

Hans Petter

_______________________________________________ ipv6 mailing list ipv6@ls.aco.net http://noc.aco.net/mailman/listinfo/ipv6

Hello Jørgen, my responses to three emails from you to the lists, jorgen@hovland.cx (Jørgen Hovland) wrote:

Will it not satisfy your needs placing 200 servers at 100 (numbers randomly selected) MCI locations world wide using IP space assigned by MCIs /32?

Certainly not - why should one be satisfied with such a pseudo-solution? A service provider (we _are_ talking about Internet infrastructure service providers currently, keep that in mind) that has come to the conclusion they want to "anycast" (aka shared unicast) their services, surely has thought about going to a big ISP before and decided that that' not what they want.

Or is this discussion simply about the fact that the /32 prefix is not yours and you want to use your "own"?

It is - currently, talking DNS providers - about the fact that you cannot accumulate too many server addresses in a DNS UDP packet.

Either way, there is no difference here network wise? You get exactly the same reachability/redundancy.

Only if you limit your thoughts to a very small world. Sorry, but the fallacy of your argument is so obvious that the words fail me here.

I am against a policy that would let LIRs receive prefixes from RIRs when the intention is to use the prefix for anycast. I have hopefully shown that you don't need a dedicated prefix for that.

No. You have shown that _you_ don't need that. You try to decide here how other people run their services. I honestly believe that's none of your business, but up to the respective service provider. You can give them good advice, of course. But you must be open to accepting arguments for the way they intend to do it. jorgen@hovland.cx (Jørgen Hovland) wrote:

You will always be forced to obey the rules of whatever provider you are using, ISP or IXP. I get the impression that you believe ISP x's routing policies will always be insufficient for you.

The problem arises when the sole ISP's routing policies are insufficient at _any_ point in time.

Nameservers are not the only anycast service so it would be tricky to discuss this in general.

DNS is a special service (UDP packet size stuff) and needs a special solution - unfortunately. jorgen@hovland.cx (Jørgen Hovland) wrote:

Hi,

-----Original Message----- From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] Sent: 13. november 2005 15:32

...

In the first scenario you are forced to the routing policies of ISP x and only to the locations of ISP x. In the second example you can co- locate, connect to and IXP and do your own routing decisions as well as be present at locations you choose (without "vasting" or even having to go to 11 servers).

You will always be forced to obey the rules of whatever provider you are using, ISP or IXP. I get the impression that you believe ISP x's routing policies will always be insufficient for you. Nameservers are not the only anycast service so it would be tricky to discuss this in general. But you want your nameserver to be reachable, that I know. Both scenarios will accomplish that with the same amount of redundancy. What kind of routing policies do you mean? Do you want to restrict your reachability?

Joergen Hovland

jorgen@hovland.cx (Jørgen Hovland) wrote:

...

From that perspective I seem to see 2 aspects in the recent discussion:

- you shall not receive address space for builing a service, you are to buy that from some "big-folk".

This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities.

Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-)

You did not comment on this part. Why?

jorgen@hovland.cx (Jørgen Hovland) wrote:

...

Certainly not - why should one be satisfied with such a pseudo-solution?

Because that’s what everybody else are doing? That’s why we currently have 600 routes in dfz and not one per server on the internet? Should DNS be excused only because the protocol itself supports a finite amount of IP addresses?

Should SPs be forbidden valid, redundant, Tier-whatever independent, autonomous solutions because we don't want an arbitrary number (prefixes in the DFZ) to change? As much as I don't like a big DFZ, as much I'm obliged to let the service provider decide on how they want to conduct business.

...

Only if you limit your thoughts to a very small world. Sorry, but the fallacy of your argument is so obvious that the words fail me here.

Could you be more specific? I am sure there are ISPs that are not willing to sell anycast services, but if you have buyers then the sellers will always show up eventually.

I'll try to be a bit more specific. I think about those big ISPs and how they are present in some regions, but not in others - tough luck if you chose them - should have chosen another, so renumber your ccTLD server. I think of this big ISP not peering with regional ISPs, Tier-3+ etc.; well, you should have chosen a Tier-2 or -3 then. But again, they are not present, where you need it. I think of connecting directly to regional communities at IXes. I think of delivering special services to special target audiences. I can think of some more things, all of which can be solved by making a compromise here and there. But everything taken together, (a) the compromises you have to make don't make a coherent picture (some cancel each other out) and (b) there's maybe still things left over you cannot cover.

...

No. You have shown that _you_ don't need that.

Obviously some people have different needs. It is good that we try to figure those out.

I'm still not sure why we are talking about how businesses should provide their services here - it's not our concern, really. We are not the judges of other people's decisions (sometimes I'd like to, yeah...).

...

You try to decide here how other people run their services.

No, I am trying to prevent excessive defragmentation of the routing table.

I can see what you're trying to do, and that is a good thing in itself. It nonetheless needs tampering with other people's decisions, and that's nothing you can do freely. And that's why I'm saying that you're trying to take over the service provider's engineering and operations departments.

I am trying to prevent a special case of PI where you are not even required to have your own network. The requirement to this special PI case is so low that anyone would be able to apply for it - and anyone _will_ apply for it.

Well, in the least, anycasting a service costs money (setup aside, operations costs money, too, transit line cost money, etc). So it is pretty unlikely "anyone" would apply for it. Well, maybe anyone, but not everyone. But you're trying to lure us away from the proposal we're discussing which states a special case of DNS for _ccTLDs_, which some people may consider Internet infrastructure (I mentioned this in my previous email). So back to the topic - I have no problem with _all_ ccTLDs and gTLDs applying for five prefixes each.

The packet size thing is a general design problem. As far as I know, there are currently two methods to solve it:

* EDNS0 * TC flag

Which are fine for any non-TLD provider to presume. TLD operators need to find a way to service all the folks, even those with broken resolvers.

...

...

Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-)

You did not comment on this part. Why?

I was probably just a bit unclear. "All you need to do is to create a network and ask for address space.." There is no monopoly threat as long as you follow the requirements. If the requirements are too strict, then it would become a problem. Currently, I think they are not.

The requirements for v6 space in the RIPE region includes having transit customers (at all, the 200 is just an arbitrary number). No ccTLD registry that's not also conducting other business may receive an allocation. That's the entire point of the special case being made. ccTLDs cannot deliver services in v6 like in v4. This - IMHO - is a v6 showstopper. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---

At 11:19 14/11/2005, Jørgen Hovland wrote:

So we are back at the beginning; I say no to anycast PI for TLDs/ccTLDs. I don't believe it is a special case so it doesn't need a special policy. TLDs/ccTLDs could/should however be used as an argument to allow v6 PI prefixes in general. V6 PI compared to v4 surely is a showstopper for many, or at least for some.

It's a showstopper for us on one of the networks we manage. We can't get V6 PI for it like we could v4 PI. -- Tim

Please. We have been through this part of the discussion half a year ago, and we've asked those that know (the DNS WG) and they tell us "we can't rely on EDNS0, and truncation is bad". It would be very helpful if you could do us the favour and read up on old arguments in the archives.

Really? I always got the sense of earlier comments (not here, though -- I seem to recall this from IETF circles) saying that if you're running so newfangled software that you speak IPv6 you would be expected to also implement EDNS0. Regards, - Håvard

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering

I read into this that you are afraid that the initial criteria are not strict enough. As far as I can see, the criteria are pretty explicit, and verificable.

If you mean afraid of a large routing table, then the answer is no. From the archives you might see that I say "who cares, it's the vendors problem". Anyway, as I said in the email after the one you replied to; I don't think there is anything special about DNS (it's just another protocol) so it would be better to discuss general PI allocations instead of specific cases of PI which is after my opinion a waste of time (but this discussion was not).

Please. We have been through this part of the discussion half a year ago, and we've asked those that know (the DNS WG) and they tell us "we can't rely on EDNS0, and truncation is bad". It would be very helpful if you could do us the favour and read up on old arguments in the archives.

It would be very helpful if you didn't assume I don't know what I am talking about.

To repeat myself: it's not the AP WG's job to tell the DNS WG how DNS works. We're making policy, (partly) based on the expertise of other working groups.

Ok, since I am with the DNS WG maybe it would be okay anyway to mention slightly off-topic but related material? EDNS0 works, just like any other working protocol. The problem is deploying it, also just like any other protocol - like IPv6. Since there is no critical problem today with IPv4, or DNS, there will always be problems deploying the next versions of it when the first people screams "hey this is not working!!!!". We could wait for it to happen. We could use it as an excuse to find temporary workarounds. We can even make special address policies for special cases that would give us more time, but sooner or later it is going to happen - because the protocol itself is not sufficient and that is your axiom. Please do give me comments, but I think I have finished discussing this topic now. Joergen Hovland

Florian & all, On 16 Nov, Florian Weimer wrote: [...] | It depends on the PI criteria. If slots in the global routing tables | are kept in short supply *and* you get at most one if you aren't an | ISP *and* you need to do IPv6 anycast, you might have a problem | because you need two globally visible prefixes (one for your | production network, one for anycast). | | But I think you are right that it makes sense to resolve the PI first, | either negatively or positively. ==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg". Then came the first draft proposel of Andreas in the AP wg asking for a /32 for ccTLDs wishing to deploy anycast. At that time, the wg said "let's not talk about "PI", which is still out of scope of this wg. Let's rather talk about specific needs of TLDs wishing to do anycast and see what we can do for them in termes of (micro-)allocation." Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem... If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution? Some people on RIPE mailing-lists are now used to coming after a consensus is almost reached and try to break everything just for the sake of building CLEAN solutions... (cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop. To recall only a few of the arguments for deploying anycast for a TLD, I would say: Redundance & Resilience against DDoS attacks, better global time response, a greater flexibility in adding and removing name servers without notifying IANA! Btw, I'd like to remind some of this mailing-list readers that the request of DENIC is not isolated since AFNIC asked even before Adndreas first draft for a constency between all RIRs in the way IPv6 allocation were made for "critical infrastructure". AFNIC has then strongly supported Andreas proposal from the beginning and hoped that the solution would come rapidly because AFNIC is still needing such a solution to start deploying anycast in IPv4 AND in IPv6 in a consistent way! I still hope this debate will lead to a concrete solution within the coming 3 years! Good luck :-) Mohsen.

Mohsen Souissi wrote: <SNIP>

Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem...

<SNIP>

(cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop.

"example.net DNS servers needs an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop." What makes .de more important then example.net DNS servers? I am quite sure that a large part of the world can live perfectly without complete *.de (especially older french people :) but would hate it when google.com (they have already a /32) or ebay.com or say cnn.com (the latter who don't have an allocation yet), are not reachable. These kind of sites also require what you want with 'anycast', a server as close as possible to the enduser for resiliency, latency, DDoS etc... For that matter .com/.net/.org don't have it (yet) either. My points for this, which are mostly also reflected in the proposal: - Special policy only for accredited ccTLD's - Give them a /32 (bigger is only filtering nightmare already) (in another message) Michael Dillon wrote:

If AFNIC and DENIC form a consortium to operate anycast deployments for TLD operators, then that is a different question entirely. I think it would be right for RIPE to allocate addresses to such a consortium just like we now do with other network operators.

You mean clustering up all ccTLD's into 1 prefix? Then why not have a single /32 with a caching recursive DNS server which answers to all queries, see section 4 of: http://unfix.org/~jeroen/archive/drafts/draft-massar-dnsop-service-00.txt But proposing that gets one into 4 holy wars I understood, especially the 'anycast' part seems to be very hurting to a number of people... Note also that clustering them together causes loss of diversity. Thus a /32 per ccTLD seems appropriate here. <SNIP>

I still hope this debate will lead to a concrete solution within the coming 3 years!

Only 3? :) If you really want to get over all of this use the current policy: just define DENIC and anything else as being an LIR (just pay some cash), providing end connectivity to 200+ *planned* sites. Those 200 sites consist out of: - 13 /48's for the anycasted PoPs - 1 /48 for the main office - X /48's for branch offices. - 100+ VPN connections to endsites (for management, employee 'dailin' etc). Done. Please read through: http://www.sixxs.net/tools/grh/dfp/all/ and see what kind of organisations have already got an allocation. Then go over to your favourite colo facility and see what equipment they have. I am quite sure that quite many don't have a lot of equipment (or customers). But they have planned it... and back to everybodies normal schedule.... Greets, Jeroen

Hi, On Thu, Nov 17, 2005 at 11:50:32AM +0100, Mohsen Souissi wrote:

==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg".

I'm not sure which WG you are talking about (IPv6 WG or LIR WG?), but it's certainly in scope for the address policy WG. The topic of PI space for IPv6 just has been avoided like the plague so far - nobody seems to be able to define proper criteria for IPv6 PI, and I'm fairly sure we will not be able to reach consensus for IPv4-style PI ("come and ask for it, and that's all you need to do"). Personally, I've seen some doomsayers so far ("IPv6 will die if we have no PI!"), but I can't remember having seen a proposal for rules that let "those that we all agree should have it" have PI, and "those that we all agree should not have it" not have it. Which reflects on the problem - there are many readers here that have good arguments against any sort of PI (that is not needed for DNS purposes, due to protocol constraints [brokenness]), and others see any possible alternative as "this is just not going to work" (read "I'm politically opposing this, and because it isn't PI, it is not acceptable")... so getting consensus will be tough.

Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem...

"We" aren't. These are just some comments by some of the participants. But of course "we" will, if someone formulates a specific policy proposal how to make PI work.

If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution?

It certainly is an European speciality to bring up the same discussion again and again without any new facts that might affect the outcome. DNS is special, in that the protocol is fairly broken, but too widespread to re-do over night. This warrants special cases for the root, and maybe special cases for *anycast* - but nobody is asking for special cases for normal unicast DNS servers. That's what glue records are for, and they work fairly well. DNS is critical infrastructure, but nobody has explained properly yet why "critical infrastructure" (in itself) requires a different way to get IP addresses. Even so, Google is likely more critical to more people than some of the ccTLDs out there... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Elmar K. Bins wrote:

How about: Every ASN is entitled to an IPv6 block. Full stop. Then you can tie it to independency of routing and to the rules for ASNs.

Anyone else think along these lines? Elmi.

Hear! Hear! I think even the routing-table purists will agree that 64K routes maximum size will be fine. I'm for this approach. -- Best regards, Cameron Gray Director Netegral Limited Registry: uk.netegral

Hi, On Sun, Nov 20, 2005 at 11:23:25AM +0000, Cameron C. Gray wrote:

I think even the routing-table purists will agree that 64K routes maximum size will be fine.

AS numbers are not really limited to 16 bits... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

as long as it's "something new", let's get a fresh subject line... :-) On Sun, 20 Nov 2005, Elmar K. Bins wrote:

Just to get the thing rolling again with something new :-)

gert@space.net (Gert Doering) wrote:

...

Personally, I've seen some doomsayers so far ("IPv6 will die if we have no PI!"), but I can't remember having seen a proposal for rules that let "those that we all agree should have it" have PI, and "those that we all agree should not have it" not have it.

How about: Every ASN is entitled to an IPv6 block. Full stop. Then you can tie it to independency of routing and to the rules for ASNs.

Anyone else think along these lines? Elmi.

this was the original ARIN proposal 2005-1, which could not reach consensus. The last time around it was re-worked to add more restrictions and again failed because other folks felt it was too restrictive. There are actually two issues: 1) the high cost of renumbering in a large organization 2) multi-homing for network reliability and resiliency the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-) It would seem obvious that as network connectivity becomes essential for doing business, it must be reliable. It is unwise to carry forward the IPv4 multi-homing model for network resilience with just faith that the system will be able to scale to an ever larger number of routes. IPv6 has so far failed to deliver on its original promise of seamless renumbering and multi-homing using multiple prefixes. The hard problems still need to be solved in a way that can scale for decades to come. regards, /Lea

On Mon, 21 Nov 2005 Michael.Dillon@btradianz.com wrote:

...

the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-)

A policy that says "if you qualify for an AS number then you also qualify for one IPv6 /32 allocation" does not run into any problems with 16-bit AS numbers. That is because you still have to qualify for the AS number before you can get the address allocation. Of course, after 16-bit AS numbers come in, some people may wish to make it easier to get AS numbers and we would probably want to change the address allocation policy at the same time.

If a policy works for 2 years, that is good enough. RIRs can change policies in a few months if there is a need.

this would create another "early adopter" bonus, now in the IPv6 space. some people believe that more fairness should be applied in this arena and we should learn from the mistakes of IPv4.

On Mon, 21 Nov 2005, Elmar K. Bins wrote:

lea.roberts@stanford.edu (Lea Roberts) wrote:

...

this was the original ARIN proposal 2005-1, which could not reach consensus. The last time around it was re-worked to add more restrictions and again failed because other folks felt it was too restrictive. There are actually two issues:

1) the high cost of renumbering in a large organization

Why should they renumber, if it's their own block?

the point is that current policy only allocates to organizations who commit to assigning space to other organizations and perhaps a case could be made for a limited number of large organizations to qualify for a PI block of IPv6 addresses. the trick is finding the criteria which can reach consensus as "fair" but not "too complicated". such a policy would encourage IPv6 adoption in these large organizations, many of whom are unwilling to deploy it using PA addresses.

...

2) multi-homing for network reliability and resiliency

Where's the problem here? Someone who can afford and establish a case for _real_ multihoming can get an ASN and thus an assignment.

Like was already said - loosening the ASN handout rules needs changes in assignment rules, too. But that's for years to come.

see also my reply to Michael Dillon. there is a legitimate fairness argument about trying to find policies that work into the future rather than policies that need to be made more restrictive later. We've already done that and prefer to make different mistakes this time. it's harder! there is no question that the easy way out is just give everyone the equivalent (or more :-) than they currently have in IPv4. that will work for now and some time into the future. sure. but why not design a future that is built to scale reliably? it's really time to try to get rid of the IPv4 mindset!! there will have to be new and better ways of solving how to use multiple providers than everybody's route going into the global routing table. some work is being done now and it's good to keep pointing out the need for creative and scaleable solutions. let's encourage the right solutions rather than short term work-arounds... /Lea

* Hans Petter Holen:

What if I want to plan for more disasters than that ? Like MCI going out of business?

Or operator error destroys the zone beyond easy recovery. If DNS operators really cared about the availability of their data, they would allow the general public to mirror it. However, some of them seem to think that such a precaution against disaster would negatively impact their current business model.

* Carsten Schiefner:

of course, I can't speak for every DNS operator, but DENIC denying the transfer of the .de zone has no other reason than data protection, ie. making the harvesting of contact data of some 9 million plus domain name holders by just piping the zone through the whois impossible.

Your claim is absurd. The real privacy issue comes form forced publication of WHOIS data. As a member of the DENIC executive board, you certainly know that, so please stop spreading such misinformation.

* Carsten Schiefner:

Florian,

Florian Weimer wrote:

...

...

of course, I can't speak for every DNS operator, but DENIC denying the transfer of the .de zone has no other reason than data protection, ie. making the harvesting of contact data of some 9 million plus domain name holders by just piping the zone through the whois impossible. Your claim is absurd. The real privacy issue comes form forced publication of WHOIS data. As a member of the DENIC executive board, you certainly know that, so please stop spreading such misinformation.

it's interesting that you appear to know what I "certainly" know...

Don't tell me you haven't been briefed on such issues. 8-/ Anyway, I have moved the discussion to a more appropriate list. Just to make myself clear, I understand that publishing zones in a ready-to-process manner might not be in the best interest of everyone. For example, if an ISP A suffers a significant outage, a competing ISP B might sift through zone data, enumerate all domains served by ISP A's name servers. When that ISP is back again, ISP B uses the imprints for said domains (that is. if there is a web server) to gather postal addresses of ISP A's customers, making them an offer to switch (by snail mail, of course, otherwise it would be spam). Incidentally this is one of the reasons why I don't publish all the zone data I've recovered, but this is not really related to privacy concerns.

-----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: 11. november 2005 19:02

So where's the benefit if DENIC sets up something inside MCI's network that only MCI customers can see? And *if* the route is leaked outside, what is gained, except people will have to maintain explicit white-lists ("hey, this /64 is DENIC-anycast, so we permit it, while not permitting other /64s")?

I will try to explain more detailed: A large network provider can have hundreds/thousands of peers. These peers receive the same /32 prefix. A large network provider has housing facilities many places in many countries. * Put your server in some or all of these housing facilities. * Give every server the same IP address. * Tell large network provider to use the closest path and make a route to this IP address where you have your servers (use a routing protocol or whatever) * The peers of large network provider will be routed to the closest DENIC server in large network providers network. * If a server is down, the next closest DENIC server will get the traffic. * There is no single point of failure here. * You are using anycast. * You have a multiple failover solution. I hope this was clear enough. Cheers, Joergen Hovland

jorgen@hovland.cx (Jørgen Hovland) wrote:

Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers around the world at their collocation facilities. MCI may then assign DENIC one /64 prefix from their /32 prefix which will be routed to the closest DENIC server in MCIs network. Would this be a suitable solution? This /32 has not been given to MCI by the RIR explicit for anycast purposes.

Vendor/ISP dependence has never been a solution for better availability. Michael and you are somewhat off the track IMHO. Read Gert's comment, too. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---