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

RE: [address-policy-wg] Policies interact
by Wilfried Woeber, UniVie/ACOnet 08 Apr '05

08 Apr '05

>>> For a routing decision you don't need 32 bits for an IPv4 prefix, >>> and you do not need 128 bits for an IPv6 prefix. >> Exact. >> A international routing decision can be limited to the first 64 Bits. >> The remaining 64 Bits are some sort of ARP-replacement. > >nope. folk are using /126s internally, and have igp or ibgp carrying >those prefixes. of course, they also have the classic loopbacks for >bgp, which can be /128s. real hardware vendors know this and don't >make the same mistakes as were made in the old a/b/c days. > >randy I thought we were talking about the routing table size and memory requirements for the DFZ. Are you implying that we will see those more specific /126s or /128s in the global routing table? Wilfried.

1 0

ICANN Calls for Comments on the Proposed Review Procedure for ASO Policy Proposal
by Axel Pawlik 08 Apr '05

08 Apr '05

Dear Colleagues, The RIPE NCC invites all members of the community to comment on ICANN's proposed Review Procedure for Address Supporting Organization (ASO) policy proposals. On April 6, 2005, ICANN called for public comments on this proposed Review Procedure. Further information and a link for submitting comments are available on the ICANN website at: http://www.icann.org/announcements/announcement-06apr05.htm Regards, Axel Pawlik Managing Director RIPE NCC

1 0

RE: [address-policy-wg] Policies interact
by Wilfried Woeber, UniVie/ACOnet 07 Apr '05

07 Apr '05

Sidetracking #2: >Savings in IPv4 space, do not carry over into IPv6. That is why >we lose these savings. But the size of the routing table increases >by 4 times therefore requiring 4 times as much RAM and 4 times as >much time to send/receive full routes. If this is the case we are looking at a poor implementation (memory-consumption-wise), imho. For a routing decision you don't need 32 bits for an IPv4 prefix, and you do not need 128 bits for an IPv6 prefix. My wild guess would be that the ratio is rather on the order of 1:1.5 than 1:4. [ Anyone having statistics about the average length of an IPv4 prefix? Probably in the range of (20..)21..22(..23) ] Wilfried.

4 4

Re: how 200 /48's fails the job
by Valtteri Vuorikoski 07 Apr '05

07 Apr '05

Pekka Savola <pekkas(a)netcore.fi> writes: > On Tue, 5 Apr 2005 Michael.Dillon(a)radianz.com wrote: > ... > > The 200 new customer limit was meant to be a measure of largeness and > > seriousness. I think that in today's world, that measure fails to do > > the job. > > Could you clarify, why do you think "200 customers" fails as a meter for largeness ? > > There are some odder cases like transit only ISPs (which technically could only have very few direct > organizational customers -- let's assume that those would get the IP space using some other provisions or > as a matter of interpretation), but apart from that, why exactly is requiring 200 customers unreasonable? I think Mr. Bartels already made some of these points, but I'll still add my two (euro)cents to this discussion. I would think that the concept of lumping all "customers" into a single class is flawed. I work for a managed hosting provider, and we currently have POPs in three countries with multiple transit providers and peerings. Obviously we have our own IPv4 allocation. However, our focus is on medium-size and large customers, which are quite unlike residential end-user customers where 200 would be next to nothing. I doubt we'll have 200 such customers (without creative accounting, that is) in a while yet, but we are still doing active business. The current rule effectively prevents us from deploying IPv6 to our customers. In the long run, I believe that as long as the current policy prevents hosting companies who serve content to end-users from deploying IPv6, it removes motivation from the end-user ISPs (who would have no problem getting the allocation) to actually deploy it to their users. While routing table growth is a concern, not having (v6) routing table growth is in my opinion an even larger concern. Therefore my view is that the arbitrary fixed criterion of having to be "large" (for whatever value of large) for a v6 allocation should be dispensed with. -- Valtteri Vuorikoski <vuori(a)magenta.net> MagentaSites Oy

5 5

Fw: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]
by Michael.Dillon＠radianz.com 07 Apr '05

07 Apr '05

> There is one point I don't understand in the whole discussion: > If every RIPE member get's an IPv6 prefix, which is true for IPv4, > we are talking about plus 10K prefixes in the table. If RIPE really and truly believes that IPv6 will become the future core protocol of the public Internet, then RIPE should allocate an IPv6 /32 to every RIPE member who has PI addresses. But that is seperate from the question of new entrants who may, or may not, be following an ISP business model. > Do people *really* think this approach works and do they > really think that such an anti-competitive 200 customer policy > - does neither hit IPv6 and the idea behind it > - does not hit community > - will not be forced down by EU commission authorities ?!? If you want to discuss anti-competitive rules, then how about the 80% threshold which fails to recognize the technical realities of IPv4 subnetting which means that large networks can never be as efficient as smaller ones. But that is being addressed by the HD-Ratio proposal. --Michael Dillon

3 2

Re: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]
by Wilfried Woeber, UniVie/ACOnet 06 Apr '05

06 Apr '05

>If you remove "to other organisations" from d) and also reword c) so that >it refers to something other than organisations (sites?) then I think >the policy will be much fairer. Now we are getting closer to the real stuff: nobody in RIPE-Land has ever been able to agree on the definition of "ISP", much less on a definition of "customer" or "organisation" or "site". >However, I still think that the plan for 200 sites within 2 years is >not necessary at this point in time. It is not even useful or helpful, because the entities which should count up to the magical number 200, eventually, are of different make and model and lifespan. If you look at the "traditional mass-market ISP", having 200 customers is zilch. Private homes, SOHO stuff, and so on. Looking at e.g. a research network, a "customer" or "site" is something like Vienna University. Till recently (before the medical faculty was split off, I don't have the curent figures at hand) this site was serving some 60K+ students plus 6..7K facutly on the campus. The whole LAN serving that community on-site can live comfortably within a *single* /48 (yes we do have an addressing plan and our backbone is dual-stack :-). But, there are "slightly" less than 200 universities in our country... Looking at the regional school districts (9 of them, aligned with the federal states), they _could_ be run as a single site within a /48 each, and from our point of view, as a single "customer" (again 9 << 200) - or they can be treated as separate schools (=sites) leaving us with a couple of thousands to add to the tally :-). It all depends on the *operational model*, the connection technology, and the contractual relationships. Bottom line: 200 is just as good or useless as a "measure" for size of an operator, or its importance, determination to introduce IPv6, or the size of a user community served - as is 0, 5, 10, 100 or 20K. And, btw, I was involved in trying to align the evolving regional IPv6 policies across the regions: the magical mistery number "200" is merely a result of social engineering, and not a result of technical or scaling deliberations. The proposals we had on the table at that time were between "0" and a couple of "thousands". > If only we had a clearer definition >of a network How about: Some transmission equipment and physiacal channel, with more than 1 attachment point, serving some functional gadet, which require a unique identification and agreeing on the use of a common set of communication rules. those ruleswhich include using those unique identifiers on more than 1 of the attachment points. > and an internetwork. More than 1 operational domain with a "network", interconnected on at least 1, probably more, points using an "interconnection network" to provide and operate the exchange of information. > I would probably say something like: >"Any organization planning to operate an IPv6 internetwork connecting >two or more physically discontiguous locations...". You might have fun coming up with a definiton of "physically discontiguous locations...", but that's a diferent exercise :-) >--Michael Dillon Wilfried.

1 0

Re: [address-policy-wg] HD ratio policy proposal
by Erics 06 Apr '05

06 Apr '05

Dear colleagues, we think the IPv4-HD-Ratio is a good instrument for LIRs to manage the demand of address space. Especially in view of their internal topologies. Even though it may have some limited impact to address space consumption we support this proposal. Kind regards Eric - for de.telekom

1 0

RE: [address-policy-wg] Summary TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 05 Apr '05

05 Apr '05

>2. /32 vs. /48 V6 prefix - routability aspect > >From a routing table perspective there is no difference if the prefix is >longer or shorter. Well, for those so keen on preserving the last bit of memory, a _shorter_ prefix would actually be more efficient ;-) > 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. Other than the goal of conservation (which we have beaten to death already) what is the benefit of doing that? Administrative ease to collate them from the database? I would be be more worried abut the potential of taking the whole block down in one big sweep by misconfiguration and/or leaking announcements. But maybe this isn't an issue in the world of anycast for "critical" DNS services. Otoh, for those who don't like the concept, it would make it easier to cut off connectivty to those segments by entering just 1 filter... Wilfried.

1 0

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