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] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Previous message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elmar K. Bins
elmi at 4ever.de
Wed Mar 23 10:58:18 CET 2005
Hi Kurtis, kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > > IPv6 prefix per operator that is not likely to be filtered by common > > practise for anycast-operation of their DNS services. > > This part troubles me. This is a significant change from current policy > on guaranteed routability, and also quite a deviation from the critical > infrastructure policies of the other RIRs. I would like to remove the > "likely not to be filtered" from the above, or add that at no times can > the RIPE NCC guarantee routability or wide reachability and acceptance > of the assigned prefixes. I'd go for something like "...IPv6 prefix per operator for anycast- operation of their DNS services. While the RIPE NCC naturally cannot guarantee routability of assigned or allocated prefixes, care shall be taken to select a prefix that is less likely to be filtered than other candidates." I myself would prefer a defined range (say, a /32 block out of which /48s are allocated), but I seem to be a minority with that opinion. This range would allow operators to exclude it from their filters. > > /32 IPv6 prefix per operator. The prefixes shall be tagged as > > 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the > > RIPE NCC > > if not in use for anycast DNS any longer." > > I don't see why RIPE need to assign a /32 when the other regions are > /48s? I would also like to add that these assignments should be made > out of a single block. Joining the minority? ;-) I believe the proposal for a /32 tried to minimize the probability of being filtered. And since there's no real need not to be generous... > Also, to follow the "have you considered private address space" (or > whatever the exact formulation is ) question in the PI application, I > would like to require the applicant to consider using an existing > anycasting service. YEs, I understand that that is a business decision, > but so is accepting these prefixes by the rest of the world. Quite some "small zone" ccTLDs already use other cc/gTLDs setups, so what you're proposing is already done in the real world. If a TLD goes to the hassle of setting up, shipping, connecting, and maintaining anycast setups around the world which, if I may say so, includes quite some battles with network operators to remove the prefix from their filters, they will most probably already have considered using third party anycast services. And decided to operate the grid themselves. Cheers, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2 at ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
- Previous message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]