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 Link: http:/www.ripe.net/ripe/docs/ipv4-policies.html , 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 Link: /membership/policies/proposals/2008-05/ ]
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 Link: http:/www.ripe.net/ripe/docs/contract-req.html ".
Anycasting assignments areIf the name server set of a ccTLD, gTLD or a Tier 0/1 ENUM without anycasting technology applied would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the TLD or the ENUM administrator may receive a single dedicated /24 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 or ENUM operator, upon a request submitted via an existing LIR and will be 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.
For the purposes of this policy the following definitions are made:
Tier0 Enum: User enum top level domain intended to store user enum country code delegations.
Tier0 Enum operator: The organisation that has been delegated the responsibility of operating the nameservers for e164.arpa by the IAB/ITU
Tier1 Enum: User enum second level domains intended to store enum user data within a specific geographical region.
Tier1 Enum operator: The organisation that has been delegated the responsibility of operating the nameserver for a specfic geographic region by the Tier0 Enum operator.
This policy only applies to those networks fitting within the definitions above. In other words, this policy does not apply to infrastructure or inter-operator ENUM networks.
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 or ENUM 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
[Following text is to appear in the RIPE Document, IPv6 Address Allocation and Assignment Policy for the RIPE NCC Service Region Link: http:/www.ripe.net/ripe/docs/ipv6policy.html , 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 Link: /membership/policies/proposals/2008-05/ ]
7. Anycasting TLD and NameserversThe 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 without anycasting technology applied would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the TLD or the ENUM administrator may receive a single dedicated /48 network prefix for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, name servers, as described in
BCP126/RFC4786Assignments for authoritative RFC 3258.The prefix will be assigned by the RIPE NCC directly to the
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 Link: http:/www.ripe.net/ripe/docs/contract-req.html ".Anycasting assignments are
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.
a.For the purposes of this policy the following definitions are made:
Tier0 Enum: User enum top level domain intended to store user enum country code delegations.
Tier0 Enum operator: The organisation that has been delegated the responsibility of operating the nameservers for e164.arpa by the IAB/ITU
Tier1 Enum: User enum second level domains intended to store enum user data within a specific geographical region.
Tier1 Enum operator: The organisation that has been delegated the responsibility of operating the nameserver for a specfic geographic region by the Tier0 Enum operator.
This policy only applies to those networks fitting within the definitions above. In other words, this policy does not apply to infrastructure or inter-operator ENUM networks.
The text of this version of the proposal was recovered from the slides presented at RIPE 57.
It was not possible to retrieve the following details from the archive:
Rationale:
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 Link: https://web.archive.org/web/20090520174527/http:/www.ripe.net/ripe/policies/proposals/2008-05.html#note1 ] and the ITU international E164 dialing codes that could be served under e164.arpa [2 Link: https://web.archive.org/web/20090520174527/http:/www.ripe.net/ripe/policies/proposals/2008-05.html#note2 ] 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:
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 Link: https://web.archive.org/web/20090520174527/http:/www.ripe.net/ripe/policies/proposals/2008-05.html#foot1 ] ftp://ftp.internic.net/domain/root.zone.gz Link: ftp://ftp.internic.net/domain/root.zone.gz
[2 Link: https://web.archive.org/web/20090520174527/http:/www.ripe.net/ripe/policies/proposals/2008-05.html#foot2 ] http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.164D-2007-PDF-E.pdf Link: http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.164D-2007-PDF-E.pdf