From contact at ripe.net Mon Jun 7 17:45:05 2004 From: contact at ripe.net (Membership Liaison Officer) Date: Mon, 07 Jun 2004 17:45:05 +0200 Subject: [address-policy-wg] Registration Deadline - RIPE NCC Regional Meeting, Moscow 16-18 June 2004 Message-ID: <5.2.1.1.2.20040607174302.02b26c10@mailhost.ripe.net> [Apologies for duplicate mails] Dear Colleagues, This is a final reminder that the RIPE NCC Regional Meeting in Moscow will be held 16-18 June 2004 at the Hotel Metropol, Moscow, Russia. Attendance to the RIPE NCC Regional Meeting is free of charge. However, attendees are responsible for covering their own travel and accommodation costs. REGISTRATION Please note that registration for the Regional Meeting closes on 9 June 2004. To register, please see: http://www.ripe.net/cgi-bin/moscow-reg AGENDA The agenda has been recently updated with more information about speakers and presentations. For the full agenda, please see: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/agenda.html MORE INFORMATION More information about the RIPE NCC Regional Meeting, Moscow is available from: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/ Any further questions can be sent directly to: . Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC From contact at ripe.net Mon Jun 7 18:17:56 2004 From: contact at ripe.net (Membership Liaison Officer) Date: Mon, 07 Jun 2004 18:17:56 +0200 Subject: [address-policy-wg] RIPE NCC Regional Meeting, Nairobi 28-30 July 2004 Message-ID: <5.2.1.1.2.20040607180949.02b19410@mailhost.ripe.net> Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting in Nairobi, to be held 28-30 July 2004. Details of the venue will follow shortly. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Registration for the Regional Meeting is open. To register, please see: http://www.ripe.net/cgi-bin/nairobi-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - How to participate in and influence IP address management policy-making; - AfriNIC - The emerging RIR; - Peering and Exchange Points; - Are we running out of IPv4 address space?; - An update on IPv6; - Domain Name management on the Internet; - Root Server Operations. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/agenda.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the region. The current draft meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Further information about the RIPE NCC and RIPE can be found at: http://www.ripe.net More information about the RIPE NCC Regional Meeting, Nairobi is available from: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/ Any further questions can be sent directly to: . Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC From baess at denic.de Tue Jun 8 12:17:35 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Tue, 8 Jun 2004 12:17:35 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: In the background I had some discussions with several people what is the best wording for the policy to reflect the discussions that we had on RIPE 47. I think the outcome of these discussions reflect pretty well what I can recall. So I would like to ask the workinggroup what you think. "Operators providing DNS for a zone that is approaching the UDP packet size limit due to the number of authoritative servers may be assigned PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These prefixes will allow them to anycast the DNS server, as described in RFC 3258." Have a nice day Andreas Baess -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess at denic.de From Joao_Damas at isc.org Tue Jun 8 16:48:13 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 8 Jun 2004 16:48:13 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: Message-ID: On 8 Jun, 2004, at 12:17, Andreas B??/Denic wrote: > In the background I had some discussions with several people what is > the > best > wording for the policy to reflect the discussions that we had on RIPE > 47. > > I think the outcome of these discussions reflect pretty well what I can > recall. > So I would like to ask the workinggroup what you think. > > "Operators providing DNS for a zone that is approaching the UDP packet > size limit due to the number of authoritative servers may be assigned > PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These > prefixes will allow them to anycast the DNS server, as described in RFC > 3258." > I would suggest a slight re-phrase: "Operators providing DNS for a zone served by a number of name servers such that the total response size when including the list of nameservers for the zone is close to the UDP packet size limit may be assigned PI network prefixes for the purpose of anycasting name servers, as described on RFC 3258. These shall be: a /24 IPv4 prefix and/or a /32 IPv6 prefix." Given that the issue is the will to anycast due to the operational impact of adding more servers to the list, not just the size of the NS RRSET itself. Also, pardon me asking but would the request be for a /24 per server to be anycasted of a /24 per zone administrator? Joao From baess at denic.de Wed Jun 9 11:28:33 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Wed, 9 Jun 2004 11:28:33 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Message-ID: Joao, > I would suggest a slight re-phrase: > "Operators providing DNS for a zone served by a number of name servers > such that the total response size when including the list of > nameservers for the zone is close to the UDP packet > size limit may be assigned PI network prefixes for the purpose of > anycasting name servers, as described on RFC 3258. These shall be: a > /24 IPv4 prefix and/or a /32 IPv6 prefix." > Given that the issue is the will to anycast due to the operational > impact of adding more servers to the list, not just the size of the NS > RRSET itself. I see your point and it's the same thing I had in mind when I wrote the policy down. I don't think that it makes sense to work to hard on an exact definition when someone classifies for an allocation. As well it is impractical to say you have to cross the limits first (and prove that your clients are suffering from it) before you can get your allocation. I thought that those who are attracted by the policy will have no problem justifying it and RIPE would have no problem to ask people returning the networks if they do not use them as stated in the policy. But maybe my thinking is too positive here. Maybe the RIPE hostmasters can tell if they have the feeling the policy is "clear" enough or if they would like to see real hard limits (i.e. 0,5% of all responses during a time window of 60 minutes must be truncated). So far I think the original would serve RIPE and the DNS operators needs: "Operators providing DNS for a zone that is approaching the UDP packet size limit due to the number of authoritative servers may be assigned PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These prefixes will allow them to anycast the DNS server, as described in RFC 3258." > Also, pardon me asking but would the request be for a /24 per server to > be anycasted of a /24 per zone administrator? One /24 per zone operator. I remember that someone (was that you?) would like to have /24 for putting the administrative interface of the anycast instances into another AS but as far as I recall there have not been much support for that idea. Have a nice day Andreas > Joao From pekkas at netcore.fi Wed Jun 9 11:38:45 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 9 Jun 2004 12:38:45 +0300 (EEST) Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Message-ID: On Wed, 9 Jun 2004, Andreas B??/Denic wrote: > So far I think the original would serve RIPE and the DNS operators needs: > > "Operators providing DNS for a zone that is approaching the UDP packet > size limit due to the number of authoritative servers may be assigned > PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These > prefixes will allow them to anycast the DNS server, as described in RFC > 3258." No, this completely misses Joao's point which spelled out that you don't get an allocation unless you will anycast it. For example, my private company shouldn't be able to get PI prefixes just by adding 20 authorative DNS servers! In other words, either you're creating PI space for ccTLDs (or some other groups, whether special or not), or you're creating PI space for anycasting for certain applications, or both. This needs to be made clearer as different people have different assumptions here. That said, I still don't think this policy makes sense. How many servers would that need to be? A lot. What prevents from anycasting a regular PA prefix among those parties which have the largest amount of servers? Nothing (prefix filters based on RIPE DB shouldn't be a problem, just add the AS of anyone anycasting to the prefix right?). > > Also, pardon me asking but would the request be for a /24 per server to > > be anycasted of a /24 per zone administrator? > > One /24 per zone operator. I remember that someone (was that you?) would > like to have /24 for putting the administrative interface of the anycast > instances into another AS but as far as I recall there have not been much > support for that idea. This is unacceptable for redundancy reasons. If the routing for the /24 hiccups (e.g., someone advertises the prefix but drops the packets), all the nameservers will down for people behind that ISP? If you anycast something, there will have to be a backup option as well. -- 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 woeber at cc.univie.ac.at Wed Jun 9 13:27:15 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 09 Jun 2004 13:27:15 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A331AD.F1DE13C6.8@cc.univie.ac.at> >> I would suggest a slight re-phrase: > >> "Operators providing DNS for a zone served by a number of name servers >> such that the total response size when including the list of >> nameservers for the zone is close to the UDP packet >> size limit may be assigned PI network prefixes for the purpose of >> anycasting name servers, as described on RFC 3258. These shall be: a >> /24 IPv4 prefix and/or a /32 IPv6 prefix." > >> Given that the issue is the will to anycast due to the operational >> impact of adding more servers to the list, not just the size of the NS >> RRSET itself. > >I see your point and it's the same thing I had in mind when I wrote the >policy down. I don't think that it makes sense to work to hard on an exact >definition when someone classifies for an allocation. It depends on how tight we want to knit the mesh (and emphasise conservation et.al. :-) > As well it is >impractical to say you have to cross the limits first (and prove that >your clients are suffering from it) before you can get your allocation. Agreed. >I thought that those who are attracted by the policy will have no problem >justifying it and RIPE would have no problem to ask people returning the >networks if they do not use them as stated in the policy. But maybe >my thinking is too positive here. I guess everything which essentially gives you easy access to a PI /24 (/32 for that matter in the long run) is going to attract interest, at least eventually. Thus here are my questions for double-checking my own mental picture and assumptions: - the applicant has to be an established LIR - correct? - as setting up a server and finding slaves, plus anycast in general is not really rocket science: is there any closer definiton of "Operators providing DNS for a zone served by a number of name servers..." - would my own domain (say - netcraft.at) qualify as well? - and trying to reclaim that address space would be pretty cumbersome for both parties, I guess, unless the zone (all zones on those servers?) go(es) away _completely_ ?! Cheers, Wilfried. From baess at denic.de Wed Jun 9 14:26:04 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Wed, 9 Jun 2004 14:26:04 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <00A331AD.F1DE13C6.8@cc.univie.ac.at> Message-ID: > It depends on how tight we want to knit the mesh (and emphasise > conservation et.al. :-) That is indeed the question that we have to agree to. > >I thought that those who are attracted by the policy will have no problem > >justifying it and RIPE would have no problem to ask people returning the > >networks if they do not use them as stated in the policy. But maybe > >my thinking is too positive here. > I guess everything which essentially gives you easy access to a PI /24 > (/32 for that matter in the long run) is going to attract interest, at > least eventually. > > Thus here are my questions for double-checking my own mental picture and > assumptions: > > - the applicant has to be an established LIR - correct? I have don't think that this should be an imperative. Do you really think that LIRs should not be able to request such an allocation on behalf of a customer that would like to do that? > - as setting up a server and finding slaves, plus anycast in general is > not really rocket science: is there any closer definiton of "Operators > providing DNS for a zone served by a number of name servers..." - > would my own domain (say - netcraft.at) qualify as well? If I recall it correctly we have opened the intial qualification from TLD DNS operators to a broader scope knowingly to include those who feel that their DNS operation is important enough for them to run this kind of infrastructure in that particular way i.e. anycasting with a number of NS that would break the 512 limit in a "signifacant" number of responses. What I have heard so far the expected number of requests for this kind of allocations will be in a range that most believe that it is not necessary to knit the mesh too tight but give a credit to the applicant. > - and trying to reclaim that address space would be pretty cumbersome > for both parties, I guess, unless the zone (all zones on those > servers?) go(es) away _completely_ ?! If someone finds it cumbersome to renumber because he has to return the resources granted to do dns anycasting he probably should not apply for this resource ;-) Cheers Andreas From pk at TechFak.Uni-Bielefeld.DE Wed Jun 9 14:43:52 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 09 Jun 2004 14:43:52 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Your message of "Wed, 09 Jun 2004 14:26:04 +0200." Message-ID: <200406091243.i59ChqH13557@grimsvotn.TechFak.Uni-Bielefeld.DE> > that would break the 512 limit in a "signifacant" number of responses. > What I have heard so far the expected number of requests for this kind of > allocations will be in a range that most believe that it is not necessary > to knit the mesh too tight but give a credit to the applicant. Since the breaking of the limit happens at the parent can the parent be involved (not sure that you want that for the particular parent ...)? -Peter From baess at denic.de Wed Jun 9 15:00:32 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Wed, 9 Jun 2004 15:00:32 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Message-ID: > > "Operators providing DNS for a zone that is approaching the UDP packet > > size limit due to the number of authoritative servers may be assigned > > PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These > > prefixes will allow them to anycast the DNS server, as described in RFC > > 3258." > No, this completely misses Joao's point which spelled out that you > don't get an allocation unless you will anycast it. For example, my > private company shouldn't be able to get PI prefixes just by adding 20 > authorative DNS servers! Anycasted DNS is an absolute must to qualify for this kind of allocation. However I can't believe taht someone will break up his DNS service just to qualify for another /24. Maybe I underestimate what some people would do for a handfull of numbers :-) > In other words, either you're creating PI space for ccTLDs (or some > other groups, whether special or not), or you're creating PI space for > anycasting for certain applications, or both. This needs to be made > clearer as different people have different assumptions here. This address space is _not_ PI in its original sense. The allocation is made to overcome a DNS limitation and we feel that we should grant resources to those who feel the need to provide DNS service in a way that is described in RFC 3258. This policy does not apply to non DNS services and it is not limited to TLDs. > That said, I still don't think this policy makes sense. How many > servers would that need to be? A lot. There has been several studies from different sources how many NS would be needed. If you plan to fully support IPv6 transition giving all of your NS A and AAAA records it is not that many before your responses will be truncated. > What prevents from anycasting > a regular PA prefix among those parties which have the largest amount > of servers? Nothing (prefix filters based on RIPE DB shouldn't be a > problem, just add the AS of anyone anycasting to the prefix right?). As I said before it is not about PA versus PI, the allocation is tagged to the anycast DNS services. We have discussed the possibility to ensure the routability of smaller prefixes from the "regular" LIR allocation but most of the people felt that although possible putting that burden (to ensure routability of some prefixes in a world that filters on PA allocation boundaries) on DNS folks is not a good idea but enabling them to use specific prefixes that are "known" to ensure routability is a better solution. It has also been agreed that using this kind of special allocations will be history as soon as anycasting is possible with a single allocation. I don't know if the routing wg is already working on this item. Have a nivce day Andreas > > > Also, pardon me asking but would the request be for a /24 per server to > > > be anycasted of a /24 per zone administrator? > > > > One /24 per zone operator. I remember that someone (was that you?) would > > like to have /24 for putting the administrative interface of the anycast > > instances into another AS but as far as I recall there have not been much > > support for that idea. > This is unacceptable for redundancy reasons. If the routing for the > /24 hiccups (e.g., someone advertises the prefix but drops the > packets), all the nameservers will down for people behind that ISP? > If you anycast something, there will have to be a backup option as > well. > -- > 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 dr at cluenet.de Wed Jun 9 15:10:51 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 9 Jun 2004 15:10:51 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: ; from baess@denic.de on Wed, Jun 09, 2004 at 03:00:32PM +0200 References: Message-ID: <20040609151051.A15850@homebase.cluenet.de> On Wed, Jun 09, 2004 at 03:00:32PM +0200, Andreas B??/Denic wrote: > However I can't believe taht someone will break up his DNS service just > to qualify for another /24. Maybe I underestimate what some people > would do for a handfull of numbers :-) Not for an IPv4 /24 PI, but certainly for an IPv6 /32. If you need PI for IPv4, you'll get it easily (given a need for it). If you need PI for IPv6, you do NOT get it (currently). Best regards, Daniel From Joao_Damas at isc.org Thu Jun 10 09:45:06 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 10 Jun 2004 09:45:06 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: Message-ID: <16FE3B16-BAB2-11D8-92D2-000A959B2120@isc.org> On 9 Jun, 2004, at 11:28, Andreas B??/Denic wrote: > Joao, > >> I would suggest a slight re-phrase: > >> "Operators providing DNS for a zone served by a number of name servers >> such that the total response size when including the list of >> nameservers for the zone is close to the UDP packet >> size limit may be assigned PI network prefixes for the purpose of >> anycasting name servers, as described on RFC 3258. These shall be: a >> /24 IPv4 prefix and/or a /32 IPv6 prefix." > >> Given that the issue is the will to anycast due to the operational >> impact of adding more servers to the list, not just the size of the NS >> RRSET itself. > > I see your point and it's the same thing I had in mind when I wrote the > policy down. I don't think that it makes sense to work to hard on an > exact > definition when someone classifies for an allocation. As well it is > impractical to say you have to cross the limits first (and prove that > your clients are suffering from it) before you can get your allocation. No, I wasn't proposing that you have to suffer before you get the reward, I am a follower of that precept. What I want is there to be a clear motivation for the allocation of resources, ie. you get the prefix because you want to anycast, not because your responses are close to the UDP size limit. I would also like to see some effort being put in place by big zone administrators on educating people about EDNS support in their servers. I am sure ccTLD operators issue recommendations to their customers. > > I thought that those who are attracted by the policy will have no > problem > justifying it and RIPE would have no problem to ask people returning > the > networks if they do not use them as stated in the policy. But maybe > my thinking is too positive here. Experience says allocations (and assignments) are not boomerangs, they go out, they rarely return. > > Maybe the RIPE hostmasters can tell if they have the feeling the policy > is "clear" enough or if they would like to see real hard limits (i.e. > 0,5% of all responses during a time window of 60 minutes must be > truncated). No, god, no, I understand hostmaster need concrete policies, judgement calls can be controversial, but no policy should need to preclude development before allowing it. > > So far I think the original would serve RIPE and the DNS operators > needs: > > "Operators providing DNS for a zone that is approaching the UDP packet > size limit due to the number of authoritative servers may be assigned > PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These > prefixes will allow them to anycast the DNS server, as described in RFC > 3258." > >> Also, pardon me asking but would the request be for a /24 per server >> to >> be anycasted of a /24 per zone administrator? > > One /24 per zone operator. I remember that someone (was that you?) > would > like to have /24 for putting the administrative interface of the > anycast > instances into another AS but as far as I recall there have not been > much > support for that idea. No, this is not about the point I brought up a few months ago about management addresses, but rather about what Pekka said, the danger of putting all the nameservers in a single /24. Any snafu affecting that /24 (any of the anycast instances flapping, for instance) will take down access to all servers. With regard to Pekka's point about filtering, some people claim to have problems at some points when they split their allocations. I don't know, I never had to do split RIR space. On the other hand, the CIDR report shows a few examples of people massively de-aggregating and they are still in business, so..., I will leave this point to be discussed by someone who actually has a problem with it. And with regards, to Wilfried's question about whether this policy proposal should require the requester to be an LIR, the reply is "why should it?". Unlike Daniel, I have trouble seeing bureaucracy as a beautiful clockwork mechanism. Cheers, Joao From gert at space.net Fri Jun 11 10:25:31 2004 From: gert at space.net (Gert Doering) Date: Fri, 11 Jun 2004 10:25:31 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: Message-ID: <20040611082531.GB6204@Space.Net> Hi Pekka, I'm answering on your e-mail, but the same issue has appeared a couple of times: On Wed, Jun 09, 2004 at 12:38:45PM +0300, Pekka Savola wrote: > > One /24 per zone operator. [..] > > This is unacceptable for redundancy reasons. If the routing for the > /24 hiccups (e.g., someone advertises the prefix but drops the > packets), all the nameservers will down for people behind that ISP? > If you anycast something, there will have to be a backup option as > well. The idea is not to put *all* name servers for a given zone into anycast space. The idea is to have a number of unicast servers (as many as fit into the delegation UDP packet, minus 1) and in addition to that, an anycast server with "many instances". So if the anycast /24 hickups, the client resolver will treat this as it will treat any failure of one of the auth DNS servers -> fall over to the next nameserver listed. Of course it's open to debate whether it might be desireable to permit "many different anycast networks for a single zone", or even "anycast all of the servers" (with individual networks). The current idea is conservative and proposes "one anycast netblock". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 11 10:47:23 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 11 Jun 2004 10:47:23 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040611082531.GB6204@Space.Net> References: <20040611082531.GB6204@Space.Net> Message-ID: Don't you think the policy ought to be more relaxed and allow the server manager for the zone to decide how many of their servers they want to anycast? Joao On 11 Jun, 2004, at 10:25, Gert Doering wrote: > Hi Pekka, > > I'm answering on your e-mail, but the same issue has appeared a couple > of times: > > On Wed, Jun 09, 2004 at 12:38:45PM +0300, Pekka Savola wrote: >>> One /24 per zone operator. [..] >> >> This is unacceptable for redundancy reasons. If the routing for the >> /24 hiccups (e.g., someone advertises the prefix but drops the >> packets), all the nameservers will down for people behind that ISP? >> If you anycast something, there will have to be a backup option as >> well. > > The idea is not to put *all* name servers for a given zone into anycast > space. The idea is to have a number of unicast servers (as many as > fit into the delegation UDP packet, minus 1) and in addition to that, > an anycast server with "many instances". > > So if the anycast /24 hickups, the client resolver will treat this as > it will treat any failure of one of the auth DNS servers -> fall over > to the next nameserver listed. > > Of course it's open to debate whether it might be desireable to permit > "many different anycast networks for a single zone", or even "anycast > all of the servers" (with individual networks). The current idea is > conservative and proposes "one anycast netblock". > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 60210 > (58081) > > 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 Jun 11 10:50:38 2004 From: gert at space.net (Gert Doering) Date: Fri, 11 Jun 2004 10:50:38 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: <20040611082531.GB6204@Space.Net> Message-ID: <20040611085038.GD6204@Space.Net> Hi, On Fri, Jun 11, 2004 at 10:47:23AM +0200, Joao Damas wrote: > Don't you think the policy ought to be more relaxed and allow the > server manager for the zone to decide how many of their servers they > want to anycast? This is not my decision. It's up to the working group to decide on the policy they want to have. The current proposal is a somewhat-balanced compromise, but in no way cast in stone (yet :) ). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 11 10:53:39 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 11 Jun 2004 10:53:39 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040611085038.GD6204@Space.Net> References: <20040611082531.GB6204@Space.Net> <20040611085038.GD6204@Space.Net> Message-ID: On 11 Jun, 2004, at 10:50, Gert Doering wrote: > Hi, > > On Fri, Jun 11, 2004 at 10:47:23AM +0200, Joao Damas wrote: >> Don't you think the policy ought to be more relaxed and allow the >> server manager for the zone to decide how many of their servers they >> want to anycast? > > This is not my decision. It's up to the working group to decide on the > policy they want to have. That's why I was asking for your opinion. > > The current proposal is a somewhat-balanced compromise, but in no way > cast in stone (yet :) ). It also appears to be under the shadow of the conservation syndrome as this seems to be the only justification to limit the usage of an RFC documented operational procedure. Joao From woeber at cc.univie.ac.at Wed Jun 9 14:51:29 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 09 Jun 2004 14:51:29 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A331B9.B6459D46.9@cc.univie.ac.at> Hi Andreas! >I have don't think that this should be an imperative. Do you really think >that LIRs should not be able to request such an allocation on behalf of >a customer that would like to do that? Sorry, my question was meant "the-other-way-'round": that a request has to come by way of an established LIR "in good standing" (this of course includes "friendly" existing LIRs offering the service for the project :-). I just wanted to be sure that we don't open a by-pass channel to the LIR structure. >If someone finds it cumbersome to renumber because he has to return the >resources granted to do dns anycasting he probably should not apply for >this resource ;-) Well, the picture might be a bit more complex, in particular for TLDs, when they have to "please" the IANA and/or ICANN to get a re-delegation at a certain point in time ;-) And I haven't yet thought to the bottom of how thing would look like if this becomes a service for supporting many zones, and all of them have to be renumbered because of an interaction with this "special assignment requirement"... >Cheers >Andreas Cheers/Servus, Wilfried. PS: and slightly off-topic: I honestly dislike special arrangements in general - when they are meant to punch holes into too restrictive general resource management rules. We have built too many cans of worms in the past doing so... From randy at psg.com Fri Jun 11 16:19:47 2004 From: randy at psg.com (Randy Bush) Date: Fri, 11 Jun 2004 07:19:47 -0700 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation References: <20040611082531.GB6204@Space.Net> Message-ID: <16585.49027.540746.936103@ran.psg.com> > Don't you think the policy ought to be more relaxed and allow the > server manager for the zone to decide how many of their servers they > want to anycast? i think the point intended is that the address space *must* be used for anycast, and not just another address grab. yes? randy From Joao_Damas at isc.org Fri Jun 11 16:38:30 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 11 Jun 2004 16:38:30 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <16585.49027.540746.936103@ran.psg.com> References: <20040611082531.GB6204@Space.Net> <16585.49027.540746.936103@ran.psg.com> Message-ID: <01E0726B-BBB5-11D8-92D2-000A959B2120@isc.org> On 11 Jun, 2004, at 16:19, Randy Bush wrote: >> Don't you think the policy ought to be more relaxed and allow the >> server manager for the zone to decide how many of their servers they >> want to anycast? > > i think the point intended is that the address space *must* be used > for anycast, and not just another address grab. yes? Well, no one doubts that is the intention here, that is why I suggested a different wording earlier, so the motivation is clear. My question is, why limit it to anycast one of the servers? Joao From baess at denic.de Fri Jun 11 16:55:06 2004 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Fri, 11 Jun 2004 16:55:06 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <01E0726B-BBB5-11D8-92D2-000A959B2120@isc.org> Message-ID: > >> Don't you think the policy ought to be more relaxed and allow the > >> server manager for the zone to decide how many of their servers they > >> want to anycast? > > > > i think the point intended is that the address space *must* be used > > for anycast, and not just another address grab. yes? > Well, no one doubts that is the intention here, that is why I suggested > a different wording earlier, so the motivation is clear. My question > is, why limit it to anycast one of the servers? Can you help me and explain what the advantage of offering multiple anycast servers in comparison to a single anycast server is? Andreas From Joao_Damas at isc.org Fri Jun 11 20:30:39 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 11 Jun 2004 20:30:39 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: Message-ID: <70665DAA-BBD5-11D8-92D2-000A959B2120@isc.org> On 11 Jun, 2004, at 16:55, Andreas B??/Denic wrote: >>>> Don't you think the policy ought to be more relaxed and allow the >>>> server manager for the zone to decide how many of their servers they >>>> want to anycast? >>> >>> i think the point intended is that the address space *must* be used >>> for anycast, and not just another address grab. yes? > >> Well, no one doubts that is the intention here, that is why I >> suggested >> a different wording earlier, so the motivation is clear. My question >> is, why limit it to anycast one of the servers? > > Can you help me and explain what the advantage of offering multiple > anycast servers in comparison to a single anycast server is? > You put your eggs in more baskets. Joao From gert at space.net Sat Jun 12 17:36:42 2004 From: gert at space.net (Gert Doering) Date: Sat, 12 Jun 2004 17:36:42 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <16585.49027.540746.936103@ran.psg.com> References: <20040611082531.GB6204@Space.Net> <16585.49027.540746.936103@ran.psg.com> Message-ID: <20040612153642.GO6204@Space.Net> Hi, On Fri, Jun 11, 2004 at 07:19:47AM -0700, Randy Bush wrote: > > Don't you think the policy ought to be more relaxed and allow the > > server manager for the zone to decide how many of their servers they > > want to anycast? > > i think the point intended is that the address space *must* be used > for anycast, and not just another address grab. yes? Yes. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From laura at ripe.net Mon Jun 14 10:36:40 2004 From: laura at ripe.net (Laura Cobley) Date: Mon, 14 Jun 2004 10:36:40 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" Message-ID: <20040614103640.491b4038.laura@ripe.net> Dear Colleagues, We have received many comments that the text of the current IPv6 Allocation and Assignment Policy document can be difficult to read and understand. Some of these difficulties were presented at RIPE 48 by Leo Vegoda: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-policy.pdf During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes. In order to assist with rewriting the IPv6 Policy document, we would like to have some input from the community on the issues needing clarification. We will send each issue for discussion in a separate mail. This is the first of these mails. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "d)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years." 1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention? 2. There are a number of interpretations of requirement "d)": - NUMBER OF ASSIGNMENTS -- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48. -- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s. Which interpretation was intended regarding the number of assignments? - RECIPIENT OF ASSIGNMENTS -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations. -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted. -- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation. -- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure". Which interpretation was intended regarding the recipient of assignments? We look forward to receiving the community's input on this. Best Regards, Laura Cobley Registration Services RIPE NCC From cfriacas at fccn.pt Mon Jun 14 10:53:35 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 14 Jun 2004 09:53:35 +0100 (WEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040614103640.491b4038.laura@ripe.net> References: <20040614103640.491b4038.laura@ripe.net> Message-ID: Inline... my views. On Mon, 14 Jun 2004, Laura Cobley wrote: > Dear Colleagues, > > We have received many comments that the text of the current IPv6 > Allocation and Assignment Policy document can be difficult to read and > understand. Some of these difficulties were presented at RIPE 48 by Leo > Vegoda: > > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-policy.pdf > > During the following discussions, the RIPE NCC was asked to co-ordinate > work on clarifying the text. Please note that we do not intend to > propose any policy changes. > > In order to assist with rewriting the IPv6 Policy document, we would > like to have some input from the community on the issues needing > clarification. We will send each issue for discussion in a separate > mail. > > This is the first of these mails. > > > Below is an excerpt from the IPv6 Address Allocation and Assignment > Policy: > > 5.1.1. Initial allocation criteria "d)" > > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] have a plan for making at least 200 /48 > assignments to other organisations within two years." > > > 1. According to this criterion, LIRs who are operators planning to only > make /64 assignments appear not to qualify. Was this the community's > intention? If focus on *only*, "Yes". Otherwise i would say "No". > 2. There are a number of interpretations of requirement "d)": > > > - NUMBER OF ASSIGNMENTS > > -- The LIR has to have a plan to make at least 200 separate /48 > assignments. Possible scenario: LIR must make 200 assignments > and the size of each must be a /48. > > -- The LIR has to have a plan to make at least the equivalent of > 200 /48 assignments. Possible scenario: LIR can assign one > /41 and seventy-two /48s. I would go with this one. Focus on address space being "handed out", not on the # of different customers. > Which interpretation was intended regarding the number of > assignments? > > > - RECIPIENT OF ASSIGNMENTS > > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations (regardless of which > organisation). Possible scenario: LIR can make 1 assignment > to its own organisation and 199 assignments to 199 > "different" organisations. This should be valid. > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations outside of its own infrastructure. > Possible scenario: LIR must make 200 assignments to 200 > "different" organisations. Assignments to its own > organisation will not be counted. Own assignments should count. At a latter point in time projects/other might shift administrative control... > -- The LIR has to have a plan to make these assignments to 200 > separate networks (regardless of which organisation these > networks belong to). Possible scenario: LIR makes 200 > assignments to 200 networks. 100 can be for its own > infrastructure and 100 can be for another single > organisation. Should be valid. Some LIRs in fact manage a lot of projects, lot of networks, etc... > -- The LIR has to have a plan to make these assignments to 200 > separate networks outside of its own infrastructure. Possible > scenario: LIR makes 200 assignments to 200 networks "outside > of its own infrastructure". Too much conservative -- also a good way to stop/slow down IPv6. :-( > Which interpretation was intended regarding the recipient of > assignments? > > We look forward to receiving the community's input on this. > > Best Regards, > > Laura Cobley > Registration Services > RIPE NCC 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 (135072/470), naming (millions) and... people!" From pekkas at netcore.fi Mon Jun 14 11:34:03 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 14 Jun 2004 12:34:03 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040614103640.491b4038.laura@ripe.net> Message-ID: My opinions.. On Mon, 14 Jun 2004, Laura Cobley wrote: > Below is an excerpt from the IPv6 Address Allocation and Assignment > Policy: > > 5.1.1. Initial allocation criteria "d)" > > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] have a plan for making at least 200 /48 > assignments to other organisations within two years." > > > 1. According to this criterion, LIRs who are operators planning to only > make /64 assignments appear not to qualify. Was this the community's > intention? The recommended policy is to make /48 assignments, so encouragement in this policy does not hurt. So, I'd maybe interpret this as "if you plan to make so many /64 assignments that 200 /48's wouldn't be enough, you may get an allocation". Means that guide LIRs towards Doing the Right Thing wrt. assignments are not a bad idea. > 2. There are a number of interpretations of requirement "d)": > > - NUMBER OF ASSIGNMENTS > > -- The LIR has to have a plan to make at least 200 separate /48 > assignments. Possible scenario: LIR must make 200 assignments > and the size of each must be a /48. > > -- The LIR has to have a plan to make at least the equivalent of > 200 /48 assignments. Possible scenario: LIR can assign one > /41 and seventy-two /48s. > > Which interpretation was intended regarding the number of > assignments? IMHO, the former. The latter would be a loophole, and there shouldn't be a need for making many allocations larger than /48 in any case (and if they are made, there will have to be permission from RIPE NCC in any case, as of today) > - RECIPIENT OF ASSIGNMENTS > > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations (regardless of which > organisation). Possible scenario: LIR can make 1 assignment > to its own organisation and 199 assignments to 199 > "different" organisations. No, your own allocations are not counted. > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations outside of its own infrastructure. > Possible scenario: LIR must make 200 assignments to 200 > "different" organisations. Assignments to its own > organisation will not be counted. This was what was meant, I think. > -- The LIR has to have a plan to make these assignments to 200 > separate networks (regardless of which organisation these > networks belong to). Possible scenario: LIR makes 200 > assignments to 200 networks. 100 can be for its own > infrastructure and 100 can be for another single > organisation. > > -- The LIR has to have a plan to make these assignments to 200 > separate networks outside of its own infrastructure. Possible > scenario: LIR makes 200 assignments to 200 networks "outside > of its own infrastructure". These two are just variants of the above assuming that "NUMBER OF ASSIGNMENTS" (above) does not need to be at least 200. -- 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 oliver at bartels.de Mon Jun 14 11:38:40 2004 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 14 Jun 2004 11:38:40 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040614103640.491b4038.laura@ripe.net> Message-ID: <200406140938.i5E9c0tH007607@alpha.bartels.de> Dear Laura, On Mon, 14 Jun 2004 10:36:40 +0200, Laura Cobley wrote: [...] Below are my views: >Below is an excerpt from the IPv6 Address Allocation and Assignment >Policy: First some gerneral comment: IPv6 is *currently* primarily an experimental feature and - from business man's view: a cost factor -. If IPv6 should ever get some significant growth, please *make it as easy as possible* to implement it. Please *avoid unnecessary buerocracy*. > 1. According to this criterion, LIRs who are operators planning to only > make /64 assignments appear not to qualify. Was this the community's > intention? It is very unlikely that some LIR would *only* make /64 assignments (DSL ?), but: This criterion would be just another item to prevent IPv6 to become a significant factor in the Internet. Thus try to avoid it. > Which interpretation was intended regarding the number of > assignments? In my view it was the fear that small blocks would increase the IPv6 global routing table size. But again, please keep in mind: - The LIR min. alloc. was changed from /20 to /21 and the requirement of a min. usage was dropped to permit large organizations with redundant upstreams to become (paying ;-) RIPE NCC members instead of using PI. These organisations want to be independend from single ISP's. If you would now force them back to single ISP upstream with a min. number of assignments, you would either gain "plans" which are not worth the paper they are written on, or, they just won't use IPv6. - With today's router technology and decreased RAM pricing and increased bandwith between BGP speakers, the larger table should not be a big issue in the IPv6 area. The real implementation of IPv6 (not just small experimental traffic) will sooner or later require new routers with e.g. improved hardware forwarding. - Operating a LIR requires some continuous investment. The RIPE NCC membership costs are some barrier to prevent a polution of the IPv6 global routing table with no-traffic prefixes. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From ripe-lst at eirconnect.net Mon Jun 14 13:08:13 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 14 Jun 2004 12:08:13 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406140938.i5E9c0tH007607@alpha.bartels.de> References: <200406140938.i5E9c0tH007607@alpha.bartels.de> Message-ID: <200406141208.13825.ripe-lst@eirconnect.net> On Mon 14 Jun 2004 10:38, Oliver Bartels wrote: > If IPv6 should ever get some significant growth, please > *make it as easy as possible* to implement it. > Please *avoid unnecessary buerocracy*. There was a proposal, at RIPE-48, to abolish the 200 customer requirement altogether. (Don't remember by whom). The reasoning being that it raises the bar to IPv6 adoption unneccessarily. For the record, I support this argument. > It is very unlikely that some LIR would *only* make /64 assignments > (DSL ?), but: Mobile telcos? > In my view it was the fear that small blocks would increase the > IPv6 global routing table size. This is a technical problem and thus a technical solution should be looked for. Why should hardware vendors determine IP allocation policy? Best regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha at eirconnect.net Ireland | http://www.eirconnect.net From leo at ripe.net Mon Jun 14 14:18:01 2004 From: leo at ripe.net (leo vegoda) Date: Mon, 14 Jun 2004 14:18:01 +0200 Subject: [address-policy-wg] New IPv6 Address Block Allocated to RIPE NCC Message-ID: Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4000::/23 from the IANA in June 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 sascha at eirconnect.net Mon Jun 14 11:46:27 2004 From: sascha at eirconnect.net (Sascha Luck) Date: Mon, 14 Jun 2004 10:46:27 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406140938.i5E9c0tH007607@alpha.bartels.de> References: <200406140938.i5E9c0tH007607@alpha.bartels.de> Message-ID: <200406141046.28144.sascha@eirconnect.net> On Mon 14 Jun 2004 10:38, Oliver Bartels wrote: > If IPv6 should ever get some significant growth, please > *make it as easy as possible* to implement it. > Please *avoid unnecessary buerocracy*. There was a proposal, at RIPE-48, to abolish the 200 customer requirement altogether. (Don't remember by whom). The reasoning being that it raises the bar to IPv6 adoption unneccessarily. For the record, I support this argument. > It is very unlikely that some LIR would *only* make /64 assignments > (DSL ?), but: Mobile telcos? > In my view it was the fear that small blocks would increase the > IPv6 global routing table size. This is a technical problem and thus a technical solution should be looked for. Why should hardware vendors determine IP allocation policy? Best regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha at eirconnect.net Ireland | http://www.eirconnect.net From woeber at cc.univie.ac.at Mon Jun 14 14:23:09 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 14 Jun 2004 14:23:09 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A335A3.95039FC8.3@cc.univie.ac.at> >And with regards, to Wilfried's question about whether this policy >proposal should require the requester to be an LIR, the reply is "why >should it?". To be more precise: not "to be an LIR" but to submit by way of an LIR" - much like the distribution of AS numbers. > Unlike Daniel, I have trouble seeing bureaucracy as a beautiful >clockwork mechanism. This is not to feed any bloated organisational overhead (no implication that there is one in this case!), but rather to avoid digging administrative bypass tunnels :-) >Cheers, >Joao Wilfried. From Joao_Damas at isc.org Mon Jun 14 14:38:44 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Mon, 14 Jun 2004 14:38:44 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <00A335A3.95039FC8.3@cc.univie.ac.at> References: <00A335A3.95039FC8.3@cc.univie.ac.at> Message-ID: On 14 Jun, 2004, at 14:23, Wilfried Woeber, UniVie/ACOnet wrote: >> And with regards, to Wilfried's question about whether this policy >> proposal should require the requester to be an LIR, the reply is "why >> should it?". > > To be more precise: not "to be an LIR" but to submit by way of an > LIR" - > much like the distribution of AS numbers. > This sounds right. >> Unlike Daniel, I have trouble seeing bureaucracy as a beautiful >> clockwork mechanism. > > This is not to feed any bloated organisational overhead (no > implication > that there is one in this case!), but rather to avoid digging > administrative bypass tunnels :-) Right, keep things simple. Joao From gert at space.net Mon Jun 14 15:27:58 2004 From: gert at space.net (Gert Doering) Date: Mon, 14 Jun 2004 15:27:58 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <00A335A3.95039FC8.3@cc.univie.ac.at> References: <00A335A3.95039FC8.3@cc.univie.ac.at> Message-ID: <20040614132758.GN6204@Space.Net> Hi, On Mon, Jun 14, 2004 at 02:23:09PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > >And with regards, to Wilfried's question about whether this policy > >proposal should require the requester to be an LIR, the reply is "why > >should it?". > > To be more precise: not "to be an LIR" but to submit by way of an LIR" - > much like the distribution of AS numbers. While this has not been explicitely spelled, I see this as the underlying assumption. Does one of you know whether this is explicitely documented for AS and PI distribution? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leo at ripe.net Mon Jun 14 15:57:53 2004 From: leo at ripe.net (leo vegoda) Date: Mon, 14 Jun 2004 15:57:53 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040614132758.GN6204@Space.Net> References: <00A335A3.95039FC8.3@cc.univie.ac.at> <20040614132758.GN6204@Space.Net> Message-ID: Hi, On Jun 14, 2004, at 3:27 pm, Gert Doering wrote: [...] > Does one of you know whether this is explicitely documented for AS > and PI distribution? We have the following for PI address space in the IPv4 policy, which can be found at: http://www.ripe.net/ripe/docs/ipv4-policies.html#pa_pi "The RIPE NCC no longer allocates PI address space. Consequently, many LIRs do not have PI allocations from which to make PI assignments. If an LIR has an End User that requires PI address space they are able to support them by sending these requests to the RIPE NCC on behalf of the End User. This support includes helping End Users prepare a properly documented request. The RIPE NCC will make PI assignments when justified." The AS policy document is more explicit: http://www.ripe.net/ripe/docs/asn-assignment.html#requesting "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region and only accepts requests for AS Numbers from LIRs. LIRs may request AS Numbers on behalf of other organisations." Regards, -- leo vegoda Registration Services Manager RIPE NCC From Michael.Dillon at radianz.com Mon Jun 14 16:24:28 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 14 Jun 2004 15:24:28 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: Message-ID: > > 1. According to this criterion, LIRs who are operators planning to only > > make /64 assignments appear not to qualify. Was this the community's > > intention? > > The recommended policy is to make /48 assignments, so encouragement in > this policy does not hurt. So, I'd maybe interpret this as "if you > plan to make so many /64 assignments that 200 /48's wouldn't be > enough, you may get an allocation". > > Means that guide LIRs towards Doing the Right Thing wrt. assignments > are not a bad idea. I don't think you really believe this, either of you. First, I don't think anyone believes that mobile operators, who plan to make 50 million /64 assignments and no /48 assignments, do not qualify for IPv6 allocations from RIPE. Second, I don't think that anyone believes that it is the "right thing" for a mobile operator to assign 50 million /48 blocks, one to each customer handset. I think the community's intention was to happily offer IPv6 addresses to mobile operator LIRs who are moving beyond their small GPRS deployments and beginning to build true 3G ubiquitous wireless networks. But, often policies need to be edited and re-edited in order to clearly express the intention. From gert at space.net Tue Jun 15 11:46:40 2004 From: gert at space.net (Gert Doering) Date: Tue, 15 Jun 2004 11:46:40 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: Message-ID: <20040615094639.GA84333@Space.Net> Hi, as the discussion seems to have ebbed down, let me try to summarize. Please correct me if this isn't fully correct. There have been a few comments about wording, to make the criteria more precise. There has been some confusion on whether this is "PI". It is not, it's "anycast space", and should be tagged as such in the database, to help people recognizing these special blocks immediately as such. The usual rules apply: "if the criteria for allocations do no longer apply, the address block should be returned" (even if that is unlikely to happen very often in practice). There has been the question whether an operator can only get one prefix, or multiple prefixes. I have amended the proposal to include the option for multiple prefixes, but also point out that the usual thing will be "only one (set)". This is meant as kind of guidance - "deploy one set, and if that's well understood and you want to deploy another set, feel free to come back". Along that lines, there has been some confusion about redundancy. An important clarification is that it's not expected to put *all* nameservers into the (single) anycast prefix, but have "unicast" servers and one (or "few") anycast sets. So if the anycast prefix is unavailable from some networks, clients will fall back to one of the unicast servers. There has been a question on whether "end users" can directly request anycast address space, and the suggestion is that it should be handled the same way as PI space and AS space: the request needs to be passed through an existing LIR. One comment asked for "do we really need yet another special rule here", and my reply would be "the current PA and PI policy doesn't permit doing this without lying to the NCC", *and* DNS is really special here due to protocol constraints. To my understanding, there were no real fundamental objections, though (besides, this proposal was already discussed on the list and in the APWG meeting at R47, with mostly neutral-to-positive reactions) So based on these comments, I want to suggest the following new text, to be incorporated into the policy documents: ------------ snip ------------ "Operators providing DNS for a zone served by a number of name servers such that the total response size when including the list of nameservers for the zone is close to the UDP packet size limit may be assigned dedicated network prefixes for the sole purpose of anycasting name servers, as described on RFC 3258. These shall be: a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set, which will usually only be one per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be returned to the RIPE NCC if not in use for anycast DNS any longer." ------------ snip ------------ To be able to proceed with the implementation, let's set a deadline of July 13 (4 weeks from now). If no fundamental opposition is voiced, we can call it consensus, and ask the RIPE NCC to go ahead with it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Tue Jun 15 12:19:32 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 15 Jun 2004 12:19:32 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040615094639.GA84333@Space.Net> References: <20040615094639.GA84333@Space.Net> Message-ID: <7E98EEEF-BEB5-11D8-AF9B-000A959B2120@isc.org> Gert, On 15 Jun, 2004, at 11:46, Gert Doering wrote: > Hi, > > as the discussion seems to have ebbed down, let me try to summarize. > Please correct me if this isn't fully correct. > > There have been a few comments about wording, to make the criteria > more precise. > > There has been some confusion on whether this is "PI". It is not, it's > "anycast space", and should be tagged as such in the database, to help > people recognizing these special blocks immediately as such. The usual > rules apply: "if the criteria for allocations do no longer apply, the > address block should be returned" (even if that is unlikely to happen > very often in practice). > Don;t know if there is a real need to tag things like this in the DB, but I am not going to argue either way. > There has been the question whether an operator can only get one > prefix, or multiple prefixes. I have amended the proposal to > include the option for multiple prefixes, but also point out that > the usual thing will be "only one (set)" Good up to here. > . This is meant as kind of > guidance - "deploy one set, and if that's well understood and > you want to deploy another set, feel free to come back". the "come back" part spoils it. Some people already understand this pretty well, no need for a several step ballet. > > Along that lines, there has been some confusion about redundancy. An > important clarification is that it's not expected to put *all* > nameservers > into the (single) anycast prefix, but have "unicast" servers and one > (or "few") anycast sets. So if the anycast prefix is unavailable from > some networks, clients will fall back to one of the unicast servers. > This could be the subject for a BCP sort of document by the DNS wg, but it has no place in an IP allocation policy. > There has been a question on whether "end users" can directly request > anycast address space, and the suggestion is that it should be handled > the same way as PI space and AS space: the request needs to be passed > through an existing LIR. > Cool. > One comment asked for "do we really need yet another special rule > here", > and my reply would be "the current PA and PI policy doesn't permit > doing > this without lying to the NCC", *and* DNS is really special here due to > protocol constraints. > There is need for a new rule because the current policy does not support the deployment of a well known and accepted operational setup that addresses a specific problem. I don't know about "special". > > To my understanding, there were no real fundamental objections, though > (besides, this proposal was already discussed on the list and in the > APWG meeting at R47, with mostly neutral-to-positive reactions) > > > So based on these comments, I want to suggest the following new > text, to be incorporated into the policy documents: > > ------------ snip ------------ > "Operators providing DNS for a zone served by a number of name servers > such that the total response size when including the list of > nameservers for the zone is close to the UDP packet size limit may > be assigned dedicated network prefixes for the sole purpose of > anycasting name servers, as described on RFC 3258. These shall be: > a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set, > which will usually only be one per operator. The prefixes shall be > tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be > returned to the RIPE NCC if not in use for anycast DNS any longer." > ------------ snip ------------ I support your suggested wording. > > > To be able to proceed with the implementation, let's set a deadline > of July 13 (4 weeks from now). If no fundamental opposition is voiced, > we can call it consensus, and ask the RIPE NCC to go ahead with it. > Joao From pekkas at netcore.fi Tue Jun 15 13:11:22 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 15 Jun 2004 14:11:22 +0300 (EEST) Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040615094639.GA84333@Space.Net> Message-ID: On Tue, 15 Jun 2004, Gert Doering wrote: > One comment asked for "do we really need yet another special rule here", > and my reply would be "the current PA and PI policy doesn't permit doing > this without lying to the NCC", *and* DNS is really special here due to > protocol constraints. If you qualify for at least /24 of v4 address space, there shouldn't be a problem with current v4 policy? If you can't qualify for that amount of addresses, do we care about anycasting that kind of server? Remember, nothing prevents anycasting with your existing allocated blocks. Hence, the policy for allocating these special PI/PA prefixes should be at least as strict as the policy for getting PI/PA prefixes in the first place .. to avoid getting around policies. > ------------ snip ------------ > "Operators providing DNS for a zone served by a number of name servers > such that the total response size when including the list of > nameservers for the zone is close to the UDP packet size limit may > be assigned dedicated network prefixes for the sole purpose of > anycasting name servers, as described on RFC 3258. These shall be: > a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set, > which will usually only be one per operator. The prefixes shall be > tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be > returned to the RIPE NCC if not in use for anycast DNS any longer." > ------------ snip ------------ I object to this as a whole, but even if we agreed that this is desirable in general, I have two strong objections: (1) there is little reason for allocating a /32 IPv6 prefix except for getting around the IPv6 policy. Why not use the "critical infrastructure" /48's for this, so we can easily filter out this junk in our BGP :) Proposal: change /32 to /48. (2) this proposal takes no stance on who can request a block of addresses like this for his DNS servers? People could add up servers and addresses for them just for the purposes of getting nice PI prefix(es) for their DNS servers. Wouldn't it be nice, never having to renumber your DNS server addresses in different registries etc. This is short-sighted. We should restrict this approach to specific class of DNS servers, like ccTLDs or the like -- if that's the class of DNS servers where we'd intend do something like this. -- 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 Tue Jun 15 13:18:05 2004 From: gert at space.net (Gert Doering) Date: Tue, 15 Jun 2004 13:18:05 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <7E98EEEF-BEB5-11D8-AF9B-000A959B2120@isc.org> References: <20040615094639.GA84333@Space.Net> <7E98EEEF-BEB5-11D8-AF9B-000A959B2120@isc.org> Message-ID: <20040615111805.GA6204@Space.Net> Hi, let me clarify a few things: On Tue, Jun 15, 2004 at 12:19:32PM +0200, Joao Damas wrote: [..] > Good up to here. > > >. This is meant as kind of > >guidance - "deploy one set, and if that's well understood and > >you want to deploy another set, feel free to come back". > > the "come back" part spoils it. Some people already understand this > pretty well, no need for a several step ballet. Maybe the wording wasn't too clear here. I don't want to imply "you MUST deploy one anycast set first, and then wait 3 months, and then come back for the second anycast set" (and it's not in the proposal text either). This is just the way I had envisioned it to happen "in the general case". [..] > >Along that lines, there has been some confusion about redundancy. An > >important clarification is that it's not expected to put *all* > >nameservers > >into the (single) anycast prefix, but have "unicast" servers and one > >(or "few") anycast sets. So if the anycast prefix is unavailable from > >some networks, clients will fall back to one of the unicast servers. > > This could be the subject for a BCP sort of document by the DNS wg, but > it has no place in an IP allocation policy. Which is exactly why it's not in the proposed text. It's just there to explain "background thoughts" - and I agree that a DNS wg BCP document would be a good place to write it down. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 15 13:27:58 2004 From: gert at space.net (Gert Doering) Date: Tue, 15 Jun 2004 13:27:58 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: References: <20040615094639.GA84333@Space.Net> Message-ID: <20040615112758.GB6204@Space.Net> Hi, On Tue, Jun 15, 2004 at 02:11:22PM +0300, Pekka Savola wrote: > On Tue, 15 Jun 2004, Gert Doering wrote: > > One comment asked for "do we really need yet another special rule here", > > and my reply would be "the current PA and PI policy doesn't permit doing > > this without lying to the NCC", *and* DNS is really special here due to > > protocol constraints. > > If you qualify for at least /24 of v4 address space, there shouldn't > be a problem with current v4 policy? There is. People don't want to use part of their PA block for the anycast announcement (due to "allocation boundary" filters) and you won't qualify for a /24 PI with just a single IP address used inside the block. The PI policy requires "more than 50% utilization" (simplified), which would mean "you need to use 128 IPs in the /24" - which a typical (ccTLD) anycast deployment will never reach. > If you can't qualify for that amount of addresses, do we care about > anycasting that kind of server? The ccTLD's office might have 500 machines in use, but the individual instances will all only use 1 IP (or very few). > Remember, nothing prevents anycasting with your existing allocated > blocks. Hence, the policy for allocating these special PI/PA prefixes > should be at least as strict as the policy for getting PI/PA prefixes > in the first place .. to avoid getting around policies. The problem in the first place is that the PI policy doesn't permit these prefixes in the first place, due to insufficient utilization. [..] > I object to this as a whole, but even if we agreed that this is > desirable in general, I have two strong objections: > > (1) there is little reason for allocating a /32 IPv6 prefix except > for getting around the IPv6 policy. Why not use the "critical > infrastructure" /48's for this, so we can easily filter out this junk > in our BGP :) We have no "critical infrastructure" /48s in RIPE land, *and* you're not supposed to catch this in "general-purpose more-specific filters" - which is the whole point of this excercise. (If you really want to filter the prefixes, you still can, as they are supposed to be clearly tagged in the RIPE DB). > Proposal: change /32 to /48. > > (2) this proposal takes no stance on who can request a block of > addresses like this for his DNS servers? Yes. On purpose, because it was envisioned that some organizations that are not TLD operators but still operate a high number of DNS servers (due to having a very large number of zones, or due to having a world-wide network, or whatever) might still meet the spirit of the thing. > People could add up servers > and addresses for them just for the purposes of getting nice PI > prefix(es) for their DNS servers. Ummm, yes. > Wouldn't it be nice, never having > to renumber your DNS server addresses in different registries etc. > This is short-sighted. We should restrict this approach to specific > class of DNS servers, like ccTLDs or the like -- if that's the class > of DNS servers where we'd intend do something like this. This was discussed in the last round, and a fair number of people voiced that we should not restrict this to TLD operators. Personally, I have no strong feelings one way or the other, but I can see that more discussion is needed here. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Mohsen.Souissi at nic.fr Tue Jun 15 14:36:52 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Tue, 15 Jun 2004 14:36:52 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040615094639.GA84333@Space.Net> References: <20040615094639.GA84333@Space.Net> Message-ID: <20040615123652.GU90840@kerkenna.nic.fr> Gert, On 15 Jun, Gert Doering wrote: [..] | | | So based on these comments, I want to suggest the following new | text, to be incorporated into the policy documents: | | ------------ snip ------------ | "Operators providing DNS for a zone served by a number of name servers | such that the total response size when including the list of | nameservers for the zone is close to the UDP packet size limit may | be assigned dedicated network prefixes for the sole purpose of | anycasting name servers, as described on RFC 3258. These shall be: | a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set, | which will usually only be one per operator. The prefixes shall be | tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be | returned to the RIPE NCC if not in use for anycast DNS any longer." | ------------ snip ------------ ==> While discussing this issue, IPv6 Policy (especially "Initial allocation criteria" section ) is being clarified (see current discussion on global-v6 at lists.apnic.net). Even though, it is said that the intention of this discussion is to clarify the IPv6 Policy and not to change it, does it make sense to consider adding explicitely the criterion above ("DNS ANYCASTING") as a new criterion to qualifiy for a /32 ? Regards, Mohsen. From woeber at cc.univie.ac.at Tue Jun 15 15:16:13 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 Jun 2004 15:16:13 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A33674.291C4248.22@cc.univie.ac.at> >==> While discussing this issue, IPv6 Policy (especially "Initial > allocation criteria" section ) is being clarified (see current > discussion on global-v6 at lists.apnic.net). Even though, it is said > that the intention of this discussion is to clarify the IPv6 > Policy and not to change it, does it make sense to consider adding > explicitely the criterion above ("DNS ANYCASTING") as a new > criterion to qualifiy for a /32 ? > >Regards, > >Mohsen. I don't think that mixing this would be a good idea, for the following reasons: - I expect the IPv6-clarification exercise to take "quite a while" to converge (across the 4+ RIR constituencies) and I get the feeling that the DNS operators would really like to see a decision reasonably soon now :-) - it is not obvious to me that this special "rucksack"-provision has to go into a globally coordinated text - and for the formal reason that the mandate right now is to provide clarifications or improved wording for the existing v6 policiy. If and when during that exercise it turnes out that we should actually start revising the v6 policy (which would not surprise me :-), then we can reconsider... Wilfried. From woeber at cc.univie.ac.at Tue Jun 15 15:40:27 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 Jun 2004 15:40:27 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A33677.8BA80B38.47@cc.univie.ac.at> Hi Pekka! The next paragraph is where I strongly start to disagree: > (2) this proposal takes no stance on who can request a block of >addresses like this for his DNS servers? Correct, and this is the way it should be! If someone wants to start deploying a particular _technology_ for her service, then there should be NO discussion about size, "importance", level in a hierarchy and similar things. > People could add up servers >and addresses for them just for the purposes of getting nice PI >prefix(es) for their DNS servers. Just like they can buy/rent cheap end systems today to be configured on a particular network to get IPv4 addresses ;-) > Wouldn't it be nice, never having >to renumber your DNS server addresses in different registries etc. Sure :-) And? >This is short-sighted. We should restrict this approach to specific >class of DNS servers, like ccTLDs or the like -- if that's the class >of DNS servers where we'd intend do something like this. This would get us (i.e. the NCC) into deep trouble: without intending to pick at a particular Zone - just to make a point - why would eg. VT. or MD. be eligible, but AC.UK. (or AC.AT. for that matter) or google.com or 3.4.E164.ARPA. would not?! >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings We just made this mistake too often already (looking at a particular application, at a particular transmission technology[1], and the like, and hard-wiring that into resource distribution policy). The only aspect that I would accept here is characteristics or rather limitations of the DNS _technology_ and _protocols_ (and maybe others), but NOT what type of service it is used for! Wilfried. [1] like 24/8 and DSL being treated as "dial-up" when in reality (for a certain period in time) the _business model_ would have been interesting to look at, and not the technology or application... From woeber at cc.univie.ac.at Tue Jun 15 16:10:57 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 Jun 2004 16:10:57 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A3367B.CEB6A6D8.26@cc.univie.ac.at> Hi Gert! >> If you qualify for at least /24 of v4 address space, there shouldn't >> be a problem with current v4 policy? > >There is. People don't want to use part of their PA block for the >anycast announcement (due to "allocation boundary" filters) and you >won't qualify for a /24 PI with just a single IP address used inside >the block. This, together with the fact that (if I remeber correctly!) there is no longer a minimum usage restriction for becoming an LIR should help to solve this problem?! Wilfried. From woeber at cc.univie.ac.at Tue Jun 15 16:20:09 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 Jun 2004 16:20:09 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation Message-ID: <00A3367D.173706B8.33@cc.univie.ac.at> >> There has been some confusion on whether this is "PI". It is not, it's >> "anycast space", and should be tagged as such in the database, to help >> people recognizing these special blocks immediately as such. The usual >> rules apply: "if the criteria for allocations do no longer apply, the >> address block should be returned" (even if that is unlikely to happen >> very often in practice). >> > >Don;t know if there is a real need to tag things like this in the DB, >but I am not going to argue either way. If there is a "real" difference as compared to PI (which I'm still not convinced :-), _and_ a "special" provision for reclaiming those addresses, then I think the answer should be YES. Wilfried. From gert at space.net Tue Jun 15 16:28:40 2004 From: gert at space.net (Gert Doering) Date: Tue, 15 Jun 2004 16:28:40 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <00A3367B.CEB6A6D8.26@cc.univie.ac.at> References: <00A3367B.CEB6A6D8.26@cc.univie.ac.at> Message-ID: <20040615142840.GE6204@Space.Net> Hi, On Tue, Jun 15, 2004 at 04:10:57PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > >> If you qualify for at least /24 of v4 address space, there shouldn't > >> be a problem with current v4 policy? > > > >There is. People don't want to use part of their PA block for the > >anycast announcement (due to "allocation boundary" filters) and you > >won't qualify for a /24 PI with just a single IP address used inside > >the block. > > This, together with the fact that (if I remeber correctly!) there is no > longer a minimum usage restriction for becoming an LIR should help to > solve this problem?! I can't fully follow you here. I described the problem, but you seem to interpret this as a solution? Take, for example, DENIC. They are a LIR, and have "their" LIR PA /20 address block (81.91.160.0/20). People "know" that inside 81/8, only /20 or larger sized blocks have been allocated, and might filter out everything more specific than a /20. So using a /24 out of the PA /20 allocation for anycasting might not work reliably "enough" to warrant the effort, due to non-reachability in those networks that have filters set up (this might be debatable, and indeed is the key issue whether an independent address block - and policy - is "necessary" or not). DENIC cannot get another "independent" PA block (because the first one is not at 80% utilization), and a single IP address doesn't qualify for a /24 PI. So they can get neither PA nor PI for this specific purpose. Now *DENIC* has enough /24 PI networks lying around from de.zz times :-), but the idea is to have a generic-enough policy that will permit similar deployments for other "DNS providers" as well. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From he at uninett.no Tue Jun 15 16:56:47 2004 From: he at uninett.no (Havard Eidnes) Date: Tue, 15 Jun 2004 16:56:47 +0200 (CEST) Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040615094639.GA84333@Space.Net> References: <20040615094639.GA84333@Space.Net> Message-ID: <20040615.165647.08709970.he@uninett.no> Hi, let's be a bit difficult, shall we? ;-) > There has been some confusion on whether this is "PI". It is not, > it's "anycast space", and should be tagged as such in the database, > to help people recognizing these special blocks immediately as such. > The usual rules apply: "if the criteria for allocations do no longer > apply, the address block should be returned" (even if that is > unlikely to happen very often in practice). What makes this different from clever wordplay? From a routing perspective the difference is pretty small, if it is there at all. > ------------ snip ------------ > "Operators providing DNS for a zone served by a number of name servers > such that the total response size when including the list of > nameservers for the zone is close to the UDP packet size limit may Hm, it's not "the UDP packet size limit", it is "the packet size limit for DNS over UDP without the application of EDNS.0". I may not have followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing space to compensate for people who have not yet upgraded their software... Of course, people may still dream up configurations which would exceed the EDNS.0 DNS over UDP packet size limit. > be assigned dedicated network prefixes for the sole purpose of > anycasting name servers, as described on RFC 3258. These shall be: > a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set, > which will usually only be one per operator. The prefixes shall be > tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be > returned to the RIPE NCC if not in use for anycast DNS any longer." > ------------ snip ------------ Regards, - H?vard From gert at space.net Tue Jun 15 17:05:44 2004 From: gert at space.net (Gert Doering) Date: Tue, 15 Jun 2004 17:05:44 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <20040615.165647.08709970.he@uninett.no> References: <20040615094639.GA84333@Space.Net> <20040615.165647.08709970.he@uninett.no> Message-ID: <20040615150544.GH6204@Space.Net> Hi, On Tue, Jun 15, 2004 at 04:56:47PM +0200, Havard Eidnes wrote: > let's be a bit difficult, shall we? ;-) Welcome to the club :-) > > There has been some confusion on whether this is "PI". It is not, > > it's "anycast space", and should be tagged as such in the database, > > to help people recognizing these special blocks immediately as such. > > The usual rules apply: "if the criteria for allocations do no longer > > apply, the address block should be returned" (even if that is > > unlikely to happen very often in practice). > > What makes this different from clever wordplay? From a routing > perspective the difference is pretty small, if it is there at all. On the router itself, there is hardly any difference. For the person configuring the router's filters, it might make a difference whether something is tagged as "this comes from a larger PA block" (so you don't necessarily need to carry it, there should be an aggregate in the table) and "this is something special". > > ------------ snip ------------ > > "Operators providing DNS for a zone served by a number of name servers > > such that the total response size when including the list of > > nameservers for the zone is close to the UDP packet size limit may > > Hm, it's not "the UDP packet size limit", it is "the packet size limit > for DNS over UDP without the application of EDNS.0". Of course. Sorry for being unprecise. ("For not correcting *this* part of the initially-also-unprecise wording ;-) "). > I may not have > followed things too closely, but it makes me sort of wonder why a push > towards EDNS.0 is not being advocated instead of polluting the routing > space to compensate for people who have not yet upgraded their > software... Of course, people may still dream up configurations which > would exceed the EDNS.0 DNS over UDP packet size limit. I leave *this* up to the DNS people - Andreas and Joao - to answer. In this discussion, I'm trying to wear the "WG Co-Chair" hat only - not actively advocating anything, just trying to clarify things, based on the proposal from DENIC (Andreas). So if people tell me that "95% of all DNS clients are already ENDS.0 capable, junk this proposal" (and have good background data for this, like "root DNS logs" or so) - fine with me, less work for me and the RIPE NCC. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Tue Jun 15 17:08:00 2004 From: randy at psg.com (Randy Bush) Date: Tue, 15 Jun 2004 08:08:00 -0700 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation References: <20040615094639.GA84333@Space.Net> <20040615.165647.08709970.he@uninett.no> Message-ID: <16591.4304.851871.450304@ran.psg.com> > Hm, it's not "the UDP packet size limit", it is "the packet size limit > for DNS over UDP without the application of EDNS.0". I may not have > followed things too closely, but it makes me sort of wonder why a push > towards EDNS.0 is not being advocated instead of polluting the routing > space to compensate for people who have not yet upgraded their > software. bingo! we seem to be pushing address space sales at the expense of routing/conservation, with no real justification. but folk have been ignoring me on this for years; so i'll go back to sleep now. > Of course, people may still dream up configurations which > would exceed the EDNS.0 DNS over UDP packet size limit. and they will, just to be silly and grab a /24 randy From laura at ripe.net Tue Jun 15 17:36:28 2004 From: laura at ripe.net (Laura Cobley) Date: Tue, 15 Jun 2004 17:36:28 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" Message-ID: <20040615173628.0363a350.laura@ripe.net> Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC From pk at TechFak.Uni-Bielefeld.DE Tue Jun 15 18:01:48 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 15 Jun 2004 18:01:48 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Your message of "Tue, 15 Jun 2004 16:56:47 +0200." <20040615.165647.08709970.he@uninett.no> Message-ID: <200406151601.i5FG1m605126@grimsvotn.TechFak.Uni-Bielefeld.DE> Hello, {I'm copying this to the DNS wg list, since the protocol issues may probably be better discussed there. Hey, I *love* these [tags] :-(} [address allocation for anycast of DNS nameservers] Havard Eidnes wrote: > > ------------ snip ------------ > > "Operators providing DNS for a zone served by a number of name servers > > such that the total response size when including the list of > > nameservers for the zone is close to the UDP packet size limit may > > Hm, it's not "the UDP packet size limit", it is "the packet size limit > for DNS over UDP without the application of EDNS.0". I may not have > followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing > space to compensate for people who have not yet upgraded their > software... Of course, people may still dream up configurations which Isn't then the parent of those trying to do anycast suffering from those resolvers unaware of EDNS0? In other words: what could the applicant do? -Peter From ripe-lst at eirconnect.net Wed Jun 16 00:12:01 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Tue, 15 Jun 2004 23:12:01 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <20040615173628.0363a350.laura@ripe.net> References: <20040615173628.0363a350.laura@ripe.net> Message-ID: <200406152312.01778.ripe-lst@eirconnect.net> On Tue 15 Jun 2004 16:36, Laura Cobley wrote: > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] plan to provide IPv6 connectivity to > organisations to which it will assign /48s by advertising that > connectivity through its single aggregated address allocation" Again, this seems to exclude mobile operators who may only want to assign /64s to their customers' handsets... rgds, Sascha -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha at eirconnect.net Ireland | http://www.eirconnect.net From kurtis at kurtis.pp.se Wed Jun 16 01:33:24 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 16 Jun 2004 01:33:24 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <16FE3B16-BAB2-11D8-92D2-000A959B2120@isc.org> References: <16FE3B16-BAB2-11D8-92D2-000A959B2120@isc.org> Message-ID: <652E0D74-BF24-11D8-8CB7-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-10, at 09.45, Joao Damas wrote: > No, this is not about the point I brought up a few months ago about > management addresses, but rather about what Pekka said, the danger of > putting all the nameservers in a single /24. Any snafu affecting that > /24 (any of the anycast instances flapping, for instance) will take > down access to all servers. Only servers that share the same path. At least if you are referring to dampening. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+HSqarNKXTPFCVEQLOpACeKVdPEl45gi9gker0EMNCNIOOKlcAoKy4 Q9hJ55rtLe7JnWXnc+jeTbor =pAXU -----END PGP SIGNATURE----- From randy at psg.com Wed Jun 16 01:38:28 2004 From: randy at psg.com (Randy Bush) Date: Tue, 15 Jun 2004 16:38:28 -0700 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation References: <16FE3B16-BAB2-11D8-92D2-000A959B2120@isc.org> <652E0D74-BF24-11D8-8CB7-000A95928574@kurtis.pp.se> Message-ID: <16591.34932.680495.671278@ran.psg.com> > Only servers that share the same path. At least if you are referring to > dampening. damping is not per path From kurtis at kurtis.pp.se Wed Jun 16 01:40:45 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 16 Jun 2004 01:40:45 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040614103640.491b4038.laura@ripe.net> References: <20040614103640.491b4038.laura@ripe.net> Message-ID: <6C0E2552-BF25-11D8-8CB7-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Below is an excerpt from the IPv6 Address Allocation and Assignment > Policy: > > 5.1.1. Initial allocation criteria "d)" > > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] have a plan for making at least 200 /48 > assignments to other organisations within two years." > > > 1. According to this criterion, LIRs who are operators planning to > only > make /64 assignments appear not to qualify. Was this the > community's > intention? I personally think this is silly. Then again I have a hard time understanding why you would not give out a /48 to each customer or "site". > 2. There are a number of interpretations of requirement "d)": > > > - NUMBER OF ASSIGNMENTS > > -- The LIR has to have a plan to make at least 200 separate /48 > assignments. Possible scenario: LIR must make 200 > assignments > and the size of each must be a /48. > > -- The LIR has to have a plan to make at least the equivalent > of > 200 /48 assignments. Possible scenario: LIR can assign one > /41 and seventy-two /48s. > > Which interpretation was intended regarding the number of > assignments? Why not just "200 assignments"? And oh, while we are at it, why 200 assignments? > - RECIPIENT OF ASSIGNMENTS > > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations (regardless of which > organisation). Possible scenario: LIR can make 1 assignment > to its own organisation and 199 assignments to 199 > "different" organisations. > > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations outside of its own > infrastructure. > Possible scenario: LIR must make 200 assignments to 200 > "different" organisations. Assignments to its own > organisation will not be counted. > > -- The LIR has to have a plan to make these assignments to 200 > separate networks (regardless of which organisation these > networks belong to). Possible scenario: LIR makes 200 > assignments to 200 networks. 100 can be for its own > infrastructure and 100 can be for another single > organisation. > > -- The LIR has to have a plan to make these assignments to 200 > separate networks outside of its own infrastructure. > Possible > scenario: LIR makes 200 assignments to 200 networks "outside > of its own infrastructure". > > Which interpretation was intended regarding the recipient of > assignments? Actually non from the RIPE community if I remember. But we discussed this before. IF we want to stay with the 200 limit, I would say 200 assignments. Period. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+JAaarNKXTPFCVEQIVHQCfaApDWVknpVsKo/qUQB6DtDdJvu8AoLuQ ix5Dx9pTA5w2gU62swoVUiNN =PRPl -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Wed Jun 16 01:43:42 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 16 Jun 2004 01:43:42 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-14, at 11.34, Pekka Savola wrote: > >> - RECIPIENT OF ASSIGNMENTS >> >> -- The LIR has to have a plan to make these 200 assignments to >> 200 separate organisations (regardless of which >> organisation). Possible scenario: LIR can make 1 assignment >> to its own organisation and 199 assignments to 199 >> "different" organisations. > > No, your own allocations are not counted. Why not? If I have a large infrastructure, or is in the start-up phase or going through a network merger etc. I might have a lot of internal infrastructure but not many customer allocations. I fail to see why we would not include own allocations as those will be coming out of your block anyway. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+JtqarNKXTPFCVEQLPNwCdGUPO5YA3T6ZVY6OgdB9WpniemSgAoI1M nH85IqerKGd7H23Ge+ZMGBY2 =Hhkp -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Wed Jun 16 02:10:20 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 16 Jun 2004 02:10:20 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <20040615173628.0363a350.laura@ripe.net> References: <20040615173628.0363a350.laura@ripe.net> Message-ID: <8DBF53A8-BF29-11D8-8CB7-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-15, at 17.36, Laura Cobley wrote: > Below is an excerpt from the IPv6 Address Allocation and Assignment > Policy: > > 5.1.1. Initial allocation criteria "c)" > > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] plan to provide IPv6 connectivity to > organisations to which it will assign /48s by advertising that > connectivity through its single aggregated address allocation" > > > LIRs who operate closed/private networks appear not to qualify because > the address space in these networks will not be advertised. Was this > the > community's intention? More or less yes. If they do not plan to advertise this space, they should go for the "unique-site-local-replacement-addresses-that-you-are-not-allowed-to- route-globally-ever" (or whatever they will be called). - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+P8KarNKXTPFCVEQLCNQCfXZjr5+dl0X/Yi37xYlM0fs7SVdAAoN/0 dDnfaTnpuWSwxIx39mYLseek =YS11 -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Wed Jun 16 02:31:55 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 16 Jun 2004 02:31:55 +0200 Subject: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <16591.34932.680495.671278@ran.psg.com> References: <16FE3B16-BAB2-11D8-92D2-000A959B2120@isc.org> <652E0D74-BF24-11D8-8CB7-000A95928574@kurtis.pp.se> <16591.34932.680495.671278@ran.psg.com> Message-ID: <91F3BE78-BF2C-11D8-8CB7-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-16, at 01.38, Randy Bush wrote: >> Only servers that share the same path. At least if you are referring >> to >> dampening. > > damping is not per path There I get for writing emails after a full day of IPv6 meeting... You are of course right. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQM+U/qarNKXTPFCVEQIiWQCggVDeBczpVZ72LCTBGrpEG810woQAn0r7 LEIW/8BSU5sLpPTt0z01QRpS =Y8nX -----END PGP SIGNATURE----- From pekkas at netcore.fi Wed Jun 16 06:20:23 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 16 Jun 2004 07:20:23 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: Message-ID: On Wed, 16 Jun 2004, Kurt Erik Lindqvist wrote: > On 2004-06-14, at 11.34, Pekka Savola wrote: > >> - RECIPIENT OF ASSIGNMENTS > >> > >> -- The LIR has to have a plan to make these 200 assignments to > >> 200 separate organisations (regardless of which > >> organisation). Possible scenario: LIR can make 1 assignment > >> to its own organisation and 199 assignments to 199 > >> "different" organisations. > > > > No, your own allocations are not counted. > > Why not? If I have a large infrastructure, or is in the start-up phase > or going through a network merger etc. I might have a lot of internal > infrastructure but not many customer allocations. I fail to see why we > would not include own allocations as those will be coming out of your > block anyway. Because the original text required that the assignments are made to the *other* organizations. By all logic, only the assignments to the others should count. In any case, your own infrastructure shouldn't take more than a /48 or something like that, so it wouldn't be useful to count it either: 199 or 200 makes no difference -- this would become bad if you could just assign e.g. /38 to your own infrastructure and state you've already assigned worth of 200 /48's. -- 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 jim at rfc1035.com Tue Jun 15 19:18:51 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 15 Jun 2004 18:18:51 +0100 Subject: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Message from Peter Koch of "Tue, 15 Jun 2004 18:01:48 +0200." <200406151601.i5FG1m605126@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <7970.1087319931@gromit.rfc1035.com> Not having seen the whole discussion thread, it's a bit hard to make sense of what's been said. However it appears to be that someone is saying that the need for anycasting (and more specifically special address allocations for anycast name servers) can be discounted if ENDS0 was more widely used. This is a flawed argument IMO. As Peter has said, resolvers that aren't EDNS0-aware will still be pounding on the parent zone's name servers. [They're also much more likely to be the resolvers that are misconfigured to go to the root to reverse lookup RFC1918 addresses, don't implement negative caching and so on....] Simply adding more NS records and glue in the parent zone's delegation for a child zone is no help. For one thing, most name server implementations have a limit on the number of name servers they can handle for a delegation. Adding extra NS records is even less help when those servers have IPv6 addresses => yet bigger DNS payloads. In fact adding extra servers and/or IPv6 addresses may be worse because there's an increased likelihood of truncated responses getting sent to these non-EDNS0 resolvers, resulting in retried queries over TCP. Nasty. Aside from these DNS protocol issues, there are plenty of other good reasons for deploying anycasting for important DNS infrastructure. That's why lots of the root and TLD name server operators are doing this already. Ironically, these include the NCC's root name server. Anycasting provides increased robustness, extra redundancy, improved performance, better scalability, extra capacity/throughput, defence in depth from DDoS attacks, etc, etc. Anycasting isn't going to go away even if all the world's DNS software implemented EDNS0. Anycasting is a fact of life. And it will become more prominent in future. So if the address policy WG is reluctant to endorse special address allocations for DNS anycasting, I'd ask them to reconsider. If it helps, we could ask the DNS WG to discuss the issue and perhaps make a recommendation to the address policy WG. From amar at telia.net Wed Jun 16 12:02:52 2004 From: amar at telia.net (amar at telia.net) Date: Wed, 16 Jun 2004 12:02:52 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <1087380172.40d01acc2ea77@webmail.telia.net> Quoting Kurt Erik Lindqvist : > Why not? If I have a large infrastructure, or is in the start-up phase > or going through a network merger etc. I might have a lot of internal > infrastructure but not many customer allocations. I fail to see why we > would not include own allocations as those will be coming out of your > block anyway. The policy states that You can assign a /48 per POP - lets say a "broadband POP". If that should include the users asignments or not is not defined. -- amar ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From Joao_Damas at isc.org Wed Jun 16 16:38:01 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 16 Jun 2004 16:38:01 +0200 Subject: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <7970.1087319931@gromit.rfc1035.com> References: <7970.1087319931@gromit.rfc1035.com> Message-ID: wow, that was a dense mail, at least it's formatting :-) Just wanted to add, since there was a question about promoting the deployment of EDNS0, that some of us do indeed try to work on that line because it would make some matters simpler (eg. adding v6 glue without fear, having more root servers if needed, etc). DNSSEC requires the use of EDNS0 so maybe some people will migrate if DNSSEC takes off. Currently, some of us monitor the amount of queries using ENDS0 that reach the servers we operate. At least on F root this figure is more or less stable between 30-40% One thing to keep in mind is that there are products shipping today which are based on some version of BIND4, for instance, so they support DNS as it was known in the BIND 4 days. Although we have approached some of the manufacturers, they can't just "transition" in a short time. In the meantime life goes on and there is a need to cope with a growing Internet. Hope this helps clarify things a bit Joao On 15 Jun, 2004, at 19:18, Jim Reid wrote: > Not having seen the whole discussion thread, it's a bit hard to make > sense of what's been said. However it appears to be that someone is > saying that the need for anycasting (and more specifically special > address allocations for anycast name servers) can be discounted if > ENDS0 was more widely used. This is a flawed argument IMO. As Peter > has said, resolvers that aren't EDNS0-aware will still be pounding on > the parent zone's name servers. [They're also much more likely to be > the resolvers that are misconfigured to go to the root to reverse > lookup RFC1918 addresses, don't implement negative caching and so > on....] Simply adding more NS records and glue in the parent zone's > delegation for a child zone is no help. For one thing, most name > server implementations have a limit on the number of name servers they > can handle for a delegation. Adding extra NS records is even less help > when those servers have IPv6 addresses => yet bigger DNS payloads. In > fact adding extra servers and/or IPv6 addresses may be worse because > there's an increased likelihood of truncated responses getting sent to > these non-EDNS0 resolvers, resulting in retried queries over TCP. > Nasty. > > Aside from these DNS protocol issues, there are plenty of other good > reasons for deploying anycasting for important DNS infrastructure. > That's why lots of the root and TLD name server operators are doing > this already. Ironically, these include the NCC's root name server. > Anycasting provides increased robustness, extra redundancy, improved > performance, better scalability, extra capacity/throughput, defence in > depth from DDoS attacks, etc, etc. Anycasting isn't going to go away > even if all the world's DNS software implemented EDNS0. Anycasting is > a fact of life. And it will become more prominent in future. > > So if the address policy WG is reluctant to endorse special address > allocations for DNS anycasting, I'd ask them to reconsider. If it > helps, we could ask the DNS WG to discuss the issue and perhaps make a > recommendation to the address policy WG. > From kurtis at kurtis.pp.se Thu Jun 17 09:58:21 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 17 Jun 2004 09:58:21 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <1087380172.40d01acc2ea77@webmail.telia.net> References: <1087380172.40d01acc2ea77@webmail.telia.net> Message-ID: <19FA2E39-C034-11D8-8CB7-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-16, at 12.02, amar at telia.net wrote: > > >> Why not? If I have a large infrastructure, or is in the start-up phase >> or going through a network merger etc. I might have a lot of internal >> infrastructure but not many customer allocations. I fail to see why we >> would not include own allocations as those will be coming out of your >> block anyway. > > The policy states that You can assign a /48 per POP - lets say > a "broadband POP". If that should include the users asignments > or not is not defined. Right. And I am arguing that those /48s should be included in the 200 limit. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNFPIaarNKXTPFCVEQI/lgCg2AMfFbKbRljx9vJGfBdzf7/zNsQAn2rq B0DIIaq+XYHNPoc9ATyFXN4K =FFGL -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Thu Jun 17 09:59:46 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 17 Jun 2004 09:59:46 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Because the original text required that the assignments are made to > the *other* organizations. By all logic, only the assignments to the > others should count. > > In any case, your own infrastructure shouldn't take more than a /48 or > something like that, so it wouldn't be useful to count it either: 199 > or 200 makes no difference -- this would become bad if you could just > assign e.g. /38 to your own infrastructure and state you've > already assigned worth of 200 /48's. See the email from Amar. Also, if you have several operating companies you might want to have separate assignments for each of them. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNFPdqarNKXTPFCVEQKQFQCfb5RaQrTHk8tX+eBRTa7sRuRwJ/wAnipW 4D9dXvdbynovbsdHahJjB3ye =Wihj -----END PGP SIGNATURE----- From pekkas at netcore.fi Thu Jun 17 11:20:49 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 17 Jun 2004 12:20:49 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> Message-ID: On Thu, 17 Jun 2004, Kurt Erik Lindqvist wrote: > > Because the original text required that the assignments are made to > > the *other* organizations. By all logic, only the assignments to the > > others should count. > > > > In any case, your own infrastructure shouldn't take more than a /48 or > > something like that, so it wouldn't be useful to count it either: 199 > > or 200 makes no difference -- this would become bad if you could just > > assign e.g. /38 to your own infrastructure and state you've > > already assigned worth of 200 /48's. > > See the email from Amar. Also, if you have several operating companies > you might want to have separate assignments for each of them. I saw that -- but I don't see *any* justification for this interpretation. Remember, the goal is to require 200 assignments to *other* organizations, not be satisfied that you can make 200 assignemnts to your internal network, or 100 assignments to your internal network and 100 to other organizations! -- 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 jon at lawrence.org.uk Thu Jun 17 12:50:29 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 17 Jun 2004 11:50:29 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <200406171150.29481.jon@lawrence.org.uk> On Thursday 17 June 2004 10:20, Pekka Savola wrote: > > I saw that -- but I don't see *any* justification for this > interpretation. Remember, the goal is to require 200 assignments to > *other* organizations, not be satisfied that you can make 200 > assignemnts to your internal network, or 100 assignments to your > internal network and 100 to other organizations! And this is part of the problem. We won't be rolling IPv6 out ot 200 customers any time soon. So we can't get an allocation. Thus we can't run trials with IPv6. I really fail to see the reason behind the 200 other organisation rule - perhaps somee one would like to explain the logic. Jon From bertrand.maujean at semnet.tm.fr Thu Jun 17 13:50:15 2004 From: bertrand.maujean at semnet.tm.fr (Bertrand Maujean) Date: Thu, 17 Jun 2004 13:50:15 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <200406171150.29481.jon@lawrence.org.uk> Message-ID: <40D18577.961D64B2@semnet.tm.fr> Hello, we face the same problem. We are a small internet access provider in France. We provide internet in residential areas, and our customers currently use less than one IPv4 address per home. We do not want to assign a /48 to all our customers only to meet RIPE's criteria. We prefer using only a /32 for each of our broadband access server, and /48 only for customers asking for it (ie : customers who have a router, several subnets, ...). Bertrand Maujean Jon Lawrence a ?crit : > On Thursday 17 June 2004 10:20, Pekka Savola wrote: > > > > I saw that -- but I don't see *any* justification for this > > interpretation. Remember, the goal is to require 200 assignments to > > *other* organizations, not be satisfied that you can make 200 > > assignemnts to your internal network, or 100 assignments to your > > internal network and 100 to other organizations! > > And this is part of the problem. > We won't be rolling IPv6 out ot 200 customers any time soon. > So we can't get an allocation. Thus we can't run trials with IPv6. > I really fail to see the reason behind the 200 other organisation rule - > perhaps somee one would like to explain the logic. > > Jon -- Bertrand Maujean, responsable Informatique & Telecoms SEM Cable de l'Est - www.semnet.tm.fr 254 rue de la gare, 54710 Ludres - 03 83 25 97 82 From Michael.Dillon at radianz.com Thu Jun 17 14:21:39 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 17 Jun 2004 13:21:39 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406171150.29481.jon@lawrence.org.uk> Message-ID: > And this is part of the problem. > We won't be rolling IPv6 out ot 200 customers any time soon. > So we can't get an allocation. Thus we can't run trials with IPv6. > I really fail to see the reason behind the 200 other organisation rule - > perhaps somee one would like to explain the logic. There is no logic to the rule. You have come right to the crux of the problem. The rules make it unnecessarily difficult to get IPv6 addresses which makes it hard for LIRs to get the addresses needed to run trials. If an LIR has already justified an IPv4 address block from RIPE then they should qualify for a block of IPv6 addresses. It doesn't matter how many IPv4 addresses they have or what plans they have for IPv6. Only one thing matters: the organization has proven that they have a real IP network and can justify receiving a RIPE IPv4 allocation. This means that they are a real IP network operator. And since all IP network operators will tranisition to IPv6 at some time in the future, they should need no other justification for an IPv6 allocation. The same rule should apply in all the other 4 RIR regions. The pseudo-logic behind this rule is that IPv4 addresses are scarce therefore we have to be careful how many we allocate and who we give them to. Since IPv6 is like IPv4 we also need complex rules to limit who gets addresses. The flaw is that IPv6 is not *LIKE* IPv4. It is a simpler and more flexible version of the Internet Protocol that has a vastly larger address space. The block of IPv6 unicast addresses currently earmarked for the RIRs is only a small part of the total address space. If we waste all of this by making dumb decisions then we still have plenty of other address space to use later on when we are wiser and have more IPv6 experience. This means that the risk of doing the wrong thing is vastly smaller than it was with IPv4. We should plan to err on the side of simplicity and flexibilty, i.e. give everyone an IPv6 allocation if they already have an IP network. There is very little downside to doing this. --Michael Dillon From pekkas at netcore.fi Thu Jun 17 14:23:33 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 17 Jun 2004 15:23:33 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406171150.29481.jon@lawrence.org.uk> Message-ID: Replying to two messages in one go.. On Thu, 17 Jun 2004, Jon Lawrence wrote: > On Thursday 17 June 2004 10:20, Pekka Savola wrote: > > > > I saw that -- but I don't see *any* justification for this > > interpretation. Remember, the goal is to require 200 assignments to > > *other* organizations, not be satisfied that you can make 200 > > assignemnts to your internal network, or 100 assignments to your > > internal network and 100 to other organizations! > > And this is part of the problem. > We won't be rolling IPv6 out ot 200 customers any time soon. > So we can't get an allocation. Thus we can't run trials with IPv6. > I really fail to see the reason behind the 200 other organisation rule - > perhaps somee one would like to explain the logic. Now, this is another argument *altogether*, not a reason to start counting internal assignments. If we want to discuss whether rewording the 200 customers rule needs tuning, let's discuss that. I think the spirit (and the implementation) of the policy is that if you have 200 customers which *might* want IPv6 (but you haven't seen actual interest from 200 customers), and you'd be willing to give it to them if they asked, you'd qualify under the "200" rule in any case. Nobody will be withdrawing your allocation just because all your customers didn't yet realize that IPv6 is a good thing. Bertrand Maujean : > we face the same problem. We are a small internet access provider in France. > We provide internet in residential areas, and our customers currently use > less than one IPv4 address per home. Because they use NAT with IPv4. They won't with IPv6, so they require sufficient number of addresses -- at least a /64, and in case they'd want to subnet, a /48. The simplest would be just giving /48 to everyone. > We do not want to assign a /48 to all > our customers only to meet RIPE's criteria. Do you mean that you don't want to give the users a /48, but rather something smaller, like /64? That's a bad idea IMHO. > We prefer using only a /32 for each of our broadband access server, and /48 > only for customers asking for it (ie : customers who have a router, several > subnets, ...). /32 for each broadband access router? How many /32's do you intend to get??! :) Was this a typo? Why not just give /48 to everyone whether they want it or not? Or at least reserve /48 to everyone, but only assign a /64 or the like if they don't support prefix delegation or other mechanisms? That way you'd fulfill the allocation criteria as well, and make the users happier. -- 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 chbm at cprm.net Thu Jun 17 14:46:06 2004 From: chbm at cprm.net (Carlos Morgado) Date: Thu, 17 Jun 2004 13:46:06 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <200406171150.29481.jon@lawrence.org.uk> Message-ID: <20040617124606.GA28680@cprm.net> On Thu, Jun 17, 2004 at 01:21:39PM +0100, Michael.Dillon at radianz.com wrote: > IPv4 addresses they have or what plans they have for IPv6. Only one > thing matters: the organization has proven that they have a real > IP network and can justify receiving a RIPE IPv4 allocation. > This means that they are a real IP network operator. And since > all IP network operators will tranisition to IPv6 at some time > in the future, they should need no other justification for an > IPv6 allocation. > Here here. This process should be much more streamlined than the person doing the IPv6 initiall allocation request saying "we have n networks, covering m addresses, we plan to dual stack everything in the future so we need x IPv6 space". There should be a simple rule saying for x IPv4 space you get y IPv6 space, if you need more you'd need to justify it. > The same rule should apply in all the other 4 RIR regions. > > The pseudo-logic behind this rule is that IPv4 addresses are > scarce therefore we have to be careful how many we allocate > and who we give them to. Since IPv6 is like IPv4 we also need > complex rules to limit who gets addresses. The flaw is that > IPv6 is not *LIKE* IPv4. It is a simpler and more flexible Even if it was *LIKE* IPv4, using the same criteria would make sense. As it's not, using IPv4 has a criteria means you're already using a stricter criteria than needed. > > This means that the risk of doing the wrong thing is vastly > smaller than it was with IPv4. We should plan to err on the side > of simplicity and flexibilty, i.e. give everyone an IPv6 allocation > if they already have an IP network. There is very little downside > to doing this. > As oposed to making needlessly hard to get an assigment on the edges of the Internet, where the commercial demand starts. cheers -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From amar at telia.net Thu Jun 17 14:55:36 2004 From: amar at telia.net (amar at telia.net) Date: Thu, 17 Jun 2004 14:55:36 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <1087476936.40d194c8b7530@webmail.telia.net> Quoting Pekka Savola : > I saw that -- but I don't see *any* justification for this > interpretation. Remember, the goal is to require 200 assignments to > *other* organizations, not be satisfied that you can make 200 > assignemnts to your internal network, or 100 assignments to your > internal network and 100 to other organizations! If so - please state this clearly in the policy so noone will make their own "interpretation" of how this should be done. -- amar ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From woeber at cc.univie.ac.at Thu Jun 17 14:54:36 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 17 Jun 2004 14:54:36 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" Message-ID: <00A33803.78E55A18.30@cc.univie.ac.at> > We do not want to assign a /48 to all >our customers only to meet RIPE's criteria. > >We prefer using only a /32 for each of our broadband access server, and /48 >only for customers asking for it (ie : customers who have a router, several >subnets, ...). First of all, I think you got the prefix length stuff mixed up altogether (/32 for each access server?! :-) But more importantly, why do you intend to continue with the "address space scarcity" paradigm towards your customers? This sounds very much like an attempt to carry over the (broken) v4-business model for services into the v6 world, like - "you want a permanent address?" - well, this i not available in this package because the NCC forces us to do dynamic address management" or - "more than one permanent address?" - well, unfortunately this is not possible for this end-user package, you have to go for a business service which gives you 4/8/16 addresses, but unfortunately you _also_ have to subscribe to a bigger bandwith" at the same time,... >Bertrand Maujean Wilfried. From jon at lawrence.org.uk Thu Jun 17 15:33:07 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 17 Jun 2004 14:33:07 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <200406171433.07689.jon@lawrence.org.uk> On Thursday 17 June 2004 13:23, Pekka Savola wrote: > > On Thu, 17 Jun 2004, Jon Lawrence wrote: > > On Thursday 17 June 2004 10:20, Pekka Savola wrote: > > > I saw that -- but I don't see *any* justification for this > > > interpretation. Remember, the goal is to require 200 assignments to > > > *other* organizations, not be satisfied that you can make 200 > > > assignemnts to your internal network, or 100 assignments to your > > > internal network and 100 to other organizations! > > > > And this is part of the problem. > > We won't be rolling IPv6 out ot 200 customers any time soon. > > So we can't get an allocation. Thus we can't run trials with IPv6. > > I really fail to see the reason behind the 200 other organisation rule - > > perhaps somee one would like to explain the logic. > > Now, this is another argument *altogether*, not a reason to start > counting internal assignments. If we want to discuss whether > rewording the 200 customers rule needs tuning, let's discuss that. Agreed - I was just wondering if anyone remembered why the 200 rule came into being in the first place. The documentation clearly states 200 end user sites. So I'd interpret that as meaning that internal assignments didn't count. > I think the spirit (and the implementation) of the policy is that if > you have 200 customers which *might* want IPv6 (but you haven't seen > actual interest from 200 customers), and you'd be willing to give it > to them if they asked, you'd qualify under the "200" rule in any case. > Nobody will be withdrawing your allocation just because all your > customers didn't yet realize that IPv6 is a good thing. Must say I'd never thought of it quite like that. I suppose you could see it as 'I planned to issue 200 /48's but my customers couldn't or wouldn't use IPv6'. Jon From gert at space.net Thu Jun 17 21:47:36 2004 From: gert at space.net (Gert Doering) Date: Thu, 17 Jun 2004 21:47:36 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> Message-ID: <20040617194736.GH6204@Space.Net> Hi, On Thu, Jun 17, 2004 at 12:20:49PM +0300, Pekka Savola wrote: > I saw that -- but I don't see *any* justification for this > interpretation. Remember, the goal is to require 200 assignments to > *other* organizations, not be satisfied that you can make 200 > assignemnts to your internal network, or 100 assignments to your > internal network and 100 to other organizations! *I* always thought the primary goal was to get IPv6 deployed... (and the "200" number is in there to get some sort of rough filter to get only those IPv6 "adaptors" that really want to do some sort of IPv6 distribution to third parties) Gert Doering (speaking mainly as IPv6 user, not as co-chair) -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 17 21:57:14 2004 From: gert at space.net (Gert Doering) Date: Thu, 17 Jun 2004 21:57:14 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406171150.29481.jon@lawrence.org.uk> References: <200406171150.29481.jon@lawrence.org.uk> Message-ID: <20040617195714.GI6204@Space.Net> Hi, On Thu, Jun 17, 2004 at 11:50:29AM +0100, Jon Lawrence wrote: > And this is part of the problem. > We won't be rolling IPv6 out ot 200 customers any time soon. > So we can't get an allocation. Thus we can't run trials with IPv6. > I really fail to see the reason behind the 200 other organisation rule - > perhaps somee one would like to explain the logic. To clarify this, speaking officially as AP WG co-chair. - to gain IPv6 experience and to run trials, you should be able to get a /48 or bigger from your friendly IPv6 neighbour / tunnel peer / upstream. - if you have serious *plans* (<< note the emphasis) for deploying IPv6 services, and you have more than 200 IPv4 customers (!), *or* there is a remote chance that you will have 200 IPv6 customers in two years, you qualify for an IPv6 allocation. This is one of the most misunderstood parts of the policy. It's sole purpose is to weed out those that want IPv6 only for their own network, not to stifle IPv6 deployment for those LIRs that really want to get the ball rolling. Nobody can claim to be 100 per cent *sure* to have 200 IPv6 customers in two years (or even a /20 worth :-) ) - and that's the reason why the number of your IPv4 customers is also taken into account when judging the application. Or, to phrase it differently. As of today, *no single* IPv6 allocation request has been denied by the RIPE NCC. Sometimes they ask questions, or want a somewhat creative network plan. Some people get scared away by this - but so far, all serious requests have been approved. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Thu Jun 17 22:05:45 2004 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jun 2004 13:05:45 -0700 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> Message-ID: <16593.63897.529194.660823@ran.psg.com> > *I* always thought the primary goal was to get IPv6 deployed... i would think that the primary goal was to move the customers' packets. if they want us to move ipv6, them it's moving ipv6. we are concerned that it is deployABLE, because customers may want it. but our job is not to get ipv6 deployed. randy From gert at space.net Thu Jun 17 22:09:55 2004 From: gert at space.net (Gert Doering) Date: Thu, 17 Jun 2004 22:09:55 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <200406171150.29481.jon@lawrence.org.uk> Message-ID: <20040617200955.GJ6204@Space.Net> Hi, On Thu, Jun 17, 2004 at 01:21:39PM +0100, Michael.Dillon at radianz.com wrote: > You have come right to the crux of the problem. The rules make it > unnecessarily difficult to get IPv6 addresses which makes it hard > for LIRs to get the addresses needed to run trials. For trials, you don't need your own allocation. If you're serious about deployment, you can get an allocation. [..] > This means that the risk of doing the wrong thing is vastly > smaller than it was with IPv4. We should plan to err on the side > of simplicity and flexibilty, i.e. give everyone an IPv6 allocation > if they already have an IP network. There is very little downside > to doing this. The members of all the RIR communities (*you*) have clearly voiced that they did not want this. *I* did propose, some years in the past, to just give a /32 to every LIR that asks for it... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 17 22:15:17 2004 From: gert at space.net (Gert Doering) Date: Thu, 17 Jun 2004 22:15:17 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040617124606.GA28680@cprm.net> References: <200406171150.29481.jon@lawrence.org.uk> <20040617124606.GA28680@cprm.net> Message-ID: <20040617201517.GK6204@Space.Net> Hi, On Thu, Jun 17, 2004 at 01:46:06PM +0100, Carlos Morgado wrote: > As oposed to making needlessly hard to get an assigment on the edges of the > Internet, where the commercial demand starts. We have about 355 IPv6 allocations to LIRs in the RIPE region. Most of them are to medium sized or small ISPs that want to "get IPv6 started". To me, this looks as if it's quite possible to get an IPv6 allocation under the current policy. But still: if you want to have it changed, please write a specific proposal for the change (*this* thread is mainly meant to clarify the wording of the existing policy, without actually changing it - but that doesn't mean it can't be done), and send it to the apwg mailing list. Consider the pros and cons of the change, and maybe the reasons behind the things being what they are now (should all be in the mailing list archives). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 17 22:20:46 2004 From: gert at space.net (Gert Doering) Date: Thu, 17 Jun 2004 22:20:46 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <16593.63897.529194.660823@ran.psg.com> References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> Message-ID: <20040617202046.GL6204@Space.Net> Hi, now this is getting philosophical, and might better belong to the ipv6-wg mailing list... but still. On Thu, Jun 17, 2004 at 01:05:45PM -0700, Randy Bush wrote: > > *I* always thought the primary goal was to get IPv6 deployed... > > i would think that the primary goal was to move the customers' > packets. if they want us to move ipv6, them it's moving ipv6. > we are concerned that it is deployABLE, because customers may > want it. > > but our job is not to get ipv6 deployed. Actually it *is* part of my job description here :-) If the move to IPv6 is ever going to happen, we should better have a large part of "the network" prepared for it - and that includes rolling out v6 address space to ISPs, deploying it in our networks, and learning from lots of mistakes, so that eventually we can move customer's IPv6 packets in good faith that they might arrive at their indended goals. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From niallm at enigma.ie Thu Jun 17 18:07:24 2004 From: niallm at enigma.ie (Niall Richard Murphy) Date: Thu, 17 Jun 2004 17:07:24 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406171433.07689.jon@lawrence.org.uk> References: <200406171433.07689.jon@lawrence.org.uk> Message-ID: <20040617160724.GA98994@enigma.ie> On Thu, Jun 17, 2004 at 02:33:07PM +0100, Jon Lawrence wrote: > Must say I'd never thought of it quite like that. I suppose you could see it > as 'I planned to issue 200 /48's but my customers couldn't or wouldn't use > IPv6'. I planned to issue 200 /48's, but all I got was this lousy T-shirt. Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. 802.11 deployment in Dublin: http://www.enigma.ie/wardrive/ From kurtis at kurtis.pp.se Fri Jun 18 21:08:10 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 18 Jun 2004 21:08:10 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406171433.07689.jon@lawrence.org.uk> References: <200406171433.07689.jon@lawrence.org.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-17, at 15.33, Jon Lawrence wrote: >> >> Now, this is another argument *altogether*, not a reason to start >> counting internal assignments. If we want to discuss whether >> rewording the 200 customers rule needs tuning, let's discuss that. > > Agreed - I was just wondering if anyone remembered why the 200 rule > came into > being in the first place. > The documentation clearly states 200 end user sites. So I'd interpret > that as > meaning that internal assignments didn't count. Which I am arguing is silly. We want IPv6 deployment to take off, right? So let's set the threshold for getting blocks fairly low. There is already a price on IPv6 blocks, the LIR fee. The 200 sites/end-users/customers/whatever does not make much sense. We are all even using fairly divergent specs for what the requirement is. And I don't remember it from the top of my head. However, I would argue that 200 assignments (internal, external, whatever you want) is enough. It's a measurement we have fairly good grip on by now. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNM9nqarNKXTPFCVEQJ0vACeMyf8pn3MCKOHZT0076rL1vzrh88An0LB rgIYdV5omq+OFA3Qs7/vB9Xw =ABb2 -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Fri Jun 18 21:04:14 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 18 Jun 2004 21:04:14 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <4A5C07C3-C15A-11D8-BFCA-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> I saw that -- but I don't see *any* justification for this >>> interpretation. Remember, the goal is to require 200 assignments to >>> *other* organizations, not be satisfied that you can make 200 >>> assignemnts to your internal network, or 100 assignments to your >>> internal network and 100 to other organizations! >> >> And this is part of the problem. >> We won't be rolling IPv6 out ot 200 customers any time soon. >> So we can't get an allocation. Thus we can't run trials with IPv6. >> I really fail to see the reason behind the 200 other organisation >> rule - >> perhaps somee one would like to explain the logic. > > Now, this is another argument *altogether*, not a reason to start > counting internal assignments. If we want to discuss whether > rewording the 200 customers rule needs tuning, let's discuss that. I disagree. If we are to count assignments, we are to count internal ones as well. IF you then feel that 200 is to low, let's discuss. > I think the spirit (and the implementation) of the policy is that if > you have 200 customers which *might* want IPv6 (but you haven't seen > actual interest from 200 customers), and you'd be willing to give it > to them if they asked, you'd qualify under the "200" rule in any case. > Nobody will be withdrawing your allocation just because all your > customers didn't yet realize that IPv6 is a good thing. Actually, this "might" argument only came after it was apparent that the reason that noone was asking for IPv6 allocations was that they realized they would never have 200 customers within two years. At least that is what I remember. I think we can stay with the 200 limit, BUT - Count internal blocks - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNM8sqarNKXTPFCVEQLb6wCeMJEzabA9xxFzI3jvkXCwW1jz5Z4AoKBn AceQTK4bDkpvEUg5sadZedWB =B9CA -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Fri Jun 18 21:13:24 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 18 Jun 2004 21:13:24 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <16593.63897.529194.660823@ran.psg.com> References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> Message-ID: <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-17, at 22.05, Randy Bush wrote: >> *I* always thought the primary goal was to get IPv6 deployed... > > i would think that the primary goal was to move the customers' > packets. if they want us to move ipv6, them it's moving ipv6. > we are concerned that it is deployABLE, because customers may > want it. > > but our job is not to get ipv6 deployed. Good point. If it where, people might realize that we forgot a bunch of stuff in IPv6. Such as multihoming...:-) But, I *think* that Gerts point was that our job is to make it as easy as possible to prepare for when (if) customers want IPv6. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNM+1qarNKXTPFCVEQLuoQCfYPlzoEQdi67Luz5CzCjoE948RKwAoIGH EglO6L5tXz6ei1XKAGle2SGO =HnZO -----END PGP SIGNATURE----- From pekkas at netcore.fi Sat Jun 19 13:31:44 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 19 Jun 2004 14:31:44 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <4A5C07C3-C15A-11D8-BFCA-000A95928574@kurtis.pp.se> Message-ID: On Fri, 18 Jun 2004, Kurt Erik Lindqvist wrote: > >>> I saw that -- but I don't see *any* justification for this > >>> interpretation. Remember, the goal is to require 200 assignments to > >>> *other* organizations, not be satisfied that you can make 200 > >>> assignemnts to your internal network, or 100 assignments to your > >>> internal network and 100 to other organizations! > >> > >> And this is part of the problem. > >> We won't be rolling IPv6 out ot 200 customers any time soon. > >> So we can't get an allocation. Thus we can't run trials with IPv6. > >> I really fail to see the reason behind the 200 other organisation > >> rule - > >> perhaps somee one would like to explain the logic. > > > > Now, this is another argument *altogether*, not a reason to start > > counting internal assignments. If we want to discuss whether > > rewording the 200 customers rule needs tuning, let's discuss that. > > I disagree. If we are to count assignments, we are to count internal > ones as well. IF you then feel that 200 is to low, let's discuss. No. The policy is: "d) have a plan for making at least 200 /48 assignments to other organisations within two years." Are an ISP's own PoPs or other parts of infrastructure "other organisations"? Nope. Never. Not by any English dictionary :). The purpose at this point is to clarify the policy, not to change it. You're confusing the issue by saying what you believe an optimal policy *SHOULD* be. I have an opinion about that as well, but that's out of scope of this debate, i.e., what the policy is and what it was intended to be (and 'other organisations' makes it crystal clear IMHO that you were not intended to count the internal assignments). -- 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 ripe-lst at eirconnect.net Sat Jun 19 14:07:26 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Sat, 19 Jun 2004 13:07:26 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <200406191307.26836.ripe-lst@eirconnect.net> On Saturday 19 June 2004 12:31, Pekka Savola wrote: > The purpose at this point is to clarify the policy, not to change it. Good point. So let's clarify this as "other organisations, not including internal assignments" and kick off a debate on changing the policy. A strict interpretation of the policy might help to get dome discussion going since, clearly, few memebers of the community are happy with it. Cheers, Sascha -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha at eirconnect.ie Ireland | http://www.eirconnect.ie From jon at lawrence.org.uk Sun Jun 20 10:02:15 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Sun, 20 Jun 2004 09:02:15 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <200406200902.15725.jon@lawrence.org.uk> On Saturday 19 June 2004 12:31, Pekka Savola wrote: > Are an ISP's own PoPs or other parts of infrastructure "other > organisations"? > > Nope. Never. Not by any English dictionary :). > Yes, it can be. You're all assuming that an LIR has to be an ISP. That's not always the case. The only infrastructure our LIR owns are the routers. We provide connectivity to several ISP's - including our own. Our ISP is simply another customer of the LIR. My personal opinion is that the '200' rule should be scrapped - this is obviously a topic for a different debate. but, in answer to the original question: "To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years." There is in my understanding no stipulation that these assignments must all be made to external organisations. Therefore an assignment to your own infrastructure counts - not that 1 assignment out of 200 makes a great deal of difference. Just my 2 peneth worth. Regards, Jon Lawrence From jordi.palet at consulintel.es Sun Jun 20 13:05:09 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 Jun 2004 13:05:09 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <20040614103640.491b4038.laura@ripe.net> Message-ID: <462601c456b6$74203180$8700000a@consulintel.es> Hi all, See my inputs below in-line. Besides this, I think we are realizing that a change in the policy is needed. My understanding is that the current policy was developed in much different circumstances, including the main one, that at that time was not "so clear" IPv6 will be deployed, at least not in a short time, and this is clearly happening now and fast. Actually, one of the motivations for http://www.ripe.net/ipv6/ipv6-support-20040512.html was "Encouraging the participation of all those who are interested in the IPv6 policy development process". I guess there are more and more communities with IPv6 deployment experience, and unfortunately they are not all participating in the policy process. On the other way around also, not all the LIRs/ISPs have IPv6 experience, and may be this is one of the hurdles for the deployment take up, they could actually believe is much more difficult that the reality. Actually I know for ISPs that just don't consider even asking RIPE about an allocation, because their reading of the policy is like "you are really going to deploy IPv6 and ensure to have 200 customers soon". My feeling is that we need to facilitate the IPv6 deployment. Some of my thoughts: 1) Do we really want to keep the "intend" to provide 200 /48 (or an equivalent distribution) in two years ? May be we can extend this period to 5 years ? 2) Is 200 /48 appropriate ? I know about ISPs with LESS customers than that. May be is time to think in that today the point must be to just have interest in using IPv6 some time, even when no concrete users are asking for it. If the ISP want to make some experiments, is ridiculous to me asking them to go for an experimental allocation, then once they finish the experiment, to move for the real allocation. The experimental allocations must be for "experimental" things, not just for "not sure if I'm going to deploy IPv6, let me try". 3) The policy should not be different than in the case of IPv6 regarding own structure, others, or any mix of both. I think just using IPv6 should provide the right for an allocation. 4) I will go even further: Why not provide IPv6 allocations by default to all the IPv4 ISPs, unless they clearly state they aren't going to use it ? 5) And even much further, should be mandatory for the ISPs, in a time frame of for example 5 years, to provide IPv6 services IF they want to keep their IPv4 allocations ? Regards, Jordi ----- Original Message ----- From: "Laura Cobley" To: Sent: Monday, June 14, 2004 10:36 AM Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > Dear Colleagues, > > We have received many comments that the text of the current IPv6 > Allocation and Assignment Policy document can be difficult to read and > understand. Some of these difficulties were presented at RIPE 48 by Leo > Vegoda: > > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-policy.pdf > > During the following discussions, the RIPE NCC was asked to co-ordinate > work on clarifying the text. Please note that we do not intend to > propose any policy changes. > > In order to assist with rewriting the IPv6 Policy document, we would > like to have some input from the community on the issues needing > clarification. We will send each issue for discussion in a separate > mail. > > This is the first of these mails. > > > Below is an excerpt from the IPv6 Address Allocation and Assignment > Policy: > > 5.1.1. Initial allocation criteria "d)" > > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] have a plan for making at least 200 /48 > assignments to other organisations within two years." > > > 1. According to this criterion, LIRs who are operators planning to only > make /64 assignments appear not to qualify. Was this the community's > intention? > > > 2. There are a number of interpretations of requirement "d)": > > > - NUMBER OF ASSIGNMENTS > > -- The LIR has to have a plan to make at least 200 separate /48 > assignments. Possible scenario: LIR must make 200 assignments > and the size of each must be a /48. > > -- The LIR has to have a plan to make at least the equivalent of > 200 /48 assignments. Possible scenario: LIR can assign one > /41 and seventy-two /48s. > > Which interpretation was intended regarding the number of > assignments? I think the intend was 200 /48 or anything more or less equivalent. > > > - RECIPIENT OF ASSIGNMENTS > > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations (regardless of which > organisation). Possible scenario: LIR can make 1 assignment > to its own organisation and 199 assignments to 199 > "different" organisations. > > -- The LIR has to have a plan to make these 200 assignments to > 200 separate organisations outside of its own infrastructure. > Possible scenario: LIR must make 200 assignments to 200 > "different" organisations. Assignments to its own > organisation will not be counted. > > -- The LIR has to have a plan to make these assignments to 200 > separate networks (regardless of which organisation these > networks belong to). Possible scenario: LIR makes 200 > assignments to 200 networks. 100 can be for its own > infrastructure and 100 can be for another single > organisation. > > -- The LIR has to have a plan to make these assignments to 200 > separate networks outside of its own infrastructure. Possible > scenario: LIR makes 200 assignments to 200 networks "outside > of its own infrastructure". > > Which interpretation was intended regarding the recipient of > assignments? I don't think it was clearly foreseen if the 200 assignments exclude "own" assignments. > > We look forward to receiving the community's input on this. > > Best Regards, > > Laura Cobley > Registration Services > RIPE NCC > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Sun Jun 20 13:05:19 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 Jun 2004 13:05:19 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" References: <20040615173628.0363a350.laura@ripe.net> Message-ID: <462701c456b6$7a16d5d0$8700000a@consulintel.es> In my opinion, closed networks today, could be connected tomorrow, and consequently advertised, so why exclude them ? Excluding them will mean that if a network is disconnected, so no advertised, even by accident, they could miss the right for that allocation ? Regards, Jordi ----- Original Message ----- From: "Laura Cobley" To: Sent: Tuesday, June 15, 2004 5:36 PM Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" > Dear Colleagues, > > As explained in the email sent on Mon, 14 Jun 2004: > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html > > This is the second mail request for clarification of the IPv6 Address > Allocation and Assignment Policy. > > > Below is an excerpt from the IPv6 Address Allocation and Assignment > Policy: > > 5.1.1. Initial allocation criteria "c)" > > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] plan to provide IPv6 connectivity to > organisations to which it will assign /48s by advertising that > connectivity through its single aggregated address allocation" > > > LIRs who operate closed/private networks appear not to qualify because > the address space in these networks will not be advertised. Was this the > community's intention? > > > Best Regards, > > Laura Cobley > Registration Services > RIPE NCC > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From kurtis at kurtis.pp.se Mon Jun 21 08:42:28 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 21 Jun 2004 08:42:28 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <2998F10E-C34E-11D8-BBC1-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-19, at 13.31, Pekka Savola wrote: > Are an ISP's own PoPs or other parts of infrastructure "other > organisations"? > > Nope. Never. Not by any English dictionary :). I haven't claimed it to be. > The purpose at this point is to clarify the policy, not to change it. Is it? > You're confusing the issue by saying what you believe an optimal > policy *SHOULD* be. Yes, and? > I have an opinion about that as well, but that's > out of scope of this debate, i.e., what the policy is and what it was > intended to be (and 'other organisations' makes it crystal clear IMHO > that you were not intended to count the internal assignments). Well, it would be good if we understood the current policy, or at least that all had the same view of it. But if it is that unclear, we should perhaps revisit it. Which is what I am arguing for. And when we do - I think this is something that we need to get in there. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaDWKarNKXTPFCVEQLpMACfUW9B709p3aVgYNGHMCT2CwHN0J8An07k ++ZM5s4v1fUYDn0jzbwZagWR =gF4H -----END PGP SIGNATURE----- From mansaxel at sunet.se Sat Jun 19 16:12:57 2004 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Sat, 19 Jun 2004 16:12:57 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> Message-ID: <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> --On fredag 18 juni 2004 21.13 +0200 Kurt Erik Lindqvist wrote: > But, I *think* that Gerts point was that our job is to make it as easy > as possible to prepare for when (if) customers want IPv6. And our customers want it (since we're NREN, few others care right now..) but we've got our /32 so all is nice and hunky dory and they are satisifed. As soon as we can get these shiny v4 routers behave, that is. OTOH, I'd hate to see the same mistakes (that seemed reasonable at the time) that were made in the v4 sunrise period be repeated in v6, like: * too small assignments for customers forcing NAT in use, * dependency on temporary hacks that suddenly must be made permanent to keep the world rolling, [0] * The tendency of RIRen to act as if their main task was conserving address space when their job is to make sure that all reasonable requests get served. The way around this, imho, is to make large enough initial assignments, and to be liberal with them. I think that the 200 customer rule is silly, invites to lies, and in general, is counterproductive. Better would be to hand out one /32 (because I think it is a nice size) to any LIR asking for one, and then perhaps be tough on the second one. So: 1. Define that the 200 customers rule is "something", either including internal assignments or not. 2. Kill it. For it is bad. 3. Focus on multihoming. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE [0] I bet a beer that we'll see luser outcry june 7th 2005 because the nice 3FFE addresses don't work like they used to, coupled with a range of quick hacks to get it back running again. Imagine: Tunneling 3FFE:: over 2001:: over v4 to get around the deprecation.. MTU 384 bytes, on a lucky day ;-) From pekkas at netcore.fi Mon Jun 21 11:41:05 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 21 Jun 2004 12:41:05 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> Message-ID: On Sat, 19 Jun 2004, M?ns Nilsson wrote: > > But, I *think* that Gerts point was that our job is to make it as easy > > as possible to prepare for when (if) customers want IPv6. > > And our customers want it (since we're NREN, few others care right now..) > but we've got our /32 so all is nice and hunky dory and they are satisifed. > As soon as we can get these shiny v4 routers behave, that is. > > OTOH, I'd hate to see the same mistakes (that seemed reasonable at the > time) that were made in the v4 sunrise period be repeated in v6, like: [...] Remember, the current policy was designed to meet two goals: 1) giving easy access to an IPv6 prefix allocation for real ISPs, and 2) not giving a prefix to enterprises or "toy" (or other small) ISPs. The mechanisms how this has been policed to a degree have been the "200 /48's" and "_to other organizations_" rules. If we still agree that we don't want to give /32's to enterprises, toy ISPs without any real number of customers (hey! my consulting company has two connectivity customers as well, should I get a /32 prefix?), or such, we have to keep in some checks. On the other hand, I think everyone agrees that real ISPs, with a large numbers of customers, should get a v6 allocation without any hassle. The current policy has allowed that, even though it's wording (".. in two years") might have been a bit scary. -- 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 chbm at cprm.net Mon Jun 21 11:58:28 2004 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 21 Jun 2004 10:58:28 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> Message-ID: <20040621095827.GA28615@cprm.net> On Mon, Jun 21, 2004 at 12:41:05PM +0300, Pekka Savola wrote: > > If we still agree that we don't want to give /32's to enterprises, toy > ISPs without any real number of customers (hey! my consulting company > has two connectivity customers as well, should I get a /32 prefix?), > or such, we have to keep in some checks. > Have we figured out how to make multihoming work without giving multihomed networks their own prefix like in v4 ? -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From ripe-lst at eirconnect.net Mon Jun 21 12:02:40 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 21 Jun 2004 11:02:40 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <200406211102.40965.ripe-lst@eirconnect.net> On Monday 21 June 2004 10:41, Pekka Savola wrote: > 1) giving easy access to an IPv6 prefix allocation for real ISPs, and > 2) not giving a prefix to enterprises or "toy" (or other small) ISPs. I take offence at being called a "toy ISP". Apart from the moral issue here, this stance is probably illegal under EU law as it is blatantly anti-competitive. regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha at eirconnect.net Ireland | http://www.eirconnect.net From kurtis at kurtis.pp.se Mon Jun 21 12:10:49 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 21 Jun 2004 12:10:49 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621095827.GA28615@cprm.net> References: <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> <20040621095827.GA28615@cprm.net> Message-ID: <45144C26-C36B-11D8-BBC1-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 11.58, Carlos Morgado wrote: > On Mon, Jun 21, 2004 at 12:41:05PM +0300, Pekka Savola wrote: > >> >> If we still agree that we don't want to give /32's to enterprises, toy >> ISPs without any real number of customers (hey! my consulting company >> has two connectivity customers as well, should I get a /32 prefix?), >> or such, we have to keep in some checks. >> > > Have we figured out how to make multihoming work without giving > multihomed > networks their own prefix like in v4 ? Depends on your definition of "figured out". At the multi6 WG interim meeting last week we got down to 6 proposal from 32. And I think those 6 will come down to two fairly shortly. Then all we need to do is develop and implement it... I suggest joining the multi6 mailinglist. Instructions at http://www.ietf.org/html.charters/multi6-charter.html - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNa0LKarNKXTPFCVEQJFMgCfUoFi2ji1/2P+IxgUH2gkx+rRbYYAn1ph iwNvR0h/6q9c5bD1ZMnTb5ao =TuZe -----END PGP SIGNATURE----- From sascha at eirconnect.net Mon Jun 21 12:00:36 2004 From: sascha at eirconnect.net (Sascha Luck) Date: Mon, 21 Jun 2004 11:00:36 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <200406211100.36214.sascha@eirconnect.net> On Monday 21 June 2004 10:41, Pekka Savola wrote: > 1) giving easy access to an IPv6 prefix allocation for real ISPs, and > 2) not giving a prefix to enterprises or "toy" (or other small) ISPs. I take offence at being called a "toy ISP". Apart from the moral issue here, this stance is probably illegal under EU law as it is blatantly anti-competitive. regards, Sascha Luck -- Eirconnect | voice: 353 21 2307195 NSC Campus | fax: 353 21 2307197 Mahon, Cork | mailto:sascha at eirconnect.net Ireland | http://www.eirconnect.net From randy at psg.com Mon Jun 21 16:47:33 2004 From: randy at psg.com (Randy Bush) Date: Mon, 21 Jun 2004 10:47:33 -0400 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> Message-ID: <16598.62725.814865.102505@roam.psg.com> > OTOH, I'd hate to see the same mistakes (that seemed reasonable at the > time) that were made in the v4 sunrise period be repeated in v6, like: > > * too small assignments for customers forcing NAT in use, v4 sunrise had too BIG, not too small, assignments. hence all the underpopulated As abd Bs. it took a major war, cidrd, to fix that. and yes your point holds; we're doing it again. those who forget history are condemned to repeat it. randy From gert at space.net Mon Jun 21 18:09:26 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 18:09:26 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <462701c456b6$7a16d5d0$8700000a@consulintel.es> References: <20040615173628.0363a350.laura@ripe.net> <462701c456b6$7a16d5d0$8700000a@consulintel.es> Message-ID: <20040621160925.GB6204@Space.Net> Hi, On Sun, Jun 20, 2004 at 01:05:19PM +0200, JORDI PALET MARTINEZ wrote: > In my opinion, closed networks today, could be connected tomorrow, and > consequently advertised, so why exclude them ? A *LIR* usually doesn't (purposely) change back and forward from "operating a non-public network" and "being connected to the Internet". End-user networks do, but the policy isn't about end-users anyway - what end-users do depends on their contractual relation to the LIR of their choice and trust. If they have no LIR available, and are not connected to the Internet, they can use non-publically-routed-global-unique IPv6 space (IIRC it was Geoff Houston's draft). > Excluding them will mean that if a network is disconnected, so no advertised, even by accident, they could miss the right for that allocation ? Nobody will take an allocation away just because your core-router died. OTOH, if someone receives an allocation and it's not visible after two years (or any other reasonable time), one might start asking questions. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 21 18:13:37 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 18:13:37 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <16598.62725.814865.102505@roam.psg.com> References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> <16598.62725.814865.102505@roam.psg.com> Message-ID: <20040621161337.GC6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 10:47:33AM -0400, Randy Bush wrote: > and yes your point holds; we're doing it again. > > those who forget history are condemned to repeat it. I dimly remember that it was *you* that argued very much in favour of "give /48s to every end site, don't start handing out different sizes", some few meetings ago. So what's wrong with it, all of a sudden? Could you please be a bit more specific about what you think is fundamentally wrong about the current IPv6 policy, so that we might go and fix it? "A networks are too big" doesn't really hold - if anything, /32s are too small. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 21 18:20:12 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 18:20:12 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406191307.26836.ripe-lst@eirconnect.net> References: <200406191307.26836.ripe-lst@eirconnect.net> Message-ID: <20040621162012.GD6204@Space.Net> Hi, On Sat, Jun 19, 2004 at 01:07:26PM +0100, Sascha Luck wrote: > A strict interpretation of the policy might help to get dome discussion going > since, clearly, few memebers of the community are happy with it. I tend to disagree with that statement. Over 360 allocations have been made, so I'd say (again) that the policy seems to be working fairly well for a number of people. People have voiced complaints about unclear wording in the policy, and this needs to be fixed. Some people have complained about the "200 customers" rule, and this certainly needs discussion. *One* person is taking major offence at not being allowed to play with the big boys. This is to be expected if the community decides to draw a line at "who gets an allocation, who doesn't". Democratic procedures aren't necessarily *nice* to everybody. I count that as "one member is very unhappy, and a few others have sore spots", which is something different from "clearly, few members are happy"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 21 18:22:21 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 18:22:21 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406200902.15725.jon@lawrence.org.uk> References: <200406200902.15725.jon@lawrence.org.uk> Message-ID: <20040621162221.GE6204@Space.Net> Hi, On Sun, Jun 20, 2004 at 09:02:15AM +0100, Jon Lawrence wrote: > not that 1 assignment out of 200 makes a great deal of difference. I think this is a very important statement. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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-lst at eirconnect.net Mon Jun 21 19:20:14 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 21 Jun 2004 18:20:14 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621162012.GD6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> Message-ID: <200406211820.15292.ripe-lst@eirconnect.net> Hi Gert, On Monday 21 June 2004 17:20, Gert Doering wrote: > I tend to disagree with that statement. Over 360 allocations have been > made, so I'd say (again) that the policy seems to be working fairly well > for a number of people. Well these 360 people have not (yet?) piped up and said "We're happy, leave it as it is". > *One* person is taking major offence at not being allowed to play with > the big boys. Condescension will get us nowhere. Ok, we're a small ISP in a small market. Since we aim at the business/leased line market only, we may not have 200 customers, let alone 200 IPv6 allocations, within 2 years (I hope to be wrong, of course). Give me *one* good reason why we shouldn't be allowed to offer IPv6 connectivity? Give me a reason why we should lose *one*, otherwise happy, customer because of an arbitrary "line in the sand"? > This is to be expected if the community decides to draw > a line at "who gets an allocation, who doesn't". Democratic procedures > aren't necessarily *nice* to everybody. When was this policy democratically decided? IIRC it was handed down from IANA/ICANN (I may be wrong on this) Besides, there is no benefit to this rule as far as I can see. IPv6 space is not a scarce resource. IPv4 is, yet is is easy enough to get. > I count that as "one member is very unhappy, and a few others have > sore spots", which is something different from "clearly, few members > are happy"... If this is to be discussed, everyone who is happy with the existing rule is, of course, free to say so. Silence does not, necessarily, imply assent. Best regards, Sascha Luck Eirconnect From gert at space.net Mon Jun 21 19:31:41 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 19:31:41 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406211820.15292.ripe-lst@eirconnect.net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> Message-ID: <20040621173141.GH6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 06:20:14PM +0100, Sascha Luck wrote: > On Monday 21 June 2004 17:20, Gert Doering wrote: > > I tend to disagree with that statement. Over 360 allocations have been > > made, so I'd say (again) that the policy seems to be working fairly well > > for a number of people. > Well these 360 people have not (yet?) piped up and said "We're happy, leave it > as it is". They don't need to - the policy has fulfilled their purpose for them. > > *One* person is taking major offence at not being allowed to play with > > the big boys. > > Condescension will get us nowhere. Ok, we're a small ISP in a small market. > Since we aim at the business/leased line market only, we may not have 200 > customers, let alone 200 IPv6 allocations, within 2 years (I hope to be > wrong, of course). > Give me *one* good reason why we shouldn't be allowed to offer IPv6 > connectivity? Give me a reason why we should lose *one*, otherwise happy, > customer because of an arbitrary "line in the sand"? If you estimate that you will continue to be very small, you could use a /40 or such from one of your upstream ISPs (which is a problem *today*, as there are not enough upstream ISPs, indeed). If you are in good hope to reach more than 200 customers, you fulfill the criteria (as has been mentioned before). > > This is to be expected if the community decides to draw > > a line at "who gets an allocation, who doesn't". Democratic procedures > > aren't necessarily *nice* to everybody. > > When was this policy democratically decided? IIRC it was handed down from > IANA/ICANN (I may be wrong on this) You are wrong on this :-) - the policy was discussed again and again at various RIPE meetings in the past 5 years. We had an interim policy, which was bad, but better than none. Then we had this policy, which is still not perfect, but enabled us to make progress. > Besides, there is no benefit to this rule as far as I can see. IPv6 space is > not a scarce resource. IPv4 is, yet is is easy enough to get. I wasn't in favour of the 200-customer rule (which is in the archives :) ). Quite a number of people from various regions insisted on it, at that time, for fear of a "landrush" or "routing table explosion" (routing table slots *are* a scarce resource indeed, but changing this policy to "every LIR in existance today gets one" won't hurt *that* much). > > I count that as "one member is very unhappy, and a few others have > > sore spots", which is something different from "clearly, few members > > are happy"... > > If this is to be discussed, everyone who is happy with the existing rule is, > of course, free to say so. Silence does not, necessarily, imply assent. The way people work, usually only those who are unhappy take the burden to figure out *where* to voice their unhappiness... But anyway, I agree that this side-track discussion isn't overly productive. In fact, I have not heard anyone stand up and say "WE MUST KEEP THE 200 CUSTOMER RULE!" - most people voiced some sort of "well, it's there, it doesn't do much harm, we can live with it", but nobody has actively stood up in favour of it. Has anyone? So shall we abandon it? In favour of *what* to replace it? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 21 19:30:37 2004 From: randy at psg.com (Randy Bush) Date: Mon, 21 Jun 2004 13:30:37 -0400 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> <16598.62725.814865.102505@roam.psg.com> <20040621161337.GC6204@Space.Net> Message-ID: <16599.6973.631683.332@roam.psg.com> > I dimly remember that it was *you* that argued very much in favour > of "give /48s to every end site not exactly. i argued against it within the ivtf; thinking it was a bit short. and i was also against assigning /48s to dialu-ups. but when i presented the ivtf position, i presented the ivtf position, not my personal opinion. > "A networks are too big" doesn't really hold - if anything, /32s are > too small. might it not depend on the size of the network? that is a lesson we learned in cidr back in the early '90s. how many times do we need to learn it? randy From chbm at cprm.net Mon Jun 21 19:42:52 2004 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 21 Jun 2004 18:42:52 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621173141.GH6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> Message-ID: <20040621174252.GB29852@cprm.net> On Mon, Jun 21, 2004 at 07:31:41PM +0200, Gert Doering wrote: > > If you estimate that you will continue to be very small, you could use > a /40 or such from one of your upstream ISPs (which is a problem *today*, > as there are not enough upstream ISPs, indeed). Which one ? And, if he decides to drop that particular upstream he gets to renumber and ask all his clients to renumber ? Are you joking ? -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From ripe-lst at eirconnect.net Mon Jun 21 20:04:28 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 21 Jun 2004 19:04:28 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621173141.GH6204@Space.Net> References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> Message-ID: <200406211904.28278.ripe-lst@eirconnect.net> On Monday 21 June 2004 18:31, Gert Doering wrote: > If you estimate that you will continue to be very small, you could use > a /40 or such from one of your upstream ISPs (which is a problem *today*, > as there are not enough upstream ISPs, indeed). I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 for commercial purposes). TTBOMK, no multihoming facility exists without your own /32 allocation (considering aggregation, probably just as well). > If you are in good hope to reach more than 200 customers, you fulfill > the criteria (as has been mentioned before). Of course, I'm in good hope of reaching that goal. If that's good enough, fine but how do I document this hope? Will the NCC take my word for it? ;) > You are wrong on this :-) - the policy was discussed again and again at > various RIPE meetings in the past 5 years. We had an interim policy, which > was bad, but better than none. Then we had this policy, which is still > not perfect, but enabled us to make progress. Fair enough. I've only attended sporadically in the last few years, so this may well have slipped past me. Mea culpa. > Quite a number of people from various regions insisted on it, at that time, > for fear of a "landrush" or "routing table explosion" (routing table slots > *are* a scarce resource indeed, but changing this policy to "every LIR > in existance today gets one" won't hurt *that* much). Well the landslide hasn't happened as far as I can see :) Even though I'd love to see it happen. The routing table does need to be considered, but it still is IMO a technical problem. Although it seems there is a shift in v4 policies away from aggregation in favour of conservation (no more reservations for contiguous address space, etc) > The way people work, usually only those who are unhappy take the burden > to figure out *where* to voice their unhappiness... Hmm, reminds me of the recent European elections ;) > So shall we abandon it? In favour of *what* to replace it? My proposal would be similar to the ARIN (I think) one: Any LIR in good standing is entitled to a /32 with justification for any follow-up allocation. Best regards, Sascha Luck Eirconnect From oliver at bartels.de Mon Jun 21 20:06:32 2004 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 21 Jun 2004 20:06:32 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621173141.GH6204@Space.Net> Message-ID: <200406211805.i5LI5ltt025287@alpha.bartels.de> Hi, On Mon, 21 Jun 2004 19:31:41 +0200, Gert Doering wrote: >In fact, I have not heard anyone stand up and say "WE MUST KEEP THE 200 >CUSTOMER RULE!" - most people voiced some sort of "well, it's there, it >doesn't do much harm, we can live with it", but nobody has actively stood >up in favour of it. Has anyone? > >So shall we abandon it? In favour of *what* to replace it? My suggestion: "To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to non-affiliated organisations to which it will assign parts of this address space according to the RIPE policy; and d) plan to provide IPv6 connectivity to a significant part of their non-affiliated customer base by advertising such connectivity through its single aggregated address allocation" There is no well defined check for c) and d) (which is the same as the 200 customers limit, *of course* we all *plan* to provide connectivity to millions of very well paying IPv6 customers and would like to gain the income, however the reality in the market tells us something different). However it gives the NCC some chance to ask questions about allocations to "we need this rare resource" non-ISP organisations. However "ceterum censeo": The multihoming-without-renumbering problem must be solved *for such organisations* or IPv6 *won't* gain a significant market share. This is because e.g. Banks are not ISP's and clearly won't qualify for an allocation in most cases, *however* they won't give up their ISP independence gained by their LIR or PI status. And e.g. home banking might be some important argument for most customers ... Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From jordi.palet at consulintel.es Mon Jun 21 20:09:14 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 21 Jun 2004 20:09:14 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> Message-ID: <08bf01c457ba$dd581f50$8700000a@consulintel.es> Today RIPE is trusting you for the 200 customers commitment, but I don't think this is the point. Why not compare with the IPv4 allocations ? Is there any minimum number of customers in x years ? LACNIC, I believe, is also just granting the /32 if you commit to route it in some years (not sure how many), independently of how many customers you bring up. Regards, Jordi ----- Original Message ----- From: "Sascha Luck" To: Sent: Monday, June 21, 2004 8:04 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > On Monday 21 June 2004 18:31, Gert Doering wrote: > > > If you estimate that you will continue to be very small, you could use > > a /40 or such from one of your upstream ISPs (which is a problem *today*, > > as there are not enough upstream ISPs, indeed). > > I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 > for commercial purposes). TTBOMK, no multihoming facility exists without your > own /32 allocation (considering aggregation, probably just as well). > > > If you are in good hope to reach more than 200 customers, you fulfill > > the criteria (as has been mentioned before). > > Of course, I'm in good hope of reaching that goal. If that's good enough, fine > but how do I document this hope? Will the NCC take my word for it? ;) > > > You are wrong on this :-) - the policy was discussed again and again at > > various RIPE meetings in the past 5 years. We had an interim policy, which > > was bad, but better than none. Then we had this policy, which is still > > not perfect, but enabled us to make progress. > > Fair enough. I've only attended sporadically in the last few years, so this > may well have slipped past me. Mea culpa. > > > Quite a number of people from various regions insisted on it, at that time, > > for fear of a "landrush" or "routing table explosion" (routing table slots > > *are* a scarce resource indeed, but changing this policy to "every LIR > > in existance today gets one" won't hurt *that* much). > > Well the landslide hasn't happened as far as I can see :) Even though I'd love > to see it happen. > The routing table does need to be considered, but it still is IMO a technical > problem. Although it seems there is a shift in v4 policies away from > aggregation in favour of conservation (no more reservations for contiguous > address space, etc) > > > The way people work, usually only those who are unhappy take the burden > > to figure out *where* to voice their unhappiness... > > Hmm, reminds me of the recent European elections ;) > > > So shall we abandon it? In favour of *what* to replace it? > > My proposal would be similar to the ARIN (I think) one: > Any LIR in good standing is entitled to a /32 with justification for any > follow-up allocation. > > Best regards, > Sascha Luck > Eirconnect > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From gert at space.net Mon Jun 21 20:17:59 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 20:17:59 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <16599.6973.631683.332@roam.psg.com> References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> <16598.62725.814865.102505@roam.psg.com> <20040621161337.GC6204@Space.Net> <16599.6973.631683.332@roam.psg.com> Message-ID: <20040621181759.GI6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 01:30:37PM -0400, Randy Bush wrote: > > "A networks are too big" doesn't really hold - if anything, /32s are > > too small. > > might it not depend on the size of the network? that is a lesson > we learned in cidr back in the early '90s. how many times do we need > to learn it? Isn't that what we have? "You get a /32, unless you can explain why a bigger block is reasonable for your network, and in that case, you get more". So it *does* depend on the size of the network, but at the same time tries to reduce bureaucracy in the actual allocation process. (Personally, I'm a bit unhappy because I think the "32" number is erring towards the "conservation" side, and this might lead to having multiple allocations for ISPs that start small but grow quickly. But the way RIPE is currently reserving /29s for those ISPs, the case *should* be infrequent) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 21 20:37:36 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 20:37:36 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406211904.28278.ripe-lst@eirconnect.net> References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> Message-ID: <20040621183736.GJ6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 07:04:28PM +0100, Sascha Luck wrote: > On Monday 21 June 2004 18:31, Gert Doering wrote: > > If you estimate that you will continue to be very small, you could use > > a /40 or such from one of your upstream ISPs (which is a problem *today*, > > as there are not enough upstream ISPs, indeed). > > I could get native IPv6 connectivity from 3 upstreams today (OK, only from 2 > for commercial purposes). TTBOMK, no multihoming facility exists without your > own /32 allocation (considering aggregation, probably just as well). As of today, multihoming with a more-specific from one of your upstreams will work - using the classic BGP multihoming approach. I don't know what the multi6 WG will come up with in the end, but can't really imagine that there is something else which will work for an ISP. > > If you are in good hope to reach more than 200 customers, you fulfill > > the criteria (as has been mentioned before). > > Of course, I'm in good hope of reaching that goal. If that's good enough, fine > but how do I document this hope? Will the NCC take my word for it? ;) They have to :-) - in the last 5 years, hardly anybody could be *sure* to have 200 IPv6 customers after two years - but unless you are sure that you won't reach that goal (due to your customer structure, whatever) the underlying goal is "optimism and get IPv6 rolled out". [..] > > Quite a number of people from various regions insisted on it, at that time, > > for fear of a "landrush" or "routing table explosion" (routing table slots > > *are* a scarce resource indeed, but changing this policy to "every LIR > > in existance today gets one" won't hurt *that* much). > > Well the landslide hasn't happened as far as I can see :) Even though I'd love > to see it happen. Things are moving, and I think the current pace isn't too bad. Too fast will not necessarily help... > The routing table does need to be considered, but it still is IMO a technical > problem. Although it seems there is a shift in v4 policies away from > aggregation in favour of conservation (no more reservations for contiguous > address space, etc) Let's not discuss IPv4 policy in this thread (but I agree). [..] > > So shall we abandon it? In favour of *what* to replace it? > > My proposal would be similar to the ARIN (I think) one: > Any LIR in good standing is entitled to a /32 with justification for any > follow-up allocation. Well, initially all regions had the "200 customers" rule (which made the whole process difficult, because the goal was a *global* policy). I need to check whether this has changed recently in one of the other regions. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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-lst at eirconnect.net Mon Jun 21 21:00:57 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 21 Jun 2004 20:00:57 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621183736.GJ6204@Space.Net> References: <200406211904.28278.ripe-lst@eirconnect.net> <20040621183736.GJ6204@Space.Net> Message-ID: <200406212000.57260.ripe-lst@eirconnect.net> On Monday 21 June 2004 19:37, Gert Doering wrote: > Well, initially all regions had the "200 customers" rule (which made the > whole process difficult, because the goal was a *global* policy). > > I need to check whether this has changed recently in one of the other > regions. AFAIK, ARIN still have the 200 customer policy, the "good standing" is what they are proposing to change it to (it came up in discussion at RIPE-48) rgds, Sascha Luck From gert at space.net Mon Jun 21 21:04:45 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 21:04:45 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <08bf01c457ba$dd581f50$8700000a@consulintel.es> References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> <08bf01c457ba$dd581f50$8700000a@consulintel.es> Message-ID: <20040621190445.GK6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 08:09:14PM +0200, JORDI PALET MARTINEZ wrote: > Why not compare with the IPv4 allocations ? Why *do*? What relevance has IPv4 to IPv6 policy? (But actually, the current size of an ISPs network *is* taken into account when considering larger-than-/32 allocations) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 21 21:06:46 2004 From: gert at space.net (Gert Doering) Date: Mon, 21 Jun 2004 21:06:46 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406212000.57260.ripe-lst@eirconnect.net> References: <200406211904.28278.ripe-lst@eirconnect.net> <20040621183736.GJ6204@Space.Net> <200406212000.57260.ripe-lst@eirconnect.net> Message-ID: <20040621190646.GL6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 08:00:57PM +0100, Sascha Luck wrote: > > I need to check whether this has changed recently in one of the other > > regions. > > AFAIK, ARIN still have the 200 customer policy, the "good standing" is what > they are proposing to change it to (it came up in discussion at RIPE-48) OK. How exactly do you define "good standing"? This needs to be something that a RIR hostmaster can base a decision on...? Personally, I like Oliver Bartels' proposal. :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jordi.palet at consulintel.es Mon Jun 21 21:14:58 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 21 Jun 2004 21:14:58 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> <08bf01c457ba$dd581f50$8700000a@consulintel.es> <20040621190445.GK6204@Space.Net> Message-ID: <0a5501c457c4$0c1955d0$8700000a@consulintel.es> Hi Gert, Because in my opinion, we should not make today any distinction in what the ISP is committing to (in terms of number of customers) to deploy IPv6, same way we don't have this rational with IPv4. Is just IP !, and moreover, we should facilitate the move to IPv6. Furthermore, if an IPv4 LIR/ISP (not end user) is requesting IPv6, not ANY more questions should be asked. If he doesn't route it within a "normal" time frame (5 years, whatever years, or what the market trend self-defines), then RIPE can always claim back the prefix, exactly the same as for IPv4. Right ? As I commented already in one of my previous emails, I will just give a /32 to every LIR/ISP (not end user) unless: 1) He explicitly states "I'm not going to use it" or 2) He request something bigger and properly justify it. I agree that if a bigger than /32 prefix is requested, then we should make sure if this make sense. Regards, Jordi ----- Original Message ----- From: "Gert Doering" To: "JORDI PALET MARTINEZ" Cc: Sent: Monday, June 21, 2004 9:04 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > Hi, > > On Mon, Jun 21, 2004 at 08:09:14PM +0200, JORDI PALET MARTINEZ wrote: > > Why not compare with the IPv4 allocations ? > > Why *do*? What relevance has IPv4 to IPv6 policy? > > (But actually, the current size of an ISPs network *is* taken into account > when considering larger-than-/32 allocations) > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 60210 (58081) > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Mon Jun 21 21:28:02 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 21 Jun 2004 21:28:02 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" References: <20040615173628.0363a350.laura@ripe.net> <462701c456b6$7a16d5d0$8700000a@consulintel.es> <20040621160925.GB6204@Space.Net> Message-ID: <0a9501c457c5$e7544550$8700000a@consulintel.es> In IPv6 this could happen in the future, is true that may be not with LIRs, but with big end customers, but this big end customers will sooner or later claim for PI and sooner or later we should provide a solution for that. I think APNIC is working in something similar to "intermittently disconnected networks", but may be I'm wrong. Anyway the point probably is, as indicated in my previous email, to facilitate the allocations and not being restrictive regarding time or number of customers, but more looking at the real market trends. Difficult to measure ? not really if we look to the average situation and then we take a non-drastic approach, at least not initially with those not announcing their prefix even when the majority of the market is already doing so. They will lose the customers and probably kill themselves ... so if they are smart will not do so. Regards, Jordi ----- Original Message ----- From: "Gert Doering" To: "JORDI PALET MARTINEZ" Cc: Sent: Monday, June 21, 2004 6:09 PM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" > Hi, > > On Sun, Jun 20, 2004 at 01:05:19PM +0200, JORDI PALET MARTINEZ wrote: > > In my opinion, closed networks today, could be connected tomorrow, and > > consequently advertised, so why exclude them ? > > A *LIR* usually doesn't (purposely) change back and forward from > "operating a non-public network" and "being connected to the Internet". > > End-user networks do, but the policy isn't about end-users anyway - what > end-users do depends on their contractual relation to the LIR of their > choice and trust. If they have no LIR available, and are not connected > to the Internet, they can use non-publically-routed-global-unique IPv6 > space (IIRC it was Geoff Houston's draft). > > > Excluding them will mean that if a network is disconnected, so no advertised, even by accident, they could miss the right for that allocation ? > > Nobody will take an allocation away just because your core-router died. > > OTOH, if someone receives an allocation and it's not visible after two > years (or any other reasonable time), one might start asking questions. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 60210 (58081) > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From german at lacnic.net Mon Jun 21 22:04:02 2004 From: german at lacnic.net (German Valdez) Date: Mon, 21 Jun 2004 17:04:02 -0300 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <08bf01c457ba$dd581f50$8700000a@consulintel.es> References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> <08bf01c457ba$dd581f50$8700000a@consulintel.es> Message-ID: <6.1.1.1.2.20040621170113.0723e598@lacnic.net.uy> Hi All At 03:09 PM 6/21/2004, JORDI PALET MARTINEZ wrote: >Today RIPE is trusting you for the 200 customers commitment, but I don't >think this is the point. > >Why not compare with the IPv4 allocations ? Is there any minimum number of >customers in x years ? > >LACNIC, I believe, is also just granting the /32 if you commit to route it >in some years (not sure how many), independently of how many customers you >bring up. It is one year and offer some kind of IPv6 services before 24 months after the allocation is made. Full list of initial allocation is as follow To qualify for an initial allocation of IPv6 address space, an organization must: a) Be a LIR or an ISP; b) Not be an end site (end user); c) Document a detailed plan for the services and IPv6 connectivity to be offered to other organizations (clients) d) Announce a single block in the Internet inter-domain routing system, aggregating the total IPv6 address allocation received, within a period not longer than 12 months. e) Offer IPv6 services to clients physically located within the region covered by LACNIC within a period not longer than 24 months. Regards German Valdez LACNIC >Regards, >Jordi > >----- Original Message ----- >From: "Sascha Luck" >To: >Sent: Monday, June 21, 2004 8:04 PM >Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial >allocation criteria "d)" > > > > On Monday 21 June 2004 18:31, Gert Doering wrote: > > > > > If you estimate that you will continue to be very small, you could use > > > a /40 or such from one of your upstream ISPs (which is a problem *today*, > > > as there are not enough upstream ISPs, indeed). > > > > I could get native IPv6 connectivity from 3 upstreams today (OK, only > from 2 > > for commercial purposes). TTBOMK, no multihoming facility exists > without your > > own /32 allocation (considering aggregation, probably just as well). > > > > > If you are in good hope to reach more than 200 customers, you fulfill > > > the criteria (as has been mentioned before). > > > > Of course, I'm in good hope of reaching that goal. If that's good > enough, fine > > but how do I document this hope? Will the NCC take my word for it? ;) > > > > > You are wrong on this :-) - the policy was discussed again and again at > > > various RIPE meetings in the past 5 years. We had an interim policy, > which > > > was bad, but better than none. Then we had this policy, which is still > > > not perfect, but enabled us to make progress. > > > > Fair enough. I've only attended sporadically in the last few years, so > this > > may well have slipped past me. Mea culpa. > > > > > Quite a number of people from various regions insisted on it, at that > time, > > > for fear of a "landrush" or "routing table explosion" (routing table > slots > > > *are* a scarce resource indeed, but changing this policy to "every LIR > > > in existance today gets one" won't hurt *that* much). > > > > Well the landslide hasn't happened as far as I can see :) Even though > I'd love > > to see it happen. > > The routing table does need to be considered, but it still is IMO a > technical > > problem. Although it seems there is a shift in v4 policies away from > > aggregation in favour of conservation (no more reservations for contiguous > > address space, etc) > > > > > The way people work, usually only those who are unhappy take the burden > > > to figure out *where* to voice their unhappiness... > > > > Hmm, reminds me of the recent European elections ;) > > > > > So shall we abandon it? In favour of *what* to replace it? > > > > My proposal would be similar to the ARIN (I think) one: > > Any LIR in good standing is entitled to a /32 with justification for any > > follow-up allocation. > > > > Best regards, > > Sascha Luck > > Eirconnect > > > > > > >********************************** >Madrid 2003 Global IPv6 Summit >Presentations and videos on line at: >http://www.ipv6-es.com > >This electronic message contains information which may be privileged or >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aware >that any disclosure, copying, distribution or use of the contents of this >information, including attached files, is prohibited. > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004 German Valdez LACNIC Potos? 1517 Montevideo 11500 - Uruguay Tel: +598 2 606 2822 Fax: +598 2 601 5509 www.lacnic.net -------------- next part -------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004 From berni at birkenwald.de Mon Jun 21 22:12:39 2004 From: berni at birkenwald.de (Bernhard Schmidt) Date: Mon, 21 Jun 2004 22:12:39 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <0a5501c457c4$0c1955d0$8700000a@consulintel.es> References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> <08bf01c457ba$dd581f50$8700000a@consulintel.es> <20040621190445.GK6204@Space.Net> <0a5501c457c4$0c1955d0$8700000a@consulintel.es> Message-ID: <40D74137.1010707@birkenwald.de> JORDI PALET MARTINEZ wrote: Hi Jordi, > As I commented already in one of my previous emails, I will just give a /32 to every LIR/ISP (not end user) unless: > 1) He explicitly states "I'm not going to use it" > or > 2) He request something bigger and properly justify it. I totally agree. Why not make a rule like 'only one sTLA per LIR' and 'has to be announced by the LIR itself or its upstream ISP(s)' and give a /32 out to every LIR? - ISPs (as long as they are LIRs, that should be the most of them) could deploy IPv6 without having to lie about their plans for 200 customers. They would not be bound to an upstream more than they are in current IPv4 world. The "has to announce by itself" would stop some kiddies wet dreams of asking their (not IPv6 capable for years) LIR to get a /32 for them to play with. - Companies with LIR status could deploy IPv6 as well. By being LIR and paying LIR fees they sort of help the community out there (more LIRs - more income - perhaps lower RIPE fees for everyone). - Companies without LIR status either have to become LIR (see above) or have to use their upstream's address space with all known consequences. As soon as there is a scalable/usable approach of multi6 there might be some thinking in the companies about whether one could save the LIR fees and go with multi6. Bernhard From dr at cluenet.de Tue Jun 22 01:18:36 2004 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 22 Jun 2004 01:18:36 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406211100.36214.sascha@eirconnect.net>; from sascha@eirconnect.net on Mon, Jun 21, 2004 at 11:00:36AM +0100 References: <200406211100.36214.sascha@eirconnect.net> Message-ID: <20040622011836.A32652@homebase.cluenet.de> On Mon, Jun 21, 2004 at 11:00:36AM +0100, Sascha Luck wrote: > [this stance] is blatantly anti-competitive. The whole IPv6 world is currently anti-competitive. Power is shifted to the bigger players more than in the v4 world. Independence from suppliers is not granted to smaller shops anymore. A technical scaling problem is used as an excuse to the conveniently raise the bar (currently [amongst other constraints] using some arbitrary quantity [number of customers] to qualify - hrhr). Even if a technical solution comes out of the multi6 WG, I have some serious doubts that the "internet core" will implement/support it, as it is against their essential commercial interests. And I totally agree with Oliver Bartels and others who proclaim that IPv6 won't take off until the enterprise multihoming issue is solved. Looks like the cat is biting it's tail... Regards, Daniel (slightly disillusioned) From pekkas at netcore.fi Tue Jun 22 06:47:33 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 22 Jun 2004 07:47:33 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622011836.A32652@homebase.cluenet.de> Message-ID: On Tue, 22 Jun 2004, Daniel Roesen wrote: > Even if a technical solution comes out of the multi6 WG, I have some > serious doubts that the "internet core" will implement/support it, as > it is against their essential commercial interests. And I totally agree > with Oliver Bartels and others who proclaim that IPv6 won't take > off until the enterprise multihoming issue is solved. Looks like the > cat is biting it's tail... Which is why the solution will likely be such that it's transparent to the "internet core". -- 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 kurtis at kurtis.pp.se Tue Jun 22 07:44:23 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 07:44:23 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621173141.GH6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> Message-ID: <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gert, >>> *One* person is taking major offence at not being allowed to play >>> with >>> the big boys. >> >> Condescension will get us nowhere. Ok, we're a small ISP in a small >> market. >> Since we aim at the business/leased line market only, we may not have >> 200 >> customers, let alone 200 IPv6 allocations, within 2 years (I hope to >> be >> wrong, of course). >> Give me *one* good reason why we shouldn't be allowed to offer IPv6 >> connectivity? Give me a reason why we should lose *one*, otherwise >> happy, >> customer because of an arbitrary "line in the sand"? > > If you estimate that you will continue to be very small, you could use > a /40 or such from one of your upstream ISPs (which is a problem > *today*, > as there are not enough upstream ISPs, indeed). This doesn't fly. He can't set his own routing policy and he can't multihome. If he changes the single upstream his customers needs to renumber. > So shall we abandon it? Yes. > In favour of *what* to replace it? RIR membership. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNfHOqarNKXTPFCVEQKtOQCg1zOZF0IUfjui3Vdgzf2A/f4HWZIAn1gC 8JG8Zg7yMx6efCwdGb8OpZoy =PTYp -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Tue Jun 22 07:48:24 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 07:48:24 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621183736.GJ6204@Space.Net> References: <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <200406211904.28278.ripe-lst@eirconnect.net> <20040621183736.GJ6204@Space.Net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 20.37, Gert Doering wrote: > >>> If you are in good hope to reach more than 200 customers, you fulfill >>> the criteria (as has been mentioned before). >> >> Of course, I'm in good hope of reaching that goal. If that's good >> enough, fine >> but how do I document this hope? Will the NCC take my word for it? ;) > > They have to :-) - in the last 5 years, hardly anybody could be *sure* > to > have 200 IPv6 customers after two years - but unless you are sure that > you > won't reach that goal (due to your customer structure, whatever) the > underlying goal is "optimism and get IPv6 rolled out". Actually, what is a customer? Someone who pays for service? Or are we talking allocations made to non-infrastructure-or-owned-entities ? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNfIK6arNKXTPFCVEQKgLwCdERdqetnMSwZbv0fr0xXNrnHnYPIAoOQq imOnTuWrKexenj7R76bfm9H9 =zxqL -----END PGP SIGNATURE----- From gert at space.net Tue Jun 22 08:45:29 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 08:45:29 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> Message-ID: <20040622064529.GT6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 07:44:23AM +0200, Kurt Erik Lindqvist wrote: > > If you estimate that you will continue to be very small, you could use > > a /40 or such from one of your upstream ISPs (which is a problem > > *today*, > > as there are not enough upstream ISPs, indeed). > > This doesn't fly. He can't set his own routing policy and he can't > multihome. If he changes the single upstream his customers needs to > renumber. As of today, "more-specific BGP multihoming" works. So he *can* set his own routing policy. Admittedly, if changing the upstream, his customers would need to be renumbered (but this is not too different from IPv4 today with "very small ISPs that do not want to become LIR" - they use upstream space for a couple of years, and eventually become LIR and have to renumber). I can see that people don't like it, I'm just mentioning that it *could* be done. We will need to do something like that for the class "is ISP but is not LIR", even if we abandon the 200-users rule. > > So shall we abandon it? > Yes. > > > In favour of *what* to replace it? > RIR membership. I'm still waiting for someone to yell "WE MUST KEEP THIS RULE!!!"... :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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-lst at ripe.net Mon Jun 21 21:20:09 2004 From: ripe-lst at ripe.net (Sascha Luck) Date: Mon, 21 Jun 2004 20:20:09 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621190646.GL6204@Space.Net> References: <200406212000.57260.ripe-lst@eirconnect.net> <20040621190646.GL6204@Space.Net> Message-ID: <200406212020.09571.ripe-lst@ripe.net> On Monday 21 June 2004 20:06, Gert Doering wrote: Hi Gert, > OK. How exactly do you define "good standing"? This needs to be something > that a RIR hostmaster can base a decision on...? In UK/Ireland a "member in good standing" is defined as someone who "have all their fees paid and have no disciplinary action pending" ;) I *think* what ARIN meant was an established LIR > Personally, I like Oliver Bartels' proposal. :-) Yes, I would sign that, too. rgds, Sascha Luck -- DDO Eirconnect From ripe-lst at ripe.net Mon Jun 21 22:09:06 2004 From: ripe-lst at ripe.net (Sascha Luck) Date: Mon, 21 Jun 2004 21:09:06 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <002401c457c8$71136a30$828e8bd5@asgard> References: <200406211820.15292.ripe-lst@eirconnect.net> <002401c457c8$71136a30$828e8bd5@asgard> Message-ID: <200406212109.06554.ripe-lst@ripe.net> Hi Marcus, On Monday 21 June 2004 20:46, Marcus Gerdon wrote: > I had *no* trouble with the policy. > Currently (!) nobody asks for IPv6 directly, but those customers, > espicially bussiness customers, we offered routing ipv6 space to get them > accustomed to v6 were mostly quite happy with this service. And that > although they're informed it's still run in a test network (regarding our > infrastructure). We've actually been asked (with the understanding that it wasn't going to be a production rollout anytime soon. There is an actual drive towards ipv6 underway in Ireland - largely owing to heanet's efforts) > There's /16's spliit up to an endless number of /23,/24 ... Tkae a look at > Gert's email footer ... THAT's a problem. Not to say we're perfect - no > way. We ourselves have announced smaller prefixes out of space assigned to > other lir's each for many months only for customers UNWILLING to renumber > in appropriate time or to keep their old link long enough. Now this is hardly the fault of the allocation/assignment policies. If you are allocated a /16 and then announce it as /24s what can the RIR do about it? > So if you're going to deploy IPv6, just write a request. If it's serious > and understandable, I'd be surprised if a hostmaster reject it when you > count a /40 for your infrastructre or only get a sum of 180 /48. If the > plan itself is a thing to understand. The best laid plans of mice and men... As others here have pointed out, we can't yet say where the market is going with ipv6. Most plans we make today are likely to be rubbish tomorrow... > ehhmm... sorry Sascha .... not meant to be rude, just wondered ... > > A LIR without own network and ONE uplink / provider ? What services do you > provide ? Your RIPE data (as far as I found on-the-fly- look like a company > paying membership fee for their PI. Now, *that* i could consider rude ;) Where do you get the uplink from, we're not even announcing the route yet (still waiting for upstream #1 to connect their end) We're only just starting and suffered some delays. Look again towards the end of the year and things will look much different. > Before answering it: I'm not going to offend you ... but with this, you > *really* should take IPv6 from your upstream. For various reasons, this is not *really* an option. rgds, Sascha Luck -- DDO Eirconnect From he at nordu.net Mon Jun 21 17:00:58 2004 From: he at nordu.net (Havard Eidnes) Date: Mon, 21 Jun 2004 17:00:58 +0200 (CEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406171150.29481.jon@lawrence.org.uk> References: <200406171150.29481.jon@lawrence.org.uk> Message-ID: <20040621.170058.26554350.he@uninett.no> > I really fail to see the reason behind the 200 other organisation > rule - perhaps someone would like to explain the logic. I think the logic is that the RIRs are trying to portion out routing space so that we don't get a global routing table explosion in IPv6 in the same way we have (had) in IPv4. To acheive this, they need to make sure that the small ISPs don't get their own allocation, but instead go to their upstream provider for an IPv6 address space delegation. I can't really see another reason for this particular aspect of the policy. No, I don't think I agree with this policy, but I think I see what the RIRs are trying to conserve. I also have to agree with Pekka; "200 assignments to other organizations" can only be interpreted one way. Not that 199 or 200 would make all that much of a difference, so that's a minor point. Regards, - H?vard From david.kessens at nokia.com Tue Jun 22 01:14:48 2004 From: david.kessens at nokia.com (David Kessens) Date: Mon, 21 Jun 2004 16:14:48 -0700 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040614103640.491b4038.laura@ripe.net> References: <20040614103640.491b4038.laura@ripe.net> Message-ID: <20040621231448.GC22751@nokia.com> Laura, On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: > > During the following discussions, the RIPE NCC was asked to co-ordinate > work on clarifying the text. Please note that we do not intend to > propose any policy changes. During the meeting, I asked you not to waste your time on this. Since the policy is already changing in the other regions, our time would be better spend to move forwards, instead of stalling the policy development process by spending time on 'clarifications'. I would like to ask the working group whether we can ask the RIPE NCC to summarize the different changes made to the policy in the other regions, so that we can have a discussion on which changes are appropriate. Thanks, David Kessens --- From david at iprg.nokia.com Tue Jun 22 01:46:53 2004 From: david at iprg.nokia.com (David Kessens) Date: Mon, 21 Jun 2004 16:46:53 -0700 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" Message-ID: <20040621234653.GB23267@nokia.com> Laura, On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: > > During the following discussions, the RIPE NCC was asked to co-ordinate > work on clarifying the text. Please note that we do not intend to > propose any policy changes. During the meeting, I asked you not to waste your time on this. Since the policy is already changing in the other regions, our time would be better spend to move forwards, instead of stalling the policy development process by spending time on 'clarifications'. I would like to ask the working group whether we can ask the RIPE NCC to summarize the different changes made to the policy in the other regions, so that we can have a discussion on which changes are appropriate. Thanks, David Kessens --- From jordi.palet at consulintel.es Tue Jun 22 09:21:16 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 22 Jun 2004 09:21:16 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <20040621234653.GB23267@nokia.com> Message-ID: <034201c45829$8258d620$640a0a0a@consulintel.es> David, Fully agree and support your suggestion. Let's move on. Regards, Jordi ---- Original Message ---- From: "David Kessens" To: "Laura Cobley" Cc: Sent: Tuesday, June 22, 2004 1:46 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > Laura, > > On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: >> >> During the following discussions, the RIPE NCC was asked to co-ordinate >> work on clarifying the text. Please note that we do not intend to >> propose any policy changes. > > During the meeting, I asked you not to waste your time on this. Since > the policy is already changing in the other regions, our time would be > better spend to move forwards, instead of stalling the policy > development process by spending time on 'clarifications'. > > I would like to ask the working group whether we can ask the RIPE NCC > to summarize the different changes made to the policy in the other > regions, so that we can have a discussion on which changes are > appropriate. > > Thanks, > > David Kessens > --- ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From kurtis at kurtis.pp.se Tue Jun 22 09:36:42 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 09:36:42 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621234653.GB23267@nokia.com> References: <20040621234653.GB23267@nokia.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 01.46, David Kessens wrote: > I would like to ask the working group whether we can ask the RIPE NCC > to summarize the different changes made to the policy in the other > regions, so that we can have a discussion on which changes are > appropriate. Agreed. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNfhjqarNKXTPFCVEQK4zQCfX4tquEy91XXIOc7afQHf3Zs9X7IAoJBf caUU3cjnVUNnbEXhg7yCh/Lo =/ilX -----END PGP SIGNATURE----- From gert at space.net Tue Jun 22 09:45:17 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 09:45:17 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621231448.GC22751@nokia.com> References: <20040614103640.491b4038.laura@ripe.net> <20040621231448.GC22751@nokia.com> Message-ID: <20040622074517.GW6204@Space.Net> Hi, On Mon, Jun 21, 2004 at 04:14:48PM -0700, David Kessens wrote: > I would like to ask the working group whether we can ask the RIPE NCC > to summarize the different changes made to the policy in the other > regions, so that we can have a discussion on which changes are > appropriate. Sounds like a useful plan. >From what I hear, things are moving in the same direction anyway ("drop 200-users rule, clarify some of the other issues"), and this may help to make better informed decisions. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Tue Jun 22 09:54:59 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 22 Jun 2004 09:54:59 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621.170058.26554350.he@uninett.no> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> Message-ID: <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> On 21 Jun, 2004, at 17:00, Havard Eidnes wrote: >> I really fail to see the reason behind the 200 other organisation >> rule - perhaps someone would like to explain the logic. > > I think the logic is that the RIRs are trying to portion out routing > space so that we don't get a global routing table explosion in IPv6 in > the same way we have (had) in IPv4. To acheive this, they need to make > sure that the small ISPs don't get their own allocation, If this is true, it is really disturbing given that the RIPE NCC was rather proactive some years ago when the whole TLA/NLA/SLA structure was conceived with the main objective of allowing only up to 8192 players in the global routing table. Eventually everyone got to see the point of view championed by DFK that it would be undue regulation of the industry. Now, like then, the arguments in favour of imposing this limitation where all to do with the current technical difficulties with coping with a huge routing table. Also disturbing is that, while there are groups working on proposing new solutions to the multihoming problem, the policy seems to reflect a conviction that they will fail and therefore there need to be constraints imposed at a table size of a few hundred entries. I would like to suggest that if the multihoming proposals fail, then the policy becomes irrelevant because so does IPv6. Therefore the policy ought to be as relaxed as possible to not preclude any possible growth at this stage. > but instead go > to their upstream provider for an IPv6 address space delegation. I > can't really see another reason for this particular aspect of the > policy. > Joao From gert at space.net Tue Jun 22 09:59:05 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 09:59:05 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> Message-ID: <20040622075905.GX6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 09:54:59AM +0200, Joao Damas wrote: > On 21 Jun, 2004, at 17:00, Havard Eidnes wrote: > > >>I really fail to see the reason behind the 200 other organisation > >>rule - perhaps someone would like to explain the logic. > > > >I think the logic is that the RIRs are trying to portion out routing > >space so that we don't get a global routing table explosion in IPv6 in > >the same way we have (had) in IPv4. To acheive this, they need to make > >sure that the small ISPs don't get their own allocation, > > If this is true, it is really disturbing given that the RIPE NCC was [..] The "200 user" criteria came from the ARIN and APNIC communities, not from the RIRs. [..] > Also disturbing is that, while there are groups working on proposing > new solutions to the multihoming problem, the policy seems to reflect a > conviction that they will fail and therefore there need to be > constraints imposed at a table size of a few hundred entries. I can't see the connection. The whole point of the multi6 group is to find multihoming solutions that do *not* need a global routing table slot. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Mohsen.Souissi at nic.fr Tue Jun 22 10:45:25 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Tue, 22 Jun 2004 10:45:25 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621234653.GB23267@nokia.com> References: <20040621234653.GB23267@nokia.com> Message-ID: <20040622084525.GA96141@kerkenna.nic.fr> David & all, On 21 Jun, David Kessens wrote: | | Laura, | | On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: | > | > During the following discussions, the RIPE NCC was asked to co-ordinate | > work on clarifying the text. Please note that we do not intend to | > propose any policy changes. | | During the meeting, I asked you not to waste your time on this. Since | the policy is already changing in the other regions, our time would be | better spend to move forwards, instead of stalling the policy | development process by spending time on 'clarifications'. | | I would like to ask the working group whether we can ask the RIPE NCC | to summarize the different changes made to the policy in the other | regions, so that we can have a discussion on which changes are | appropriate. ==> If it is deemed that it would be worth proceeding now to the Policy change (instead of simply clarifing it as it was initially intended), let me please draw your attention to the following web page at APNIC site, which compares RIR implementations of the global IPv6 Policy and which may be useful as a start: http://www.apnic.net/docs/policy/rir-comparison.html By the way, you can have a look at section 3.4.1 ("Critical Infrastructure") which describes, AFAIK, somtehing which is implemented only in APNIC region and which would be useful for ccTLDs in Europe (for instance, .de and .fr to name a few of them). Regards, Mohsen. From hosaka at nic.ad.jp Tue Jun 22 11:02:57 2004 From: hosaka at nic.ad.jp (Toshiyuki Hosaka) Date: Tue, 22 Jun 2004 18:02:57 +0900 (JST) Subject: Fw: [GLOBAL-V6] [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" (fwd) Message-ID: <20040622.180257.09104302.hosaka@nic.ad.jp> Dear all, Please allow me to forward global-ipv6 ML post by Kosuke Ito, who has not subscribed ripe-policy-wg ML. Also I would suggest you can ask original IPv6 policy intention to v6-edit team(v6-edit at ripe.net) that knows it very well, if you still need that. best regards, Toshi -- Toshiyuki Hosaka IP Department, Japan Network Information Center (JPNIC) tel: +81-(0)3-5297-2311 fax: +81-(0)3-5297-2312 -------------- next part -------------- An embedded message was scrubbed... From: Kosuke Ito Subject: Re: [GLOBAL-V6] [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" (fwd) Date: no date Size: 10061 URL: From jordi.palet at consulintel.es Tue Jun 22 11:04:50 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 22 Jun 2004 11:04:50 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <20040621234653.GB23267@nokia.com> <20040622084525.GA96141@kerkenna.nic.fr> Message-ID: <066001c45837$fa02a760$640a0a0a@consulintel.es> Hi Mohsen, http://www.apnic.net/docs/policy/rir-comparison.html Looking at the LACNIC site, I believe this is not updated. I think same for ARIN. Regarding the critical infrastructure, I fully support a policy change on this in RIPE. Regards, Jordi ----- Original Message ----- From: "Mohsen Souissi" To: "David Kessens" Cc: "Laura Cobley" ; Sent: Tuesday, June 22, 2004 10:45 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > David & all, > > On 21 Jun, David Kessens wrote: > | > | Laura, > | > | On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: > | > > | > During the following discussions, the RIPE NCC was asked to co-ordinate > | > work on clarifying the text. Please note that we do not intend to > | > propose any policy changes. > | > | During the meeting, I asked you not to waste your time on this. Since > | the policy is already changing in the other regions, our time would be > | better spend to move forwards, instead of stalling the policy > | development process by spending time on 'clarifications'. > | > | I would like to ask the working group whether we can ask the RIPE NCC > | to summarize the different changes made to the policy in the other > | regions, so that we can have a discussion on which changes are > | appropriate. > > ==> If it is deemed that it would be worth proceeding now to the > Policy change (instead of simply clarifing it as it was initially > intended), let me please draw your attention to the following web page > at APNIC site, which compares RIR implementations of the global IPv6 > Policy and which may be useful as a start: > > http://www.apnic.net/docs/policy/rir-comparison.html > > By the way, you can have a look at section 3.4.1 ("Critical > Infrastructure") which describes, AFAIK, somtehing which is > implemented only in APNIC region and which would be useful for ccTLDs > in Europe (for instance, .de and .fr to name a few of them). > > Regards, > > Mohsen. > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Michael.Dillon at radianz.com Tue Jun 22 11:06:41 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 22 Jun 2004 10:06:41 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406211820.15292.ripe-lst@eirconnect.net> Message-ID: > Besides, there is no benefit to this rule as far as I can see. IPv6 space is > not a scarce resource. IPv4 is, yet is is easy enough to get. It should not be any more difficult to get an IPv6 allocation than it is to get an IPv4 allocation. Therefore, any ISP/LIR who already has an IPv4 allocation should be able to get their first IPv6 /32 simply by asking for it. In fact, you could argue that the RIRs should just allocate an IPv6 block to every ISP/LIR right now and send them out in the next email. --Michael Dillon From gert at space.net Tue Jun 22 11:13:00 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 11:13:00 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622084525.GA96141@kerkenna.nic.fr> References: <20040621234653.GB23267@nokia.com> <20040622084525.GA96141@kerkenna.nic.fr> Message-ID: <20040622091300.GZ6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 10:45:25AM +0200, Mohsen Souissi wrote: > By the way, you can have a look at section 3.4.1 ("Critical > Infrastructure") which describes, AFAIK, somtehing which is > implemented only in APNIC region and which would be useful for ccTLDs Please let's not reopen the generic "critical infrastructure" discussion now. It has come up a couple of times, and every time there was consensus that we don't want that in the RIPE region. If you have a *more specific* proposal, you're welcome, of course. > in Europe (for instance, .de and .fr to name a few of them). DENIC seems to be fairly happy with the IPv6 /48 they currently use. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Tue Jun 22 11:17:15 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Tue, 22 Jun 2004 11:17:15 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622075905.GX6204@Space.Net> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> Message-ID: On 22 Jun, 2004, at 9:59, Gert Doering wrote: > [..] >> Also disturbing is that, while there are groups working on proposing >> new solutions to the multihoming problem, the policy seems to reflect >> a >> conviction that they will fail and therefore there need to be >> constraints imposed at a table size of a few hundred entries. > > I can't see the connection. The whole point of the multi6 group is > to find multihoming solutions that do *not* need a global routing table > slot. What the solution is does not matter as long as it is workable. The point I raised has nothing to do with how multi6 intends to achieve it's goals, rather with the fact that the current attitude towards policy making for IPv6 seems to have the underlying assumption that there is a need to drastically reduce the number of organisations that can get allocations to reduce the number of entries in the routing table. This happens at the same time that there is a group working on solutions so it shows little faith in the outcome of the work. I am arguing for a change in mentality that, while keeping memory of the good lessons learned in IPv4 (eg. allocation size related to network size, via variable sized prefixes) does not keep newcomers from deploying IPv6 (eg. a LIR -> an allocation or variations) Joao From Michael.Dillon at radianz.com Tue Jun 22 11:15:49 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 22 Jun 2004 10:15:49 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406212020.09571.ripe-lst@ripe.net> Message-ID: > In UK/Ireland a "member in good standing" is defined as someone who "have all > their fees paid and have no disciplinary action pending" ;) I *think* what > ARIN meant was an established LIR In the ARIN region we have LIRs who received their allocation from SRI-NIC or the Internic in the distant past. These LIRs pay no fees to ARIN and may not even maintain their contact data. The reason I suggested that we only issue IPv6 to LIRs in good standing was to give these LIRs a reason to join ARIN. It's not just about the money. It's about getting everyone in the industry to work together to maintain fair adressing policies. --Michael Dillon From chbm at cprm.net Tue Jun 22 12:08:09 2004 From: chbm at cprm.net (Carlos Morgado) Date: Tue, 22 Jun 2004 11:08:09 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622064529.GT6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> Message-ID: <20040622100809.GA2019@cprm.net> On Tue, Jun 22, 2004 at 08:45:29AM +0200, Gert Doering wrote: > Hi, > > On Tue, Jun 22, 2004 at 07:44:23AM +0200, Kurt Erik Lindqvist wrote: > > > If you estimate that you will continue to be very small, you could use > > > a /40 or such from one of your upstream ISPs (which is a problem > > > *today*, > > > as there are not enough upstream ISPs, indeed). > > > > This doesn't fly. He can't set his own routing policy and he can't > > multihome. If he changes the single upstream his customers needs to > > renumber. > > As of today, "more-specific BGP multihoming" works. So he *can* set > his own routing policy. > Can you personaly garantee the upstream suplying the space won't aggregate his prefix ? If you can't this just turned a nice IPv6 space rental setup. -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From gert at space.net Tue Jun 22 12:29:06 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 12:29:06 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622100809.GA2019@cprm.net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622100809.GA2019@cprm.net> Message-ID: <20040622102906.GE6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 11:08:09AM +0100, Carlos Morgado wrote: > > > This doesn't fly. He can't set his own routing policy and he can't > > > multihome. If he changes the single upstream his customers needs to > > > renumber. > > As of today, "more-specific BGP multihoming" works. So he *can* set > > his own routing policy. > > Can you personaly garantee the upstream suplying the space won't aggregate > his prefix ? And if he does, so what? He will loose traffic, as the *other* ISP will make the more specific visible world-wide, and thus no paid-for packets will arrive at the aggregating upstream. Using a more-specific block out of PA space is a well-established technique in IPv4 today. It's not "beautiful", but it works better than other variants. > If you can't this just turned a nice IPv6 space rental setup. Huh? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From chbm at cprm.net Tue Jun 22 12:58:15 2004 From: chbm at cprm.net (Carlos Morgado) Date: Tue, 22 Jun 2004 11:58:15 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622102906.GE6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622100809.GA2019@cprm.net> <20040622102906.GE6204@Space.Net> Message-ID: <20040622105815.GB2019@cprm.net> On Tue, Jun 22, 2004 at 12:29:06PM +0200, Gert Doering wrote: > > > If you can't this just turned a nice IPv6 space rental setup. > > Huh? > We'll see upstreams that don't actually sell good connectivity but just rent space disguised as bad cheap connectivity. -- Carlos Morgado - Internet Engineering GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From gert at space.net Tue Jun 22 13:03:26 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 13:03:26 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622105815.GB2019@cprm.net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622100809.GA2019@cprm.net> <20040622102906.GE6204@Space.Net> <20040622105815.GB2019@cprm.net> Message-ID: <20040622110326.GH6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 11:58:15AM +0100, Carlos Morgado wrote: > On Tue, Jun 22, 2004 at 12:29:06PM +0200, Gert Doering wrote: > > > If you can't this just turned a nice IPv6 space rental setup. > > Huh? > We'll see upstreams that don't actually sell good connectivity but just rent > space disguised as bad cheap connectivity. So what can we do about it? Just dropping the 200-customers rules won't change the fact that some people will always want address space with the community saying "*you* can't get an allocation from your RIR". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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-lst at eirconnect.net Tue Jun 22 13:23:50 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Tue, 22 Jun 2004 12:23:50 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622064529.GT6204@Space.Net> References: <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> Message-ID: <200406221223.50604.ripe-lst@eirconnect.net> Hi Gert, all, On Tuesday 22 June 2004 07:45, Gert Doering wrote: > As of today, "more-specific BGP multihoming" works. So he *can* set > his own routing policy. It's certainly a work-around if all else fails. I'm not sure it should be *encouraged* though, since announcing more-specific routes flies in the face of aggregation. Besides, don't most people filter on allocation boundaries? rgds, Sascha Luck -- DDO Eirconnect From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 13:30:34 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 20:30:34 +0900 Subject: [address-policy-wg] Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> Message-ID: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>If you estimate that you will continue to be very small, you could use >>a /40 or such from one of your upstream ISPs (which is a problem >>*today*, >>as there are not enough upstream ISPs, indeed). > This doesn't fly. He can't set his own routing policy and he can't > multihome. Kurt, as I made presentation in front of you and Brian Carpenter at multi6 WG meeting of IETF58 in Minneapolis on Nov. 2003, it is possible for a small ISP delegated address blocks from multiple larger ISPs and can still have its own policy. Since then, you made no counter argument against my presentation that it is your fallacy to say things against the presentation. For those of you who are not familiar with my (expired) draft used at the meeting, it is available at: http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt The interim conclusion of the draft is: Thus, it is not essential that ISPs have their own TLAs. > If he changes the single upstream his customers needs to > renumber. If one changes homing, one needs to renumber, of course. But, it has nothing to do with multihoming or hierarchical ISPs. Just as we shouldn't discourage customers change ISPs, we shouldn't discourage ISPs change upper level ISPs. >>So shall we abandon it? > Yes. No. >> In favour of *what* to replace it? > RIR membership. No. It is proven not to scale. Does it mean that it is beneficial for you if RIRs have more power even though it sacrifices ISPs and users of the Internet by requiring routers with a lot more routing table entries than necessary? Masataka Ohta From ripe-lst at eirconnect.net Tue Jun 22 13:28:18 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Tue, 22 Jun 2004 12:28:18 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <20040622110716.GI6204@Space.Net> Message-ID: <200406221228.18365.ripe-lst@eirconnect.net> Hi Carlos, all, On Tuesday 22 June 2004 12:16, Carlos Friacas wrote: > I cant really support the idea RIPE/NCC is a monopoly. It works in an > open and well-known fashion, cooperating with the community it > serves... > The real danger to internet governance is ICANN, and having Internet > Addressing and other stuff decisions depend on a US Government Department. I would also not much fancy if Internet governance/IP allocation policy/etc fell into the hands of the likes of the European Commission or such... rgds, Sascha Luck -- DDO Eirconnect From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 13:42:47 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 20:42:47 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> Message-ID: <40D81B37.30106@necom830.hpcl.titech.ac.jp> Joao Damas; > The point I raised has nothing to do with how multi6 intends to achieve > it's goals, rather with the fact that the current attitude towards > policy making for IPv6 seems to have the underlying assumption that > there is a need to drastically reduce the number of organisations that > can get allocations to reduce the number of entries in the routing > table. This happens at the same time that there is a group working on > solutions so it shows little faith in the outcome of the work. In multi6 WG, there certainly is a proposal to reduce the number of TLAs. > I am arguing for a change in mentality that, while keeping memory of the > good lessons learned in IPv4 (eg. allocation size related to network > size, via variable sized prefixes) does not keep newcomers from > deploying IPv6 (eg. a LIR -> an allocation or variations) Then, accept the fact that we can't have so much TLAs. A simple way to do so is to allow TLAs only to national IRs. There are other ways, too. Masataka Ohta From kurtis at kurtis.pp.se Tue Jun 22 13:39:30 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 13:39:30 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622075905.GX6204@Space.Net> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 09.59, Gert Doering wrote: > I can't see the connection. The whole point of the multi6 group is > to find multihoming solutions that do *not* need a global routing table > slot. Well, they will need a global routing table slot, but preferably not more than one :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgadaarNKXTPFCVEQKDlQCg45zioLuVEJ23LaLFbEuWh/2WeRQAoKQF 7W5N2tArVmQpzd9GIemhUZU7 =q+GO -----END PGP SIGNATURE----- From gert at space.net Tue Jun 22 13:43:26 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 13:43:26 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406221223.50604.ripe-lst@eirconnect.net> References: <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <200406221223.50604.ripe-lst@eirconnect.net> Message-ID: <20040622114326.GJ6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 12:23:50PM +0100, Sascha Luck wrote: > On Tuesday 22 June 2004 07:45, Gert Doering wrote: > > As of today, "more-specific BGP multihoming" works. So he *can* set > > his own routing policy. > > It's certainly a work-around if all else fails. I'm not sure it should be > *encouraged* though, since announcing more-specific routes flies in the face > of aggregation. Having more-specifics for multihomed (and only those!) customers doesn't mean the rest of the block must be deaggregated. The impact on the routing table is, at worst, the same as in "you get your own prefix and announce that world-wide". At best, the customer might eventually cease to be multihomed, and the more-specific goes away. > Besides don't most people filter on allocation boundaries? Most people don't filter at all. Of those that do, some filter on allocations, and some permit up to /48s. Which doesn't break anything in that model - the aggregate is there, so packets travel in the right direction. "Near to the network in question", chances are high that more-specifics *are* visible, and thus the packets can reach their destination. Nobody can *guarantee* anything anyway. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 22 13:44:52 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 13:44:52 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> Message-ID: <92E8AEA1-C441-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 11.17, Joao Damas wrote: >> I can't see the connection. The whole point of the multi6 group is >> to find multihoming solutions that do *not* need a global routing >> table >> slot. > > What the solution is does not matter as long as it is workable. > > The point I raised has nothing to do with how multi6 intends to > achieve it's goals, rather with the fact that the current attitude > towards policy making for IPv6 seems to have the underlying assumption > that there is a need to drastically reduce the number of organisations > that can get allocations to reduce the number of entries in the > routing table. This happens at the same time that there is a group > working on solutions so it shows little faith in the outcome of the > work. Well, there is also a time scale factor. If multi6 concluded today, someone still needs to do the protocol work, which is at least two years. Add to that implementation. 10 years might be optimistic. Then again we haven't gotten 500 routes in the past 10 years. And even if all LIRs got a prefix that would still only be some 20k prefixes at best. But you are right, that there is a roll-out plan missing. At some point we need to decide who's job it is to come up with the implementation strategy and a policy for what to do in the mean time. I would like to say that multi6 has moved far enough that it's time to start discussing this. But I think I will save that for after the San Diego IETF meeting. I think also the multi6 WG chairs needs to talk with the ADs of how to proceed with this issue... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgbt6arNKXTPFCVEQLCewCeMsJ6fQuijsW2UW++/PHBXxs74VkAoOXf DZby4qMAQ3rYOlDUo0Irxteq =UDUs -----END PGP SIGNATURE----- From gert at space.net Tue Jun 22 13:49:12 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 13:49:12 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Message-ID: <20040622114911.GK6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 08:30:34PM +0900, Masataka Ohta wrote: > >> In favour of *what* to replace it? > > RIR membership. > No. It is proven not to scale. "Proven"? When, where, by whom, based on what data? There are less than 10.000 LIRs in existance today, all RIRs combined. So that would be a maximum of 10.000 routing table entries (if we can manage to keep it at "1 prefix per LIR"). > Does it mean that it is beneficial for you if RIRs have more > power even though it sacrifices ISPs and users of the Internet > by requiring routers with a lot more routing table entries > than necessary? 10.000 routing table entries is something far below the near 140.000 we have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 routes, it *does* scale up to fairly insane numbers. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 22 13:49:18 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 13:49:18 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622102906.GE6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622100809.GA2019@cprm.net> <20040622102906.GE6204@Space.Net> Message-ID: <314D5C8A-C442-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 12.29, Gert Doering wrote: > On Tue, Jun 22, 2004 at 11:08:09AM +0100, Carlos Morgado wrote: >>>> This doesn't fly. He can't set his own routing policy and he can't >>>> multihome. If he changes the single upstream his customers needs to >>>> renumber. >>> As of today, "more-specific BGP multihoming" works. So he *can* set >>> his own routing policy. >> >> Can you personaly garantee the upstream suplying the space won't >> aggregate >> his prefix ? > > And if he does, so what? He will loose traffic, as the *other* ISP > will make the more specific visible world-wide, and thus no paid-for > packets will arrive at the aggregating upstream. > > Using a more-specific block out of PA space is a well-established > technique in IPv4 today. It's not "beautiful", but it works better > than other variants. Well, in todays IPv4 world people are also taking PA blocks and advertise them as individual /24s, just to implement policy. I am not sure that is so much better than just giving the LIRs a /32. Those who are to small to become LIRs? Though luck. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgcxKarNKXTPFCVEQKErwCdEMKuZqc8p28+Balrh6FLurHR6boAn2SQ MYTctDKhAqzgdRCIcn4XhOyX =y9Kr -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Tue Jun 22 13:52:35 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 13:52:35 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D81B37.30106@necom830.hpcl.titech.ac.jp> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 13.42, Masataka Ohta wrote: > A simple way to do so is to allow TLAs only to national IRs. What is a "national IR"? National Internet Registry? What about corporations that fall outside the nation boundary? Who controls the national IRs? What are the rules they operate by? What do we gain with this over RIRs? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgdh6arNKXTPFCVEQJrVwCg5+d4ijks9Nx57KwrOinD+pRGWvwAoNEs h9Ypi+U12+ZIoFfb6a/6ZUjU =dEIB -----END PGP SIGNATURE----- From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 14:01:59 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 21:01:59 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <92E8AEA1-C441-11D8-860C-000A95928574@kurtis.pp.se> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <92E8AEA1-C441-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <40D81FB7.4070003@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist wrote: > Well, there is also a time scale factor. If multi6 concluded today, > someone still needs to do the protocol work, which is at least two > years. Add to that implementation. 10 years might be optimistic. Just for your (other than Kurt) information, there is running code of a multi6 proposal which does not bloat global routing table size, which has been running even before the multi6 WG was formed. The only problem for the deployment of the proposal is that IPv6 is not deployed. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 14:09:40 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 21:09:40 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> Message-ID: <40D82184.30909@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>A simple way to do so is to allow TLAs only to national IRs. Can you beahve fair to quote properly. I wrote: >>A simple way to do so is to allow TLAs only to national IRs. >> >>There are other ways, too. > What is a "national IR"? National Internet Registry? What about > corporations that fall outside the nation boundary? Who controls the > national IRs? What are the rules they operate by? What do we gain with > this over RIRs? For example, in my draft you actively ignored, I wrote: For example, some TLA may be supplied from RIRs with bidding. Some TLA may be allocated to each country (proportional to the population of the country) and delivered with the countrie's policy. As you have chances to ask questions, you are supposed to understand the meanings of the examples of the draft. Or, you can say that you have never been interested in mult6 issues. Masataka Ohta From oliver at bartels.de Tue Jun 22 14:10:02 2004 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 22 Jun 2004 14:10:02 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040622114911.GK6204@Space.Net> Message-ID: <200406221209.i5MC9Htt009455@alpha.bartels.de> On Tue, 22 Jun 2004 13:49:12 +0200, Gert Doering wrote: >"Proven"? When, where, by whom, based on what data? > >There are less than 10.000 LIRs in existance today, all RIRs combined. > >So that would be a maximum of 10.000 routing table entries (if we >can manage to keep it at "1 prefix per LIR"). Full Ack. A table of this size is handled with a one cycle memory access in modern routing hardware. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 14:18:05 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 21:18:05 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040622114911.GK6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> Message-ID: <40D8237D.5020301@necom830.hpcl.titech.ac.jp> Gert Doering wrote: >>>>In favour of *what* to replace it? >>> >>>RIR membership. >> >>No. It is proven not to scale. > "Proven"? When, where, by whom, based on what data? > > There are less than 10.000 LIRs in existance today, all RIRs combined. According to my upper bound, it's already unnecessarily too large. > 10.000 routing table entries is something far below the near 140.000 we > have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 > routes, it *does* scale up to fairly insane numbers. Of course, you can have as many routing table entries as you want, as long as backbone routers, speed of which degrade as their routing table bloat, have large enough routing table. However, routing table does cost. High speed memory for backbone routers costs a lot. The cost must be paid by ISPs and, then, by users. If the size of global routing table is limited by a hard upper bound, it simplifies the design of routers a lot (you can put a backbone router (or many of them) with a global routing table in a chip), reduces cost of routers a lot and increases speed of routers a lot. Note that, for scalable (thus, end to end) site multihoming properly work, all the sites are required to circulate global routing table within the sites. Masataka Ohta From kurtis at kurtis.pp.se Tue Jun 22 14:15:52 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 14:15:52 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following is explicitly not written as co-chair of the IETF multi6 WG. > Kurt, as I made presentation in front of you and Brian > Carpenter at multi6 WG meeting of IETF58 in Minneapolis I think I have seen close to 40 presentations that all would solve the multihoming problem one way or the other, or at least parts of it. > on Nov. 2003, it is possible for a small ISP delegated > address blocks from multiple larger ISPs and can still > have its own policy. It's possible for a small ISP to get several blocks from their upstream, route them inside their network and assign each of their customers with an address out of each of those blocks. Does it scale? Nope. Can it handle failures in the upstream? No. Etc. > Since then, you made no counter argument against my > presentation that it is your fallacy to say things > against the presentation. There are several of the proposals in multi6 that have never received comments, nor support of any kind. > For those of you who are not familiar with my (expired) draft > used at the meeting, it is available at: > > http://www.watersprings.org/pub/id/draft-ohta-multihomed-isps-00.txt > > The interim conclusion of the draft is: > > Thus, it is not essential that ISPs have their own TLAs. Your document does not address the criterias for being classified in a particular category. It does not address what would happen if an ISP grow, get's split/divided. It does not address what the financial models for transit would be. It does not address the non-balance of local vs global traffic coverage. It does not take into account the current peering economics of the Internet. So it's really hard to say anything regarding it. >> If he changes the single upstream his customers needs to >> renumber. > > If one changes homing, one needs to renumber, of course. Which is a limiting factor that I think you will that customers will find unacceptable. > But, it has nothing to do with multihoming or hierarchical > ISPs. > > Just as we shouldn't discourage customers change ISPs, we shouldn't > discourage ISPs change upper level ISPs. Having to renumber when chaining ISPs is not to discourage _change_ of ISP. It's to discourage signing up with that ISP in the first place. >>> In favour of *what* to replace it? > >> RIR membership. > > No. It is proven not to scale. In what way? > Does it mean that it is beneficial for you if RIRs have more > power even though it sacrifices ISPs and users of the Internet > by requiring routers with a lot more routing table entries > than necessary? I am not following this. In what way would the RIRs get more "power"? The policies of the RIRs is set by the RIR community. We are having a lot more routing entries today than we need to, and people seems to think it is a good idea. Actually it is today used to implement policies that follow requirements set by users to their ISPs. Users that pay to get that policy. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgi/aarNKXTPFCVEQIAcQCfYowvBqwQ8MRQusq68q1OBTkKdwkAoPTb zVVRNw/ZJa4p6sGXKMM20RRC =DMSt -----END PGP SIGNATURE----- From nils at druecke.strg-alt-entf.org Tue Jun 22 14:16:40 2004 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Tue, 22 Jun 2004 08:16:40 -0400 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622064529.GT6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> Message-ID: <20040622121640.GB18423@bug> On Tue, Jun 22, 2004 at 08:45:29AM +0200, Gert Doering wrote: > > This doesn't fly. He can't set his own routing policy and he can't > > multihome. If he changes the single upstream his customers needs to > > renumber. > As of today, "more-specific BGP multihoming" works. So he *can* set > his own routing policy. Maybe I have lost you somewhere now: You only get an assignement when you are a big one (>200 customers). That is to keep the routing table smaller. Because that does not work for small ISPs (see above) they announce a route for a smaller network (that was assigned to him from his upstream provider). So we have one /32 route less, one /40 route more or something like that. Doesn't seem to save much space in the routing table? > Admittedly, if changing the upstream, his customers would need to be > renumbered (but this is not too different from IPv4 today with > "very small ISPs that do not want to become LIR" - they use upstream > space for a couple of years, and eventually become LIR and have to > renumber). It is an absolute pain in the ass. And it will be in the future. Yes, the mechanisms to make it easy are in place, but they are not implemented. Renumbering is NOT EASY. It costs a hell lot of money, each time it has to be done. > I can see that people don't like it, I'm just mentioning that it *could* > be done. We will need to do something like that for the class "is ISP > but is not LIR", even if we abandon the 200-users rule. I would change that to "is mutlihomed but is not LIR". Even without being an ISP you can easily run into the same problems. And I do not want to be in charge at Siemens, GM, Nortel, Cisco or so for renumbering projects. With using globally unique addresses in the organization (and being able to do that is one of the advantages of IPv6 - using site local and NAT does not make sense, I can stay at v4 then) makes it even worse. Now renumbering of official Adresses "only" means changing everything about external communication. Nils From kurtis at kurtis.pp.se Tue Jun 22 14:20:03 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 14:20:03 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D82184.30909@necom830.hpcl.titech.ac.jp> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> Message-ID: <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> A simple way to do so is to allow TLAs only to national IRs. >>> >>> There are other ways, too. > >> What is a "national IR"? National Internet Registry? What about >> corporations that fall outside the nation boundary? Who controls the >> national IRs? What are the rules they operate by? What do we gain with >> this over RIRs? > > For example, in my draft you actively ignored, I wrote: > > For example, some TLA may be supplied from RIRs with bidding. > > Some TLA may be allocated to each country (proportional to the > population of the country) and delivered with the countrie's policy. I was asking trying to clarify what you meant by "national IR" and under what policies these would operate. Which is a fairly substantive question. > As you have chances to ask questions, Which is exactly what I am doing. But I think the chairs will ask us to take this elsewhere soon, as this is pretty far off topic. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgj96arNKXTPFCVEQLORQCg1SG5EaX1Xh3R3LExIANRud1/7uwAoPKv CJ8Ei3j6Ujf7FFouwuBJiq3H =jE/f -----END PGP SIGNATURE----- From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 14:26:30 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 21:26:30 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <200406221209.i5MC9Htt009455@alpha.bartels.de> References: <200406221209.i5MC9Htt009455@alpha.bartels.de> Message-ID: <40D82576.8040501@necom830.hpcl.titech.ac.jp> Oliver Bartels: >>So that would be a maximum of 10.000 routing table entries (if we >>can manage to keep it at "1 prefix per LIR"). > > Full Ack. > > A table of this size is handled with a one cycle memory access > in modern routing hardware. By definition of "one cycle memory access", any table of any size can be handled with a one cycle memory access in any routing hardware. However, memory access cycle can be a lot larger than a CPU clock cycle. On typical modern chips, tens of registers can be accessed within a CPU cycle. On chip primary cache with thousands of entries needs about twice or three times more than that. Off chip cache needs about ten, twenty or, maybe, hundred more to access. Masataka Ohta From ncc at ripe.net Tue Jun 22 14:21:55 2004 From: ncc at ripe.net (Paul Rendek) Date: Tue, 22 Jun 2004 14:21:55 +0200 Subject: [address-policy-wg] ASO AC - Call for Nominations 2004 - RIPE NCC Service Region Message-ID: <40D82463.4000805@ripe.net> Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC From gert at space.net Tue Jun 22 14:26:40 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 14:26:40 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622121640.GB18423@bug> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622121640.GB18423@bug> Message-ID: <20040622122640.GS6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 08:16:40AM -0400, Nils Ketelsen wrote: > On Tue, Jun 22, 2004 at 08:45:29AM +0200, Gert Doering wrote: > > > > This doesn't fly. He can't set his own routing policy and he can't > > > multihome. If he changes the single upstream his customers needs to > > > renumber. > > As of today, "more-specific BGP multihoming" works. So he *can* set > > his own routing policy. > > Maybe I have lost you somewhere now: You only get an assignement when you > are a big one (>200 customers). Yes. > That is to keep the routing table smaller. "Because the community wanted to have it this way". > Because that does not work for small ISPs (see above) they announce a route > for a smaller network (that was assigned to him from his upstream provider). > > So we have one /32 route less, one /40 route more or something like that. > Doesn't seem to save much space in the routing table? Not that much. One could apply more-specific filters to routes coming from other regions, so it *would* save something. Or the customer might eventually decide to cease to multihome, and the more-specific gets folded back into the aggregate - and this *does* happen, two of our customers did this in the past couple of years, and we're not one of the "really big" ISPs. [..] > > Admittedly, if changing the upstream, his customers would need to be > > renumbered (but this is not too different from IPv4 today with > > "very small ISPs that do not want to become LIR" - they use upstream > > space for a couple of years, and eventually become LIR and have to > > renumber). > > It is an absolute pain in the ass. And it will be in the future. Yes, the > mechanisms to make it easy are in place, but they are not implemented. > Renumbering is NOT EASY. It costs a hell lot of money, each time it has to > be done. Announcing your routes to the whole world also costs "a hell of a lot of money". Not your money, of course, but everyone elses. So pain needs to be balanced. > > I can see that people don't like it, I'm just mentioning that it *could* > > be done. We will need to do something like that for the class "is ISP > > but is not LIR", even if we abandon the 200-users rule. > > I would change that to "is mutlihomed but is not LIR". Even without being an > ISP you can easily run into the same problems. And I do not want to be in > charge at Siemens, GM, Nortel, Cisco or so for renumbering projects. So what is your propsal for a new policy, then? "Everybody who is special gets their own allocation?" Which makes it very simple, as long as you can define "special". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 14:32:41 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 21:32:41 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <40D826E9.8040200@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>For example, in my draft you actively ignored, I wrote: >> >> For example, some TLA may be supplied from RIRs with bidding. >> >> Some TLA may be allocated to each country (proportional to the >> population of the country) and delivered with the countrie's policy. > I was asking trying to clarify what you meant by "national IR" and > under what policies these would operate. Which is a fairly substantive > question. And, as I properly quoted, the answer was given in my draft you actively ignored. proportional to the population of the country OK? > But I think the chairs will ask us to take this elsewhere soon, as this > is pretty far off topic. As my suggestion is just "for example" that there are a lot to discuss which is within the scope of "address-policy-wg". Masataka Ohta From oppermann at pipeline.ch Tue Jun 22 14:28:39 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 22 Jun 2004 14:28:39 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 PolicyClarification - Initial allocation criteria "d)") References: <200406221209.i5MC9Htt009455@alpha.bartels.de> <40D82576.8040501@necom830.hpcl.titech.ac.jp> Message-ID: <40D825F7.E81383F3@pipeline.ch> Masataka Ohta wrote: > > Oliver Bartels: > > >>So that would be a maximum of 10.000 routing table entries (if we > >>can manage to keep it at "1 prefix per LIR"). > > > > Full Ack. > > > > A table of this size is handled with a one cycle memory access > > in modern routing hardware. > > By definition of "one cycle memory access", any table of any size > can be handled with a one cycle memory access in any routing hardware. > > However, memory access cycle can be a lot larger than a CPU clock > cycle. > > On typical modern chips, tens of registers can be accessed within > a CPU cycle. On chip primary cache with thousands of entries > needs about twice or three times more than that. Off chip cache > needs about ten, twenty or, maybe, hundred more to access. If I get this correctly you seem to argue that because todays hardware is "slow" and/or "inefficient" for large routing tables IPv6 multi- homing should not be allowed? This way at looking things in fundamentally broken. The need for speed has started many developments we enjoy today. I am sure engineers will find good and efficient ways to deal with large routing tables at high speeds. Just look at the last ten years. In 1994 a T3 was like "wow!". Today n-times 10Gig is "wow!". Go ahead and technology will follow. -- Andre From oliver at bartels.de Tue Jun 22 14:31:08 2004 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 22 Jun 2004 14:31:08 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D81FB7.4070003@necom830.hpcl.titech.ac.jp> Message-ID: <200406221230.i5MCUNtt010022@alpha.bartels.de> On Tue, 22 Jun 2004 21:01:59 +0900, Masataka Ohta wrote: >Just for your (other than Kurt) information, there is running code >of a multi6 proposal which does not bloat global routing table >size, which has been running even before the multi6 WG was formed. With todays >10GB backbones, we need running *hardware*. >The only problem for the deployment of the proposal is that >IPv6 is not deployed. This is *the* cat-tail-problem we are talking about: IPv6 *won't* be deployed if it can't provide at a minimum all commonly used features of IPv4 and does something better. Multihoming with unique and world wide valid IP adresses *is* a feature commonly used by *large* customers who pay significant amounts of the ISP infrastructure. At the end of the day the technical guys have to justify the invests into new infrastructure to the commercial guys. They will simply ask: "What does IPv6 gain to our company" "Oh well, instead of having first class PA/PI adresses, we will have second class multi6 accessibility and our true address range will be at the mercy of our Upstream/ISP" If you want to see what happens with investments of artificial "comission" protocols, have a look at UMTS ;-/ Ceterum censeo: Either the routing bottleneck is removed, or we won't see a successfull IPv6 in the next fifty years. And sadly as it is: To make some address range globaly routable as *numeric packet address* and not as super-DNS or second class host-hast-to-start-search addreses the routers which do the job need some information about the goal of the packet, of either static or dynamic type. And as the ISP market has no regional hierachy like a postal service, it must be world wide. IMHO the only chance of a commercially successfull deployment is some sort of make-it-better-than-BGP which can handle large amounts of prefix data. As we can't expect such a change in the near future, in my personal view the policy needs a modification which: a) advances and pushes forward IPv6 deployment, instead of the >=200 limit which is rather contraproductive. b) *currently* keeps the cover on the multihoming pot until the problem is *really* solved by technology. Sorry that I have no better news, but mathematics and physical law's won't be changed by discussions, as well as economical laws won't. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From gert at space.net Tue Jun 22 14:35:09 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 14:35:09 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D8237D.5020301@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> Message-ID: <20040622123509.GT6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 09:18:05PM +0900, Masataka Ohta wrote: > Gert Doering wrote: > > >>>>In favour of *what* to replace it? > >>> > >>>RIR membership. > >> > >>No. It is proven not to scale. > > > "Proven"? When, where, by whom, based on what data? > > There are less than 10.000 LIRs in existance today, all RIRs combined. > According to my upper bound, it's already unnecessarily too large. So the *proof* mentioned above consists of "your personal feelings what the upper limit on the routing table size should be"? While I honour your feelings (I also think that the routing table shouldn't grow out of bounds), this is no "proof" that it's not going to scale. Also it brings back the problem of "who is worthy enough to receive one of 8192 TLAs", which was abandoned some 5 years ago, because there is no entity that can make this decision. > > 10.000 routing table entries is something far below the near 140.000 we > > have today in IPv4. While I'm seriously unhappy with the 140.000 IPv4 > > routes, it *does* scale up to fairly insane numbers. > > Of course, you can have as many routing table entries as you want, > as long as backbone routers, speed of which degrade as their routing > table bloat, have large enough routing table. Of course. But I tend to believe if people tell me "10k routes are no problem today". Oliver is building routers, with fast memory, and good routing table lookup algorithms. Today, high end routers can handle 140k routes. [..] > If the size of global routing table is limited by a hard upper > bound, it simplifies the design of routers a lot (you can put > a backbone router (or many of them) with a global routing table > in a chip), reduces cost of routers a lot and increases speed > of routers a lot. This is not going to work. *Inside* your AS, you will always have some more routes, and depending on the quality of your IGP aggregation, you might easily end up with more than 10k *internal* routes. So no matter what upper bound you put on the external routes, you cannot assume that nobody will ever need more routing table entries. Out of interest: what number do you suggest for the hard upper bound? > Note that, for scalable (thus, end to end) site multihoming properly > work, all the sites are required to circulate global routing table > within the sites. Actually, no. Not even in IPv4 today (which is part of the problem, that you can inject your prefix from a Cisco 2500 router, while everyone else needs to buy $costly hardware to *carry* your prefix). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From oliver at bartels.de Tue Jun 22 14:40:16 2004 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 22 Jun 2004 14:40:16 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D82576.8040501@necom830.hpcl.titech.ac.jp> Message-ID: <200406221239.i5MCdVtt010229@alpha.bartels.de> On Tue, 22 Jun 2004 21:26:30 +0900, Masataka Ohta wrote: >However, memory access cycle can be a lot larger than a CPU clock >cycle. With 10000 prefixed put in in a TCAM and get a result per pipeline cycle. This means 100M packet lookups per second, which is sufficient for >10G. TCAM does the complete prefix lookup in one cycle. It's limit by price is the table size (typically 64K to 256K). If it is combined with regular RAM (per cluster table), someone can select millions of prefixes *pipelined* within few accesses in a fully pipelined architecture in the >=10G and >=100Mpps range. >On typical modern chips, tens of registers can be accessed within >a CPU cycle. On chip primary cache with thousands of entries >needs about twice or three times more than that. Off chip cache >needs about ten, twenty or, maybe, hundred more to access. Modern Routers no longer use traditional CPU/cache architectures. Either fast static RAM together with trie structures (e.g. patricia tree/radix tree) or TCAM is used together with highly pipelined processors. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From gert at space.net Tue Jun 22 14:47:01 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 14:47:01 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <20040622124701.GV6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 02:20:03PM +0200, Kurt Erik Lindqvist wrote: > But I think the chairs will ask us to take this elsewhere soon, as this > is pretty far off topic. Oh, well, it gives interesting insights. Also I finally got my statement for "WE NEED TO KEEP THE 200 USERS RULE!", and I'm now trying to sum up the discussion into a summary statement... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 14:53:52 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 21:53:52 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> Message-ID: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>Kurt, as I made presentation in front of you and Brian >>Carpenter at multi6 WG meeting of IETF58 in Minneapolis > I think I have seen close to 40 presentations that all would solve the > multihoming problem one way or the other, or at least parts of it. 40? Below is the agenda of the last Minneapolis meeting. Agenda bashing, Chairs (5 min) DT2 Update, David&Marcelo (5 min) DT1 Update, Tony&Iljitsch (5 min) MAST, Dave Crocker (15 min) draft-arifumi-tcp-mh-00, Arifumi Matsumoto (10 min) draft-ohta-multihomed-isps-00, Masataka Ohta (15 min) draft-ohira-assign-select-e2e-multihome-02, Kenji Ohira (10 min) LIN6 update, Masahiro Ishiyama (5 min) draft-nordmark-multi6-threats-00, Erik Nordmark (5 min) draft-nordmark-multi6-noid-01 and draft-nordmark-multi6-sim-01, Erik Nordmark (10 min) Update from chairs and where we go next Open microphone There were a lot less than 40 presentations and the number of proposals was even less. >>on Nov. 2003, it is possible for a small ISP delegated >>address blocks from multiple larger ISPs and can still >>have its own policy. > It's possible for a small ISP to get several blocks from their > upstream, route them inside their network and assign each of their > customers with an address out of each of those blocks. Does it scale? > Nope. Can it handle failures in the upstream? No. Etc. First of all, the small ISPs have multiple upstream ISPs. It is explicitly stated in my draft, which is 3 pages long: It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites. NLI is an acronym of "Next Level ISP". >>Since then, you made no counter argument against my >>presentation that it is your fallacy to say things >>against the presentation. > There are several of the proposals in multi6 that have never received > comments, nor support of any kind. That's fine, as long as you are indifferent to the issue. However, as you actively made statement against my draft, you are guilty. > Your document does not address the criterias for being classified in a > particular category. My document does address the criteria for being classified in TLI. Classification as NLI is up to TLIs. > It does not address what would happen if an ISP > grow, get's split/divided. No, of course. What if, an ISP having a global routing table entry grow, get's split/divided? The issue is orthogonal to my draft. > It does not address what the financial > models for transit would be. No, of course. It is a policy issue orthogonal to my draft. > It does not address the non-balance of > local vs global traffic coverage. No, of course. For TLI, only the global traffic is important. > It does not take into account the > current peering economics of the Internet. No, of course. It is a policy issue orthogonal to my draft. > So it's really hard to say > anything regarding it. which means you have been indifferent to multi6 issues. >>>If he changes the single upstream his customers needs to >>>renumber. >> >>If one changes homing, one needs to renumber, of course. > Which is a limiting factor that I think you will that customers will > find unacceptable. Huh? What can the customer do, then? Note that it is not acceptable for the customer to switch to other ISP only to change its address. > Having to renumber when chaining ISPs is not to discourage _change_ of > ISP. It's to discourage signing up with that ISP in the first place. What if an ISP bankrupts (like UUNET) and stop operating? Are you saying to discourage signing up with any ISP which may possibly stop operating in the future? Masataka Ohta From kurtis at kurtis.pp.se Tue Jun 22 14:56:28 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 14:56:28 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D826E9.8040200@necom830.hpcl.titech.ac.jp> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> <40D826E9.8040200@necom830.hpcl.titech.ac.jp> Message-ID: <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 14.32, Masataka Ohta wrote: > > proportional to the population of the country > > OK? Well, I was unclear. I was referring to the policy of the national IR? Who sets that policy? Actually, what is the national IR? National government? Who gives the national IR authority? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgsgaarNKXTPFCVEQKAxACg/u+0brzfNy/70ZYfRTI+0itUJkoAoJXp 6uMfeFYh3794+OqhVGshZBc5 =mkIy -----END PGP SIGNATURE----- From nils at druecke.strg-alt-entf.org Tue Jun 22 15:03:00 2004 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Tue, 22 Jun 2004 09:03:00 -0400 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622122640.GS6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622121640.GB18423@bug> <20040622122640.GS6204@Space.Net> Message-ID: <20040622130300.GD18423@bug> On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote: > > > I can see that people don't like it, I'm just mentioning that it *could* > > > be done. We will need to do something like that for the class "is ISP > > > but is not LIR", even if we abandon the 200-users rule. > > I would change that to "is mutlihomed but is not LIR". Even without being an > > ISP you can easily run into the same problems. And I do not want to be in > > charge at Siemens, GM, Nortel, Cisco or so for renumbering projects. > > So what is your propsal for a new policy, then? > > "Everybody who is special gets their own allocation?" I personally would like to see "Everybody who wants it gets an allocation", but I see the technical limitations. But I agree with Oliver in so far, as I can not see IPv6 deployment in major organisations without giving them advantages over IPv4. This is an economical limitation. So now the question is: Should the policy try to fix the technical problem and then we wait for economics to change, or should the policy try to fix the economical problem and we wait for technology to change? Given the pace of change in these two field, I think it is more likely that technicians come up with a solution being able to handle billions of routes, then economy doing something that costs money to lose a benefit. Currently working on the next budget I again (like the last two years) think about budgeting for the move v4 to v6 (or more precisely for its start, as this will never be done within one year). And though my technically intereted heart would love to do it, the brain kicks in: There is absolutely no reason, it costs money, it does not give you any advantage. I think the policy, concentrating on technical issues, actually makes IPv6 less attractive. Nils -- C: Ich m?chte nicht l?nger "Junge" genannt werden. Ich finde den Ausdruck dem?tigend und sexistisch. H: Wie m?chtest Du dann genannt werden? [aus "Calvin and Hobbes" C: "Genetisch bevorzugter Jugendlicher". by Watterson] From kurtis at kurtis.pp.se Tue Jun 22 15:14:08 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 15:14:08 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> Message-ID: <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > There were a lot less than 40 presentations and the number of > proposals was even less. Since the first meeting in Vienna there have been a lot more presentations. I didn't say anything about Minneapolis. Whatever. >>> on Nov. 2003, it is possible for a small ISP delegated >>> address blocks from multiple larger ISPs and can still >>> have its own policy. > >> It's possible for a small ISP to get several blocks from their >> upstream, route them inside their network and assign each of their >> customers with an address out of each of those blocks. Does it scale? >> Nope. Can it handle failures in the upstream? No. Etc. > > First of all, the small ISPs have multiple upstream ISPs. Yes? > It is explicitly stated in my draft, which is 3 pages long: > > It is expected that NLIs have multiple prefixes each belonging to > multiple TLAs, all of which is delegated to sites. > > NLI is an acronym of "Next Level ISP". Yes? And if the end host selects an address that belongs to a TLI that has a internal network failure and the traffic is blaockholed in that providers network, how does the end node find out? TCP timeout? >> There are several of the proposals in multi6 that have never received >> comments, nor support of any kind. > > That's fine, as long as you are indifferent to the issue. I am not. But it's the multi6 WG that will have to end up selecting what to move forward. > However, as you actively made statement against my draft, you > are guilty. "Guilty"!? Whatever. >> Your document does not address the criterias for being classified in a >> particular category. > > My document does address the criteria for being classified in TLI. > > Classification as NLI is up to TLIs. So each TLI can have their own policy for their down-stream NLIs? Who decides who are the TLIs? >> It does not address what would happen if an ISP >> grow, get's split/divided. > > No, of course. > > What if, an ISP having a global routing table entry grow, get's > split/divided? Actually, this is an issue today. Not a complex one, but there is policies in place for it. And if a TLI no longer is a TLI, that will have implications on down-streams. >> It does not address what the financial >> models for transit would be. > > No, of course. > It is a policy issue orthogonal to my draft. Your draft does makes assumptions on how the policy would like. It actually makes assumptions that are very different from the model of today so I think it would be reasonable to explain the thinking. Otherwise I don't think to many ISPs will be interested. >> It does not address the non-balance of >> local vs global traffic coverage. > > No, of course. > > For TLI, only the global traffic is important. What about TLIs that do have large customer bases in local networks? What about very dominant local players that today can force large ISPs to peer simply because of the dominance in particular markets? >> It does not take into account the >> current peering economics of the Internet. > > No, of course. > > It is a policy issue orthogonal to my draft. Again, if you propose something that ignores the polices as they are implemented in todays Internet, I would expect at least some elaboration on how you see todays ISPs adopt this scheme. >> Having to renumber when chaining ISPs is not to discourage _change_ of >> ISP. It's to discourage signing up with that ISP in the first place. > > What if an ISP bankrupts (like UUNET) and stop operating? It creates a nightmare for it's customers. Been there, done that, and have plenty of T-shirts to prove it. I think you miss the point. customers do not want to renumber if their _ISP change upstream_. That have a financial impact on them without them having control of the decision. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNgwp6arNKXTPFCVEQIHOgCgzo+9bGXkc8O5A1wwLbC5C5f68/wAoLom neT+RDZlLHxQTDdRyTF+Uq7y =0ZWg -----END PGP SIGNATURE----- From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 15:25:19 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 22:25:19 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040622123509.GT6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <20040622114911.GK6204@Space.Net> <40D8237D.5020301@necom830.hpcl.titech.ac.jp> <20040622123509.GT6204@Space.Net> Message-ID: <40D8333F.8000804@necom830.hpcl.titech.ac.jp> Gert Doering; >>According to my upper bound, it's already unnecessarily too large. > So the *proof* mentioned above consists of "your personal feelings what > the upper limit on the routing table size should be"? No. I gave the upper bound considering the current number of unit of global policies ((UN approved) countries and (self qualified) tier1 providers) and concluded 1000 is large enough. > While I honour your feelings (I also think that the routing table > shouldn't grow out of bounds), this is no "proof" that it's not going > to scale. As you agree that there should be bounds, any policy not incorporating the bounds does not scale. QED. > Also it brings back the problem of "who is worthy enough to receive > one of 8192 TLAs", which was abandoned some 5 years ago, because there > is no entity that can make this decision. But, we have entities to define address allocation rules. So, it is merely an issue to have an agreeable rule. For example, assign 3 TLAs to NICs operating ccTLDs. NICs of countries are assigned one more for each population of 10 million. Then, have 500 for initial auction with lease period of a year with 10 more supplied monthly for 5 years. There will be about 2,000 TLAs, yet. > Of course. But I tend to believe if people tell me "10k routes are no > problem today". Oliver is building routers, with fast memory, and > good routing table lookup algorithms. Be careful. I'm not offending Oliver. But, it should be noted that, in general, router vendors, especially large ones, want to keep their product as expensive as possible. And, now, though I may offend Oliver, router engineers do their work in a way they have been doing. So, it is possible to have a router with 10k routes today and tomorrow. But, it will costs almost as much as today even in tomorrow. However, it is a lot less expensive if global routing can be performed only by looking 13 bits of the address. There is no associative memory necessary. It's just a memory of 8K entry with no associativity. I think it is still reasonable to have an associative memory of, say, 1K entry, for local routing. > Today, high end routers can handle 140k routes. How much does it costs? How much do low end routers with 1G ethernet interfaces costs? >>If the size of global routing table is limited by a hard upper >>bound, it simplifies the design of routers a lot (you can put >>a backbone router (or many of them) with a global routing table >>in a chip), reduces cost of routers a lot and increases speed >>of routers a lot. > This is not going to work. *Inside* your AS, you will always have > some more routes, Sure. It does work. See above. > and depending on the quality of your IGP aggregation, > you might easily end up with more than 10k *internal* routes. It's a poor operation, which costs. > So no matter what upper bound you put on the external routes, you > cannot assume that nobody will ever need more routing table entries. Those requiring a lot IGP entries should pay the cost by themselves. > Out of interest: what number do you suggest for the hard upper bound? 8K for the global routing table, though I think, with reasons, 1K is large enough. >>Note that, for scalable (thus, end to end) site multihoming properly >>work, all the sites are required to circulate global routing table >>within the sites. > Actually, no. Not even in IPv4 today (which is part of the problem, > that you can inject your prefix from a Cisco 2500 router, while > everyone else needs to buy $costly hardware to *carry* your prefix). Yes and no. IPv4 today is hopeless, because of legacy randomized allocation of class Cs, which is why multi6 is not multi4. The charter of multi6 says: but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 15:29:34 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 22:29:34 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> <40D826E9.8040200@necom830.hpcl.titech.ac.jp> <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <40D8343E.4020009@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >> proportional to the population of the country >> >>OK? > Well, I was unclear. I was referring to the policy of the national IR? > Who sets that policy? Actually, what is the national IR? National > government? Who gives the national IR authority? Do you know how nations get ccTLDs? Hint: We have UN. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 15:41:20 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 22:41:20 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <200406221239.i5MCdVtt010229@alpha.bartels.de> References: <200406221239.i5MCdVtt010229@alpha.bartels.de> Message-ID: <40D83700.5080703@necom830.hpcl.titech.ac.jp> Oliver Bartels; >>However, memory access cycle can be a lot larger than a CPU clock >>cycle. > > With 10000 prefixed put in in a TCAM and get a result per pipeline > cycle. This means 100M packet lookups per second, which is > sufficient for >10G. TCAM does the complete prefix lookup > in one cycle. I know. Do you know that the current Internet backbone is operating with parallel 10Gs? > It's limit by price is the table size (typically 64K to 256K). So, large memory costs. Do you also know that access speed of memory (including but not limited to TCAM) degrades proportional to log or sqrt of the number of entries? > If it is combined with regular RAM (per cluster table), someone can > select millions of prefixes *pipelined* within few accesses in > a fully pipelined architecture in the >=10G and >=100Mpps range. I know. And, it costs a lot. >>On typical modern chips, tens of registers can be accessed within >>a CPU cycle. On chip primary cache with thousands of entries >>needs about twice or three times more than that. Off chip cache >>needs about ten, twenty or, maybe, hundred more to access. > > Modern Routers no longer use traditional CPU/cache architectures. > Either fast static RAM together with trie structures (e.g. patricia > tree/radix tree) or TCAM is used together with highly pipelined > processors. Both modern routers and modern CPUs are highly pipelined, which means there is some performance loss if TCAM or primary cache miss occurs. Secondary or third level cache of modern CPUS often have millions of entries and constructed with static RAM. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 15:59:52 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 22:59:52 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <40D83B58.90906@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>>It's possible for a small ISP to get several blocks from their >>>upstream, route them inside their network and assign each of their >>>customers with an address out of each of those blocks. Does it scale? >>>Nope. Can it handle failures in the upstream? No. Etc. >> >>First of all, the small ISPs have multiple upstream ISPs. > > > Yes? It does scale. It can handle failures in the upstream. >>It is explicitly stated in my draft, which is 3 pages long: >> >> It is expected that NLIs have multiple prefixes each belonging to >> multiple TLAs, all of which is delegated to sites. >> >>NLI is an acronym of "Next Level ISP". > Yes? And if the end host selects an address that belongs to a TLI that > has a internal network failure and the traffic is blaockholed in that > providers network, how does the end node find out? TCP timeout? Read the draft of end to end multihoming. It is an issue of transport/application layer. Application running over TCP can use default TCP timeout or modify it. Application may use UDP with its own timeout. >>>There are several of the proposals in multi6 that have never received >>>comments, nor support of any kind. >> >>That's fine, as long as you are indifferent to the issue. > I am not. You have been. > But it's the multi6 WG that will have to end up selecting > what to move forward. It's your problem that you failed to properly control the WG. > "Guilty"!? Whatever. See the subject. > So each TLI can have their own policy for their down-stream NLIs? Who > decides who are the TLIs? If you need an example policy, read the draft. >>>It does not address what would happen if an ISP >>>grow, get's split/divided. >> >>No, of course. >> >>What if, an ISP having a global routing table entry grow, get's >>split/divided? > > > Actually, this is an issue today. Not a complex one, but there is > policies in place for it. And if a TLI no longer is a TLI, that will > have implications on down-streams. Sure. So, even if you directly subscribe to an TLI, you may have to renumber. Fair enough. > Your draft does makes assumptions on how the policy would like. My draft does not make any assumption on how the policy would like. You failed to give specific example for counter argument. >>>It does not address the non-balance of >>>local vs global traffic coverage. > What about TLIs that do have large customer bases in local networks? > What about very dominant local players that today can force large ISPs > to peer simply because of the dominance in particular markets? Dominant local players may be treated as NLI or it can be an independent TLI. I know Yahoo, for example, has certain influence on its ISPs. >>It is a policy issue orthogonal to my draft. > Again, if you propose something that ignores the polices as they are > implemented in todays Internet, I would expect at least some > elaboration on how you see todays ISPs adopt this scheme. I do recognize the policies and says them orthogonal. >>What if an ISP bankrupts (like UUNET) and stop operating? > > > It creates a nightmare for it's customers. Been there, done that, and > have plenty of T-shirts to prove it. I think you miss the point. > customers do not want to renumber if their _ISP change upstream_. That > have a financial impact on them without them having control of the > decision. You miss the point. I'm saying all the ISPs have chance to change its prefix. Masataka Ohta From kurtis at kurtis.pp.se Tue Jun 22 15:55:33 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 15:55:33 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D8343E.4020009@necom830.hpcl.titech.ac.jp> References: <200406171150.29481.jon@lawrence.org.uk> <20040621.170058.26554350.he@uninett.no> <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> <40D826E9.8040200@necom830.hpcl.titech.ac.jp> <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> <40D8343E.4020009@necom830.hpcl.titech.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 15.29, Masataka Ohta wrote: > >>> proportional to the population of the country >>> >>> OK? > >> Well, I was unclear. I was referring to the policy of the national IR? >> Who sets that policy? Actually, what is the national IR? National >> government? Who gives the national IR authority? > > Do you know how nations get ccTLDs? Well, this is an interesting question loaded with more politics that I really would like to get into. > Hint: We have UN. Hint: How does the island of Taiwan get a block? This discussion will drift into WSIS/ITU/UN/ICANN/IETF etc. Let's drop it here. I know what your view is then. Good enough. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg6XKarNKXTPFCVEQIrtQCfVvAFQzdG2EYvmQgDsIkoo+AgaNUAn3GN bVdP/hq5sdW/TdgG6jZEg1Sj =K/7S -----END PGP SIGNATURE----- From chbm at cprm.net Tue Jun 22 16:05:08 2004 From: chbm at cprm.net (Carlos Morgado) Date: Tue, 22 Jun 2004 15:05:08 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622122640.GS6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622121640.GB18423@bug> <20040622122640.GS6204@Space.Net> Message-ID: <20040622140508.GC2019@cprm.net> On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote: > Not that much. One could apply more-specific filters to routes coming > from other regions, so it *would* save something. Or the customer might What's this "regions" you speak about ? We're a fairly small (in the global scheme of things) transit provider and we're connected to 4 continents. Are you thinking about toy ISPs with one transit and a connection to the local IX ? -- Carlos Morgado - Internet Engineering GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From gert at space.net Tue Jun 22 16:10:50 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 16:10:50 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D8343E.4020009@necom830.hpcl.titech.ac.jp> References: <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> <40D826E9.8040200@necom830.hpcl.titech.ac.jp> <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> <40D8343E.4020009@necom830.hpcl.titech.ac.jp> Message-ID: <20040622141050.GY6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 10:29:34PM +0900, Masataka Ohta wrote: > > Well, I was unclear. I was referring to the policy of the national IR? > > Who sets that policy? Actually, what is the national IR? National > > government? Who gives the national IR authority? > > Do you know how nations get ccTLDs? > > Hint: We have UN. To bring in the governments into an address policy discussion should qualify for application of Godwin's law. "The thread has ended here". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 22 16:14:19 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 16:14:19 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D83B58.90906@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> Message-ID: <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> It is explicitly stated in my draft, which is 3 pages long: >>> >>> It is expected that NLIs have multiple prefixes each belonging to >>> multiple TLAs, all of which is delegated to sites. >>> >>> NLI is an acronym of "Next Level ISP". > >> Yes? And if the end host selects an address that belongs to a TLI that >> has a internal network failure and the traffic is blaockholed in that >> providers network, how does the end node find out? TCP timeout? > > Read the draft of end to end multihoming. Ok, so you are actually proposing that we a) Change the allocation policies according to draft-ohta-multihomed-isps-00.txt and b) Adopt the mechanisms in draft-ohta-e2e-multihoming-06.txt ? > It is an issue of transport/application layer. So we need to modify the application layer according to the e2e draft? > Application may use UDP with its own timeout. So all UDP applications need to modified (or not used at multihomed sites)? >> But it's the multi6 WG that will have to end up selecting >> what to move forward. > > It's your problem that you failed to properly control the WG. This is a discussion that doesn't belong here, but it's not the role of the WG chairs to control the WG. It's the chairs job to conclude what solutions there are support for and which ones there are not. This is the reason for the classification of solutions sent to the multi6 WG and the statement that many of them simply do not have any support. >> So each TLI can have their own policy for their down-stream NLIs? Who >> decides who are the TLIs? > > If you need an example policy, read the draft. Make a bidding round for the TLI roles? So you want an open market for default-free address space? >>>> It does not address the non-balance of >>>> local vs global traffic coverage. > >> What about TLIs that do have large customer bases in local networks? >> What about very dominant local players that today can force large ISPs >> to peer simply because of the dominance in particular markets? > > Dominant local players may be treated as NLI or it can be an > independent TLI. > > I know Yahoo, for example, has certain influence on its ISPs. So Yahoo would qualify as a TLI? If they won a TLI assignment in the bidding round? While for example NTT might not? >>> It is a policy issue orthogonal to my draft. > >> Again, if you propose something that ignores the polices as they are >> implemented in todays Internet, I would expect at least some >> elaboration on how you see todays ISPs adopt this scheme. > > I do recognize the policies and says them orthogonal. Well, the bidding for address space has a large chance to off-set the financial models of the Internet today. >> It creates a nightmare for it's customers. Been there, done that, and >> have plenty of T-shirts to prove it. I think you miss the point. >> customers do not want to renumber if their _ISP change upstream_. That >> have a financial impact on them without them having control of the >> decision. > > You miss the point. I'm saying all the ISPs have chance to change > its prefix. Why would customers go to NLIs in the first place? I for one would only by service from TLIs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg+vqarNKXTPFCVEQKuBgCfThWCvXgCnbYfsyFvRFxUlBsbnMUAn3hs LKmspmiIwsGGSWDu80HV4m56 =lPg6 -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Tue Jun 22 16:15:07 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 16:15:07 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622141050.GY6204@Space.Net> References: <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> <40D826E9.8040200@necom830.hpcl.titech.ac.jp> <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> <40D8343E.4020009@necom830.hpcl.titech.ac.jp> <20040622141050.GY6204@Space.Net> Message-ID: <904AF586-C456-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 16.10, Gert Doering wrote: > "The thread has ended here". Understood. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg+7qarNKXTPFCVEQKofwCg7YM4YqeDXkZIG4jqSoYnKv8DtMgAoJut BMsrbLN4fcA1dZikS9+wm+Zo =sBKy -----END PGP SIGNATURE----- From oliver at bartels.de Tue Jun 22 16:19:11 2004 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 22 Jun 2004 16:19:11 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D83700.5080703@necom830.hpcl.titech.ac.jp> Message-ID: <200406221418.i5MEIQtt012541@alpha.bartels.de> On Tue, 22 Jun 2004 22:41:20 +0900, Masataka Ohta wrote: >Do you know that the current Internet backbone is operating >with parallel 10Gs? Someone may stretch the term "backbone". There is no single one. Some use OC-3 and some use OC-192, some plan to use 40G (and caclculate wavelength counts against bandwidth occupied by a single wavelength). >So, large memory costs. Not really. Todays price, single pcs., IDT/-100 at Arrow for 64K*72 TCAM: $155 from stock. If someone operates a major backbone, this is no real cost factor compared to leased lines and wavelengths ... Even if you multiply this with five for sales droid financing ... Fast synchronous static memory is even *much* less, e.g. few $'s per Multi-Mbit chip. >Do you also know that access speed of memory (including but >not limited to TCAM) degrades proportional to log or sqrt of >the number of entries? Again, it depends ... >Both modern routers and modern CPUs are highly pipelined, which >means there is some performance loss if TCAM or primary cache >miss occurs. A *cached* router is a good-weather-only product which would die e.g. if a DDoS or SQL Slammer is on the road. Thus modern backbone routers *do not use route caches*. >Secondary or third level cache of modern CPUS often have millions >of entries and constructed with static RAM. Which again tells us that 10K is not a real limit for modern routers, as well as 100K is not. Noone would buy a *new* backbone router which isn't capable to handle a n*100K table even if there is "rain and snow" inside the network ... Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 16:24:26 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 23:24:26 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406221230.i5MCUNtt010022@alpha.bartels.de> References: <200406221230.i5MCUNtt010022@alpha.bartels.de> Message-ID: <40D8411A.6060202@necom830.hpcl.titech.ac.jp> Oliver Bartels; >>Just for your (other than Kurt) information, there is running code >>of a multi6 proposal which does not bloat global routing table >>size, which has been running even before the multi6 WG was formed. > > With todays >10GB backbones, we need running *hardware*. Sure. The proposal needs no change on routers, which is why the code is running, of course, over commercial v6 routers. >>The only problem for the deployment of the proposal is that >>IPv6 is not deployed. > > This is *the* cat-tail-problem we are talking about: > IPv6 *won't* be deployed if it can't provide at a minimum all > commonly used features of IPv4 and does something better. Currently, the only merit of v6 over v4 is that v6 address space is larger. Trying to add other merit, v6 became unncessarily complex and, thus, worse than v4. The only exception is the possiblity to limit the number of global routing table entries. See below. > Multihoming with unique and world wide valid IP adresses > *is* a feature commonly used by *large* customers who > pay significant amounts of the ISP infrastructure. That is a problem of v6, not of the proposal above. > At the end of the day the technical guys have to justify the > invests into new infrastructure to the commercial guys. > They will simply ask: > "What does IPv6 gain to our company" > "Oh well, instead of having first class PA/PI adresses, we will > have second class multi6 accessibility and our true address > range will be at the mercy of our Upstream/ISP" The proper answer should be: Because IPv6 requires only 8192 global routing table entries, 10G backbone router costs 100 times less than that of IPv4 > IMHO the only chance of a commercially successfull > deployment is some sort of make-it-better-than-BGP > which can handle large amounts of prefix data. Huh? Do you mean we shouldn't have policy to allow a lot of prefixes? > As we can't expect such a change in the near future, > in my personal view the policy needs a modification > which: > a) advances and pushes forward IPv6 deployment, > instead of the >=200 limit which is rather contraproductive. The only limitation globally necessary is on the number of TLAs. Other limitations are local issues. > b) *currently* keeps the cover on the multihoming pot > until the problem is *really* solved by technology. The problem is proven to be solved. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 16:27:14 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 23:27:14 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622141050.GY6204@Space.Net> References: <75BAE0C0-C421-11D8-B7DA-000A959B2120@isc.org> <20040622075905.GX6204@Space.Net> <40D81B37.30106@necom830.hpcl.titech.ac.jp> <40D82184.30909@necom830.hpcl.titech.ac.jp> <7D089EFC-C446-11D8-860C-000A95928574@kurtis.pp.se> <40D826E9.8040200@necom830.hpcl.titech.ac.jp> <93A15952-C44B-11D8-860C-000A95928574@kurtis.pp.se> <40D8343E.4020009@necom830.hpcl.titech.ac.jp> <20040622141050.GY6204@Space.Net> Message-ID: <40D841C2.6020507@necom830.hpcl.titech.ac.jp> Gert Doering wrote: >>>Well, I was unclear. I was referring to the policy of the national IR? >>>Who sets that policy? Actually, what is the national IR? National >>>government? Who gives the national IR authority? >> >>Do you know how nations get ccTLDs? >> >>Hint: We have UN. > > > To bring in the governments into an address policy discussion should qualify > for application of Godwin's law. "The thread has ended here". So, we don't have ccTLDs. OK. Masataka Ohta From german at lacnic.net Tue Jun 22 16:25:28 2004 From: german at lacnic.net (German Valdez) Date: Tue, 22 Jun 2004 11:25:28 -0300 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <066001c45837$fa02a760$640a0a0a@consulintel.es> References: <20040621234653.GB23267@nokia.com> <20040622084525.GA96141@kerkenna.nic.fr> <066001c45837$fa02a760$640a0a0a@consulintel.es> Message-ID: <6.1.1.1.2.20040622105852.069cdc10@lacnic.net.uy> Hi Jordi You are right. The policy comparison document is updated every six months in collaborative work among the 4 RIR we are just about to released the newest version soon. LACNIC is right now applying a different IPv6 initial allocation policy. The rest of the document remains the same as the original common IPv6 policy. This issue was discussed during LACNIC V in last november and implemented in february this year. LACNIC community had consensus about get rid of 200 /48 assignments, demand the announcement of the entire IPv6 block before the 12 months and asked for IPv6 based services before the 24 months. It is important to mention also that LACNIC do not allocate IPv6 address to closed networks at this moment. This topic has been also a point of discussion among the differentescommunities. I add the text for the initial IPv6 allocation policy at LACNIC To qualify for an initial allocation of IPv6 address space, an organization must: a) Be a LIR or an ISP; b) Not be an end site (end user); c) Document a detailed plan for the services and IPv6 connectivity to be offered to other organizations (clients) d) Announce a single block in the Internet inter-domain routing system, aggregating the total IPv6 address allocation received, within a period not longer than 12 months. e) Offer IPv6 services to clients physically located within the region covered by LACNIC within a period not longer than 24 months. Regards German Valdez LACNIC At 06:04 AM 6/22/2004, JORDI PALET MARTINEZ wrote: >Hi Mohsen, > >http://www.apnic.net/docs/policy/rir-comparison.html >Looking at the LACNIC site, I believe this is not updated. I think same >for ARIN. > >Regarding the critical infrastructure, I fully support a policy change on >this in RIPE. > >Regards, >Jordi > >----- Original Message ----- >From: "Mohsen Souissi" >To: "David Kessens" >Cc: "Laura Cobley" ; >Sent: Tuesday, June 22, 2004 10:45 AM >Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial >allocation criteria "d)" > > > > David & all, > > > > On 21 Jun, David Kessens wrote: > > | > > | Laura, > > | > > | On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: > > | > > > | > During the following discussions, the RIPE NCC was asked to > co-ordinate > > | > work on clarifying the text. Please note that we do not intend to > > | > propose any policy changes. > > | > > | During the meeting, I asked you not to waste your time on this. Since > > | the policy is already changing in the other regions, our time would be > > | better spend to move forwards, instead of stalling the policy > > | development process by spending time on 'clarifications'. > > | > > | I would like to ask the working group whether we can ask the RIPE NCC > > | to summarize the different changes made to the policy in the other > > | regions, so that we can have a discussion on which changes are > > | appropriate. > > > > ==> If it is deemed that it would be worth proceeding now to the > > Policy change (instead of simply clarifing it as it was initially > > intended), let me please draw your attention to the following web page > > at APNIC site, which compares RIR implementations of the global IPv6 > > Policy and which may be useful as a start: > > > > http://www.apnic.net/docs/policy/rir-comparison.html > > > > By the way, you can have a look at section 3.4.1 ("Critical > > Infrastructure") which describes, AFAIK, somtehing which is > > implemented only in APNIC region and which would be useful for ccTLDs > > in Europe (for instance, .de and .fr to name a few of them). > > > > Regards, > > > > Mohsen. > > > > > > >********************************** >Madrid 2003 Global IPv6 Summit >Presentations and videos on line at: >http://www.ipv6-es.com > >This electronic message contains information which may be privileged or >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aware >that any disclosure, copying, distribution or use of the contents of this >information, including attached files, is prohibited. > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004 -------------- next part -------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004 From oliver at bartels.de Tue Jun 22 16:26:59 2004 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 22 Jun 2004 16:26:59 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D8411A.6060202@necom830.hpcl.titech.ac.jp> Message-ID: <200406221426.i5MEQDtt012768@alpha.bartels.de> On Tue, 22 Jun 2004 23:24:26 +0900, Masataka Ohta wrote: >The proper answer should be: > > Because IPv6 requires only 8192 global routing table > entries, 10G backbone router costs 100 times less than > that of IPv4 You are joking. If you buy a $100000 car and drive 1000 milles per year, you won't drop your total cost of ownership by a factor of 10 if you just get the gasoline 10 times cheaper ... I agree with Gert: => application of Godwin's law. "The thread has ended here". Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From lear at cisco.com Tue Jun 22 16:23:46 2004 From: lear at cisco.com (Eliot Lear) Date: Tue, 22 Jun 2004 16:23:46 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D83B58.90906@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> Message-ID: <40D840F2.4080109@cisco.com> Ohta-san, Which part of your previous message provides me guidance on how your solution will solve scaling problems? Eliot From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 16:44:51 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 23:44:51 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <200406221418.i5MEIQtt012541@alpha.bartels.de> References: <200406221418.i5MEIQtt012541@alpha.bartels.de> Message-ID: <40D845E3.5090103@necom830.hpcl.titech.ac.jp> Oliver Bartels; >>Do you know that the current Internet backbone is operating >>with parallel 10Gs? > > Someone may stretch the term "backbone". > There is no single one. There is 10G backbone with paralle routes operated at least one ISP in Japan. >>So, large memory costs. > > Not really. > > Todays price, single pcs., IDT/-100 at Arrow for 64K*72 TCAM: > $155 from stock. Instllation of chips, especially those operating at highest possible speed, costs a lot more than that. If it is not on chip, you lose, a lot. > If someone operates a major backbone, this is no real > cost factor compared to leased lines and wavelengths ... If country backbone is as slow as 10G, maybe. However... In Japan, today, several Kms of dark fiber costs tens of USD/month. > Even if you multiply this with five for sales droid financing ... Internet grows faster than any sales droid can understand. > Fast synchronous static memory is even *much* less, e.g. > few $'s per Multi-Mbit chip. As it is off the chip, you automarically lose. >>Do you also know that access speed of memory (including but >>not limited to TCAM) degrades proportional to log or sqrt of >>the number of entries? > > Again, it depends ... It depends? I'm saying how it depends. It, of course, is not a problem, if and only if the routing table size has hard limit. >>Both modern routers and modern CPUs are highly pipelined, which >>means there is some performance loss if TCAM or primary cache >>miss occurs. > > A *cached* router is a good-weather-only product which would > die e.g. if a DDoS or SQL Slammer is on the road. That's why the global routing table must be small. > Thus modern backbone routers *do not use route caches*. I know. Who suggested route cache? I didn't. >>Secondary or third level cache of modern CPUS often have millions >>of entries and constructed with static RAM. > > Which again tells us that 10K is not a real limit for modern > routers, as well as 100K is not. It merely means that it costs, especially when you do off chip interleaving with a lot of wiring. > Noone would buy a *new* backbone router which isn't capable > to handle a n*100K table even if there is "rain and snow" inside > the network ... That was a valid argument for IPv4. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 16:48:50 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 23:48:50 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406221426.i5MEQDtt012768@alpha.bartels.de> References: <200406221426.i5MEQDtt012768@alpha.bartels.de> Message-ID: <40D846D2.7000902@necom830.hpcl.titech.ac.jp> Oliver Bartels; > You are joking. I'm afraid you are seriously saying that speed of the Internet stays same forever. > If you buy a $100000 car and drive 1000 milles per year, you > won't drop your total cost of ownership by a factor of 10 if you > just get the gasoline 10 times cheaper ... 10 years ago, T3 was considered to be fast. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 16:51:45 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 22 Jun 2004 23:51:45 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <40D84781.8020604@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>>>It is explicitly stated in my draft, which is 3 pages long: >>>> >>>> It is expected that NLIs have multiple prefixes each belonging to >>>> multiple TLAs, all of which is delegated to sites. >>>> >>>>NLI is an acronym of "Next Level ISP". >> >>>Yes? And if the end host selects an address that belongs to a TLI that >>>has a internal network failure and the traffic is blaockholed in that >>>providers network, how does the end node find out? TCP timeout? >> >>Read the draft of end to end multihoming. > > > Ok, so you are actually proposing that we I'm actually proposing that you read the draft, if you are interested in multi6 issues. Then, if you have any question, ask, hopefully with proper quoting of the draft. Masataka Ohta From Michael.Dillon at radianz.com Tue Jun 22 16:52:51 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 22 Jun 2004 15:52:51 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <40D841C2.6020507@necom830.hpcl.titech.ac.jp> Message-ID: > >>>Well, I was unclear. I was referring to the policy of the national IR? > >>>Who sets that policy? Actually, what is the national IR? National > >>>government? Who gives the national IR authority? > >> > >>Do you know how nations get ccTLDs? > >> > >>Hint: We have UN. > > > > > > To bring in the governments into an address policy discussion should qualify > > for application of Godwin's law. "The thread has ended here". > > So, we don't have ccTLDs. OK. This is terribly confused. In fact, nations get ccTLDs by accepting incoming international mail, i.e. letters and parcels. Any area of the world that has a postal system which receives incoming mail, also has a two-letter code assigned by the Universal Postal Union. They aren't terribly concerned about political divisions when making the code allocations. The important thing is that the area must have a separate postal system and since Taiwan has a postal system separate from the People's Republic of China, it also gets a UPU code. Same thing for Hong Kong. And mainland France also had a code until recently (MF) to distinguish it from the French overseas departments and territories which all have their own individual codes. IANA and ICANN simply refer to the UPU list to decide whether or not to give out a ccTLD. They prefer to give the ccTLD to an administrator who has the support of the majority of Internet users in the ccTLD area and there is a dispute procedure to sort out arguments. If necessary, governments can win those disputes but it usually is not necessary for governments to get involved at all because the independent ccTLD organizations in most countries try to do a good enough job that nobody complains about them. Strangely enough, this is not that different from the RIR system. --Michael Dillon From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 17:01:54 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 00:01:54 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <40D849E2.6010105@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; >>Application may use UDP with its own timeout. > So all UDP applications need to modified (or not used at multihomed > sites)? If there is a family of UDP applications sharing the same idea on "connection", there can be a set of connection management library functions shared by the applications. Then, it may be that only the library may be modified. > This is a discussion that doesn't belong here, but it's not the role of > the WG chairs to control the WG. Then, it was your mistake that you controlled the WG to forbid presentations of proposals. > Make a bidding round for the TLI roles? So you want an open market for > default-free address space? Read the draft for an example. It does not say "open". > So Yahoo would qualify as a TLI? If they won a TLI assignment in the > bidding round? While for example NTT might not? Read the draft. >>I do recognize the policies and says them orthogonal. > Well, the bidding for address space has a large chance to off-set the > financial models of the Internet today. As explained in my presentation, it does not. > Why would customers go to NLIs in the first place? I for one would only > by service from TLIs. It is you who are ignoring the reality. Why do customers today buy service from tier2 providers? Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 17:06:19 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 00:06:19 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D840F2.4080109@cisco.com> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <40D840F2.4080109@cisco.com> Message-ID: <40D84AEB.4090101@necom830.hpcl.titech.ac.jp> Eliot Lear; Hi, > Which part of your previous message provides me guidance on how your > solution will solve scaling problems? Scaling problems of which? If we have hard limit on the global routing table size, there is no scaling problem on the global routing table size. The question is whether we can put the limit or not. Considering that the global routing table entries are for global policy control, we don't need so much entries much more than those having real global policy, that is, (self qualified) tier1. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 17:20:08 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 00:20:08 +0900 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: Message-ID: <40D84E28.2000806@necom830.hpcl.titech.ac.jp> Michael.Dillon at radianz.com wrote: >>>>>Who sets that policy? Actually, what is the national IR? National >>>>>government? Who gives the national IR authority? >>>> >>>>Do you know how nations get ccTLDs? >>>> >>>>Hint: We have UN. > IANA and ICANN simply refer to the UPU list to decide whether or not to > give out a ccTLD. They prefer to give the ccTLD to an administrator who > has the support of the majority of Internet users in the ccTLD area and > there is a dispute procedure to sort out arguments. If necessary, > governments can win those disputes but it usually is not necessary for > governments to get involved at all because the independent ccTLD > organizations in most countries try to do a good enough job that nobody > complains about them. So, just as there are national NICs there can be national IRs. National IRs may nor may not be a part of a government. Masataka Ohta PS It's not UPU but ISO-3166, which is maintained by UN (security council). http://www.icann.org/icp/icp-1.htm : whose codes are assigned from a table known as ISO-3166-1, which is : maintained by an agency of the United Nations. From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 17:32:02 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 00:32:02 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D84E40.1080304@zurich.ibm.com> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D84E40.1080304@zurich.ibm.com> Message-ID: <40D850F2.4000701@necom830.hpcl.titech.ac.jp> Brian E Carpenter; > As Kurtis said, there have been no indications of support > for Masataka's draft in multi6, As you give no chance to discuss it at the meeting, it is not a valid decision. > so subject to the minutes of > the recent meeting being sent to the list and agreed, > it is off the table. Thank you for yet another demonstration of poor chairing. WG can't decide something at the meeting. Masataka Ohta From brc at zurich.ibm.com Tue Jun 22 17:20:32 2004 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Tue, 22 Jun 2004 17:20:32 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D849E2.6010105@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> Message-ID: <40D84E40.1080304@zurich.ibm.com> Since Kurtis took off his co-chair hat for this thread, I will put mine on. This is not a fruitful discussion, and it certainly should not be cross-posted. As Kurtis said, there have been no indications of support for Masataka's draft in multi6, so subject to the minutes of the recent meeting being sent to the list and agreed, it is off the table. Since multi6 has not firmly identified a solutions direction, and no work on a specific solution is chartered in the IETF yet, it's premature to discuss possible impact of multi6 on RIR policy. Brian multi6 WG co-chair Masataka Ohta wrote: > Kurt Erik Lindqvist; > > >>>Application may use UDP with its own timeout. > > >>So all UDP applications need to modified (or not used at multihomed >>sites)? > > > If there is a family of UDP applications sharing the same > idea on "connection", there can be a set of connection > management library functions shared by the applications. > Then, it may be that only the library may be modified. > > >>This is a discussion that doesn't belong here, but it's not the role of >>the WG chairs to control the WG. > > > Then, it was your mistake that you controlled the WG to forbid > presentations of proposals. > > >>Make a bidding round for the TLI roles? So you want an open market for >>default-free address space? > > > Read the draft for an example. It does not say "open". > > >>So Yahoo would qualify as a TLI? If they won a TLI assignment in the >>bidding round? While for example NTT might not? > > > Read the draft. > > >>>I do recognize the policies and says them orthogonal. > > >>Well, the bidding for address space has a large chance to off-set the >>financial models of the Internet today. > > > As explained in my presentation, it does not. > > >>Why would customers go to NLIs in the first place? I for one would only >>by service from TLIs. > > > It is you who are ignoring the reality. > > Why do customers today buy service from tier2 providers? > > Masataka Ohta > > > From kurtis at kurtis.pp.se Tue Jun 22 18:06:48 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 18:06:48 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D84781.8020604@necom830.hpcl.titech.ac.jp> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> Message-ID: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 16.51, Masataka Ohta wrote: >> Ok, so you are actually proposing that we > > I'm actually proposing that you read the draft, if you > are interested in multi6 issues. For the record for the RIPE address policy WG, I will take this discussion over to multi6 only. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNhZG6arNKXTPFCVEQLyCQCeMpcC0HeHQ5kwbyosKArIwO8zoosAn1PM VjC50f6zfRPocE5XrfPG9Zc1 =bva4 -----END PGP SIGNATURE----- From gert at space.net Tue Jun 22 20:58:36 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 20:58:36 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> Message-ID: <20040622185835.GC6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 06:06:48PM +0200, Kurt Erik Lindqvist wrote: > On 2004-06-22, at 16.51, Masataka Ohta wrote: > > >> Ok, so you are actually proposing that we > > I'm actually proposing that you read the draft, if you > > are interested in multi6 issues. > For the record for the RIPE address policy WG, I will take this > discussion over to multi6 only. I would appreciate if you could send us an "executive summary", so that people over here that are not so well-versed in the different multi6 proposals can try to judge the benefits and costs of this proposal. Something that right now confuses *me* is: If I understand this correctly, the 'default-free zone' is meant to be kept below 1000 routes, so routers can be fast. But what about the internal structure of all these networks? At least the "internal core" boxes need to know all routes for the "NLI"s (or the NLIs' customers), which might well be many 1000s... thanks, Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 22 21:06:12 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 21:06:12 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622140508.GC2019@cprm.net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622121640.GB18423@bug> <20040622122640.GS6204@Space.Net> <20040622140508.GC2019@cprm.net> Message-ID: <20040622190612.GD6204@Space.Net> Hi, On Tue, Jun 22, 2004 at 03:05:08PM +0100, Carlos Morgado wrote: > On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote: > > > Not that much. One could apply more-specific filters to routes coming > > from other regions, so it *would* save something. Or the customer might > > What's this "regions" you speak about ? We're a fairly small (in the global > scheme of things) transit provider and we're connected to 4 continents. > Are you thinking about toy ISPs with one transit and a connection to the > local IX ? I was speaking of RIR regions (which is the only thing that a router can filter on, provided ICANN will eventually start allocating decent chunks). Of course ISPs that are connected to all the regions will need to carry all more-specifics. Tough, cost of making business. There are different ISPs out there - those that are obviously large enough to not be called "toy ISPs", but still only active in one or two regions - so why should an ISP that's only active in the US carry more specifics from APNIC or Europe? Or vice versa? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 22 21:29:37 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 04:29:37 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040622185835.GC6204@Space.Net> References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> Message-ID: <40D888A1.7070901@necom830.hpcl.titech.ac.jp> Gert Doering; Hi, > Something that right now confuses *me* is: If I understand this > correctly, the 'default-free zone' is meant to be kept below 1000 > routes, so routers can be fast. The hard limit is, IMO, 8192. > But what about the internal > structure of all these networks? At least the "internal core" boxes > need to know all routes for the "NLI"s (or the NLIs' customers), which > might well be many 1000s... You are right. There is nothing mentioned in the draft, but I suggested 1000 today, which I still think enough for TLI internal, but should not be enough for NLI. Do you have any suggestion? Note that routers in NLIs may have less performance than those in TLIs. Masataka Ohta From gert at space.net Tue Jun 22 22:34:12 2004 From: gert at space.net (Gert Doering) Date: Tue, 22 Jun 2004 22:34:12 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D888A1.7070901@necom830.hpcl.titech.ac.jp> References: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> Message-ID: <20040622203411.GG6204@Space.Net> Hi, On Wed, Jun 23, 2004 at 04:29:37AM +0900, Masataka Ohta wrote: > Note that routers in NLIs may have less performance than those > in TLIs. Why? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohta at necom830.hpcl.titech.ac.jp Wed Jun 23 00:00:15 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 07:00:15 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040622203411.GG6204@Space.Net> References: <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> <20040622203411.GG6204@Space.Net> Message-ID: <40D8ABEF.30306@necom830.hpcl.titech.ac.jp> Gert Doering; >>Note that routers in NLIs may have less performance than those >>in TLIs. > Why? Because with minimum peering global traffic concentrates on peerings between TLIs and because minimum links make the traffice concentrate on backbone links of TLIs. With extra links, extra peerings and associated policies, it is possible to reduce the concentration or even have an NLI link carry more traffic than links of TLIs. Masataka Ohta From kurtis at kurtis.pp.se Wed Jun 23 09:12:27 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 23 Jun 2004 09:12:27 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040622185835.GC6204@Space.Net> References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> Ok, so you are actually proposing that we >>> I'm actually proposing that you read the draft, if you >>> are interested in multi6 issues. >> For the record for the RIPE address policy WG, I will take this >> discussion over to multi6 only. > > I would appreciate if you could send us an "executive summary", so > that people over here that are not so well-versed in the different > multi6 proposals can try to judge the benefits and costs of this > proposal. Which proposal? Ohta-sans? I will rather give you a short update on the status of multi6 in general. > Something that right now confuses *me* is: If I understand this > correctly, the 'default-free zone' is meant to be kept below 1000 > routes, so routers can be fast. But what about the internal > structure of all these networks? At least the "internal core" boxes > need to know all routes for the "NLI"s (or the NLIs' customers), which > might well be many 1000s... This is just one out of many proposals (+30) that was brought to the multi6 WG. During the interim meeting in Santa Monica last week a number of actions where triggered 1) The WG have been asked if they want to adopt draft-lear-multi6-things-to-think-about-03.txt as per the charter item "practical questions" 2) The WG have been asked if they want to adopt draft-nordmark-multi6-threats-02.txt as per the charter item "security threats" 3) A classification of many/most of the proposals brought to the multi6 WG was posted to the mailinglist as well as discussed during the interim meeting. The classification was based on draft-huston-multi6-architectures-01.txt. During the discussions at the interim meeting, the classification was revised and discussed. It was concluded that most of the classes either a) Lack support b) Proposals have been withdrawn by their author c) Are interesting as components for other solutions Based on this it was proposed to concentrate on solutions that are either "fat-ip" or wedgelayers at layer "3.5". This classification and the reasoning was posted to the multi6 WG mailinglist, and should be discussed there if anyone have opinions on it. Now, there is also the issue that the minutes from the interim meeting unfortunately have not been posted yet, as a full day minutes takes some time to merge. In the mean time there is a Jabber log at http://www.xmpp.org/ietf-logs/multi6 at ietf.xmpp.org/2004-06-14.html. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNktaqarNKXTPFCVEQI6LwCg5HxX2NAjrpbMN57Cs3dZrxae2SAAniiJ Yh5nFQ2QMfuXnFxr9L8j5guw =RHFL -----END PGP SIGNATURE----- From ncc at ripe.net Wed Jun 23 09:15:10 2004 From: ncc at ripe.net (Paul Rendek) Date: Wed, 23 Jun 2004 09:15:10 +0200 Subject: [address-policy-wg] [local-ir@ripe.net]ASO AC - Call for Nominations 2004 - RIPE NCC Service Region Message-ID: <000001c458f1$d1eba320$01a8a8c0@skytron.de> Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC From ncc at ripe.net Wed Jun 23 09:15:10 2004 From: ncc at ripe.net (Paul Rendek) Date: Wed, 23 Jun 2004 09:15:10 +0200 Subject: [address-policy-wg] [ncc-co@ripe.net] ASO AC - Call for Nominations 2004 - RIPE NCC Service Region Message-ID: <000201c458f1$d1ee1420$01a8a8c0@skytron.de> Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC From chbm at cprm.net Wed Jun 23 11:42:52 2004 From: chbm at cprm.net (Carlos Morgado) Date: Wed, 23 Jun 2004 10:42:52 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040622190612.GD6204@Space.Net> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <20040622064529.GT6204@Space.Net> <20040622121640.GB18423@bug> <20040622122640.GS6204@Space.Net> <20040622140508.GC2019@cprm.net> <20040622190612.GD6204@Space.Net> Message-ID: <20040623094252.GA6392@cprm.net> On Tue, Jun 22, 2004 at 09:06:12PM +0200, Gert Doering wrote: > Hi, > > On Tue, Jun 22, 2004 at 03:05:08PM +0100, Carlos Morgado wrote: > > On Tue, Jun 22, 2004 at 02:26:40PM +0200, Gert Doering wrote: > > > > > Not that much. One could apply more-specific filters to routes coming > > > from other regions, so it *would* save something. Or the customer might > > > > What's this "regions" you speak about ? We're a fairly small (in the global > > scheme of things) transit provider and we're connected to 4 continents. > > Are you thinking about toy ISPs with one transit and a connection to the > > local IX ? > > I was speaking of RIR regions (which is the only thing that a router > can filter on, provided ICANN will eventually start allocating decent > chunks). > Exactly. All this discussion becomes somewhat moot if the trend of /23s goes on much longer. Not to mention you lose hope of being able to recognize where an address is supposed to be without db lookups, but that's out of this scope. > > There are different ISPs out there - those that are obviously large > enough to not be called "toy ISPs", but still only active in one or > two regions - so why should an ISP that's only active in the US carry > more specifics from APNIC or Europe? Or vice versa? > Fair enough. >From a routing perspective, if you have 2 transit providers and ask them to announce default + clients/direct peerings you get a somewhat similar situation to IPv6 RIR prefixes + local specifics. Or am I missing something ? -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From mohta at necom830.hpcl.titech.ac.jp Wed Jun 23 13:03:38 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 Jun 2004 20:03:38 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> Message-ID: <40D9638A.7040105@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist; With your fallacy denied, why do you replay the well known fallacy of NAT that NAT is transparent to the upper layers? It is of course for those having some expertise on the Internet architecture that entities performing address rewriting between layer 4 of a peer is no transparent. > Based on this it was proposed to concentrate on solutions that are > either "fat-ip" or wedgelayers at layer "3.5". So, it is simply wrong. An easy counter example is an application protocol carrying raw address such as IPv4 FTP. Another easy counter example is applications over UDP. Layer 3.5 means an interim layer to perform address rewriting with which multihoming is supported without upper layer changes. Such approach does work to let all the existing upper layer accept incoming packets, regardless of their locators. However, with the unmodified upper layer, it is impossible for the interim or lower layers when to try alternate address of its peer. That is, such approach does not work to let any of the existing upper layer generate outgoing packets with proper destination locators. Thus, there is no such thing as the magical layer 3.5. That NAT and the layer 3.5 interoperate with TCP means nothing. Masataka Ohta From kurtis at kurtis.pp.se Wed Jun 23 13:10:54 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 23 Jun 2004 13:10:54 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D9638A.7040105@necom830.hpcl.titech.ac.jp> References: <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D9638A.7040105@necom830.hpcl.titech.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-23, at 13.03, Masataka Ohta wrote: > >> Based on this it was proposed to concentrate on solutions that are >> either "fat-ip" or wedgelayers at layer "3.5". > > So, it is simply wrong. I am simply referring the conclusions of the interim meeting on the request of the WG co-chair. Values of this being right or wrong, or other comments on various proposals to the multi6 problem belong in the multi6 WG. Not here (which I am sure the WG chairs will agree with). - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNllQaarNKXTPFCVEQIiTwCdGGiZVRjT5YA/LoyJU/H/+1KGVRYAoMWv OfxW6NYkpRMc66u8JunqmgL/ =1/8r -----END PGP SIGNATURE----- From gert at space.net Wed Jun 23 13:17:54 2004 From: gert at space.net (Gert Doering) Date: Wed, 23 Jun 2004 13:17:54 +0200 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D9638A.7040105@necom830.hpcl.titech.ac.jp> References: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D9638A.7040105@necom830.hpcl.titech.ac.jp> Message-ID: <20040623111754.GO6204@Space.Net> Hi, On Wed, Jun 23, 2004 at 08:03:38PM +0900, Masataka Ohta wrote: > With your fallacy denied, why do you replay the well known > fallacy of NAT that NAT is transparent to the upper layers? Please STOP cc: ing the address-policy working group on e-mails that are purely about protocol design decisions and problems. Your opinions about the address policy are known by now, and these e-mails do not contribute further to the discussion at hand. Gert Doering, speaking as APWG Co-Chair. -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From he at uninett.no Wed Jun 23 16:22:29 2004 From: he at uninett.no (Havard Eidnes) Date: Wed, 23 Jun 2004 16:22:29 +0200 (CEST) Subject: [address-policy-wg] Re: Fallacy by Kurt In-Reply-To: <40D888A1.7070901@necom830.hpcl.titech.ac.jp> References: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> Message-ID: <20040623.162229.70984010.he@uninett.no> > > Something that right now confuses *me* is: If I understand this > > correctly, the 'default-free zone' is meant to be kept below 1000 > > routes, so routers can be fast. > > The hard limit is, IMO, 8192. Past history has told us that at least some technologists have failed miserably in predicting whether fast routers can be built which handle largish routing tables. If I recall correctly, an argument similar to the above one was one of the arguments the ATM proponents used in their day: you need a short header to do fast lookups, and "fast IP routers cannot be built". History since then has at least told me that this was not entirely accurate. Therefore, I tend to view the above justification and limits with a healthy dose of scepticism. Regards, - H?vard From filiz at ripe.net Wed Jun 23 16:25:26 2004 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 23 Jun 2004 16:25:26 +0200 Subject: [address-policy-wg] IPv6 Policy - Initial Allocation Criteria in other regions Message-ID: <20040623142526.GS17294@x13.ripe.net> Dear Colleagues, As requested by the working group, please find below a summary of the variations in the Initial Allocation Criteria for IPv6 Policy from each of the other regions. For all regions, the following criteria apply: a) Requester must be an LIR b) Requester must not be an end site The other criteria vary. They are summarised below by region: ARIN region: Requesters must: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; d) have a plan for making at least 200 /48 assignments to other organisations within two years. There is a policy proposal in last call review currently which states: - to change the timeframe above in 'd)' from "two years" to "five years" and - to have 'd)' prepended "be an existing, known ISP in the ARIN region or..." (http://www.arin.net/policy/2003_4.html) APNIC region: Requesters must: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; d) have a plan for making at least 200 /48 assignments to other organisations within two years. In addition, APNIC will make allocations to closed networks if they meet all other criteria. LACNIC region: Requesters must: c) document a detailed plan for the services and IPv6 connectivity to be offered to other organisations (clients); d) announce a single block in the Internet inter-domain routing system, aggregating the total IPv6 address allocation received, within a period not longer than 12 months; e) offer IPv6 services to clients physically located within the region covered by LACNIC within a period not longer than 24 months. Regarding your comments on the RIR Comparative Policy Overview document, http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.html I realise that it is currently out of date. This document is currently being reviewed. I expect the document to be published in July. It will include the above points along with any other policy related matters. Kind regards, -- Filiz Yilmaz RIPE NCC From mohta at necom830.hpcl.titech.ac.jp Wed Jun 23 23:15:41 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 24 Jun 2004 06:15:41 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt In-Reply-To: <20040623.162229.70984010.he@uninett.no> References: <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D888A1.7070901@necom830.hpcl.titech.ac.jp> <20040623.162229.70984010.he@uninett.no> Message-ID: <40D9F2FD.8070004@necom830.hpcl.titech.ac.jp> Havard Eidnes wrote: Thank you for good examples. >>>Something that right now confuses *me* is: If I understand this >>>correctly, the 'default-free zone' is meant to be kept below 1000 >>>routes, so routers can be fast. >> >>The hard limit is, IMO, 8192. > Past history has told us that at least some technologists have > failed miserably in predicting whether fast routers can be built > which handle largish routing tables. And, I happened to be a technologist who know how to build a fast (Pbps or more) router even before no one have the needs. So, the only problem on fast routers is their prices. Limiting the number of global routing table entries helps a lot. With no loops in the forwarding path of routers, the limiting factor is latency of routing table look up. While parallelism is a solution, it does not reduce the routing table size. So, to reduce the prices of routers, it is better to reduce the routing table size. Their are poeple who use science to prove that it is impossible to make flying machines. Their are people who use science to make flying machines more efficient and less expensive. > If I recall correctly, an argument similar to the above one was > one of the arguments the ATM proponents used in their day: you > need a short header to do fast lookups, and "fast IP routers > cannot be built". History since then has at least told me that > this was not entirely accurate. At that days, my theory explained why ATM is about 10 times slower than IP. The theory is simply that, given 28 bit address with hierarchy (VPI/VCI or more), it is almost as complex as processing 32 bit IP. So, it takes about 10 times more amount of work to process 48B chunks than 500B-in-average chunks. Of course, there are other factors obscuring the essential difference. > Therefore, I tend to view the above justification and limits with > a healthy dose of scepticism. So, you can still insist that my theory is incorrect and ATM is 8192 or more times faster than IP, while I can keep saying ATM is about 10 times slower than IP with reasons. I can also say 8192 is large enough for the number of global routing table entries with reasons. You can alsy say IPv6 is no good because 128 bit address is not long enough. But, it's your limitation, not mine. Masataka Ohta PS Note that there are people who analize that large routing table increases the time for BGP convergence. From mohta at necom830.hpcl.titech.ac.jp Thu Jun 24 08:17:14 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 24 Jun 2004 15:17:14 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <20040623111754.GO6204@Space.Net> References: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D9638A.7040105@necom830.hpcl.titech.ac.jp> <20040623111754.GO6204@Space.Net> Message-ID: <40DA71EA.1050500@necom830.hpcl.titech.ac.jp> Gert Doering; >>With your fallacy denied, why do you replay the well known >>fallacy of NAT that NAT is transparent to the upper layers? > Please STOP cc: ing the address-policy working group on e-mails that > are purely about protocol design decisions and problems. It is not protocol design decision but is information that Kurt want multi6 not solve the multihoming problem. I stated it with a well known reason that intermediate entities such as layer 3.5 and NAT which perform address rewriting can not be transparent. > Your opinions about the address policy are known by now, and these > e-mails do not contribute further to the discussion at hand. The point of my post is that 8192 is large enough as the global routing table size, which is mostly orthogonal to multi6 issues (except that failure of multi6 bloat the routing table size indefinitely large). One important factor not explained yet very well is that BGP converges slowly as the number of ASes increases, which is another reason to limit the global routing table size. Masataka Ohta From poty at iiat.ru Thu Jun 24 08:34:40 2004 From: poty at iiat.ru (Potapov Vladislav) Date: Thu, 24 Jun 2004 10:34:40 +0400 Subject: [address-policy-wg] Re: Fallacy by Kurt Message-ID: >And, I happened to be a technologist who know how to build a >fast (Pbps or more) router even before no one have the needs. >So, the only problem on fast routers is their prices. >Limiting the number of global routing table entries helps a lot. Dear Masataka, It may help to optimize only ONE and not very IMPORTANT part of the router. You knew how to build fast (in mean of PPS OR MORE) routers, but didn't say about importance of the routing table. Please, give me an example of multigigabit routers without support of large routing table (or even switches, which don't have any routing table at all) which is cheaper than Cisco 2511 or so? The price of the multigigabit-per-second routers is high itself and not because of need to support routing tables. Please DO NOT turn fact. >So, you can still insist that my theory is incorrect and ATM is >8192 or more times faster than IP, while I can keep saying ATM >is about 10 times slower than IP with reasons. It seems that you have only your old theories in mind. Your previous heroic prophecies maid be right but it doesn't prove that your current prophecy is right, just because it IS prophecy without ANY facts in mind. Vladislav Potapov From jorgen at hovland.cx Thu Jun 24 12:46:57 2004 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 24 Jun 2004 11:46:57 +0100 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D9638A.7040105@necom830.hpcl.titech.ac.jp> <20040623111754.GO6204@Space.Net> <40DA71EA.1050500@necom830.hpcl.titech.ac.jp> Message-ID: <002501c459d8$92c616c0$0400000a@jorgen> ----- Original Message ----- From: "Masataka Ohta" Sent: Thursday, June 24, 2004 7:17 AM > Gert Doering; > > >>With your fallacy denied, why do you replay the well known > >>fallacy of NAT that NAT is transparent to the upper layers? > > > Please STOP cc: ing the address-policy working group on e-mails that > > are purely about protocol design decisions and problems. > > It is not protocol design decision but is information that > Kurt want multi6 not solve the multihoming problem. > > I stated it with a well known reason that intermediate entities > such as layer 3.5 and NAT which perform address rewriting can > not be transparent. > > > Your opinions about the address policy are known by now, and these > > e-mails do not contribute further to the discussion at hand. > > The point of my post is that 8192 is large enough as the > global routing table size, which is mostly orthogonal to > multi6 issues (except that failure of multi6 bloat the routing > table size indefinitely large). > > One important factor not explained yet very well is that BGP > converges slowly as the number of ASes increases, which is > another reason to limit the global routing table size. > You can try but you can't stop the evolution(tm). A number like that or any other number will be just as "fatal" like the 640kb problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and should be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of them could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR. If a LIR is multihomed they should be allocated a prefix. If not then people will stick to IPv4 until we really run out of ip's and keep sticking to it. Then we would have major problems deprecating IPv4. PI allocations doesn't exist anymore with IPv6 so that problem is solved..? Joergen Hovland From mohta at necom830.hpcl.titech.ac.jp Thu Jun 24 15:56:53 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 24 Jun 2004 22:56:53 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <002501c459d8$92c616c0$0400000a@jorgen> References: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D9638A.7040105@necom830.hpcl.titech.ac.jp> <20040623111754.GO6204@Space.Net> <40DA71EA.1050500@necom830.hpcl.titech.ac.jp> <002501c459d8$92c616c0$0400000a@jorgen> Message-ID: <40DADDA5.8050604@necom830.hpcl.titech.ac.jp> Joergen Hovland; First of all, if you insist writing your name beyond ASCII, that's fine if it is common local practice within your country. However, you should accept the fact that your international mail is often treated as SPAM. >>One important factor not explained yet very well is that BGP >>converges slowly as the number of ASes increases, which is >>another reason to limit the global routing table size. > You can try but you can't stop the evolution(tm). I don't. > A number like that or any other number will be just as "fatal" like the 640kb Who said 8192 of the global routing table size fatal? It, of course, is doable, as exemplified by the current reality with >100K. > problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and should > be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of them > could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR. Wrong. It does impose unnecessary restriction on mergers of LIRs. > If a > LIR is multihomed they should be allocated a prefix. If the LIR covers large enough (a lot lot larger than 200), yes of course. > If not then people will stick to IPv4 until we really run out of ip's and keep > sticking to it. Sure. It is exactly why I suggest giving v4 blocks to ISPs, only when the ISPs publicly announce that they will fully support v6 shortly , which was presented several years ago at Amsterdam RIPE meeting. At that time, many expected, without technical reasons, that IPv6 will prevail. > Then we would have major problems deprecating IPv4. PI allocations doesn't > exist anymore with IPv6 so that problem is solved..? The only technical way to deprecate v4 is to exhaust the v4 address space. It should be noted that NAT delayed the exhaustion and delayed v6 deployment. It should also be noted that it was good because v6 is still faulty not to be deployed widely. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Jun 24 16:06:27 2004 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 24 Jun 2004 23:06:27 +0900 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") In-Reply-To: <40D96AFD.991B5206@ix.netcom.com> References: <200406191307.26836.ripe-lst@eirconnect.net> <20040621162012.GD6204@Space.Net> <200406211820.15292.ripe-lst@eirconnect.net> <20040621173141.GH6204@Space.Net> <3717B75A-C40F-11D8-BBBB-000A95928574@kurtis.pp.se> <40D8185A.7030900@necom830.hpcl.titech.ac.jp> <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D849E2.6010105@necom830.hpcl.titech.ac.jp> <40D96AFD.991B5206@ix.netcom.com> Message-ID: <40DADFE3.30004@necom830.hpcl.titech.ac.jp> Jeff Williams wrote: > Open to some does not mean "all the way open" to others. So restrictions > for the sake of how far "Open" discussion is, is dependent sometimes on > whom is discussing what aspect of relevant issues on a topic area... So true. > That said, I liked your draft. I still must study it more however. Thank you. However, such statement without technical reasoning is no better than the emotional postings by Brian Carpenter. So, let's have discussions on technical points with verifiable reasons. Note, for example, that I oppose any proposal trying to import *THE* swamp of v4. Masataka Ohta From jorgen at hovland.cx Thu Jun 24 17:10:22 2004 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Thu, 24 Jun 2004 16:10:22 +0100 Subject: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") References: <40D82BE0.90404@necom830.hpcl.titech.ac.jp> <0B9FE26D-C44E-11D8-860C-000A95928574@kurtis.pp.se> <40D83B58.90906@necom830.hpcl.titech.ac.jp> <73777057-C456-11D8-860C-000A95928574@kurtis.pp.se> <40D84781.8020604@necom830.hpcl.titech.ac.jp> <2A874E04-C466-11D8-860C-000A95928574@kurtis.pp.se> <20040622185835.GC6204@Space.Net> <40D9638A.7040105@necom830.hpcl.titech.ac.jp> <20040623111754.GO6204@Space.Net> <40DA71EA.1050500@necom830.hpcl.titech.ac.jp> <002501c459d8$92c616c0$0400000a@jorgen> <40DADDA5.8050604@necom830.hpcl.titech.ac.jp> Message-ID: <014f01c459fd$5f1312e0$0400000a@jorgen> ----- Original Message ----- From: "Masataka Ohta" Sent: Thursday, June 24, 2004 2:56 PM Subject: Re: [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)") > Joergen Hovland; > >First of all, if you insist writing your name beyond ASCII, >that's fine if it is common local practice within your >country. However, you should accept the fact that your >international mail is often treated as SPAM. ?????? ?????? (test) > > >>One important factor not explained yet very well is that BGP > >>converges slowly as the number of ASes increases, which is > >>another reason to limit the global routing table size. > > Who said 8192 of the global routing table size fatal? There are N amount of LIR's and other companies in the need of prefixes. Any limit below N is not going to work. Since N is a dynamic variable it can not be permanently set. > > It, of course, is doable, as exemplified by the current reality with > >100K. > > > problem was in the 80's in the long run. The problem with the current IPv6 specification as I see it is purely technical and should > > be dealt with by the vendors making the IP routers. There is more than one way to implement routing algorithms, and several of them > > could equally give the best performance. Of course it would help if the RIR's tried not to hand out more than 1 prefix per LIR. > > Wrong. It does impose unnecessary restriction on mergers of LIRs. I said only to try, not to demand. Unnecessary fragmentation should always be avoided. > > > If a > > LIR is multihomed they should be allocated a prefix. > > If the LIR covers large enough (a lot lot larger than 200), yes > of course. I meant if the LIR was multihomed, period. You can't deny v4 LIR's a v6 prefix if you want v6 to be deployed in this century. Isn't the only reason why v6 policies are so strict compared to v4 today due to the socalled multi-homing problem? Are we afraid of that we won't be able to develop better hardware/software that can support even larger routingtables tomorrow ? > > Then we would have major problems deprecating IPv4. PI allocations doesn't > > exist anymore with IPv6 so that problem is solved..? > > The only technical way to deprecate v4 is to exhaust the v4 address > space. > You are probably correct. But if the same restrictive v6 policies exist when v4 is exhausted people might start to pay good money (like a blackmarket) for v4 multihomed capable prefixes since they can't get multihomed capable v6 prefixes. Then v4 and v6 will together live for ever. Joergen Hovland From gert at space.net Thu Jun 24 21:52:05 2004 From: gert at space.net (Gert Doering) Date: Thu, 24 Jun 2004 21:52:05 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040614103640.491b4038.laura@ripe.net> References: <20040614103640.491b4038.laura@ripe.net> Message-ID: <20040624195205.GD67702@Space.Net> Hi, SUMMARY of the IPv6 working group thread "Re: IPv6 Policy Clarification - Initial allocation criteria "d)" The discussion started with a request for clarification from the RIPE NCC hostmasters about the "200 /48 assignments to other organization" rule. At first, people discussed various interpretations of this: - whether or not "infrastructure /48s" count towards the 200 number (no clear statement what really was intended, as it didn't originally come from the RIPE region, and people have very different opinions on what it should be) - whether or not ISPs assigning only /64s (3GPP networks) qualify (most people seem to agree that those qualify, but per the letter, they don't. Some comments are confused why someone would assign /64s at all, but that's what the 3GPP standard recommends) In the course of the discussion, one major point emerged: - please *change* the policy and remove the "200 assignments" clause (and leave the remaining criteria mostly unchanged, that is, the applicant still has to be a LIR). there have been many voices supporting this change, and only one voice vehemently argueing against it. Masaka Ohta urges us to rework the whole system to make sure that at maximum 1000 routes appear in the global table. To base the WGs decision on more facts, the RIPE NCC has been asked to provide an overview about the current IPv6 policy (proposals) in the other regions. Filiz from the NCC has done this yesterday (thanks). There have been a couple of sidetrack discussions without specific results: - whether the "one size fits all" (/32) model for sizing the LIR allocations is a good way to tackle things, or whether it's repeating the "class A allocation" error. - whether or not using "more specific PA space" from one upstream ISP is a valid way to do BGP multihoming, at least for some networks - whether or not the price of a >10Gbit router is significantly changed if the number of routes it must carry is hard capped to 1000 (or 8192). (Oliver Bartels has sent me some more supporting documents. His claim is that a TCAM memory based hardware forwarding engine can handle at least 65k IPv6 prefixes at >10Gbit/s with a $150 US$ TCAM per line card. Going to a $350 US$ TCAM per line card enables >130k prefixes. Comparing that to the cost of 10Gbit/s. optics, SDH framing chips, and hardware development effort, that's a only a minor part of the total costs. For lower bandwidth, todays algorithms don't even need TCAM, SRAM is enough. Details upon request) - a very vehement discussion concerning a specific IETF multi6 proposal which may or may not have been judged fairly by the multi6 working group. Kurtis Lindqvist moved *that* subthread to the IETF list, and volunteered to give updates about multi6 progress to the APWG list. - at least two persons voiced very clearly that they are convinced IPv6 deployment will not go ahead unless companies that have their own IPv4 address space today will be able to reach that amount of independence and flexibility with IPv6 as well. Read: get "IPv6 PI" address space (or qualify for a LIR allocation, which is effectively the same). This latter part worries me. Judging from the discussion, and "counting voices", I propose to proceed as follows: - study the "other regions policy" report from the RIPE NCC - try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder. - circulate that proposal, present it at RIPE49, and if there is consensus, integrate it into the official RIPE policy. I don't think that we will be able to find consensus for "let's start handing out PI address space". But if one of the proponents wants to try to propose a policy that will permit "special networks" to receive a portable allocation without widely opening the flood gates (there *is* consensus that "everybody can get their own block and carry it around" is *not* what will scale), please go ahead and do so. Please do it in a new thread, though. Gert Doering -- APWG Co-Chair -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 24 21:54:13 2004 From: gert at space.net (Gert Doering) Date: Thu, 24 Jun 2004 21:54:13 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <462601c456b6$74203180$8700000a@consulintel.es> References: <20040614103640.491b4038.laura@ripe.net> <462601c456b6$74203180$8700000a@consulintel.es> Message-ID: <20040624195413.GE67702@Space.Net> Hi, On Sun, Jun 20, 2004 at 01:05:09PM +0200, JORDI PALET MARTINEZ wrote: > 5) And even much further, should be mandatory for the ISPs, in a time frame of for example 5 years, to provide IPv6 services IF they want to keep their IPv4 allocations ? No. It's not the address policy's job to force market developments (it's worse enough already with the effects our policy has, but we should not do that on purpose). Our job is to make sure that numbers that must be globally unique are distributed in a fair and balanced way. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 24 22:11:47 2004 From: gert at space.net (Gert Doering) Date: Thu, 24 Jun 2004 22:11:47 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <20040615173628.0363a350.laura@ripe.net> References: <20040615173628.0363a350.laura@ripe.net> Message-ID: <20040624201147.GF67702@Space.Net> Hi, on your other wish for clarification: On Tue, Jun 15, 2004 at 05:36:28PM +0200, Laura Cobley wrote: > "To qualify for an initial allocation of IPv6 address space, an > organisation must [...] plan to provide IPv6 connectivity to > organisations to which it will assign /48s by advertising that > connectivity through its single aggregated address allocation" > > LIRs who operate closed/private networks appear not to qualify because > the address space in these networks will not be advertised. Was this the > community's intention? At the time this was written, "site-local" addresses where considered as the solution for these networks. Since then, they have mostly been deprecated, but a new solution (draft-ietf-ipv6-unique-local-addr-04.txt) seems to be in sight. I've seem some comments to the extent of "we must be very liberal here". The more interesting question is: does it make any difference? Of course there are large numbers of enterprises that operate closed networks, but does anyone have numbers about the number of *LIRs* that purposely and permanently do not connect their PA-allocated network blocks to "the Internet", while still paying yearly RIR membership fees? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nils at druecke.strg-alt-entf.org Thu Jun 24 23:31:20 2004 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Thu, 24 Jun 2004 17:31:20 -0400 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <20040624201147.GF67702@Space.Net> References: <20040615173628.0363a350.laura@ripe.net> <20040624201147.GF67702@Space.Net> Message-ID: <20040624213120.GA8190@bug> On Thu, Jun 24, 2004 at 10:11:47PM +0200, Gert Doering wrote: > > LIRs who operate closed/private networks appear not to qualify because > > the address space in these networks will not be advertised. Was this the > > community's intention? > At the time this was written, "site-local" addresses where considered > as the solution for these networks. Since then, they have mostly been > deprecated, but a new solution (draft-ietf-ipv6-unique-local-addr-04.txt) > seems to be in sight. Which is a good thing. Site-local would bring up the same problems, RfC1918 space did (to organisations connecting to each other, both using 10/8 => Double NAT). With globally unique local addresses this would be solved. I just did a quick read of the document (did not have the time for slow reading), but I think the most interesting question still open is "how do I get my globally unique local address prefix". But that concept would sort out a lot of the existing problems we have with IPv4 today. > Of course there are large numbers of enterprises that operate closed > networks, but does anyone have numbers about the number of *LIRs* that > purposely and permanently do not connect their PA-allocated network blocks > to "the Internet", while still paying yearly RIR membership fees? I do not have real numbers, but know a few providers doing that. When they manage their customers networks, they use globally unique addresses for that. Currently this can only be done with IPv4 PA/PI space, as RfC1918 addresses are not unique. So they use addresses out of their assignment to have guaranteed uniqueness. Also I know of some of the big customers of ours doing it. Reality is though, mostly they assign the complete block and then just nullroute it, if traffic comes from the outside, as I think of it. So the block is is announced, but not reachable, though not "connected to the internet". But if globally unique local addresses (can I get an acronym for that, that is way too long ... and GULA even sounds nice) become reality this would be an alternative, as uniqueness seems to be the only reason for using these addresses. Nils -- Sch?tzt ungeborenes Leben -- esst weniger Obst From nils at druecke.strg-alt-entf.org Thu Jun 24 23:35:03 2004 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Thu, 24 Jun 2004 17:35:03 -0400 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "c)" In-Reply-To: <20040624213120.GA8190@bug> References: <20040615173628.0363a350.laura@ripe.net> <20040624201147.GF67702@Space.Net> <20040624213120.GA8190@bug> Message-ID: <20040624213503.GA8341@bug> On Thu, Jun 24, 2004 at 05:31:20PM -0400, Nils Ketelsen wrote: > Reality is though, mostly they assign the complete block and then just ^^^^^^ This should read "announce" Nils -- "Kommt Schrot kommt Not" [Torfrock in dem epochalen Werk 'Wildsau'] From pekkas at netcore.fi Fri Jun 25 07:36:52 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 25 Jun 2004 08:36:52 +0300 (EEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040624195205.GD67702@Space.Net> Message-ID: On Thu, 24 Jun 2004, Gert Doering wrote: > - try to come up with new rules for the allocation criteria, dropping > the 200-assignments part, and integrate whatever is necessary to > balance the remainder. Wasn't pretty much all of this (except one comment) based on the misconception that you'd actually have to have 200 IPv6 customers, not that you would have *potential* IPv6 customers (i.e: v4 customers, and you willing to give them service)? So I don't think there was such a strong need for removeing the rule, just if we clarified it sufficiently so that people would not (again!) interpret it too strongly. -- 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 jordi.palet at consulintel.es Fri Jun 25 08:32:31 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 25 Jun 2004 08:32:31 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: Message-ID: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> Hi Pekka, Sorry, but I can't agree with this. I provided the example of small ISPs, that have less than 200 customers for IPv4. So are we limiting those small ISPs (that may have a complete own infrastructure, even international peerings/links, etc.) and their customers from using IPv6 ? Some of this small ISPs survive because they provide service to a reduced set of companies, but BIG companies ... So the size of the ISP doesn't mean necessarily that the addressing space they may need is not big ! Just look to other RIRs ... Regards, Jordi ----- Original Message ----- From: "Pekka Savola" To: "Gert Doering" Cc: "Laura Cobley" ; Sent: Friday, June 25, 2004 7:36 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > On Thu, 24 Jun 2004, Gert Doering wrote: > > - try to come up with new rules for the allocation criteria, dropping > > the 200-assignments part, and integrate whatever is necessary to > > balance the remainder. > > Wasn't pretty much all of this (except one comment) based on the > misconception that you'd actually have to have 200 IPv6 customers, not > that you would have *potential* IPv6 customers (i.e: v4 customers, and > you willing to give them service)? > > So I don't think there was such a strong need for removeing the rule, > just if we clarified it sufficiently so that people would not (again!) > interpret it too strongly. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From oliver at bartels.de Fri Jun 25 09:23:26 2004 From: oliver at bartels.de (Oliver Bartels) Date: Fri, 25 Jun 2004 09:23:26 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: Message-ID: <200406250722.i5P7Mdtt002867@alpha.bartels.de> On Fri, 25 Jun 2004 08:36:52 +0300 (EEST), Pekka Savola wrote: >So I don't think there was such a strong need for removeing the rule, >just if we clarified it sufficiently so that people would not (again!) >interpret it too strongly. You might think so, but I have the impression that the community thinks different. The point is : We want to push IPv6 forward. Here is the choice: - We insist on a strict 200 customers rule: IPv6 *will* die. Period. Because larger companies tend to use special business ISP's with often have less than 200 customers, *but* the service of these customers probably is important to the internet users. And to show the complete nonsense of the /48 rule: This will either even exclude companies like AOL or T-Online from IPv6 if they do not intend to assign /48's to their *residential* customers, or will force them to do so, which sooner or later again means: New prefix, full table, game over. - We "would not (again!) interpret it too strongly": Then this rule is worth nothing. A rule which should be interpreted in this way enforces that every applicant sends a "plan" like: "Of course *we want* to get zillions of IPv6 customers and became the one and only monopoly provider and thus 200 users is peanuts for us". A rule which should be interpreted this way is not worth the paper or disk space it is written on, even thru this is the current handling of the rule. We should prevent to waste the capacity of the RIPE NCC and limited time of their hostmasters to read such useless "plans" and then better completely remove the rule. And at the end this means: As it is ignored in practice, LIR will become the synonym for PI, which is *not* what was intended. - We look at the intention of the rule and modify the wording in a useful way to keep cover on the PI pot until a technical solution to the global table explosion problem is provided in some way, but to provide full level IPv6 to all customer servicing true ISP's (where ISP means: companies that sell connectivity to other non-affiliated customers) wanting to push IPv6 forward. I am a friend of "open words": I can not hide my impression that there are massive commercial interests of some large players to implement a market-prohibitive rule because their management *thinks* they will gain additional business customers from it. Some "technical" arguments are then used to support this interest. However, please here my words: Those managers *won't get* additional customers, however they *will* damage IPv6. For sure. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From gert at space.net Fri Jun 25 09:57:19 2004 From: gert at space.net (Gert Doering) Date: Fri, 25 Jun 2004 09:57:19 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: References: <20040624195205.GD67702@Space.Net> Message-ID: <20040625075718.GH67702@Space.Net> Hi, On Fri, Jun 25, 2004 at 08:36:52AM +0300, Pekka Savola wrote: > On Thu, 24 Jun 2004, Gert Doering wrote: > > - try to come up with new rules for the allocation criteria, dropping > > the 200-assignments part, and integrate whatever is necessary to > > balance the remainder. > > Wasn't pretty much all of this (except one comment) based on the > misconception that you'd actually have to have 200 IPv6 customers, not > that you would have *potential* IPv6 customers (i.e: v4 customers, and > you willing to give them service)? Actually, since the current policy is in effect, this was the main sore spot about it. People being scared away due to misinterpretation, people complaining about the "restrictive policy", and so on. Nobody (from the RIPE region) ever spoke in favour of it, as far as I can remember... > So I don't think there was such a strong need for removeing the rule, > just if we clarified it sufficiently so that people would not (again!) > interpret it too strongly. We would definitely need to clarify it "very much so". Even then, I'm not sure what good it does - a "normal" LIR that's serious about it will be able to come up with 200 prospective customers (if only by creative definitions of "end site"). The really problematic cases, like "big transport provider, most customers bring their own address space anyway, so few (if any) direct assignments" would still remain (NORDUnet comes to mind). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 25 09:59:27 2004 From: gert at space.net (Gert Doering) Date: Fri, 25 Jun 2004 09:59:27 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> References: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> Message-ID: <20040625075927.GI67702@Space.Net> Hi, On Fri, Jun 25, 2004 at 08:32:31AM +0200, JORDI PALET MARTINEZ wrote: > Some of this small ISPs survive because they provide service to a reduced set of companies, but BIG companies ... So the size of the ISP doesn't mean necessarily that the addressing space they may need is not big ! Customer size is a non-argument for v6. 5 BIG COMPANIES will receive the same 5 /48s as 5 small dsl customers. (Now if you offer dial-up services for all employees of 5 BIG COMPANIES, you'll reach 200 end site assignments very quickly - so, again, no problem with the 200-user rule here). But I think the whole point of the discussion is that the rule is pretty pointless. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 25 10:01:58 2004 From: gert at space.net (Gert Doering) Date: Fri, 25 Jun 2004 10:01:58 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406250722.i5P7Mdtt002867@alpha.bartels.de> References: <200406250722.i5P7Mdtt002867@alpha.bartels.de> Message-ID: <20040625080158.GJ67702@Space.Net> Hi, On Fri, Jun 25, 2004 at 09:23:26AM +0200, Oliver Bartels wrote: > And to show the complete nonsense of the /48 rule: > This will either even exclude companies like AOL or T-Online > from IPv6 if they do not intend to assign /48's to their > *residential* customers, or will force them to do so, which > sooner or later again means: > New prefix, full table, game over. This argument doesn't hold. Look at Telia - they got a /20. That's enough address space for at least 5 million /48s. Nothing precludes AOL or T-Online from applying for a /18, or even more, based on their customer numbers. (Also, if "every ISP that is able to fill a /20" will insert a 2nd or 3rd prefix into the global table, it definitely won't kill any router) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jon at lawrence.org.uk Fri Jun 25 12:55:57 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Fri, 25 Jun 2004 11:55:57 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040625075927.GI67702@Space.Net> References: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> <20040625075927.GI67702@Space.Net> Message-ID: <200406251155.57643.jon@lawrence.org.uk> On Friday 25 June 2004 08:59, Gert Doering wrote: > > But I think the whole point of the discussion is that the rule is pretty > pointless. > I agree. Saying that we *plan* to make IPv6 available to 200 end sites within 2 years is pretty easy. The fact that we currently have no where near 200 end sites could be viewed as irrelevant as far as planniing is concerned. This in my view makes a joke of the rule. Even a brand new LIR with only half a dozen end sites at present could easily present a case for *planning* to have 200 over the next 2 years. It was suggested that if you don't/can't reach the 200 rule then you should take address space from your upstream. How many datacenters are going to be willing to do that. We'd like to be able to start offering IPv6 services for our datacenter, there's no way we're going to take a single upstream. A datacenter needs to be multihomed with different providers (at least in my opinion). I suppose I could assign a /48 to each customer in the datacenter (to reach the magic 200) but most customers have only *one* server, so that would be a big waste of space. Instead I'd simply assign a single /48 to the datacenter and that would be aggregated by us on our multiple links, but by doing this we'd never reach 200 end sites. I personally think we should get rid of the 200 rule completely. Saying something along the lines of: An LIR should provide IPv6 services (to end user sites) and advertise an aggregated route within 12 months of receiving the allocation. Regards, Jon From cfriacas at fccn.pt Fri Jun 25 13:08:45 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 25 Jun 2004 12:08:45 +0100 (WEST) Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406251155.57643.jon@lawrence.org.uk> References: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> <20040625075927.GI67702@Space.Net> <200406251155.57643.jon@lawrence.org.uk> Message-ID: On Fri, 25 Jun 2004, Jon Lawrence wrote: > On Friday 25 June 2004 08:59, Gert Doering wrote: > > > > But I think the whole point of the discussion is that the rule is pretty > > pointless. > > > I agree. > Saying that we *plan* to make IPv6 available to 200 end sites within 2 years > is pretty easy. The fact that we currently have no where near 200 end sites > could be viewed as irrelevant as far as planniing is concerned. > This in my view makes a joke of the rule. Even a brand new LIR with only half > a dozen end sites at present could easily present a case for *planning* to > have 200 over the next 2 years. > > It was suggested that if you don't/can't reach the 200 rule then you should > take address space from your upstream. How many datacenters are going to be > willing to do that. We'd like to be able to start offering IPv6 services for > our datacenter, there's no way we're going to take a single upstream. A > datacenter needs to be multihomed with different providers (at least in my > opinion). I suppose I could assign a /48 to each customer in the datacenter > (to reach the magic 200) but most customers have only *one* server, so that > would be a big waste of space. Instead I'd simply assign a single /48 to the > datacenter and that would be aggregated by us on our multiple links, but by > doing this we'd never reach 200 end sites. > > I personally think we should get rid of the 200 rule completely. > Saying something along the lines of: > An LIR should provide IPv6 services (to end user sites) and advertise an > aggregated route within 12 months of receiving the allocation. > > Regards, > Jon 1. repeating myself... "200 rule"... IMHO to dropped as soon as possible. 2. please drop the "conservation" thinggy... ~"big waste of space" one server means one LAN = /64, just like a p2p connection is also a LAN = /64. someone might disagree on this... ;-) if you have more than one LAN, that means a /48. if you have a customer with 2 servers, if they are on the same LAN, just put a /64 on top of the table. if he wants them separated (2 vlans), give him a /48 and simply route his 2 /64s. ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" From david.kessens at nokia.com Fri Jun 25 23:12:14 2004 From: david.kessens at nokia.com (David Kessens) Date: Fri, 25 Jun 2004 14:12:14 -0700 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040625075718.GH67702@Space.Net> References: <20040624195205.GD67702@Space.Net> <20040625075718.GH67702@Space.Net> Message-ID: <20040625211214.GK30006@nokia.com> Gert, On Fri, Jun 25, 2004 at 09:57:19AM +0200, Gert Doering wrote: > > Nobody (from the RIPE region) ever spoke in favour of it, as far as I > can remember... Actually ... It was a compromise between the different regions. As such, it worked just fine since we managed to get a policy in place that worked better than the one before. Times change though and it seems that nobody cares at all anymore about the fact that we are dealing here with global resource that has global impact and that should have a global policy. There is no point to keep adhering to global policy that is not in use anymore in any of the other regions. It is very sad, but it's the truth. > > So I don't think there was such a strong need for removeing the rule, > > just if we clarified it sufficiently so that people would not (again!) > > interpret it too strongly. > > We would definitely need to clarify it "very much so". This is not about clarifying. The policy is very clear: 'you need a plan to have 200 customers'. I cannot help it that people have trouble reading that. Getting rid of the requirement for 'a plan' or for '200 customers' is a 'policy change' not a 'clarification'. And policy changes should be discussed out in the open and not be sneaked in as if they are just a minor 'clarification'. David Kessens --- From jon at lawrence.org.uk Fri Jun 25 23:53:00 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Fri, 25 Jun 2004 22:53:00 +0100 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040625211214.GK30006@nokia.com> References: <20040624195205.GD67702@Space.Net> <20040625075718.GH67702@Space.Net> <20040625211214.GK30006@nokia.com> Message-ID: <200406252253.00965.jon@lawrence.org.uk> On Friday 25 June 2004 22:12, David Kessens wrote: > The policy is very clear: 'you need a plan to have 200 customers'. That's the whole point. The policy says *plan* to make 200 /48 assignments to other organisations within two years. What's the point in that ? anyone can *plan* to make 200 assignments. It seems to be a rule for the sake of having a rule - I'm sure there must have been good reasons for bringing it in, perhaps I just don't get it. e.g. An LIR gets an allocation by showing a plan to assign 200 /48's. But after 2 years they've only assigned 50. They would have obeyed the policy even though they failed to achieve the 200 assignments. This says to me that the 200 assignment rule is completely pointless. > Times change though and it seems that nobody cares at all anymore about the > fact that we are dealing here with global resource that has global impact > and that should have a global policy. Yes, it is a global resource and I agree that it should be used in accordance with some global policy. But that global policy has got to make sense, and I just can't see the sense in the 200 assignments rule. Jon From gert at space.net Sat Jun 26 00:08:52 2004 From: gert at space.net (Gert Doering) Date: Sat, 26 Jun 2004 00:08:52 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040625211214.GK30006@nokia.com> References: <20040624195205.GD67702@Space.Net> <20040625075718.GH67702@Space.Net> <20040625211214.GK30006@nokia.com> Message-ID: <20040625220852.GV67702@Space.Net> Hi, On Fri, Jun 25, 2004 at 02:12:14PM -0700, David Kessens wrote: > On Fri, Jun 25, 2004 at 09:57:19AM +0200, Gert Doering wrote: > > Nobody (from the RIPE region) ever spoke in favour of it, as far as I > > can remember... > > Actually ... It was a compromise between the different regions. Yes, I remember :-) - I just said "nobody from *us* direly wanted to see it there". Obviously someone from the other regions must have. > As > such, it worked just fine since we managed to get a policy in place > that worked better than the one before. Times change though and it > seems that nobody cares at all anymore about the fact that we are > dealing here with global resource that has global impact and that > should have a global policy. The differences in IPv4 policy are much more fundamental, and things are still running quite well. So minor differences in the v6 policy shouldn't do great harm. OTOH, a globally unique policy is nearly impossible to change (in any sort of reasonable timeframe) given the current RIR/LIR structures - as we can see here. These issues ("can we give an allocation to a 3GPP network? to a big transit provider with few direct customers?") are open issues since years now, and there doesn't seem to be any coordinated effort to change the global policy, or to integrate LACNICs local changes (if there *is* a global effort going on, it's hiding well, and I apologize for noticing it). [..] > > > So I don't think there was such a strong need for removeing the rule, > > > just if we clarified it sufficiently so that people would not (again!) > > > interpret it too strongly. > > > > We would definitely need to clarify it "very much so". > > This is not about clarifying. The policy is very clear: 'you need a > plan to have 200 customers'. "...in two years time". So what happens if you assume that it's unlikely that you'll reach that number (which would be "normal" for any network these days, unfortunately)? Do known-unrealistic plans count as well? Also it's not that clear that it have to be *customers* (what about LIRs that have only few direct re-selling ISP customers, but zillions of end sites connected to *them*?) or just "/48 assignments". What's a "site", by the way? > I cannot help it that people have trouble > reading that. Getting rid of the requirement for 'a plan' or for '200 > customers' is a 'policy change' not a 'clarification'. And policy > changes should be discussed out in the open and not be sneaked in as > if they are just a minor 'clarification'. Hmmm, you must have missed something in my summary e-mail :-) - let me repeat that part: --------- snip ---------- Judging from the discussion, and "counting voices", I propose to proceed as follows: - study the "other regions policy" report from the RIPE NCC - try to come up with new rules for the allocation criteria, dropping the 200-assignments part, and integrate whatever is necessary to balance the remainder. - circulate that proposal, present it at RIPE49, and if there is consensus, integrate it into the official RIPE policy. --------- snip ---------- I won't consider that "sneaking it in". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) 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 Jun 26 00:12:52 2004 From: gert at space.net (Gert Doering) Date: Sat, 26 Jun 2004 00:12:52 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406251155.57643.jon@lawrence.org.uk> References: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> <20040625075927.GI67702@Space.Net> <200406251155.57643.jon@lawrence.org.uk> Message-ID: <20040625221252.GW67702@Space.Net> Hi, On Fri, Jun 25, 2004 at 11:55:57AM +0100, Jon Lawrence wrote: > opinion). I suppose I could assign a /48 to each customer in the datacenter > (to reach the magic 200) but most customers have only *one* server, so that > would be a big waste of space. Actually, "waste of space" is a non-argument for IPv6-to-customer assignments - you have 65k /48s (at least), which should make for a fairly big datacenter. The policy says "every customer gets a /48", except in very specific circumstances. (By the way: we don't assign /48s to our *datacenter* customers either - every datacenter customer VLAN gets a /64, no matter if "one single machine" or "hundreds". As soon as the customer has "more infrastructure" behind his VLAN, or a separate internet access product, he'll get the /48, of course). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From david.kessens at nokia.com Sat Jun 26 00:27:36 2004 From: david.kessens at nokia.com (David Kessens) Date: Fri, 25 Jun 2004 15:27:36 -0700 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <200406252253.00965.jon@lawrence.org.uk> References: <20040624195205.GD67702@Space.Net> <20040625075718.GH67702@Space.Net> <20040625211214.GK30006@nokia.com> <200406252253.00965.jon@lawrence.org.uk> Message-ID: <20040625222736.GA15693@nokia.com> Jon, On Fri, Jun 25, 2004 at 10:53:00PM +0100, Jon Lawrence wrote: > On Friday 25 June 2004 22:12, David Kessens wrote: > > The policy is very clear: 'you need a plan to have 200 customers'. > > That's the whole point. The policy says *plan* to make 200 /48 assignments to > other organisations within two years. > What's the point in that ? anyone can *plan* to make 200 assignments. The point was to have a slight barrier to make sure that only people that had a serious intent to deploy ipv6 networks would apply for addresses. As such, it actually worked and it was not too big of a hurdle for people who wish to deploy ipv6 either, although admittedly, it should be noted that at least some people seem to have trouble understanding the difference between a 'plan' and actually having 200 customers. This was at the time a compromise between the different regions and the most liberal rule that was acceptable for all regions. The alternative was to keep the old policy and I am pretty sure that you would like that one even less. From that point of view, it made a lot of sense for the RIPE region to accept this rule because it was better then what we had before. Let's not waste any more time on the '200 customer' rule. The reasons for it's existence are not there anymore. I was just trying to give a bit of background information why this rule existe and what it was designed for. Now that the other regions seem to depart from this policy and apply policies that are more liberal but also divergent from each other, it seems that there is unfortunately no reason any longer to aim for a global policy. The regional registries seem to be unwilling to support a process where we started to develop such policies on a global level through a bottom-up process. We tried for the ipv6 policies with a global maillist and it failed. This is a serious problem inherent with the regional setup that just doesn't make a lot of sense for resources that need global management. One day this is going to cause interesting problems. The system as it is setup today is working as a never ending escalation of liberalizing the rules without any regard for the reality that all those prefixes are going to end up in one global routing table. David Kessens --- From jordi.palet at consulintel.es Sat Jun 26 00:40:39 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 26 Jun 2004 00:40:39 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" References: <20040624195205.GD67702@Space.Net> <20040625075718.GH67702@Space.Net> <20040625211214.GK30006@nokia.com> <200406252253.00965.jon@lawrence.org.uk> <20040625222736.GA15693@nokia.com> Message-ID: <32a301c45b05$715e5c30$640a0a0a@consulintel.es> Hi David, I'm very interested to heard about what "interesting problems" do you think the lack of a global policy will create. May be having those problems openly discussed could provide the required propeller in order to ensure a global coordination again. Regards, Jordi ----- Original Message ----- From: "David Kessens" To: "Jon Lawrence" Cc: Sent: Saturday, June 26, 2004 12:27 AM Subject: Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" > > Jon, > > On Fri, Jun 25, 2004 at 10:53:00PM +0100, Jon Lawrence wrote: > > On Friday 25 June 2004 22:12, David Kessens wrote: > > > The policy is very clear: 'you need a plan to have 200 customers'. > > > > That's the whole point. The policy says *plan* to make 200 /48 assignments to > > other organisations within two years. > > What's the point in that ? anyone can *plan* to make 200 assignments. > > The point was to have a slight barrier to make sure that only people > that had a serious intent to deploy ipv6 networks would apply for > addresses. As such, it actually worked and it was not too big of a > hurdle for people who wish to deploy ipv6 either, although admittedly, > it should be noted that at least some people seem to have trouble > understanding the difference between a 'plan' and actually having 200 > customers. > > This was at the time a compromise between the different regions and > the most liberal rule that was acceptable for all regions. The > alternative was to keep the old policy and I am pretty sure that you > would like that one even less. From that point of view, it made a lot > of sense for the RIPE region to accept this rule because it was better > then what we had before. > > Let's not waste any more time on the '200 customer' rule. The reasons > for it's existence are not there anymore. I was just trying to give a > bit of background information why this rule existe and what it was > designed for. > > Now that the other regions seem to depart from this policy and apply > policies that are more liberal but also divergent from each other, it > seems that there is unfortunately no reason any longer to aim for a > global policy. The regional registries seem to be unwilling to support > a process where we started to develop such policies on a global level > through a bottom-up process. We tried for the ipv6 policies with a > global maillist and it failed. This is a serious problem inherent with > the regional setup that just doesn't make a lot of sense for resources > that need global management. One day this is going to cause > interesting problems. The system as it is setup today is working as a > never ending escalation of liberalizing the rules without any regard > for the reality that all those prefixes are going to end up in one > global routing table. > > David Kessens > --- > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jeroen at unfix.org Sun Jun 27 15:01:24 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 27 Jun 2004 15:01:24 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040625221252.GW67702@Space.Net> References: <28c601c45a7e$31cffd30$640a0a0a@consulintel.es> <20040625075927.GI67702@Space.Net> <200406251155.57643.jon@lawrence.org.uk> <20040625221252.GW67702@Space.Net> Message-ID: <1088341283.32069.1932.camel@segesta.zurich.ibm.com> On Sat, 2004-06-26 at 00:12, Gert Doering wrote: > Hi, > > On Fri, Jun 25, 2004 at 11:55:57AM +0100, Jon Lawrence wrote: > > opinion). I suppose I could assign a /48 to each customer in the datacenter > > (to reach the magic 200) but most customers have only *one* server, so that > > would be a big waste of space. > > Actually, "waste of space" is a non-argument for IPv6-to-customer > assignments - you have 65k /48s (at least), which should make for a > fairly big datacenter. > > The policy says "every customer gets a /48", except in very specific > circumstances. > > (By the way: we don't assign /48s to our *datacenter* customers either - > every datacenter customer VLAN gets a /64, no matter if "one single > machine" or "hundreds". As soon as the customer has "more infrastructure" > behind his VLAN, or a separate internet access product, he'll get the /48, > of course). I usually like to think of it like: - a 'link', thus a network which is not routed gets a /64. - a routed network gets a /48. The first includes p2p _links_, tunnel _links_ etc. But also an IX with one shared medium counts as a link, even if there are 100.000 devices on that same link. When there is a router in the riddle, then give them a /48. Which is just like you mentioned with 'more infrastructure'. Greets. Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From mansaxel at sunet.se Tue Jun 29 16:10:52 2004 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Tue, 29 Jun 2004 16:10:52 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <16598.62725.814865.102505@roam.psg.com> References: <4CFE244C-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <20040617194736.GH6204@Space.Net> <16593.63897.529194.660823@ran.psg.com> <91FA5C31-C15B-11D8-BFCA-000A95928574@kurtis.pp.se> <5D038A9A6F934C1A9EA8668B@E3993D2B0BE66833664712A4> <16598.62725.814865.102505@roam.psg.com> Message-ID: <85113815F71F721B3D7854C4@E3993D2B0BE66833664712A4> --On m?ndag 21 juni 2004 10.47 -0400 Randy Bush wrote: >> OTOH, I'd hate to see the same mistakes (that seemed reasonable at the >> time) that were made in the v4 sunrise period be repeated in v6, like: >> >> * too small assignments for customers forcing NAT in use, > > v4 sunrise had too BIG, not too small, assignments. hence all the > underpopulated As abd Bs. it took a major war, cidrd, to fix that. I would argue, perhaps foolishly, that an assignment that is 1/4294967296 of the theoretical space available is sensible if done to any organisation large enough that it today, with the present routing infrastructure, is an autonomous system, and further, that this is much more sensible than the sunrise practice of handing out 1/65536 of the available space to just about anyone. (which *was* stupid, I agree, even though my present employer benefited greatly from this.) The practice is similar, yes, but the world surrounding it has changed. > and yes your point holds; we're doing it again. > those who forget history are condemned to repeat it. Yes, but if pain is to be avoided in some place, one must decide where to move it instead. As long as multi6 is working we need an interim solution. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 231 bytes Desc: not available URL: From mansaxel at sunet.se Tue Jun 29 21:45:21 2004 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Tue, 29 Jun 2004 21:45:21 +0200 Subject: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" In-Reply-To: <20040621234653.GB23267@nokia.com> References: <20040621234653.GB23267@nokia.com> Message-ID: <4EAF6614096BCAEC385C1A0C@E3993D2B0BE66833664712A4> --On m?ndag 21 juni 2004 16.46 -0700 David Kessens wrote: > I would like to ask the working group whether we can ask the RIPE NCC > to summarize the different changes made to the policy in the other > regions, so that we can have a discussion on which changes are > appropriate. Agree. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 231 bytes Desc: not available URL: From contact at ripe.net Wed Jun 30 14:56:40 2004 From: contact at ripe.net (Membership Liaison Officer) Date: Wed, 30 Jun 2004 14:56:40 +0200 Subject: [address-policy-wg] Reminder - RIPE NCC Regional Meeting, Nairobi, Kenya 28-30 July 2004 Message-ID: <5.2.1.1.2.20040630144635.029e5ea0@mailhost.ripe.net> [Apologies for duplicate emails] Dear Colleague, We would like to remind you that the RIPE NCC Regional Meeting in Nairobi will be held 28 - 30 July 2004 at the Norfolk Hotel, Nairobi, Kenya. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. Conference attendees will include RIPE NCC members, industry partners, government representatives and regulators with particular interest in wide area IP networking. If your organisation wishes to provide a presentation or suggest a relevant topic, or if you have any questions, please send an email to: REGISTRATION To register, please see: http://www.ripe.net/cgi-bin/nairobi-reg Please note that registration closes on 19 July 2004. AGENDA The Regional Meeting draft agenda has been updated and can be found at: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/agenda.html Agenda points and discussion topics include: * AfriNIC - The emerging RIR; * Peering and Exchange Points; * Are we running out of IPv4 address space?; * An update on IPv6; * The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; * How to participate in and influence IP address management policy-making; * Domain Name management on the Internet; * Root Server Operations. MORE INFORMATION More information about the RIPE NCC Regional Meeting, Nairobi is available from: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/index.html I trust you will find the discussions and tutorials on Internet Resource allocation and management relevant to your work. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC http://www.ripe.net From filiz at ripe.net Wed Jun 30 17:16:44 2004 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 30 Jun 2004 17:16:44 +0200 Subject: [address-policy-wg] New AS Number Block allocated to RIPE NCC Message-ID: <20040630151644.GR8989@x13.ripe.net> Dear Colleagues, The RIPE NCC received the AS Number Block 33792 - 34815 from the IANA in June 2004. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC