Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
Hello! In addition to the criteria that leaked out to list a few days ago I have added the technical problem that is solved by deploying anycast for DNS with a lower number of server names to the list of requirements to get an allocation. So the suggested policy would be: RIPE should be able to allocate a single /24 IPv4 and a /32 IPv6 address block for the operation of anycast DNS servers if: - the operator serves a TLD zone - the number of (planned?) nameservers would lead to a truncation of the authority/additional section in a DNS delegation response containing the NS RRset in [draft-ietf-dnsop-respsize-00.txt 2.9] As far as DENIC is concerned we would love to see this policy in effect as our additional section is already truncated and we would need to remove names from the authority section to gain more space for V6 glues. But we think it is a good thing to keep the network diversity that we have. See you in Amsterdam Andreas Baess
Hi, On Fri, Jan 16, 2004 at 11:18:29AM +0100, Andreas Bäß/Denic wrote:
RIPE should be able to allocate a single /24 IPv4 and a /32 IPv6 address block for the operation of anycast DNS servers if: - the operator serves a TLD zone - the number of (planned?) nameservers would lead to a truncation of the authority/additional section in a DNS delegation response containing the NS RRset in [draft-ietf-dnsop-respsize-00.txt 2.9]
I would support that. Yes, I know that it's a very special case, and it could be done by a "swamp" (or a random PI) /24 just fine. But I'm very much in favour of having official ways to do things that need doing - and I'm convinced that this is a good thing to do. As for the impact on the routing table: this new policy would not make more or less impact than just announcing a random /24, but it would allow for better documentation what it's all about. As far as "other" anycast deployments go: there have been some voices on the list that "we must not do a policy that's too narrow minded" - yes, that's true, but we don't want a "permit all" policy either (well, we *could* do that, but there does not seem to be consensus to do that). *If* other people show up, and say "we want to do this-and-that, and have a specific need that cannot be done in the current framework", we can always adapt the then-existent policies. (This is speaking as myself, and as APWG co-chair). Andreas: I would appreciate if you could give a short presentation (5 mins?) in Amsterdam, repeating the reasoning behind this proposal, to stir some discussion. Then we can have a final call for consensus some time after the meeting. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (2)
-
Andreas Bäß/Denic -
Gert Doering