proposal for RIPE's IPv6-address space structure
Daniel Karrenberg Daniel.Karrenberg at ripe.net
Fri Nov 22 12:05:29 CET 1996
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. > 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. > 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. 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. > We hope that this proposal will serve at least as input for > discussion. Certainly. Daniel
[ lir-wg Archives ]