[arin-ppml] Policy Proposal 109: Standardize IP Reassignment Registration Requirements
Member Services
info at arin.net
Thu Feb 4 11:33:18 EST 2010
ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.
This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.
The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.
In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/
Regards,
Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Policy Proposal 109: Standardize IP Reassignment Registration Requirements
Proposal Originator: Chris Grundemann
Proposal Version: 1.0
Date: 4 FEB 2010
Proposal type: Modify
Policy term: Permanent
Policy statement:
## Definitions ##
- Add:
2.3. Organizational Information
When required, organization Information must include at a minimum:
Legal name, city, state, zip code equivalent and at least one valid
technical or abuse POC; inclusion of street address is highly
encouraged. The POC shall be designated by the organization and must
include at least one verifiable email address, inclusion of a phone
number is highly encouraged.
## IPv4 ##
- Rename 4.2.3.7. "Reassignment information" to "Registration"
- Rename 4.2.3.7.1. "Customer organization information" to
"Reassignment Information" and replace text with:
When an organization holding an IPv4 address allocation makes IPv4
address assignments, it must register reassignment information via
SWIP or RWHOIS server. SWIP and RWHOIS reassignments shall include
each client's organizational information, except where specifically
exempted by this policy.
- Replace 4.2.3.7.6. Residential Customer Privacy with:
4.2.3.7.6. Residential Subscribers
4.2.3.7.6.1. Residential Market Area
In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather
than to individual subscribers. This assignment information regarding
each market area holding an address block should be registered 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. Each assignment to specific end-users
of /29 and larger blocks still requires individual registration.
4.2.3.7.6.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 record for that block.
- Strike section 4.2.6. "Cable Address Space Policy"
## IPv6 ##
- Replace Section 6.5.5. with:
6.5.5. Registration
6.5.5.1. Reassignment information
When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register reassignment information in a
database, accessible by RIRs as appropriate (information registered by
an RIR may be replaced by a distributed database for registering
address management information in future). These reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.
6.5.5.2. /56 registered unit
Information is registered in units of assigned /56 networks. When more
than a /56 is assigned to a client organization, the assigning
organization is responsible for ensuring that the address space is
registered in an RIR database.
6.5.5.3. Submit within 7 days
Any time an LIR receives a new block of address space, reassignment
information should be submitted within 7 days of issuance of the new
space.
6.5.5.4. Visible via WHOIS
This information must be visible via WHOIS prior to submitting a
request for a new allocation. For further information on reassigning
IP address space, please see RFC 2050.
6.5.5.6. Residential Subscribers
6.5.5.6.1. Residential Market Area
In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather
than to individual subscribers. This assignment information regarding
each market area holding an address block should be registered 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. Each assignment to specific end-users
of /56 and larger blocks still requires individual registration.
6.5.5.6.2. Residential Customer Privacy
To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /56 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.
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. This includes
designating an upstream POC as their own prefered POC.
4) Expands the priviledges previously reserved solely for cable ISPs
to all ISPs/LIRs with residential subscribers. Namely the ability to
SWIP/RWHOIS an entire residential market area as one reassignment. It
also expands this priviledge to IPv6 reasignments, instead of just
IPv4 as it is now.
Timetable for implementation: Immediate
More information about the ARIN-PPML
mailing list