[address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation

On 9 Jun, 2004, at 11:28, Andreas Bäß/Denic wrote:

> Joao,
>
>> I would suggest a slight re-phrase:
>
>> "Operators providing DNS for a zone served by a number of name servers
>> such that the total response size when including the list of
>> nameservers for the zone is close to the UDP packet
>> size limit may be assigned PI network prefixes for the purpose of
>> anycasting name servers, as described on RFC 3258. These shall be: a
>> /24 IPv4 prefix and/or a /32 IPv6 prefix."
>
>> Given that the issue is the will to anycast due to the  operational
>> impact of adding more servers to the list, not just the size of the NS
>> RRSET itself.
>
> I see your point and it's the same thing I had in mind when I wrote the
> policy down. I don't think that it makes sense to work to hard on an 
> exact
> definition when someone classifies for an allocation. As well it is
> impractical to say you have to cross the limits first (and prove that
> your clients are suffering from it) before you can get your allocation.

No, I wasn't proposing that you have to suffer before you get the 
reward, I am a follower of that precept.
What I want is there to be a clear motivation for the allocation of 
resources, ie. you get the prefix because you want to anycast, not 
because your responses are close to the UDP size limit.

I would also like to see some effort being put in place by big zone 
administrators on educating people about EDNS support in their servers. 
I am sure ccTLD operators issue recommendations to their customers.

>
> I thought that those who are attracted by the policy will have no 
> problem
> justifying it and RIPE would have no problem to ask people returning 
> the
> networks if they do not use them as stated in the policy. But maybe
> my thinking is too positive here.

Experience says allocations (and assignments) are not boomerangs, they 
go out, they rarely return.

>
> Maybe the RIPE hostmasters can tell if they have the feeling the policy
> is "clear" enough or if they would like to see real hard limits (i.e.
> 0,5% of all responses during a time window of 60 minutes must be
> truncated).

No, god, no, I understand hostmaster need concrete policies, judgement 
calls can be controversial, but no policy should need to preclude 
development before allowing it.

>
> So far I think the original would serve RIPE and the DNS operators 
> needs:
>
> "Operators providing DNS for a zone that is approaching the UDP packet
> size limit due to the number of authoritative servers may be assigned
> PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These
> prefixes will allow them to anycast the DNS server, as described in RFC
> 3258."
>
>> Also, pardon me asking but would the request be for a /24 per server 
>> to
>> be anycasted of a /24 per zone administrator?
>
> One /24 per zone operator. I remember that someone (was that you?) 
> would
> like to have /24 for putting the administrative interface of the 
> anycast
> instances into another AS but as far as I recall there have not been 
> much
> support for that idea.

No, this is not about the point I brought up a few months ago about 
management addresses, but rather about what Pekka said, the danger of 
putting all the nameservers in a single /24. Any snafu affecting that 
/24 (any of the anycast instances flapping, for instance) will take 
down access to all servers.

With regard to Pekka's point about filtering, some people claim to have 
problems at some points when they split their allocations. I don't 
know, I never had to do split RIR space. On the other hand, the CIDR 
report shows a few examples of people massively de-aggregating and they 
are still in business, so..., I will leave this point to be discussed 
by someone who actually has a problem with it.

And with regards, to Wilfried's question about whether this policy 
proposal should require the requester to be an LIR, the reply is "why 
should it?". Unlike Daniel, I have trouble seeing bureaucracy as a 
beautiful clockwork mechanism.

Cheers,
Joao