Search RPD Archives
[rpd] Summary of proposals: IPv4 Runout Management
Noah
noah at neo.co.tz
Tue Nov 8 18:20:40 UTC 2016
Alain
+1
You break down make sense...
Noah
On 7 Nov 2016 18:48, "ALAIN AINA" <aalain at trstech.net> wrote:
> Hello,
>
> See inline...
>
> On Nov 5, 2016, at 6:40 AM, Owen DeLong <owen at delong.com> wrote:
>
>
> On Nov 4, 2016, at 13:08 , Andrew Alston <Andrew.Alston at liquidtelecom.com>
> wrote:
>
> Please can we know what the motivation behind the /14 number chosen for
> new entrants is and what data was used to select this number.
>
> The same applies for the /13 for unforeseen future, how was this number
> arrived at, and can we understand the motivation behind reserving more
> space for unforeseen future than for new entrants.
>
> Without data to evaluate these numbers they come across as arbitrary and
> without justification and I oppose putting anything into policy that cannot
> be backed by empirical facts.
>
> I oppose the IPv6 address space as a requirement – it has proven to be an
> ineffective method of promoting ipv6 and serves absolutely no purpose (see
> V6 announcement vs allocation statistics and the fact that the continent
> already has over 500 ipv6 assignments spread pretty evenly across the
> continent with active deployments in only 3 or 4 countries)
>
> I oppose the allocations for new entrants being used exclusively for ipv6
> transition – I do not believe that AfriNIC has the right to dictate to
> anyone how they use their space, and if they have a legitimate requirement
> for v4 space for internal (non globally routable, but requirement global
> uniqueness) they should be able to get it – there would be no translation
> on such internal things.
>
> Andrew
>
> On 04/11/2016, 22:51, "ALAIN AINA" <aalain at trstech.net> wrote:
>
> Hello All.
>
> Thanks Co-chairs for the summary on the IPv4 softlanding-bis proposal.
>
> Our proposal set:
>
> a /16 for Critical Infrastructure : DNS root ops, IXPs, TLD (cc and g)
> ops, RIRs, IANA
>
>
> This is too broad, given the IANA gTLD Make Money Fast scheme currently
> being deployed.
>
>
> We can narrow it down to the geographic gTLD. The plan was to make sure
> the emerging gTLD registries operating in the region, be treated as the
> cc. Let's hear what folks think .
>
>
> a /14 for new entrants
>
>
> I’m not in support of this without further clarification as previously
> stated.
>
>
> Make sure New entrants( without no previous allocations/assignments) get
> the minimum v4 space needed from the "102/8" to support their v6 to v4
> services.
>
> Rationale behind the /14. AFRNIC has in average 133 new members a year.The
> /14 covers the need for just under 2 years with a max allocation of /22.
> See slide 24 from presentation given at AFRINIC-24 in Botswana,
> http://www.trstech.net/alain/public/softlanding-slides-AFRINIC-24.pdf
>
>
> 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.
>
> 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)
>
>
> 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:
>
> 1. Be an LIR;
> 2. Not be an end site;
> 3. Show a detailed plan to provide IPv6 connectivity to organizations
> in the AFRINIC region.
> 4. 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*
>
> 1. Assignment target - End-sites which provide Public Internet
> services for a single administrative organisations' network, regardless of
> their size.
> 2. 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161108/d468932e/attachment-0001.html>
More information about the RPD
mailing list