Hytham EL Nakhal wrote:
Hi Vincent,
Thank you ,
>>(b) On the other hand, we need to consider the needs/demand for
IP from the different countries in >>the AfriNIC region; it's
not proportionate .
Sure it's not proportionate so that I said >> " if " we divide PI
blocks equally.. I agree with you & George Ezzat for that some
countries will need more PI than others but in worst case if we divide
it equally each country I think will have enough PI keeping in mind
your comment point >> (c) It's however worth noting that end-users
with a high demand (>> /48) for v6 space can always become an LIR or
acquire the same from an LIR. Let's not forget that the primary
objective of this policy is to provide PI v6 for critical
infrastructure providers.
All countries proportional?? not really - Swaziland will never need as
many PI allocations as South Africa.
Having said that - is it not the job of the Registry to work out these
finer points? They are doing a reasonable job so far.
On Mar 13, 2007, at 7:55 PM, Hytham EL Nakhal wrote:
>
> Dear Vincent,
>
> I'd like to discuss something may be get benefits of all
> suggestions regarding PI assignment, What about dedicating a /32
> for PI assignments, and each PI is /48 , so we have 2 to the power
> 16 PI assignments (i.e. 65536 /48 PI blocks). AfriNIC provide
> services for Africa Continent which contains about 55 countries. So
> if we divide PI blocks equally over countries we find that each
> country will have more than 1190 PI blocks, "Is it enough for each
> country" ? to know the answer we can have a look on the number of
> IPv4 PI assignments for each country in database (keeping in mind
> that /48 IPv6 block has addresses more more than /24 IPv4).
>
> Then we can make all /48 PI assignments from a dedicated /32 block
> and in same time we can arrange for a serial /48 blocks for each
> country and inside each country we can keep a guard band for each
> PI assignment in case of future growth.
This is a very nice suggestion.
(a) IMHO, though a /32 is not as large a space as the numbers may
insinuate, with proper usage of assigned /48 prefixes, we can greatly
minimise the need for preserving a /32 for every /48 assigned.
(b) On the other hand, we need to consider the needs/demand for IP
from the different countries in the AfriNIC region; it's not
proportionate.
(c) It's however worth noting that end-users with a high demand (>> /
48) for v6 space can always become an LIR or acquire the same from an
LIR. Let's not forget that the primary objective of this policy is to
provide PI v6 for critical infrastructure providers.
No they can't become an LIR - not with the current IPv6 LIR policy.....
To become an LIR - you have to have customers you can sub-allocate to.
UniForum SA applied to become an LIR in order to get IPv6 address space
and was refused because they do not intend to do any sub-allocations to
other people/organisations.
If an organisation starts out getting PI space - why would they then
continue and get more (different) space from an LIR?
Is this policy for use only by Critical Infrastructure providers?
Who defines what this means?
If its "self-defining" ie - The Organisation multi-homes already with
IPv4 space and plans to do the same with IPv6 space - then I'm happy
with the wording "critical infrastructure" but not with "provider".
A number of the banks in South Africa do multi-home - I see no reason
not to allow them to be allocated PI IPv6 address space. There is a good
chance that a /48 would not be enough space - but how could they ever
become an LIR? - doesn't sound right. Sure - they could "allocate to
their branches" - but thats watering down what I see an LIR as being.
Sorry - not trying to pick on or offend anyone.... :-)
Let's see what others have to say about this.
:-)
--
. . ___. .__ Posix Systems - Sth Africa
/| /| / /__ [EMAIL PROTECTED] - Mark J Elkins, SCO ACE, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
