[address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy

Dear all,
I find it hard to see a clear consensus on this proposal and will ask 
the RIPE NCC to summarize the concerns in the process and asssist the 
author to reformulate the proposal to take theese concerns into account. 
We vill then reopen the discussion phase as soon as there is a revised 
version of the  proposal.

Best Regards,

Hans Petter Holen
Address Policy Chair

------------------------------------------------------------------------

> Dear all,
> After concideration and consultation with mu co-chairs I propose to 
> exted the discussion period to May 6th so we still have oportunity to 
> discuss this at the RIPE meeting.
>
> Best Regards,
> Hans Petter Holen
> Address Policy Chair
>
> Hans Petter Holen wrote:
>
>> Dear all,
>> Please find enclosed a policy proposal. As per my previous message I 
>> will "beta-test" the new PDP on this proposal.
>> The current proposal has been discussed previously and has now been 
>> re-formulated after that discussion.
>> My proposal is to enter this proposal into the Discussion Phase with 
>> a time line of 2 weeks  ending on April 4th.
>>
>> Best Regards,
>>
>> Hans Petter
>>
>>
>> 1.Number (assigned by the RIPE NCC)
>>     alpha
>>
>> 2.Policy Proposal Name: TLD Anycast Allocation Policy
>>
>> 3.Author
>>  a.name: Andreas Baess
>>  b.e-mail: baess at denic.de
>>  c.telephone: +49 69 27235 0
>>  d.organisation: DENIC e.G.
>>
>> 4.Proposal Version: 1
>>
>> 5.Submission Date:
>>
>> 6.Suggested WG for discussion and publication:   Address Policy 
>> Working Group
>>
>> 7.Proposal type: new
>>
>> 8.Policy term: renewable
>>
>> 9.Summary of proposal
>>
>> To enable ccTLD and gTLD nameserver operators to provide their DNS 
>> service
>> using shared unicast technology, RIPE NCC is able to assign one IPv4 and
>> IPv6 prefix per operator that is not likely to be filtered by common
>> practise for anycast-operation of their DNS services.
>>
>> 10. Policy text
>>
>> a.Current: N/A
>>
>> b.New:
>>
>> "If the nameserverset of a TLD without anycasting technology applied 
>> would
>> not pass the IANA Administrative Procedure for Nameserver Delegation and
>> Glue Data (http://www.iana.org/procedures/delegation-data.html) may 
>> receive
>> dedicated network prefixes for the sole purpose of anycasting name 
>> servers,
>> as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one
>> /32 IPv6 prefix per operator. The prefixes shall be tagged as 
>> 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the 
>> RIPE NCC
>> if not in use for anycast DNS any longer."
>>
>> 11. Rationale:
>>
>> PROS
>>
>> A. Acceptance of DNS for special treatment
>>
>> Studies like 
>> http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.pdf 
>>
>> shows clearly that ccTLD and gTLD nameservers are a critical network 
>> infrastructure that justify special policies to guarantee operability of
>> Internet applications.
>>
>> B. Policy Harmonization
>>
>> Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing
>> assignments to network critical infrastructure. All three policies 
>> classify
>> TLDs as critical infrastructure. Extracts from these policies can be 
>> found
>> in Appendices I through III. C. Scalability of DNS
>> To serve the projected increase of DNS queries and to ensure sufficient
>> network topological coverage and diversity TLD managers need to deploy
>> an increasing number of nameservers.
>>
>> D.    Resilience
>> Internet has become part of the daily life and their availabilty is as
>> important as the availability of all public services.  Anycasting is
>> currently the state-of-the-art solution to lower the impact of DDoS 
>> attacks.
>>
>> E.    IPv6 Support
>>
>> As the world starts exploiting IPv6, the DNS infrastructure should 
>> support
>> IPv6 natively. However it is not yet possible to reduce the number of
>> nameservers in the IPv4 cloud.
>>
>> CONS
>> F. Waste of Address Space
>>
>> Accepting a number of IPv4/24 and IPv6/32 allocations for critical 
>> network
>> infrastructures does not align with the traditional address conservation
>> efforts. With anycasting it is very likely that only a few addresses 
>> from
>> the entire assignment would be used.
>>
>> 2. Root DNS are special, others are not
>>
>> RIPE document 233 dated from  24th May 2002 says: "Although it is 
>> undesirable
>> to give special status to any IP (IPv4 or IPv6) address block, it was 
>> agreed
>> by the community that the particular need defined in this document is 
>> the only
>> justifiable exception to that general principle."
>>
>> 3. Assigning an own network prefix is just a workaround to ensure global
>> reachability which could also be achieved by adjusting currently 
>> deployed
>> route filter practices.
>>
>> Appendix I
>>
>> APNIC Policy
>>
>> (Following section is taken from 
>> http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3)
>>
>> 11.3 Critical infrastructure
>>
>> The following critical infrastructure networks, if operating in the
>> Asia Pacific region, are eligible to receive a portable assignment:
>>
>> * root domain name system (DNS) server;
>> * global top level domain (gTLD) nameservers;
>> * country code TLD (ccTLDs) nameservers;
>> * IANA;
>> * Regional Internet Registry (RIRs); and
>> * National Internet Registry (NIRs).
>>
>> Assignments to critical infrastructure are available only to the actual
>> operators of the network infrastructure performing such functions.
>> Registrar organisations which do not actually host the network housing
>> the registry infrastructure, will not be eligible for an assignment 
>> under this policy.
>>
>> The minimum assignment made under these terms is /24.
>>
>>
>>
>> Appendix II
>>
>> ARIN Policy
>>
>> (Following section taken from 
>> http://ww2.arin.net/policy/index.html#four4)
>>
>> 4.4.  Micro-allocation - ARIN will make micro-allocations to critical
>> infrastructure providers of the Internet, including public exchange 
>> points,
>> core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD
>> operators) as well as the RIRs and IANA. These allocations will be no
>> longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations
>> may be granted in certain situations.
>>
>> Appendix III
>>
>> LACNIC
>>
>> (Following section is taken from http://lacnic.net/policy-en.pdf)
>>
>> 3.3.3 Micro Allocations
>>
>> Micro allocation is the name given to those allocations that imply 
>> blocks
>> smaller than /20 but always larger than or equal to /24.
>>
>> LACNIC can grant this type of allocation in case of projects and 
>> infrastructure
>> for networks that are key or critical for the region, such as IXPs 
>> (Internet
>> Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among 
>> others.
>>
>> In the case of IXPs or NAPs, in order to be able to apply for this 
>> type of
>> allocation, organizations shall meet the following requirements:
>>
>> 1. Duly document the following aspects:
>> 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The 
>> organization shall have at least three members and an open policy in 
>> relation to the association of new members.
>> 1. 2Submit a company structure organizational diagram.
>> 1. 3Document the numbering plan to be implemented.
>> 2. Provide a usage plan for the following three and six months.
>>
>> The rest of the applications shall be studied based on the analysis 
>> of the
>> documentation justifying the critical and/or key aspects of the project.
>> Organizations receiving micro allocations are not authorized to 
>> suballocate
>> these addresses.
>>
>>
>>