[ppml] Proposed Policy: PI assignments for V6

[Owen DeLong]

--On Saturday, December 4, 2004 5:45 AM -0600 Stephen Sprunk 
<stephen at sprunk.org> wrote:

>> Policy Proposal Name: PI assignments for V6
>>
>> Author: Owen DeLong
>>
>> Policy term: permanent
>
> Should this policy automatically expire once a certain number of prefixes
> are assigned, after a certain period of time, when 32-bit ASNs are
> deployed,
> etc. or can we reasonably expect operators to force repealing the policy
> if
> a "land rush" develops?
>
I think that in the unlikely event of a v6 "land rush" (remember, under this
policy, it would require an ASN rush as well), we can expect the BOD to
act properly under their emergency authority and also that we can expect
the community to take action appropriate to the circumstances and technology
of the time.

I don't think we need to automatically expire this policy on either of
the proposed basis.

>> 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.
>
> I had to read this several times to understand you weren't expecting end
> sites to become LIRs; please consider separating end sites and small ISPs
> into different paragraphs.
>
Will do.

>> 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
>
> I don't like the wording here, but I can't seem to come up with something
> better...
>
>> in exchange for agreement that their existing block will be reclaimed and
>> may be reissued to a different organization in 24 months.
>
> 24 months seems excessive for end-site renumbering since they won't have
> to
> coordinate with sub-assignees.  Perhaps different limits for allocations
> and
> assignments?
>
While I agree that 24 months is a bit excessive, I don't think there's
any real penalty to the community from this, and, I didn't want to
be presumptuous about how complicated renumbering could be.  I think
that 24 months is a reasonable timeframe for an ISP with less than 200
customers.  I think there's no harm letting end-sites have the same
amount of time.  As such, I figured keeping it simple and having one
time limit made more sense.

> Other comments:
>
> Should prefixes be required to be taken from block(s) designated for this
> use, since that will help ISPs adjust their filters?  This seems common
> with
> other recent proposals.
>
I'm not opposed to this, but, at the same time, I'm not sure it's
necessary or beneficial.

> Should multiple organizations using the same ASN be considered a single
> end-site and thus required to share a prefix?
>
For purposes of this proposal, I think so.  The requirements for getting
an ASN are fairly simple.  If you aren't multihomed or are multihomed
only at the IGP level, then, you should be able to work out a shared
prefix just as easily.

Essentially, I think for purposes of this policy, multiple organizations
sharing an AS looks a lot like a small ISP (the actual AS owner) providing
LIR services to a small number of customers (the other orgs).

> Should having PI space disqualify an end-site from PA assignments, or vice
> versa?  What about PI space allocated under other policies?
>
I think ARIN should leave the PA decision to the LIR.  Having PA space 
should
not disqualify an org from obtaining PI space under this policy, but, LIRs
may require the PA space to be returned after some reasonable renumbering
period.  I think each LIR should set their own policy in this regard.

Direct PI allocation/assignment under other RIR policy should, indeed,
be a disqualifying factor.  I will attempt to codify this in the next
revision of the policy.

> Should we include any way for disconnected sites (which many not have an
> ASN) to get PI space?  The IPv4 policy directs such sites to use RFC 1918
> space, but there is no equivalent (yet) in IPv6.
>
If they are truly disconnected, I'm not sure why IETF or RIRs should be
getting involved in their choice of addressing policy.  If they are
"partially disconnected", then, they are somewhat connected, and, I think
PA space is the preferred alternative if their needs for PI can't meet
the simple tests of this policy.

>> 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.
>
> In another forum it was claimed that ARIN charged ISPs $100/yr for IPv6 PI
> allocations; looking at the fee schedule, it appears that starting 1 Jan
> 05,
> the fees will be $2,500 plus $2,250/yr for a /32.  Anyone requesting a
> second allocation pays $20k plus $18k/yr.  That's quite a difference from
> $100/yr.
>
Yes.

> ARIN's "usual and customary way" has already set the fees for end-user
> direct assignments to be the same as for ISP allocations, per section
> 12(D)
> of the 3 Aug 04 BoT meeting.
>
Except that ARIN's current fee structure does not address any assignment
smaller than /32.  That would need to be addressed, and, I would hope that
we could get something similar to current IPv4 pricing under 2002-3,
including the $100 annual renewal for all resources that current end-sites
pay.

> At these fee levels, I must question the viability of direct PI
> assignments
> as a replacement for many or even most potential ULA uses, which I
> understand to be a central motivation for this policy proposal.  Of
> course,
> this policy is still warranted for "normal" uses of PI space in IPv6.
>
I am confident that if this policy is adopted, the fee structure will be
adjusted accordingly.

Owen


-- 
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/20041204/78994399/attachment.sig>