[address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?

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 don’t 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