Hi,
I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal.
I'm still of the opinion that removing the dual homing requirement for PI is a mistake.
Having done some work on renumbering on IPv6, its much easier than v4 (assuming that you design the addressing to be portable) and not the barrier that people believe that it is with v4.
Please feel free to correct my thinking but PA space is for LIRs to give to customers for their use, PI space is for those customers who require a separate block because they need to be 'independent' of their LIR. The only time this is required (afaict) is when the block *needs* to be routed by a third party for resilience and therefore needs to be multi-homed.
By removing that requirement we are 'encouraging' the requisition of additional resources where non is required and increasing the size of the routing table unnecessarily.
If there is another problem we are trying to solve (as in PI space not being suitable for sub-allocation) then we are trying to solve it the wrong way...
this is a repeat for the 68060th time so i try to be brief: there wasn't a multihoming requirement in the IPv4 PI world lately, or was it? there is no IPv4 PI problem (rather a IPv4 PA deaggregation problem), so there certainly won't be any with IPv6 PI - by design ("one prefix only, usually") there is a problem with this difference between IPv4 and IPv6 PI policies which hinders IPv6 deployment right now This policy change is about NOTHING else than aligning the IPv6 PI policy with the IPv4 PI policy we have for ages. It will not end the world or encourage more IPv6 PI usage than IPv4 PI usage. All other requirements are still the same (roughly). This policy change does not try to solve any other problem than allowing IPv4 PI holders who don't multi-home to be able to get IPv6 PI and do the right thing - getting IPv6 deployment started. If there is a problem with this policy in 5-10 years due to some reasons, we can change the policy again, it's not written in stone. Things change, policies can, too. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect