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
Hi, On Wed, Jan 07, 2004 at 04:15:11PM +0100, Andreas Bäß/Denic wrote:
Request For An IPv4/IPv6 Policy Allowing Assignments For Network Critical Infrastructure
I strictly oppose anything that has "Assignments For Network Critical Infrastructure" in its title. I *do* support establishment of a policy for "Anycast address space", which might or might not be used for "Criticial Infrastructure elements". This is important: the key item is "Anycast". Everything else, critical or not, can be served by the current policies just fine. So the goal should be to formulate criteria at what point something is special enough to warrant an exceptional network block, and that should be based on technical arguments ("Anycast service, 3 or more locations, cannot be done by DNS (as e.g. Akamai would do it), etc."). Without clear criteria, this is too vague to base decisions on. NB: the other 3 RIR's "critical infrastructure" policies are just broken by design - what's special about ARIN's or ICANN's network, as opposed to the network that runs google.com? I'd say Google is much more critical to the average network user... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, Jan 07, 2004 at 04:35:06PM +0100, Gert Doering <gert@space.net> wrote a message of 34 lines which said:
what's special about ARIN's or ICANN's network, as opposed to the network that runs google.com?
ARIN (or ICANN or AFNIC or DENIC) manage public resources.
I'd say Google is much more critical to the average network user...
May be but it is a private and for-profit company. It does not manage a public resource.
Hi, On Wed, Jan 07, 2004 at 04:41:31PM +0100, Stephane Bortzmeyer wrote:
what's special about ARIN's or ICANN's network, as opposed to the network that runs google.com? ARIN (or ICANN or AFNIC or DENIC) manage public resources.
I don't claim that ARIN or ICANN or DENIC are not special, or are not important for the functioning of the Internet as a whole. But what's special about *their network*? In which way is their *network* different from any order garden variety customer network? Answer: from a technical point of view, it isn't. It's routing IP packets, it has upstream ISPs, and name resolution is done just fine via DNS. (Root name servers *are* special, because they can't be resolved via DNS (obviously)).
From a user point of view, ICANN, ARIN, DENIC, and whoever are even less special. If any of those networks falls off the earth for a day, the average user won't even notice - but if Google is offline, they *will* notice.
I'd say Google is much more critical to the average network user... May be but it is a private and for-profit company. It does not manage a public resource.
In which way makes "manage a public resource" a network infrastructure "critical"? Why isn't whitehouse.gov a "critical network infrastructure"? (To repeat myself: I have no doubts that all these instutitions are very important for the well-being of the network. But IP being what it is, their network infrastructure is "just any other network"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
what's special about ARIN's or ICANN's network, as opposed to the network that runs google.com?
ARIN (or ICANN or AFNIC or DENIC) manage public resources.
I'd say Google is much more critical to the average network user...
May be but it is a private and for-profit company. It does not manage a public resource.
great! so now we will have socio-economic constraints on address space allocation. next is political. how about blonde boys and girls can get /24s if they giggle nicely? randy
Stephane and all, Stephane Bortzmeyer wrote:
On Wed, Jan 07, 2004 at 04:35:06PM +0100, Gert Doering <gert@space.net> wrote a message of 34 lines which said:
what's special about ARIN's or ICANN's network, as opposed to the network that runs google.com?
ARIN (or ICANN or AFNIC or DENIC) manage public resources.
This is *Special* to be sure, and ICANN in particular have not managed their RIR's very well, if at all. Hence better and much more direct oversight by DOC/NTIA is needed but not been forthcoming.
I'd say Google is much more critical to the average network user...
May be but it is a private and for-profit company. It does not manage a public resource.
If it manages it's allocated addresses, than it defacto manages a portion of a public resource. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801
Hi, On Wed, 7 Jan 2004, Andreas Bäß/Denic wrote: <snip>
Technical justification for this policy
<snip>
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.
Conservation is not an issue regarding IPv6. IPv6 usage growth will also transform conservation of IPv4 in a non-issue. How many ccTLDs/gTLDs exist? Isnt this number easy to identify?
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."
It pretty much justifies it. <snip> I can also second gert's advice: focus on "anycast" to sharpen up the policies... Hope this can be done in 2004. Regards, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (131586/456), naming (millions) and... people!"
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.
Conservation is not an issue regarding IPv6.
...within an address block, this is true. However, what is being talked about here is "globally routeable chunks of addresses", and there conservation *is* an issue, since nothing really changes with respect to routing with IPv6 compared to IPv4. Regards, - Håvard
Hi, On Wed, Jan 07, 2004 at 05:26:20PM +0100, Havard Eidnes wrote:
Conservation is not an issue regarding IPv6.
...within an address block, this is true. However, what is being talked about here is "globally routeable chunks of addresses", and there conservation *is* an issue, since nothing really changes with respect to routing with IPv6 compared to IPv4.
I agree. I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course. (This is not contradicting myself, I want to point out. The network of the DENIC "office" is not special - but the name servers are. The more, the better, and there is no way to do anycasting without an additional routing table entry). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Gert Doering wrote:
Hi,
On Wed, Jan 07, 2004 at 05:26:20PM +0100, Havard Eidnes wrote:
Conservation is not an issue regarding IPv6.
...within an address block, this is true. However, what is being talked about here is "globally routeable chunks of addresses", and there conservation *is* an issue, since nothing really changes with respect to routing with IPv6 compared to IPv4.
I agree.
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
(This is not contradicting myself, I want to point out. The network of the DENIC "office" is not special - but the name servers are. The more, the better, and there is no way to do anycasting without an additional routing table entry).
Do you mean one (1) /32 that can be cut up into smaller allocations (/48) which then should appear in the global routing table, allowing the services that reside in those blocks to be anycast? Or do you mean multiple /32's as the case is for the moment*? * - list will be presented at the upcoming RIPE meeting in the IPv6-WG. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBP/w7TCmqKFIzPnwjEQKFVQCdGlarkZfl5JpNemb67/+BCH7e9hQAnRIZ TaEiEmlyYzeW/IC9b6T0kUsT =ViVg -----END PGP SIGNATURE-----
Hi, On Wed, Jan 07, 2004 at 06:01:00PM +0100, Jeroen Massar wrote:
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course. [..]
Do you mean one (1) /32 that can be cut up into smaller allocations (/48) which then should appear in the global routing table, allowing the services that reside in those blocks to be anycast? Or do you mean multiple /32's as the case is for the moment*?
For the routing table size, it doesn't really matter. Neither for the global address usage. For filtering reasons, /32s would be more convenient. (But we're not talking v6 yet :-) - DENIC aims at a v4 policy change) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, you have not been right when assuming that DENIC is only looking for an IPv4 solution. All of our nameservers should have full and native V4 _and_ V6 connectivity which includes the anycast servers as well.
Do you mean one (1) /32 that can be cut up into smaller allocations (/48) which then should appear in the global routing table, allowing the services that reside in those blocks to be anycast? Or do you mean multiple /32's as the case is for the moment*?
For the routing table size, it doesn't really matter. Neither for the global address usage.
For filtering reasons, /32s would be more convenient.
(But we're not talking v6 yet :-) - DENIC aims at a v4 policy change)
Gert Doering -- NetMaster
Regards Andreas Baess -- DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt
Hay, Andreas Bäß/Denic wrote:
Gert,
you have not been right when assuming that DENIC is only looking for an IPv4 solution. All of our nameservers should have full and native V4 _and_ V6 connectivity which includes the anycast servers as well. [...]
well, we finally should descide, if this is just about xxTLD nameervers, or about a general Anycast Policy. As I said before, i see huge differences between those two possibilites. For IPv6, there is a TLD Policy available. If we're only talking about improving connectivity options for xxTLD Nameservers, we indeed should just add some exeption to the current IPv4 Assignment policy, or transform the current http://www.ripe.net/ripe/docs/ipv6-rootservers.html to include ccTLDs and IPv4. In the meantime, after some discussions on other channels, i'm even of the opinion, this would be the better idea. - There seems to be no need for a special policy regarding IP Blocks used for anycast. Some status value ASSIGNED ANYCAST would be nice, but i guess, we need no policy - This whole issue is rather about Nameservers. xxTLD operators can't justify something like a /24 in IPv4 or /32 in IPv6 just for one nameserver glue record. Most other people thinking about deploying anycast services most likely have other needs or even other means of acquiring address space which is routable globally ==> Just update the TLD-rootnameserver Policy, easy, main problem solved, and probably even a global policy then, not only a RIPE solution. ...my 0.02EUR for now -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
- There seems to be no need for a special policy regarding IP Blocks used for anycast. Some status value ASSIGNED ANYCAST would be nice, but i guess, we need no policy
- This whole issue is rather about Nameservers. xxTLD operators can't justify something like a /24 in IPv4 or /32 in IPv6 just for one nameserver glue record. Most other people thinking about deploying anycast services most likely have other needs or even other means of acquiring address space which is routable globally
could you explain why, other than socially, the needs and resources of tld operators are different than those of anyone else deploying globally available services? randy
Hay, Randy Bush wrote:
- There seems to be no need for a special policy regarding IP Blocks used for anycast. Some status value ASSIGNED ANYCAST would be nice, but i guess, we need no policy
- This whole issue is rather about Nameservers. xxTLD operators can't justify something like a /24 in IPv4 or /32 in IPv6 just for one nameserver glue record. Most other people thinking about deploying anycast services most likely have other needs or even other means of acquiring address space which is routable globally
could you explain why, other than socially, the needs and resources of tld operators are different than those of anyone else deploying globally available services?
very simple - someone descided this before since a dedicated globally valid IPv6 Assignment policy is there specially for Root Nameserver Operators. So there must have been some global agreement on this issue this before. And this does not have to do anything with Anycasting now. <...> mind a slight sarcasm between the lines -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi, On Sat, Jan 10, 2004 at 05:12:01PM +0100, Sascha Lenz wrote:
could you explain why, other than socially, the needs and resources of tld operators are different than those of anyone else deploying globally available services?
very simple - someone descided this before since a dedicated globally valid IPv6 Assignment policy is there specially for Root Nameserver Operators.
*Root* Nameservers are not *TLD* name servers. And there is no special policy for *TLD* name servers. Please be more precise in your wording. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Sat, Jan 10, 2004 at 07:55:44AM -0800, Randy Bush wrote:
could you explain why, other than socially, the needs and resources of tld operators are different than those of anyone else deploying globally available services?
Design errors in DNS - limited packet size of DNS answer packets carrying glue records. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
could you explain why, other than socially, the needs and resources of tld operators are different than those of anyone else deploying globally available services? Design errors in DNS - limited packet size of DNS answer packets carrying glue records.
that's WHY some dns server folk want to use anycast [0]. but this does not make their address and routing needs any different from folk deploying other services. randy --- [0] - actually, only one of the reasons. others include giving users proximity to service.
On Wed, 7 Jan 2004, Gert Doering wrote:
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
.. until someone figures out that, hey, each ccTLD actually requires more entries (e.g., 3), because having just one prefix for all the servers increases the danger/threat of a routing system hiccup for a prefix.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Pekka Savola wrote:
On Wed, 7 Jan 2004, Gert Doering wrote:
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
.. until someone figures out that, hey, each ccTLD actually requires more entries (e.g., 3), because having just one prefix for all the servers increases the danger/threat of a routing system hiccup for a prefix..
I don't think so. The same prefix is announced in many places. If one of them is going down no problem. It is very unlikely that all go down because there is no single instance. The only thing that could happen is that ie. one large ISP filters that particular netblock. But then you've probably always still got a couple of the normal unicast nameservers around in the zone. -- Andre
On Wed, 7 Jan 2004, Andre Oppermann wrote:
Pekka Savola wrote:
On Wed, 7 Jan 2004, Gert Doering wrote:
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
.. until someone figures out that, hey, each ccTLD actually requires more entries (e.g., 3), because having just one prefix for all the servers increases the danger/threat of a routing system hiccup for a prefix..
I don't think so. The same prefix is announced in many places. If one of them is going down no problem. It is very unlikely that all go down because there is no single instance.
No, this is not the problem. The problem is that someone announces the prefix, but the packets get blackholed for whatever reason (badly configured access lists, forwarding bugs, etc.). Something like this has happened multiple times... This is a real threat, I think, especially if you are putting all the eggs in one basket. Note that the root nameservers aren't. Even if one anycasted root server address was hosed, the others would still be OK. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hi, On Wed, Jan 07, 2004 at 08:14:12PM +0200, Pekka Savola wrote:
On Wed, 7 Jan 2004, Gert Doering wrote:
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
.. until someone figures out that, hey, each ccTLD actually requires more entries (e.g., 3), because having just one prefix for all the servers increases the danger/threat of a routing system hiccup for a prefix..
Those entries would be for the anycast servers. There's nothing wrong with having 8 other servers hosted at some ISPs, happily using PA addresses out of the corresponding ISP's PA space, and not needing a single routing table entry. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, Jan 07, 2004 at 08:14:12PM +0200, Pekka Savola <pekkas@netcore.fi> wrote a message of 14 lines which said:
.. until someone figures out that, hey, each ccTLD actually requires more entries (e.g., 3), because having just one prefix for all the servers increases the danger/threat of a routing system hiccup for a prefix..
Most ccTLD plan to anycast only some of their servers and to keep at least two unicast machines, for this very reason.
Most ccTLD plan ...
how can you possibly say anything about what most cctlds plan? how can you say anything more than what a few plan? broad hyperbolic statements do not help us set sound policy. randy
Randy and all, Randy Bush wrote:
Most ccTLD plan ...
how can you possibly say anything about what most cctlds plan? how can you say anything more than what a few plan?
broad hyperbolic statements do not help us set sound policy.
Agreed on a broad basis or from a broad perspective. However broad questions in response also do not help set sound policy. pot, kettle, black...
randy
Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801
On Fri, Jan 09, 2004 at 08:21:48AM -0800, Randy Bush <randy@psg.com> wrote a message of 8 lines which said:
Most ccTLD plan ...
how can you possibly say anything about what most cctlds plan?
Because my english is insufficient. Most ccTLD (among those who plan to deploy anycast and (documented or talked about) their plans) plan ... Is it parsable?
On Wed, 7 Jan 2004, Pekka Savola wrote:
On Wed, 7 Jan 2004, Gert Doering wrote:
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
.. until someone figures out that, hey, each ccTLD actually requires more entries (e.g., 3), because having just one prefix for all the servers increases the danger/threat of a routing system hiccup for a prefix..
I see... However, 3 x (what? 200 countries) is still numerable... :) However-bis im afraid the entries per ccTLD might tend more to 6 than 3... even so i would prefer having 1200 "critical stuff" routes that some thousands originated my misconfigurations/historical reasons...
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (131586/456), naming (millions) and... people!"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, jan 7, 2004, at 17:32 Europe/Stockholm, Gert Doering wrote:
On Wed, Jan 07, 2004 at 05:26:20PM +0100, Havard Eidnes wrote:
Conservation is not an issue regarding IPv6.
...within an address block, this is true. However, what is being talked about here is "globally routeable chunks of addresses", and there conservation *is* an issue, since nothing really changes with respect to routing with IPv6 compared to IPv4.
I agree.
I would be happy to sacrifice one routing table entry per ccTLD, though, if it increases reliability of the whole DNS system. Speaking for my network only, of course.
(This is not contradicting myself, I want to point out. The network of the DENIC "office" is not special - but the name servers are. The more, the better, and there is no way to do anycasting without an additional routing table entry).
We solved this for IPv4 more or less with the PI-TF. Perhaps we should take this on as a point for IPv6. Agreed that it's not really the same problem, but partly the same methods could be used. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP/xUz6arNKXTPFCVEQLOpACfQn/IkejCIeuGrFMOK/Bs7R5w8eMAmwai 4HIoOL8SU+9O40pbPTzVdlif =lzjl -----END PGP SIGNATURE-----
On Wed, Jan 07, 2004 at 05:32:42PM +0100, Gert Doering <gert@space.net> wrote a message of 29 lines which said:
(This is not contradicting myself, I want to point out. The network of the DENIC "office" is not special - but the name servers are. The more, the better, and there is no way to do anycasting without an additional routing table entry).
Therefore we agree. What if DENIC changes its proposal to "critical resource *and* using anycasting"?
Hi, On Thu, Jan 08, 2004 at 11:04:33AM +0100, Stephane Bortzmeyer wrote:
(This is not contradicting myself, I want to point out. The network of the DENIC "office" is not special - but the name servers are. The more, the better, and there is no way to do anycasting without an additional routing table entry).
Therefore we agree. What if DENIC changes its proposal to "critical resource *and* using anycasting"?
I said so in the beginning: if the focus is on "anycast", I'll happy to support the proposal. As nobody is able to define what "criticial infrastructure" might be, something more specific would be useful. Like: - Anycast deployment - multiple distributed servers bring benefits for the whole community - due to protocol limitations this cannot be done using other approaches (like "put up 100 servers at various ISP networks, using PA space from those ISPs") or something like this. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
gert@space.net (Gert Doering) wrote:
Therefore we agree. What if DENIC changes its proposal to "critical resource *and* using anycasting"?
I said so in the beginning: if the focus is on "anycast", I'll happy to support the proposal.
I believe that your argumentation holds; "critical infrastructure" is something very personal, and "public"...what's public? Isn't google a public service, too? Or Yahoo? Or ebay? Or ... I favour concentrating on the anycast argument, I think, the best we could do is an allocation block from which all "anycast assignments" can be made (thus not filtering beyond /24s from this block would be easier) and it would of course be perfect, if CCTLDs joined each other in hosting anycast boxes. Well, at least it'd be nice... Yours, Elmar. -- Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. (mlelstv, dcii 2003) -----------------------------------------------------------[ ELMI-RIPE ]---
I'ld like to wish all of you a Happy New Year, and to appeal to everyone to heed <http://homepages.cwi.nl/~piet/mailrestr-en.html> when posting to this and any other RIPE list. In particular, multipart MIME containing HTML which imposes a font which may well be illegible for the recipient is quite a nuisance. Show clue, folks! Thanks Niall O'Reilly
participants (14)
-
Andre Oppermann -
Andreas Bäß/Denic -
Carlos Friacas -
Elmar K. Bins -
Gert Doering -
Havard Eidnes -
Jeff Williams -
Jeroen Massar -
Kurt Erik Lindqvist -
Niall O'Reilly -
Pekka Savola -
Randy Bush -
Sascha Lenz -
Stephane Bortzmeyer