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@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.p...
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.