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