You can develop much, but as long as it's not there, why the need for a policy on that? Do we really want a very very vague policy? Last time i checked, i was told that RIPE NCC doesn't like vague policies.
Very very vague policies are bad. But policies which specify too much irrelevant detail are also bad. The current IPv4 Anycast policy is bad because it says that some DNS servers are special and deserve to have their own PI block without any of the normal technical justification. Also, these special DNS servers are exempt from the usage rules and are allowed to waste over 99% of their block. A good policy would leave DNS out of the criteria because DNS isn't special. If an organization can show that they have many geographically diverse hosting sites where they will host servers using IPv4 Anycast, then we have something similar to the technical justification that other IPv4 users must provide. In addition, we could require these organizations to have a plan for using a reasonable percentage of their PI block within the first year, perhaps 25%. This would mean that they have to do one of two things: 1) Find other DNS providers that want to use IPv4 Anycast and sell them hosting services. 2) Find people who want to pay for IPv4 Anycast hosting services for some other application. Maybe commercial. Maybe experimental. RIPE normally does not care what end users do on the Internet as long as they build real networks and connect real hosts. Doesn't that sound a lot like a normal LIR/ISP who gets a PI allocation and then sells Internet access services to other companies? IPv4 Anycast is a little bit special and does deserve a policy that is tailored to the TECHNICAL REQUIREMENTS OF IMPLEMENTING IPv4 ANYCAST, but it does not deserve a restrictive policy that is anticompetitive and forces companies to lie and cheat RIPE in order to get a PI block. RIPE's current policy treats IPv4 Anycast as a second class citizen unless it is used by the in-group who run DNS servers.
Again, do you have a real world example? Why isn't the policy about experimental assignments, which is there for IPv4 and IPv6 not enough to get the development started?
Fixing the IPv4 Anycast policy does not prevent you from proposing a good experimental use policy or proposing changes to the IPv6 policies. We can do all of these things at the same time in separate policy proposals.
We make policy BEFORE handing out resources. Therefore, the use of the
..soo in your eyes, the ULA-C policy proposal was timed right? :-)
No because ULA-C resources do not exist. IPv4 Anycast has been described in RFCs since at least 1993. Check RFC 1546 for the first one that I know of. Also, IPv4 Anycast is mentioned in RFC 3068 where it is used as an address for 6to4 Relay Service. So DNS is not the only IPv4 Anycast application that has been currently implemented. It also exists for 6to4 relay. IPv4 Anycast is an old technology (if 14 years is old) which can be applied to a wide range of applications. We should not be blocking the development of such applications by forcing developers to work their way through the policy process in order to simply get a single /32 address. If we had a rational IPv4 Anycast policy, then some service providers with geographically distributed data centers would get an IPv4 Anycast /24 from RIPE and offer /32's to customer who host their IPv4 Anycast application in their data center.
OK, i think i need another .. say two /23s and /32s for Anycast usage, i MIGHT deploy it someday in the future,
Go sign a contract with an Anycast hosting company and pay their monthly fees. I don't care if you ever get your application functioning and RIPE doesn't care either. As long as you have some hosts connected to the Internet in the Anycast ISP hosting centers, they will give you a fully justified /32 from their /24. --Michael Dillon