On 7 Apr 2009, at 11:46, Filiz Yilmaz wrote:
I don't know if it's entirely fair and just to hold v4 to ransom in order to drive v6 adoption, but as someone who has done v6 rollouts on his own network already, and is paid to roll v6 out onto others' networks, I appreciate the sentiment and think that healthy to set our minds wandering and get conversation started. If it's good to restrict the allocation and assignment of v4 resources to organisations who have a stated v6 deployment policy, then why do we need to wait until the final /8 has been allocated to the NCC before we begin such a policy ? Perhaps we should have a phased process that asks organisations how they are deploying v6 on the PA and PI request forms, and then future requests from that organisation, or related organisations are refused if the deployment has not started. Why was /27 selected rather than /26 or /25 ? Since most deployments have multiple, separate infrastructure assignments, and services/user assignments, it seems that a /27 as a minimum allocation is far to small to promote any degree of aggregation whatsoever. This policy is therefore counter to one of RIPE's regularly stated aims - to promote route aggregation. The counter argument to this is that I might as well accept that we the side of common sense has lost the v4 aggregation debate, and v4 after-market sales will drive deagg further, so why should we care ? On the other hand, perhaps this policy will be seen as an ipv4 life extension policy. We do not want to muddy the message that we send to the community. V4's free pool will soon be gone. Do not gamble your company on policies designed to extend the availability of a very scarce resource. Maybe we can pool some of the ideas in 2009-03 and -04, and the community response, and build a solid run down policy that encourages v6 adoption, but doesn't pretend to be able to extend the life of v4. Andy