- lir-wg - mailman.ripe.net

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 26 May '03

26 May '03

My comments about RIPE-261: - I like the fact that the three big RIRs are working together up front. It is full of good intentions. - The "sparse allocation algorithm" or "binary chop algorithm" is trying to re-invent the wheel. Please refer to RFC3531 instead. It is a good idea though. - I don't like the idea of the CAP. > Gert Doering wrote: > Nevertheless, let's get back to the basic question - how > shall we go ahead: My order of preference is (with notes) | [1] go for a full multi-level regional distribution, down to | "one /32 per LIR per country" (as detailed by Michael Py) This still requires some work to be done but has finer aggregation capabilities than the one below. In essence, it is an enhancement of the one below. | [2] allocate bigger chunks IANA->RIR (/8?) and inside those | chunks, use a binary chop algorithm similar to the one | described in RIPE-261 This looks a good option to me. If going this way I would advise including AFRINIC up front in the process even though they have not started yet. | [3] continue the IANA->RIR->LIR allocation as it is now It's not good but it's not bad. | [4] accept RIPE-261 The main reason I put list as my last choice is because I think the size of the CAP (/3) is too big. If we want any special-purpose application we'll have to get out of FP001 which is going to be politically very difficult. If the CAP was a /5 I would have put this option as #3. Michel.

1 0

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 26 May '03

26 May '03

Folks, [consolidated answers] > Hank Nussbacher wrote: > So don't assign wealth. I never did. > Use some number that has direct influence on IPv6 > usage. Among the possibilities: > - # of computer per capita This would definitely have a direct bearing on IPv6 usage, but is subject to change a lot more rapidly than population. In China for example, I have seen some projections that say the number of connected computers per capita will be multiplied by 100 in the next 10 years. Compare this with the growth of the Chinese population. I don't remember you giving specific reasons why allocation based on population is bad. > Clive D.W. Feather wrote: > Either population or land area is about the best indicator you're > going to get of *eventual* *long-term* demand. I agree. I picked population because IPv6 usage is tied to human activity. The fact of the matter is that unless there are tremendous changes I don't see a lot of human activity in deserts, oceans and ice caps. >> Andre Oppermann wrote: >> Can anyone tell me why an IP address should be geograhically >> significant in this way? Doesn't this open a can of worms of >> potential abuse all over the place? > Gert Doering wrote: > One motivation I can see for it is to permit more-specific > announcements inside a region (because it's interesting to > find "the shortest way" to the destination network) but to > summarize the routing information "from the outside". > For us, as a small german ISP, it's not really important who > is hooked up where in the US or in the AP region - so a > summary route "all this stuff is in the US, send this to > our upstream" (simplified) is likely to suit us fine. I agree and I will add to this that even if you don't have the more-specific announcements the geography could be used to take an educated guess at traffic engineering. Example: - You buy transit from to bigger ISPs, A and B. ISP A has dark fiber all over the place but not too much L3 infrastructure and they backhaul your circuit to Paris which is their main hub. You know that ISP B has a large number of peers in an IXP in Germany where lots of ISPs also peer. - If you have no specific route to a prefix, it makes sense to send all traffic to German prefixes to ISP B, because the likeliness of ISP B having a shorter connection is greater. > But then, *if* we decide to do some kind of distribution on > the geographic level, we need to setup "chunks" in advance > (to avoid having more than one high-level prefix per "region"). > So this scheme should take future development into account - > and who are we to say that a country X "will always be poor > and under-developed"? Agree. > Leo Vegoda wrote: > It is worth noting that the current IPv6 policy is not > restricted to allocating /32s. LIRs moving large numbers > of IPv4 customers to IPv6 can receive shorter prefixes: > [..] > For this reason, it probably makes sense to take account > of existing IPv4 usage when considering this issue. It does indeed. Michel.

2 1

RE: [ipv6-wg@ripe.net] Discussion about RIPE-261
by Joao Luis Silva Damas 26 May '03

26 May '03

Michel, using countries as the delimiter for any sort of network design seems a bit strange. Isn't the natural boundary closer to be an ISP, wherever its network is? You talk about colonising planets. I would think that is much more probable you would have to worry about some European countries merging in a few decades. The opposite can also happen, as it has in recent history. Regional definitions also change. Form instance, would you care to explain the concept of Western Europe vs Eastern Europe, particularly beyond 2004? Last time I checked, Hawaii was still part of the USA. And so on... Even if every user becomes multi-homed, as is a common scenario quoted by IPv6 visionaries, would the focus change from the ISP towards the user as the reference point for routing and network operations? I really don't think so. Just like today you would get to talk to your cable TV company, the electricity company, the gas company, the water supply company, etc. Each of them, and a few new ones, would operate some sort of IP network to read your meters, provide "extra" service, etc and each is likely to have different policies because that would be the factor providing them with a way of differentiating their service. Geography is not that important, network topology and autonomous policies are. Joao At 13:59 -0700 25/5/03, Michel Py wrote: >Gert, > > >> Gert Doering wrote: >> - The /23 allocations ICANN -> RIRs are bad, because they lead to >> address space fragmentation, and the blocks are too small to do >useful >> allocation towards the LIRs. Something NEEDS to be changed here. > >Agree. > > >> So my personal recommendation would be: >> - change the /23 allocation boundary ICANN -> RIR to something more >> useful, like a /12 or so (a /12 means "512 of them are available, >> so we're not yet burning bridges - but a /8 would work as well. >> A /16 is already somewhat tight). > >I don't find this very flexible. If you look at what happened with >LACNIC, countries from ARIN were transferred to LACNIC. I expect that >when AFRINIC is activated, countries from both RIPE and ARIN will be >transferred to AFRINIC. > >I agree with this goal: > >> - As a technical reason: people want to be able to filter IPv6 >> prefixes by region, like "I only have one uplink that provides me >> with US connectivity, so there's no need to carry any US prefixes >> in my routing table, I just point a summary down that line". > >If you want to do this, you might as well do it right in the first >place. IMHO, delegating space to a RIR as a single block is a mistake. >It would be much more flexible to assign space to countries, and simply >say that RIRs have stewardship of the space assigned to countries >belonging to them. If a country changes RIRs like we have seen for >LACNIC and like we will likely see for AFRINIC, no change in addresses >and the geographical summary is preserved. > >Below is an example interpolated from the work we have done on >geographic assignments: >http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > >Quick notes: >- We are presently talking about PA space; the document mentioned above >refers to PI space. However the geographic cutoff collapsed to the >country level would not change. > >- I chose to assign a /8 to the entire world, which can be discussed. >This means that after we colonize 255 other planets we have a problem >:-) can someone help me with that warp drive please? > >- What could also be discussed are the details of how this was >generated, but I would like to get the _concept_ across then we can talk >about the details. > >Zone Population %G Pop. IANA >---------------- ---------- ------- -------------- >China 1284971000 20.91% 2346:0000::/11 >Continental Asia 673454413 10.96% 2346:2000::/11 >India 1025096000 16.68% 2346:4000::/12 >Northern Africa 565854163 9.21% 2346:5000::/12 >Asian Islands 488468000 7.95% 2346:6000::/12 >Western Europe 423412058 6.89% 2346:7000::/12 >North America 318243350 5.18% 2346:8000::/12 >South America 350724557 5.71% 2346:9000::/13 >Eastern Europe 307858000 5.01% 2346:9800::/13 >Middle East 258577000 4.21% 2346:A000::/13 >Southern Africa 242566332 3.95% 2346:A800::/13 >Central America 175719760 2.86% 2346:B000::/14 >Oceania 30568053 0.50% 2346:B400::/16 >---------------- ---------- ------- -------------- >World 6145512686 100.00% 2346:0000::/8 > > >Example of one zone: > >Country Population %Z Pop. %G Pop. IANA >------------------- ---------- ------- ------- -------------- >United States 285926000 89.85% 4.65% 2346:8000::/13 >Canada 1015000 9.75% 0.50% 2346:8800::/17 >Hawaii 1224398 0.38% 0.02% 2346:8880::/21 >Bermuda 60000 0.02% 0.00% 2346:8888::/24 >Greenland 12483 0.00% 0.00% 2346:8889::/24 >-------------------- ---------- ------- ------- -------------- >Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 > >Implementing such a system would change the way large(global) LIRs >request space from RIRs. As of today, they would typically request one >/32 per RIR. For people the size of Sprint, they would then have to >request a /32 per country they service and assign space to customers >from the correct prefix. > >What this means to large LIRs is a large initial number of prefixes, but >it's not fundamentally worse than an always-growing number of /32s when >IPv6 finally takes off IMHO. > >For smaller LIRs that service only one country, there would be no >change. > >There would be some impact on the GRT as there would be a "SPRINT-USA" >block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" >block, etc. In other words, what we are looking at is one /32 prefix per >country per large LIR, opposed to as many /32s a large LIR would need in >the long run anyway. > >Comments welcome. > > >> - inside that RIR allocation, use the binary chop algorithm >> described in RIPE-261 for the RIR->LIR distribution. > >I'm not familiar with this; would that be something like RFC3531? > >Michel.

1 0

Re: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261
by Hank Nussbacher 26 May '03

26 May '03

At 01:59 PM 25-05-03 -0700, Michel Py wrote: Can you explain "%G Pop."? How is it calculated? I assume it has to do with GDP but please explain the calculation as well as the source of the numbers (the exact UN stats page would help). Needless to say, your numbers do not seem to take in any socio-economic factors. Assigning a /12 to North America as well as to Northern Africa and India might make socialistic sense as well as being "politically correct", but from a reality standpoint, it just don't fly. -Hank >Below is an example interpolated from the work we have done on >geographic assignments: >http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > >Quick notes: >- We are presently talking about PA space; the document mentioned above >refers to PI space. However the geographic cutoff collapsed to the >country level would not change. > >- I chose to assign a /8 to the entire world, which can be discussed. >This means that after we colonize 255 other planets we have a problem >:-) can someone help me with that warp drive please? > >- What could also be discussed are the details of how this was >generated, but I would like to get the _concept_ across then we can talk >about the details. > >Zone Population %G Pop. IANA >---------------- ---------- ------- -------------- >China 1284971000 20.91% 2346:0000::/11 >Continental Asia 673454413 10.96% 2346:2000::/11 >India 1025096000 16.68% 2346:4000::/12 >Northern Africa 565854163 9.21% 2346:5000::/12 >Asian Islands 488468000 7.95% 2346:6000::/12 >Western Europe 423412058 6.89% 2346:7000::/12 >North America 318243350 5.18% 2346:8000::/12 >South America 350724557 5.71% 2346:9000::/13 >Eastern Europe 307858000 5.01% 2346:9800::/13 >Middle East 258577000 4.21% 2346:A000::/13 >Southern Africa 242566332 3.95% 2346:A800::/13 >Central America 175719760 2.86% 2346:B000::/14 >Oceania 30568053 0.50% 2346:B400::/16 >---------------- ---------- ------- -------------- >World 6145512686 100.00% 2346:0000::/8 > > >Example of one zone: > >Country Population %Z Pop. %G Pop. IANA >------------------- ---------- ------- ------- -------------- >United States 285926000 89.85% 4.65% 2346:8000::/13 >Canada 1015000 9.75% 0.50% 2346:8800::/17 >Hawaii 1224398 0.38% 0.02% 2346:8880::/21 >Bermuda 60000 0.02% 0.00% 2346:8888::/24 >Greenland 12483 0.00% 0.00% 2346:8889::/24 >-------------------- ---------- ------- ------- -------------- >Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 > >Implementing such a system would change the way large(global) LIRs >request space from RIRs. As of today, they would typically request one >/32 per RIR. For people the size of Sprint, they would then have to >request a /32 per country they service and assign space to customers >from the correct prefix. > >What this means to large LIRs is a large initial number of prefixes, but >it's not fundamentally worse than an always-growing number of /32s when >IPv6 finally takes off IMHO. > >For smaller LIRs that service only one country, there would be no >change. > >There would be some impact on the GRT as there would be a "SPRINT-USA" >block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" >block, etc. In other words, what we are looking at is one /32 prefix per >country per large LIR, opposed to as many /32s a large LIR would need in >the long run anyway. > >Comments welcome. > > > > - inside that RIR allocation, use the binary chop algorithm > > described in RIPE-261 for the RIR->LIR distribution. > >I'm not familiar with this; would that be something like RFC3531? > >Michel.

1 0

Discussion about RIPE-261
by Gert Doering 23 May '03

23 May '03

Hi, those of you that have been to Barcelona have heard the presentation by Paul Wilson from APNIC concerning the RIPE-261 document. In short, it's a proposal how to reorganize distributing IPv6 allocations "from the root" to the LIRs, fixing the way it's done now (ICANN allocating /23 fragments to the RIRs, and the RIRs having to fill them quite thoroughly, not leaving space for an ISP to grow past a /29). Technically, this is a matter between the RIRs and ICANN, but as this proposal affects routing and filtering as well, it would be useful to have consensus among the members that it's a good thing. So: please read the document (ftp://ftp.ripe.net/ripe/docs/ripe-261.txt) and comment on it. Note: this e-mail goes to ipv6-wg and lir-wg, but please don't followup to ipv6-wg - keep all of the discussion in the lir-wg mailing list. Speaking as "me personally" (this is not the official WG chair speaking here, just a concerned IPv6 user!), I have the following comments: - The /23 allocations ICANN -> RIRs are bad, because they lead to address space fragmentation, and the blocks are too small to do useful allocation towards the LIRs. Something NEEDS to be changed here. - Nevertheless, I do NOT like the idea of a "common address pool". People want to be able to see the "region" that a prefix is coming from by looking at the address. This is working fine now in v4 (except for the swamp and part of ERX) and in the so-far IPv6 allocations (except that due to the /23s it's getting messy), but would be broken by the CAP. - As a technical reason: people want to be able to filter IPv6 prefixes by region, like "I only have one uplink that provides me with US connectivity, so there's no need to carry any US prefixes in my routing table, I just point a summary down that line". This is not yet done, but I am convinced that we shouldn't break routing hierarchy without good need. - If people *really* go into "multiple /48s per site" multihoming, source address selection works by doing a longest-match check, and this will work better if same-region addresses have something like a common prefix, instead of "everythins smeared everywhere". So my personal recommendation would be: - change the /23 allocation boundary ICANN -> RIR to something more useful, like a /12 or so (a /12 means "512 of them are available, so we're not yet burning bridges - but a /8 would work as well. A /16 is already somewhat tight). - every RIR still gets its own allocation from where RIR->LIR allocations are taken - inside that RIR allocation, use the binary chop algorithm described in RIPE-261 for the RIR->LIR distribution. So - let the discussion start now! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

2 1

Autoreply: [lir-wg] Discussion about RIPE-261
by webmaster＠keyworld.net 23 May '03

23 May '03

Hi, I am out of the office till the 9th of June 2003. --> If you have a technical issue please send an e-mail to support(a)keyworld.net. --> If you have a query on the Vegastream products please send an e-mail to sales(a)keyworld.net. --> If you have a query on website hosting or require changes to one currently hosted with us please contact Mr. Alton Costa on email alton(a)keyworld.net Thank you for choosing KeyWORLD as your communications partner. Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster(a)keyworld.net Website: http://www.keyworld.net

1 0

AW: [lir-wg] Problems with route object update
by Marcus.Ruchti＠colt.de 23 May '03

23 May '03

that's true, I've made the same experiences. Mostly we request an own maintainer for a customer when we request a new PI network, but the majority of the users hasn't the knowledge or they don't want to build up knowledge to create or to update the RIPE database... Marcus -----Ursprüngliche Nachricht----- Von: Sebastien Lahtinen [mailto:md@ncuk.net] Gesendet am: Donnerstag, 22. Mai 2003 15:20 An: Wilfried Woeber, UniVie/ACOnet Cc: lir-wg(a)ripe.net Betreff: RE: [lir-wg] Problems with route object update On Thu, 22 May 2003, Wilfried Woeber, UniVie/ACOnet wrote: > >but if it was not an option for the LIR to be maintainer of the > >customers PI assignment (end user mandatory maintainer) it would solve > >the problem. > > 2 problems here: > > - the LIR has to "donate" its resources to apply for the PI block with > the NCC. So there may be a reason (in some cases) for protecting the > object with the LIR's maintainer; > > - in our case (for customers with legacy addresses) we have an agreement > in place to jointly manage and protect the inetnum objects. Some may > even choose to have us do that as a service. > For that reason, blocking this would be undesirable from my point of > view. I couldn't agree more. We've done PI for clients on their own maintainer if that's what they want, but creating extra maintainers "for the sake of it" seems pointless because half the PI users may not understand how to use their maintainer anyway! Sebastien. --- NetConnex Broadband Ltd. tel. +44 870 745 4830 fax. +44 870 745 4831 Court Farm Lodge, 1 Eastway, Epsom, Surrey, KT19 8SG. United Kingdom.

2 1

Problems with route object update
by Marcus.Ruchti＠colt.de 22 May '03

22 May '03

Hi all, I've recognized that we have massive problems in the last weeks with RIPE database updates by other ISP's. e.g. a new customer wants that we will announce a PI network used by him but it is maintained by another LIR. I've asked for creating a route object with our maintainer several times without success. I think all this happens with intention to constrain the business activity of the competitor ! Is there a possibility to insert the RIPE-NONE Maintainer in the whole PI blocks (e.g. /16). In this step I won't mention the names of those ISP's... regards, Marcus Ruchti COLT Telecom GmbH

3 4

RE: [lir-wg] Problems with route object update
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

>> We recommend that End Users maintain their PI inetnum themselves if they >> want to do so. However, they are free to have their provider maintain it >> for them if they want that, instead. > >Yes, I understand, the problem is if the LIR decides not to inform the >customer of this option, This sounds like a business relation (ethics?) issue, rather than a registry or database issue. >but if it was not an option for the LIR to be >maintainer of the customers PI assignment (end user mandatory maintainer) it >would solve the problem. 2 problems here: - the LIR has to "donate" its resources to apply for the PI block with the NCC. So there may be a reason (in some cases) for protecting the object with the LIR's maintainer; - in our case (for customers with legacy addresses) we have an agreement in place to jointly manage and protect the inetnum objects. Some may even choose to have us do that as a service. For that reason, blocking this would be undesirable from my point of view. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Archives of LIR WG sessions available
by Gert Doering 15 May '03

15 May '03

Hi LIR WG readers, for those of you that are not aware of it already: the LIR WG meeting yesterday was recorded and is now available online, via the following URLs: mms://webcast.ripe.net/ripe45/lir-1.wmv mms://webcast.ripe.net/ripe45/lir-2.wmv (visible via windows media player and mplayer under Linux) regards, Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54495 (54267) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0