[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