proposal for RIPE's IPv6-address space structure

Hi Daniel,

> 
> Hi,
> 
> some quick comments:
> 
>   > |FP+RegID|  Provider ID | Subscriber ID | Intra-Sub |
>   > |        |  PRID | RPID |               |           |
>   > +--------+-------+------+---------------+-----------+
>   > | 8 bit  | 7 bit | n bit| (49 - n)      |  64 bit   |
>   > +--------+-------+------+---------------+-----------+
>   > 
>   > with n = 17 !
>   > 
>   > 
>   > PRID (Provider Region ID)
>   > 7 bit corresponds to 128 IDs. These are mainly reserved for the
>   > countries of the 'natural', ie. European, RIPE-Region (A5).
> 
> Can you provide a rationale for grouping providers by country.
> It strikes me as contrary to both aggregation and conservation goals.

We assume that ISPs will mainly offer their service within one country.

> 
>   > Non-European domains supported by RIPE get their own prefix
>   > (FP+RegID) in order to support a dedicated authority for
>   > these regions in the future.
> 
> This is very difficult to do since it is by no means clear where regional
> boundaries will be.

Is it much more difficult to draw a border between the African RIPE region
and the European RIPE region than between the RIPE region and the INTERNIC
region?
 
> 
>   > If this turns out not to be enough to satisfy the needs of
>   > a very LARGE provider then, there should be the option to
>   > double the assigned address space by adjoining the neighboring
>   > address block. In order to do so RPIDs should be assigned in
>   > multiples of 16 initially, leaving the option to half the
>   > 'reserved' address space but still keeping the option to
>   > double.
> 
> For this to work, the additional space needed must be exactly
> the reserved size. Usually it is either less or more.
> Strategies like that have been shown to be less than optimal for
> conservation while the additional aggregation effect is not very
> big. 

Do you prefer a scheme in which the address space of a provider is
more precisely adapted for its needs? More conservation, less aggregation?
 
> 
> How about just using the 56 bits for local-IR+subscriber?
> The boundary does not need to be fixed at all.
> Then use a similar scheme than the present IPv4 one to determine the
> size of allocations to local IRs (provider): 
> Fixed size for new local IRs and further allocations based on
> established usage rate.

I think this scheme could result in a too conservative allocation policy
with regard to the large address space we have at our disposal. It might
be negative for aggregation and/or IPSs.

> 
>   > We hope that this proposal will serve at least as input for 
>   > discussion.
> 
> Certainly.
> 
> Daniel
>