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

Gert,

On 15 Jun, 2004, at 11:46, Gert Doering wrote:

> Hi,
>
> as the discussion seems to have ebbed down, let me try to summarize.
> Please correct me if this isn't fully correct.
>
> There have been a few comments about wording, to make the criteria
> more precise.
>
> There has been some confusion on whether this is "PI".  It is not, it's
> "anycast space", and should be tagged as such in the database, to help
> people recognizing these special blocks immediately as such.  The usual
> rules apply: "if the criteria for allocations do no longer apply, the
> address block should be returned" (even if that is unlikely to happen
> very often in practice).
>

Don;t know if there is a real need to tag things like this in the DB, 
but I am not going to argue either way.

> There has been the question whether an operator can only get one
> prefix, or multiple prefixes.  I have amended the proposal to
> include the option for multiple prefixes, but also point out that
> the usual thing will be "only one (set)"

Good up to here.

> .  This is meant as kind of
> guidance - "deploy one set, and if that's well understood and
> you want to deploy another set, feel free to come back".

the "come back" part spoils it. Some people already understand this 
pretty well, no need for a several step ballet.

>
> Along that lines, there has been some confusion about redundancy.  An
> important clarification is that it's not expected to put *all* 
> nameservers
> into the (single) anycast prefix, but have "unicast" servers and one
> (or "few") anycast sets.  So if the anycast prefix is unavailable from
> some networks, clients will fall back to one of the unicast servers.
>

This could be the subject for a BCP sort of document by the DNS wg, but 
it has no place in an IP allocation policy.

> There has been a question on whether "end users" can directly request
> anycast address space, and the suggestion is that it should be handled
> the same way as PI space and AS space: the request needs to be passed
> through an existing LIR.
>

Cool.

> One comment asked for "do we really need yet another special rule 
> here",
> and my reply would be "the current PA and PI policy doesn't permit 
> doing
> this without lying to the NCC", *and* DNS is really special here due to
> protocol constraints.
>

There is need for a new rule because the current policy does not 
support the deployment of a well known and accepted operational setup 
that addresses a specific problem. I don't know about "special".

>
> To my understanding, there were no real fundamental objections, though
> (besides, this proposal was already discussed on the list and in the
> APWG meeting at R47, with mostly neutral-to-positive reactions)
>
>
> So based on these comments, I want to suggest the following new
> text, to be incorporated into the policy documents:
>
> ------------ snip ------------
> "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 dedicated network prefixes for the sole purpose of
> anycasting name servers, as described on RFC 3258. These shall be:
> a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set,
> which will usually only be one per operator.  The prefixes shall be
> tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be
> returned to the RIPE NCC if not in use for anycast DNS any longer."
> ------------ snip ------------

I support your suggested wording.

>
>
> To be able to proceed with the implementation, let's set a deadline
> of July 13 (4 weeks from now).  If no fundamental opposition is voiced,
> we can call it consensus, and ask the RIPE NCC to go ahead with it.
>

Joao