[sig-policy]RE: [sig-ipv6]Let's restart discussion about RIPE-261 [long]

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

Yong Wan Ju and APNIC Folks,


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.