- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>> 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? A workable policy would need to have definitions of "infrastructure" and "critical" that RIPE can use to evaluate any requests. >.de reachability is mostly meaningless for the majority of the >Internet users (as are all other ccTLDs). Reachability of .com and .net is also mostly meaningless for the majority of the Internet users. They only care if they can get to .cn sites because they can only read one language. The Internet has never recognized the tyranny of the majority so I don't think we should be worrying about this today. --Michael Dillon

3 2

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>In which case I claim that my PC at home is a highly critical infrastructure >as well. When I posted the following suggestion, it included a definition for critical infrastructure and your PC at home doesn't meet it. 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. Your PC at home is not offering a service that will exist for the foreseeable future. I can forsee a future for the Internet into the 22nd century when you and your home PC will be dead. Your home PC is probably not offering a service that is used freely by many organizations. I think this part of the definition needs some work because some people would argue that Google's service meets this criteria but I would argue that part of Google's service are the ads which are not offered freely, i.e. they cost money. Your home PC is not offering any service that would continue to be offered even if you and your home and your company cease to exist. But if DENIC ceases to exist, it is 100% certain that ICANN would find some other organization to continue offering .de nameservice. Maybe this definition should use a name other than critical infrastructure. And my suggestion is nothing more than a first draft. My main point is that a new policy proposal should begin with a first draft of the policy itself so that people can discuss the draft policy instead of spending all the time discussing why it is impossible to write a policy at all. --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>>People seem to be confused about the meaning of "critical infrastructure" >>so I decided to see what Google has to say. The first thing it comes up >>with is an American government organization called the Department for >>Homeland Security. On their question and answer page they say this: >>http://www.ciao.gov/publicaffairs/qsandas.htm >Why should Europe and the RIPE region care about what the US defines as >critical infrastructure? Two reasons. 1. We were talking about Google and if you use Google to search for "critical infrastructure" that is the first link that comes up. 2. There was confusion about the meaning of the English language phrase "critical infrastructure" and it is useful to study how native speakers of English define this phrase. The U.S.A. contains a large number of native English speakers. If you prefer European sources, here is a PDF booklet from the UK's National Infrastructure Security Co-ordination Centre formed in 1999 before the U.S.A. was putting so much emphasis on homeland security. http://www.niscc.gov.uk/aboutniscc/booklet/NISCC%20Booklet2.pdf And if you want EU sources, then here is a report to the EU Parliament on Scientific and Technological Options Assessment (STOA) that is published in both English and German http://www.europarl.eu.int/workshop/itsecurity/docs/helmbrecht_en.pdf http://www.europarl.eu.int/workshop/itsecurity/docs/helmbrecht_de.pdf The point is that "critical infrastructure" is a term that many people already use in policies and they always find it important to provide a definition for the term within the context that they are discussing. RIPE can do the same. --Michael Dillon (living and working in London)

1 0

Re: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Sabine Dolderer/Denic 08 Jan '04

08 Jan '04

On 08.01.2004 12:10 Hank Nussbacher <hank(a)att.net.il> wrote: > > At 11:01 AM 08-01-04 +0000, Michael.Dillon(a)radianz.com wrote: > > >People seem to be confused about the meaning of "critical infrastructure" > >so I decided to see what Google has to say. The first thing it comes up > >with is an American government organization called the Department for > >Homeland Security. On their question and answer page they say this: > >http://www.ciao.gov/publicaffairs/qsandas.htm > > > >1.) What is a critical infrastructure? > > > >The USA Patriot Act defines critical infrastructures as those > >"systems and assets, whether physical or virtual, so vital to the > >United States that the incapacity or destruction of such systems > >and assets would have a debilitating impact on security, national > >economic security, national public health or safety, or any > >combination of those matters." > > Why should Europe and the RIPE region care about what the US defines as > critical infrastructure? Because it is not only a US-centric view of the Internet. Most governments (at least the German which I know best and most other Europeans) have started to make their own definitions about what they define as critical to their national infrastructure. And they are asking questions how these infrastructure is protected. But I tend to agree that it is maybe better if we find a more neutral wording. Sabine > > > > > Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. > > > >Translated: There are lies, damned lies and RIPE-141 request forms. > > It is RIPE-219. RIPE-141 is dead. > > > >--Michael Dillon > > -Hank > > Viele Grüße Sabine Dolderer -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>> 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. It is best to clarify what resource we want to conserve. I don't think there is any need to conserve IPv4 addresses any more. Exponential growth is a think of the past and we have enough IPv4 addresses to last 10 to 20 years. We also have a replacement protocol, IPv6, that is already commercially deployed in Asia and in Europe. However, we might still want to conserve the number of entries in the global routing table because of the impact on router memory, router CPU and the time required to reload a full view of the Internet when a router is restarted. If we refuse to give DENIC a /24 from the recovered "Class C" swamp space we would be saving a small amount of IPv4 address space but we might not save any global routing table entries... --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>That's why I'm in favour to have a policy that permits allocations for >specific, well-defined Anycast services. That allocations would come >from a well-known block, so people would know to not filter /24s from >there (and so on). I agree that there should be a specific and well-defined policy. But I think that this policy does not need to be restricted to anycast services. It is a good thing to allocate only /24s and not any longer prefixes like /32 because there is no shortage of IPv4 address space and no need to conserve this space so severely. And I think that the well-known block used for this type of allocation should come from the old "Class C" swamp space. We have recovered lots of unused addresses from this area and we should begin to allocate them for special purposes which can benefit a large part of the community. --Michael Dillon

2 1

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michael.Dillon＠radianz.com 07 Jan '04

07 Jan '04

>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

3 2

RE: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Michel Py 07 Jan '04

07 Jan '04

> Gert Doering wrote: > (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"). Although the wording is a little strong, I would second this. The issue here is, then why not google, then why not me? Michel.

1 0

Change of Minumum IPv4 Allocation Size
by Filiz Yilmaz 23 Dec '03

23 Dec '03

Dear Colleagues, The final date for comments on the "Last Call" on the proposal to change the minimum IPv4 allocation size to /21 ended on 22 December 2003. There were no comments made therefore we will implement this policy change on 1 January 2004. Please note that there will be two changes. Firstly, the minimum IPv4 allocation size is /21. Secondly, it is no longer required to demonstrate efficient utilisation of a /22. Our supporting documentation and software will be updated as soon as possible. Please note that /21 allocations will only come from the 83.0.0.0/8 and 84.0.0.0/8 blocks. A full listing of the "Smallest RIPE NCC Allocation / Assignment Sizes" can be found at: http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html Kind regards, Filiz Yilmaz Snr. Hostmaster RIPE NCC

1 0

FORMAL PROPOSAL: change of initial PA allocation size
by Gert Doering 23 Dec '03

23 Dec '03

Hi, this was discussed on the list before the last RIPE meeting, and we had it on the address policy working group meeting (presented by me). I think we mostly have consensus on this issue, but I want to present it as a formal proposal, before it's incorporated into the policy. PROPOSAL: * the minimum initial allocation size (for new LIRs) is reduced from a /20, as of today, to a /21. (If a new LIR can demonstrate need for a bigger initial allocation, they can get a larger address block. This will not be changed). * the requirement to show an immediate need for 25% of the allocated address space is removed for the "minimum initial allocation" The motivation for that is that under the current policy, startup LIRs that do not already hold address space cannot get an initial PA allocation (which would be a /20 as of today, or bigger), because in many cases, they cannot demonstrate immediate need, or prior utilization of sufficient address space. To work around this, many startup LIRs use PI address space as a start, and when they have filled enough of this, apply for their own PA again. The problem with this is that in the end, it's very likely that more than one route will end up in the global BGP table (where one PA route would be sufficient), and also it encourages lying to the RIRs (PI space must not be distributed to third parties, i.e., LIR customers). The drawback of the changes are that it's potentially wasting address space for "very small LIRs" (that would be happy with a /23 PI space and will now get a "huge" /21). The wastage would only happen for very small LIRs that will never grow to fill the initial /21. A rough calculation shows that "1000 new LIR /21 allocations" would need a /11, which is not an unbearable strain on the conservation side, judging from the total number of LIRs in RIPE land today. A second drawback of this is that people may need to adapt their BGP filters to permit /21s from the network block(s) where these allocations are made from. So the RIPE NCC needs to document this accordingly, and ideally, well in advance. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57785 (56883) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

4 6