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

RE: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Daniel Monteith 13 Jan '04

13 Jan '04

/24 if only :) I believe currently its the LIR initial allocation boundary that's the minimum guaranteed not to be filtered. I would welcome a move by the ISP's (mainly a couple of tier 1's) to relax this so that BGP multihoming for the small people becomes easier and more efficient. I am sure we are getting to the stage when route table size is not so much of an issue anymore. Cheers Dan -----Original Message----- From: Andre Chapuis [mailto:chapuis@ip-plus.net] Sent: Monday, January 12, 2004 3:43 PM To: Daniel Karrenberg; address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Agreed, And what about defining an address-range where every ISP opens its filter up to /29 (as an example) ? This would deal with both anycast and address-space conservation. Let's show that we (as ISPs) are not bound to the /24 forever ! André At 10:23 12.01.2004, Daniel Karrenberg wrote: >This discussion is *not* about address policy, >it really is about ** routing policy! ** >The goal is to get prefixes propagated. >They could live in any odd part of the address space! > >Routing policy is made by ISPs. (period) > >In order to provide hints to ISPs making such policy I have previolusly >proposed a *registry* for "special" prefixes with some general >categories like: > > - root server > - TLD server > - second level name server > - internet search engine > - other important prefix (see remarks section ;-) > - .... > >Such a registry could be provided by the RIRs and used by the ISPs when >defining and implementing their routing policy. The art here is to >design the categories and to decide which ones can be policed. It is >easy to determine and to check regularly if a prefix contains name >servers for instance. Other categories should be "self-declaration". >ISPs can then decide if and how to use such a registry. > >Is this something that provides added value to ISPs? >Is it something that is useful for those using such prefixes? > >Daniel > > >PS: If getting any address space at all is a problem for these applications, >this needs to be addressed. Maybe it is already addressed by adjusting >the "initial" usage requirements back to "nil" or some reasonable low level and >reducing the initial allocation size. > >This is a different discussion which belongs here, but I do not reeally follow >it anymore, so pardon me if I just assume it is moving along. -------------------------------------------------------- Andre Chapuis IP+ Backbone Engineering AS3303 Swisscom Enterprise Solutions Ltd Genfergasse 14, CH-3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 --------------------------------------------------------

6 5

Re: allocations to critical infrastructure
by Michael.Dillon＠radianz.com 13 Jan '04

13 Jan '04

>They are, but they are not even using the amount of redundancy available >by DNS today (read: "as many name servers as fit into a minimum sized >UDP packet full of glue"). So there is hardly an argument for doing >anycast. I think that it is dangerous for a policy to force people to follow an evolutionary path when they implement technology. If it is considered "best practice" for a DNS infrastructure to use anycast then we should not penalize them because they jump there from a more primitive state. >The route servers use TCP, which will not work over anycast (in the >general case - consider load balancing, every other packet going to >a different destination machine. No problem for UDP, big problem >for TCP) It is also dangerous for a policy to punish people for evolving their technology. If it is considered "best practice" to use anycast to publish critical infrastructure databases then people should be able to change their services to enable them to use UDP and anycast. There are many ways in which a service could be adapted to anycast, even a session-based service. There are also non-anycast ways to solve this type of problem, such as peer-2-peer overlay networks, that could still benefit from having a well-known address range as a rendezvous point. I really don't think that the policy needs to be a close fit for a certain technical implementation. Instead it needs to express the basic principle which is a non-technical principle. Then it can provide a checklist which deal with technical questions. In the future if the technical implementations change, it will be easier to add or change checklist items if there is a solid principle underlying the policy. --Michael Dillon

2 1

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

12 Jan '04

>> 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. >Google is free for most users... Google is a business. If they want fault tolerance then they can buy it from Akamai or else build their own global infrastructure. If Google disappears, we can get similar service from many of their competitors. They aren't part of the infrastructure of the Internet. >> exist. But if DENIC ceases to exist, it is 100% certain that ICANN >> would find some other organization to continue offering .de nameservice. > What makes you so sure that DNS and/or ICANN will survive? LDAP is a well-proven robust and scalable directory services technology that is deployed at large organizations world-wide. But even though LDAP can do everything that DNS can do, there is no movement at all to replace DNS with LDAP and very few organizations run their DNS on top of backend LDAP servers. So DNS will survive for a long time. But if DNS would be replaced by LDAP, then I think DENIC would provide LDAP hosting for the .DE domain. And if DENIC does not survive, then ICANN would find someone else to provide LDAP services for .DE. But if ICANN does not survive, then its powers of allocating top level domains will pass to another organization, and this organization will make sure that there is somebody to host .DE. --Michael Dillon

8 8

Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Elmar K. Bins 12 Jan '04

12 Jan '04

chapuis(a)ip-plus.net (Andre Chapuis) wrote: > Agreed, > And what about defining an address-range where every ISP opens its filter up to /29 (as an example) ? This would deal with both anycast and address-space conservation. > Let's show that we (as ISPs) are not bound to the /24 forever ! Nice idea. You try convincing the Tier-1s (and -wannabes). I second this thought, but I deem it impractical, since the "big players" will be hard to convince to change their filtering boundaries. I believe, some answers will be in the style of "who's RIPE anyway?". Yours, Elmar. -- Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. (mlelstv, dcii 2003) -----------------------------------------------------------[ ELMI-RIPE ]---

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 12 Jan '04

12 Jan '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:1A00::/23 from the IANA in January 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Andreas Bäß/Denic 12 Jan '04

12 Jan '04

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

14 31

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

12 Jan '04

> >From my observation on this discussion there seem to be no other parties > >beside TLD operators that are currently so much interested in setting up > >anycast services. At least, nobody said so on this list. >Some DNSBL operators are definitely interested. DNS Black Lists are part of the crtitical email infrastructure. Someday a bogon routeserver service like this one: http://www.cymru.com/BGP/bogon-rs.html might want to use anycast. It is part of the critical routing infrastructure. It would be good for the policy to be based on the principle of supporting fault tolerance for critical infrastructure and then it can have a checklist of indicators like TLD operator, anycast implementation, freely available service and so on. It is a good idea to have a checklist that makes the policy easy to implement by the hostmasters, but it is also a good idea for the policy to have a clear foundation statement to cover anything that was not considered in the checklist. --Michael Dillon

2 1

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

09 Jan '04

>> Google is a business. If they want fault tolerance then they can >Ah, and VeriSign, or VRS, isn't? Or those DNS providers for ORG, INFO, LA, >AG, ...? Most of those registries have signed a Registry Data Escrow Agreement with ICANN and every day they update a copy of the domain registry data that is held by a 3rd party escrow agent. This is because they are operating a service on behalf of ICANN and if they go bakrupt or if they break their ICANN contract then ICANN can take the escrow copy of the data and get someone else to run the TLD registry. Verisign is a business, but the DNS and whois services that they provide are part of the Internet's infrastructure. There is no alternative place to get authoritative mapping of .com domain names to IP addresses or ownership data for a .com domain. In that sense Verisign has no competitors. >> buy it from Akamai or else build their own global infrastructure. >> If Google disappears, we can get similar service from many of their >> competitors. They aren't part of the infrastructure of the Internet. >But part of the economically critical infrastructure. And it's not the RIR's >job to decide whether they better buy the service or provide it themselves. >Sorry, this part of the discussion is heading absolutely nowhere. You're right, I don't know why you headed in that direction. RIPE is concerned with critical Internet infrastructure and not with critical economic infrastructure. --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

>The policy needs to balance everyones needs Yes. >(among that: "little extra routes in the DFZ"). DFZ (default free zone) = global routing table. If someone can implement a solution by announcing a shorter prefix from an existing netblock then there is nothing that RIPE can do to change the number of routes in the global routing table. >The policy does also need very clear-cut criteria to *decide* whether >something meets the policy or not. Applying technical criteria is easy >(easier, at least) than a fuzzy term like "critical infrastructure" >that mean something different to whoever reads it. Yes. And a good policy would start by defining the fuzzy term so that everyone understands the scope of the term when it is used in the policy. >Commenting on your first example: for the USA, something might very >well be a "critical infrastructure", like the US power grid, and *still* >the rest of the world might not care much if it breaks down... - so >the definition of "criticial infrastructure" is very much localized and >fuzzy. Yes. The word "critical" is a value judgement. Critical Internet Infrastructure is different from Critical National Infrastructure. In the USA they are focusing on infrastructure that is critical to their nation. We should look at infrastructure that is critical to the Internet, both globally and in the RIPE region. --Michael Dillon

2 1

Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure
by Hank Nussbacher 08 Jan '04

08 Jan '04

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? > > 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

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

>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 ... 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." That's not something very personal. It is something that is important to a large number of people. Here's another one: http://www.atis.org/tg2k/_critical_infrastructure.html critical infrastructure: 1. Elements of a system that are so vital that disabling any of them would incapacitate the entire system. Disabling .de would make the Internet unusable for millions of people in Germany and would affect millions of German-speaking people around the world. When some part of the infrastructure of the Internet is considered to be critical, the people responsible for it will build it so that it can never fail. They do this by applying fault tolerance techniques. Anycasting DNS is a fault tolerance technique. DENIC is asking for a policy that understands the need for fault tolerance when an organization is managing part of the Internet's critical infrastructure. If this policy focuses on the fault tolerance technique then it is doing the wrong things. Policies are not about technology. RIPE policies are political agreements that balance the needs of everyone in the RIPE community. This policy needs to focus on defining which kinds of "critical infrastructure" are important enough for the whole community to justify special allocations. > Es gibt Luegen, verdammte Luegen und RIPE-141(-219)-Netzantraege. Translated: There are lies, damned lies and RIPE-141 request forms. --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

>> 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

IANA Policies for Allocation of IPv4 Blocks to RIRs
by Axel Pawlik 15 Dec '03

15 Dec '03

Dear Colleagues, The Regional Internet Registries (RIRs) have been working together with the Internet Assigned Numbers Authority (IANA) on a policy for the allocation of IPv4 address space to the RIRs. The proposed policy was presented to the RIPE Address Policy Working Group at RIPE 46 in September. The presentation can be found at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-ap-iana-rir/ Following discussion in all four RIR regions, this policy proposal and discussion results will be forwarded to the ICANN ASO Address Council for review and submission to the ICANN Board. It is considered a global policy proposal. Please review the document "Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries". The document can be found at: http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html Comments on this proposal should be sent to this list. The review period is six weeks and will end on 16 November. A webcast recording of the entire RIPE Address Policy Working Group session can be found at: mms://webcast.ripe.net/ripe46/ap-1a.wmv mms://webcast.ripe.net/ripe46/ap-2a.wmv Kind regards, Axel

2 1

Re: [address-policy-wg] Fwd: selling ip:s? (kf)
by Michael.Dillon＠radianz.com 05 Dec '03

05 Dec '03

>IP addresses are clearly quite valuable, especially PI ones, not to mention >the "allocated unspecified" ones, for obvious reasons. However, the community >should definately do everything in it's power to make sure IP addresses are >not, under any circumstances, sold. We should also note that any value which may be attached to IPv4 addresses today will likely be significantly diluted as IPv6 is more widely deployed. Anyone who thinks that they will gain some advantage by paying for IPv4 addresses will be greatly disappointed when that advantage evaporates because of IPv6. Scarcity often increases the value of something so we should be quite clear that IPv6 addresses will be so abundant that any intrinsic scarcity value in IP addresses will disappear. I think that this point is important enough to be incorporated in a document regarding IPv4 addresses as a warning. There are already commercial IPv6 services available in Europe as well as several production networks used internally by research and development consortia. There is no doubt that IPv6 has matured and that the growth in the deployment of IPv6 will continue. All of this tends to reduce the pressure on the IPv4 address space and therefore reduces any intrinsic value of an IPv4 address. --Michael Dillon

2 1

RE: [address-policy-wg] Fwd: selling ip:s? (kf)
by Mike Norris 05 Dec '03

05 Dec '03

> why are we not allowed to sell ip address? i dont understand...please explain...thank you Quote from ripe-152: "By themselves, these resources have no intrinsic value; their worth is only realised in conjunction with the provision of Internet access. Thus, while registries may charge for their administrative and technical services, they may not charge for name space or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private. " See http://www.ripe.net/ripe/docs/ripe-152.html <http://www.ripe.net/ripe/docs/ripe-152.html> for the full document. Regards. Mike Norris

5 4

Fwd: selling ip:s? (kf)
by MEUZAK6＠aol.com 03 Dec '03

03 Dec '03

why are we not allowed to sell ip address? i dont understand...please explain...thank you

1 0