Draft Policy ARIN-2010-14: Standardize IP Reassignment Registration Requirements [Archived]

Status: NRPM Sections 2.12, 2.13, 4.2.3.7, 6.5.5 and 12.2.

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 10 August 2010

Origin - Policy Proposal 109

Draft Policy - 10 August 2010

Staff assessment - 21 September 2010

Returned to the AC’s docket - 13 October 2010

Last call - 21 December 2010 through 12 January 2011

AC recommended adoption - 3 Feb 2011

Adopted by the Board - 15 Feb 2011

Implemented - 27 Sep 2011

Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XXVI

ARIN Advisory Council:

Shepherds: Marla Azinger
and Cathy Aronson

• 15 July 2010
• 19 Aug 2010
• 16 Sep 2010
• 8 Oct 2010
• 18 Nov 2010
• 16 Dec 2010
• 28 Jan 2011
• 17 Feb 2011

ARIN Board of Trustees:

15 February 2011

Revisions:

Previous version(s)

Implementation:

27 September 2011

Draft Policy ARIN-2010-14
Standardize IP Reassignment Registration Requirements

Version/Date: 11 October 2010

Proposal type: New

Policy term: Permanent

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

In most cases, ISPs that have residential subscribers assign address
space to their access infrastructure to which their customers connect
rather than to individual subscribers. This assignment information
regarding each market area holding an address block should be entered
via SWIP (or by using RWhois) with the network name used to identify
each market area. Initial allocations are based on total number of homes
that could purchase the service in a given market area.

Using SWIP or RWhois, residential access ISPs must show that they have
reassigned at least 80% of their current address space, with a 50 to 80%
utilization rate, in order to request additional addresses.

Each assignment to a specific end-user (if holding /29 and larger
blocks) requires the submission of a SWIP or use of an RWhois server.
Requesters will also be asked to provide detailed plans for use of the
newly requested space.

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 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.

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 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:

#Short Rationale:
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 Rationale:

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.

Timetable for implementation: Immediate