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. 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. 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). 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. Have a nice day Andreas

Joao

...

"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."

No, this completely misses Joao's point which spelled out that you don't get an allocation unless you will anycast it. For example, my private company shouldn't be able to get PI prefixes just by adding 20 authorative DNS servers!

Anycasted DNS is an absolute must to qualify for this kind of allocation. However I can't believe taht someone will break up his DNS service just to qualify for another /24. Maybe I underestimate what some people would do for a handfull of numbers :-)

In other words, either you're creating PI space for ccTLDs (or some other groups, whether special or not), or you're creating PI space for anycasting for certain applications, or both. This needs to be made clearer as different people have different assumptions here.

This address space is _not_ PI in its original sense. The allocation is made to overcome a DNS limitation and we feel that we should grant resources to those who feel the need to provide DNS service in a way that is described in RFC 3258. This policy does not apply to non DNS services and it is not limited to TLDs.

That said, I still don't think this policy makes sense. How many servers would that need to be? A lot.

There has been several studies from different sources how many NS would be needed. If you plan to fully support IPv6 transition giving all of your NS A and AAAA records it is not that many before your responses will be truncated.

What prevents from anycasting a regular PA prefix among those parties which have the largest amount of servers? Nothing (prefix filters based on RIPE DB shouldn't be a problem, just add the AS of anyone anycasting to the prefix right?).

As I said before it is not about PA versus PI, the allocation is tagged to the anycast DNS services. We have discussed the possibility to ensure the routability of smaller prefixes from the "regular" LIR allocation but most of the people felt that although possible putting that burden (to ensure routability of some prefixes in a world that filters on PA allocation boundaries) on DNS folks is not a good idea but enabling them to use specific prefixes that are "known" to ensure routability is a better solution. It has also been agreed that using this kind of special allocations will be history as soon as anycasting is possible with a single allocation. I don't know if the routing wg is already working on this item. Have a nivce day Andreas

...

...

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.

This is unacceptable for redundancy reasons. If the routing for the /24 hiccups (e.g., someone advertises the prefix but drops the packets), all the nameservers will down for people behind that ISP? If you anycast something, there will have to be a backup option as well.

-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Hi Pekka, I'm answering on your e-mail, but the same issue has appeared a couple of times: On Wed, Jun 09, 2004 at 12:38:45PM +0300, Pekka Savola wrote:

...

One /24 per zone operator. [..]

This is unacceptable for redundancy reasons. If the routing for the /24 hiccups (e.g., someone advertises the prefix but drops the packets), all the nameservers will down for people behind that ISP? If you anycast something, there will have to be a backup option as well.

The idea is not to put *all* name servers for a given zone into anycast space. The idea is to have a number of unicast servers (as many as fit into the delegation UDP packet, minus 1) and in addition to that, an anycast server with "many instances". So if the anycast /24 hickups, the client resolver will treat this as it will treat any failure of one of the auth DNS servers -> fall over to the next nameserver listed. Of course it's open to debate whether it might be desireable to permit "many different anycast networks for a single zone", or even "anycast all of the servers" (with individual networks). The current idea is conservative and proposes "one anycast netblock". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

Hi, On Fri, Jun 11, 2004 at 10:47:23AM +0200, Joao Damas wrote:

Don't you think the policy ought to be more relaxed and allow the server manager for the zone to decide how many of their servers they want to anycast?

This is not my decision. It's up to the working group to decide on the policy they want to have. The current proposal is a somewhat-balanced compromise, but in no way cast in stone (yet :) ). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

Don't you think the policy ought to be more relaxed and allow the server manager for the zone to decide how many of their servers they want to anycast?

i think the point intended is that the address space *must* be used for anycast, and not just another address grab. yes? randy

...

...

Don't you think the policy ought to be more relaxed and allow the server manager for the zone to decide how many of their servers they want to anycast?

i think the point intended is that the address space *must* be used for anycast, and not just another address grab. yes?

Well, no one doubts that is the intention here, that is why I suggested a different wording earlier, so the motivation is clear. My question is, why limit it to anycast one of the servers?

Can you help me and explain what the advantage of offering multiple anycast servers in comparison to a single anycast server is? Andreas

Hi, On Fri, Jun 11, 2004 at 07:19:47AM -0700, Randy Bush wrote:

...

Don't you think the policy ought to be more relaxed and allow the server manager for the zone to decide how many of their servers they want to anycast?

i think the point intended is that the address space *must* be used for anycast, and not just another address grab. yes?

Yes. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-10, at 09.45, Joao Damas wrote:

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.

Only servers that share the same path. At least if you are referring to dampening. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+HSqarNKXTPFCVEQLOpACeKVdPEl45gi9gker0EMNCNIOOKlcAoKy4 Q9hJ55rtLe7JnWXnc+jeTbor =pAXU -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-16, at 01.38, Randy Bush wrote:

...

Only servers that share the same path. At least if you are referring to dampening.

damping is not per path

There I get for writing emails after a full day of IPv6 meeting... You are of course right. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+U/qarNKXTPFCVEQIiWQCggVDeBczpVZ72LCTBGrpEG810woQAn0r7 LEIW/8BSU5sLpPTt0z01QRpS =Y8nX -----END PGP SIGNATURE-----

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

On Tue, 15 Jun 2004, Gert Doering wrote:

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.

If you qualify for at least /24 of v4 address space, there shouldn't be a problem with current v4 policy? If you can't qualify for that amount of addresses, do we care about anycasting that kind of server? Remember, nothing prevents anycasting with your existing allocated blocks. Hence, the policy for allocating these special PI/PA prefixes should be at least as strict as the policy for getting PI/PA prefixes in the first place .. to avoid getting around policies.

------------ 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 object to this as a whole, but even if we agreed that this is desirable in general, I have two strong objections: (1) there is little reason for allocating a /32 IPv6 prefix except for getting around the IPv6 policy. Why not use the "critical infrastructure" /48's for this, so we can easily filter out this junk in our BGP :) Proposal: change /32 to /48. (2) this proposal takes no stance on who can request a block of addresses like this for his DNS servers? People could add up servers and addresses for them just for the purposes of getting nice PI prefix(es) for their DNS servers. Wouldn't it be nice, never having to renumber your DNS server addresses in different registries etc. This is short-sighted. We should restrict this approach to specific class of DNS servers, like ccTLDs or the like -- if that's the class of DNS servers where we'd intend do something like this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Gert, On 15 Jun, Gert Doering wrote: [..] | | | 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 ------------ ==> While discussing this issue, IPv6 Policy (especially "Initial allocation criteria" section ) is being clarified (see current discussion on global-v6@lists.apnic.net). Even though, it is said that the intention of this discussion is to clarify the IPv6 Policy and not to change it, does it make sense to consider adding explicitely the criterion above ("DNS ANYCASTING") as a new criterion to qualifiy for a /32 ? Regards, Mohsen.

Hi, On Tue, Jun 15, 2004 at 04:56:47PM +0200, Havard Eidnes wrote:

let's be a bit difficult, shall we? ;-)

Welcome to the club :-)

...

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).

What makes this different from clever wordplay? From a routing perspective the difference is pretty small, if it is there at all.

On the router itself, there is hardly any difference. For the person configuring the router's filters, it might make a difference whether something is tagged as "this comes from a larger PA block" (so you don't necessarily need to carry it, there should be an aggregate in the table) and "this is something special".

...

------------ 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

Hm, it's not "the UDP packet size limit", it is "the packet size limit for DNS over UDP without the application of EDNS.0".

Of course. Sorry for being unprecise. ("For not correcting *this* part of the initially-also-unprecise wording ;-) ").

I may not have followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing space to compensate for people who have not yet upgraded their software... Of course, people may still dream up configurations which would exceed the EDNS.0 DNS over UDP packet size limit.

I leave *this* up to the DNS people - Andreas and Joao - to answer. In this discussion, I'm trying to wear the "WG Co-Chair" hat only - not actively advocating anything, just trying to clarify things, based on the proposal from DENIC (Andreas). So if people tell me that "95% of all DNS clients are already ENDS.0 capable, junk this proposal" (and have good background data for this, like "root DNS logs" or so) - fine with me, less work for me and the RIPE NCC. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

Hello, {I'm copying this to the DNS wg list, since the protocol issues may probably be better discussed there. Hey, I *love* these [tags] :-(} [address allocation for anycast of DNS nameservers] Havard Eidnes <he@uninett.no> wrote:

...

------------ 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

Hm, it's not "the UDP packet size limit", it is "the packet size limit for DNS over UDP without the application of EDNS.0". I may not have followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing space to compensate for people who have not yet upgraded their software... Of course, people may still dream up configurations which

Isn't then the parent of those trying to do anycast suffering from those resolvers unaware of EDNS0? In other words: what could the applicant do? -Peter