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

[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