Draft Policy 2010-14: Standardize IP Reassignment Registration Requirements

[ARIN]

Draft Policy 2010-14
Standardize IP Reassignment Registration Requirements

Attached is the ARIN staff assessment of 2010-14.

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.

2010-14 is below and available at:
https://www.arin.net/policy/proposals/2010_14.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Staff Assessment of Draft Policy 2010-14 (version dated 10 August 2010)
Standardize IP Reassignment Registration Requirements

1. Proposal Summary (Staff Understanding)

This policy:

• Tightens the requirements for SWIP or RWHOIS registration information
• Replaces the existing Cable Address Policy with a broader policy
applicable to all residential dynamic addressing pools
• Extends its application to IPv6
• Better defines what a residential customer is
• Changes reassignment policy so that /64s and larger networks must be
registered via SWIP or RWhois
• Adds a criterion for staff to initiate a NRPM 12 resource review audit.


2. Comments

A. ARIN Staff Comments

• This proposal would replace the 3 existing qualifying criteria of the
Cable Policy (NRPM section 4) with the single criterion of must
show >50% utilization.
  o It is staff’s observation that the existing cable policy works well
for cable providers as is and staff cannot discern what problem this
section of the proposal is attempting to solve.
  o The current cable policy requires 80% of the ISP’s address space to
be provisioned to hardware and to be reassigned, with a 50 – 80%
utilization rate. This new proposal removes the 80% requirement, which
would allow a provider to provision and reassign only 50% of their most
recent allocation. The result seems to be lowered efficiency of overall
address space usage.
  o The text in this section is somewhat unclear and confusing as written.
• Because this proposal would apply to all residential dynamic
addressing pools (in addition to cable), it would likely be beneficial
for many of ARIN’s customers who share very similar technologies to the
cable industry, but have never been able to apply under the cable policy
(technologies like dsl, fiber to the home, etc.).
• This proposal provides a well-defined explanation of what a
residential customer is and will be beneficial to both the community and
to the staff.  The existing definition of  “residential customer” has
caused some confusion for customers.


B. ARIN General Counsel

Currently, counsel is reviewing US and Canadian law regarding the
policy’s suggested changes to the balance in current ARIN policy on
customer ‘privacy’ and business proprietary information related to
residential customers.  At this point there is no significant legal
issue.  We will update this as soon as possible.


3. Resource Impact
This policy would have moderate to major resource impact.  It is
estimated that implementation would occur within 6 months to 9 months
after ratification by the ARIN Board of Trustees. The following would be
needed in order to implement:

• Potential Database impact if all /64s and larger assignments must now
be swipped (there are ~4 billion /64s in a /32 so the scale of this goes
beyond anything ARIN has seen).
• Changes to current business processes
• Updated templates
• Updated guidelines
• Staff training

Full draft policy text below:

>
>
>
> Draft Policy 2010-14
> Standardize IP Reassignment Registration Requirements
>
> Version/Date: 10 August 2010
>
> Policy statement:
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add 
> text:
>
> 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.
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> 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.
>
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
>
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.3. Residential Subscribers
>
> 4.2.3.7.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 4.2.3.7.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks 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 directory record for that
> block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 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.
>
> 6.5.5.1. Reassignment information
>
> Each 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.
>
> 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.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 6.5.5.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks 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.
>
> ## Resource Review ##
>
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
>
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
>
> -- 
>
> Rationale:
>
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information – Phone number, street address and abuse
> POC now required.
> 2) Residential Customer – Added “for personal use only” to the 
> definition.
> 3) Registration (4.2.3.7 & 6.5.5) – Added “but not limited to” WRT
> assignment histories.
> 4) IPv6 – Requires all /64 and larger blocks to be registered.
> 5) Resource Review – Added this section.
>
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
>
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
>
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
>
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
>
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
>
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it’s customers.
>
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
>
>
>
>
>
>