Editorial Change (formerly Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup) [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: Implemented
Tracking Information
Discussion Tracking
Mailing List:
Formal introduction on PPML on 21 November 2017
Origin - ARIN-prop-246
Draft Policy - 21 November 2017
Communtiy Review-20 Feburary - 23 March 2018
Advanced to Board of Trustees -23 April 2018
Adopted - 24 May 2018
Implemented - 24 July 2018
ARIN Public Policy Meeting:
ARIN Advisory Council:
AC Shepherds:
Alyssa Moore, Owen DeLong
ARIN Board of Trustees:
Revisions:
Implementation:
24 July 2018
Version Date: 20 February 2018
Proposed Editorial Change to NRPM
(Formerly Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup)
2.5. Allocate and Assign
A distinction is made between address allocation and address assignment, i.e., ISPs are “allocated” address space as described herein, while end-users are “assigned” address space.
Allocate - To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them.
Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties.
Proposed Editorial Change:
2.5 Allocation, Assignment, Reallocation, Reassignment
…
Allocation - Address space delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties.
Assignment - Address space delegated to an organization directly by ARIN for the exclusive use of the recipient organization.
Reallocation - Address space sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties.
Reassignment - Address space sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization.
Make the following editorial changes to section 3.2:
Current text:
3.2. Distributed Information Server Use Requirements[edit]
The minimal requirements for an organization to setup a distributed information service to advertise reassignment information are:
The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards.
The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts.
The distributed information service must return reassignment information for the IP address queried. The service may allow for privacy protections for customers.
For residential users, the service may follow ARIN’s residential privacy policy that includes displaying only the city, state, zip code, and country. For all other reassignments, the service shall follow ARIN’s privacy policy for publishing data in a public forum.
The distributed information service may return results for non-IP queries.
The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff.
The distributed information service may include optional attributes per object that are defined locally.
The distributed information service must return results that are up-to-date on reassignment information.
Proposed Editorial Change:
3.2. Distributed Information Server Use Requirements
The minimal requirements for an organization to setup a distributed information service to advertise reassignment and reallocation information are:
The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards.
The distributed information service must allow public access to reassignment and reallocation information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts.
The distributed information service must return reassignment and reallocation information for the IP address queried. The service may allow for privacy protections for customers. For residential users, the service may follow ARIN’s residential privacy policy that includes displaying only the city, state, zip code, and country. For all other reassignments and reallocations, the service shall follow ARIN’s privacy policy for publishing data in a public forum.
The distributed information service may return results for non-IP queries.
The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff.
The distributed information service may include optional attributes per object that are defined locally. The distributed information service must return results that are up-to-date on reassignment and reallocation information.
Make the following editorial changes to section 4.2:
Current text:
4.2.1.1. Purpose
ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers.
Proposed Editorial Change:
4.2.1.1. Purpose
ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers.
Current text:
4.2.3. Reassigning Address Space to Customers
Proposed Editorial Change:
4.2.3. Reassigning and Reallocating Address Space to Customers
Current Text:
4.2.3.1. Efficient utilization
ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted.
Proposed Editorial Change:
4.2.3.1. Efficient utilization
ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted.
Current text:
4.2.3.4. Downstream customer adherence
ISPs must require their downstream customers to adhere to the following criteria:
4.2.3.4.1. Utilization
Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space.
Proposed Editorial Changes:
4.2.3.4. Downstream customer adherence
ISPs must require their downstream customers to adhere to the following criteria:
4.2.3.4.1. Utilization
Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space.
Current text:
4.2.3.5. ARIN approval of reassignments/reallocations
4.2.3.5.1. /18
All extra-large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN.
4.2.3.5.2. /19
Small to large ISPs making customer reassignments of a /19 or larger must first seek ARIN’s approval.
Proposed Editorial Changes:
4.2.3.5. ARIN approval of reassignments/reallocations
4.2.3.5.1. /18
All extra-large ISPs making reassignments or reallocations of a /18 or larger to a customer must first have these reassignments or reallocations reviewed and approved by ARIN.
4.2.3.5.2. /19
Small to large ISPs making customer reassignments or reallocations of a /19 or larger must first seek ARIN’s approval.
Current text:
4.2.3.7.1. Reassignment Information
Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Proposed Editorial Changes:
4.2.3.7.1. Reassignment and Reallocation Information
Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Current text:
4.2.3.7.2.Assignments visible within 7 days
All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment.
Proposed Editorial Changes:
4.2.3.7.2.Reassignments and Reallocations visible within 7 days
All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation.
Current text:
4.2.4. ISP Additional Requests
4.2.4.1. Utilization percentage (80%)
ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers.
Proposed Editorial Changes:
4.2.4. ISP Additional Requests
4.2.4.1. Utilization percentage (80%)
ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers.
Make the following editorial changes to section 6 to clarify language regarding current practices and requirements for reallocations and reassignments, and specifically to clarify that recording reallocation information is required where current language is ambiguous:
Current text:
6.5.2.1(e) Initial Allocations to LIRs, Size
For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN.
Proposed Editorial Changes:
6.5.2.1(e) Initial Allocations to LIRs, Size
For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN.
Current text:
6.5.2.2. Qualifications
An organization qualifies for an allocation under this policy if they meet any of the following criteria:
a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
In either case, they will be making reassignments from allocation(s) under this policy to other organizations.
Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
Proposed Editorial Changes:
6.5.2.2. Qualifications
An organization qualifies for an allocation under this policy if they meet any of the following criteria:
a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations.
Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
Current text:
6.5.4. Assignments from LIRs/ISPs
Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply.
Proposed Editorial Changes:
6.5.4. Reassignments from LIRs/ISPs
Reassignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply.
Current text:
6.5.4.1. Assignment to operator’s infrastructure
An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.
Proposed Editorial Changes:
6.5.4.1. Reassignment to operator’s infrastructure
An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.
Current text:
6.5.5. Registration
ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use.
Proposed Editorial Changes:
6.5.5. Registration
ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use.
Current text:
6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Proposed Editorial Changes:
6.5.5.1. Reassignment information
Each static IPv6 reassignment or reallocation containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Current text:
6.5.5.2. Assignments visible within 7 days
All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment
Proposed Editorial Changes:
6.5.5.2. Reassignments and Reallocations visible within 7 days
All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation.
Current text:
- Resource Review
(…)
- c) whenever ARIN has reason to believe that an organization is not complying with reassignment policies, or
Proposed Editorial Changes:
- Resource Review
(…)
- c) whenever ARIN has reason to believe that an organization is not complying with reassignment or reallocation policies, or
##########
Earlier Version
##########
Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup
Version Date: 15 November 2017
Problem Statement:
The current text of NRPM uses the terms ‘reallocate’ and ‘reassign’ in ways that are both internally inconsistent within NRPM and inconsistent with the definitions of Reassignments and Reallocations as fields within the ARIN database. Frequently the term ‘reassignment’ or ‘reassign’ is used in NRPM as an umbrella term for both reallocations and reassignments. As a result, someone familiar with the ARIN Whois database, but unfamiliar with history of particular portions of NRPM and their intended meaning may interpret certain NRPM requirements as applying only to reassignments and not to reallocations. This is particularly problematic when it comes to SWIP requirements and the requirement to record reallocations and reassignments with ARIN, which under current text could be read to only apply to reassignments.
Policy Statement:
Make the following changes to the definitions in Section 2.5
Current text:
2.5. Allocate and Assign
A distinction is made between address allocation and address assignment, i.e., ISPs are “allocated” address space as described herein, while end-users are “assigned” address space.
Allocate - To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them.
Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties.
Proposed Editorial Change:
2.5 Allocation, Assignment, Reallocation, Reassignment
Allocation - Address space delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties.
Assignment - Address space delegated to an organization directly by ARIN for the exclusive use of the recipient organization.
Reallocation - Address space sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties.
Reassignment - Address space sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization.
Make the following editorial changes to section 4.2:
Current text:
4.2.1.1. Purpose
ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers.
Proposed Editorial Change:
4.2.1.1. Purpose
ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers.
Current text:
4.2.3. Reassigning Address Space to Customers
Proposed Editorial Change:
4.2.3. Reassigning and Reallocating Address Space to Customers
Current Text:
4.2.3.1. Efficient utilization
ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted.
Proposed Editorial Change:
4.2.3.1. Efficient utilization
ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted.
Current text:
4.2.3.4. Downstream customer adherence
ISPs must require their downstream customers to adhere to the following criteria:
4.2.3.4.1. Utilization
Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space.
Proposed Editorial Changes:
4.2.3.4. Downstream customer adherence
ISPs must require their downstream customers to adhere to the following criteria:
4.2.3.4.1. Utilization
Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space.
Current text:
4.2.3.5. ARIN approval of reassignments/reallocations
4.2.3.5.1. /18
All extra-large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN.
4.2.3.5.2. /19
Small to large ISPs making customer reassignments of a /19 or larger must first seek ARIN’s approval.
Proposed Editorial Changes:
4.2.3.5. ARIN approval of reassignments/reallocations
4.2.3.5.1. /18
All extra-large ISPs making reassignments or reallocations of a /18 or larger to a customer must first have these reassignments or reallocations reviewed and approved by ARIN.
4.2.3.5.2. /19
Small to large ISPs making customer reassignments or reallocations of a /19 or larger must first seek ARIN’s approval.
Current text:
4.2.3.7.1. Reassignment Information
Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Proposed Editorial Changes:
4.2.3.7.1. Reassignment and Reallocation Information
Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Current text:
4.2.3.7.2.Assignments visible within 7 days
All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment.
Proposed Editorial Changes:
4.2.3.7.2.Reassignments and Reallocations visible within 7 days
All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation.
Current text:
4.2.4. ISP Additional Requests
4.2.4.1. Utilization percentage (80%)
ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers.
Proposed Editorial Changes:
4.2.4. ISP Additional Requests
4.2.4.1. Utilization percentage (80%)
ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers.
Make the following editorial changes to section 6 to clarify language regarding current practices and requirements for reallocations and reassignments, and specifically to clarify that recording reallocation information is required where current language is ambiguous:
Current text:
6.5.2.1(e) Initial Allocations to LIRs, Size
For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN.
Proposed Editorial Changes:
6.5.2.1(e) Initial Allocations to LIRs, Size
For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN.
Current text:
6.5.2.2. Qualifications
An organization qualifies for an allocation under this policy if they meet any of the following criteria:
a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
In either case, they will be making reassignments from allocation(s) under this policy to other organizations.
Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
Proposed Editorial Changes:
6.5.2.2. Qualifications
An organization qualifies for an allocation under this policy if they meet any of the following criteria:
a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations.
Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
Current text:
6.5.4. Assignments from LIRs/ISPs
Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply.
Proposed Editorial Changes:
6.5.4. Reassignments from LIRs/ISPs
Reassignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply.
Current text:
6.5.4.1. Assignment to operator’s infrastructure
An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.
Proposed Editorial Changes:
6.5.4.1. Reassignment to operator’s infrastructure
An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.
Current text:
6.5.5. Registration
ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use.
Proposed Editorial Changes:
6.5.5. Registration
ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use.
Current text:
6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Proposed Editorial Changes:
6.5.5.1. Reassignment information
Each static IPv6 reassignment or reallocation containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy.
Current text:
6.5.5.2. Assignments visible within 7 days
All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment
Proposed Editorial Changes:
6.5.5.2. Reassignments and Reallocations visible within 7 days
All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation.
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.