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/address-policy-wg@ripe.net/
[address-policy-wg] Re: Policy Change Request - Allow address allocations for anycast DNS operation] (fwd)
- Next message (by thread): [address-policy-wg] Re: NCC#2004080845 IPV6 Addresses pool
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Pekka Savola
pekkas at netcore.fi
Sun Aug 1 19:35:12 CEST 2004
Following up with really old email.. [Gert:] > 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. I don't think this really matters. First, the allocation boundary filters filters filter out a lot of stuff as well. If you put them in, you should know that you might not get some advertisements. Second, even if you filter on the boundary, you'll just go to the main office, not necessarily the closest anycasting service. So, the service you get is no worse than it's today. Last, there are also those other, non-anycasted servers, so you'll be able to reach them as well. I don't clearly see why this exception is necessary, especially if folks document the more specific block appropriately in the registry. > > 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). I'm not sure what you meant by 1 IP -- the DNS server or some small offices? (or offices behind a NAT?) > > 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. Ok -- then we have still the PA policy left that might be useful. > [..] > > 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). Just chunk out a couple of /48's from the block where the IX addresses have been allocated? Given the reasoning above, and the fact that the servers should always also include non-anycasted addresses, I see no reason why these should be given special status -- it's not as if it's critical that these prefixes go through the filters or aelse all else breaks. That IMHO argues for similar treatment as ARIN's "critical infrastructure" prefixes: /48's which some might and some might not filter. We certainly intend to :). > > (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. Due to reasons discussed below, I strongly believe that we need restrictions here. I don't care much about giving special golden PI blocks to TLD operators, but I care even less for giving them anyone at all that comes knocking at the door! TLD operators should at least be considered (by some measure) "semi-critical" infrastructure. Big ISPs don't need these special provisions, and the net doesn't care about the small ISPs which can't get routable PI otherwise (and this would be a nice trick to get it through a loophole). In short, let's just decide on a list, if we need this in the first place. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
- Next message (by thread): [address-policy-wg] Re: NCC#2004080845 IPV6 Addresses pool
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]