[arin-ppml] Simplified IPv6 policy

[Owen DeLong]

> 
> 
> 
> Replacement text:
> 
> 1.1.  Number resources not to be considered property
> 
> It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.
> 
> The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license, as definied in the ARIN Registration Services Agreement.
> 
> Note that when a license is renewed, the new license will be evaluated under and governed by the applicable number resource policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.
> 
I do not like the use of the term license, and, I think Steve Ryan would likely take issue with it as well.

Personally, I think that the first paragraph is sufficient.  The remaining two paragraphs simply restate
(badly) what is in the RSA and do not need to be part of the NRPM.
> 
> 
> 6.2.  Policies for IPv6 allocations and assignments
> 
> 6.2.1.  Allocations and assignments
> To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria.  Allocations are made to LIRs, and assignments to certain end users.
> 
> 6.2.2.  Assignments from LIRs/ISPs
> End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified.
> 
> The following guidelines may be useful (but they are only guidelines):
> 
>    * /64 when it is known that one and only one subnet is needed
>    * /56 for small sites, those expected to need only a few subnets over the next 5 years.
>    * /48 for larger sites
> 
> For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation.
> 
> ARIN is not concerned about which address size an LIR/ISP actually assigns. Accordingly, ARIN will not request the detailed information on IPv6 user networks as in IPv4, except for the purpose of measuring utilization as defined in this document.
> 
This paragraph should be deleted.  ARIN is concerned if you want to issue more than a /48 to an end site and should
be able to review such large assignments.

> 6.2.3. Allocations and assignments from ARIN
> 
> 6.2.3.1  Goals
> To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally makes allocations only in the discrete sizes of /48, /40, /32, /28, or /24 or larger.  Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's <a href="https://www.arin.net/fees/fee_schedule.html">fee schedule</a>
> for each size assigned.
> 
The first "makes allocations" should either be "issues IPv6 addresses" or "makes allocations or assignments".
The last "assigned" should either be "issued" or "assigned or allocated".

> 6.2.3.2  X-Small (/48)
> To qualify for a /48 allocation or assignment, an organization must:
>    * Serve at least 500 hosts, if multihomed; or
>    * Serve at least 1000 hosts; or
>    * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or
>    * Be a critical infrastructure provider of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA; or
>    * Qualify for a Micro-allocations for Internal Infrastructure per 6.3.3.2.2.
> 
I would rather see this in the ~100 host range, if multihomed.  I'm fine with 1000 hosts otherwise.

There should not be any IPv4 requirement for getting IPv6 space.  The efficient utilization of IPv4 resources as a determining
factor for getting IPv6 resources should be removed in my opinion.

> 6.2.3.2.1 Critical Infrastructure
> Organizations qualified as critical infrastructure providers may be granted multiple /48 allocations in certain situations.  Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude exchange point operators from requesting address space under other policies.
> 
Why create a separate pool for exchange point allocations?

> 6.2.3.2.2 Micro-allocations for Internal Infrastructure
> Organizations that currently hold IPv6 allocations may apply for a /48 micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose.
> 
> 6.2.3.3  Small (/40)
> To qualify for a /40 allocation or assignment, an organization must qualify for two or more /48s.
> 
This is in direct conflict with the statement at the beginning that an organization can only qualify for one block
of each size. This problem persists in your subsequent requirements to qualify for larger blocks as well.


> 6.2.3.4  Medium (/32)
> To qualify for a /32 allocation or assignment, an organization must:
>    * Qualify for 100 or more /48s; or
>    * Be an existing, known LIR; or 
>    * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years.
> 
> 6.2.3.5  Large (/28)
> To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 20,000 /48s.
> 
> 6.2.3.6  X-Large (/24 or larger)
> Allocations or assignments of /24 or larger may be made only in exceptional cases, to organizations that require more than a /28, and have submitted documentation that reasonably justifies the request. If approved, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure.
> 
> 6.3. Registration
> 
> When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database.
> 
This is a major departure from current whois policy and I do not think that an overhaul of whois
should be packaged with a major change to IPv6 policy.  Please restore the current SWIP/rhwois
requirements for publishing the data.

I'm fine with registering IPv6 data in terms of /56s, but, what about cases where customers are
issued /64s? There are 256 /64 customers in a single /56.

> IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.
> 
I don't think this needs to be in the NRPM.  I think that it is already addressed in other areas.

> 6.3.1. Residential Customer Privacy (2003-3)
> 
> To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block.
> 
> 6.3.2. Reverse lookup
> 
> When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.
> 
I think this needs word-smithing, but, I'm at a loss to come up with something better at the moment.

> Thoughts?

See above.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091223/59006a20/attachment.htm>