[address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
Jørgen Hovland jorgen at hovland.cx
Thu Nov 10 12:28:10 CET 2005
Hi, I would like to comment on this topic. --- From: Andreas Bäß/Denic Date: Mon, 4 Apr 2005 18:18:22 +0200 >1. Is there a need for anycasting at all ? > >I was surprised to see this question on the list. >I think that anycasted nameservers are an accepted standard and there >is no need to discuss pros and cons anymore. If anycasting involves creating special prefix allocation policies, then I am 100% against anycast. We are currently running anycast on our own nameservers, but we don't require our own v4 or v6 prefix just for that. I don't see why you can't do the same with your already 11 nameservers (on 11 networks?), but maybe that's just me. Furthermore, nameservers should not be specially treated. It is impossible to define what is important and what is not (like defining what spam is). The only anycast service at all I would be willing to exempt is root nameservers and give them their own prefix if needed. Nothing, and by nothing I mean any service (dns, web, mail etc), is justified for their own anycast prefix unless you can implement it with standard allocation policies. Microallocations might be a standard allocation policy. What I don't want to see is that RIRs hand out microallocations for the sole purpose of running anycast. Then I would probably be asking for at least 50 microallocations just for myself, oh pretty please. 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 dont put the prefix in the dfz. I don't think it belongs there. Thank you, Joergen Hovland -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Andreas Bäß/Denic 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
[ ipv6-wg Archives ]