Search RPD Archives
[AfriNIC-rpd] Re: [resource-policy] AfriNIC Policy Proposal:IPv6ProviderIndependent (PI) Assignment for End-Sites
Adiel A. Akplogan
adiel at afrinic.net
Thu Mar 15 17:44:12 UTC 2007
>Andrew Alston wrote:
>>>>As for slack space for growing a range, this is a difficult issue
>>>>but I think it is one which is a matter of assignment logistics and
>>>>not assignment policy.
>>>>Perhaps the provision of a /44 per /48 should be determined by the
>>>>intended use of the block.
>>>I agree with you and I think we should leave this to the RIR
>>>(AfriNIC) to determine when making the assignment.
>>I have to respectfully (strongly) disagree with this. Unless there is a
>>strong policy about the boundaries and boundaries are fixed, it leaves the
>>door open to chaos (and while I am a great fan of a chaotic open internet,
>>there are limits).
>>The drawbacks I see are as follows:
>>a.) The entire reason for the boundary is to allow for growth, ANY
>>organization should be allowed to grow, and as far as I know, and as far as
>>I know AfriNIC does not employ psychics, if this boundary is non-static,
>>mistakes are bound to happen, people will get blocks that cannot grow, and
>>once again, the routing table starts to grow!
>>b.) The idea of a /44 boundary levels the playing field, everyone is
>>entitled to the same initial, everyone is entitled to grow, let's not allow
>>some who know how to work the system to end up with more than those that
>>don't, because I see this as a real danger unless there are fixed policies.
>>(look at the situation with v4 at the moment, and while I won't go into what
>>I mean by working the system, a little analysis and some thought should
>>clear up what I mean)
>>c.) We need some uniformity in what we do in regards to what the other RIR's
>>are doing, and the /44 boundary I might add is already in policy in at least
>>one other region (ARIN)
>As AfriNIC already puts /32's on reasonable growth boundaries - why
>should we not expect them to do the same with /48 assignments? (I
>guess its fair to make a strong suggestion though)
>Look at the bottom of
>the allocs look like..
Thanks Mark, that is perfect illustration of what I just said
in my previous mail.
More information about the RPD