[rpd] Some thoughts, and some actions required

[Douglas Onyango]

Hi Scott,
On 29 January 2016 at 04:28, Scott Leibrand <scottleibrand at gmail.com> wrote:
>I don't have a strong opinion on how that should be
> done: I'm just pointing out that it would be good to ensure some sort of
> soft landing free pool remains for several more years to ensure IPv4 space
> is still available for new entrants until the burden of interconnecting the
> legacy IPv4 Internet to the IPv6 Internet switches from IPv6-only to
> IPv4-only networks.

I believe this is why we have the /12 reserved.

>
> -Scott
>
>
> On Thu, Jan 28, 2016 at 6:22 PM, Douglas Onyango <ondouglas at gmail.com>
> wrote:
>>
>> Hi Scott,
>> In this case, I think adding v6 deployment as an eligibility
>> requirement should suffice?
>> Whether it's on the first allocation/assignment or on subsequent ones
>> can be discussed.
>>
>> Regards,
>>
>> On 29 January 2016 at 04:11, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>> > There are certain needs for IPv4 space that only require uniqueness, but
>> > not
>> > routability.  For example, router IDs often need to be unique IPv4
>> > addresses
>> > (even when only routing IPv6), but they don't need to be announced to
>> > anyone.  To date, most requests under 4.10 have been for /24s, and ARIN
>> > considers "we'd like to route this block on the Internet" to be valid
>> > justification for needing a /24, so the policy allowing (but not
>> > requiring)
>> > smaller allocations doesn't do any harm.  ARIN already has to do
>> > non-classful rDNS delegation for blocks >/24, so I don't think the
>> > burden
>> > there (if people actually choose to request smaller blocks) will be all
>> > that
>> > significant.
>> >
>> > I am not necessarily suggesting reserving *more* space: if you'd prefer
>> > you
>> > could tighten up the eligibility requirements on some of the
>> > already-reserved space.  I am only suggesting that completely exhausting
>> > the
>> > AfriNIC IPv4 free pool, with no space left to allocate to new entrants
>> > for
>> > any reason, would put African companies at a disadvantage to new
>> > entrants in
>> > other regions, who all have some sort of space reserved for that
>> > purpose.
>> >
>> > -Scott
>> >
>> > On Thu, Jan 28, 2016 at 5:58 PM, Douglas Onyango <ondouglas at gmail.com>
>> > wrote:
>> >>
>> >> Hi Scott,
>> >> On 28 January 2016 at 23:25, Scott Leibrand <scottleibrand at gmail.com>
>> >> wrote:
>> >>
>> >>
>> >> > I would also suggest that at the very least the AfriNIC community
>> >> > consider
>> >> > an addition to the soft-landing policy that sets aside an IPv4 block
>> >> > dedicated to facilitating IPv6 deployment, by making IPv4 addresses
>> >> > available for IPv6 translation technologies, dual stack DNS servers,
>> >> > etc.
>> >> > Something like https://www.arin.net/policy/nrpm.html#four10 could be
>> >> > implemented either by carving out a pool out of AfriNIC's existing
>> >> > inventory, or by dedicating space newly redistributed from IANA for
>> >> > the
>> >> > purpose.  Alternately, a RIPE/APNIC style "one block per network"
>> >> > soft
>> >> > landing policy would accomplish a similar objective: making sure that
>> >> > future
>> >> > new entrants can continue to receive enough IPv4 addresses to talk to
>> >> > the
>> >>
>> >> While I like the idea of promoting v6 deployment as we near
>> >> exhaustion, I find the idea of further reserving the more space not
>> >> very appealing. You must recall that the Softlanding has already
>> >> reserved a /12 for unforeseen circumstances.
>> >>
>> >> Further, I am curious as to what motivated ARIN's choice to allocate
>> >> /28-/24 block from the reserve in your policy
>> >> https://www.arin.net/policy/nrpm.html#four10
>> >>
>> >> I can only see this approach either breaking the Internet, as people
>> >> drop your routes on account of size, or additional reverse delegation
>> >> work being created for the RIR.
>> >>
>> >>
>> >> Regards,
>> >
>> >
>>
>>
>>
>> --
>> Douglas Onyango, PRINCE 2, ITILv3
>> UG: +256 776 716 138
>
>



-- 
Douglas Onyango, PRINCE 2, ITILv3
UG: +256 776 716 138