[arin-ppml] ARIN-2011-3: Better IPv6 Allocations for ISPs last call

Mon May 2 14:26:39 EDT 2011

Team,
While IPv6 is not IPv4 we should never the less take into consideration
everything we have learned
and develop Best Practices from Lessons Learned.
I support this Policy.

John Kuhn
Break Through Technologies
ESC MGS
Government of Ontario

	  ARIN-2011-3: Better IPv6 Allocations for ISPs

	Changes include:
	1. Does not delete section 2.9 (request from staff, no impact on
policy
	meaning)
	2. Limits LIR recursion to a single level and limit subordinate
LIRs to
	/32. (community concern)
	3. Restores PAU to the calculation in 6.5.2.1(c) (from errata
slide
	presented in meeting)
	4. Preserves 2010-12 language in new 6.5.3.1 (from errata slide
	presented in meeting)
	5. Preserves verbiage allowing ISPs to allocate to their own
internal
	infrastructure in 6.5.4.1 (from errata slide presented in
meeting)
	6. Adds a statement to delete current NRPM 6.9 (from errata
slide
	presented in meeting)
	7. Adds language to limit initial allocations to no more than a
/16
	(6.5.2.1(b)) and to limit subsequent allocations to no larger
than a /12
	(an organization may apply for additional /12s, but, no single
	allocation larger than a /12 can be made at one time)
(6.5.2.1(e))
	(community concern)

	Feedback is encouraged during the last call period. All comments
should
	be provided to the Public Policy Mailing List. Last call for
2011-3 will
	expire on 2 May 2011. After last call the AC will conduct their
last
	call review.

	The draft policy text is below and available at:
	https://www.arin.net/policy/proposals/

	The ARIN Policy Development Process is available at:
	https://www.arin.net/policy/pdp.html

	Regards,

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

	## * ##

	Draft Policy ARIN-2011-3
	Better IPv6 Allocations for ISPs

	Version/Date: 18 April 2011

	Policy Statement:

	Amend section 2 as follows:

	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 When applied to IPv6 policies, 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 When applied to IPv6 policies, 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 when
applied
	to IPv6
	policies:

	(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 from the
	containing block 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 (in slash notation, /n, where n is evenly
divisible
	by 4, allowing unit quantities of 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. In no case shall
	an ISP receive more than a /16 initial allocation.

	(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 = P-(X+Y) and P is the organization's
	Provider Allocation Unit 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.
	LIRs which do not receive resources directly from ARIN will
	not be able to make such allocations to subordinate LIRs and
	subordinate LIRs which need more than a /32 shall apply
	directly to ARIN.

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

	In either case, they will be making reassignments
	from allocation(s) under this policy to other organizations.

	(c) Provide ARIN a reasonable technical justification
	indicating why an allocation is necessary. Justification
	must include the intended purposes for the allocation and
	describe the network infrastructure the allocation will be used
to
	support. Justification must also include a plan detailing
anticipated
	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.

	(d) If an LIR has already reached a /12 or more, ARIN will
	allocate a single additional /12 rather than continue
	expanding nibble boundaries.

	Renumber/move the second paragraph of existing section 6.5.2.1
to 6.5.3.1.

	For reference, this would become:
	6.5.3.1 Subsequent Allocations for Transition
	Subsequent allocations will also be considered for deployments
	that cannot be accommodated by, nor were accounted for, under
	the initial allocation. Justification for the subsequent subnet
size
	will be based on the plan and technology provided with a /24
	being the maximum allowed for a transition technology.
	Justification for transitional allocations will be reviewed
every 3
	years and reclaimed if they are no longer in use for
transitional
	purposes. All such allocations for transitional technology will
be
	made from a block designated for this purpose.

	(This paragraph comes from 2010-12 which was adopted after this
draft
	policy was written).

	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.

	6.5.4.1 An LIR may assign up to a /48 per PoP as well as up to
an
	additional /48 globally for its own infrastructure.

	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.

	Delete section 6.9

	_______________________________________________
	PPML
	You are receiving this message because you are subscribed to
	the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
	Unsubscribe or manage your mailing list subscription at:
	http://lists.arin.net/mailman/listinfo/arin-ppml
	Please contact info at arin.net if you experience any issues.

************************************************************************
***************
	The information contained in this message, including
attachments, may contain
	privileged or confidential information that is intended to be
delivered only to the
	person identified above. If you are not the intended recipient,
or the person
	responsible for delivering this message to the intended
recipient, Windstream requests
	that you immediately notify the sender and asks that you do not
read the message or its
	attachments, and that you delete them without copying or sending
them to anyone else.

	------------------------------

	_______________________________________________
	ARIN-PPML mailing list
	ARIN-PPML at arin.net
	http://lists.arin.net/mailman/listinfo/arin-ppml

	End of ARIN-PPML Digest, Vol 71, Issue 8
	****************************************

-- 

<http://api.ning.com/files/60Dc*7fMSnOD5inYWvnElhieb2y*e2O798iHVa48vgYOJ
Umz33g1MSmWAGQs0M2C7g4LXqAu0KvJ0c99k3kSouZfig33AnNo/emaillogo.jpg> 

Rudi Daniel 
danielcharles consulting
<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadine
s/DanielCharles/153611257984774> 
1-784 498 8277
<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadine
s/DanielCharles/153611257984774> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110502/19096373/attachment.htm>