[rpd] Summary of proposals: IPv4 Runout Management

Tue Nov 8 14:04:46 UTC 2016

Hi Community

See inlines...

Le 7 nov. 2016 17:44, "Owen DeLong" <owen at delong.com> a écrit :
>>>>
>>>>   a /13 for  unforeseen future
>>>
>>>
>>> I am absolutely opposed to this.
>>
>>
>> This proposal stays in the spirit of the current soft landing policy. We
propose to reduce the reserve to accommodate new entrants and critical
infrastructures.
>
>
> Unless I am mistaken, the current soft landing does NOT include a
“Strategic Reserve” for purposes to be determined later. This is a new
feature of this proposal.
>
>> This is a “Strategic Reserve”  for future use on which community will
decide as we go.  As such i would like to hear from people in the region on
the Strategic Reserve;  3.125% of the  specific last /8 (102/8)
>
>
> I’m not sure if you intended this to be a vaguely worded implication that
I am not in the region or not. While it is true that I do not reside in the
region, as I have stated previously, I work for a company that has
substantial operations in the region and yet has not yet consumed any
AfriNIC resources while supporting virtually every single African internet
user with improved internet experiences. Like it or not, while I used to be
an interested bystander, for the last 19 months, I have been a
participating stakeholder and not merely an interested bystander.
>
> Andrew Alston is very much in the region and has also been vehemently
opposed to this provision.
>
> There’s been very little support for it on the list so far.
>

This proposal was submitted in February and went through long series
discussions  and to the face to face so how can Mr. Delong say, "very
little support"?  Shall we replay the archives or open the game again?

I refer to the cochairs.

I have been part of the  discussions in the past and active at face to
face, so how can you affirm that.

If I am forced to say it again,   I support, the reservation for the
critical  infrastructure, for new comers,  the strategic reserve,  the ipv6
requirement and so the proposal.

Regards

Arnaud

> Any technology which would need this “strategic reserve” is a technology
which does not exist yet. From my perspective, the only thing such a
provision can do is encourage such technologies to be developed with
dependencies on IPv4. This is absolutely wrong-headed. We should be
encouraging new technologies to be developed WITHOUT dependencies on IPv4
and with full IPv6 support from day 1.
>
> If you reward bad judgment (which is all that you can hope for from this
provision), then you get an increase in bad judgment. One need look no
further than the US financial crisis of 2008 for proof of this fact.
>
> Owen
>
>>
>>>
>>>>   IPv6  address space (AFRINIC or upstreams) as requirement to IPv4
allocations
>>>
>>>
>>> Can you clarify this
>>
>>
>>  Section 3.8, allocations criteria in the proposal read:
>> ……………...
>> LIR and End users requesting IPv4 must have IPv6 resources from AFRINIC
(or request concomitantly with the IPv4) or from their upstreams.
>>
>>> and how it is relevant or useful?
>>
>>
>> The last /8 (102/8) gotten through the global soft landing policy aims
among other objectives to encourage a smooth transition to IPv6.
>> So if you need  space from this last /108, show your IPv6.
>>
>> Current allocations/assignment criteria for v6 are as below from CPM:
>>
>> 6.5.1.1 Initial allocation criteria
>>
>> To qualify for an initial allocation of IPv6 address space, an
organization must:
>>
>> Be an LIR;
>> Not be an end site;
>> Show a detailed plan to provide IPv6 connectivity to organizations in
the AFRINIC region.
>> Show a reasonable plan for making /48 IPv6 assignments to end sites in
the AFRINIC region within twelve months. The LIR should also plan to
announce the allocation as a single aggregated block in the inter-domain
routing system within twelve months.
>> ===========
>>
>> 6.8.2 Assignment Criteria
>>
>> Assignment target - End-sites which provide Public Internet services for
a single administrative organisations' network, regardless of their size.
>> Assignment criteria:
>> The end-site must not be an IPv6 LIR
>> The end-site must become an AFRINIC End User Member and pay the normal
AFRINIC fee for its' membership category
>> The end site must either be a holder of IPv4 PI address space or qualify
for an IPv4 PI assignment from AFRINIC under the IPv4 policy currently in
effect.
>> The end-site must justify the need for the IPv6 PI address space.
>> The 'end-site' must show a plan to use and announce the IPv6 provider
independent address space within twelve (12) months. After that period, if
not announced, the assigned IPv6 PI address space should be reclaimed and
returned to the free pool by AFRINIC.
>> --------
>> If you do not have v6 or loose your v6 (review of allocations, etc…) you
will not qualify  for v4 in the last /8 unless justified.
>>
>>
>> Hope this helps
>>
>> —Alain
>>
>>
>>>
>>>>
>>>>   We invite people to read the FAQ which is attached to the proposal
and which helps with the understanding.
>>>>
>>>>
http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2
>>>>
>>>>   From recent discussions, the authors of the solanding-bis proposal
 would be happy  to consider  making explicit in the proposal the following
points:
>>>>
>>>>
>>>>   - Multiple new entrants under common ownership being treated as a
single new entrant
>>>
>>>
>>> If we are to have a new entrant reservation, this is a vital
protection. Otherwise, anyone can find a friendly jurisdiction in the
region and spin up as many new entrants as they like. Sort of like AWS for
Coprorations to obtain addresses.
>>>
>>> We should also put some form of exclusion or protection against
combining, consolidating, or trading in new-entrant space in any existing
merger/acquisition transfer policy as well as for any future
transfer/trade/sale policy that may be adopted.
>>>
>>>>   - Allocations to New entrants being used exclusively for IPv6
transitions mechanisms and services as explained in the FAQ
>>>
>>>
>>> I think this is also a vital protection against new entrants seeking
larger than acceptable allocations.
>>>
>>> Owen
>>>
>>>>
>>>>   Hope this helps
>>>>
>>>>   --Alain
>>>>
>>>>> On Nov 3, 2016, at 4:03 PM, Dewole Ajao <dewole at forum.org.ng> wrote:
>>>>>
>>>>> Thank you for the feedback, Owen. We look forward to the authors of
both proposals considering the various inputs as well as offering further
clarification to help the community better understand the rationale(s)
behind the current drafts of their proposal(s).
>>>>>
>>>>> Regards,
>>>>> Dewole.
>>>>>
>>>>> On 02/11/2016 23:16, Owen DeLong wrote:
>>>>>>
>>>>>> Thanks for doing this… It’s very useful.
>>>>>>
>>>>>> There are elements from each of the proposals I like, but none of
them would get my support in their current form.
>>>>>>
>>>>>> I like the idea of a reserved carve-out for critical infrastructure.
>>>>>> I like the idea of a small (/12, perhaps) cutout for new
organizations that are late to the party to receive up to a /24 for
transition purposes.
>>>>>>
>>>>>> I do not like the idea of a large reservation for new entrants to
the exclusion of the needs of existing participants.
>>>>>>
>>>>>> I especially do not like the idea of reserving a block of addresses
for some undefined future use. Any future development that would require
such a thing should be done under IPv6. There is no excuse for such
development to be done in a manner that requires IPv4 addresses at this
point in the evolution of the internet. We should not reward or encourage
backward-thinking engineering.
>>>>>>
>>>>>> I think that the reservation for critical infrastructure should be
from a specific block.
>>>>>>
>>>>>> I think it would be reasonable, if there is need, for the new
entrant block to be comprised of fragments totaling a /12 equivalent rather
than necessarily blocking out a specific /12.
>>>>>>
>>>>>> I do not think that reclaimed space should be reserved for new
entrants. Rather, I would prefer to see one of two approaches taken to
reclaimed space:
>>>>>>
>>>>>> 1. An annoucement is made on relevant mailing lists that the space
has been received and applications will be accepted beginning at a
>>>>>> certain date and time. Such date and time to be not less than 14
days after the announcement is sent out.
>>>>>>
>>>>>> or
>>>>>>
>>>>>> 2. A waiting list of unmet requests is created and the space is
offered to those requestors on the waiting list on a FIFO basis.
>>>>>>
>>>>>> If we are to have a new-entrant block (I consider this optional, but
desirable), it should be strictly for purposes of providing the addresses
needed for transitional technologies (CGN, 6rd, etc.) and we should not
allocate more than a /24 to any single new entrant. Multiple new entrants
under common ownership should be treated as a single new entrant in most
cases.
>>>>>>
>>>>>> Owen
>>>>>>
>>>>>>
>>>>>>> On Nov 2, 2016, at 13:49 , Dewole Ajao <dewole at forum.org.ng> wrote:
>>>>>>>
>>>>>>> Good day,
>>>>>>>
>>>>>>> As indicated in an earlier email, please take some time to view and
comment on https://goo.gl/FDLmZF with a view toward fine-tuning and
producing an improved IPv4 runout management plan.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> Dewole Ajao
>>>>>>> PDWG Co-Chair
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> RPD mailing list
>>>>>>> RPD at afrinic.net
>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>
>>>>
>>>>
>>>>   _______________________________________________
>>>>   RPD mailing list
>>>>   RPD at afrinic.net
>>>>   https://lists.afrinic.net/mailman/listinfo/rpd
>>>>
>>>>
>>>> _______________________________________________
>>>> RPD mailing list
>>>> RPD at afrinic.net
>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>
>>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161108/6cace7e6/attachment.html>