[address-policy-wg] Comments on 2006-01 (IPv6 Address Allocation and Assignment Policy)

[let's not mix up 2006-01 and 2006-02]

> We're not talking 3 years from the assignment is made, but 3 years from
> the time when there is consensus that PI in the traditional sense is no
> longer necessary.

And if consensus does not occur?  We haven't even reached the stage of
running code yet, and there is very significant controversy about
whether shim6 will ever be a suitable solution to the multihoming
problem.

> [I support PI if I have my arms twisted to fully implement v6 *now*, but
> the fundamental question is whether v6 without a scalable routing
> architecture is ready for use.]

Agreed.  And I vote that we stop using v4 on the same principle: that it
doesn't have a scalable routing architecture and is consequently not
ready for production use.  Oh, but wait??!

I support ipv6 PI space.  We have no option about its requirement now,
and in the 10 years that ipv6 has been around in its (more-or-less)
current form, the only potential alternative to emerge is shim6, which
is a long way from having running code, quite a bit further from
production deployment and the way things are looking at the moment,
furthest still from rough consensus.

I do not support the current policy proposal 2006-01 (v2.0) as it
stands, although it could be fixed to make it more palatable.

The primary problem is the implicit fixed lifetime of the address space
assignment for those organisations who require PI6 space but who have no
particular reason to eventually become a LIR. A LIR has significant
requirements in terms of administration, and it does not seem reasonable
to me to encumber those organisations who have a simple requirement for
portable address space with the choice of either becoming a LIR or being
forced to renumber.  This makes the proposal unpalatable.

I would be more inclined to support a scenario where the PI6 space
assignment is permanent but contingent on a simpler contractual
relationship with the RIR, and where that contractual relationship does
not force the assignee to become a LIR at some arbitrary point in the
future.

The minimum assignment size of /32 is too large.  PI6 space should be
assigned in some accordance with the requirements of the assignee.  It
makes no sense to assign a /32 to a small organisation with a
multihoming requirement, just because there are lots of /32's available.
Adjusting this policy to assign smaller amount of address space will not
cause any difference in count-size to the PI prefix swamp, because the
number of assignments will be directly related to the number of
assignees, not the size of the assignment (multiple assignments will
probably be uncommon, given the amount of v6 address space available).

Assignment from a super block is a good thing.

The proposal should note that an ipv6 assignment should not count
towards the requestor LIR's billing score.  If the assignee has a direct
relationship with the RIR, then this channel should be used to deal with
the administrative expense of assigning and maintaining the PI space
assignment.

The proposal should also note that if the direct relationship between
the assignee and the RIR is ended, then the address space will be
reclaimed by the RIR.  We have a lot of ipv4 address space assignment
leakage, and now that we've learned the lesson, there is no need to make
the same mistake with ipv6.

Nick