Beeing the first on this list in 2004 I can't resist to express
my best wishes to everyone :-)

During the last year, when we made plans for our further
operations of our nameservice (i.e. anycast and introduction
of IPv6), we discovered that we are getting into conflict
with some of the RIPE allocation policies. I have been encouraged
to start a discussion about making a policy change request.

So here it comes:

Request For An IPv4/IPv6 Policy Allowing Assignments
For Network Critical Infrastructure

Abstract

At the moment, DENIC has eleven nameservers serving the de zone. At the moment they are
all IPv4 only. DENIC wants to change the DNS setup with a higher total number of
nameservers which not only have IPv4 but also IPv6 connectivity. However DENIC cannot
simply increase the number of NS records and add AAAA records as this would quickly
occasion truncation in the authority section of the UDP answer. Ignoring this limitation would
cause negative effects that are described in http://www.ietf.org/internet-drafts/draft-ietf-
dnsop-respsize-00.txt

In order to keep at least the current quality of service, improve the resilience against
distributed denial of service attacks (DDoS) and easier future scalability, the deployment of
anycast technology (RFC3258) has been chosen for the future DENIC DNS operation.

DENIC can not simply use addresses out of their current assignment because it is current
practice to filter announcements on allocation boundaries.

Therefore DENIC requests to establish a policy for ccTLD and gTLD nameservers that allows
RIPE NCC to assign IPv4, IPv6 addresses that are not likely to be filtered by common
practise for anycast-operation of their DNS services.


Technical justification for this policy

Pros:

1.        Acceptance of DNS to be network critical

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.

Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to
network critical infrastructure. All three policies classify ccTLDs as critical infrastructure.
Extracts from these policies can be found in Appendices I through III.  

2.        Usage of DNS

By size
 
DENIC has 7 million registered domains with a monthly increase of 1%. The introduction of
IDN in 2004 will increase the number of de-domains by roughly 500,000 to 1,000,000
domains in addition to the normal growth rate.  

Query load on nameservers

DENIC currently serves 10,000 queries per second (all nameservers combined). The load is
expected to increase exponentially as the acceptance of the Internet as a communication
infrastructure is rising.  

New usage for DNS

New integrating services like ENUM rely on DNS as their distributed information database.
The adoption of ENUM will contribute to the importance of DNS for normal life of industry
operations.
3.        Resilience

As availability expectation for Internet applications grow, nameservers are part of the critical
Internet infrastructures to make these applications work. Anycasting is currently the state-of-
the-art solution to lower the impact of DDoS attacks.
4.        Allow smooth IPv6 transition

As the world starts exploiting IPv6, the critical infrastructures should support them natively.
However the limit of 512 bytes UDP responses put a limit on the total number of names and
addresses (IPv4 and IPv6) that can be supplied using DNS protocol. Extension mechanisms
for DNS (EDNS0) has removed this limitation but is not widely deployed yet. This dilemma,
needing more space in the packets than DNS protocol provides, can be overcome by using
anycast technology.



Cons:

1.        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.        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."

Consequences of a policy change

After allowing special assignments for anycast ccTLD/gTLD nameservers, there is a need to
establish consensus in the RIPE region about which criteria will qualify a service to be
considered Internet critical infrastructure. There might be other services beside TLD DNS
falling into this category.




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://www.arin.net/policy/ipv4.html#microalloc)

Micro-allocations (Policy 2001-3)

Note: This policy makes obsolete the former micro-allocation policy.

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.

Exchange point allocations MUST be allocated from specific blocks reserved only for this
purpose. All other micro-allocations WILL be allocated out of other blocks reserved for
micro-allocation purposes. ARIN will make a list of these blocks publicly available.


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.


--
Andreas Baess
DENIC eG
Wiesenhüttenplatz 26
D-60329 Frankfurt