The proposal is to allow Tier 0/1 ENUM operators to receive IPv4 and IPv6 anycasting assignments and extend the number of anycasting prefixes that can be assigned to an operator from one to up to four assignments.
If the name server set of a ccTLD or a gTLD without anycasting technology applied would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the TLD administrator may receive a single dedicated /24 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
Anycasting assignments are subject to Provider Independent (PI) number resource policies as described in this document and also to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for anycast DNS any longer.
[Following text is to appear in the RIPE Document, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region, if the proposal reaches consensus. Please review this change that the proposal is bringing within the drafted policy document from the link above in Draft RIPE Documents]
The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /24 prefixes per TLD and four /24 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC4786.
Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for authoritative TLD or ENUM Tier 0/1 DNS lookup services via anycast any longer.
If the name server set of a ccTLD or a gTLD without anycasting technology applied would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the TLD administrator may receive a single dedicated /48 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
The prefix will be assigned by the RIPE NCC directly to the TLD, upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. TLD anycasting address assignments are subject to the policies described in the RIPE NCC document entitled "Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for anycast DNS any longer.
[Following text is to appear in the RIPE Document, IPv6 Address Allocation and Assignment Policy for the RIPE NCC Service Region, if the proposal reaches consensus. Please review this change that the proposal is bringing within the drafted policy document from the link above in Draft RIPE Documents]
The organisations applicable under this policy are TLD managers as, recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /48 prefixes per TLD and four /48 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC4786
Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer.
It was stated at the recent RIPE Meeting by multiple operators that one /24 assignment is not enough and it's blocking the efficient deployment of anycast. If deployment of anycast is increased it could keep (or decrease) the number of NS records per TLD/ENUM, in turn this would enable operators to keep DNS reply size low even with DNSSEC.
The other regions already have a policy in place where multiple prefixes can be assigned to a single operator where such a need is justified.
Comparisons of current RIRs policies regarding DNS anycast assignments for TLD and/or ENUM Tier 0/1 can be found at:
ENUM has also been included, as this is a comparable level of critical DNS infrastructure so should be given the same opportunity.
Some people may argue that this will cause some waste of address space and additional entries in routing tables but the number of TLD/ENUM operators is limited and so such impact should be minimal.
It should also be noted that this proposal is more conservative in comparison with the policy in place in the other regions.
Some people may ask why TLD and ENUM operators should get special assignments. Due to well-understood DNS protocol limitations, the resiliency of DNS can't be increased beyond a given point without using anycast technology, so there's a strong technical reasoning. On the other hand, the number of TLD and ENUM tier 0/1 operators is limited to a few hundred, so the potential for routing table growth is limited.
Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy may have if the proposal is accepted and implemented.
We have looked at top level domains (both generic and country code TLD) in the root zone [1] and the ITU international E164 dialing codes that could be served under e164.arpa [2] and considered those listed within the RIPE NCC service region. This points to 156 possible operators who might request address space from the RIPE NCC under the proposed policy. As each operator can receive up to four prefixes, it is possible that 624 potential anycast assignments would be generated in IPv4 (/24s) and IPv6 (/48s) if this proposal were to be accepted and became a policy. In IPv4 this would resolve into a little over a /15, and in IPv6 it would be a little over a /39.
It is possible that there would be an increase of about 1,200 entries in the routing tables.
Please note that there has been a proposal discussed within the policy development process of ICANN regarding expansion of generic top-level domain names. You can find information about this at:
http://www.icann.org/en/topics/new-gtld-program.htm
This expansion is not currently in effect, however, if it is implemented in the future, it may have an impact on the numbers considered in our analysis.
Having analysed the data that is currently available, the RIPE NCC does not anticipate that this proposal will cause any significant impact on RIPE NCC Operations/Services, if implemented.
[1] ftp://ftp.internic.net/domain/root.zone.gz
[2] http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.164D-2007-PDF-E.pdf