Policy proposal: #alpha: TLD Anycast Allocation Policy
Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th. Best Regards, Hans Petter 1.Number (assigned by the RIPE NCC) alpha 2.Policy Proposal Name: TLD Anycast Allocation Policy 3.Author a.name: Andreas Baess b.e-mail: baess@denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G. 4.Proposal Version: 1 5.Submission Date: 6.Suggested WG for discussion and publication: Address Policy Working Group 7.Proposal type: new 8.Policy term: renewable 9.Summary of proposal To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services. 10. Policy text a.Current: N/A b.New: "If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer." 11. Rationale: PROS A. Acceptance of DNS for special treatment Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.p... shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications. B. Policy Harmonization Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers. D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks. E. IPv6 Support As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud. CONS F. Waste of Address Space 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. Root DNS are special, others are not 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." 3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices. 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://ww2.arin.net/policy/index.html#four4) 4.4. Micro-allocation - 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. 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-04, at 20.38, Hans Petter Holen wrote:
Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th.
I am behind on email, but better late than never....
9.Summary of proposal
To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services.
This part troubles me. This is a significant change from current policy on guaranteed routability, and also quite a deviation from the critical infrastructure policies of the other RIRs. I would like to remove the "likely not to be filtered" from the above, or add that at no times can the RIPE NCC guarantee routability or wide reachability and acceptance of the assigned prefixes.
"If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer."
I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block. Also, to follow the "have you considered private address space" (or whatever the exact formulation is ) question in the PI application, I would like to require the applicant to consider using an existing anycasting service. YEs, I understand that that is a business decision, but so is accepting these prefixes by the rest of the world. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkE4h6arNKXTPFCVEQK5PwCgy2upHuiK5Odk+FyGV54UY6UXCzQAnjMA itq8rIX9z3ov1GjO4LGEc1Tn =4ibU -----END PGP SIGNATURE-----
Hi Kurtis, kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services.
This part troubles me. This is a significant change from current policy on guaranteed routability, and also quite a deviation from the critical infrastructure policies of the other RIRs. I would like to remove the "likely not to be filtered" from the above, or add that at no times can the RIPE NCC guarantee routability or wide reachability and acceptance of the assigned prefixes.
I'd go for something like "...IPv6 prefix per operator for anycast- operation of their DNS services. While the RIPE NCC naturally cannot guarantee routability of assigned or allocated prefixes, care shall be taken to select a prefix that is less likely to be filtered than other candidates." I myself would prefer a defined range (say, a /32 block out of which /48s are allocated), but I seem to be a minority with that opinion. This range would allow operators to exclude it from their filters.
/32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer."
I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block.
Joining the minority? ;-) I believe the proposal for a /32 tried to minimize the probability of being filtered. And since there's no real need not to be generous...
Also, to follow the "have you considered private address space" (or whatever the exact formulation is ) question in the PI application, I would like to require the applicant to consider using an existing anycasting service. YEs, I understand that that is a business decision, but so is accepting these prefixes by the rest of the world.
Quite some "small zone" ccTLDs already use other cc/gTLDs setups, so what you're proposing is already done in the real world. If a TLD goes to the hassle of setting up, shipping, connecting, and maintaining anycast setups around the world which, if I may say so, includes quite some battles with network operators to remove the prefix from their filters, they will most probably already have considered using third party anycast services. And decided to operate the grid themselves. Cheers, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 23-mrt-05, at 11:28, Sander Steffann wrote:
I myself would prefer a defined range (say, a /32 block out of which /48s are allocated), but I seem to be a minority with that opinion.
I'll join that minority group :-)
I would strongly prefer a smaller block than a /32. ARIN has a /30. If someone makes a filter that allows upto /48 in that /30, this means that some evildoer could inject 250k /48s in that /30 and make routers all over the world run out of memory. On the other hand, if RIPE would use a /35 or something like that, this would only allow for a maximum of 8192 of these prefixes. A leak of that size presumably won't kill too many routers. I would also be very happy if RIPE would charge enough money to people wanting to do this to make them consider whether they really need it.
On Wed, 23 Mar 2005, Iljitsch van Beijnum wrote:
I would also be very happy if RIPE would charge enough money to people wanting to do this to make them consider whether they really need it.
Agreed.. but unfortunately, RIRs operate (typically) on a cost-recovery basis.. FWIW, I think it makes perfect sense to give each of these their own /32. Arguments about conservation are IMHO bogus when we're talking about one-in-4-billion allocations. That allows people to filter just fine, has better failure modes (as Joao pointed out), and does not have the concern Iljitsch noted. I guess the folks opposed to using /32's are mainly the ones which want to inject their own (non-related) /48's and would like the operators to drop the "we don't accept anything past /32 or /35 unless very well justified" filters. Which are a good thing, but out of scope for discussion on this list. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, Mar 23, 2005 at 10:58:18AM +0100, Elmar K. Bins wrote:
I myself would prefer a defined range (say, a /32 block out of which /48s are allocated), but I seem to be a minority with that opinion. This range would allow operators to exclude it from their filters.
I totally agree. Derriving policy from prefix length (at least in the range up to /48) is just bogus and shouldn't be supported by issuing /32s to guarrantee routability. The folks filtering ANYTHING longer than /32 or /35 are just wrong. A /48 is far more than enough.
I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block.
Joining the minority? ;-)
I certainly do. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote:
I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block.
What would the problem be with the /32, really? Counting the addresses? Howeverm, the "out of a single block" is the part that really bothers me. Putting supposedly "critical infrastructure" as it is called elsewhere in a block that makes them all share fate in the event of network "optimisations" is still a bad idea.
Also, to follow the "have you considered private address space" (or whatever the exact formulation is ) question in the PI application, I would like to require the applicant to consider using an existing anycasting service.
Sounds like a good idea, actually. Joao
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-23, at 14.39, Joao Damas wrote:
On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote:
I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block.
What would the problem be with the /32, really? Counting the addresses?
"640k should be enough for anyone" :-) (Although Mr Gates disputes that statement ever been said here : http://www.nybooks.com/articles/15180#fn*). My main concern is that this again is contrary to the "conservation" policy which is one of the reasons we have RIRs at all...
Howeverm, the "out of a single block" is the part that really bothers me. Putting supposedly "critical infrastructure" as it is called elsewhere in a block that makes them all share fate in the event of network "optimisations" is still a bad idea.
Well, this can be argued the otherway around as well. We know that ISPs filter out previously unused space, and that they are not very active in updating those filters when IANA starts allocating out of new blocks. Having all in well-known block would limit that. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkF1GaarNKXTPFCVEQLi+wCfTXZHrL4u+kAvRuDB1O6mc2AJWy0AoPN1 S4yfPNG+44ZYMKm7gZ3Z0nZq =FH9m -----END PGP SIGNATURE-----
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
Howeverm, the "out of a single block" is the part that really bothers me. Putting supposedly "critical infrastructure" as it is called elsewhere in a block that makes them all share fate in the event of network "optimisations" is still a bad idea.
Well, this can be argued the otherway around as well. We know that ISPs filter out previously unused space, and that they are not very active in updating those filters when IANA starts allocating out of new blocks. Having all in well-known block would limit that.
Additionally, once someone starts filtering, they will receive much more pressure than if the block contained only one piece of "critical infrastructure". As always the coin has two sides :) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 23 Mar, 2005, at 14:54, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2005-03-23, at 14.39, Joao Damas wrote:
On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote:
I don't see why RIPE need to assign a /32 when the other regions are /48s? I would also like to add that these assignments should be made out of a single block.
What would the problem be with the /32, really? Counting the addresses?
"640k should be enough for anyone" :-) (Although Mr Gates disputes that statement ever been said here : http://www.nybooks.com/articles/15180#fn*). My main concern is that this again is contrary to the "conservation" policy which is one of the reasons we have RIRs at all...
You really think so? Even for IPv6? For me the real value is that RIRs provide uniqueness, that is their true value. Just like a cadaster. Conservation has been an additional task that has been put on the RIRs thanks to the limitations of IPv4 (<mild sarcasm> and surely IPv6 will solve that </mild sarcasm>. Was the main goal of the RIPE NCC conservation (other than through promotion of CIDR) when it came into existence?
Howeverm, the "out of a single block" is the part that really bothers me. Putting supposedly "critical infrastructure" as it is called elsewhere in a block that makes them all share fate in the event of network "optimisations" is still a bad idea.
Well, this can be argued the otherway around as well. We know that ISPs filter out previously unused space, and that they are not very active in updating those filters when IANA starts allocating out of new blocks. Having all in well-known block would limit that.
However that affects one at a time, rather than all at once. I mean if go shooting ducks I really prefer to have them all nicely bunched together so that it requires less skill, but if I am a duck I would rather make it more difficult for the hunter (or wild sniper entering the burger shop, as it may be) Joao
Dear all, After concideration and consultation with mu co-chairs I propose to exted the discussion period to May 6th so we still have oportunity to discuss this at the RIPE meeting. Best Regards, Hans Petter Holen Address Policy Chair Hans Petter Holen wrote:
Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th.
Best Regards,
Hans Petter
1.Number (assigned by the RIPE NCC) alpha
2.Policy Proposal Name: TLD Anycast Allocation Policy
3.Author a.name: Andreas Baess b.e-mail: baess@denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G.
4.Proposal Version: 1
5.Submission Date:
6.Suggested WG for discussion and publication: Address Policy Working Group
7.Proposal type: new
8.Policy term: renewable
9.Summary of proposal
To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services.
10. Policy text
a.Current: N/A
b.New:
"If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer."
11. Rationale:
PROS
A. Acceptance of DNS for special treatment
Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.p...
shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications.
B. Policy Harmonization
Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers.
D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks.
E. IPv6 Support
As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud.
CONS F. Waste of Address Space
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. Root DNS are special, others are not
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."
3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices.
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://ww2.arin.net/policy/index.html#four4)
4.4. Micro-allocation - 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.
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.
Dear all, I find it hard to see a clear consensus on this proposal and will ask the RIPE NCC to summarize the concerns in the process and asssist the author to reformulate the proposal to take theese concerns into account. We vill then reopen the discussion phase as soon as there is a revised version of the proposal. Best Regards, Hans Petter Holen Address Policy Chair ------------------------------------------------------------------------
Dear all, After concideration and consultation with mu co-chairs I propose to exted the discussion period to May 6th so we still have oportunity to discuss this at the RIPE meeting.
Best Regards, Hans Petter Holen Address Policy Chair
Hans Petter Holen wrote:
Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th.
Best Regards,
Hans Petter
1.Number (assigned by the RIPE NCC) alpha
2.Policy Proposal Name: TLD Anycast Allocation Policy
3.Author a.name: Andreas Baess b.e-mail: baess@denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G.
4.Proposal Version: 1
5.Submission Date:
6.Suggested WG for discussion and publication: Address Policy Working Group
7.Proposal type: new
8.Policy term: renewable
9.Summary of proposal
To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services.
10. Policy text
a.Current: N/A
b.New:
"If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer."
11. Rationale:
PROS
A. Acceptance of DNS for special treatment
Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.p...
shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications.
B. Policy Harmonization
Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers.
D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks.
E. IPv6 Support
As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud.
CONS F. Waste of Address Space
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. Root DNS are special, others are not
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."
3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices.
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://ww2.arin.net/policy/index.html#four4)
4.4. Micro-allocation - 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.
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.
participants (8)
-
Daniel Roesen -
Elmar K. Bins -
Hans Petter Holen -
Iljitsch van Beijnum -
Joao Damas -
Kurt Erik Lindqvist -
Pekka Savola -
Sander Steffann