Thanks Andreas for this clear summary. As you asked at the end of your message below, I would have one comment and one suggestion : - comment: One /48 microallocation per TLD under a common prefix ( a /32 or shorter per RIR) would ideally meet the goal. The "well-known" prefix would be taken into account in BGP filters so that /48 get the biggest chance not to be filtered. - suggestion: While waiting for the "ideal solution" to be implemented. The wg should move forward with this proposal and allocate one /32 per TLD applying for it. Probably, only a small number of TLDs will ask for such allocations before the "ideal solution" gets in place. In all cases, the number of requested blocks is bounded and there must be no scaling issues since the conditions are clearly stated: TLD + Anycast (+ potential problems with growing DNS response size due to growing number of NS's and glue RR's). Regards, Mohsen. On 04 Apr, Andreas B/Denic wrote: | Dear WG! | | I have followed the discussion about the TLD Anycast Allocation Policy | and decided not to quote from the previous posting but to pick up the | arguments - as I | have understood them - and pointing to the places where I have | tried to address them in my policy draft. | | 1. Is there a need for anycasting at all ? | | I was surprised to see this question on the list. | I think that anycasted nameservers are an accepted standard and there | is no need to discuss pros and cons anymore. | | | 2. /32 vs. /48 V6 prefix - routability aspect | | >From a routing table perspective there is no difference if the prefix is | longer or shorter. When asking around which prefix length would have a | good chance to ensure the goal of not beeing filtered I have felt | consensus | that a /32 has by far the best chances. However I'm considering if it | wouldn't be best to declare a /32 microallocation block from which RIPE | will | assign /48 blocks. | | 3. /32 vs. /48 V6 prefix - address conservation aspect | | There is no question that a /32 is quite a big block and that this | sacrifice | to "ensure" reachability from most network places is worth it. | This question should be raised at regular intervals which is covered by | renewing/adjusting/withdrawing the policy if circumstances have changed. | I felt that there has been consensus within the folks I have | talked to that a /32 is currently a good thing to keep the komplexity | of anycast deployment at a bearable level. However the last disccusion | showed me that a lot of people would prefer to assign /48 from a /32 | TLD Anycast Allocation Block. | | 4. Are the number of assignments under this policy limited? | | The policy in its current form implies a limit of one V4 and one V6 block | assignment because as soon as one assigment is made there is no chance | to pass the referenced IANA test to get another assignment. | | 5. Who gets the address assignment? | | The assignment is bound to a TLD nameservice. Therefore the applicant | would be | a TLD administrator. The TLD administrator can use this assignment either | by himself or hand it to an anycast provider that will operate the anycast | nameservers for him. | I don't think that sharing an assignment between multiple TLDs if they | outsource | their operation to an anycasting DNS provider should be a must to separate | TLD operations from each other and that the extra address space spent is a | good | thing keeping in mind the limited number of TLDs where talking about. | | | Summary: | | I hope with my explanation it explains that most of the concerns have been | addressed already. Allocating a /32 prefix to all RIPE TLD anycast | assignments | should help to address concerns about address space usage and make setting | up | routing filters easier. | | Any comments or suggestions? | | Andreas | -- | DENIC e.G. Phone :+49 69 27235 120 | Wiesenhuettenplatz 26 Fax :+49 69 27235 235 | D-60329 Frankfurt Mail : baess@denic.de | -- | DENIC e.G. Phone :+49 69 27235 120 | Wiesenhuettenplatz 26 Fax :+49 69 27235 235 | D-60329 Frankfurt Mail : baess@denic.de

On 4-apr-05, at 18:18, Andreas Bäß/Denic wrote:

1. Is there a need for anycasting at all ?

I was surprised to see this question on the list. I think that anycasted nameservers are an accepted standard and there is no need to discuss pros and cons anymore.

Well, certainly not here. But if this is your question, answering it is easy: no, there is no NEED. Whether it's useful in a particular case is something different.

2. /32 vs. /48 V6 prefix - routability aspect

There are incorrect documents published which suggest that filtering at /32 is ok. After changing these documents and waiting some time this should no longer be an issue. BTW, from RFC 3513: 2.6 Anycast Addresses [...] For any assigned anycast address, there is a longest prefix P of that address that identifies the topological region in which all interfaces belonging to that anycast address reside. Within the region identified by P, the anycast address must be maintained as a separate entry in the routing system (commonly referred to as a "host route"); outside the region identified by P, the anycast address may be aggregated into the routing entry for prefix P. Note that in the worst case, the prefix P of an anycast set may be the null prefix, i.e., the members of the set may have no topological locality. In that case, the anycast address must be maintained as a separate routing entry throughout the entire internet, which presents a severe scaling limit on how many such "global" anycast sets may be supported. Therefore, it is expected that support for global anycast sets may be unavailable or very restricted.

3. /32 vs. /48 V6 prefix - address conservation aspect

There is no question that a /32 is quite a big block and that this sacrifice to "ensure" reachability from most network places is worth it.

There is at least a question here, even if we agree on the answer. However, it's not simply whether it's worth it or not, it's a question of doing the right thing. If we start changing allocation policies to accommodate laziness on the part of router operators, where does it end?

I don't think that sharing an assignment between multiple TLDs if they outsource their operation to an anycasting DNS provider should be a must to separate TLD operations from each other and that the extra address space spent is a good thing keeping in mind the limited number of TLDs where talking about.

Disagree. Resource conservation should be the default, this should only be changed when there is clear evidence that this is problematic.

Any comments or suggestions?

Yes. I want to see a specific plan from the TLD community about what they want to do here. "Give us the prefixes" isn't good enough for me.