[lir-wg] RE: [ipv6-wg at ripe.net] Discussion about RIPE-261
Joao Luis Silva Damas joao at psg.com
Mon May 26 09:30:36 CEST 2003
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.
[ lir-wg Archives ]