Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Summary of proposals: IPv4 Runout Management

Kevin Kamonye kevin.kamonye at gmail.com
Tue Nov 8 17:05:10 UTC 2016 

In my view, both proposals are a not ideal but I will support the latter.

*¬001-DRAFT03*

Pros:
- *Action: Reserve a /13 for some future uses, as yet unforeseen...* <-
Ideally means less v4 would be available for allocation. Make this a /8 and
am all in.

Cons: -
- Everything.

- Special mention to old-school regulator mentality of 'protecting (read
denying)' resources by introducing unnecessary complications, and just
generally trying to tell others that you know what is best. And please,
this is not a personal attack on the authors who am sure are all members of
this community; this is just how it looks to me.

*¬002-DRAFT01*

Pros: -
*Allows the most rational depletion of v4, consequently encouraging compelling
the uptake of v6, even though it ensures v4 will still be relevant several
decades into the future

*Generally *more* clear and concise in what it aims to achieve and how to
achieve it.

Cons: -
Vague on how it will *Encourage the uptake of IPv6 in an aggressive manner*

Regards,

*Kevin*


On 8 November 2016 at 17:04, Arnaud AMELINA <amelnaud at gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> 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/4097b1d4/attachment-0001.html>

More information about the RPD mailing list