This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
- Previous message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
- Next message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Tue Jun 15 13:27:58 CEST 2004
Hi, On Tue, Jun 15, 2004 at 02:11:22PM +0300, Pekka Savola wrote: > 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? There is. People don't want to use part of their PA block for the anycast announcement (due to "allocation boundary" filters) and you won't qualify for a /24 PI with just a single IP address used inside the block. The PI policy requires "more than 50% utilization" (simplified), which would mean "you need to use 128 IPs in the /24" - which a typical (ccTLD) anycast deployment will never reach. > If you can't qualify for that amount of addresses, do we care about > anycasting that kind of server? The ccTLD's office might have 500 machines in use, but the individual instances will all only use 1 IP (or very few). > 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. The problem in the first place is that the PI policy doesn't permit these prefixes in the first place, due to insufficient utilization. [..] > 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 :) We have no "critical infrastructure" /48s in RIPE land, *and* you're not supposed to catch this in "general-purpose more-specific filters" - which is the whole point of this excercise. (If you really want to filter the prefixes, you still can, as they are supposed to be clearly tagged in the RIPE DB). > 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? Yes. On purpose, because it was envisioned that some organizations that are not TLD operators but still operate a high number of DNS servers (due to having a very large number of zones, or due to having a world-wide network, or whatever) might still meet the spirit of the thing. > People could add up servers > and addresses for them just for the purposes of getting nice PI > prefix(es) for their DNS servers. Ummm, yes. > 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. This was discussed in the last round, and a fair number of people voiced that we should not restrict this to TLD operators. Personally, I have no strong feelings one way or the other, but I can see that more discussion is needed here. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
- Previous message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
- Next message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]