[ppml] Proposed Policy: PI assignments for V6

[marcelo bagnulo braun]

Hi all,

i think it is not a good idea to accept this policy _now_

i think that probably a PI assignment policy will be needed in the 
future, but i wouldn't promote it now.

here is why:

for several years now the community have been working on a multihoming 
solution that is compatible with PA assignments. this has been 
considered important in order to preserve the health of the global 
routing system as you al already know.
This is a difficult problem and it is really taking quite some time to 
figure out how to solve it and to reach consensus. However, some 
progress is being made and i guess that we are not so far from agreeing 
on which way to go. During last IETF in washington the multi6 wg agreed 
to follow a path towards a solution. Yes, there is still some way to 
develop and deploy a solution, but we are moving.
In any case, as you may well notice, any multihoming solution 
compatible with PA addressing will require that:
- multiple PA prefixes configured in the multihomed sites (instead of 
one)
- it won't provide PI addressing (so a multihomed site will still have 
to renumber if it changes providers)
This two reasons make it a priori an inferior solution to obtaining PI 
addressing on the eyes of the multihomed site, even though it is a much 
superior solution in the eyes of the community since it preserves 
global routing system scalability.
In any case, if a PI assignment policy is adopted, the PA compatible 
multihoming solution won't get any chance to get deployed i guess, 
since i guess that multihomed sites will have the following choices:
- A PA compatible solution which: doesn't provides provider 
independence, requires multiple prefixes and it is new i.e. no 
experience, no products, no previous knowledge
- a PI multihoming solution: everything works as you already know
What do you think multihomed sites will choose?

My proposal is to wait until a PA compatible solution for multihoming 
is developed and some experience is gained with it. Then we can see if 
it is useful and especially who is useful for. Probably it won't be 
good enough for some sites, and probably then we will need a PI 
asignment policy to satisfy the need of those sites.
But we shouldn't do it now, that the multihoming solution is not yet 
here, and we would be killing it before it comes.

Regards, marcelo

El 02/12/2004, a las 22:34, Member Services escribió:

> ARIN received the following proposed policy.  In accordance with the 
> ARIN
> Internet Resource Policy Evaluation Process, the proposal is being 
> posted
> to the ARIN Public Policy Mailing List and being placed on ARIN's 
> website.
>
> The ARIN Advisory Council will review the proposal and within ten 
> working
> days may decide to:
> 1)  support the proposal as is,
> 2)  work with the author to clarify, divide or combine one or more 
> policy
> proposals, or
> 3)  not support the policy proposal.
>
> If the AC supports the proposal or reaches an agreement to work with 
> the
> author, then the proposal will be posted as a formal policy proposal to
> the Public Policy Mailing List and it will be presented at the Public
> Policy Meeting.  If the AC does not support the proposal, then the 
> author
> may elect to use the petition process to advance the proposal. If the
> author elects not to petition or the petition fails, then the proposed
> policy will be considered closed.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/ipep.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: PI assignments for V6
>
> Author: Owen DeLong
>
> Policy term: permanent
>
> Policy statement:
>
> Any end-site or other organization which meets the current tests for
> assignment of an autonomous system number (ASN) shall also qualify for 
> one
> IPv6 prefix assignment or allocation of the minimum size justified by 
> them
> under the ARIN guidelines for LIR assignment to such an organization.  
> If
> the organization wishes to receive an allocation, they must meet the 
> tests
> for being an LIR, except that this smaller allocation will not require 
> a
> plan for assigning to an additional 200 organizations.  To qualify as 
> an
> LIR under this policy, the organization must have the intent of 
> assigning
> to additional organizations, and, should be able to show ARIN 
> reasonable
> evidence of such intent.
>
> If the organization grows to require more space, they will not be 
> entitled
> to an additional block, but, may obtain a new replacement block of
> sufficient size to meet their needs in exchange for agreement that 
> their
> existing block will be reclaimed and may be reissued to a different
> organization in 24 months.
>
> Rationale:
>
> There is a legitimate and growing need for provider independent 
> addressing
> for end-site organizations and small ISPs.  While there were and are
> technical reasons for limiting this in the v4 world, they need to be
> solved in the v6 world, or, we will not see widespread adoption of v6.
>
> This policy does not promote extreme growth in the routing table, as it
> would provide support for fewer than 70,000 v6 prefixes if every
> organization that currently has an ASN were to get an assignment, grow,
> and, be in the 24 month renumbering period.  Realistically, it is
> unreasonable to think that this policy would contribute even 10,000 
> routes
> to the v6 table in the near term future.
>
> This policy provides for reasonable v6 provider independent assignments
> and allocations without creating a land-grab, explosive routing table
> growth, or a v6 swamp.
>
> All such assignments under this policy shall be subject to the same
> renewal criteria as v4 end-user assignments with a fee structure to be 
> set
> by ARIN in the usual and customary way.
>
> Timetable for implementation:
>
> Upon adoption by the ARIN board of trustees.
>