there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they?
They shouldn't unless they need features that are available in v6 that are not available in v4. Where's the harm in this? The v6 stack provides for encapsulating v4 addresses in v6 easily enough and the v6 specs already make allowance for this. I don't see any reason we need to get such a site over to v6.
on the other hand, 1 ASN -> 1 v6 prefix does not necessarily mean 1 v6 prefix -> 1 ASN. might work out.
While I think a policy of "If you qualify for an ASN, you qualify for a prefix" makes sense, I do not think that the reverse makes any sense whatsoever. Just because you have or qualify for a prefix does not necessarily mean you qualify for or need an ASN. Additionally, there will be providers that grow and have multiple prefixes within a single ASN.
The convenience factor _is_ already outlawed.
true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed.
As near as I can tell, there's very little reason for such a site to ever adopt v6 and very little reason for the world to care that they didn't. As such, I'm not sure I understand why this is a significant issue. Is there some reason it's important for these sites to go to v6 instead of using 4-to-6 address encapsulation at their border? Owen -- If it wasn't crypto-signed, it probably didn't come from me.