[address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20040107/f5e1cc98/attachment.html>