- address-policy-wg - mailman.ripe.net

Summary TLD Anycast Allocation Policy
by Andreas Bäß/Denic 05 Apr '05

05 Apr '05

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(a)denic.de -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess(a)denic.de

5 4

Re: [Ticket #1032183] Autoreply: viadomains <bleep>
by Randy Bush 05 Apr '05

05 Apr '05

i have plonked all mail from vianetworks.co.uk. if they ever get a clue and have something useful to say, someone please tell me. randy > From: via-domains <domains(a)vianetworks.co.uk> > RT-Ticket: Ticket #1032183 > Managed-by: RT 3.2.3 (http://www.bestpractical.com/rt/) > RT-Originator: randy(a)psg.com > To: randy(a)psg.com > > Thank you for your enquiry concerning "Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria", a summary > of which appears below. It has been logged with our automated ticketing > system and will be forwarded on to the appropriate department. > > You have been allocated a unique reference number - [Ticket > #1032183] - for this query that should be used in all further > correspondence relating to this matter. If replying by email, please > make sure that the ticket number is in the subject header. > > Thank you for your query, > > VIA Networks UK Support Administration > domains(a)vianetworks.co.uk > ------------------------------------------------------------------------- > Spam detection software, running on the system "he401war", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or block > similar future email. If you have any questions, see > sysadmin(a)vianetworks.co.uk for details. > > Content preview: >> and we once thought 32 bits of address should be > enough for ever > *I* wasn't part of that "we" - and the math is a > *little* bit different > here. > *I* wasn't part of that "we" one of > the few benefits of age is perspective [...] > > Content analysis details: (6.1 points, 5.0 required) > > pts rule name description > ---- ---------------------- -------------------------------------------------- > 1.0 RCVD_FROM_SECONDARY Went through secondary MX record > 0.1 TW_VT BODY: Odd Letter Triples with VT > 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% > [score: 1.0000] > -0.4 AWL AWL: Auto-whitelist adjustment > > >

3 2

Draft Agenda for Address Policy WG @ RIPE 50 Thursday 5th May
by Hans Petter Holen 05 Apr '05

05 Apr '05

Dear all, Please find enclosed a first Draft Agenda for the upcoming Address Policy meeting. -hph A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 49: http://www.ripe.net/ripe/wg/address-policy/r49-minutes.html B. Policy overview - Regional policy overview -- presentation of the status of the current regional proposals under the "beta test of the PDP" -- status of the PDP and transition to the PDP - Gloobal policy overview C. Policy proposal: #alpha: TLD Anycast Allocation Policy D. Policy proposal: #beta: IPv4-HD-Ratio E. Policy proposal: #gamma: IPv6 remove 200 customer requirement F. Other v6 issues ? G. Status of the IPv4 Global Policy H. Status of the IPv6 Global Policy I. Any other Business

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 04 Apr '05

04 Apr '05

>>> Well, this can be argued the otherway around as well. We know that >>> ISPs >>> filter out previously unused space, and that they are not very active >>> in updating those filters when IANA starts allocating out of new >>> blocks. Having all in well-known block would limit that. >> >> ...wouldn't we/you/they/all have to do some filtering the "other way >> 'round" if all of those prefixes are contained in _one_ superblock to >> guard against someone/something announcing (and potentially black- >> holeing(sp?)) a route for that /32? > >Eh, I would assume there is no /32 to announce and that more specifics >will always win. > >- - kurtis - In a perfect world - yes. But "per default" when you announce something in v6-world, you are "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that is longer than that. I really don't see any benefit from adding complexity again, other than clinging to the well-worn conservatiopn goal from IPv4. Wilfried.

16 39

HD ratio policy proposal
by Kelaidis Christine 04 Apr '05

04 Apr '05

My company believes that the proposal for the calculation of the HD ratio to measure IPv4 usage is a an improvement to the existing one and we would like to support this new policy proposal. Christine Kelaidis

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 29 Mar '05

29 Mar '05

>No, what it means is: "People who inject routes in the global routing >table, for whatever reason, increase the cost of operating routers. So >for reasons of fairness and as a mild deterrent, these people should >bear a generous share of the costs associated with operating the RIR >infrastructure." Again, this implies the existence of some sort of cross-domain funds- transfers. As there is no direct and transparent relationship between ensuring uniqueness of address space blocks (RIR business) and those covering the cost of implementing the routing layer for the global Internet, it would simply be an address tax raised by the RIRs. There's not even the concept of "reverse funds" transfer from the RIRs charging for such addresses back to the LIRs. >A good way to do this would be to require everyone who wants such a >block to become a RIR and to charge address based costs only on the >number of blocks and not on their size. No, see above. [btw, I assume the string "RIR" in the previous paragraph is just a typo and that you meant to type "LIR". Otherwise this would be a clever move to kill the proposal - by sending them to ICANN for recogition as an RIR :-] And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point? >Note that I'm not saying these people should pay an artificially >inflated fee (although deep in my heart I would love that), just their >fair share. With your definition of fair for something you don't like :-) Scary... > It shouldn't be cheaper to obtain a special prefix than a regular one. Indeed, and then it should not be smaller or, rather, more difficult and risky to use. >Also, there should be limits on the number of special prefixes. Ahem, how many - and why? Wilfried.

6 10

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 25 Mar '05

25 Mar '05

>If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. Looking at the fact that for a couple of years already the majority no longer cares (or even reads? much less acts on) the weekly routing table reports suggests that you are right. >Jon Wilfried.

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>personally, i have no answer. We seem to be coming to the bottom of the pit :-) > sorry to make you read all this rubbish to find that. Fine with me. > why not show a bit of wimsey and block out >42 /32 chunks for this and have a three month bidding period to see >how much money the rirs can collect to donate to heal some of the >horrifying wounds of the latest natural disaster or unnatural us >imperialism? Aah, so this time at least we don't want to raise money for poor routers, but for victims of some sort of disaster or another. And why 42? (other than being "this" universal number) Wouldn't we be able to raise more money if we would give away more prefixes ;-) Or maybe just 32 x /32? Funny times, Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Joao Damas 24 Mar '05

24 Mar '05

OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay so the only point of contention is the size of the prefix. Using longer prefixes does not add much to the conservation and introduces more exceptions. Even if other RIRs are doing /48s already why would introducing an additional chunk of swamp space with the potential for more likely large scale failure be of any benefit? If people agree with assigning the addresses for this purpose, which seems to be the case, just issue a standard allocation and be done. Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50. Joao PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon. PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software.

3 7

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>I would also be very happy if RIPE would charge enough money to people >wanting to do this to make them consider whether they really need it. ...this is just a fuzzy wording for: "Make the RIRs sell address space at different (and maximum) premiums, depending on how dearly the applicant needs the addresses at that particular point in time." I would not support such a proposal. Wilfried.

2 1