[ppml] Proposed Policy: PI assignments for V6

[Michel Py]

> Policy Proposal Name: PI assignments for V6
> Author: Owen DeLong
> Policy term: permanent

After long consideration and despite the fact that I have previously
opposed PI assignments for v6 I decided to support Owen's proposal; the
predicted availability of ULAs made me reverse my former position.

I still don't like the idea, and this leaves me with the uncomfortable
feeling of choosing the lesser of two evils, but I feel it is the right
thing to do now.

In the past, I have opposed PI assignments on the ground that it would
be opening the floodgates. I regret to report that the choice left
before us today is not to flood or not to flood anymore, but whether we
want a controlled flood or an uncontrolled one.

It's only a matter of time before an illegitimate registry such as
http://www.wiana.org/ pops up for ULAs. This would have been fine for
locally-scoped addresses but not for global addresses, and ULAs are
global. I vote to keep control of IPv6 PI assignments within the RIR
system.

Picking the right fees is going to be tricky. Contrary to popular
belief, I don't think that the debate along the lines of a $100/yr
maintenance fee vs. a $1,000/yr maintenance fee is relevant. The
question is not if an organization that needs a PI prefix can or cannot
afford a $1,000/yr fee; we're not talking about doing what's right
anymore but about damage control: the name of the game here is to keep
the number of small shops that think they need a PI block go the ULA way
below critical mass.

My personal preference would be a low one-time fee. The fee needs to be
low for the reason mentioned above, and I don't think that a yearly
maintenance fee is appropriate for the following reason: what happens if
an organization stops paying the fee? Unlike v4, there is no incentive
to reclaim the block to assign it to someone else (because unlike IPv4
there is no shortage of IPv6 addresses) which means that an IPv6 PI
block that has been assigned once will unfortunately become a de-facto
lifetime assignment.

I fully realize that what I wrote above is basically a support to create
the IPv6 swamp. My point here is that we are choosing the lesser of two
evils: do we want an uncontrolled swamp formed of ULAs that might not
even be registered anywhere (and that don't bring any money to the RIRs)
or do we prefer a more controlled swamp?


> Owen DeLong wrote:
> That isn't how I read the RFC.  As I read it, if I have a need
> for multiple subnets in my home, SOHO, business, etc., and I
> request it, my LIR should issue me a /48, not a batch of /64s.
> I'm not saying this is good, nor am I saying it is bad, but,
> as I read the RFC, that is what it says.

Indeed. We have settled this a long time ago, but some people still want
to use /127s on PTP links, likely the same that want to avoid "wasting"
a resource that is not constrained. Although a single /64 would likely
be fine for most home/SOHO, I do expect the "geek" home to request and
get a /48, even if 64k subnets are un-necessary. Allocating a /56 might
be less a waste than a /48 but is a futile exercise.

Michel.