From baess at denic.de Wed Jan 7 16:15:11 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Wed, 7 Jan 2004 16:15:11 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Jan 7 16:35:06 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 16:35:06 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040107153506.GY30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Jan 7 16:58:51 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 16:58:51 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107154131.GB23046@nic.fr> References: <20040107153506.GY30954@Space.Net> <20040107154131.GB23046@nic.fr> Message-ID: <20040107155851.GZ30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From michel at arneill-py.sacramento.ca.us Wed Jan 7 17:02:45 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 7 Jan 2004 08:02:45 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: > 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. From cfriacas at fccn.pt Wed Jan 7 17:03:31 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 7 Jan 2004 16:03:31 +0000 (WET) Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: Hi, On Wed, 7 Jan 2004, Andreas B??/Denic wrote: > Technical justification for this policy > 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. 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!" From he at uninett.no Wed Jan 7 17:26:20 2004 From: he at uninett.no (Havard Eidnes) Date: Wed, 07 Jan 2004 17:26:20 +0100 (CET) Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040107.172620.08995640.he@uninett.no> > > 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 From gert at space.net Wed Jan 7 17:32:42 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 17:32:42 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107.172620.08995640.he@uninett.no> References: <20040107.172620.08995640.he@uninett.no> Message-ID: <20040107163242.GE30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Michael.Dillon at radianz.com Wed Jan 7 18:15:54 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 7 Jan 2004 17:15:54 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >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 From Michael.Dillon at radianz.com Wed Jan 7 18:29:15 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 7 Jan 2004 17:29:15 +0000 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >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. ICANN isn't special. They don't offer any infrastructure services. However, ARIN and RIPE maintain resgistry databases which are published in the form of a whois directory. This is part of the Internet infrastructure. DENIC hosts the .de top level domain and provides an authoritative DNS service. That is also part of the infrastructure. If an organization wants special treatment, first they have to show us that they operate a service that is a part of the Internet infrastructure. Then they have to show that this service is special enough to be called "critical". You are right that everyone forwards packets and that is not special enough. But what if someone operates a SIP network to carry VoIP calls for 112 (999) calls? Maybe that would make a part of their network into critical infrastructure. When making policy it is best to think ahead into the future a bit and make sure that they new policy will work for a few years, at least. --Michael Dillon From Michael.Dillon at radianz.com Wed Jan 7 18:36:38 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 7 Jan 2004 17:36:38 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >> 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 From niall.oreilly at ucd.ie Wed Jan 7 18:44:58 2004 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 07 Jan 2004 17:44:58 +0000 Subject: [address-policy-wg] considered dangerous In-Reply-To: References: Message-ID: <3661909E-4139-11D8-B986-000393DA759C@ucd.ie> I'ld like to wish all of you a Happy New Year, and to appeal to everyone to heed 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 From pekkas at netcore.fi Wed Jan 7 19:14:12 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 7 Jan 2004 20:14:12 +0200 (EET) Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107163242.GE30954@Space.Net> Message-ID: 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 From oppermann at pipeline.ch Wed Jan 7 19:20:13 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 07 Jan 2004 19:20:13 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allowallocations to critical infrastructure References: Message-ID: <3FFC4DDD.8FB2ED14@pipeline.ch> 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 From pekkas at netcore.fi Wed Jan 7 19:27:42 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 7 Jan 2004 20:27:42 +0200 (EET) Subject: [address-policy-wg] RIPE Access Policy Change Request to allowallocations to critical infrastructure In-Reply-To: <3FFC4DDD.8FB2ED14@pipeline.ch> Message-ID: 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 From gert at space.net Wed Jan 7 20:30:34 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 20:30:34 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <002501c3d53f$d3f32890$210d640a@unfix.org> References: <20040107163242.GE30954@Space.Net> <002501c3d53f$d3f32890$210d640a@unfix.org> Message-ID: <20040107193034.GI30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Jan 7 20:40:17 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 20:40:17 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040107194017.GJ30954@Space.Net> 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 From randy at psg.com Wed Jan 7 20:40:16 2004 From: randy at psg.com (Randy Bush) Date: Wed, 7 Jan 2004 11:40:16 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: > ICANN isn't special. They don't offer any infrastructure services. > However, ARIN and RIPE maintain resgistry databases which are > published in the form of a whois directory. as does icann. face it. everybody thinks what they are doing is special and what others are doing is less special. this is called the grazing of the commons. and, in this case, the grass is the routing table. because denic is so as to be unable to find an old unused swamp C, does not imply that global allocation policy needs to be changed. randy From gert at space.net Wed Jan 7 20:42:08 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 20:42:08 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <20040107163242.GE30954@Space.Net> Message-ID: <20040107194208.GK30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Jan 7 20:46:08 2004 From: gert at space.net (Gert Doering) Date: Wed, 7 Jan 2004 20:46:08 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040107194608.GL30954@Space.Net> Hi, On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote: > because denic is so as to be unable to find an old unused > swamp C, does not imply that global allocation policy needs to be > changed. I don't think this is the issue. They want to do Anycast, and want to do it in an official and documented way, so people can easily see what's going on, without resorting to "find a swamp C" network. 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). 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 From pekkas at netcore.fi Wed Jan 7 21:00:20 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 7 Jan 2004 22:00:20 +0200 (EET) Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: Message-ID: On Wed, 7 Jan 2004, Randy Bush wrote: > because denic is so as to be unable to find an old unused > swamp C, does not imply that global allocation policy needs to be > changed. mmm.. I wouldn't mind getting the anycast address for my co-lo box. easy provider - independence! :) but seriously .. IANA and the IETF have allocated these C blocks to some services (e.g. 192.88.99.0/24). They could do the same again if the _service_ would be *global* and well-defined enough. "Every ccTLD" is probably not. Which is why maybe just getting a /24 block somewhere if you want to do anycast for service FOO would be just about enough. You know, the administrative hoops you have to jump through to get a "golden" /24 shouldn't be fewer than those you have to jump through to get a regular /24.. else we'll be facing an uprise of "anycast" applications.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pk at TechFak.Uni-Bielefeld.DE Wed Jan 7 21:30:48 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 07 Jan 2004 21:30:48 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: Your message of "Wed, 07 Jan 2004 20:40:17 +0100." <20040107194017.GJ30954@Space.Net> Message-ID: <200401072030.i07KUnN18268@grimsvotn.TechFak.Uni-Bielefeld.DE> > 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 From kurtis at kurtis.pp.se Wed Jan 7 19:49:49 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 7 Jan 2004 19:49:49 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107163242.GE30954@Space.Net> Message-ID: <45264795-4142-11D8-A6A8-000A95928574@kurtis.pp.se> -----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----- From kurtis at kurtis.pp.se Wed Jan 7 19:49:49 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 7 Jan 2004 19:49:49 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107163242.GE30954@Space.Net> Message-ID: <45264795-4142-11D8-A6A8-000A95928574@kurtis.pp.se> -----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----- From bortzmeyer at nic.fr Wed Jan 7 16:41:31 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 7 Jan 2004 16:41:31 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107153506.GY30954@Space.Net> References: <20040107153506.GY30954@Space.Net> Message-ID: <20040107154131.GB23046@nic.fr> On Wed, Jan 07, 2004 at 04:35:06PM +0100, Gert Doering 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. From jeroen at sixxs.net Wed Jan 7 18:01:00 2004 From: jeroen at sixxs.net (Jeroen Massar) Date: Wed, 7 Jan 2004 18:01:00 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107163242.GE30954@Space.Net> Message-ID: <002501c3d53f$d3f32890$210d640a@unfix.org> -----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----- From Michael.Dillon at radianz.com Thu Jan 8 11:10:27 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 10:10:27 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >> 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 From gert at space.net Thu Jan 8 11:15:53 2004 From: gert at space.net (Gert Doering) Date: Thu, 8 Jan 2004 11:15:53 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040108100433.GA550@nic.fr> References: <20040107.172620.08995640.he@uninett.no> <20040107163242.GE30954@Space.Net> <20040108100433.GA550@nic.fr> Message-ID: <20040108101552.GV30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Michael.Dillon at radianz.com Thu Jan 8 11:18:39 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 10:18:39 +0000 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >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 From gert at space.net Thu Jan 8 11:17:45 2004 From: gert at space.net (Gert Doering) Date: Thu, 8 Jan 2004 11:17:45 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040108101745.GW30954@Space.Net> Hi, On Thu, Jan 08, 2004 at 10:10:27AM +0000, Michael.Dillon at radianz.com wrote: > >.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. In which case I claim that my PC at home is a highly critical infrastructure as well. The majority could care less, of course, but I agree with you that I don't care about the majority. Which drives home the point just fine :-) 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 From gert at space.net Thu Jan 8 11:19:35 2004 From: gert at space.net (Gert Doering) Date: Thu, 8 Jan 2004 11:19:35 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040108101935.GX30954@Space.Net> Hi, On Thu, Jan 08, 2004 at 10:18:39AM +0000, Michael.Dillon at radianz.com wrote: > >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. We don't *want* a "everybody that doesn't like the current policy can just get addresses under the execptional policy"-policy. A specific problem needs solving. Besides this, the current policy works well. 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 From ripe at detebe.org Thu Jan 8 11:26:21 2004 From: ripe at detebe.org (Elmar K. Bins) Date: Thu, 8 Jan 2004 11:26:21 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040108101552.GV30954@Space.Net> References: <20040107.172620.08995640.he@uninett.no> <20040107163242.GE30954@Space.Net> <20040108100433.GA550@nic.fr> <20040108101552.GV30954@Space.Net> Message-ID: <20040108102621.GA32105@new.detebe.org> gert at 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 ]--- From Michael.Dillon at radianz.com Thu Jan 8 11:32:40 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 10:32:40 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >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 From cfriacas at fccn.pt Thu Jan 8 11:31:38 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 8 Jan 2004 10:31:38 +0000 (WET) Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: On Wed, 7 Jan 2004 Michael.Dillon at radianz.com wrote: > >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. > > ICANN isn't special. They don't offer any infrastructure services. > > However, ARIN and RIPE maintain resgistry databases which are > published in the form of a whois directory. This is part of the > Internet infrastructure. DENIC hosts the .de top level domain > and provides an authoritative DNS service. That is also part > of the infrastructure. Agreed. Forgot to mention APNIC and LACNIC. RIR's databases are crucial for us "Internet wrench-guys"... > If an organization wants special treatment, first they have > to show us that they operate a service that is a part of the > Internet infrastructure. Then they have to show that this service > is special enough to be called "critical". Globally critical or Regionally critical? I think the scope of the "critical" part is an important issue... > You are right that everyone forwards packets and that is not > special enough. But what if someone operates a SIP network to > carry VoIP calls for 112 (999) calls? Maybe that would make a > part of their network into critical infrastructure. When making > policy it is best to think ahead into the future a bit and make > sure that they new policy will work for a few years, at least. > > --Michael Dillon > > 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!" From cfriacas at fccn.pt Thu Jan 8 11:34:30 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 8 Jan 2004 10:34:30 +0000 (WET) Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: On Wed, 7 Jan 2004 Michael.Dillon at radianz.com 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. > > 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. "IPv6 usage growth will also transform conservation of IPv4 in a non-issue." > Exponential growth is a think of the past and we have enough > IPv4 addresses to last 10 to 20 years. 100% Agree. I dont want IPv6 because the world is running out of addresses, i want IPv6 because IPv6 is better than IPv4. > We also have a replacement > protocol, IPv6, that is already commercially deployed in Asia > and in Europe. I usually tend to say: IPv6 is not a new protocol, it is a new protocol *version*... > 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... surely... > --Michael Dillon > > ./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!" From cfriacas at fccn.pt Thu Jan 8 11:37:36 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 8 Jan 2004 10:37:36 +0000 (WET) Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: 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!" From Michael.Dillon at radianz.com Thu Jan 8 12:01:09 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 11:01:09 +0000 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >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 From hank at att.net.il Thu Jan 8 12:10:04 2004 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 08 Jan 2004 13:10:04 +0200 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: Message-ID: <5.1.0.14.2.20040108130754.00ae73b8@max.att.net.il> At 11:01 AM 08-01-04 +0000, Michael.Dillon at 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 From Michael.Dillon at radianz.com Thu Jan 8 13:10:07 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 12:10:07 +0000 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >>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) From gert at space.net Thu Jan 8 13:24:39 2004 From: gert at space.net (Gert Doering) Date: Thu, 8 Jan 2004 13:24:39 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040108122439.GY30954@Space.Net> Hi, On Thu, Jan 08, 2004 at 11:01:09AM +0000, Michael.Dillon at radianz.com wrote: [..] > 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. The policy needs to balance everyones needs (among that: "little extra routes in the DFZ"). 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. 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. 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 From gert at space.net Thu Jan 8 13:28:15 2004 From: gert at space.net (Gert Doering) Date: Thu, 8 Jan 2004 13:28:15 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040108122815.GA30954@Space.Net> Hi, On Thu, Jan 08, 2004 at 10:32:40AM +0000, Michael.Dillon at radianz.com wrote: > 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. But with the same logic somewhere in the 22nd century we might not even be using DNS anymore... > 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. Google is free for most users... > 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. What makes you so sure that DNS and/or ICANN will survive? > 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. I second that. This is why I already wrote a draft of a few key elements that would enable the RIPE NCC to make *decisions* based on that policy. 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 From Michael.Dillon at radianz.com Thu Jan 8 13:45:01 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 12:45:01 +0000 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >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 From Michael.Dillon at radianz.com Thu Jan 8 14:06:38 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 13:06:38 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >> 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 From pk at TechFak.Uni-Bielefeld.DE Thu Jan 8 14:11:53 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 08 Jan 2004 14:11:53 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: Your message of "Thu, 08 Jan 2004 13:06:38 GMT." Message-ID: <200401081311.i08DBrb20228@grimsvotn.TechFak.Uni-Bielefeld.DE> > 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, ...? > 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. -Peter From Michael.Dillon at radianz.com Thu Jan 8 14:50:24 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 8 Jan 2004 13:50:24 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >> 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 From randy at psg.com Thu Jan 8 16:20:58 2004 From: randy at psg.com (Randy Bush) Date: Thu, 8 Jan 2004 07:20:58 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <20040107153506.GY30954@Space.Net> <20040107154131.GB23046@nic.fr> Message-ID: >> 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 From randy at psg.com Thu Jan 8 16:45:49 2004 From: randy at psg.com (Randy Bush) Date: Thu, 8 Jan 2004 07:45:49 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: > Google is a business. hint: so is denic From dr at cluenet.de Thu Jan 8 17:16:32 2004 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 8 Jan 2004 17:16:32 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: ; from randy@psg.com on Thu, Jan 08, 2004 at 07:45:49AM -0800 References: Message-ID: <20040108171632.A30614@homebase.cluenet.de> On Thu, Jan 08, 2004 at 07:45:49AM -0800, Randy Bush wrote: > > Google is a business. > > hint: so is denic Some might argue that DENIC is more like a lawyer's office with attached technical department. :-) Gruss, Daniel From jwkckid1 at ix.netcom.com Thu Jan 8 22:28:15 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 13:28:15 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <20040107153506.GY30954@Space.Net> <20040107154131.GB23046@nic.fr> Message-ID: <3FFDCB6F.6A55B7FA@ix.netcom.com> Stephane and all, Stephane Bortzmeyer wrote: > On Wed, Jan 07, 2004 at 04:35:06PM +0100, > Gert Doering 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 8 22:33:02 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 13:33:02 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: <3FFDCC8D.15EF75DB@ix.netcom.com> Michael and all, There is no such thing you call "tyranny of the majority", which has been a mantra of yours and some ICANN staff and BoD. Majority of stakeholders has always ruled or determined what policy and/or policies they want/desire. Michael.Dillon at radianz.com wrote: > >> 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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 8 22:39:41 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 13:39:41 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: <3FFDCE1D.CC2BFB33@ix.netcom.com> Michael and all, By the definitions you are attempting to quote, it would seem to me that many ISp's would fit as well as Google and other public/private services on the net provide or offer. > >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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 8 22:41:48 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 13:41:48 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <5.1.0.14.2.20040108130754.00ae73b8@max.att.net.il> Message-ID: <3FFDCE9B.3B8FB3F8@ix.netcom.com> Hank and all, Hank Nussbacher wrote: > At 11:01 AM 08-01-04 +0000, Michael.Dillon at 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 that same "Critical infrastructure" is critical to many/most europeans. > > > > > 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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 8 22:46:13 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 13:46:13 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: <3FFDCFA5.18192FBB@ix.netcom.com> Michael and all, Michael.Dillon at radianz.com wrote: > >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. Good! Your finnaly "getting it"! >:) > > > --Michael Dillon 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 8 23:01:07 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 14:01:07 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: <3FFDD323.331D9F4D@ix.netcom.com> Randy and all, Randy Bush wrote: > > Google is a business. > > hint: so is denic Good point! So is Apnic, ARIN, ICANN, LACNIC, AFNIC, ect, ect, ect... The distinction comes in that non-profit "Businesses" and for-profit businesses manage, to one degree or another, "Critical Infrastructure"... Hence how a policy can be crafted that adequately recognizes this fact will be "Critical" as to such a policy being successful and/or accepted.. 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From hpholen at tiscali.no Thu Jan 8 23:08:01 2004 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 8 Jan 2004 23:08:01 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107194608.GL30954@Space.Net> Message-ID: <3F795D8900048C30@cpfe3.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) |On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote: |> because denic is so as to be unable to find an old unused |> swamp C, does not imply that global allocation policy needs to be |> changed. | |I don't think this is the issue. They want to do Anycast, and |want to do it in an official and documented way, so people can |easily see what's going on, without resorting to "find a swamp |C" network. | |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). What should the cirteria to get "Anycast space" be ? From gert at space.net Thu Jan 8 23:19:56 2004 From: gert at space.net (Gert Doering) Date: Thu, 8 Jan 2004 23:19:56 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <3F795D8900048C30@cpfe3.be.tisc.dk> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> Message-ID: <20040108221956.GU30954@Space.Net> Hi, On Thu, Jan 08, 2004 at 11:08:01PM +0100, Hans Petter Holen wrote: > |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). > > What should the cirteria to get "Anycast space" be ? I had a proposal that nobody commented on :-) - it didn't mention "critical" anywhere, so maybe it wasn't sexy enough. I suggested: -------------------------- - 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") -------------------------- Now it's up to you people out there to come up with something better that a) solves the problem at hand (and not tries to solve everything else while at it - we're not going to save the world today, sorry) b) can be evaluated by a RIPE NCC hostmaster, so there must be clear and *easy* rules - it needs not be easy to get the space, but to say "you go - you don't" should be easy. Of course we could add something like - is accepted in a peer review (following this-and-that procedure) if that's what people want. 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 From bmanning at karoshi.com Thu Jan 8 23:39:00 2004 From: bmanning at karoshi.com (bill) Date: Thu, 8 Jan 2004 14:39:00 -0800 (PST) Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <3F795D8900048C30@cpfe3.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) from "Hans Petter Holen" at Jan 08, 2004 11:08:01 PM Message-ID: <200401082239.i08Md0t25014@karoshi.com> > > |On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote: > |> because denic is so as to be unable to find an old unused > |> swamp C, does not imply that global allocation policy needs to be > |> changed. > | > |I don't think this is the issue. They want to do Anycast, and > |want to do it in an official and documented way, so people can > |easily see what's going on, without resorting to "find a swamp > |C" network. > | > |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). > > What should the cirteria to get "Anycast space" be ? > well, if they are in a wellknown block (and w/o authenticated routing) then its pretty simple to hijack said prefix for local use. And perhaps more to the point, if everything is in said wkp, then blackholing the entire prefix makes installing local policy -dirt simple- ... as a blackhat, I would prefer to have every "critical infrastructure" component densely packed into a single prefix. YMMV of course. --bill From jwkckid1 at ix.netcom.com Fri Jan 9 02:59:57 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 08 Jan 2004 17:59:57 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: Message-ID: <3FFE0B1D.256A0B8A@ix.netcom.com> Michael and all, Michael.Dillon at radianz.com wrote: > >> 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. And let's not forget that ICANN's escrow policy and contract requirement is not legally enforceable, and TLD Registries know this all too well as few abide by it. > > > 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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From kurtis at kurtis.pp.se Fri Jan 9 08:34:11 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 9 Jan 2004 08:34:11 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040108221956.GU30954@Space.Net> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> Message-ID: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> |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). >> >> What should the cirteria to get "Anycast space" be ? > > I had a proposal that nobody commented on :-) - it didn't mention > "critical" anywhere, so maybe it wasn't sexy enough. > > I suggested: > -------------------------- > - 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") > -------------------------- I think this has the same problem as "critical infrastructure" in that you now need to define "benefits for the whole community". Second, with the definition above, if I am an ISP that decides to anycast my DNS-servers, do I get the "anycast space"? To be honest, I think you need to nail down what we are talking about. Maybe we will need a "Anycasted RIPE NCC Service Region TLD DNS-server space". > b) can be evaluated by a RIPE NCC hostmaster, so there must be clear > and *easy* rules - it needs not be easy to get the space, but to > say "you go - you don't" should be easy. I think that anycasting is a problem (been there, done that, waiting for the t-shirt) when it comes to getting address space. I am sure you can find a swamp C-block, as Randy suggested - BUT I do think there is a point in registering a block correctly and getting it in a legitimate way. Now, if what we are trying to solve is anycasting for TLD DNS-servers in the RIPE NCC Service region, why don't we just write that? If it turns out there is a problem of anycasting Goolge-servers in the region that is considered to be painful enough that we all think they should get special treatment, let's write that up then. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP/5ZdqarNKXTPFCVEQKcewCeMO17WmDzCOXaDARCnknpRLvxROcAoIS8 BYza7ha5BypTwxGGNfdbUDMQ =UZvo -----END PGP SIGNATURE----- From gert at space.net Fri Jan 9 11:44:45 2004 From: gert at space.net (Gert Doering) Date: Fri, 9 Jan 2004 11:44:45 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> Message-ID: <20040109104445.GD30954@Space.Net> Hi, On Fri, Jan 09, 2004 at 08:34:11AM +0100, Kurt Erik Lindqvist wrote: > I think this has the same problem as "critical infrastructure" in that > you now need to define "benefits for the whole community". I agree. > Second, with > the definition above, if I am an ISP that decides to anycast my > DNS-servers, do I get the "anycast space"? That's why there is a protocol limitation. If you're an ISP and already have 10 (!) distinct name servers in different PA blocks and different countries, and want to increase your resiliency further, this might be a viable approach. On the other hand, I've never seen anything delegated to more than 6 DNS servers - which can be done w/o anycast just fine. But I agree: we need to decide whether we *want* to permit that, and formulate the policy in accordance to that. > To be honest, I think you > need to nail down what we are talking about. Maybe we will need a > "Anycasted RIPE NCC Service Region TLD DNS-server space". "we" might need, indeed :) [..] > Now, if what we are trying to solve is anycasting for TLD > DNS-servers in the RIPE NCC Service region, why don't we just write > that? I would be fine with such a proposal. So it could look like this: Criteria: - Anycast - technical requirements (UDP record full) - ccTLD or gTLD operator Assignment: - /24 "status: ASSIGNED ANYCAST" out of well-known range - all anycast blocks (in RIPE land) come from the same range 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 From gert at space.net Fri Jan 9 11:57:33 2004 From: gert at space.net (Gert Doering) Date: Fri, 9 Jan 2004 11:57:33 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040109104445.GD30954@Space.Net> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040109104445.GD30954@Space.Net> Message-ID: <20040109105732.GF30954@Space.Net> Hi, On Fri, Jan 09, 2004 at 11:44:45AM +0100, Gert Doering wrote: > So it could look like this: > > Criteria: > - Anycast > - technical requirements (UDP record full) > - ccTLD or gTLD operator > > Assignment: > - /24 "status: ASSIGNED ANYCAST" out of well-known range > - all anycast blocks (in RIPE land) come from the same range People just pointed out to me that it's a "IPv4/IPv6 Policy", so the whole thing should be formulated accordingly. For IPv6, it could be done in analogy to the IPv6 root server policy. 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 From slz at baycix.de Fri Jan 9 12:15:20 2004 From: slz at baycix.de (Sascha Lenz) Date: Fri, 09 Jan 2004 12:15:20 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040109104445.GD30954@Space.Net> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040109104445.GD30954@Space.Net> Message-ID: <3FFE8D48.1090601@baycix.de> Hay, for starters: i must admit, that i didn't read all mails of this thread, because most sub-discussions are - IMHO - way off topic. So apologies if i missed something important. Gert Doering wrote: [...] >>Second, with >>the definition above, if I am an ISP that decides to anycast my >>DNS-servers, do I get the "anycast space"? > > > That's why there is a protocol limitation. If you're an ISP and already > have 10 (!) distinct name servers in different PA blocks and different > countries, and want to increase your resiliency further, this might > be a viable approach. > > On the other hand, I've never seen anything delegated to more than > 6 DNS servers - which can be done w/o anycast just fine. > > But I agree: we need to decide whether we *want* to permit that, and > formulate the policy in accordance to that. I don't really see why "we" want to restrict the usage of Address space for Anycast applications to some specific things like "i have too many nameservers, need to convert to anycast or my zone explodes!!" or something like that. My opinion is, that _if_ there's a distinct (IPv4)Anycast Policy, it should be rather open to new ideas. (Note: i don't really see the need for such a policy anyways, everyone was happy without it up to now. But since i do favour correct documentation in the whois database, i still like the idea somehow.) [...] > >>Now, if what we are trying to solve is anycasting for TLD >>DNS-servers in the RIPE NCC Service region, why don't we just write >>that? > > > I would be fine with such a proposal. > > So it could look like this: > > Criteria: > - Anycast > - technical requirements (UDP record full) > - ccTLD or gTLD operator Again, this probably prevents using IPv4 Address blocks for other anycast usage. I mean, what if I come up with a cool idea why i want to use anycast, probably i don't even request a new IPv4 block for that but use one of "my" blocks i already have and want to document it, e.g. with "ASSIGNED ANYCAST" - now i'm not allowed to do this? Will RIPE have to take away my net because i illegally use it for Anycast? What about if I use non-RIR assigned/allocated blocks (EARLY-REGISTRATION)? Or just what about if someone comes up with a new requirement for anycast on the list - do we have to discuss it another two months and again change the policy then? ==> I'd prefer more open "Criteria". We have no real IPv4 shortage, i don't see why we need to restrict this that much once again. RIPE hostmasters should be able to recognize a "good reason", even if there's no keyword in it they can check against a certain policy. > > Assignment: > - /24 "status: ASSIGNED ANYCAST" out of well-known range > - all anycast blocks (in RIPE land) come from the same range Since i like good documentation, i like this - i.e. i support this :-) Although - what about people using "old" Address space from a different range for Anycast? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From gert at space.net Fri Jan 9 13:00:13 2004 From: gert at space.net (Gert Doering) Date: Fri, 9 Jan 2004 13:00:13 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <3FFE8D48.1090601@baycix.de> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040109104445.GD30954@Space.Net> <3FFE8D48.1090601@baycix.de> Message-ID: <20040109120013.GQ30954@Space.Net> Hi, On Fri, Jan 09, 2004 at 12:15:20PM +0100, Sascha Lenz wrote: > ==> I'd prefer more open "Criteria". We have no real IPv4 shortage, > i don't see why we need to restrict this that much once again. > RIPE hostmasters should be able to recognize a "good reason", even > if there's no keyword in it they can check against a certain policy. It's not that easy. *If* they start "judging" requests, they also start asking lots of additional questions (to understand the background), and then people will again start complaining "the hostmasters are so annoying with all these questions! why do I need to send in an IPv6 network diagram, I just want addresses!"... This is why I'm aiming for a very specific "checklist". No doubts, no discussions. 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 From slz at baycix.de Fri Jan 9 15:49:28 2004 From: slz at baycix.de (Sascha Lenz) Date: Fri, 09 Jan 2004 15:49:28 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040109120013.GQ30954@Space.Net> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040109104445.GD30954@Space.Net> <3FFE8D48.1090601@baycix.de> <20040109120013.GQ30954@Space.Net> Message-ID: <3FFEBF78.9000009@baycix.de> Hay, Gert Doering wrote: > Hi, > > On Fri, Jan 09, 2004 at 12:15:20PM +0100, Sascha Lenz wrote: > >>==> I'd prefer more open "Criteria". We have no real IPv4 shortage, >> i don't see why we need to restrict this that much once again. >> RIPE hostmasters should be able to recognize a "good reason", even >> if there's no keyword in it they can check against a certain policy. > > > It's not that easy. *If* they start "judging" requests, they also start > asking lots of additional questions (to understand the background), and > then people will again start complaining "the hostmasters are so > annoying with all these questions! why do I need to send in an IPv6 > network diagram, I just want addresses!"... > > This is why I'm aiming for a very specific "checklist". No doubts, no > discussions. Maybe, but that might be overregulating things once again. I'd rather say, no nifty criteria at all then. Or probably similar to the Experiemental Allocation/Assignment policy, that people just have to show what they do with Anycast Services somewhere public, so everyone can see what kind of service it is or so. Or just "networks ASSIGNED ANYCAST have to be used as anycast addresses", i.e. they need to be announced from more than one location, similar to the ASN policy ("...you have to have at least two peers..."). The latter will prevent misuage in case people trying to get portable (unicast) addresses by abusing an open anycast policy. Still, why shouldn't I be able to announce my nets from multiple places and start anycast services for whatever reason i personally think i need to do this for? I can do this with my old nets, i also can just fake some PI-request for something different and use that than. A restrictive policy doesn't help much to get things documented here. The intention of the policy should be, that anycast services can be documented properly in first place - if I understood the initial request right. Since as we see out there in real life and some people noted during the discussion - you can _do_ anycast even without a new policy. It's just about "legalizing" it and getting the ability to document it. I don't see a reason, why this should be limited to certain "critical infrastructure" noone can agree upon what this should be in first place anyways. (Note: i'm talking only about IPv4 here for the moment since things in IPv6 are a) different and b) not even settled yet when it comes to IPv6 routing issues) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From bortzmeyer at nic.fr Thu Jan 8 10:11:46 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 8 Jan 2004 10:11:46 +0100 Subject: [address-policy-wg] Re: Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040108091146.GA32150@nic.fr> On Wed, Jan 07, 2004 at 11:40:16AM -0800, Randy Bush wrote a message of 15 lines which said: > because denic is so as to be unable to find an old unused > swamp C, They should have an old unused swamp C prefix? I thought they were supposed to have been sent back a long time ago :-) From bortzmeyer at nic.fr Thu Jan 8 10:58:16 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 8 Jan 2004 10:58:16 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <20040107163242.GE30954@Space.Net> Message-ID: <20040108095816.GA500@nic.fr> On Wed, Jan 07, 2004 at 08:14:12PM +0200, Pekka Savola 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. From bortzmeyer at nic.fr Thu Jan 8 11:04:33 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 8 Jan 2004 11:04:33 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107163242.GE30954@Space.Net> References: <20040107.172620.08995640.he@uninett.no> <20040107163242.GE30954@Space.Net> Message-ID: <20040108100433.GA550@nic.fr> On Wed, Jan 07, 2004 at 05:32:42PM +0100, Gert Doering 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"? From dolderer at denic.de Thu Jan 8 12:35:21 2004 From: dolderer at denic.de (Sabine Dolderer/Denic) Date: Thu, 8 Jan 2004 12:35:21 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: On 08.01.2004 12:10 Hank Nussbacher wrote: > > At 11:01 AM 08-01-04 +0000, Michael.Dillon at 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 at denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 From randy at psg.com Fri Jan 9 17:21:48 2004 From: randy at psg.com (Randy Bush) Date: Fri, 9 Jan 2004 08:21:48 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <20040107163242.GE30954@Space.Net> <20040108095816.GA500@nic.fr> Message-ID: > 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 From jwkckid1 at ix.netcom.com Sat Jan 10 03:37:53 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Fri, 09 Jan 2004 18:37:53 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040109104445.GD30954@Space.Net> <3FFE8D48.1090601@baycix.de> <20040109120013.GQ30954@Space.Net> Message-ID: <3FFF6580.7BC0242B@ix.netcom.com> Gert and all, Judging requests is not necessarily a bad thing, but doing so can quickly become a very bad thing unless there is a set of procedures and/or policies that are enforceable and will dictate the limitations and specifics of such judgments. Gert Doering wrote: > Hi, > > On Fri, Jan 09, 2004 at 12:15:20PM +0100, Sascha Lenz wrote: > > ==> I'd prefer more open "Criteria". We have no real IPv4 shortage, > > i don't see why we need to restrict this that much once again. > > RIPE hostmasters should be able to recognize a "good reason", even > > if there's no keyword in it they can check against a certain policy. > > It's not that easy. *If* they start "judging" requests, they also start > asking lots of additional questions (to understand the background), and > then people will again start complaining "the hostmasters are so > annoying with all these questions! why do I need to send in an IPv6 > network diagram, I just want addresses!"... > > This is why I'm aiming for a very specific "checklist". No doubts, no > discussions. > > 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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Sat Jan 10 03:41:48 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Fri, 09 Jan 2004 18:41:48 -0800 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <20040107163242.GE30954@Space.Net> <20040108095816.GA500@nic.fr> Message-ID: <3FFF666C.53B79600@ix.netcom.com> 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From baess at denic.de Sat Jan 10 14:02:38 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Sat, 10 Jan 2004 14:02:38 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> Message-ID: >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. > Now, if what we are trying to solve is anycasting for TLD > DNS-servers in the RIPE NCC Service region, why don't we just write > that? Asuming that Curtis is hiding his sympathy to allow TLD operators to get IPv4/v6 address space for the operation of anycast services I second that idea. Lets add anycast TLD nameservice to the list of accepted exceptions. > If it turns out there is a problem of anycasting Goolge-servers > in the region that is considered to be painful enough that we all think > they should get special treatment, let's write that up then. It seems to be much easier and practical to add allowances to a list of exceptions than finding an accepted term and criteria that defines an open future path for applications that automatically qualify for this rule. Have a nice weekend Andreas -- DENIC eG Wiesenh?ttenplatz 26 D-60329 Frankfurt From baess at denic.de Sat Jan 10 14:33:08 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Sat, 10 Jan 2004 14:33:08 +0100 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040107193034.GI30954@Space.Net> Message-ID: 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 From slz at baycix.de Sat Jan 10 14:52:27 2004 From: slz at baycix.de (Sascha Lenz) Date: Sat, 10 Jan 2004 14:52:27 +0100 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <4000039B.4050103@baycix.de> 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 at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From md at Linux.IT Sat Jan 10 15:53:15 2004 From: md at Linux.IT (Marco d'Itri) Date: Sat, 10 Jan 2004 15:53:15 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> Message-ID: <20040110145315.GA5806@wonderland.linux.it> On Jan 10, Andreas B??/Denic wrote: >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. -- ciao, | Marco | [4018 ripaTaONbBKuo] From randy at psg.com Sat Jan 10 16:53:33 2004 From: randy at psg.com (Randy Bush) Date: Sat, 10 Jan 2004 07:53:33 -0800 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> Message-ID: > 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. i have deployed non-dns anycast services a number of times in the last decade. next. randy From randy at psg.com Sat Jan 10 16:55:44 2004 From: randy at psg.com (Randy Bush) Date: Sat, 10 Jan 2004 07:55:44 -0800 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <4000039B.4050103@baycix.de> Message-ID: > - 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 From slz at baycix.de Sat Jan 10 17:12:01 2004 From: slz at baycix.de (Sascha Lenz) Date: Sat, 10 Jan 2004 17:12:01 +0100 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <4000039B.4050103@baycix.de> Message-ID: <40002451.3000300@baycix.de> 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 at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From gert at space.net Sat Jan 10 17:22:10 2004 From: gert at space.net (Gert Doering) Date: Sat, 10 Jan 2004 17:22:10 +0100 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <4000039B.4050103@baycix.de> Message-ID: <20040110162210.GH30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Sat Jan 10 17:23:08 2004 From: gert at space.net (Gert Doering) Date: Sat, 10 Jan 2004 17:23:08 +0100 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <40002451.3000300@baycix.de> References: <4000039B.4050103@baycix.de> <40002451.3000300@baycix.de> Message-ID: <20040110162308.GI30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Sat Jan 10 17:25:31 2004 From: gert at space.net (Gert Doering) Date: Sat, 10 Jan 2004 17:25:31 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> Message-ID: <20040110162531.GJ30954@Space.Net> Hi, On Sat, Jan 10, 2004 at 07:53:33AM -0800, Randy Bush wrote: > > 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. > > i have deployed non-dns anycast services a number of times in the last > decade. next. In case you didn't notice, the internet grew somewhat over the last decade. Add to that the addition of v6 glue to some xTLD name server sets and you get a conflict between the number of DNS servers that you want to deploy, and the number of glue records that fit into the packets. 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 From randy at psg.com Sat Jan 10 17:36:32 2004 From: randy at psg.com (Randy Bush) Date: Sat, 10 Jan 2004 08:36:32 -0800 Subject: Antwort: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <4000039B.4050103@baycix.de> <20040110162210.GH30954@Space.Net> Message-ID: >> 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. From jwkckid1 at ix.netcom.com Sun Jan 11 03:49:27 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sat, 10 Jan 2004 18:49:27 -0800 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040110162531.GJ30954@Space.Net> Message-ID: <4000B9B6.ABD43EDA@ix.netcom.com> Gert and all, Gert Doering wrote: > Hi, > > On Sat, Jan 10, 2004 at 07:53:33AM -0800, Randy Bush wrote: > > > 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. > > > > i have deployed non-dns anycast services a number of times in the last > > decade. next. > > In case you didn't notice, the internet grew somewhat over the last > decade. Many have commented and question in the past if Randy has taken such notice you are refrencing. > > > Add to that the addition of v6 glue to some xTLD name server sets and > you get a conflict between the number of DNS servers that you want > to deploy, and the number of glue records that fit into the packets. > > 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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From kurtis at kurtis.pp.se Sun Jan 11 15:28:41 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 11 Jan 2004 15:28:41 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040109104445.GD30954@Space.Net> References: <20040107194608.GL30954@Space.Net> <3F795D8900048C30@cpfe3.be.tisc.dk> <20040108221956.GU30954@Space.Net> <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> <20040109104445.GD30954@Space.Net> Message-ID: <73F9BA98-4442-11D8-8B02-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Second, with >> the definition above, if I am an ISP that decides to anycast my >> DNS-servers, do I get the "anycast space"? > > That's why there is a protocol limitation. If you're an ISP and > already > have 10 (!) distinct name servers in different PA blocks and different > countries, and want to increase your resiliency further, this might > be a viable approach. ok, agreed. >> Now, if what we are trying to solve is anycasting for TLD >> DNS-servers in the RIPE NCC Service region, why don't we just write >> that? > > I would be fine with such a proposal. > > So it could look like this: > > Criteria: > - Anycast > - technical requirements (UDP record full) > - ccTLD or gTLD operator > > Assignment: > - /24 "status: ASSIGNED ANYCAST" out of well-known range > - all anycast blocks (in RIPE land) come from the same range fine with me. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAFdoKarNKXTPFCVEQJ/7wCcD6QXvKQE7y91vn7c1Gb05LzzxEIAnjDb FdIBVIIPHw4ntZjCmaMgL5xk =I+4g -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Sun Jan 11 15:31:00 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 11 Jan 2004 15:31:00 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <37E07256-4276-11D8-B548-000A95928574@kurtis.pp.se> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randy, On 2004-01-10, at 16.53, Randy Bush wrote: >> 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. > > i have deployed non-dns anycast services a number of times in the last > decade. next. the problem is that you then apparently had access to routable space. Which not everyone has today. It's been done for other services, and it has been done for DNS for a long time. And yes, we should find a solution for other people wanting to do anycast as well. But in most cases, I suspect that they already have access to other sources of address space. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAFeJqarNKXTPFCVEQIxvgCeJv/Va6Z4pT2yTRoZ+GiFl/jdDOoAoItg RJkPms5IeZ8f1RjExHP4XyIR =as3W -----END PGP SIGNATURE----- From hpholen at tiscali.no Mon Jan 12 09:10:24 2004 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 12 Jan 2004 09:10:24 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040108221956.GU30954@Space.Net> Message-ID: <3F796D8300049988@cpfe7.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) |I suggested: |-------------------------- | - Anycast deployment OK - I want to do anycast for my server - so I qualify. | - multiple distributed servers bring benefits for the whole community so - I need more than one server to do this, that is slikgltyl limiting ths from beeing available to everybody. How is "bring benefits for the whole community" different from "critical infrastructure" ? I agree the first is a slightly better definition, but how do we measure this criteria ? Or is it a judgemental criteria to be evaluated by the RIPE NCC ? | - due to protocol limitations this cannot be done using other approaches so you will have an argument on wether the mecahnisms in the DNS protocol are good enouugh to create redundancy. | (like "put up 100 servers at various ISP networks, using PA |space from | those ISPs") Is that to be interpreted as a fixed number ? That would make it more difficult to apply this in a smaller country like Norway (where do I find ISP % 95...) that in for instance germany ? -hph From daniel.karrenberg at ripe.net Mon Jan 12 10:23:30 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 12 Jan 2004 10:23:30 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <200401081311.i08DBrb20228@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200401081311.i08DBrb20228@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040112092329.GC4076@reifa.local> 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. From Michael.Dillon at radianz.com Mon Jan 12 11:09:04 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 12 Jan 2004 10:09:04 +0000 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: > >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 From gert at space.net Mon Jan 12 11:17:28 2004 From: gert at space.net (Gert Doering) Date: Mon, 12 Jan 2004 11:17:28 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040112101728.GY30954@Space.Net> Hi, On Mon, Jan 12, 2004 at 10:09:04AM +0000, Michael.Dillon at radianz.com wrote: > > >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. 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. > Someday a bogon routeserver service like this one: > http://www.cymru.com/BGP/bogon-rs.html > might want to use anycast. 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) 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 From gert at space.net Mon Jan 12 11:37:45 2004 From: gert at space.net (Gert Doering) Date: Mon, 12 Jan 2004 11:37:45 +0100 Subject: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <3F796D8300049988@cpfe7.be.tisc.dk> References: <20040108221956.GU30954@Space.Net> <3F796D8300049988@cpfe7.be.tisc.dk> Message-ID: <20040112103745.GA30954@Space.Net> Hi, On Mon, Jan 12, 2004 at 09:10:24AM +0100, Hans Petter Holen wrote: > | (like "put up 100 servers at various ISP networks, using PA > |space from those ISPs") > > Is that to be interpreted as a fixed number ? > That would make it more difficult to apply this in a smaller country like > Norway (where do I find ISP % 95...) that in for instance germany ? You're not supposed to have all servers in the same country...! (But anyway: I agree that it's difficult to specify the criteria. So I'd appreciate if someone else would actually come up with specific suggestions, instead of only discussing why the stuff we already have isn't going to work). 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 From Michael.Dillon at radianz.com Mon Jan 12 11:54:04 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 12 Jan 2004 10:54:04 +0000 Subject: [address-policy-wg] Re: allocations to critical infrastructure Message-ID: >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 From leo at ripe.net Mon Jan 12 15:14:52 2004 From: leo at ripe.net (leo vegoda) Date: Mon, 12 Jan 2004 15:14:52 +0100 Subject: [address-policy-wg] New IPv6 Address Block Allocated to RIPE NCC Message-ID: <20040112141452.GA18304@ripe.net> 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: Regards, -- leo vegoda Registration Services Manager RIPE NCC From bortzmeyer at nic.fr Mon Jan 12 13:59:27 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 12 Jan 2004 13:59:27 +0100 Subject: [address-policy-wg] Re: Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <20040107163242.GE30954@Space.Net> <20040108095816.GA500@nic.fr> Message-ID: <20040112125927.GA6015@nic.fr> On Fri, Jan 09, 2004 at 08:21:48AM -0800, Randy Bush 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? From chapuis at ip-plus.net Mon Jan 12 16:43:04 2004 From: chapuis at ip-plus.net (Andre Chapuis) Date: Mon, 12 Jan 2004 16:43:04 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040112092329.GC4076@reifa.local> References: <200401081311.i08DBrb20228@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040112092329.GC4076@reifa.local> Message-ID: <6.0.1.1.2.20040112163813.04a5f008@localhost:1143> 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 at ip-plus.net CCIE #6023 -------------------------------------------------------- From ripe at detebe.org Mon Jan 12 16:48:37 2004 From: ripe at detebe.org (Elmar K. Bins) Date: Mon, 12 Jan 2004 16:48:37 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <6.0.1.1.2.20040112163813.04a5f008@localhost:1143> References: <200401081311.i08DBrb20228@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040112092329.GC4076@reifa.local> <6.0.1.1.2.20040112163813.04a5f008@localhost:1143> Message-ID: <20040112154836.GF85279@new.detebe.org> chapuis at 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 ]--- From DanielMo at InterXion.com Mon Jan 12 16:56:25 2004 From: DanielMo at InterXion.com (Daniel Monteith) Date: Mon, 12 Jan 2004 15:56:25 -0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> /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 at ip-plus.net] Sent: Monday, January 12, 2004 3:43 PM To: Daniel Karrenberg; address-policy-wg at 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 at ip-plus.net CCIE #6023 -------------------------------------------------------- From gert at space.net Mon Jan 12 17:35:08 2004 From: gert at space.net (Gert Doering) Date: Mon, 12 Jan 2004 17:35:08 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> References: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> Message-ID: <20040112163507.GN30954@Space.Net> Hi, On Mon, Jan 12, 2004 at 03:56:25PM -0000, Daniel Monteith wrote: > I am sure we are getting to the stage when route table size is not so much of an issue anymore. Routing table size is more an issue than ever. 129k prefixes, LOTS of useless garbage, and still growing. 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 From randy at psg.com Mon Jan 12 17:40:09 2004 From: randy at psg.com (Randy Bush) Date: Mon, 12 Jan 2004 08:40:09 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> Message-ID: > /24 if only heck, why not /32? > I am sure we are getting to the stage when route table size is not so much > of an issue anymore. why are you sure, and for what values of "we"? randy, who is sad to be old enough that he's not sure of anything From chapuis at ip-plus.net Mon Jan 12 17:41:03 2004 From: chapuis at ip-plus.net (Andre Chapuis) Date: Mon, 12 Jan 2004 17:41:03 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040112163507.GN30954@Space.Net> References: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> <20040112163507.GN30954@Space.Net> Message-ID: <6.0.1.1.2.20040112173829.08fdb088@localhost:1143> Agreed Gert, but we have about 65K by filtering on minalloc sizes ... Andr? At 17:35 12.01.2004, Gert Doering wrote: >Hi, > >On Mon, Jan 12, 2004 at 03:56:25PM -0000, Daniel Monteith wrote: >> I am sure we are getting to the stage when route table size is not so much of an issue anymore. > >Routing table size is more an issue than ever. > >129k prefixes, LOTS of useless garbage, and still growing. > >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 -------------------------------------------------------- Andre Chapuis IP+ Backbone Engineering AS3303 Swisscom Enterprise Solutions Ltd Genfergasse 14, CH-3050 Bern +41 31 893 89 61 chapuis at ip-plus.net CCIE #6023 -------------------------------------------------------- From jorgen at hovland.cx Mon Jan 12 18:55:01 2004 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 12 Jan 2004 17:55:01 -0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> Message-ID: <002f01c3d935$33df9290$8818c389@macs.hw.ac.uk> ----- Original Message ----- From: "Randy Bush" To: "Daniel Monteith" Cc: Sent: Monday, January 12, 2004 4:40 PM Subject: RE: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure > > /24 if only > > heck, why not /32? > Filtering on /32 shouldn't be a huge problem. I count 4 294 967 296 /32's. That's the upper limit and it's really not that much. If we did permit /32's, a router could for instance aggregate incoming chunks of matching netblocks into fewer ones in order to decrease workload and memory usage etc... Without thinking too hard, this number is also the same if we filter on /32 with IPv6. But we are talking about filtering on /48 these days so that's a bigger challenge. Permitting /32 would atleast solve the problem with anycast. Joergen Hovland From hpholen at tiscali.no Mon Jan 12 21:47:27 2004 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 12 Jan 2004 21:47:27 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040112092329.GC4076@reifa.local> References: <200401081311.i08DBrb20228@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040112092329.GC4076@reifa.local> Message-ID: <9957078.1073944047@cq.oslo.net> --On 12. januar 2004 10:23 +0100 Daniel Karrenberg wrote: > > This discussion is *not* about address policy, > it really is about ** routing policy! ** This is actually a very good point, I personally support this view. Thanks for pointing this out. Hans Petter From dr at cluenet.de Mon Jan 12 22:17:39 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 12 Jan 2004 22:17:39 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <9957078.1073944047@cq.oslo.net>; from hpholen@tiscali.no on Mon, Jan 12, 2004 at 09:47:27PM +0100 References: <20040112092329.GC4076@reifa.local> <9957078.1073944047@cq.oslo.net> Message-ID: <20040112221739.A2155@homebase.cluenet.de> On Mon, Jan 12, 2004 at 09:47:27PM +0100, Hans Petter Holen wrote: > --On 12. januar 2004 10:23 +0100 Daniel Karrenberg > wrote: > > This discussion is *not* about address policy, > > it really is about ** routing policy! ** > > This is actually a very good point, I personally support this view. So we should discuss things in routing-wg, and if we come to the conclusion that we like to see some special IP block to make "special" anycast assignments from, come back to address-policy-wg, right? Regards, Daniel From jwkckid1 at ix.netcom.com Tue Jan 13 02:45:36 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 12 Jan 2004 17:45:36 -0800 Subject: [address-policy-wg] Re: allocations to critical infrastructure References: Message-ID: <40034DBF.6A0E32BC@ix.netcom.com> Michael and all, Michael, this argument/debate has been hashed before on other forums, as you know because you were a participant. I see that your arguments favoring including "Anycast" in a "Best practices" document as part of a routing policy have not changed. However such arguments do not appear to yet again carry sufficient justification to be wise or even "Doable" in a practical sense. Hence leaving again such a policy as you espouse to be considered close to reasonable... Michael.Dillon at radianz.com wrote: > >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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Tue Jan 13 03:03:11 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 12 Jan 2004 18:03:11 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <5605524A6CD2BC499B3272B47B97028FE3484A@uk-lon-01.office.interxion.net> Message-ID: <400351DE.7F869421@ix.netcom.com> Randy and all, Randy Bush wrote: > > /24 if only > > heck, why not /32? > > > I am sure we are getting to the stage when route table size is not so much > > of an issue anymore. > > why are you sure, and for what values of "we"? > > randy, who is sad to be old enough that he's not sure of anything I am sure as aging is a debilitating all of us will eventually face it's ravages, you will be wise enough to seriously consider retirement. Soon perhaps? 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From baess at denic.de Tue Jan 13 20:55:44 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Tue, 13 Jan 2004 20:55:44 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040112103745.GA30954@Space.Net> Message-ID: > On Mon, Jan 12, 2004 at 09:10:24AM +0100, Hans Petter Holen wrote: > > | (like "put up 100 servers at various ISP networks, using PA > > |space from those ISPs") > > > > Is that to be interpreted as a fixed number ? > > That would make it more difficult to apply this in a smaller country like > > Norway (where do I find ISP % 95...) that in for instance germany ? > > You're not supposed to have all servers in the same country...! > > (But anyway: I agree that it's difficult to specify the criteria. As far as I have followed the discussion there seems to be a favour to grant TLD operators permission to get resources to operate an anycast DNS. >From my point of view it does not make sense to add any additional threshold like number of instances or worldwide distribution as it is the decision of the registry where it starts the rollout and how fast and how many servers he would like to have totally to fullfill the registries SLAs for their query load. > So I'd appreciate if someone else would actually come up with specific > suggestions, instead of only discussing why the stuff we already have > isn't going to work). So my suggestion is to allow the allocation of a single /24 IPv4 and a /32 IPv6 address block to TLD operators who want to operate an anycast DNS service for their TLD. If they don't provide this service within a year or stop the service after starting it, they have to return the allocations. As this allocation will be multihomed be nature with it's own routing policy they also qualify for a distinct AS number to define this routing policy. When the service terminates the reouting policy does no longer exist and naturally they have to return this resource as well. Andreas -- DENIC eG Wiesenh?ttenplatz 26 D-60329 Frankfurt From gert at space.net Tue Jan 13 22:15:49 2004 From: gert at space.net (Gert Doering) Date: Tue, 13 Jan 2004 22:15:49 +0100 Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <20040112103745.GA30954@Space.Net> Message-ID: <20040113211549.GS30954@Space.Net> Hi, uh, sorry, this mail was *NOT* supposed to go to the APWG mailing list. I bounced it (assuming a CC: was lost) but the whole thing "escaped" prematurely. Please *ignore* this e-mail. gert, who will have to buy Andreas a beer in Amsterdam :-o On Tue, Jan 13, 2004 at 08:55:44PM +0100, Andreas B??/Denic wrote: > From: Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?= > To: Gert Doering > Subject: Antwort: Re: [address-policy-wg] Re: RIPE Access Policy Change Request to > allow allocations to critical infrastructure > Message-ID: > Resent-From: gert at Space.Net > Resent-Date: Tue, 13 Jan 2004 22:11:51 +0100 > Resent-To: address-policy-wg at ripe.net > On Mon, Jan 12, 2004 at 09:10:24AM +0100, Hans Petter Holen wrote: > > | (like "put up 100 servers at various ISP networks, using PA=20 > > |space from those ISPs") > >=20 > > Is that to be interpreted as a fixed number ? > > That would make it more difficult to apply this in a smaller country=20 [..] -- 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 From gert at space.net Wed Jan 14 17:17:00 2004 From: gert at space.net (Gert Doering) Date: Wed, 14 Jan 2004 17:17:00 +0100 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: <3FE8AD4A.D6FB5F3D@ix.netcom.com> References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> Message-ID: <20040114161700.GM30954@Space.Net> Hi, On Tue, Dec 23, 2003 at 01:02:03PM -0800, Jeff Williams wrote: > Hans and all, > > You are mistaken Hans. It would benefit you and everyone here > if you would track Apnic a little closer... Why? We are not APNIC, we are RIPE, and we only make RIPE policies. So if we send out a formal proposal to change RIPE things to RIPE lists, and nobody from the RIPE community objects - what's wrong with assuming consensus, then? 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 From randy at psg.com Wed Jan 14 17:25:58 2004 From: randy at psg.com (Randy Bush) Date: Wed, 14 Jan 2004 08:25:58 -0800 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> Message-ID: > So if we send out a formal proposal to change RIPE things to RIPE > lists, and nobody from the RIPE community objects - what's wrong > with assuming consensus, then? maybe because we have not yet implemented that packets and routing information stay only within the ripe region? it's the global internet we're affecting. think locally, act globally -- motto of the small view polluter randy From gert at space.net Wed Jan 14 17:40:47 2004 From: gert at space.net (Gert Doering) Date: Wed, 14 Jan 2004 17:40:47 +0100 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> Message-ID: <20040114164047.GO30954@Space.Net> Hi, On Wed, Jan 14, 2004 at 08:25:58AM -0800, Randy Bush wrote: > > So if we send out a formal proposal to change RIPE things to RIPE > > lists, and nobody from the RIPE community objects - what's wrong > > with assuming consensus, then? > > maybe because we have not yet implemented that packets and routing > information stay only within the ripe region? it's the global > internet we're affecting. As the global routing information *does* affect ourselves as well, you can be assured that we won't (all) loose that aspect out of focus. The policy change in question had *exactly* this in mind: avoid people going for 2 or more PI prefixes just because they were not allowed to get *one* PA allocation. So please: constructive criticism is welcome, but things like "all that you do is wrong, because APNIC is doing something!" (and no further reason or detail given) are just wasting our time. 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 From randy at psg.com Wed Jan 14 17:46:56 2004 From: randy at psg.com (Randy Bush) Date: Wed, 14 Jan 2004 08:46:56 -0800 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> <20040114164047.GO30954@Space.Net> Message-ID: > So please: constructive criticism is welcome, but things like > "all that you do is wrong, because APNIC is doing something!" > (and no further reason or detail given) are just wasting our > time. excuse! where did i say that? please do not put stupid words into my keyboard, i do that well enough. i merely responded to what i considered an unwise statement which sets an incorrect atmosphere and could become a quoted precident set by a co-chair of this wg. >>> So if we send out a formal proposal to change RIPE things to >>> RIPE lists, and nobody from the RIPE community objects - what's >>> wrong with assuming consensus, then? i still consider this unwise, and for the reasons i stated. and, in the face of such statements, i do not consider pointing out that we are making, or proposing to make, policy that affects the global internet a waste of time. if you feel it wastes yours, you have a delete key. randy From hpholen at tiscali.no Wed Jan 14 17:56:40 2004 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 14 Jan 2004 17:56:40 +0100 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: Message-ID: <3FE68A3100020366@cpfe0.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) Could somebody summarize what the APNIC objections to changed policy are ? -hph |> So if we send out a formal proposal to change RIPE things to RIPE |> lists, and nobody from the RIPE community objects - what's |wrong with |> assuming consensus, then? | |maybe because we have not yet implemented that packets and |routing information stay only within the ripe region? it's |the global internet we're affecting. | |think locally, act globally | -- motto of the small view polluter | |randy | From Michael.Dillon at radianz.com Wed Jan 14 18:13:54 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 14 Jan 2004 17:13:54 +0000 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size Message-ID: >> So please: constructive criticism is welcome, but things like >> "all that you do is wrong, because APNIC is doing something!" >> (and no further reason or detail given) are just wasting our >> time. >excuse! where did i say that? please do not put stupid words into >my keyboard, i do that well enough. I suppose Randy has a killfile that discards messages from j-e-f-f w-i-l-l-i-a-m-s so he didn't realize that Gert was replying to one of Jeff's messages to the list. >>> So if we send out a formal proposal to change RIPE things to >>> RIPE lists, and nobody from the RIPE community objects - what's >>> wrong with assuming consensus, then? >i still consider this unwise, and for the reasons i stated. and, >in the face of such statements, i do not consider pointing out that >we are making, or proposing to make, policy that affects the global >internet a waste of time. I agree with Randy here. The regional boundaries are very fuzzy. The Internet routes across these boundaries as if they were not there. Many companies operate networks in more than one region. I was born in the ARIN region, now I live in the RIPE region and I work for a company whose network spans ARIN, RIPE and APNIC regions. Consensus on a RIPE mailing list could be a way to ignore what is happening in other regions and it could be a way to lock out other people in the RIPE region who haven't thought of looking at the mailing list. I know that the IETF uses mailing list consensus very successfully but the IETF is doing a very different job from RIPE. --Michael Dillon From gert at space.net Wed Jan 14 18:53:10 2004 From: gert at space.net (Gert Doering) Date: Wed, 14 Jan 2004 18:53:10 +0100 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> <20040114164047.GO30954@Space.Net> Message-ID: <20040114175310.GT30954@Space.Net> hi, On Wed, Jan 14, 2004 at 08:46:56AM -0800, Randy Bush wrote: > > So please: constructive criticism is welcome, but things like > > "all that you do is wrong, because APNIC is doing something!" > > (and no further reason or detail given) are just wasting our > > time. > > excuse! where did i say that? *You* didn't. Jeff Williams did, to which I replied, and then you came in and implied that we don't care about globality... > please do not put stupid words into > my keyboard, i do that well enough. i merely responded to what i > considered an unwise statement which sets an incorrect atmosphere > and could become a quoted precident set by a co-chair of this wg. Sorry for that. You are right, it wasn't meant to be read that way in absoluteness ("what do we care about other regions"). Of course we care, but for the RIPE policy process, the accusation (from Jeff) "You are mistaken Hans. It would benefit you and everyone here if you would track Apnic a little closer...", in response to the statement from Hans-Petter "we don't have any objections, so we can assume consensus here", is ridiculous. 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 From randy at psg.com Wed Jan 14 18:58:17 2004 From: randy at psg.com (Randy Bush) Date: Wed, 14 Jan 2004 09:58:17 -0800 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> <20040114164047.GO30954@Space.Net> <20040114175310.GT30954@Space.Net> Message-ID: > Jeff Williams did who? sorry, aside from academic papers, i read the new york times, the nation, and world press review, none of which have comic pages. i kinda wish the nyt had doonsbury though. and now back to discussing how many addresses fit on the head of a pin. :-) randy From anne at apnic.net Thu Jan 15 00:52:13 2004 From: anne at apnic.net (Anne Lord) Date: Thu, 15 Jan 2004 09:52:13 +1000 (EST) Subject: [hm-staff] RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size In-Reply-To: <3FE68A3100020366@cpfe0.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) Message-ID: Hans Petter, No-one from the APNIC Secretariat has made any comments about the proposed policy. The reference to APNIC occurred in a sentence by Jeff Williams. Things got a bit confused from thereon.. Anne APNIC Secretariat ---------------------------------------------------------------------- On Wed, 14 Jan 2004, Hans Petter Holen wrote: > Could somebody summarize what the APNIC objections to changed policy are ? > > -hph > > |> So if we send out a formal proposal to change RIPE things to RIPE > |> lists, and nobody from the RIPE community objects - what's > |wrong with > |> assuming consensus, then? > | > |maybe because we have not yet implemented that packets and > |routing information stay only within the ripe region? it's > |the global internet we're affecting. > | > |think locally, act globally > | -- motto of the small view polluter > | > |randy > | > > _______________________________________________ > Hostmaster-staff mailing list > Hostmaster-staff at apnic.net > http://mailman.apnic.net/mailman/listinfo/hostmaster-staff > From jwkckid1 at ix.netcom.com Thu Jan 15 05:03:13 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 14 Jan 2004 20:03:13 -0800 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> Message-ID: <40061101.1355CB46@ix.netcom.com> Gert and all, Gert Doering wrote: > Hi, > > On Tue, Dec 23, 2003 at 01:02:03PM -0800, Jeff Williams wrote: > > Hans and all, > > > > You are mistaken Hans. It would benefit you and everyone here > > if you would track Apnic a little closer... > > Why? We are not APNIC, we are RIPE, and we only make RIPE policies. Understood of course. However shouldn't the respective RIR's coordinate their policies or proposed policies? > > > So if we send out a formal proposal to change RIPE things to RIPE lists, > and nobody from the RIPE community objects - what's wrong with assuming > consensus, then? Seeking consensus is of course a good thing. However assuming consensus is not consensus at all. Hence to the extent an consensus exists it must be measured and by all of the stakeholder/user community in which consensus on any proposed policy is being considered. > > > 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 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 15 05:07:54 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 14 Jan 2004 20:07:54 -0800 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> Message-ID: <4006121A.390A94C2@ix.netcom.com> Randy and all, Randy Bush wrote: > > So if we send out a formal proposal to change RIPE things to RIPE > > lists, and nobody from the RIPE community objects - what's wrong > > with assuming consensus, then? > > maybe because we have not yet implemented that packets and routing > information stay only within the ripe region? it's the global > internet we're affecting. Good point made here Randy! Well done. > > > think locally, act globally > -- motto of the small view polluter Well I don't know about this???? > > > 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Thu Jan 15 05:29:37 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 14 Jan 2004 20:29:37 -0800 Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: <3FE68A3100002DAF@cpfe0.be.tisc.dk> <3FE8AD4A.D6FB5F3D@ix.netcom.com> <20040114161700.GM30954@Space.Net> <20040114164047.GO30954@Space.Net> Message-ID: <40061731.2E65DB53@ix.netcom.com> Randy, Gert and all, Randy Bush wrote: > > So please: constructive criticism is welcome, but things like > > "all that you do is wrong, because APNIC is doing something!" > > (and no further reason or detail given) are just wasting our > > time. > > excuse! where did i say that? please do not put stupid words into > my keyboard, i do that well enough. i merely responded to what i > considered an unwise statement which sets an incorrect atmosphere > and could become a quoted precident set by a co-chair of this wg. > > >>> So if we send out a formal proposal to change RIPE things to > >>> RIPE lists, and nobody from the RIPE community objects - what's > >>> wrong with assuming consensus, then? > > i still consider this unwise, and for the reasons i stated. and, > in the face of such statements, i do not consider pointing out that > we are making, or proposing to make, policy that affects the global > internet a waste of time. if you feel it wastes yours, you have a > delete key. Your response here Randy was a bit harsh, as I am sure you are aware of and intended. However am I wrong in my understanding on these exchanges on this thread that a rift in differences of ideology has crept into the policy making process here unto engaged? As Randy well knows I do not often agree with his ideas or point of view. But in this instance I certainly do. It is at least unwise and I contend impossible for any WG to decide what an initial PA allocation size should be without the known and measured consensus of those directly and indirectly effected. Yet a global view and policy is prudent if not necessary. This said, it is also understandable that Gert's view from a RIPE Regional/local view in setting a initial PA allocation size may have some Regional/local advantages but could/would cause a disparency on a global business basis.. As such a need for a global policy is more attractive if it is crafted to meet or even slightly exceed a known current need and a far future need... > > > 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From Michael.Dillon at radianz.com Thu Jan 15 11:19:22 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 15 Jan 2004 10:19:22 +0000 Subject: [hm-staff] RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size Message-ID: >No-one from the APNIC Secretariat has made any comments about the >proposed policy. The reference to APNIC occurred in a sentence by >Jeff Williams. Things got a bit confused from thereon.. Anyone who is involved in any area of Internet policymaking anywhere in the world, *MUST* be aware who Jeff Williams is and what he does. According to this URL, "Jeff Williams is a fake and an impostor". http://www.dnso.org/clubpublic/ga/Arc03/msg00615.html He seems to like spending his time creating confusion and stirring up trouble for people working on Internet related policy. If you can read German there is a great article about him here http://www.wortfeld.de/2003/08/das_emailphantom Please don't take any of his comments seriously. --Michael Dillon From michel at arneill-py.sacramento.ca.us Thu Jan 15 11:41:09 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 15 Jan 2004 02:41:09 -0800 Subject: [hm-staff] RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size Message-ID: > Michael.Dillon at radianz.com wrote: > Anyone who is involved in any area of Internet > policymaking anywhere in the world, *MUST* be aware > who Jeff Williams is and what he does. [snip] > Please don't take any of his comments seriously. Thank you. From jwkckid1 at ix.netcom.com Fri Jan 16 02:46:01 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 15 Jan 2004 17:46:01 -0800 Subject: [hm-staff] RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size References: Message-ID: <40074255.5054FFD0@ix.netcom.com> Michael and all, I see your at it again. Seems you have a real personality problem that is obviously a cronic one. See: ============ Copy of past Dillion deluge follows ======== Subject: Re: Root-64 Weekly Status Report Date: Fri, 24 Nov 2000 20:46:31 -0800 From: Jeff Williams Organization: INEGroup Spokesman To: JIM FLEMING CC: DOMAIN-POLICY at LISTS.NETSOL.COM, Michael Dillon References: 1 Jim and all, Some of us have been around long enough to understand Michael Dillon's motivations as a litany of pontificators of the now, and long defunct IAHC effort which DOC/NTIA shut down. As such, we unfortunately see Michael Dilllon has surfaced to spew forth this nonsense again. JIM FLEMING wrote: > http://www.cctec.com/maillists/nanog/historical/9610/msg00930.html > > Re: Root-64 Weekly Status Report (fwd) > > ---------------------------------------------------------------------------- > ---- > > To: nanog at merit.edu > Subject: Re: Root-64 Weekly Status Report (fwd) > From: Michael Dillon > Date: Sun, 27 Oct 1996 10:15:07 -0800 (PST) > In-Reply-To: > Organization: Memra Software Inc. - Internet consulting > Sender: owner-nanog at merit.edu > > ---------------------------------------------------------------------------- > ---- > > On Sun, 27 Oct 1996, Dorian R. Kim wrote: > > > > What happens when other employees of your company read some of the > > > material Jim Fleming has written and believe that this is an official > > > new way to deal with Internet domain names? > > > > They will be referred to more suitable educational material. > > It would sure be nice if there was some suitable educational material > generally available. I've been contacted several times by reporters over > this issue and the best I can do is to point out that this is not as > simple as the Alternic/Route64 people make it seem and to point them to my > TLD resources page at http://www.memra.com/ndbg.html for background > material and let them draw their own conclusions. > > If the members of this list generally support what ISOC and IANA are doing > with the IAHC it may be a good idea to get your PR departments to issue a > press release indicating that support. Right now a lot of the press has > this mistaken idea that the industry supports Alternic/Route64 while the > IANA/ISOC/IAHC efforts are way out in ivory tower left field somewhere. > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael at memra.com > > - - - - - - - - - - - - - - - - - > > Jim Fleming > http://www.unir.com > Mars 128n 128e > http://www.unir.com/images/architech.gif > http://www.unir.com/images/address.gif > http://www.unir.com/images/headers.gif > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 ============= End of disgusting copy ================ Michael.Dillon at radianz.com wrote: > >No-one from the APNIC Secretariat has made any comments about the > >proposed policy. The reference to APNIC occurred in a sentence by > >Jeff Williams. Things got a bit confused from thereon.. > > Anyone who is involved in any area of Internet policymaking > anywhere in the world, *MUST* be aware who Jeff Williams is and > what he does. According to this URL, "Jeff Williams is a fake and > an impostor". http://www.dnso.org/clubpublic/ga/Arc03/msg00615.html > > He seems to like spending his time creating confusion and > stirring up trouble for people working on Internet related > policy. > > If you can read German there is a great article about him here > http://www.wortfeld.de/2003/08/das_emailphantom > > Please don't take any of his comments seriously. > > --Michael Dillon -- 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From leslien at arin.net Fri Jan 16 02:13:45 2004 From: leslien at arin.net (Leslie Nobile) Date: Thu, 15 Jan 2004 20:13:45 -0500 Subject: [address-policy-wg] ARIN to allocate from 70.0.0.0/8 Message-ID: <000301c3dbcd$ffc931a0$588888c0@arin.net> Hello- ARIN received the IPv4 address block 70.0.0.0/8 from the IANA on Jan. 15, 2004. In the near future, ARIN will begin making allocations from this new block. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. You may wish to adjust any filters you have in place accordingly. For informational purposes, a list of ARIN's currently administered IP blocks can be found under "CIDR Blocks" at: http://www.arin.net/statistics/index.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) From baess at denic.de Fri Jan 16 11:18:29 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Fri, 16 Jan 2004 11:18:29 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: Hello! In addition to the criteria that leaked out to list a few days ago I have added the technical problem that is solved by deploying anycast for DNS with a lower number of server names to the list of requirements to get an allocation. So the suggested policy would be: RIPE should be able to allocate a single /24 IPv4 and a /32 IPv6 address block for the operation of anycast DNS servers if: - the operator serves a TLD zone - the number of (planned?) nameservers would lead to a truncation of the authority/additional section in a DNS delegation response containing the NS RRset in [draft-ietf-dnsop-respsize-00.txt 2.9] As far as DENIC is concerned we would love to see this policy in effect as our additional section is already truncated and we would need to remove names from the authority section to gain more space for V6 glues. But we think it is a good thing to keep the network diversity that we have. See you in Amsterdam Andreas Baess From gert at space.net Fri Jan 16 15:37:49 2004 From: gert at space.net (Gert Doering) Date: Fri, 16 Jan 2004 15:37:49 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: Message-ID: <20040116143749.GS30954@Space.Net> Hi, On Fri, Jan 16, 2004 at 11:18:29AM +0100, Andreas B??/Denic wrote: > RIPE should be able to allocate a single /24 IPv4 and a /32 IPv6 address > block for the operation of anycast DNS servers if: > - the operator serves a TLD zone > - the number of (planned?) nameservers would lead to a truncation of the > authority/additional section in a DNS delegation response containing the > NS RRset in [draft-ietf-dnsop-respsize-00.txt 2.9] I would support that. Yes, I know that it's a very special case, and it could be done by a "swamp" (or a random PI) /24 just fine. But I'm very much in favour of having official ways to do things that need doing - and I'm convinced that this is a good thing to do. As for the impact on the routing table: this new policy would not make more or less impact than just announcing a random /24, but it would allow for better documentation what it's all about. As far as "other" anycast deployments go: there have been some voices on the list that "we must not do a policy that's too narrow minded" - yes, that's true, but we don't want a "permit all" policy either (well, we *could* do that, but there does not seem to be consensus to do that). *If* other people show up, and say "we want to do this-and-that, and have a specific need that cannot be done in the current framework", we can always adapt the then-existent policies. (This is speaking as myself, and as APWG co-chair). Andreas: I would appreciate if you could give a short presentation (5 mins?) in Amsterdam, repeating the reasoning behind this proposal, to stir some discussion. Then we can have a final call for consensus some time after the meeting. 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 From Michael.Dillon at radianz.com Fri Jan 16 17:30:57 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 16 Jan 2004 16:30:57 +0000 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: >Yes, I know that it's a very special case, and it could be done by >a "swamp" (or a random PI) /24 just fine. But I'm very much in favour of >having official ways to do things that need doing - and I'm convinced >that this is a good thing to do. A "swamp" /24 gets through more legacy filters than a random PI /24. Therefore the policy should specify that these /24s come from the former class C range. --Michael Dillon From adiel at akplogan.com Sun Jan 18 12:12:35 2004 From: adiel at akplogan.com (Adiel A. AKPLOGAN) Date: Sun, 18 Jan 2004 12:12:35 +0100 Subject: [address-policy-wg] AfriNIC Transition: IPv4 allocation Policy change Message-ID: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> IPv4 Allocation Policy for the African Portion of the RIPE NCC service Region: The motivation behind this is that today there are three different policies applied to African LIRs: (ARIN, RIPE NCC, APNIC). To ease the transition to AfriNIC (the registry for Africa) policies need to be harmonized. The ARIN Community has already taken a step by creating a particular policy for its African members. It will be a good step if the RIPE community can do the same for its African Members by making the minimum allocation the same. The proposed policy change below is for those operating in Africa. It is intended as an interim, transitional policy during the period before AfriNIC takes on the RIR function for the African continent. From that time the policies agreed at the AfriNIC-I meeting will be used in Africa. Also we should keep in mind that this will only affect the IP block 196.200/13 used by RIPE NCC to allocate address in Africa. BGP filters then need to be adapted to permit longer prefix (/22) only in this block. Proposed change: * Minimum allocation: The minimum allocation for African members of RIPE NCC should be changed from /21 to /22. _______________________________________________________________________ Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 Singel 258 - 1016AB Amsterdam - NL www.ripe.net -------------- next part -------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004 From gert at space.net Sun Jan 18 16:34:38 2004 From: gert at space.net (Gert Doering) Date: Sun, 18 Jan 2004 16:34:38 +0100 Subject: [address-policy-wg] AfriNIC Transition: IPv4 allocation Policy change In-Reply-To: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> References: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> Message-ID: <20040118153438.GE30954@Space.Net> Hi, On Sun, Jan 18, 2004 at 12:12:35PM +0100, Adiel A. AKPLOGAN wrote: > Proposed change: > > * Minimum allocation: The minimum allocation for African members of > RIPE NCC should be changed from /21 to /22. Hmmm, what's the rationale behind being *so* conservative in doing allocations? A /21 is already pretty small. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jwkckid1 at ix.netcom.com Mon Jan 19 03:19:35 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sun, 18 Jan 2004 18:19:35 -0800 Subject: [address-policy-wg] AfriNIC Transition: IPv4 allocation Policy change References: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> Message-ID: <400B3EB7.7CBA952B@ix.netcom.com> Adiel and all, Have you put your proposal before the stakeholders/users in your region? If so is their a measured consensus. I know that until now, none of our members in your region have heard of your proposal. Thank you for providing in here and now though. I am sure our members will review it and determine if it is acceptable or offer an alternative.. Adiel A. AKPLOGAN wrote: > IPv4 Allocation Policy for the African Portion of the RIPE NCC service > Region: > > The motivation behind this is that today there are three different > policies applied to African LIRs: (ARIN, RIPE NCC, APNIC). To ease the > transition to AfriNIC (the registry for Africa) policies need to be > harmonized. The ARIN Community has already taken a step by creating a > particular policy for its African members. It will be a good step if > the RIPE community can do the same for its African Members by making > the minimum allocation the same. > > The proposed policy change below is for those operating in Africa. It > is intended as an interim, transitional policy during the period > before AfriNIC takes on the RIR function for the African > continent. From that time the policies agreed at the AfriNIC-I meeting > will be used in Africa. > > Also we should keep in mind that this will only affect the IP block > 196.200/13 used by RIPE NCC to allocate address in Africa. BGP filters > then need to be adapted to permit longer prefix (/22) only in this > block. > > Proposed change: > > * Minimum allocation: The minimum allocation for African members of > RIPE NCC should be changed from /21 to /22. > > _______________________________________________________________________ > Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 > RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 > Singel 258 - 1016AB Amsterdam - NL www.ripe.net > > ------------------------------------------------------------------------ > > Part 1.2 Type: Plain Text (text/plain) 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Mon Jan 19 03:26:02 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Sun, 18 Jan 2004 18:26:02 -0800 Subject: [address-policy-wg] AfriNIC Transition: IPv4 allocation Policy change References: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> <20040118153438.GE30954@Space.Net> Message-ID: <400B403A.D50518DC@ix.netcom.com> Gertp and all, Gert Doering wrote: > Hi, > > On Sun, Jan 18, 2004 at 12:12:35PM +0100, Adiel A. AKPLOGAN wrote: > > Proposed change: > > > > * Minimum allocation: The minimum allocation for African members of > > RIPE NCC should be changed from /21 to /22. > > Hmmm, what's the rationale behind being *so* conservative in doing > allocations? A /21 is already pretty small. I agree personally. A /21 if far too small for a minimum. However I believe it is motivated by the inadequacies of CIDR, which needs fixing, and some SIG's that are not obvious in their motivations... > > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 58081 (57882) > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Tue Jan 20 03:49:24 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 19 Jan 2004 18:49:24 -0800 Subject: [address-policy-wg] Re: Joint policy? (was:RE: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region References: Message-ID: <400C9733.D100DE9C@ix.netcom.com> Marcelo and all, marcelo bagnulo wrote: > Hi Jeff, > > I guess that your point is not strictly related with this particular IPv6 > policy proposal but in general about if policies should be common or not. > (so i changed the subject) Yes in part, this is the point I was trying to make and support from others comments/remarks. > > > IMHO not taking into account what ather regions are doing is clearly a > mistake (i don't think anyone thinks otherwise) Agreed. > > > OTOH, i am not sure that a joint policy should be the default option. > Different regions have very different realities and policies should be > adapted to this realities. Yes to a very small degree I agree. However in allocation minimums and maximums I and our members in all regions, do not agree. > > > Cooordination is required and so forums like this one to coordinate policies > and where people from other regions can give their opinion on other region's > policies are needed Agreed here strongly. However it again seems that sharing these discussions with other regions seems to be something some participants such as Brian have seemingly been not desiring to do... > > > So i guess that we should try to do joint policies when it is possible and > when a policy is suitable for all the regions, but i am not very confident > that this will be the case always Of course in some instances joint of global policies will not be adequate for some regions. However this should be the rare exception, not the norm. > > > Coming back to the IPv6 case... > > For this particular case of IPv6, i understand that several regions are > having problems whith the policy. > APNIC people have brought lot of issues about this policy to this list and > also a proposal to waive the 200 /48 assignments has been discussed in ARIN, > so perhaps there is possibility here for a joint policy. If we were to do > this, how do think we should continue? First we all should be sharing discussions on issue areas of common consideration. And from their ICANN should set or incorporate any such policy which the RIR's must conform to after of course, stakeholder/user input and considerations is based on a measured consensus... > > > Regards, marcelo > > > -----Mensaje original----- > > De: global-v6-admin at lists.apnic.net > > [mailto:global-v6-admin at lists.apnic.net]En nombre de Jeff Williams > > Enviado el: lunes, 19 de enero de 2004 12:16 > > Para: mbagnulo at ing.uc3m.es > > CC: Kosuke Ito; German Valdez; Izumi Okutani; global-v6 at lists.apnic.net; > > icann board address > > Asunto: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > > > > Marcelo and all, > > > > The issue is not whether Lacnic has a great need now for > > IPv6 addresses or not, or wheater other other RIR's have their > > own minimum allocation policy. Rather the issue is should or should > > not any such allocation policy be uniform across all RIR's and > > how should that policy be determined. > > > > What is seemingly happening is history repeating itself again > > in that each > > region is jumping to a conclusion without consideration enough for > > the future and desiring to be far to restrictive due to special > > interests. We saw allot of this during Jon Postels tenure > > and it lead to a huge mess... > > > > marcelo bagnulo wrote: > > > > > Hi Kosuke, > > > > > > > I would not like to see avalanche multiplication on relaxing > > > > the allocation conditions initiating from LACNIC to all other > > > > regions... This is my worry. > > > > > > While i am not arguing whether or not having common policy is > > the right way > > > to go, I really don't see how this avalanche can be caused by the policy > > > proposed by lacnic. > > > I mean, this policy only applies to the lacnic region where the IPv6 > > > requests so far are measures in tens (a few tens i think), so i > > don't think > > > that an avalanche is likely in the region. Moreover, the proposed policy > > > requests that the LIR has to provide IPv6 services to customers > > physically > > > located _in_ the lacnic region. > > > > > > With respect to all other regions, rirs in these regions still have its > > > policy so, i don't see how this can affect them. > > > > > > the motivation for the lacnic policy proposal is that, as it has been > > > mentioned in this list, the community is not applying for IPv6 > > address space > > > becuase they feel they will not meet the 200 /48 allocations in > > the next 2 > > > years. Moreover, they are not planning to have them, so they > > know they don't > > > qualify for it. > > > > > > AFAIU, the goal of the current policy is to assign address > > space to people > > > that want to actually provide IPv6 services. > > > The proposed policy attempts to do that. The imposed condition does not > > > depends on the adoption of IPv6 in the internet, but in the > > efforts made by > > > the one who obtained the allocation to provide IPv6 services. > > So the policy > > > asks that in order to obtain an allocation, the LIR has to provide IPv6 > > > services to its customers in the region. IMHO this would enable > > obtaining an > > > address block to those who want to provide IPv6 but don't > > really think they > > > will reach the 200 customers in 2 years (which is considered to > > be the most > > > common case in the lacnic region so far) > > > > > > Regards, marcelo > > > > > > > > > > > Regards, > > > > > > > > Kosuke > > > > > > > > > > > > Jeff Williams wrote: > > > > > German and all, > > > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > > does seek such input, that the desires and requirements of those > > > > > participating stakeholders/users will be adheared to in a > > responsible > > > > > and direct way? > > > > > > > > > > German Valdez wrote: > > > > > > > > > > > > > > >>Hi Izumi > > > > >> > > > > >>sorry for delay > > > > >> > > > > >>It is intention of the RIR to work in common policies, > > like the IPv6 > > > > one, > > > > >>when this is possible. > > > > >> > > > > >>Nevertheless, this IPv6 policy proposal is the result of > > a regional > > > > need. > > > > >>So far has accomplished all the step of our Policy > > > > Development Process. > > > > >> > > > > >>Even though common policies may work well they are not > > bindig for the > > > > RIR. > > > > >> > > > > >>We are aware that this proposal is broken a common > > policy. For this > > > > reason > > > > >>we are sharing this criteria with the Global IPv6 community. > > > > >> > > > > >>This 45 days period of comment (which ends at january > > 23rd) is not > > > > part of > > > > >>the policy development process, however is a faculty of LACNIC's > > > > Board to > > > > >>do this. The reason was to recieve more comments from the global > > > > community > > > > >>before the Board made a decision. > > > > >> > > > > >>Regards > > > > >> > > > > >>German Valdez > > > > >>Policy Liaison > > > > >>LACNIC > > > > >> > > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > > >> > > > > >>>It had been my understanding that IPv6 policy would be > > co-ordinated > > > > >>>among the RIRs, but this seems to imply a regional > > policy like IPv4. > > > > >>> > > > > >>>That's also one method of the policy process that's > > proved to work > > > > >>>well, but it should at least be a concious decision by the > > > > RIRs(or its > > > > >>>communities). > > > > >>> > > > > >>>Could someone from the RIRs share the position about this? > > > > >>> > > > > >>>Izumi > > > > >>>JPNIC > > > > >>> > > > > >>>From: German Valdez > > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > > >>> > > > > >>> > > > > >>>> > > > > >>>>FYI LACNIC is calling for last comments for new policies to > > > > be applied > > > > >>> > > > > >>>next > > > > >>> > > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > > allocation. > > > > >>>> > > > > >>>>This proposal is the result of the analysis of the > > LACNIC IPv6 WG > > > > and the > > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > > >>>> > > > > >>>>You can review this proposal at > > http://lacnic.net/en/last-call.html > > > > >>>> > > > > >>>>On december 9th we started a 45 days period for > > comments for these > > > > >>>>policies, including the IPv6 one. Comments will be received > > > > through our > > > > >>>>policy public list politicas at lacnic.net, subscription > > to this list > > > > is open > > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > > >>>> > > > > >>>>Regards > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>German Valdez > > > > >>>>Policy Liaison > > > > >>>>LACNIC > > > > >>>> > > > > >>>>_______________________________________________ > > > > >>>>global-v6 mailing list > > > > >>>>global-v6 at lists.apnic.net > > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >>>> > > > > >>> > > > > >>>_______________________________________________ > > > > >>>global-v6 mailing list > > > > >>>global-v6 at lists.apnic.net > > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >> > > > > >>_______________________________________________ > > > > >>global-v6 mailing list > > > > >>global-v6 at lists.apnic.net > > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > 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 at ix.netcom.com > > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > > > > _______________________________________________ > > > > > global-v6 mailing list > > > > > global-v6 at lists.apnic.net > > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > > > > > > -- > > > > **********IPv6 Internet Wonderland!************ > > > > Kosuke Ito, Master Planning and Steering Group > > > > IPv6 Promotion Council of Japan > > > > (Visiting Researcher, SFC Lab. KEIO University) > > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > > Cell:+81-90-4605-4581 > > > > mailto: kosuke at v6pc.jp http://www.v6pc.jp/ > > > > Lifetime e-mail: kosuke at stanfordalumni.org > > > > > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6 at lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6 at lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > 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 at ix.netcom.com > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > global-v6 mailing list > > global-v6 at lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Tue Jan 20 10:18:51 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 20 Jan 2004 01:18:51 -0800 Subject: [address-policy-wg] Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region References: Message-ID: <400CF27A.F49E45CF@ix.netcom.com> Anne and all, Anne Lord wrote: > Hi Izumi, Kosuke, > > > Could I confirm once again that this was the concious > > decision(acknowledgement) made by all RIRs, having considered its > > implications? > > I think German has replied to this question and I think the reply > from the APNIC Secretariat will be similar. I did not see Germans answer to this question nor to mine I ask him below on this thread. I also checked the archives and also cannot find his answer. The APNIC Secretariat's answer was indirect and cryptic in nature as it does not reflect the needs of the stakeholders/users of the regions community that can be demonstrated. I did request some evidence of such demonstrated/measured consensus, of the secretariat, but after two days, none has been forthcoming... > > > This was *not* part of a concious decision or acknowledgement made > by all the RIRs. The decision flowed from the LACNIC community > proposing and accepting the proposal as meeting a 'need' in their > region. > > It is useful to observe that this policy is globally co-ordinated > rather than a global policy: there were never any agreements by > any RIR staff that there would be a single global policy. Actually > APNIC EC has taken a decision to interpret one aspect of the policy > in a way that differs from the other regions. See: > > http://www.apnic.net/docs/policy/ipv6-policy-clarification.html Ah yes well as has already been observed and recently discussed, this "Clarification" has been refuted... > > > I also see this and the LACNIC change as part of the normal globally > co-ordinated policy development processes. My understanding is that > the reason that LACNIC announced their consensus on the global-v6 policy > discussion list, was in order to collect feedback from the other > regions, and if necessary to re-asses the consensus decision. > In other words, this was an attempt to look at the global context > and to co-ordinate. It is almost always a wise idea to co-ordinate between and with any or all regions. However one ML for doing so is not shown to be adequate for accomplishing said co-ordination... > > > Also please feel welcome to bring the proposed change, and this > discussion to the agenda of the Policy SIG at the forthcoming > APNIC Open Policy Meeting. > > Best wishes, > > Anne > -- > > > From: Kosuke Ito > > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > Date: Sun, 18 Jan 2004 12:08:36 +0900 > > > > > > > > Hi, German and all > > > > > > I do understand that LACNIC community like to have their > > > own "bootstrap" condition for deploying IPv6 in LACNIC > > > region, but I do NOT like to have it with an open jaw > > > condition, anyway. > > > > > > And, I would like to know other RIRs people's view on > > > this matter, and how LACNIC consider the possible side > > > effect to the global community once the LACNIC special > > > condition is implemented. > > > I believe that RIRs/NIRs community should have a single > > > view (even though each region has a different need) on > > > the global coordinated policy like the IPv6 policy which > > > was built up on the large amount of efforts balancing many > > > factors from the global point of view, since the IP address > > > space is a global resourse shared accross the globe. > > > And RIRs/NIRs, I personally believe, should set a allowance > > > of changing the global policy to accomodate a local need. > > > When it needs to change (locally), possible effects after > > > the change should be discussed from the global resourse > > > management point of view at the same time. > > > > > > I would not like to see avalanche multiplication on relaxing > > > the allocation conditions initiating from LACNIC to all other > > > regions... This is my worry. > > > > > > Regards, > > > > > > Kosuke > > > > > > > > > Jeff Williams wrote: > > > > German and all, > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > does seek such input, that the desires and requirements of those > > > > participating stakeholders/users will be adheared to in a responsible > > > > and direct way? > > > > > > > > German Valdez wrote: > > > > > > > > > > > >>Hi Izumi > > > >> > > > >>sorry for delay > > > >> > > > >>It is intention of the RIR to work in common policies, like the IPv6 > > > one, > > > >>when this is possible. > > > >> > > > >>Nevertheless, this IPv6 policy proposal is the result of a regional > > > need. > > > >>So far has accomplished all the step of our Policy Development Process. > > > >> > > > >>Even though common policies may work well they are not bindig for the > > > RIR. > > > >> > > > >>We are aware that this proposal is broken a common policy. For this > > > reason > > > >>we are sharing this criteria with the Global IPv6 community. > > > >> > > > >>This 45 days period of comment (which ends at january 23rd) is not > > > part of > > > >>the policy development process, however is a faculty of LACNIC's > > > Board to > > > >>do this. The reason was to recieve more comments from the global > > > community > > > >>before the Board made a decision. > > > >> > > > >>Regards > > > >> > > > >>German Valdez > > > >>Policy Liaison > > > >>LACNIC > > > >> > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > >> > > > >>>It had been my understanding that IPv6 policy would be co-ordinated > > > >>>among the RIRs, but this seems to imply a regional policy like IPv4. > > > >>> > > > >>>That's also one method of the policy process that's proved to work > > > >>>well, but it should at least be a concious decision by the RIRs(or its > > > >>>communities). > > > >>> > > > >>>Could someone from the RIRs share the position about this? > > > >>> > > > >>>Izumi > > > >>>JPNIC > > > >>> > > > >>>From: German Valdez > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > >>> > > > >>> > > > >>>> > > > >>>>FYI LACNIC is calling for last comments for new policies to be applied > > > >>> > > > >>>next > > > >>> > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > allocation. > > > >>>> > > > >>>>This proposal is the result of the analysis of the LACNIC IPv6 WG > > > and the > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > >>>> > > > >>>>You can review this proposal at http://lacnic.net/en/last-call.html > > > >>>> > > > >>>>On december 9th we started a 45 days period for comments for these > > > >>>>policies, including the IPv6 one. Comments will be received > > > through our > > > >>>>policy public list politicas at lacnic.net, subscription to this list > > > is open > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > >>>> > > > >>>>Regards > > > >>>> > > > >>>> > > > >>>> > > > >>>>German Valdez > > > >>>>Policy Liaison > > > >>>>LACNIC > > > >>>> > > > >>>>_______________________________________________ > > > >>>>global-v6 mailing list > > > >>>>global-v6 at lists.apnic.net > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > >>>> > > > >>> > > > >>>_______________________________________________ > > > >>>global-v6 mailing list > > > >>>global-v6 at lists.apnic.net > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > >> > > > >>_______________________________________________ > > > >>global-v6 mailing list > > > >>global-v6 at lists.apnic.net > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > 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 at ix.netcom.com > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6 at lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > -- > > > **********IPv6 Internet Wonderland!************ > > > Kosuke Ito, Master Planning and Steering Group > > > IPv6 Promotion Council of Japan > > > (Visiting Researcher, SFC Lab. KEIO University) > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > Cell:+81-90-4605-4581 > > > mailto: kosuke at v6pc.jp http://www.v6pc.jp/ > > > Lifetime e-mail: kosuke at stanfordalumni.org > > > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6 at lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > _______________________________________________ > > global-v6 mailing list > > global-v6 at lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From joao at psg.com Tue Jan 20 16:50:03 2004 From: joao at psg.com (Joao Damas) Date: Tue, 20 Jan 2004 16:50:03 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Message-ID: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> Coming in late but let's see if I understand this: The problem has to do with the fact that there are requests for a /24 that plan to host only one address (maybe 2, one for a server and one for a router) and that if the requester tells the truth, it does not qualify. Note that from a routing point of view, if you look at an anycasted network from the outside, it is indistinguishable from a multi-homed network so in itself the routing is not the problem, it is the fact that you are asking for a prefix to host only one active IP address but you need it to be routable and today that means a /24. This goal could very well be achieved by keeping the addresses of the servers you are already using and migrating all other active IP's out of the /24 that contains the address you want to "anycast". After all, none of the root servers that are anycasting today have renumbered (one that is not anycasting today will renumber soon because they can't apply what I just described, which was unfortunate). The problem is then with obtaining a /24 for each anycasted site, not for the service IP but for the "management" IP, something that allows you to uniquely identify the different incarnations of the the same IP, geographically distributed and only accessible through networks other than your own (for the operator of the anycast service, anycast is indeed different from multi-homing). Depending on the requirements for independence (in its various aspects), you may use an IP inside someone else's PA block for that, if you buy hosting from them, for instance, or you may need to ask for a separate /24. It is this last part that may pose a problem within current RIPE policies. Note that the IPv6 root server policy has nothing to do with anycast but rather with routability of a prefix containing only one active IPv6 address and that there is no RIPE IPv4 root server anycast policy in spite of there being anycasted instances of root servers hosted by European organisations. Joao On 16 Jan, 2004, at 15:37, Gert Doering wrote: > Hi, > > On Fri, Jan 16, 2004 at 11:18:29AM +0100, Andreas B??/Denic wrote: >> RIPE should be able to allocate a single /24 IPv4 and a /32 IPv6 >> address >> block for the operation of anycast DNS servers if: >> - the operator serves a TLD zone >> - the number of (planned?) nameservers would lead to a truncation of >> the >> authority/additional section in a DNS delegation response containing >> the >> NS RRset in [draft-ietf-dnsop-respsize-00.txt 2.9] > > I would support that. > > Yes, I know that it's a very special case, and it could be done by > a "swamp" (or a random PI) /24 just fine. But I'm very much in favour > of > having official ways to do things that need doing - and I'm convinced > that this is a good thing to do. > > As for the impact on the routing table: this new policy would not make > more or less impact than just announcing a random /24, but it would > allow for better documentation what it's all about. > > As far as "other" anycast deployments go: there have been some voices > on the list that "we must not do a policy that's too narrow minded" - > yes, > that's true, but we don't want a "permit all" policy either (well, we > *could* do that, but there does not seem to be consensus to do that). > > *If* other people show up, and say "we want to do this-and-that, and > have a specific need that cannot be done in the current framework", we > can always adapt the then-existent policies. > > > (This is speaking as myself, and as APWG co-chair). > > > Andreas: I would appreciate if you could give a short presentation > (5 mins?) in Amsterdam, repeating the reasoning behind this proposal, > to stir some discussion. > > Then we can have a final call for consensus some time after the > meeting. > > 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 > > From gert at space.net Tue Jan 20 16:54:50 2004 From: gert at space.net (Gert Doering) Date: Tue, 20 Jan 2004 16:54:50 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <20040116143749.GS30954@Space.Net> Message-ID: <20040120155449.GR30954@Space.Net> Hi, On Mon, Jan 19, 2004 at 05:45:51PM +0100, Joao Damas wrote: > This goal could very well be achieved by keeping the addresses of the > servers you are already using and migrating all other active IP's out > of the /24 that contains the address you want to "anycast". After all, > none of the root servers that are anycasting today have renumbered (one > that is not anycasting today will renumber soon because they can't > apply what I just described, which was unfortunate). For the root servers, this is a viable approach (as you can't easily change their IP address). I'm not sure how useful this approach would be for a typical ccTLD that hosts their existing name servers in the PA address block of some hosting provider. > The problem is then with obtaining a /24 for each anycasted site, not > for the service IP but for the "management" IP, something that allows > you to uniquely identify the different incarnations of the the same IP, > geographically distributed and only accessible through networks other > than your own (for the operator of the anycast service, anycast is > indeed different from multi-homing). > Depending on the requirements for independence (in its various > aspects), you may use an IP inside someone else's PA block for that, if > you buy hosting from them, for instance, or you may need to ask for a > separate /24. > It is this last part that may pose a problem within current RIPE > policies. This specific solution (a separate /24 per anycast *instance*) would indeed *also* be a problem under the current policy, but this can be solved - as you suggested - by going for "local" PA addresses. The problem is really the anycast space - you need a routeable /24 (as far as anybody can promise "routeability") for a single host, and the current PI policy won't give you that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kurtis at kurtis.pp.se Tue Jan 20 20:07:56 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 20 Jan 2004 20:07:56 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joao, On 2004-01-20, at 16.50, Joao Damas wrote: > This goal could very well be achieved by keeping the addresses of the > servers you are already using and migrating all other active IP's out > of the /24 that contains the address you want to "anycast". After all, > none of the root servers that are anycasting today have renumbered > (one that is not anycasting today will renumber soon because they > can't apply what I just described, which was unfortunate). > This was actually spelled out as a problem with NEW services (TLDs) moving to anycast. That is people who do not have their own addresses at all at this point. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQA18j6arNKXTPFCVEQKIgQCfdI0l1TMNy2mmCWtP/umLcpr23K0An2FL J7KQTOTKYhprMKX9QV7sutrO =1b17 -----END PGP SIGNATURE----- From jsohn at netpia.com Tue Jan 20 20:41:22 2004 From: jsohn at netpia.com (Jason Sohn) Date: Wed, 21 Jan 2004 04:41:22 +0900 Subject: [address-policy-wg] test Message-ID: <03ae01c3df8d$63a13d40$7701a8c0@jason> CONFIDENTIALITY NOTICE: This transmission is only for the intended recipient(s). The information contained in this correspondence is confidential. If you are not the intended recipient, you are hereby kindly notified that any dissemination, distribution, copying, or use of this communication is strictly prohibited. If you have received this transmission in error, please notify me immediately and permanently delete this transmission and any attachments. Thank you. No warranty is made that any attachment is free from viruses or other defects, and no responsibility for the consequences arising therefrom will be accepted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwkckid1 at ix.netcom.com Tue Jan 20 22:56:10 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 20 Jan 2004 13:56:10 -0800 Subject: [address-policy-wg] Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region References: <20040120191437P.izumi@nic.ad.jp> Message-ID: <400DA3F9.6F26B8B2@ix.netcom.com> Izumi and all, > Hi German and Anne, > > Thanks for the clarification. > > If the v6 policy is to be "co-ordinated" but not unique, I agree that > it is sufficient to announce the consensus in the global ML, but my > understanding is different. > > I thought that all the RIRs share a single policy document for IPv6 > and may create supplmentary documents/fringe policies to accomodate > minor differences. Based on this context, I assumed that any major > changes in the policy document requires consensus of the global > community, and not only within the region. I agree that your assumption regarding v6 or for that matter v4 regarding major allocation policy requires or should require a measured consensus by all of the participating stakeholders/users. > > > It is my understanding that the extent of regional differences > accomodated in the v6 policy had never been publicly discussed nor > stated. All I want to do is clarify this part, which was why I wished > to confirm whether there had been any agreement among the RIRs. Seems to me from following these ML's that the RIR's staff are making or attempting to make policy without any or adequate verifiable measured consensus of the participating stakeholders/users. I know our members in the different regions feel this way and I have ask for but not yet received any confirmation of a demonstrated measured consensus documentation from all regions.. > > > Let me emphasise once again that I am not against the idea of having a > regional policy. I also understand that the LACNIC community has good > reasons to implement the policy change. The policy change that the STAFF of LACNIC has been proportion is needed and/or desired has to my knowledge not reached a participating stakeholder/user measured consensus. > > > If either all RIRs, or the global community thinks it's fine to have a > regional policy and this has been clearly stated, I don't have any > problem about the LACNIC community implementing its own policy. It should and in our members view, that any or all regions that are seeking a regional policy regarding v6 or v4 allocations, must have the measured consensus of the stakeholder/users in those regions. To date none do that I am aware of or have been shown as legitimately documented. > > > Could I assume that we all agree about having regional policies in > IPv6? (I'd interpret this as not only apply to LACNIC but also to > other RIRs) No we don't all agree that there should be regional policies for v6 in as much as minimum allocations as far as I can tell... > > > Izumi > > From: Anne Lord > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > Date: Tue, 20 Jan 2004 15:04:35 +1000 (EST) > > > > > Hi Izumi, Kosuke, > > > > > Could I confirm once again that this was the concious > > > decision(acknowledgement) made by all RIRs, having considered its > > > implications? > > > > I think German has replied to this question and I think the reply > > from the APNIC Secretariat will be similar. > > > > This was *not* part of a concious decision or acknowledgement made > > by all the RIRs. The decision flowed from the LACNIC community > > proposing and accepting the proposal as meeting a 'need' in their > > region. > > > > It is useful to observe that this policy is globally co-ordinated > > rather than a global policy: there were never any agreements by > > any RIR staff that there would be a single global policy. Actually > > APNIC EC has taken a decision to interpret one aspect of the policy > > in a way that differs from the other regions. See: > > > > http://www.apnic.net/docs/policy/ipv6-policy-clarification.html > > > > I also see this and the LACNIC change as part of the normal globally > > co-ordinated policy development processes. My understanding is that > > the reason that LACNIC announced their consensus on the global-v6 policy > > discussion list, was in order to collect feedback from the other > > regions, and if necessary to re-asses the consensus decision. > > In other words, this was an attempt to look at the global context > > and to co-ordinate. > > > > Also please feel welcome to bring the proposed change, and this > > discussion to the agenda of the Policy SIG at the forthcoming > > APNIC Open Policy Meeting. > > > > Best wishes, > > > > Anne > > -- > > > > > From: Kosuke Ito > > > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > Date: Sun, 18 Jan 2004 12:08:36 +0900 > > > > > > > > > > > Hi, German and all > > > > > > > > I do understand that LACNIC community like to have their > > > > own "bootstrap" condition for deploying IPv6 in LACNIC > > > > region, but I do NOT like to have it with an open jaw > > > > condition, anyway. > > > > > > > > And, I would like to know other RIRs people's view on > > > > this matter, and how LACNIC consider the possible side > > > > effect to the global community once the LACNIC special > > > > condition is implemented. > > > > I believe that RIRs/NIRs community should have a single > > > > view (even though each region has a different need) on > > > > the global coordinated policy like the IPv6 policy which > > > > was built up on the large amount of efforts balancing many > > > > factors from the global point of view, since the IP address > > > > space is a global resourse shared accross the globe. > > > > And RIRs/NIRs, I personally believe, should set a allowance > > > > of changing the global policy to accomodate a local need. > > > > When it needs to change (locally), possible effects after > > > > the change should be discussed from the global resourse > > > > management point of view at the same time. > > > > > > > > I would not like to see avalanche multiplication on relaxing > > > > the allocation conditions initiating from LACNIC to all other > > > > regions... This is my worry. > > > > > > > > Regards, > > > > > > > > Kosuke > > > > > > > > > > > > Jeff Williams wrote: > > > > > German and all, > > > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > > does seek such input, that the desires and requirements of those > > > > > participating stakeholders/users will be adheared to in a responsible > > > > > and direct way? > > > > > > > > > > German Valdez wrote: > > > > > > > > > > > > > > >>Hi Izumi > > > > >> > > > > >>sorry for delay > > > > >> > > > > >>It is intention of the RIR to work in common policies, like the IPv6 > > > > one, > > > > >>when this is possible. > > > > >> > > > > >>Nevertheless, this IPv6 policy proposal is the result of a regional > > > > need. > > > > >>So far has accomplished all the step of our Policy Development Process. > > > > >> > > > > >>Even though common policies may work well they are not bindig for the > > > > RIR. > > > > >> > > > > >>We are aware that this proposal is broken a common policy. For this > > > > reason > > > > >>we are sharing this criteria with the Global IPv6 community. > > > > >> > > > > >>This 45 days period of comment (which ends at january 23rd) is not > > > > part of > > > > >>the policy development process, however is a faculty of LACNIC's > > > > Board to > > > > >>do this. The reason was to recieve more comments from the global > > > > community > > > > >>before the Board made a decision. > > > > >> > > > > >>Regards > > > > >> > > > > >>German Valdez > > > > >>Policy Liaison > > > > >>LACNIC > > > > >> > > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > > >> > > > > >>>It had been my understanding that IPv6 policy would be co-ordinated > > > > >>>among the RIRs, but this seems to imply a regional policy like IPv4. > > > > >>> > > > > >>>That's also one method of the policy process that's proved to work > > > > >>>well, but it should at least be a concious decision by the RIRs(or its > > > > >>>communities). > > > > >>> > > > > >>>Could someone from the RIRs share the position about this? > > > > >>> > > > > >>>Izumi > > > > >>>JPNIC > > > > >>> > > > > >>>From: German Valdez > > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > > >>> > > > > >>> > > > > >>>> > > > > >>>>FYI LACNIC is calling for last comments for new policies to be applied > > > > >>> > > > > >>>next > > > > >>> > > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > > allocation. > > > > >>>> > > > > >>>>This proposal is the result of the analysis of the LACNIC IPv6 WG > > > > and the > > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > > >>>> > > > > >>>>You can review this proposal at http://lacnic.net/en/last-call.html > > > > >>>> > > > > >>>>On december 9th we started a 45 days period for comments for these > > > > >>>>policies, including the IPv6 one. Comments will be received > > > > through our > > > > >>>>policy public list politicas at lacnic.net, subscription to this list > > > > is open > > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > > >>>> > > > > >>>>Regards > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>German Valdez > > > > >>>>Policy Liaison > > > > >>>>LACNIC > > > > >>>> > > > > >>>>_______________________________________________ > > > > >>>>global-v6 mailing list > > > > >>>>global-v6 at lists.apnic.net > > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >>>> > > > > >>> > > > > >>>_______________________________________________ > > > > >>>global-v6 mailing list > > > > >>>global-v6 at lists.apnic.net > > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > >> > > > > >>_______________________________________________ > > > > >>global-v6 mailing list > > > > >>global-v6 at lists.apnic.net > > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > 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 at ix.netcom.com > > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > > > > _______________________________________________ > > > > > global-v6 mailing list > > > > > global-v6 at lists.apnic.net > > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > > > > > > -- > > > > **********IPv6 Internet Wonderland!************ > > > > Kosuke Ito, Master Planning and Steering Group > > > > IPv6 Promotion Council of Japan > > > > (Visiting Researcher, SFC Lab. KEIO University) > > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > > Cell:+81-90-4605-4581 > > > > mailto: kosuke at v6pc.jp http://www.v6pc.jp/ > > > > Lifetime e-mail: kosuke at stanfordalumni.org > > > > > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6 at lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6 at lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > > > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From jwkckid1 at ix.netcom.com Tue Jan 20 10:18:51 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 20 Jan 2004 01:18:51 -0800 Subject: [address-policy-wg] [apnic-talk]Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region References: Message-ID: <400CF27A.F49E45CF@ix.netcom.com> Anne and all, Anne Lord wrote: > Hi Izumi, Kosuke, > > > Could I confirm once again that this was the concious > > decision(acknowledgement) made by all RIRs, having considered its > > implications? > > I think German has replied to this question and I think the reply > from the APNIC Secretariat will be similar. I did not see Germans answer to this question nor to mine I ask him below on this thread. I also checked the archives and also cannot find his answer. The APNIC Secretariat's answer was indirect and cryptic in nature as it does not reflect the needs of the stakeholders/users of the regions community that can be demonstrated. I did request some evidence of such demonstrated/measured consensus, of the secretariat, but after two days, none has been forthcoming... > > > This was *not* part of a concious decision or acknowledgement made > by all the RIRs. The decision flowed from the LACNIC community > proposing and accepting the proposal as meeting a 'need' in their > region. > > It is useful to observe that this policy is globally co-ordinated > rather than a global policy: there were never any agreements by > any RIR staff that there would be a single global policy. Actually > APNIC EC has taken a decision to interpret one aspect of the policy > in a way that differs from the other regions. See: > > http://www.apnic.net/docs/policy/ipv6-policy-clarification.html Ah yes well as has already been observed and recently discussed, this "Clarification" has been refuted... > > > I also see this and the LACNIC change as part of the normal globally > co-ordinated policy development processes. My understanding is that > the reason that LACNIC announced their consensus on the global-v6 policy > discussion list, was in order to collect feedback from the other > regions, and if necessary to re-asses the consensus decision. > In other words, this was an attempt to look at the global context > and to co-ordinate. It is almost always a wise idea to co-ordinate between and with any or all regions. However one ML for doing so is not shown to be adequate for accomplishing said co-ordination... > > > Also please feel welcome to bring the proposed change, and this > discussion to the agenda of the Policy SIG at the forthcoming > APNIC Open Policy Meeting. > > Best wishes, > > Anne > -- > > > From: Kosuke Ito > > Subject: Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > Date: Sun, 18 Jan 2004 12:08:36 +0900 > > > > > > > > Hi, German and all > > > > > > I do understand that LACNIC community like to have their > > > own "bootstrap" condition for deploying IPv6 in LACNIC > > > region, but I do NOT like to have it with an open jaw > > > condition, anyway. > > > > > > And, I would like to know other RIRs people's view on > > > this matter, and how LACNIC consider the possible side > > > effect to the global community once the LACNIC special > > > condition is implemented. > > > I believe that RIRs/NIRs community should have a single > > > view (even though each region has a different need) on > > > the global coordinated policy like the IPv6 policy which > > > was built up on the large amount of efforts balancing many > > > factors from the global point of view, since the IP address > > > space is a global resourse shared accross the globe. > > > And RIRs/NIRs, I personally believe, should set a allowance > > > of changing the global policy to accomodate a local need. > > > When it needs to change (locally), possible effects after > > > the change should be discussed from the global resourse > > > management point of view at the same time. > > > > > > I would not like to see avalanche multiplication on relaxing > > > the allocation conditions initiating from LACNIC to all other > > > regions... This is my worry. > > > > > > Regards, > > > > > > Kosuke > > > > > > > > > Jeff Williams wrote: > > > > German and all, > > > > > > > > I wonder when if ever LACNIC will be seeking advisory input from > > > > the stakeholders/users in their region? I also wonder if LACNIC > > > > does seek such input, that the desires and requirements of those > > > > participating stakeholders/users will be adheared to in a responsible > > > > and direct way? > > > > > > > > German Valdez wrote: > > > > > > > > > > > >>Hi Izumi > > > >> > > > >>sorry for delay > > > >> > > > >>It is intention of the RIR to work in common policies, like the IPv6 > > > one, > > > >>when this is possible. > > > >> > > > >>Nevertheless, this IPv6 policy proposal is the result of a regional > > > need. > > > >>So far has accomplished all the step of our Policy Development Process. > > > >> > > > >>Even though common policies may work well they are not bindig for the > > > RIR. > > > >> > > > >>We are aware that this proposal is broken a common policy. For this > > > reason > > > >>we are sharing this criteria with the Global IPv6 community. > > > >> > > > >>This 45 days period of comment (which ends at january 23rd) is not > > > part of > > > >>the policy development process, however is a faculty of LACNIC's > > > Board to > > > >>do this. The reason was to recieve more comments from the global > > > community > > > >>before the Board made a decision. > > > >> > > > >>Regards > > > >> > > > >>German Valdez > > > >>Policy Liaison > > > >>LACNIC > > > >> > > > >>At 12:07 AM 1/7/2004, Izumi Okutani wrote: > > > >> > > > >>>It had been my understanding that IPv6 policy would be co-ordinated > > > >>>among the RIRs, but this seems to imply a regional policy like IPv4. > > > >>> > > > >>>That's also one method of the policy process that's proved to work > > > >>>well, but it should at least be a concious decision by the RIRs(or its > > > >>>communities). > > > >>> > > > >>>Could someone from the RIRs share the position about this? > > > >>> > > > >>>Izumi > > > >>>JPNIC > > > >>> > > > >>>From: German Valdez > > > >>>Subject: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region > > > >>>Date: Thu, 11 Dec 2003 08:16:29 -0300 > > > >>> > > > >>> > > > >>>> > > > >>>>FYI LACNIC is calling for last comments for new policies to be applied > > > >>> > > > >>>next > > > >>> > > > >>>>year. One of this policies is a new criteria for IPv6 Initial > > > allocation. > > > >>>> > > > >>>>This proposal is the result of the analysis of the LACNIC IPv6 WG > > > and the > > > >>>>discussion held during our Open Policy Forum in The Havana, Cuba > > > >>>> > > > >>>>You can review this proposal at http://lacnic.net/en/last-call.html > > > >>>> > > > >>>>On december 9th we started a 45 days period for comments for these > > > >>>>policies, including the IPv6 one. Comments will be received > > > through our > > > >>>>policy public list politicas at lacnic.net, subscription to this list > > > is open > > > >>>>at http://lacnic.net/en/lists.html. Any comments are welcomed. > > > >>>> > > > >>>>Regards > > > >>>> > > > >>>> > > > >>>> > > > >>>>German Valdez > > > >>>>Policy Liaison > > > >>>>LACNIC > > > >>>> > > > >>>>_______________________________________________ > > > >>>>global-v6 mailing list > > > >>>>global-v6 at lists.apnic.net > > > >>>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > >>>> > > > >>> > > > >>>_______________________________________________ > > > >>>global-v6 mailing list > > > >>>global-v6 at lists.apnic.net > > > >>>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > >> > > > >>_______________________________________________ > > > >>global-v6 mailing list > > > >>global-v6 at lists.apnic.net > > > >>http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > 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 at ix.netcom.com > > > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > > > > _______________________________________________ > > > > global-v6 mailing list > > > > global-v6 at lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > > > > > > > > > > -- > > > **********IPv6 Internet Wonderland!************ > > > Kosuke Ito, Master Planning and Steering Group > > > IPv6 Promotion Council of Japan > > > (Visiting Researcher, SFC Lab. KEIO University) > > > Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 > > > Cell:+81-90-4605-4581 > > > mailto: kosuke at v6pc.jp http://www.v6pc.jp/ > > > Lifetime e-mail: kosuke at stanfordalumni.org > > > > > > > > > > > > _______________________________________________ > > > global-v6 mailing list > > > global-v6 at lists.apnic.net > > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > > > > _______________________________________________ > > global-v6 mailing list > > global-v6 at lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/global-v6 > > > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ apnic-talk mailing list apnic-talk at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk From kurtis at kurtis.pp.se Wed Jan 21 08:05:53 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 21 Jan 2004 08:05:53 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region In-Reply-To: <400DA3F9.6F26B8B2@ix.netcom.com> References: <20040120191437P.izumi@nic.ad.jp> <400DA3F9.6F26B8B2@ix.netcom.com> Message-ID: <40A4EF22-4BE0-11D8-BCF8-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-20, at 22.56, Jeff Williams wrote: >> >> It is my understanding that the extent of regional differences >> accomodated in the v6 policy had never been publicly discussed nor >> stated. All I want to do is clarify this part, which was why I wished >> to confirm whether there had been any agreement among the RIRs. > > Seems to me from following these ML's that the RIR's staff are > making or attempting to make policy without any or adequate > verifiable measured consensus of the participating stakeholders/users. > I know our members in the different regions feel this way and I have > ask for but not yet received any confirmation of a demonstrated > measured consensus documentation from all regions.. > How many of you members are going to the RIPE meeting next week? How many of your members are registered as LIRs in the RIPE region? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQA4k1aarNKXTPFCVEQKYuwCdEuSz9vYPcw4jXKa46hapn6wT2VkAoMue vcsiTZrmRnJygAr4YHHuWFUv =hQdE -----END PGP SIGNATURE----- From jwkckid1 at ix.netcom.com Wed Jan 21 10:24:15 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 21 Jan 2004 01:24:15 -0800 Subject: [address-policy-wg] Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region References: <20040120191437P.izumi@nic.ad.jp> <400DA3F9.6F26B8B2@ix.netcom.com> <40A4EF22-4BE0-11D8-BCF8-000A95928574@kurtis.pp.se> Message-ID: <400E453E.638C65FD@ix.netcom.com> Kurt and all, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2004-01-20, at 22.56, Jeff Williams wrote: > > >> > >> It is my understanding that the extent of regional differences > >> accomodated in the v6 policy had never been publicly discussed nor > >> stated. All I want to do is clarify this part, which was why I wished > >> to confirm whether there had been any agreement among the RIRs. > > > > Seems to me from following these ML's that the RIR's staff are > > making or attempting to make policy without any or adequate > > verifiable measured consensus of the participating stakeholders/users. > > I know our members in the different regions feel this way and I have > > ask for but not yet received any confirmation of a demonstrated > > measured consensus documentation from all regions.. > > > > How many of you members are going to the RIPE meeting next week? I have no idea actually. Some will be for sure.. > How > many of your members are registered as LIRs in the RIPE region? First the members of our organization are no MY members.. I also don't have a clue here either for sure. I can find out I suppose. I know there are several... > > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQA4k1aarNKXTPFCVEQKYuwCdEuSz9vYPcw4jXKa46hapn6wT2VkAoMue > vcsiTZrmRnJygAr4YHHuWFUv > =hQdE > -----END PGP SIGNATURE----- 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From kurtis at kurtis.pp.se Wed Jan 21 08:41:31 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 21 Jan 2004 08:41:31 +0100 Subject: [address-policy-wg] Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region In-Reply-To: <400E453E.638C65FD@ix.netcom.com> References: <20040120191437P.izumi@nic.ad.jp> <400DA3F9.6F26B8B2@ix.netcom.com> <40A4EF22-4BE0-11D8-BCF8-000A95928574@kurtis.pp.se> <400E453E.638C65FD@ix.netcom.com> Message-ID: <3AD3BAD6-4BE5-11D8-BCF8-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-21, at 10.24, Jeff Williams wrote: >> >> How many of you members are going to the RIPE meeting next week? > > I have no idea actually. Some will be for sure.. > Good. So if they don't like the policy as it stands, the mikes are open! There, done. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQA4tMqarNKXTPFCVEQI4RwCeOhTppcO/tGITp7bdUeJy1k5IwkMAoLWn 9Grg3AbgcNblbWci0ih0zz8Y =7OVa -----END PGP SIGNATURE----- From jwkckid1 at ix.netcom.com Wed Jan 21 11:05:42 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 21 Jan 2004 02:05:42 -0800 Subject: [address-policy-wg] Re: [GLOBAL-V6]IPv6 Policy Proposal for LACNIC Region References: <20040120191437P.izumi@nic.ad.jp> <400DA3F9.6F26B8B2@ix.netcom.com> <40A4EF22-4BE0-11D8-BCF8-000A95928574@kurtis.pp.se> <400E453E.638C65FD@ix.netcom.com> <3AD3BAD6-4BE5-11D8-BCF8-000A95928574@kurtis.pp.se> Message-ID: <400E4EF5.9F18878@ix.netcom.com> Kurt and all, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2004-01-21, at 10.24, Jeff Williams wrote: > > >> > >> How many of you members are going to the RIPE meeting next week? > > > > I have no idea actually. Some will be for sure.. > > > > Good. So if they don't like the policy as it stands, the mikes are open! Good! As I am the elected spokesman for our organization I have already provided our concerns and interests for the respective regions.. > > > There, done. Also done and more likely to come... > > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQA4tMqarNKXTPFCVEQI4RwCeOhTppcO/tGITp7bdUeJy1k5IwkMAoLWn > 9Grg3AbgcNblbWci0ih0zz8Y > =7OVa > -----END PGP SIGNATURE----- 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From adiel at akplogan.net Tue Jan 20 19:58:45 2004 From: adiel at akplogan.net (Adiel AKPLOGAN) Date: Tue, 20 Jan 2004 19:58:45 +0100 Subject: [address-policy-wg] AfriNIC Transition: IPv4 allocation Policy change In-Reply-To: <400B3EB7.7CBA952B@ix.netcom.com> References: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> <400B3EB7.7CBA952B@ix.netcom.com> Message-ID: <6.0.0.22.0.20040120174918.03f70348@pop.mail.yahoo.fr> Hello Jeff, > Have you put your proposal before the stakeholders/users in your >region? If so is their a measured consensus. Yes we had many informal discussion with ISPs in our region about it and most of them seems that as a good thin to do to make the allocation coherent with the size of the region ISPs. But let me also point out here that the main idea behind this proposal is the harmonization of the applied policies in our region. This will ease the transition process. Changing IPv4 minimum allocation size for African members in RIPE NCC will make the size uniform with what is done in ARIN region for example. >I know that until now, none of our members in your region have heard of your >proposal. Thank you for providing in here and now though.I am sure our >members will review it and determine if it is acceptable or offer an >alternative.. ok - a. > > IPv4 Allocation Policy for the African Portion of the RIPE NCC service > > Region: > > > > The motivation behind this is that today there are three different > > policies applied to African LIRs: (ARIN, RIPE NCC, APNIC). To ease the > > transition to AfriNIC (the registry for Africa) policies need to be > > harmonized. The ARIN Community has already taken a step by creating a > > particular policy for its African members. It will be a good step if > > the RIPE community can do the same for its African Members by making > > the minimum allocation the same. > > > > The proposed policy change below is for those operating in Africa. It > > is intended as an interim, transitional policy during the period > > before AfriNIC takes on the RIR function for the African > > continent. From that time the policies agreed at the AfriNIC-I meeting > > will be used in Africa. > > > > Also we should keep in mind that this will only affect the IP block > > 196.200/13 used by RIPE NCC to allocate address in Africa. BGP filters > > then need to be adapted to permit longer prefix (/22) only in this > > block. > > > > Proposed change: > > > > * Minimum allocation: The minimum allocation for African members of > > RIPE NCC should be changed from /21 to /22. > > > > _______________________________________________________________________ > > Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 > > RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 > > Singel 258 - 1016AB Amsterdam - NL www.ripe.net > > > > ------------------------------------------------------------------------ > > > > Part 1.2 Type: Plain Text (text/plain) > >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 at ix.netcom.com >Contact Number: 214-244-4827 or 214-244-3801 > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004 _______________________________________________________________________ Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 Singel 258 - 1016AB Amsterdam - NL www.ripe.net -------------- next part -------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004 From Joao_Damas at isc.org Wed Jan 21 13:48:16 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 21 Jan 2004 13:48:16 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> Message-ID: <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> On 20 Jan, 2004, at 20:07, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Joao, > > On 2004-01-20, at 16.50, Joao Damas wrote: > >> This goal could very well be achieved by keeping the addresses of the >> servers you are already using and migrating all other active IP's out >> of the /24 that contains the address you want to "anycast". After all, >> none of the root servers that are anycasting today have renumbered >> (one that is not anycasting today will renumber soon because they >> can't apply what I just described, which was unfortunate). >> > > This was actually spelled out as a problem with NEW services (TLDs) > moving to anycast. That is people who do not have their own addresses > at all at this point. No, it was spelt as a new deployment strategy for a running service. In particular the proponent does have address space already though this should not have impact on the discussion. In any case, the point is that the problem is a policy one: obtaining a /24 in which there will be only a few (<5) active IPs. It is not a routing issue. In addition, in some cases, this can be worked around by moving service IPs around until you have a clean /24 for this sort of use. Last, Gert missed the point by reducing the discussion to only the /24 that would be used for the service IP, because with anycast you will always need a different IP address to be able to access each of the anycast instances, and as for the service /24, some people may be able to work around this using address space they already have and some will not, so any policy discussion needs to take into account both requirements as they are not independent. Joao From gert at space.net Wed Jan 21 14:03:25 2004 From: gert at space.net (Gert Doering) Date: Wed, 21 Jan 2004 14:03:25 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> Message-ID: <20040121130325.GK30954@Space.Net> Hi, On Wed, Jan 21, 2004 at 01:48:16PM +0100, Joao Damas wrote: > In addition, in some cases, this can be worked around by moving service > IPs around until you have a clean /24 for this sort of use. > Last, Gert missed the point by reducing the discussion to only the /24 > that would be used for the service IP, because with anycast you will > always need a different IP address to be able to access each of the > anycast instances, To the contrary. *This* can (and should) be done with PA space, as for any other machine round the world that needs remote access. There is nothing special about the administrative IP, so there is *no* need to do *anything* special in the policy here. > and as for the service /24, some people may be able > to work around this using address space they already have and some will > not, so any policy discussion needs to take into account both > requirements as they are not independent. Strong disagreement. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jwkckid1 at ix.netcom.com Thu Jan 22 03:28:54 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 21 Jan 2004 18:28:54 -0800 Subject: [address-policy-wg] AfriNIC Transition: IPv4 allocation Policy change References: <6.0.0.22.0.20040118120045.03f5e3c0@pop.mail.yahoo.fr> <400B3EB7.7CBA952B@ix.netcom.com> <6.0.0.22.0.20040120174918.03f70348@pop.mail.yahoo.fr> Message-ID: <400F3565.3FB88997@ix.netcom.com> Adiel and all, Adiel AKPLOGAN wrote: > Hello Jeff, > > > Have you put your proposal before the stakeholders/users in your > >region? If so is their a measured consensus. > > Yes we had many informal discussion with ISPs in our region about it and > most of them seems that as a good thin to do to make the allocation > coherent with the size of the region ISPs. Ok and were are the numbers of the ISPs and/or the documented evidence to quantify this? When was this done? > > > But let me also point out here that the main idea behind this proposal is > the harmonization of the applied policies in our region. This will ease the > transition process. Changing IPv4 minimum allocation size for African > members in RIPE NCC will make the size uniform with what is done in ARIN > region for example. Well, ARIN has yet to justify their stated Executive created policy... > > > >I know that until now, none of our members in your region have heard of your > >proposal. Thank you for providing in here and now though.I am sure our > >members will review it and determine if it is acceptable or offer an > >alternative.. > > ok > > - a. > > > > IPv4 Allocation Policy for the African Portion of the RIPE NCC service > > > Region: > > > > > > The motivation behind this is that today there are three different > > > policies applied to African LIRs: (ARIN, RIPE NCC, APNIC). To ease the > > > transition to AfriNIC (the registry for Africa) policies need to be > > > harmonized. The ARIN Community has already taken a step by creating a > > > particular policy for its African members. It will be a good step if > > > the RIPE community can do the same for its African Members by making > > > the minimum allocation the same. > > > > > > The proposed policy change below is for those operating in Africa. It > > > is intended as an interim, transitional policy during the period > > > before AfriNIC takes on the RIR function for the African > > > continent. From that time the policies agreed at the AfriNIC-I meeting > > > will be used in Africa. > > > > > > Also we should keep in mind that this will only affect the IP block > > > 196.200/13 used by RIPE NCC to allocate address in Africa. BGP filters > > > then need to be adapted to permit longer prefix (/22) only in this > > > block. > > > > > > Proposed change: > > > > > > * Minimum allocation: The minimum allocation for African members of > > > RIPE NCC should be changed from /21 to /22. > > > > > > _______________________________________________________________________ > > > Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 > > > RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 > > > Singel 258 - 1016AB Amsterdam - NL www.ripe.net > > > > > > ------------------------------------------------------------------------ > > > > > > Part 1.2 Type: Plain Text (text/plain) > > > >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 at ix.netcom.com > >Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > >--- > >Incoming mail is certified Virus Free. > >Checked by AVG anti-virus system (http://www.grisoft.com). > >Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004 > > _______________________________________________________________________ > Adiel A. AKPLOGAN Off. +31 (0)20 535 4444 > RIPE NCC - AfriNIC project Manager Fax: +31 (0)20 535 4445 > Singel 258 - 1016AB Amsterdam - NL www.ripe.net > > ------------------------------------------------------------------------ > > Part 1.2 Type: Plain Text (text/plain) 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From axel.pawlik at ripe.net Thu Jan 22 17:45:34 2004 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Thu, 22 Jan 2004 17:45:34 +0100 Subject: [address-policy-wg] Call for Nominations to the ICANN Board of Directors Message-ID: <5.2.0.9.2.20040122165146.02722438@localhost> Dear colleagues, We are pleased to announce a Call for Nominations to the ICANN Board of Directors (see below). In our effort to reach as many interested parties as possible you may receive multiple copies of this message. Please accept our apologies for this. The Call for Nominations for ICANN Board of Directors and current appointments to the Board can be found on the ASO website at: http://www.aso.icann.org/ A publicly archived "expressions of support" form will be made available on the ASO website for those that wish to support nominated candidates. Kind regards, Axel Pawlik RIPE NCC ---- ASO General Assembly 2004 and Call for Nominations for ICANN Board of Directors The Address Council of the Address Supporting Organisation is pleased to announce the 5th ASO General Assembly Meeting, to be held on Wednesday, 5 May 2004 in Amsterdam, The Netherlands. This meeting will be hosted by the RIPE NCC alongside the RIPE 47 Meeting and will be open to all parties with an interest in ASO policy matters. A detailed meeting agenda will be published in due course on the ASO web site at: http://www.aso.icann.org. In compliance with the ASO MoU , the Address Council and ICANN hereby call for nominations to the ICANN Board to fill vacant ASO seats on the ICANN Board. The next such seat scheduled to become vacant in May 2004 is currently occupied by Mr Lyman Chapin. However, candidates nominated at this time may also be chosen to fill other seats that may become vacant before or after this time. Note that appointments to the ICANN Board must satisfy the geographic diversity contraints specified in section 3c. of the ASO MoU. Nominees from North America, South America and Europe are eligible this time. Any individual may be nominated within this process, with the exception of any official of a national government or a multinational entity established by treaty or other agreement between national governments (ICANN Bylaws Art. VI., Sec 4). Self-nominations are permitted. Nominations should be sent by e-mail to and should state the following details : A. Nominee details 1. Full name 2. Organisational affiliation 3. Email address 4. Physical address 5. Country of residence 6. Telephone contact 7. Biography B. Details of nominating individual 1. Full name 2. Organisational affiliation 3. Email address 4. Country of residence Nominations must be submitted in English and must be received by the ASO Secretariat before 0900 UTC, 20 April 2004. All nominees will be contacted via e-mail to confirm their willingness to serve as an ICANN Director. If the nominee is not contactable via email then the nomination will not be confirmed, a nominee must explicitly confirm the nomination to the ASO Secretariat to be considered as a candidate. All confirmed nominations will be listed on the ASO website (see http://www.aso.icann.org) as soon as they are confirmed. Those wishing to express support for any individuals who have been nominated should use the "ICANN Board - Support of Nomination" Form which will be made available on the ASO website. The list of nominated individuals and the supporting comments will be passed to the Address Council after all nominees are confirmed, and prior to the General Assembly meeting on 5 May 2004, 16:00 - 18:30. More information regarding the ASO GA and nominations process will be posted on the ASO website in due course. From Joao_Damas at isc.org Fri Jan 23 14:15:33 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 23 Jan 2004 14:15:33 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040121130325.GK30954@Space.Net> References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> <20040121130325.GK30954@Space.Net> Message-ID: <39ABCB1E-4DA6-11D8-84CE-000A959B2120@isc.org> On 21 Jan, 2004, at 14:03, Gert Doering wrote: > Hi, > > On Wed, Jan 21, 2004 at 01:48:16PM +0100, Joao Damas wrote: >> In addition, in some cases, this can be worked around by moving >> service >> IPs around until you have a clean /24 for this sort of use. >> Last, Gert missed the point by reducing the discussion to only the /24 >> that would be used for the service IP, because with anycast you will >> always need a different IP address to be able to access each of the >> anycast instances, > > To the contrary. *This* can (and should) be done with PA space, It may or it may not be possible. When anycasting a service you want to keep the origin ASN the same, so you need your own routing infrastructure, separating your anycasted equipment from that of the rest of the net. This means that the management addresses will be inside that separate routing infrastructure and so your statement "can and should" can not and should not be made a pre-condition. > as for > any other machine round the world that needs remote access. There is > nothing special about the administrative IP, so there is *no* need to > do *anything* special in the policy here. > >> and as for the service /24, some people may be able >> to work around this using address space they already have and some >> will >> not, so any policy discussion needs to take into account both >> requirements as they are not independent. > > Strong disagreement. > See above Joao From gert at space.net Fri Jan 23 14:20:41 2004 From: gert at space.net (Gert Doering) Date: Fri, 23 Jan 2004 14:20:41 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <39ABCB1E-4DA6-11D8-84CE-000A959B2120@isc.org> References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> <20040121130325.GK30954@Space.Net> <39ABCB1E-4DA6-11D8-84CE-000A959B2120@isc.org> Message-ID: <20040123132041.GQ30954@Space.Net> Hi, On Fri, Jan 23, 2004 at 02:15:33PM +0100, Joao Damas wrote: > >>IPs around until you have a clean /24 for this sort of use. > >>Last, Gert missed the point by reducing the discussion to only the /24 > >>that would be used for the service IP, because with anycast you will > >>always need a different IP address to be able to access each of the > >>anycast instances, > > > >To the contrary. *This* can (and should) be done with PA space, > > It may or it may not be possible. When anycasting a service you want to > keep the origin ASN the same, so you need your own routing > infrastructure, separating your anycasted equipment from that of the > rest of the net. This means that the management addresses will be > inside that separate routing infrastructure and so your statement "can > and should" can not and should not be made a pre-condition. This is certainly one way to setup things. But even so there is no reason not to use PA space for the management side of things - announcing the PA block to your host network, if you feel like having to announce the management IPs somewhere, but no reason to pollute the global table with local information. > >Strong disagreement. > See above Indeed :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Joao_Damas at isc.org Fri Jan 23 16:01:58 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 23 Jan 2004 16:01:58 +0100 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure In-Reply-To: <20040123132041.GQ30954@Space.Net> References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> <20040121130325.GK30954@Space.Net> <39ABCB1E-4DA6-11D8-84CE-000A959B2120@isc.org> <20040123132041.GQ30954@Space.Net> Message-ID: <1755734E-4DB5-11D8-84CE-000A959B2120@isc.org> On 23 Jan, 2004, at 14:20, Gert Doering wrote: > Hi, > > On Fri, Jan 23, 2004 at 02:15:33PM +0100, Joao Damas wrote: >>>> IPs around until you have a clean /24 for this sort of use. >>>> Last, Gert missed the point by reducing the discussion to only the >>>> /24 >>>> that would be used for the service IP, because with anycast you will >>>> always need a different IP address to be able to access each of the >>>> anycast instances, >>> >>> To the contrary. *This* can (and should) be done with PA space, >> >> It may or it may not be possible. When anycasting a service you want >> to >> keep the origin ASN the same, so you need your own routing >> infrastructure, separating your anycasted equipment from that of the >> rest of the net. This means that the management addresses will be >> inside that separate routing infrastructure and so your statement "can >> and should" can not and should not be made a pre-condition. > > This is certainly one way to setup things. > > But even so there is no reason not to use PA space for the management > side of things - announcing the PA block to your host network, if you > feel like having to announce the management IPs somewhere, but no > reason > to pollute the global table with local information. Remember that most people doing this will want to multihome the management part. Returning to the question at hand, it seems that anycast is here to stay. Critical infrastructure or not, this is a legitimate use of available technology to solve a particular problem which meets certain constraints coming from the current filtering BCPs that require the use of a certain minimum block of addresses (currently a /24, preferably from blocks where the minimum assignment is that size) for the service to be implemented independently of the number of active IP addresses in that block. Given these boundary conditions, policy needs to be adjusted to formally take into this legitimate use into account. Joao From jwkckid1 at ix.netcom.com Sat Jan 24 08:24:36 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Fri, 23 Jan 2004 23:24:36 -0800 Subject: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure References: <4FB3D903-4B60-11D8-9041-000A959B2120@psg.com> <1542CE8C-4C10-11D8-8794-000A959B2120@isc.org> <20040121130325.GK30954@Space.Net> <39ABCB1E-4DA6-11D8-84CE-000A959B2120@isc.org> <20040123132041.GQ30954@Space.Net> Message-ID: <40121DB4.FB2DD87E@ix.netcom.com> Gert and all, Gert Doering wrote: > Hi, > > On Fri, Jan 23, 2004 at 02:15:33PM +0100, Joao Damas wrote: > > >>IPs around until you have a clean /24 for this sort of use. > > >>Last, Gert missed the point by reducing the discussion to only the /24 > > >>that would be used for the service IP, because with anycast you will > > >>always need a different IP address to be able to access each of the > > >>anycast instances, > > > > > >To the contrary. *This* can (and should) be done with PA space, > > > > It may or it may not be possible. When anycasting a service you want to > > keep the origin ASN the same, so you need your own routing > > infrastructure, separating your anycasted equipment from that of the > > rest of the net. This means that the management addresses will be > > inside that separate routing infrastructure and so your statement "can > > and should" can not and should not be made a pre-condition. > > This is certainly one way to setup things. > > But even so there is no reason not to use PA space for the management > side of things - announcing the PA block to your host network, if you > feel like having to announce the management IPs somewhere, but no reason > to pollute the global table with local information. I think this depends on whether or not the local information is of a nature to critical infrastructure, which of course also requires a good definition as to what "critical infrastructure" is and is not. > > > > >Strong disagreement. > > See above > > Indeed :-) > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 58081 (57882) > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 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 at ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From salmon at netzquadrat.de Mon Jan 26 19:57:23 2004 From: salmon at netzquadrat.de (Thilo Salmon) Date: Mon, 26 Jan 2004 19:57:23 +0100 Subject: [address-policy-wg] (no subject) Message-ID: <1075143442.24413.809.camel@thilo> Hello everyone, when RIPE received 82/8 from IANA about a year ago, there has been a discussion on potential routing issues due to ancient filters on this list. That thread went far enough to raise the question whether or not subnets in question should be returned. Getting my daily fix of tech rants I noticed this issue appears to have resurfaced in the mainstream media at http://heise.de/newsticker/data/hob-26.01.04-000/ (German) http://translate.google.com/translate?hl=en&sl=de&u=http://heise.de/newsticker/data/hob-26.01.04-000/ (Google translation) We received a prefix from within this network which we plan to use soon and I am now wondering whether or not we can expect to run into problems. Going through a number of looking glasses I could see my announcement just fine. But then, ISPs who offer lookging glass services are probably more likely to keep their filters up to date. Has anybody used 82/8 subnets and gathered real life experience on how they route? I'd much rather be prepared, if this turns into a teaching assignment. Thilo From daniel.karrenberg at ripe.net Tue Jan 27 10:31:25 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 27 Jan 2004 10:31:25 +0100 Subject: [address-policy-wg] (no subject) In-Reply-To: <1075143442.24413.809.camel@thilo> References: <1075143442.24413.809.camel@thilo> Message-ID: <20040127093125.GJ476@reifa.local> On 26.01 19:57, Thilo Salmon wrote: > Hello everyone, > > when RIPE received 82/8 from IANA about a year ago, there has been a > discussion on potential routing issues due to ancient filters on this > list. That thread went far enough to raise the question whether or not > subnets in question should be returned. Getting my daily fix of tech > rants I noticed this issue appears to have resurfaced in the mainstream > media at > > http://heise.de/newsticker/data/hob-26.01.04-000/ (German) > http://translate.google.com/translate?hl=en&sl=de&u=http://heise.de/newsticker/data/hob-26.01.04-000/ > (Google translation) Well I'd call that a perfect example of "distributing responsibility". > We received a prefix from within this network which we plan to use soon > and I am now wondering whether or not we can expect to run into > problems. Going through a number of looking glasses I could see my > announcement just fine. But then, ISPs who offer lookging glass services > are probably more likely to keep their filters up to date. > > Has anybody used 82/8 subnets and gathered real life experience on how > they route? I'd much rather be prepared, if this turns into a teaching > assignment. You might have a look using the RIPE NCC service called RIS: http://www.ripe.net/ripencc/pub-services/np/ris/index.html more particular http://www.ris.ripe.net/cgi-bin/risprefix.cgi Looking for more specifics of 82/8 around midnight today yields more than 21k entries of 930 distinct prefixes. To me this means it is routed pretty ubiquitously. I will send you the file privately because it is more tham 2MB. Daniel From hpholen at tiscali.no Thu Jan 29 15:17:46 2004 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 29 Jan 2004 15:17:46 +0100 Subject: [address-policy-wg] Summary of actions from RIPE 47 address policy meeting Message-ID: <3FCCA815000229EF@cpfe6.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) Action Responsible Status 46.1 Chairs-WG Revise RIPE 152 (not allowed to charge for domain names), Done 46.4 Chairs Summarize and propose updated description of the policy process Completed 47.1 Chair Policy Development Process Form a task force to write a policy development process propposal 47.2 NCC RIPE 152 to Historical and recomed to the RIPE NCC to make a clear statement that they do not charge for IP addresses 47.3 Andreas B?? Anycast for CCTLD ? complete discussion on mailinglist to form formal proposal 47.4 Chair Afrinic proposal for /22 mimimum allocation size. Seek final consensus on the list Best Regards, Hans Petter Holen Chair From jwkckid1 at ix.netcom.com Fri Jan 30 04:04:47 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 29 Jan 2004 19:04:47 -0800 Subject: [address-policy-wg] Summary of actions from RIPE 47 address policy meeting References: <3FCCA815000229EF@cpfe6.be.tisc.dk> (added by postmaster@cpmail.dk.tiscali.com) Message-ID: <4019C9CE.7F0F4541@ix.netcom.com> Hans and all, Are members in the AFNIC region do not support a the proposed minimum allocation of a /22. Hans Petter Holen wrote: > Action Responsible Status > 46.1 Chairs-WG Revise RIPE 152 (not allowed to charge for > domain names), Done > > 46.4 Chairs Summarize and propose updated description of > the policy process Completed > > 47.1 Chair Policy Development Process > Form a task force to write a policy > development process propposal > > 47.2 NCC RIPE 152 to Historical and recomed to the > RIPE NCC to make a clear statement that > they do not charge for IP addresses > > 47.3 Andreas B?? Anycast for CCTLD ? complete discussion on > mailinglist to form formal proposal > > 47.4 Chair Afrinic proposal for /22 mimimum allocation > size. Seek final consensus on the list > > Best Regards, > Hans Petter Holen > Chair 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] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Contact Number: 214-244-4827