PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy
Without questioning the particular needs of the proponent, the proposal as it stands has some issues to be resolved (quoting only the v4 part for ripe405 here):
6.9 Anycasting Name servers
If the name server set of an organisation running DNS without using
It is unclear to me whether "an organisation" refers to the domain holder, zone maintainer or the DNS infrastructure provider, if any. The original proposal deliberately chose the term TLD here, referring to the TLD manager, not the service provider and if this proposal intends to change that, it should be made more explicit.
anycasting technology would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the organisation may receive a single dedicated /24 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
The organisation should demonstrate that the number of name servers or IP addresses for these name servers in the delegation exceeds eight and that without anycasting their zone size exceeds the UDP datagram size.
During the discussion of the original anycast policy proposal it was carefully avoided -- after some looping debate -- to encode explicit DNS parameters into said proposal. That's the whole point of referring to IANA's delegation procedure. Now, I understand that IANA's procedures aren't applicable to non-TLDs, but at the same time it isn't obvious where the number "eight" originates from. To make matters more complicated, the basic procedure IANA is supposed to apply would indeed fit well, but then depends on the respective parent's glue and registration policy. Again, I'm not sure anyone would want the RIPE NCC to engage in cumbersome tests and judgements, so even a fixed number might be fine - if there's some rationale given. NIT: "their zone size exceeds the UDP datagram size" should probably read "a referral response for their domain would exceed the 512 octet UDP payload limit".
The organisation should also demonstrate that they need to do anycasting due to the geographical diversity of their DNS setup. The organisation will be required to demonstrate that anycasting will be used in diverse geographical locations. The existence of the real servers should be demonstrated with anycasting nodes that can be pinged and tracerouted.
That should be topological diversity instead. I'm not so confident that pings and traceroutes can differentiate between anycast and multihoming uses. The basic question is whether checks should be applied at all.
The prefix will be assigned by the RIPE NCC directly to the organisation, upon a request submitted via an existing LIR and will be registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database. The prefix must be returned to the RIPE NCC if no longer in use for anycast DNS.
Within the "arguments opposing the proposal" I'd suggest to change the reason from "... be opened to organisations that are not a ccTLD or a gTLD." to something like "... no longer have an upper bound of {some fraction of 267}." Actually, the proliferation of anycast assignments could lead to more rigid filtering. -Peter