Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
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 think you are wrong here. The important part of this proposal is the critical infrastructure. Anycast is a technical solution and it can be used for unimportant things as well.
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...
DNS services are critical infrastructure, especially top level domain services. You might argue that it would be better for all top level domains to pool their resources and share the same anycast architecture and I would probably agree with you. But I believe that the .de DNS service is far more important than Google's search engine because if the .de service is unavailable then no-one will be able to resolve google.de so the search engine will become unreachable. I agree that the other RIR policies may not be a good example for RIPE to follow. Sometimes RIPE can do things better. Personally I would rather have seen DENIC propose a simple policy text and then explain why. That might be easier to discuss than a request for someone else to write the policy text. Suggestion... RIPE will allocate /24 blocks from the IPv4 address range that was once called "Class C" address space for use by services that are part of the Internet's critical infrastructure. These blocks are for services that will exist for the forseeable future, are used freely by many organizations, and are likely to outlive the lifetime of the organization currently operating the service. I think that .de nameservice meets this criteria. The .de DNS will exist forever, anybody can use it without subscribing or registering, and if DENIC ceased to exist, some other organization would take over the responsibility of hosting .de. --Michael Dillon
Hi, On Wed, Jan 07, 2004 at 05:15:54PM +0000, Michael.Dillon@radianz.com wrote:
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 think you are wrong here.
I could certainly be wrong, but I'm still opposing it, and I've mentioned good reasons why "critical infrastructure" is not a very useful phrase regarding the decision "who is important enough to gain a special case".
The important part of this proposal is the critical infrastructure. Anycast is a technical solution and it can be used for unimportant things as well.
Sure, but you'd need a dedicated and routeable prefix for *any* sort of anycast. While there *is no* critical infrastructure (besides the root DNS servers) that's "definitely more critical than everything else that's really so very important".
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...
DNS services are critical infrastructure, especially top level domain services.
DNS services are critical infrastructure, but nothing about DNS services (except the root) needs special network allocation policies. ccTLD/gTLD DNS service works very well using provider aggregateable address space. Changing glue in the root zone is heard to be needlessly difficult, but that's not something thats ideally solved by changing the address allocation policies (to avoid having to change glue records at all).
You might argue that it would be better for all top level domains to pool their resources and share the same anycast architecture and I would probably agree with you. But I believe that the .de DNS service is far more important than Google's search engine because if the .de service is unavailable then no-one will be able to resolve google.de so the search engine will become unreachable.
I don't buy that. DENIC has many name servers, spread all over Europe (and further maybe), already now, without changing IP address policy. Whatever happens to one of those servers doesn't affect my capability to resolve "google.de" (and besides, there's google.com as well :) ). If the master zone file is corrupted, google.de is dead indeed - but no matter what you do to address allocation is going to fix *that*. The point here is "they need more servers and the DNS protocol is too restricted to permit more servers with distinct names" -> so the whole issue is *anycast*. Inventing an address policy that permits everyone who is specially important to get "their special address block" will, in itself, do *nothing* to increase ccTLD reliability. Adding anycast will do. [..]
Suggestion... RIPE will allocate /24 blocks from the IPv4 address range that was once called "Class C" address space for use by services that are part of the Internet's critical infrastructure. These blocks are for services that will exist for the forseeable future, are used freely by many organizations, and are likely to outlive the lifetime of the organization currently operating the service.
That's not helpful, as it centers around "critical infrastructure". How is the RIPE NCC supposed to evaluate how "criticial" something is? .de reachability is mostly meaningless for the majority of the Internet users (as are all other ccTLDs). 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
good reasons why "critical infrastructure" is not a very useful phrase regarding the decision "who is important enough to gain a special case".
I agree that this particular term could be optimized because it actually calls for a beauty contest. But chosing the title can be postponed.
ccTLD/gTLD DNS service works very well using provider aggregateable address space. Changing glue in the root zone is heard to be needlessly difficult, but that's not something thats ideally solved by changing the address allocation policies (to avoid having to change glue records at all).
Andreas' mail included a pointer to the Vixie/Kato draft which explains why you can't increase the number of NS or A or AAAA RRs for TLD (and other) beyond a certain limit. The reasoning is similar to the root server case. So, anycasting is Best Current Practice. But a policy change that indirectly "allowed" a separate route per anycast address would sooner or later have to decide who's going to do anycast or who's doing critical vs non-critical anycast or would miss the goal because routes would again be filtered. Even if special anycast addresses would be defined, what's the threshold, i.e. how many instances would be required and who's going to check and monitor these requirements? How big is the problem currently? -Peter
participants (3)
-
Gert Doering -
Michael.Dillon＠radianz.com -
Peter Koch