[address-policy-wg] PI for Not-DNS Anycast.

> 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