[ppml] Proposed Policy: Recommended v6 aggregation practices

[Member Services]

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal and may decide to:
      1. Accept the proposal as a formal policy proposal as it is presented;
      2. Work with the author to:
          a) clarify the language or intent of the proposal;
          b) divide the proposal into two (2) or more proposals; or
          c) combine the proposal with other proposals; or,
      3. Not accept the proposal as a formal policy proposal.

The AC review will be conducted at their next regularly scheduled meeting.

If the AC accepts the proposal or reaches an agreement with the author,
then the proposal will be posted as a formal policy proposal to PPML and
it will be presented at a Public Policy Meeting. If the AC does not
accept the proposal or can not reach an agreement with the author, then
the AC will notify the community of their decision with an explanation;
at that time the author may elect to use the petition process to advance
their proposal. If the author elects not to petition or the petition
fails, then the proposal will be considered closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Recommended v6 aggregation practices

Author: Owen DeLong

Proposal Version: 1.0

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