[ppml] Policy Proposal -- Recommended v6 aggregation practices

Owen DeLong owen at delong.com
Fri Apr 28 15:39:49 EDT 2006


Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0

Policy Proposal Name: Recommended v6 aggregation practices
Author
name: Owen DeLong
email: owen at delong.com
telephone: 408-921-6984
organization: DeLong Consulting
Proposal Version: 1.0
Submission Date: 28 April, 2006
Proposal type: new
Policy term: permanent
Policy statement:

Add section 6.3.9 to NRPM as follows:

6.3.9 Recommended Practices to Maximize Aggregation
	6.3.9.1
		Whenever feasible, an organization should make best possible
		use of provider assigned space.

	6.3.9.2
		Except in the most extraordinary of circumstances, no ASN should
		originate more than a single v6 aggregate prefix. Sparse allocation
		practices should prevent the need for growth-induced additional
		prefixes in most cases. Non-ISP organizations expanding beyond their
		reservation should renumber into the larger block if at all possible.

	6.3.9.3	
		In the case of merger or acquisition resulting in a combination
		of multiple autonomous systems into a single topology and/or
		routing policy, the organization should strive to either combine
		the networks into one of the existing prefixes, or, obtain a
		new larger prefix and renumber.  A grace period of up to 3 years
		should be allowed for this purpose.

Rationale:

	A number of the concerns raised over proposal 2005-1 seem to center
	around the possibility of routing table growth due to further deaggregation
	and other forms of v4-like table bloat resulting from PI space.

	This proposal is an attempt to reduce and/or mitigate those issues
	to some extent.  I have no illusion that this is a panacea, and, I
	remain convinced that the only truly viable solution is to develop
	a routing process for IDR which does not use the End System Identifier
	as the Routing Locator.

	I also remain uncomfortable with the idea of ARIN getting involved
	in routing policy.  I think this is the purview of the ISPs exchanging
	the routes in question.  However, I think these recommendations are
	a reasonable compromise towards a pragmatic attempt to address the
	existing situation until something better can be achieved.

Timetable for implementation: Immediately upon BoT Approval
Meeting presenter: Owen DeLong

END OF TEMPLATE

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060428/33e13ef5/attachment.sig>


More information about the ARIN-PPML mailing list