ARIN-2010-14 Previous Version [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.

View the current policy proposal text.

The following version was archived on 21 December 2010.

Draft Policy ARIN-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.

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.