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

Hi,

On Wed, Jan 07, 2004 at 05:15:54PM +0000, Michael.Dillon at 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 at Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299