From info at arin.net  Sat Nov  6 09:46:29 2010
From: info at arin.net (ARIN)
Date: Sat, 06 Nov 2010 09:46:29 -0400
Subject: [arin-announce] [Fwd: Policy Proposal 120: Protecting Number
	Resources]
Message-ID: <4CD55C35.9070803@arin.net>

The following is a new policy proposal that has been posted to the ARIN
Public Policy Mailing List for discussion on that list.

Reminder: RSS feeds of all posts to the Public Policy Mailing List
(PPML) and just postings by ARIN to PPML are available at:
https://www.arin.net/participate/mailing_lists/rss.html

Regards,

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

-------- Original Message --------
Subject: 	Policy Proposal 120: Protecting Number Resources
Date: 	Sat, 06 Nov 2010 09:43:15 -0400
From: 	ARIN <info at arin.net>
To: 	arin-ppml at arin.net



ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (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.

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,

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


## * ##


Policy Proposal 120: Protecting Number Resources

Proposal Originator: Leo Bicknell

Proposal Version: 1.0

Date: 5 November 2010

Proposal type: new

Policy term: permanent

Policy statement:

ARIN shall use any reasonable and practical methods to proactively
look for fraudulently obtained or abandoned number resources and
seek the return of those resources to ARIN.

A report of activities under this policy shall be delivered at each
ARIN meeting.

Rationale:

ARIN has generally only reactively looked for fraudulently obtained
or abandoned number resources, generally via reports to
https://www.arin.net/resources/fraud/.

While it is great for ARIN to take these community reports, ARIN
can be in a far better position to know which resources were
fraudulently obtained or abandoned due to the additional paperwork
that ARIN holds which is not available to the public, and the record
of interactions (or lack thereof) with the resource holder.

] From: John Curran <jcurran at arin.net>
] To: Leo Bicknell <bicknell at ufp.org>
] CC: "arin-ppml at arin.net" <arin-ppml at arin.net>
] Subject: Re: [arin-ppml] Audits
]
] On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
] >  What would the community have to get the ARIN staff to go proactively
] >  looking for fraud, abuse, defunct companies and other non-compliant
] >  uses of the address space?
]
] As usual: have the community develop an appropriate policy and ensure that
] there is an adequate level of support for the increased ARIN costs (which
] will appear back as overall service fees) once we get to implementation.
]
] /John

I expect the board/executive management will interpret reasonable
and practical to be some amount of staff time that is not zero, but
will also not "break the bank".

I also expect that ARIN will report on the number resources (in the
aggregate) that were returned due to this proactive activity, as
well as the cost to the members of this activity (again, in the
aggregate) so as to obtain feedback if more, or less resources
should be used in this area.

Timetable for implementation: immediate








From info at arin.net  Mon Nov 15 12:26:02 2010
From: info at arin.net (ARIN)
Date: Mon, 15 Nov 2010 12:26:02 -0500
Subject: [arin-announce] Call for Community Consultation - ARIN Services and
 Database Access for Invalid Points of Contact (POCs)
Message-ID: <4CE16D2A.7040601@arin.net>

ARIN is seeking community input regarding the availability of ARIN 
services to invalid Points of Contact (POCs) identified by ARIN's POC 
Validation Process. Please refer to Number Resource Policy Manual 
section 3.6 Annual Whois POC Validation for background, 
https://www.arin.net/policy/nrpm.html#three6.

Based on feedback expressed at the recent ARIN Public Policy and Member 
Meeting in Atlanta as well as the Public Policy Mailing List (PPML), 
ARIN is considering implementing changes to the services available to 
Invalid POCs. These changes are intended to further improve the accuracy 
of POC data in ARIN's Whois by requiring users to validate their invalid 
POCs prior to requesting services and database changes.

The proposed changes limit services to users linked to Invalid POCs in 
the following manner:

? ARIN Online users would only have access to POC validation and 
modification features until they validate any non-validated POCs to 
which they are linked. Once validated, an ARIN Online user would have 
access to all available ARIN Online functionality.

? Any service requests made through ARIN?s RESTful Provisioning Service, 
https://www.arin.net/resources/restful-interfaces.html, would be 
returned with a message directing users to validate their associated POC 
information through ARIN Online.

? Template submissions for POC, organization, network modifications, v4 
simple reassignments, v4 detailed reassignments, v4 reallocations, v6 
detailed reassignments and v6 reallocation requests would be returned 
with a message directing users to validate their associated POC 
information through ARIN Online.

? Templates requesting resources directly from ARIN (v4 ISP request, v4 
End-User request, v6 ISP request, v6 End-User request, ASN, 
experimental), or requesting resource transfers or ASN modifications 
would be accepted and ticketed, however, they will not be processed if 
the POC is invalid. ARIN staff would notify submitters via email to 
validate their associated POC information through ARIN Online.

? Other services and/or functionality may be added in this change of 
service at ARIN's discretion.

This change in service will be implemented in early-to-mid 2011 if 
supported by the community.

Comments regarding this proposed service change for Invalid POCs can be 
submitted through the ARIN Consultation and Suggestion Process, 
available at: https://www.arin.net/participate/acsp/index.html.

Please submit your feedback to the arin-consult at arin.net. You can 
subscribe to this mailing list at:
http://lists.arin.net/mailman/listinfo/arin-consult.

Discussion on arin-consult at arin.net will close on 15 December 2010, at 
Noon EST.

ARIN welcomes community-wide participation. Please address any process 
questions to info at arin.net.

Regards,

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




From info at arin.net  Tue Nov 16 11:58:52 2010
From: info at arin.net (ARIN)
Date: Tue, 16 Nov 2010 11:58:52 -0500
Subject: [arin-announce] =?windows-1252?q?New_ARIN_Education_Multimedia_?=
 =?windows-1252?q?=96_Deploying_IPv6?=
Message-ID: <4CE2B84C.20805@arin.net>

ARIN is proud to announce a new Flash-based primer titled: Deploying 
IPv6. This presentation describes the impending depletion of the IPv4 
resource and the need to adopt IPv6. Because IPv4 and IPv6 will coexist 
for the foreseeable future, companies will need to maintain business 
continuity for all IPv4 and IPv6 customers after IPv4 depletion. This 
narrated presentation highlights the critical factors that service and 
content providers, software developer, equipment vendors and governments 
need to consider as they transition to IPv6. We encourage you to use the 
downloadable version in conjunction with the IPv4 Depletion and IPv6 
Adoption Community Use Slide Deck found on the General Education page 
(https://www.arin.net/knowledge/general.html) to help explain why it is 
time for your organization to adopt IPv6.

https://www.arin.net/knowledge/deploying_ipv6/

ARIN strives to provide these types of resources that advance our 
mission to facilitate the advancement of the Internet through 
information and educational outreach.

We hope you enjoy it, and if you have suggestions for other educational 
materials, please send them to info at arin.net.

Regards,

Communications and Member Services
American Registry for Internet Numbers






From info at arin.net  Wed Nov 17 11:35:09 2010
From: info at arin.net (ARIN)
Date: Wed, 17 Nov 2010 11:35:09 -0500
Subject: [arin-announce] [Fwd: RE: [arin-ppml] Sensible IPv6 Allocation
 Policies - Rev 0.8 (PP 121)]
Message-ID: <4CE4043D.1030009@arin.net>

The following is a new policy proposal that has been posted to the ARIN
Public Policy Mailing List for discussion on that list.

Reminder: RSS feeds of all posts to the Public Policy Mailing List
(PPML) and just postings by ARIN to PPML are available at:
https://www.arin.net/participate/mailing_lists/rss.html

Regards,

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

-------- Original Message --------
Subject: 	RE: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
(PP 121)
Date: 	Wed, 17 Nov 2010 11:20:32 -0500
From: 	ARIN <info at arin.net>
To: 	arin-ppml at arin.net
References: 	<4CD55B73.9030104 at arin.net>



Policy Proposal 121: Sensible IPv6 Allocation for ISPs

ARIN acknowledges receipt of the policy proposal that can be found below.

The ARIN Advisory Council (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.

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,

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


## * ##


> -----Original Message-----

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On

> Behalf Of Owen DeLong

> Sent: Tuesday, November 16, 2010 9:10 AM

> To: policy; ppml at arin.net PPML

> Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8

>

>  Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

>    1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs

>    2. Proposal Originators

>          1. name: Owen DeLong

>          2. e-mail: owen at delong.com

>          3. telephone: 408-890-7992

>          4. organization: Hurricane Electric

>          1. name: David Farmer

>          2. e-mail: farmer at umn.edu

>          3. telephone: 612-812-9952

>          4. organization: University of Minnesota

>          1. name: Andrew Dul

>          2. e-mail: andrew.dul at quark.net

>          3. telephone: 206-395-4004

>          4. organization: Cascadeo Corp.

>          1. name: Chris Grundemann

>          2. e-mail: christopher.grundemann at twtelecom.com

>          3. telephone: 303.542.6524

>          4. organization: TW Telecom

> 3. Proposal Version: 0.8

> 4. Date: 16 November, 2010 5. Proposal type: M 6. Policy term:

> Permanent 7. Policy statement:

> Amend section 2 as follows:

> Delete section 2.9 (Obsolete)

> Replace section 2.10 with the following:

>     2.10 The term End Site shall mean a single structure or service

> delivery address, or, in the case of a multi-tenant structure, a single

> tenant within said structure (a single customer location).

> Add the following:

>     2.12 The term serving site shall mean a location where an ISP

> terminates or aggregates customer connections, including, but, not

> limited to Points of Presence (POPs), Datacenters, Central or Local

> switching office or regional or local combinations thereof.

>     2.13 The term provider assignment unit shall mean the prefix of

> the smallest block a given ISP assigns to end sites (recommended /48).

>     2.14 The term utilized shall have the following definitions:

>           (i) A provider assignment unit shall be considered fully

> utilized when it is assigned to an end-site.

>           (ii) Larger blocks shall have their utilization defined by

> dividing the number of provider assignment units assigned by the total

> number of provider assignment units. This ratio will often be expressed

> as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75%

> utilization)

>

>

> Replace sections 6.5.1 through 6.5.3 with the following:

> 6.5.1 Terminology

>     (a) The terms ISP and LIR are used interchangeably in this

> document and any use of either term shall be construed to include both

> meanings.

>     (b) The term nibble boundary shall mean a network mask which

> aligns on a 4-bit boundary (a number X such that 2^n=X where n is

> evenly divisible by 4, such as 16, 256, 4096, etc.)

> 6.5.2     Initial Allocations to LIRs

>     6.5.2.1     Size

>     (a)   All allocations shall be made on nibble boundaries.

>     (b)   In no case shall an LIR receive smaller than a /32 unless

> they specifically request a /36.

>     (c)   The maximum allowable allocation shall be the smallest

> nibble-boundary aligned block that can provide an equally sized nibble-

> boundary aligned block to each of the requesters serving sites large

> enough to satisfy the needs of the requesters largest single serving

> site using no more than 75% of the available addresses.

>

>           This calculation can be summarized as /N where N = 48-(X+Y)

> and X is a multiple of 4 greater than 4/3*serving sites and Y is a

> multiple of 4 greater than 4/3*end sites served by largest serving

> site.

>

>

>     (d)   For purposes of the calculation in (c), an end site which

> can justify more than a /48 under the end-user assignment criteria in

> 6.5.8 shall count as the appropriate number of /48s that would be

> assigned under that policy.

>     (e)   For purposes of the calculation in (c), an LIR which has

> subordinate LIRs shall make such allocations according to the same

> policies and criteria as ARIN. In such a case, the prefixes necessary

> for such an allocation should be treated as fully utilized in

> determining the block sizing for the parent LIR.

>     (f)   An LIR is not required to design or deploy their network

> according to this structure. It is strictly a mechanism to determine

> the largest IP address block to which the LIR is entitled.

>     6.5.2.2     Qualifications

>     An organization qualifies for an allocation under this policy if

> they meet any of the following criteria:

>     (a)   Have a previously justified IPv4 ISP allocation from ARIN

> or one of its predecessor registries or can qualify for an IPv4 ISP

> allocation under current criteria.

>     (b)   Are currently multihomed for IPv6 or will immediately

> become multihomed for IPv6 using a valid assigned global AS number.

>     (c)   Provide ARIN a reasonable technical justification,

> indicating why an allocation is necessary, including the intended

> purposes for the allocation, and describing the network infrastructure

> the allocation will be used to support. Justification must include a

> plan detailing assignments to other organizations or customers for one,

> two and five year periods, with a minimum of 50 assignments within 5

> years.

> 6.5.3     Subsequent Allocations to LIRs

>     (a)   Where possible ARIN will make subsequent allocations by

> expanding the existing allocation.

>     (b)   An LIR which can show utilization of 75% or more of their

> total address space, or more than 90% of any serving site shall be

> entitled to a subsequent allocation.

>     (c)   If ARIN can not expand one or more existing allocations,

> ARIN shall make a new allocation based on the initial allocation

> criteria above. The LIR is encouraged, but not required to renumber

> into the new allocation over time and return any allocations no longer

> in use.

> Replace section 6.5.4 with the following

> 6.5.4     Assignments to end users shall be governed by the same

> practices adopted by the community in section 6.5.8 except that the

> requirements in 6.5.8.1 do not apply.

> Add the following to 6.5.7

> LIRs which received an allocation under previous policies which is

> smaller than what they are entitled to under this policy may receive a

> new initial allocation under this policy provided that they agree to

> renumber into that new allocation and return their prior allocation(s)

> within 5 years. If possible, ARIN will simply expand their existing

> allocation rather than requiring renumber and return.

>    8. Rationale:

> The current ISP policy for IPv6 allocations is both short-sighted and

> insufficient for rational deployments by most ISPs. We have gained

> significant operational experience with IPv6 in the time since it was

> written and it is clear that current policy is driving many ISPs to

> choices of excess conservatism that will eventually harm innovation in

> the consumer space.

> Under the proposed policy, the entirety of the ARIN region can still be

> numbered in no more than 2 /12s (quite probably 1). There are still 506

> /12s free within the current /3. It is unreasonable to shoot ourselves

> in the foot with address scarcity thinking so early into the IPv6

> deployment. This policy seeks to strike a more reasonable and

> harmonious balance of the goals stated in NRPM 6.3.

> The lower bound of /36 is intended to facilitate extremely small ISPs

> getting a smaller block if they do not need to support more than ~4000

> customers. It is hoped that the board will take subsequent action to

> adjust the fee structure to eliminate the $1,000/year price hike for

> those extremely small ISPs. These ISPs can, of course, get a /32 if

> they wish.

> The intent of section 6.5.4 is to create and preserve parity between

> the requirements for LIR->End User and ARIN->End User policies. This

> section presumes that 6.5.8 has already been modified as described in

> draft policy 2010-8.

> Some examples of determining the size of block for which an

> organization is eligible:

> Bill's Bait, Sushi, and IP Transit:

>     Largest serving site:         200 end sites

>     Number of serving sites:      5

>     200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 *

> 0.75), so, round up to 4096 (12 bits)

>     5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75),

> so, no further round up. 16 (4 bits)

>     48 - (12+4) = 32 -- This organization could receive up to a /32.

> Lee's Rural Internet, Inc.

>     Largest serving site:         1024 end sites

>     Number of serving sites:      30

>     1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072

> (4096 * 0.75), so 4096 (12 bits)

>     30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 *

> 0.75), so, 256 (8 bits)

>     48 - (12+8) = 28 -- This organization could receive up to a /28.

> Paul's Mega Metro ISP, LLC

>     Largest serving site:         3,500 end sites

>     Number of serving sites:      140

>     3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072

> (4096 * 0.75), so, round up to 65,536 (16 bits)

>     140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 *

> 0.75), so, 256 (8 bits)

>     48 - (16+8) = 24 -- This organization could receive up to a /24

> PON's CMTS mega DSL Corp.

>     Largest serving site:         30,000 end sites

>     Number of serving sites:      700

>     30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 <

> 49,152 (65536 * 0.75), so, 65,536 (16 bits)

>     700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072

> (4096 * 0.75), so, 4,096 (12 bits)

>     48 - (16+12) = 20 -- This organization could receive up to a /20.

> Sizing table:

> Units           Round-up    Bits

> 0-11            16          4

> 13-191          256         8

> 192-3,071 4,096       12

> 3,072-49,151    65,536            16

> 49,152-786,431  1,048,576   20

>    9. Timetable for implementation: Immediate

>

> END OF TEMPLATE

>

>

>

>








From info at arin.net  Thu Nov 18 18:10:13 2010
From: info at arin.net (ARIN)
Date: Thu, 18 Nov 2010 18:10:13 -0500
Subject: [arin-announce] [Fwd: Policy Proposal 122: Reserved Pool for Future
	Policy Development]
Message-ID: <4CE5B255.3040102@arin.net>

The following is a new policy proposal that has been posted to the ARIN
Public Policy Mailing List for discussion on that list.

Reminder: RSS feeds of all posts to the Public Policy Mailing List
(PPML) and just postings by ARIN to PPML are available at:
https://www.arin.net/participate/mailing_lists/rss.html

Regards,

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

-------- Original Message --------
Subject: 	Policy Proposal 122: Reserved Pool for Future Policy Development
Date: 	Thu, 18 Nov 2010 18:09:06 -0500
From: 	ARIN <info at arin.net>
To: 	arin-ppml at arin.net



ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (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.

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,

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


## * ##


Policy Proposal 122: Reserved Pool for Future Policy Development

Proposal Originator: Martin Hannigan

Proposal Version: 1.0

Date: 18 Nov 2010

Proposal type: Delete, Temporary

Policy term: October 20, 2011 00:00 UTC

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will place a contiguous /10 in a reserved pool for a use to be
determined at a later date. If adopted, this proposal will delete
Section 4.10 permanently and then expire per the policy term.

Rationale:

During the attempted fix of Section 4.10 we had consensus that 4.10 was
insufficient and potentially damaging and unbalanced with respect to
transition efforts.  This will provide for time to review  our current
depletion strategy and improve upon it to the benefit of the entire
community.

Timetable for implementation: Immediate







From info at arin.net  Fri Nov 19 10:48:12 2010
From: info at arin.net (ARIN)
Date: Fri, 19 Nov 2010 10:48:12 -0500
Subject: [arin-announce] [Fwd: Policy Proposal 123: Reserved Pool for
	Critical Infrastructure]
Message-ID: <4CE69C3C.5000607@arin.net>

The following is a new policy proposal that has been posted to the ARIN
Public Policy Mailing List for discussion on that list.

Reminder: RSS feeds of all posts to the Public Policy Mailing List
(PPML) and just postings by ARIN to PPML are available at:
https://www.arin.net/participate/mailing_lists/rss.html

Regards,

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

-------- Original Message --------
Subject: 	Policy Proposal 123: Reserved Pool for Critical Infrastructure
Date: 	Fri, 19 Nov 2010 10:47:48 -0500
From: 	ARIN <info at arin.net>
To: 	arin-ppml at arin.net



ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (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.

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,

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


## * ##


Policy Proposal 123: Reserved Pool for Critical Infrastructure

Proposal Originator: Martin Hannigan

Proposal Version: 1.0

Date: 19 Nov 2010

Proposal type: Temporary

Policy term: October 20, 2011 00:00 UTC

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will place a contiguous /20 in reserve for Critical Infrastructure.

Rationale:

During the attempted fix of Section 4.10 we had consensus that 4.10 was
insufficient and potentially damaging and unbalanced with respect to
transition efforts. In order to enable the community to work to fix this
problem in a responsible manner, we need to insure that we do not break
the Internet or cause unnecessary hardship or cost to underserved
markets. This policy will protect those resources with a reasonable
amount of reserved v4 address space.

This proposal should be considered an emergency proposal. IANA
exhaustion is likely to occur prior to the next ARIN meeting.

Timetable for implementation: Immediate







From info at arin.net  Tue Nov 23 12:25:40 2010
From: info at arin.net (ARIN)
Date: Tue, 23 Nov 2010 12:25:40 -0500
Subject: [arin-announce] Get Ready for New Templates
Message-ID: <4CEBF914.7050404@arin.net>

In early 2011, ARIN will be releasing updated templates (Version 5) when 
we change systems in order to support per-delegation management of 
nameservers and provision secure delegations through Domain Name System 
Security Extensions (DNSSEC). This new delegation management system will 
be available through ARIN Online only, so we will be releasing a new set 
of templates that will also include an API key field for added security 
and authentication. The nameserver fields and the optional resource 
contact section are also being removed from the Version 5 templates. The 
new templates are available for preview at:

https://www.arin.net/features/template_changes.html

For those who continue to use the version 4 templates, the new system 
will ignore nameserver changes submitted via template and will ignore 
any resource POCs added on Detailed Reassignment or Reallocation 
templates. Please note that version 3 templates will not be supported 
after the new templates are released, so if you are still using version 
3, please plan accordingly.

Because the current system is not yet ready to accept the new templates, 
please continue using the current template set until further notice. 
After the version 5 templates are released, all new requests should be 
submitted using these revised templates. The new system is backward 
compatible, so ARIN will continue to accept the version 4 templates to 
allow customers using scripts sufficient time to update their software. 
If you continue using version 4 templates after version 5 is released, 
you must include an API key in the subject line or associate your e-mail 
address with an API key.

For details on this and other uses for API keys, please refer to:

https://www.arin.net/features/api_keys.html

ARIN encourages all customers to transition to using ARIN Online to 
modify your resources as these features are released because they will 
allow your modifications to be reflected immediately in our database. We 
will continue to provide and support templates for those who are unable 
to use ARIN?s Web interface.

We encourage you to learn more about all of the projects in development; 
details are available at:

https://www.arin.net/features/

If you have further questions about these template changes or other 
upcoming features, please email hostmaster at arin.net.

Regards,

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





From info at arin.net  Mon Nov 29 12:04:27 2010
From: info at arin.net (ARIN)
Date: Mon, 29 Nov 2010 12:04:27 -0500
Subject: [arin-announce] Board Action: LRSA Extension and Bylaws Changes
Message-ID: <4CF3DD1B.6010905@arin.net>

The ARIN Board of Trustees has extended the availability of the Legacy 
Registration Services Agreement (LRSA) in order to allow additional 
organizations to participate. Legacy number resource holders now have 
until 31 December 2011 to enter into a Legacy RSA with ARIN. Any 
organization or individual in the ARIN service region holding legacy 
Internet number resources not covered by any other registration services 
agreement with ARIN is invited to sign.

In addition, the ARIN Board of Trustees adopted two bylaws changes at 
its meeting on 22 November 2010. These changes are:
     >Added a clear definition of the Compensation Committee
     >Clarified how it may be determined that the President is 
incapacitated, and the succession process when this incapacitation arises

View these changes in the Bylaws change log at 
https://www.arin.net/about_us/corp_docs/bylaws_changelog.html.

Regards,

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


From info at arin.net  Mon Nov 29 15:53:30 2010
From: info at arin.net (ARIN)
Date: Mon, 29 Nov 2010 15:53:30 -0500
Subject: [arin-announce] Changes at GetIPv6.info
Message-ID: <4CF412CA.6080502@arin.net>

ARIN made available a public wiki site focused exclusively on IPv6 in 
May 2007 at http://getipv6.info. In the time since that release, there 
have been hundreds of contributions made by many active participants in 
our community. To help facilitate this on-going effort to expand and 
share knowledge on IPv6, ARIN recently shifted the content on the 
website into more intuitive groups and to outline some new areas where 
we believe additional information would be helpful to the large and 
diverse community we serve.

While much of the content has been simply regrouped and remains 
unchanged, we hope these new categories and the reorganized home page 
assist the community in sharing knowledge and getting the right answers 
to those most in need.

All interested individuals in the community are invited to use the site, 
at http://www.getipv6.info, to post information they believe may be 
helpful to others looking at implementations or migrations of networks 
to IPv6. This can include recommended practices, success stories, case 
studies, and general information on using IPv6 in the ARIN region.

Those unfamiliar with wiki-based websites should review the MediaWiki 
User's Guide at http://meta.wikimedia.org/wiki/MediaWiki_User's_Guide
before getting started. ARIN staff involvement is generally limited to 
assisting or organizing navigation and highlighting specific content 
articles or categories. Individuals with questions or suggestions about 
this site may send them to webmaster at arin.net.

As the Internet comes closer to the eventual end of the global IPv4 
address pool, the need for the type of information on this site will 
grow as the immediate need for IPv6 deployment is more broadly 
recognized. Whether you're someone with IPv6 expertise to share or just 
someone looking for answers, we hope these recent changes help you 
accomplish your goal.

Regards,

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







From info at arin.net  Tue Nov 30 16:23:49 2010
From: info at arin.net (ARIN)
Date: Tue, 30 Nov 2010 16:23:49 -0500
Subject: [arin-announce] =?windows-1252?q?Four_/8_Blocks_Allocated_to_the_?=
 =?windows-1252?q?RIRs_=96_2=2E73=25_Remains_at_IANA?=
Message-ID: <4CF56B65.50100@arin.net>

Today, 30 November 2010, the IANA allocated four /8s to the RIRs ? 23/8 
and 100/8 to ARIN and 5/8 and 37/8 to RIPE NCC. This leaves only seven 
/8s remaining in IANA free pool of IPv4 addresses, or 2.73% of the total.

When the IANA IPv4 free pool has only five /8 blocks remaining, they 
will be simultaneously distributed to the five RIRs in accordance with 
global policy. This means that only two blocks remain to be handed out 
under the normal distribution method.

With so little IPv4 address space left in the global free pool, ARIN 
continues to emphasize the need for all Internet stakeholders to adopt 
the next generation of Internet Protocol, IPv6.

Visit https://www.arin.net/knowledge/v4-v6.html for more information on 
IPv6 adoption, or contact us at info at arin.net with any questions.

Regards,


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