[sig-policy]RE: [sig-ipv6]Let's restart discussion about RIPE-261 [long]
As a reply to Gert Doering on the RIPE LIR mailing list, I recently
proposed an alternative method to delegate space to RIRs. The main goal
behind this proposal is to comply with the following:
> Gert Doering wrote:
> - 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 a valid goal, IMHO. However, I find some potential issues with
what Gert proposed below:
> Gert Doering wrote:
> 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).
The issues are related to RIR reorganization, such as the one we just
had with LACNIC and the one we are expecting with AFRINIC. If a country
changes RIRs, it is no longer part of the summary it used to be,
resulting in new assignments being made out of the prefix of the new RIR
and address space fragmentation.
Although we could (and should) anticipate the creation of AFRINIC,
Gert's proposal would leave no option to changes made in the APNIC
region after the fact.
Please note that I am not suggesting or recommending any changes being
made; my point is simply a matter of admitting that things are never set
in stone and that changes do happen over time for a variety of reasons.
In a nutshell my proposal is about this:
Instead of delegating space to RIRs, space is delegated to countries
instead, based on predicted population. Then, LIRs are given stewardship
of the address space of countries that belong to their jurisdiction.
If a country changes RIRs, the stewardship of the country's address
space is simply transferred to the new RIR and address assignments made
in the country are still made out of the same block by the new RIR (vs.
being made out of the new RIR's block) and this would preserve the goal
mentioned at the beginning of this text.
Below is an example of how it could work:
Zone Population %G Pop. IANA
---------------- ---------- ------- ---------
China 1284971000 20.91% 2100::/11
Continental Asia 673454413 10.96% 2120::/11
India 1025096000 16.68% 2140::/12
Northern Africa 565854163 9.21% 2150::/12
Asian Islands 488468000 7.95% 2160::/12
Western Europe 423412058 6.89% 2170::/12
North America 318243350 5.18% 2180::/12
South America 350724557 5.71% 2190::/13
Eastern Europe 307858000 5.01% 2198::/13
Middle East 258577000 4.21% 21A0::/13
Southern Africa 242566332 3.95% 21A8::/13
Central America 175719760 2.86% 21B0::/14
Oceania 30568053 0.50% 21B4::/16
---------------- ---------- ------- ---------
World 6145512686 100.00% 2100::/8
Example of one zone:
Country Population %Z Pop. %G Pop. IANA
------------------- ---------- ------- ------- --------------
United States 285926000 89.85% 4.65% 2180:0000::/13
Canada 1015000 9.75% 0.50% 2188:0000::/17
Hawaii 1224398 0.38% 0.02% 2188:8000::/21
Bermuda 60000 0.02% 0.00% 2188:8800::/24
Greenland 12483 0.00% 0.00% 2188:8900::/24
-------------------- ---------- ------- ------- --------------
Zone: North America 318243350 100.00% 5.18% 2180:0000::/12
Above is an example interpolated from the work we have done on
geographic assignments:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt. I do encourage the
reader to have a quick look at it, keeping in mind that the link above
is totally unrelated to today's topic; I simply leveraged the geographic
database I hand on hand.
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.
- 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.
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. Related to root-to-RIR delegations, geography is a
half-baked idea and I am conscious of this. Don't hesitate to ask
questions.
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.
- I don't like the idea of the CAP.
Gert asked the following on the RIPE list a few days ago:
| [ ] continue the IANA->RIR->LIR allocation as it is now
| [ ] accept RIPE-261
| [ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks,
| use a binary chop algorithm similar to the one described in
RIPE-261
| [ ] go for a full multi-level regional distribution, down to
| "one /32 per LIR per country" (as detailed by Michael Py)
| [ ] something else
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.