<div dir="auto"><div dir="auto">{warning! long email, so apologies please :'-(}</div><div dir="auto">Dear PDWG,</div><div dir="auto"><br></div><div dir="auto">Please apologies for the pasting action :'-(</div><div dir="auto"><br></div><div dir="auto"><tl;dr></div><div dir="auto">Yes! i took the responsibility to bring the CPM section 5.5 | IPv4 LIR/ISP Allocations (5.5.1 Allocation policies and guidelines) to you, in case it might have been a too hard task to go it the location of that content. Please accept to read it...</div><div dir="auto"><br></div><div dir="auto">...i did it with the naive expectation that it </div><div dir="auto">could help the PDWG to move forward </div><div dir="auto">on some recuring topics, such as </div><div dir="auto">Internet number resources (at least for </div><div dir="auto">IPv4 types) utilisation and responsibilities </div><div dir="auto">thereof, within the AfriNIC's service region.</div><div dir="auto"><br></div><div dir="auto">Therefore permit me to recommend the following subventions to your particular attention:</div><div dir="auto"><br></div><div dir="auto">¿°?</div><div dir="auto">•<span style="font-family:sans-serif"> </span><span style="font-family:sans-serif">5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered.</span></div><div dir="auto">• <span style="font-family:sans-serif">5.5.1.2.3 Must show an existing efficient utilization of IP addresses from their upstream provider.</span></div><div dir="auto"><span style="font-family:sans-serif">• </span><span style="font-family:sans-serif">5.5.1.3 Slow start mechanism for first allocations</span></div><div dir="auto"><span style="font-family:sans-serif">• </span><span style="font-family:sans-serif">5.5.1.4.1 An LIR may receive an additional allocation when about 80% of all the address space currently allocated to it has been used in valid assignments and/or sub-allocations.</span></div><span style="font-family:sans-serif">• </span><span style="font-family:sans-serif">5.5.1.4.2 Reservations are not considered as valid assignments or sub-allocations.</span><div dir="auto"><font face="sans-serif">• </font><span style="font-family:sans-serif">5.5.1.7 Documentation</span></div><span style="font-family:sans-serif">• 5.5.1.8 Network infrastructure (of LIR) vs End-User networks</span><div dir="auto"><font face="sans-serif">• </font><span style="font-family:sans-serif">5.5.1.9 Utilisation</span></div><span style="font-family:sans-serif">• 5.5.1.10 Reservations not supported</span><div dir="auto"><font face="sans-serif">• </font><span style="font-family:sans-serif">5.5.1.11 Validity of an assignment</span><font face="sans-serif"><br></font><div dir="auto"><span style="font-family:sans-serif">• </span><span style="font-family:sans-serif">5.5.1.13 Sub-Allocation Window (SAW)</span><br style="font-family:sans-serif">• <span style="font-family:sans-serif">5.5.1.13.1 A sub-allocation window (SAW) refers to the maximum number of IPv4 addresses that the LIR may sub-allocate to the end-users without seeking approval from AFRINIC.</span><span style="font-family:sans-serif"><br>• </span><span style="font-family:sans-serif">5.5.1.13.2 AFRINIC will review sub-allocation made by the LIR's using their SAW to ensure that policies are followed correctly.</span><div dir="auto"><font face="sans-serif">• </font><span style="font-family:sans-serif">5.5.1.13.3 Below are a few guidelines for the SAW:</span><div dir="auto"><span style="font-family:sans-serif">• 5.5.1.14 Recordkeeping by LIRs</span><span style="font-family:sans-serif"><br></span></div><div dir="auto">¿°?</div><div dir="auto"><br></div><div dir="auto">Please let me know if it was a bad initiative :-/</div><div dir="auto"><br></div><div dir="auto">Thanks.</div><div dir="auto"></tl;dr></div><div dir="auto"><br></div><div dir="auto">Source: <<a href="https://afrinic.net/policy/manual#lir-isp-allocation" target="_blank">https://afrinic.net/policy/<wbr>manual#lir-isp-allocation</a>></div><div dir="auto"><br></div>~°~<div dir="auto">...<br>5.5 IPv4 LIR/ISP Allocations<div dir="auto"><br>5.5.1 Allocation policies and guidelines<br><br>5.5.1.1 Introduction<br><br>5.5.1.1.1 AFRINIC allocates ranges of IPv4 addresses to Local Internet Registries (LIRs).<br><br>LIRs reassign or sub-allocated that space to their customers. All LIR's assigning address space allocated from AFRINIC are also advised to adopt a set of policies that are consistent with the policies described in this document.<br><br>5.5.1.1.2 Determination of IP address space allocation size is the responsibility of AFRINIC staff.<br><br>In an effort to ensure that Classless Inter-Domain Routing (CIDR) is implemented and utilized as efficiently as possible, AFRINIC will issue blocks of IPv4 addresses on appropriate "CIDR-supported" bit boundaries. (CIDR - "Classless Inter-Domain Routing", is explained in RFC1517-1959, <a href="https://www.ietf.org/standards/rfcs/" target="_blank">https://www.<wbr>ietf.org/standards/rfcs/</a>).<br><br>5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered.<br><br>The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied.<br><br>5.5.1.2 First IPv4 Allocation<br><br>5.5.1.2.1 AFRINIC's minimum allocation is /22 or 1024 IPv4 addresses.<br><br>5.5.1.2.2 The organisation must be an AFRINIC member in good standing, and;<br><br>5.5.1.2.3 Must show an existing efficient utilization of IP addresses from their upstream provider.<br><br>Justification may be based on a combination of immediate need and existing usage, in which case, the existing assignments must be renumbered into the LIR's new allocation. The verification of previous efficient utilisation is based on assignments (and sub-allocations) registered in the RIPE, ARIN, LACNIC and APNIC databases and only these registered assignments will be considered valid.<br><br>5.5.1.3 Slow start mechanism for first allocations<br><br>AFRINIC shall apply a slow start mechanism to all new LIRs. With respect to allocations made by AFRINIC, the first allocation an LIR receives will be the size of the minimum practical allocation unless otherwise justified.<br><br>The slow start policy is used by all RIR's to prevent allocations of large blocks of address space that may then remain substantially unassigned. AFRINIC will implement the slow start mechanism in a consistent and fair manner for every LIR and will apply the same principles and standards to every applicant for address space.<br><br>5.5.1.4 Additional Allocation<br><br>5.5.1.4.1 An LIR may receive an additional allocation when about 80% of all the address space currently allocated to it has been used in valid assignments and/or sub-allocations.<br><br>A new allocation can also be made if a single assignment or sub-allocation requires more addresses than those currently held by the LIR.<br><br>5.5.1.4.2 Reservations are not considered as valid assignments or sub-allocations.<br><br>It may be useful for internal aggregation to keep some IP blocks free for future growth. These internal reservations are however not counted as valid usage and must be assigned or sub-allocated before requesting for additional allocation.<br><br>5.5.1.4.3 AFRINIC will always try to allocate contiguous address ranges, allowing the LIR to minimise the number of route announcements it makes.<br><br>However, it will not always be possible to allocate a range of contiguous with the LIR's previous allocation.<br><br>5.5.1.5 Sub-Allocations<br><br>The minimum size of a sub-allocation is /24. It allows a reasonable number of small assignments to be made by a downstream ISP. An LIR may not sub-allocate IPv4 space above its sub-allocation window (see 5.5.1.13 for sub-allocation windows).<br><br>LIR's may make sub-allocations to multiple downstream ISP's. (Downstream ISP's efficiently using a sub-allocation qualify to receive a /22 allocation should they want to become an LIR).<br><br>The LIR is responsible for ensuring that address space allocated to it, and subsequently, the address space that it sub-allocates is used in accordance with the community's policies and guidelines.<br><br>LIRs are advised to make use of the slow-start mechanism when making sub-allocations to downstream ISPs. Here, the LIR ensures that space sub-allocated is efficiently used and the LIR can also monitor and determine the ability of the downstream ISP to operate within the policies set by the community.<br><br>Sub-allocations form part of an LIR's aggregatable space. Therefore, an LIR should ensure that IP space is not retained by the downstream ISP if the reseller ceases to obtain connectivity from the LIR's network (sub-allocations are non-portable).<br><br>5.5.1.6 PA Assignment policies and guidelines<br><br>LIR's must request approval from AFRINIC for all sub-allocations above their Sub-Allocation Window.<br><br>The following guidelines are intended to help LIRs and end-users in their search for equitable compromises:<br><br>5.5.1.7 Documentation<br><br>The information required by AFRINIC to justify an end-user's IP address requirements includes addressing needs, network infrastructure and future plans. Such information is required when an LIR is requesting IP space for their end-users at the time of sending in the request. In order to ensure that previous sub-allocations are not duplicated, the current address space usage is also required. This information is essential in making the appropriate sub-allocation approvals, and the level of detail will depend on the size of the request and complexity of the network. The LIR should ensure that the necessary information is completed before making a sub-allocation request to AFRINIC.<br><br>When making sub-allocation from their SAW, LIR's should also ensure that such information is given by the end-user.<br><br>5.5.1.8 Network infrastructure (of LIR) vs End-User networks<br><br>IP addresses used solely for connecting an end-user to a service provider (e.g., point-to-point links) are considered as part of the service provider's infrastructure. Such addresses should only be registered as part of the service provider's infrastructure. When an end-user has a network using public address space, this space must be registered with the contacts of the end-user. If the end-user is an individual rather than an organisation, space may be registered with the contact information of the service provider but with the end-user referenced in the AFRINIC whois database object.<br><br>5.5.1.9 Utilisation<br><br>Immediate utilisation of assignments should be at least 25% of the assigned space. After one year, unless special circumstances are defined, it should be at least 50%.<br><br>5.5.1.10 Reservations not supported<br><br>End-users are not permitted to reserve address space based on long term plans. This violates the goal of conservation and fragments the address space when initial forecasts are not met. If an LIR wants to assign address space for customers, it must make the assignments from any unallocated or unassigned address space it currently holds. For the purposes evaluating allocation requests, space reserved by an LIR for other customers is considered unused.<br><br>5.5.1.11 Validity of an assignment<br><br>Assignments remain valid as long as the original criteria on which the assignment was based are still in place and the assignment is registered in the AFRINIC database. An assignment is therefore invalid if it is not registered in the database and if the purpose for which it was registered has changed or no longer holds.<br><br>5.5.1.12 Re-numbering<br><br>This is replacing IP addresses on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met. The addresses to be replaced must still be in use. When a renumbering request exceeds the LIR's sub-allocation window, the request should be sent to AFRINIC for approval.<br><br>A period of three months is normally considered sufficient to migrate a network to the new IP space. Once a network has been renumbered, AFRINIC staff will remove the old assignment from the AFRINIC database. In case the three monthsÕ period is not sufficient, the LIR should inform AFRINIC about the additional time they might take to completely renumber.<br><br>5.5.1.13 Sub-Allocation Window (SAW)<br><br>5.5.1.13.1 A sub-allocation window (SAW) refers to the maximum number of IPv4 addresses that the LIR may sub-allocate to the end-users without seeking approval from AFRINIC. The SAW size is expressed in CIDR notation.<br><br>5.5.1.13.2 AFRINIC will review sub-allocation made by the LIR's using their SAW to ensure that policies are followed correctly. LIR's should also ensure that documentation for sub-allocation made using the SAW be similar to that requested for larger requests.<br><br>5.5.1.13.3 Below are a few guidelines for the SAW:<br><br>All new LIRs have a SAW of zero. All sub-allocations will need prior approval by AFRINIC.<br>The LIR cannot make any sub-allocation to the end-user above their SAW in a 12 monthsÕ period (1 year). At the end of a calendar year from the approval of a SAW, the SAW is refreshed for one more year. In case the LIR's SAW is exhausted for a particular end-user, approval must be sought from AFRINIC for any other sub-allocation to the same end-user.<br>LIR's are welcome to approach AFRINIC for a review of their SAW. They may also seek a second opinion from AFRINIC even for a sub-allocation that could be made with their SAW if they chose. Before a SAW is raised, the following will be considered:<br>All required documentation is normally presented.<br>Previous sub-allocation assignments from this sub-allocation are all registered in the database correctly.<br>Current SAW has not been misused/abused.<br>New LIR's are advised to train their contacts to handle address space assignments according to the policies and procedures in this document. If due to inexperienced contacts at the LIR, errors due to poor judgement consistently happen, the SAW may be lowered or removed to allow AFRINIC staff to assist in training the LIR's staff in the AFRINIC community's policies.<br><br></div><div dir="auto">5.5.1.14 Recordkeeping by LIRs<br><br>LIR's must keep and maintain records of any documentation regarding assignments and sub-allocations to end-users. It is needed for future reference when evaluating requests from the same organisation and for any audits by AFRINIC. These documents should be kept electronically for easier access. It's advisable that these records should include but not be limited to:<br><br>The original request.<br>Supporting documentation.<br>Related correspondence between LIR and end-user.<br>The decision of the assignment, and the reasons behind any unusual decision.<br>Role of the person that made the decision.<br><br><div dir="auto">5.6 IPv4 End-User (PI) Assignments<br> ...</div><div dir="auto">~°~<br><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Shalom,</div><div dir="auto">--sb. </div><div dir="auto"><br></div><div dir="auto"><br></div></div></div></div></div></div></div></div>
<br><br>-- <br>--<p>Best Regards !<br>__<br>baya.sylvain[AT cmNOG DOT cm]|<<a href="https://cmnog.cm/dokuwiki/Structure">https://cmnog.cm/dokuwiki/Structure</a>><br>Subscribe to Mailing List: <<a href="https://lists.cmnog.cm/mailman/listinfo/cmnog/">https://lists.cmnog.cm/mailman/listinfo/cmnog/</a>><br>__<br>#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!»<br>‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬<br>«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)<br><br></p>