From marcelo at it.uc3m.es Fri Apr 1 11:51:35 2005 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Fri, 1 Apr 2005 11:51:35 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <424AFE5E.4070904@tiscali.no> References: <00A413E8.29BB620E.5@cc.univie.ac.at> <200503242047.12338.jon@lawrence.org.uk> <20050324215454.GA377@srv01.cluenet.de> <200503242341.18978.jon@lawrence.org.uk> <424AFE5E.4070904@tiscali.no> Message-ID: <60d1a7188495a62e2ca24e6f06acbd79@it.uc3m.es> Hi, El 30/03/2005, a las 21:30, Hans Petter Holen escribi?: > > > Jon Lawrence wrote: > >> >>> PI will come or IPv6 not fly. Face it. >>> >>> > I agree that IPv6 needs multi-homing to fly - but I was hoping there > would be other technical implementations of multi-homing than PI. > I do however undersand how multi-homing works with PI addresses - I am > not shure I can say the same of other proposals. > I think that it is important to distinguish between the different type of sites and their requirements. I mean i guess that there is a difference between the requirements of a big site with multiple locations over the globe and the requirements of a home network multihomed to the ADSL and cable providers. In addition, i guess that the expected number of multihomed home networks is quite higher than the expected number of really big multihomed sites. So we have that multihoming does not mean the same in the different scenarios. We have different requirements and different scalability requirements. I guess that is it important to find a solution for SOHO multihomed that does not impose additional routes in the global routing table, because of the expected number of such sites. Perhaps such solution will not provide all the benefits of current BGP based multihoming (like traffic engineering, provider independence and perhaps some other). However, it will probably will suit the needs of most SOHO multihomed networks. On the other hand, it is possible that certain mutlihomed sites (probably the big ones) won't find that this alternative solution will suit their needs. In this case, i guess that it is reasonable to assign PI to those. So, my take is that the path is to first understand what types of multihomed sites are well serve with an alternative multihoming solution (like the shim being deployed in the IETF) that does not impose additional burden in the inter domain routing. then understand what sites are not well served by this solution and really need BGP based multihoming. At this point i guess we could be ready to define a policy to assign PI addresses for this type of sites that really need it for multihoming. Regards, marcelo > -hph > From hpholen at tiscali.no Mon Apr 4 06:57:42 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 04 Apr 2005 06:57:42 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria Message-ID: <4250C946.5020502@tiscali.no> Dear all, Please find enclosed a policy proposal from Andy Furnell. My proposal is to enter this proposal into the Discussion Phase with a time line of 4 weeks ending on May 9the allowing the discusssion to continue over the RIPE meeting. 1. Number #gamma 2. Policy Proposal Name: IPv6 Initial Allocation Criteria 3. Author a. name: Andy Furnell b. e-mail: andy at linx.net c. telephone: +44 (0) 20 7645 3519 d. organisation: London Internet Exchange (LINX) 4. Proposal Version: 1 5. Submission Date: 4/4-2005 6. Suggested WG for discussion and publication: Address Policy WG 7. Proposal type: modify a. new, modify, or delete 8. Policy term: renewable a. temporary, permanent, or renewable. 9. Summary of proposal: The proposal is to change the IPv6 Initial Allocation criteria outlined in the "IPv6 Address Allocation and Assignment Policy" (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed change is to remove "have a plan for making at least 200 /48 assignments to other organisations within two years" and to remove the reference to "/48s" as the assignment size. 10. Policy text a. Current (if modify): 5.1.1. Initial allocation criteria 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 organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organisations within two years. b. New: 5.1.1. Initial allocation criteria 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 organisations and customers to which it will make assignments by advertising that connectivity through its single aggregated address allocation. 11. Rationale: a. Arguments supporting the proposal Many LIRs' networks do not have 200 customers to make assignments to but still maintain autonomous network and addressing policies. These require address space that is both aggregatable and independent from that of their peers. In addition, a /48 assignment is not always appropriate; ISPs might have different plans for the size of the assignments they will make and the policy should not stand as an obstacle for them. Such a change in the policy will also make IPv6 allocations more accessible and could result in the acceleration of IPv6 development. b. Arguments opposing the proposal With such a change in the policy, every LIR operating an autonomous network would be able to receive an IPv6 allocation. The worst case scenario would be a number of allocations equal to the number of LIRs in the RIPE region. --------------------------------------------------------------------------- From kelaidi at ote.gr Mon Apr 4 07:35:04 2005 From: kelaidi at ote.gr (Kelaidis Christine) Date: Mon, 4 Apr 2005 08:35:04 +0300 Subject: [address-policy-wg] HD ratio policy proposal Message-ID: <12CD8406D55B7C4185BF83C2C1D587F101382F51@MAILSRV.central-domain.root.ote.gr> My company believes that the proposal for the calculation of the HD ratio to measure IPv4 usage is a an improvement to the existing one and we would like to support this new policy proposal. Christine Kelaidis From jeroen at unfix.org Mon Apr 4 10:18:48 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Apr 2005 10:18:48 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <4250C946.5020502@tiscali.no> References: <4250C946.5020502@tiscali.no> Message-ID: <1112602728.22261.82.camel@firenze.zurich.ibm.com> On Mon, 2005-04-04 at 06:57 +0200, Hans Petter Holen wrote: > 11. Rationale: > a. Arguments supporting the proposal > Many LIRs' networks do not have 200 customers to make assignments > to but still maintain autonomous network and addressing policies. > These require address space that is both aggregatable and independent > from that of their peers. In addition, a /48 assignment is not > always appropriate; ISPs might have different plans for the size > of the assignments they will make and the policy should not stand > as an obstacle for them. Such a change in the policy will also make > IPv6 allocations more accessible and could result in the acceleration > of IPv6 development. The 200 thing can go indeed. The /48, which is the minimum assignment towards that endsite must stay. Otherwise there will be ISP's who are going to give out /56's, /58's, /60's, /62's etc. The reason for the _minimum_ of a /48 is that when you want to change over to another ISP that you can get the equally sized /48. Or do you want to get, say, 3 IPv6's IP's from your upstream ISP? If you are so extremely big that you need multiple /48's (which contain 65k /64's as you will know) you are also more than capable of getting your own TLA under the new proposed #gamma policy, and most people will most likely going to just that for a large amount of reasons, especially because they simply want 'an entry in the routing table'... 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 jordi.palet at consulintel.es Mon Apr 4 10:40:36 2005 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 04 Apr 2005 10:40:36 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <1112602728.22261.82.camel@firenze.zurich.ibm.com> Message-ID: Agree, let's go the 200 customers, but keep the /48. Otherwise in order to be coherent, lets change RFC3177 also (which I will not agree). Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: "address-policy-wg-admin at ripe.net" > > Fecha: Mon, 04 Apr 2005 10:18:48 +0200 > Para: Hans Petter Holen > CC: > Asunto: Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial > Allocation Criteria > > On Mon, 2005-04-04 at 06:57 +0200, Hans Petter Holen wrote: > > > >> 11. Rationale: >> a. Arguments supporting the proposal >> Many LIRs' networks do not have 200 customers to make assignments >> to but still maintain autonomous network and addressing policies. >> These require address space that is both aggregatable and independent >> from that of their peers. In addition, a /48 assignment is not >> always appropriate; ISPs might have different plans for the size >> of the assignments they will make and the policy should not stand >> as an obstacle for them. Such a change in the policy will also make >> IPv6 allocations more accessible and could result in the acceleration >> of IPv6 development. > > The 200 thing can go indeed. The /48, which is the minimum assignment > towards that endsite must stay. Otherwise there will be ISP's who are > going to give out /56's, /58's, /60's, /62's etc. > > The reason for the _minimum_ of a /48 is that when you want to change > over to another ISP that you can get the equally sized /48. > Or do you want to get, say, 3 IPv6's IP's from your upstream ISP? > > If you are so extremely big that you need multiple /48's (which contain > 65k /64's as you will know) you are also more than capable of getting > your own TLA under the new proposed #gamma policy, and most people will > most likely going to just that for a large amount of reasons, especially > because they simply want 'an entry in the routing table'... > > Greets, > Jeroen > From iljitsch at muada.com Mon Apr 4 10:48:53 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 4 Apr 2005 10:48:53 +0200 Subject: [address-policy-wg] Re: Geographical routing, was: Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: References: Message-ID: <885b941cf09000c778ce372d2cee8218@muada.com> On 31-mrt-05, at 16:20, Michael.Dillon at radianz.com wrote: >> If I've understood correctly, geographical addressing will lead >> to forced interconnection of providers in the geographical area This is a common misconception. Unfortunately, many people have assumptions about geography in routing based on mailing list discussions. > We have enough knowledge of intercontinental cable routes > today in order to design a geographical aggregation topology. > There are unlikely to be any significantly new intercontinental > or overland paths that could not be predicted based on today's > knowledge. It would make an interesting university research > project to design such an addressing topology and I hope that > someone will take up the challenge. Until we have this kind of > work on the table to discuss, it is hard to prove that geographic > addressing will work or that it won't work. I put a lot of effort into geographic addressing. Some of you may even remember that I talked about this at RIPE 44 and RIPE 46: once for the IPv6 wg, which was slightly perplexed, and then for the routing wg where I don't think anyone got it. It's a significant departure from business as usual, I'm afraid... Have a look at: http://www.bgpexpert.com/presentations/ http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt The interesting part here is that each AS gets to implement geographical aggregation completely independent from every other AS. This includes NOT aggregating, which means that there is absolutely NO difference between simply doing PI and following my proposal for anyone who chooses to carry all routes everywhere (except that the address space for multihomers must be allocated according to geography). There are no changes to BGP. The idea is that everyone announces their geographical customer routes everywhere, but people filter out the geographically undesirable routing information _within_ _their_ _own_ _AS_. So there is no dependency on free transit, and only a limited dependency on interconnection. When there is lack of interconnection in an area, this doesn't lead to lack of reachability, just to lack of aggregation. In the common case where a multihomer connects to two ISPs in the same area and both ISPs are well-connected in the area, there is potential for aggregation. In places where there are so many multihomers that the amount of routing information becomes problematic, there is bound to be reasonable interconnection, especially when looking at the continent or part-of-a-continent scale. From steffann at nederland.net Mon Apr 4 12:10:15 2005 From: steffann at nederland.net (Sander Steffann) Date: Mon, 4 Apr 2005 12:10:15 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <1112602728.22261.82.camel@firenze.zurich.ibm.com> Message-ID: <2B1A983EDCEC3447B22632B64F7264600B74AC@bill.office.computel.nl> Hi, > The 200 thing can go indeed. I completely agree. > The /48, which is the minimum assignment > towards that endsite must stay. Otherwise there will be ISP's who are > going to give out /56's, /58's, /60's, /62's etc. This I am not so sure about. Fixing the assignment size on /48 makes the structure of address allocations and assignments very clear, but I am not sure if we should make this official policy or just a recommendation. I don't see a problem with assigning a /48 to a customer, but maybe this should be the decision of the LIR... - Sander. From andy at linx.net Mon Apr 4 13:16:17 2005 From: andy at linx.net (Andy Furnell) Date: Mon, 4 Apr 2005 12:16:17 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <1112602728.22261.82.camel@firenze.zurich.ibm.com> Message-ID: <20050404111617.GC9065@linx.net> On Mon, Apr 04, 2005 at 10:40:36AM +0200, JORDI PALET MARTINEZ wrote: > > Agree, let's go the 200 customers, but keep the /48. Otherwise in order to > be coherent, lets change RFC3177 also (which I will not agree). > > > De: Jeroen Massar > > > > The 200 thing can go indeed. The /48, which is the minimum assignment > > towards that endsite must stay. Otherwise there will be ISP's who are > > going to give out /56's, /58's, /60's, /62's etc. > > > > The reason for the _minimum_ of a /48 is that when you want to change > > over to another ISP that you can get the equally sized /48. > > Or do you want to get, say, 3 IPv6's IP's from your upstream ISP? > > > > If you are so extremely big that you need multiple /48's (which contain > > 65k /64's as you will know) you are also more than capable of getting > > your own TLA under the new proposed #gamma policy, and most people will > > most likely going to just that for a large amount of reasons, especially > > because they simply want 'an entry in the routing table'... > > I'm just not sure this is something we want to be setting in stone. Granted once clause 'd' about 200 assignments is gone, the requirement to assign /48s would no longer seem to be an obstacle for LIRs' allocation request. However, logic still stands that even though one size (/48) may be big enough to contain just about all end-site networks it almost certainly doesn't fit them all. I agree wholeheartedly that RFC3177 should stay. However, RFC3177 contains a recommendation as to how to assign your address space, and we already draw attention to this in ripe-267 5.4.1. So it seems unnecessary (and maybe a little contradictory) to restate its recommendations as requirements; it strikes me that this should be a choice for ISPs to make and for customers to act on rather than making it a box to be ticked when making your allocation request. Andy -- Andy Furnell Mob: +44 (0) 7909 680019 London Internet Exchange http://www.linx.net From marcelo at it.uc3m.es Mon Apr 4 14:13:20 2005 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Mon, 4 Apr 2005 14:13:20 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <4250C946.5020502@tiscali.no> References: <4250C946.5020502@tiscali.no> Message-ID: <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> Hi, El 04/04/2005, a las 6:57, Hans Petter Holen escribi?: > Dear all, > Please find enclosed a policy proposal from Andy Furnell. > My proposal is to enter this proposal into the Discussion Phase with a > time line of 4 weeks ending on May 9the allowing the discusssion to > continue over the RIPE meeting. > > > 1. Number #gamma > 2. Policy Proposal Name: IPv6 Initial Allocation Criteria > 3. Author > a. name: Andy Furnell > b. e-mail: andy at linx.net > c. telephone: +44 (0) 20 7645 3519 > d. organisation: London Internet Exchange (LINX) > 4. Proposal Version: 1 > 5. Submission Date: 4/4-2005 > 6. Suggested WG for discussion and publication: Address Policy WG 7. > Proposal type: modify > a. new, modify, or delete > 8. Policy term: renewable > a. temporary, permanent, or renewable. > 9. Summary of proposal: > The proposal is to change the IPv6 Initial Allocation criteria > outlined in the "IPv6 Address Allocation and Assignment Policy" > (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed > change is to remove "have a plan for making at least 200 /48 > assignments to other organisations within two years" and to > remove the reference to "/48s" as the assignment size. > > 10. Policy text > a. Current (if modify): > > 5.1.1. Initial allocation criteria > > 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 organisations to which > it will assign /48s by advertising that connectivity through its > single aggregated address allocation; and > > d) have a plan for making at least 200 /48 assignments to other > organisations within two years. > > b. New: > > 5.1.1. Initial allocation criteria > > 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 organisations and > customers to which it will make assignments by advertising that > connectivity through its single aggregated address allocation. > > I guess that it may make sense to define a time frame here... i mean, an organization planning to provide IPv6 connectivity in 20 years would qualify here? Regards, marcelo > 11. Rationale: > a. Arguments supporting the proposal > Many LIRs' networks do not have 200 customers to make assignments > to but still maintain autonomous network and addressing policies. > These require address space that is both aggregatable and independent > from that of their peers. In addition, a /48 assignment is not > always appropriate; ISPs might have different plans for the size of > the assignments they will make and the policy should not stand as > an obstacle for them. Such a change in the policy will also make > IPv6 allocations more accessible and could result in the acceleration > of IPv6 development. b. Arguments opposing the proposal With > such a change in the policy, every LIR operating an autonomous > network would be able to receive an IPv6 allocation. The worst > case scenario would be a number of allocations equal to the number of > LIRs in the RIPE region. > > ----------------------------------------------------------------------- > ---- > From gert at space.net Mon Apr 4 14:40:26 2005 From: gert at space.net (Gert Doering) Date: Mon, 4 Apr 2005 14:40:26 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <4250C946.5020502@tiscali.no> References: <4250C946.5020502@tiscali.no> Message-ID: <20050404124026.GA84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 06:57:42AM +0200, Hans Petter Holen wrote: > 9. Summary of proposal: > The proposal is to change the IPv6 Initial Allocation criteria > outlined in the "IPv6 Address Allocation and Assignment Policy" > (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed > change is to remove "have a plan for making at least 200 /48 > assignments to other organisations within two years" and to I'm all for removing the 200-customer rule, as it's pointless, and about everyone agrees upon that (we had multiple lengthy discussions on this topic in the past, and the only argument in favour of it that I can remember was "we want the RIPE policy to be in line with the other regions", which is no longer true anyway). > remove the reference to "/48s" as the assignment size. This is a useful thing, even if people don't agree with it on the first glance (but those just need more coffee) :-) I've read other comments that say "please do not remove it, because ISPs will then start to assign /52, /62, and whatnots". I think this argument doesn't really hold, because *this* is *NOT* the place that specifies the rules for LIR->customer assignments (!!). The "how to assign to customers" -- /48, /64 or /128, depending on circumstances -- rule *is specified* in section 5.4.1 of the same document (ripe-267) in very explicit form. So I'd go for a forward reference. Text proposal is below. The reason why this "/48 assignment" stuff from the criteria needs to removed is that it doesn't make sense. The policy explicitely specifies that it's *fine* to assign /64s to certain categories of end users (5.4.1), but 5.1.1 says "but if you do that, you will not get address space to do it". Who is bitten by this is the 3GPP people, because they are planning only /64s - and if we have a policy that says "the only real driver for IPv6 isn't going to get addresses", that policy is dumb. > 10. Policy text > a. Current (if modify): > > 5.1.1. Initial allocation criteria > > 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 organisations to which > it will assign /48s by advertising that connectivity through its > single aggregated address allocation; and > > d) have a plan for making at least 200 /48 assignments to other > organisations within two years. > > b. New: > > 5.1.1. Initial allocation criteria > > 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 organisations and > customers to which it will make assignments by advertising that > connectivity through its single aggregated address allocation. I'd opt for: c) plan to provide IPv6 connectivity to organisations and customers to which it will make assignments _according to the rules specified in section 5.4.1_, and will advertise that connectivity through its single aggregated address allocation. just to make it clear that this change doesn't mean "/60s are fine now". > 11. Rationale: > a. Arguments supporting the proposal > Many LIRs' networks do not have 200 customers to make assignments > to but still maintain autonomous network and addressing policies. > These require address space that is both aggregatable and independent > from that of their peers. I agree. > In addition, a /48 assignment is not > always appropriate; ISPs might have different plans for the size > of the assignments they will make and the policy should not stand > as an obstacle for them. I disagree on the wording. The assignment size is specified in 5.4.1, and ISPs should explictely NOT have "different plans". This is one of the very important fundaments of the policy: end customer changes ISP, and does *not* have to start haggling about address space size (and especially doesn't have to reorganize his internal subnetting due to different sized assignments being handed out). As we are not changing 5.4.1, this statement is somewhat confused anyway - for an ISP to be permitted to have "different plans", we'd need to change 5.4.1... > Such a change in the policy will also make > IPv6 allocations more accessible and could result in the acceleration > of IPv6 development. Agreed. > b. Arguments opposing the proposal > With such a change in the policy, every LIR operating an autonomous > network would be able to receive an IPv6 allocation. The worst > case scenario would be a number of allocations equal to the number of > LIRs in the RIPE region. The routing system can bear that. (Yes, I hear you shouting, but I can count). Go for it! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Mon Apr 4 14:42:12 2005 From: gert at space.net (Gert Doering) Date: Mon, 4 Apr 2005 14:42:12 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <2B1A983EDCEC3447B22632B64F7264600B74AC@bill.office.computel.nl> References: <1112602728.22261.82.camel@firenze.zurich.ibm.com> <2B1A983EDCEC3447B22632B64F7264600B74AC@bill.office.computel.nl> Message-ID: <20050404124212.GB84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 12:10:15PM +0200, Sander Steffann wrote: > This I am not so sure about. Fixing the assignment size on /48 makes the > structure of address allocations and assignments very clear, but I am not > sure if we should make this official policy or just a recommendation. I > don't see a problem with assigning a /48 to a customer, but maybe this > should be the decision of the LIR... We're not making this policy, this *is* policy - same document, 5.4.1, and I do not see any proposal to change this. So please don't intermix "initial allocation criteria" (5.1.1) with "end user assignment sizes" (5.4.1) - and *please* don't change 5.4.1 or RFC3177. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Mon Apr 4 14:44:26 2005 From: gert at space.net (Gert Doering) Date: Mon, 4 Apr 2005 14:44:26 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> Message-ID: <20050404124426.GC84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 02:13:20PM +0200, marcelo bagnulo braun wrote: > I guess that it may make sense to define a time frame here... i mean, > an organization planning to provide IPv6 connectivity in 20 years would > qualify here? Yes. But how much harm can it do? This organization would eat up about 1/4294967296 of the address space, and pay a yearly fee to RIPE to be permitted to keep it. Sounds like a fair deal to me. If the address space is allocated and doesn't even end up in the routing tables, even better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From mike at linx.net Mon Apr 4 14:49:23 2005 From: mike at linx.net (Mike Hughes) Date: Mon, 04 Apr 2005 13:49:23 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> Message-ID: --On 04 April 2005 14:13 +0200 marcelo bagnulo braun wrote: > I guess that it may make sense to define a time frame here... i mean, an > organization planning to provide IPv6 connectivity in 20 years would > qualify here? I'd suggest we steer clear of yet more seemingly arbitrary numbers and limitations. It should be an immediate "demonstrable need", which would be in harmony with the initial IPv4 allocation policy. Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From jeroen at unfix.org Mon Apr 4 14:59:11 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Apr 2005 14:59:11 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404124026.GA84850@Space.Net> References: <4250C946.5020502@tiscali.no> <20050404124026.GA84850@Space.Net> Message-ID: <1112619551.22261.99.camel@firenze.zurich.ibm.com> On Mon, 2005-04-04 at 14:40 +0200, Gert Doering wrote: > Hi, > > On Mon, Apr 04, 2005 at 06:57:42AM +0200, Hans Petter Holen wrote: > > 9. Summary of proposal: > > The proposal is to change the IPv6 Initial Allocation criteria > > outlined in the "IPv6 Address Allocation and Assignment Policy" > > (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed > > change is to remove "have a plan for making at least 200 /48 > > assignments to other organisations within two years" and to > > I'm all for removing the 200-customer rule, as it's pointless... > So I'd go for a forward reference. Text proposal is below. /me goes with Gert, his version sounds completely sane IMHO. 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 andy at linx.net Mon Apr 4 15:26:05 2005 From: andy at linx.net (Andy Furnell) Date: Mon, 4 Apr 2005 14:26:05 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404124026.GA84850@Space.Net> References: <4250C946.5020502@tiscali.no> <20050404124026.GA84850@Space.Net> Message-ID: <20050404132605.GI9065@linx.net> On Mon, Apr 04, 2005 at 02:40:26PM +0200, Gert Doering wrote: > > > > The reason why this "/48 assignment" stuff from the criteria needs to > removed is that it doesn't make sense. The policy explicitely specifies > that it's *fine* to assign /64s to certain categories of end users > (5.4.1), but 5.1.1 says "but if you do that, you will not get address > space to do it". Who is bitten by this is the 3GPP people, because > they are planning only /64s - and if we have a policy that says "the > only real driver for IPv6 isn't going to get addresses", that policy > is dumb. > > > > c) plan to provide IPv6 connectivity to organisations and > > customers to which it will make assignments by advertising that > > connectivity through its single aggregated address allocation. > > I'd opt for: > > c) plan to provide IPv6 connectivity to organisations and > customers to which it will make assignments _according to the > rules specified in section 5.4.1_, and will advertise that > connectivity through its single aggregated address allocation. > > just to make it clear that this change doesn't mean "/60s are fine now". Exactly. 5.4.1 and RFC3177 are important for the sake of maintaining a coherent assignment policy, but the size of the assignments an LIR/ISP is planning on making (which we very much hope will be picked from the /48 /64 or /128 bucket as per that policy) should not impact their ability to obtain an allocation in the first place... Andy -- Andy Furnell Mob: +44 (0) 7909 680019 London Internet Exchange http://www.linx.net From gert at space.net Mon Apr 4 15:28:11 2005 From: gert at space.net (Gert Doering) Date: Mon, 4 Apr 2005 15:28:11 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404132605.GI9065@linx.net> References: <4250C946.5020502@tiscali.no> <20050404124026.GA84850@Space.Net> <20050404132605.GI9065@linx.net> Message-ID: <20050404132811.GK84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 02:26:05PM +0100, Andy Furnell wrote: > > I'd opt for: > > > > c) plan to provide IPv6 connectivity to organisations and > > customers to which it will make assignments _according to the > > rules specified in section 5.4.1_, and will advertise that > > connectivity through its single aggregated address allocation. > > > > just to make it clear that this change doesn't mean "/60s are fine now". > > Exactly. 5.4.1 and RFC3177 are important for the sake of maintaining a > coherent assignment policy, but the size of the assignments an LIR/ISP > is planning on making (which we very much hope will be picked from the > /48 /64 or /128 bucket as per that policy) should not impact their > ability to obtain an allocation in the first place... OK, so we're all in violent agreement, are we? :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From pekkas at netcore.fi Mon Apr 4 15:35:23 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 4 Apr 2005 16:35:23 +0300 (EEST) Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404124426.GC84850@Space.Net> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> Message-ID: On Mon, 4 Apr 2005, Gert Doering wrote: > On Mon, Apr 04, 2005 at 02:13:20PM +0200, marcelo bagnulo braun wrote: >> I guess that it may make sense to define a time frame here... i mean, >> an organization planning to provide IPv6 connectivity in 20 years would >> qualify here? > > Yes. But how much harm can it do? This organization would eat up about > 1/4294967296 of the address space, and pay a yearly fee to RIPE to > be permitted to keep it. Sounds like a fair deal to me. > > If the address space is allocated and doesn't even end up in the routing > tables, even better. I don't think I agree here. So, 1-man consulting companies, providing web hosting for one customer could fulfill the criteria for a /32? Looks like every enterprise out there would also get a /32. Doesn't look like a good idea at all. While I agree that the "200 customers" rule could maybe use a bit of improvement, I don't think removing it completely is the right fix at all. So, I'm opposed to the policy change. -- 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 Mon Apr 4 15:48:44 2005 From: gert at space.net (Gert Doering) Date: Mon, 4 Apr 2005 15:48:44 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> Message-ID: <20050404134844.GL84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 04:35:23PM +0300, Pekka Savola wrote: > >Yes. But how much harm can it do? This organization would eat up about > >1/4294967296 of the address space, and pay a yearly fee to RIPE to > >be permitted to keep it. Sounds like a fair deal to me. > > I don't think I agree here. So, 1-man consulting companies, providing > web hosting for one customer could fulfill the criteria for a /32? If that enterprise is willing to pay RIPE fees for it, it would qualify. > Looks like every enterprise out there would also get a /32. If they are willing to undergo the necessary paperwork, and pay the yearly fees, yes. (Which is only different from today insofar as "today the enterprise has to lie to RIPE [or be quite creative in their definition of 'customer'] to get the /32" - look at current allocations where people are wondering how the critera could have been fulfilled) > Doesn't look like a good idea at all. While I agree that the "200 > customers" rule could maybe use a bit of improvement, I don't think > removing it completely is the right fix at all. > > So, I'm opposed to the policy change. I'm wondering what your alternative proposal is, as you don't like the 200-customer rule either. If you're worried about a landslide: let's put an (arbitrary) safety margin in there "only 5000 prefixes are handed out, then we stop and re-evaluate policy". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From steffann at nederland.net Mon Apr 4 16:07:57 2005 From: steffann at nederland.net (Sander Steffann) Date: Mon, 4 Apr 2005 16:07:57 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050404124212.GB84850@Space.Net> Message-ID: <2B1A983EDCEC3447B22632B64F726460108774@bill.office.computel.nl> Hi Gert, > We're not making this policy, this *is* policy - same > document, 5.4.1, and I do not see any proposal to change this. > > So please don't intermix "initial allocation criteria" (5.1.1) with > "end user assignment sizes" (5.4.1) - and *please* don't change 5.4.1 > or RFC3177. Ok. I got a little confused by the other messages on the list. Like I said: I don't have any problems with the /48 assignment size, and if there is no proposal to change it: even better :-) - Sander From baess at denic.de Mon Apr 4 18:18:22 2005 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Mon, 4 Apr 2005 18:18:22 +0200 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy Message-ID: Dear WG! I have followed the discussion about the TLD Anycast Allocation Policy and decided not to quote from the previous posting but to pick up the arguments - as I have understood them - and pointing to the places where I have tried to address them in my policy draft. 1. Is there a need for anycasting at all ? I was surprised to see this question on the list. I think that anycasted nameservers are an accepted standard and there is no need to discuss pros and cons anymore. 2. /32 vs. /48 V6 prefix - routability aspect >From a routing table perspective there is no difference if the prefix is longer or shorter. When asking around which prefix length would have a good chance to ensure the goal of not beeing filtered I have felt consensus that a /32 has by far the best chances. However I'm considering if it wouldn't be best to declare a /32 microallocation block from which RIPE will assign /48 blocks. 3. /32 vs. /48 V6 prefix - address conservation aspect There is no question that a /32 is quite a big block and that this sacrifice to "ensure" reachability from most network places is worth it. This question should be raised at regular intervals which is covered by renewing/adjusting/withdrawing the policy if circumstances have changed. I felt that there has been consensus within the folks I have talked to that a /32 is currently a good thing to keep the komplexity of anycast deployment at a bearable level. However the last disccusion showed me that a lot of people would prefer to assign /48 from a /32 TLD Anycast Allocation Block. 4. Are the number of assignments under this policy limited? The policy in its current form implies a limit of one V4 and one V6 block assignment because as soon as one assigment is made there is no chance to pass the referenced IANA test to get another assignment. 5. Who gets the address assignment? The assignment is bound to a TLD nameservice. Therefore the applicant would be a TLD administrator. The TLD administrator can use this assignment either by himself or hand it to an anycast provider that will operate the anycast nameservers for him. I don't think that sharing an assignment between multiple TLDs if they outsource their operation to an anycasting DNS provider should be a must to separate TLD operations from each other and that the extra address space spent is a good thing keeping in mind the limited number of TLDs where talking about. Summary: I hope with my explanation it explains that most of the concerns have been addressed already. Allocating a /32 prefix to all RIPE TLD anycast assignments should help to address concerns about address space usage and make setting up routing filters easier. Any comments or suggestions? Andreas -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess at denic.de -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess at denic.de From narten at us.ibm.com Mon Apr 4 18:26:08 2005 From: narten at us.ibm.com (Thomas Narten) Date: Mon, 04 Apr 2005 12:26:08 -0400 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: Message from gert@space.net of "Mon, 04 Apr 2005 15:48:44 +0200." <20050404134844.GL84850@Space.Net> Message-ID: <200504041626.j34GQ8lK007622@rotala.raleigh.ibm.com> Gert Doering writes: > Hi, > On Mon, Apr 04, 2005 at 04:35:23PM +0300, Pekka Savola wrote: > > >Yes. But how much harm can it do? This organization would eat up about > > >1/4294967296 of the address space, and pay a yearly fee to RIPE to > > >be permitted to keep it. Sounds like a fair deal to me. > > > > I don't think I agree here. So, 1-man consulting companies, providing > > web hosting for one customer could fulfill the criteria for a /32? > If that enterprise is willing to pay RIPE fees for it, it would qualify. > > Looks like every enterprise out there would also get a /32. > If they are willing to undergo the necessary paperwork, and pay the > yearly fees, yes. And how does this scale going forward? I.e., when folk figure out that all they have to do to get their very own PI address space is join RIPE and pay the fee? > If you're worried about a landslide: let's put an (arbitrary) safety > margin in there "only 5000 prefixes are handed out, then we stop and > re-evaluate policy". So, we repeat the IPv4 experience where the early birds get a precious resource, while the late arrivers have to play under changed rules (that they view as being unfair)? I thought one of the goals with IPv6 address policy was _NOT_ to repeat the mistakes of the past. Thomas From gert at space.net Mon Apr 4 18:43:23 2005 From: gert at space.net (Gert Doering) Date: Mon, 4 Apr 2005 18:43:23 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504041626.j34GQ8lK007622@rotala.raleigh.ibm.com> References: <20050404134844.GL84850@Space.Net> <200504041626.j34GQ8lK007622@rotala.raleigh.ibm.com> Message-ID: <20050404164323.GV84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 12:26:08PM -0400, Thomas Narten wrote: > > > Looks like every enterprise out there would also get a /32. > > If they are willing to undergo the necessary paperwork, and pay the > > yearly fees, yes. > > And how does this scale going forward? I.e., when folk figure out that > all they have to do to get their very own PI address space is join > RIPE and pay the fee? Yes. This is how it works with IPv4 PA blocks right now (in RIPE land) - and *these* blocks are *not* what's filling the routing tables with 150k routes, given that we have only a few thousand RIPE members. > > If you're worried about a landslide: let's put an (arbitrary) safety > > margin in there "only 5000 prefixes are handed out, then we stop and > > re-evaluate policy". > > So, we repeat the IPv4 experience where the early birds get a precious > resource, while the late arrivers have to play under changed rules > (that they view as being unfair)? > > I thought one of the goals with IPv6 address policy was _NOT_ to > repeat the mistakes of the past. The only way to avoid *all* mistakes is to avoid giving anybody address space at all. There is no way to come up with a policy that decides today who is "worthy" that will not be challenged by someone else in 10 years. Or next week. Personally, I'd go for a handful of mistakes (and I'm willing to put enough RAM in my routers to handle 10.000 entries in the IPv6 BGP tables) if that means "we'll start making progress" - because if IPv6 isn't going to take up soon, it's dead. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jon at lawrence.org.uk Mon Apr 4 19:13:54 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Mon, 4 Apr 2005 18:13:54 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404164323.GV84850@Space.Net> References: <20050404134844.GL84850@Space.Net> <200504041626.j34GQ8lK007622@rotala.raleigh.ibm.com> <20050404164323.GV84850@Space.Net> Message-ID: <200504041813.54279.jon@lawrence.org.uk> On Monday 04 April 2005 17:43, Gert Doering wrote: > Hi, > > Yes. This is how it works with IPv4 PA blocks right now (in RIPE land) > - and *these* blocks are *not* what's filling the routing tables with > 150k routes, given that we have only a few thousand RIPE members. > > > > > I thought one of the goals with IPv6 address policy was _NOT_ to > > repeat the mistakes of the past. > > The only way to avoid *all* mistakes is to avoid giving anybody address > space at all. There is no way to come up with a policy that decides > today who is "worthy" that will not be challenged by someone else in > 10 years. Or next week. > > Personally, I'd go for a handful of mistakes (and I'm willing to put > enough RAM in my routers to handle 10.000 entries in the IPv6 BGP tables) > if that means "we'll start making progress" - because if IPv6 isn't going > to take up soon, it's dead. > There are bound to be mistakes, like you say. However, one of the major mistakes with v4 (imho) was the initial handing out of large amounts of address space to people who had no use for that many addresses. We're not faced with the quite same problems of address space exhaustion with v6, but I see absolutely no reason to repeat the same errors over and over by just wasting the address resources. I'd rather see large routing tables rather than in 10 years time find we're running out of v6 space. Most of this seems to stem from the simple requirement to multihome (anycast or otherwise). Perhaps we should just wait for the final recommendations from multi6 and see what they've come up with. Jon From pekkas at netcore.fi Mon Apr 4 19:40:38 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 4 Apr 2005 20:40:38 +0300 (EEST) Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404134844.GL84850@Space.Net> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> <20050404134844.GL84850@Space.Net> Message-ID: On Mon, 4 Apr 2005, Gert Doering wrote: >> Looks like every enterprise out there would also get a /32. > > If they are willing to undergo the necessary paperwork, and pay the > yearly fees, yes. > > (Which is only different from today insofar as "today the enterprise > has to lie to RIPE [or be quite creative in their definition of 'customer'] > to get the /32" - look at current allocations where people are wondering > how the critera could have been fulfilled) No, it's very different. Only the biggest enterprises can lie or "find the right words" about the "200 /48 other organizations" rule. For example, explain they have 200 branch offices for which those wouldn't really be separate organizations. With the proposed model, 1-man enterprise could also get a /32. I guess there's practically no way to prevent very big enterprises from getting a /32 under the current policies, if the sites want the space. But we must not extent that to "every enterprise out there". There are way too many of those. >> Doesn't look like a good idea at all. While I agree that the "200 >> customers" rule could maybe use a bit of improvement, I don't think >> removing it completely is the right fix at all. >> >> So, I'm opposed to the policy change. > > I'm wondering what your alternative proposal is, as you don't like the > 200-customer rule either. Don't get me wrong: the current policy is OK to me, but I could accept some amount of rewording. The current proposal is overkill, though. As to the alternative.. we could, for example, decrease the 200-customer limit to (say) 50 or add add some text to describe what we really meant with that (for example, you don't actually need to get 200 v6 customers in 2 years, but that you basically have 200 distinct customers). Some clarification for basically transit-only ISPs could also be done. I think we (as in, the "community", hopefully, "the global community") could find the words to achive this. > If you're worried about a landslide: let's put an (arbitrary) safety > margin in there "only 5000 prefixes are handed out, then we stop and > re-evaluate policy". Quite the contrary. If we start with too liberal policy now, we're never (practically) going to change it to be stricter later. -- 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 Mohsen.Souissi at nic.fr Mon Apr 4 19:41:08 2005 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Mon, 4 Apr 2005 19:41:08 +0200 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy In-Reply-To: References: Message-ID: <20050404174108.GF1285@kerkenna.nic.fr> Thanks Andreas for this clear summary. As you asked at the end of your message below, I would have one comment and one suggestion : - comment: One /48 microallocation per TLD under a common prefix ( a /32 or shorter per RIR) would ideally meet the goal. The "well-known" prefix would be taken into account in BGP filters so that /48 get the biggest chance not to be filtered. - suggestion: While waiting for the "ideal solution" to be implemented. The wg should move forward with this proposal and allocate one /32 per TLD applying for it. Probably, only a small number of TLDs will ask for such allocations before the "ideal solution" gets in place. In all cases, the number of requested blocks is bounded and there must be no scaling issues since the conditions are clearly stated: TLD + Anycast (+ potential problems with growing DNS response size due to growing number of NS's and glue RR's). Regards, Mohsen. On 04 Apr, Andreas B/Denic wrote: | Dear WG! | | I have followed the discussion about the TLD Anycast Allocation Policy | and decided not to quote from the previous posting but to pick up the | arguments - as I | have understood them - and pointing to the places where I have | tried to address them in my policy draft. | | 1. Is there a need for anycasting at all ? | | I was surprised to see this question on the list. | I think that anycasted nameservers are an accepted standard and there | is no need to discuss pros and cons anymore. | | | 2. /32 vs. /48 V6 prefix - routability aspect | | >From a routing table perspective there is no difference if the prefix is | longer or shorter. When asking around which prefix length would have a | good chance to ensure the goal of not beeing filtered I have felt | consensus | that a /32 has by far the best chances. However I'm considering if it | wouldn't be best to declare a /32 microallocation block from which RIPE | will | assign /48 blocks. | | 3. /32 vs. /48 V6 prefix - address conservation aspect | | There is no question that a /32 is quite a big block and that this | sacrifice | to "ensure" reachability from most network places is worth it. | This question should be raised at regular intervals which is covered by | renewing/adjusting/withdrawing the policy if circumstances have changed. | I felt that there has been consensus within the folks I have | talked to that a /32 is currently a good thing to keep the komplexity | of anycast deployment at a bearable level. However the last disccusion | showed me that a lot of people would prefer to assign /48 from a /32 | TLD Anycast Allocation Block. | | 4. Are the number of assignments under this policy limited? | | The policy in its current form implies a limit of one V4 and one V6 block | assignment because as soon as one assigment is made there is no chance | to pass the referenced IANA test to get another assignment. | | 5. Who gets the address assignment? | | The assignment is bound to a TLD nameservice. Therefore the applicant | would be | a TLD administrator. The TLD administrator can use this assignment either | by himself or hand it to an anycast provider that will operate the anycast | nameservers for him. | I don't think that sharing an assignment between multiple TLDs if they | outsource | their operation to an anycasting DNS provider should be a must to separate | TLD operations from each other and that the extra address space spent is a | good | thing keeping in mind the limited number of TLDs where talking about. | | | Summary: | | I hope with my explanation it explains that most of the concerns have been | addressed already. Allocating a /32 prefix to all RIPE TLD anycast | assignments | should help to address concerns about address space usage and make setting | up | routing filters easier. | | Any comments or suggestions? | | Andreas | -- | DENIC e.G. Phone :+49 69 27235 120 | Wiesenhuettenplatz 26 Fax :+49 69 27235 235 | D-60329 Frankfurt Mail : baess at denic.de | -- | DENIC e.G. Phone :+49 69 27235 120 | Wiesenhuettenplatz 26 Fax :+49 69 27235 235 | D-60329 Frankfurt Mail : baess at denic.de From oliver at bartels.de Mon Apr 4 21:10:13 2005 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 04 Apr 2005 21:10:13 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504041813.54279.jon@lawrence.org.uk> Message-ID: <200504041910.j34JAAe5013129@alpha.bartels.de> On Mon, 4 Apr 2005 18:13:54 +0100, Jon Lawrence wrote: >There are bound to be mistakes, like you say. However, one of the major >mistakes with v4 (imho) was the initial handing out of large amounts of >address space to people who had no use for that many addresses. We're not >faced with the quite same problems of address space exhaustion with v6, but I >see absolutely no reason to repeat the same errors over and over by just >wasting the address resources. >I'd rather see large routing tables rather than in 10 years time find we're >running out of v6 space. Well, we will also see routers beeing capable to route more than 150K prefixes. We can even see them today. And there are really PC's with more than 640K of RAM ;-) At these old days when these 64MB routers were designed, RAM chips had 4 to 16 MBits of RAM. Today we are talking about min. 256MBit SDRAM dies, smaller SDRAM's will have their "call for last order" very soon now. >Most of this seems to stem from the simple requirement to multihome (anycast >or otherwise). Perhaps we should just wait for the final recommendations from >multi6 and see what they've come up with. I always had the oppinion the "no risk at all, better no decision than some decision, let us better wait until the project is dead" approach is called the *German* disease ... :-| Again for multiv6: *There won't be a *full* and *unrestricted* solution, the we_want_multiv6_but_keep_BGP4 approach has fundamental laws of math and computer science against it: An *address* is an *address* and is spoken *address*, because it addresses something, which means it guides something to a destination, which does not mean that it just references something and let's some unknown big wonder do the job ;-/ However there *is* an IPv4 solution called PI/BGP4 and we won't convince customers to adopt an 128 Bit address space if even the old effective 24 Bit international routing won't be available any more :-( For a 128 Bit address space from a users point of view I would expect at least an full international routing of 48 Bits, which means *of course* a *larger* number of *possible* prefixes. This has nothing to do with "old mistakes", if we can't route this range with independent prefixes, *forget it*. But it is possible, BGP4 is proven with existing products for appx. 500K prefixes, if more is needed, I would suggest thinking of an protocol update. Below 500K, BGP4 is ok for sure, and 20K is much less than 500K. Ceterum censeo: 1. If routers can't route 20K *IPv6* prefixes, it is better to drop this technology now. Simply because routers *can/must* route >>150K IPv4 prefixes. If it seems so dificult to implement IPv6 that we can't afford even one prefix per paying LIR, then it is obvious that IPv4 is clearly the better technology and we should stay with it rather than switching to IPv6. ( Let us all save the money and let's have a big "final IPv6" party ;-/ 2. If we want to shift IPv6 to a common and commercial *product* rather than a toy-place for techies, we should *distribute* it and not restrict it. You can't sell the shoes and restrict them with a don't-wear-them policy ... I do fully agree with Gert: "because if IPv6 isn't going to take up soon, it's dead." And I also fully agree with the policy proposal. 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 randy at psg.com Mon Apr 4 21:17:04 2005 From: randy at psg.com (Randy Bush) Date: Mon, 4 Apr 2005 09:17:04 -1000 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria References: <200504041813.54279.jon@lawrence.org.uk> <200504041910.j34JAAe5013129@alpha.bartels.de> Message-ID: <16977.37552.149509.909833@roam.psg.com> >> There are bound to be mistakes, like you say. However, one of the major >> mistakes with v4 (imho) was the initial handing out of large amounts of >> address space to people who had no use for that many addresses. We're not >> faced with the quite same problems of address space exhaustion with v6, >> but I see absolutely no reason to repeat the same errors over and over by >> just wasting the address resources. >> I'd rather see large routing tables rather than in 10 years time find we're >> running out of v6 space. > Well, we will also see routers beeing capable to route more than > 150K prefixes. We can even see them today. > > And there are really PC's with more than 640K of RAM ;-) > > At these old days when these 64MB routers were designed, > RAM chips had 4 to 16 MBits of RAM. Today we are talking > about min. 256MBit SDRAM dies, smaller SDRAM's will have > their "call for last order" very soon now. and we once thought 32 bits of address should be enough for ever randy From oliver at bartels.de Mon Apr 4 21:22:19 2005 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 04 Apr 2005 21:22:19 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16977.37552.149509.909833@roam.psg.com> Message-ID: <200504041922.j34JMGe5013310@alpha.bartels.de> On Mon, 4 Apr 2005 09:17:04 -1000, Randy Bush wrote: >and we once thought 32 bits of address should be enough for ever If this policy discussion continues, and continues, and continues ... ... then 32 bits of address *will be* enough for ever. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From jeroen at unfix.org Mon Apr 4 21:27:59 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Apr 2005 21:27:59 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504041922.j34JMGe5013310@alpha.bartels.de> References: <200504041922.j34JMGe5013310@alpha.bartels.de> Message-ID: <1112642879.28943.1.camel@firenze.zurich.ibm.com> On Mon, 2005-04-04 at 21:22 +0200, Oliver Bartels wrote: > On Mon, 4 Apr 2005 09:17:04 -1000, Randy Bush wrote: > >and we once thought 32 bits of address should be enough for ever > If this policy discussion continues, and continues, and continues ... > ... then 32 bits of address *will be* enough for ever. To put it in another perspective: If these policies cause 2000::/3 to be exhausted then there are 7 more tries left to do it all over again. And indeed the people in 2000::/3 who where early adopters will have the advantage of getting a huge space easily, just like in IPv4 land. But in IPv4 land there was not much left, in IPv6 there are another 7 tries to go before it is completely filled up... Now folks get over it ;) 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 gert at space.net Tue Apr 5 00:25:22 2005 From: gert at space.net (Gert Doering) Date: Tue, 5 Apr 2005 00:25:22 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16977.37552.149509.909833@roam.psg.com> References: <200504041813.54279.jon@lawrence.org.uk> <200504041910.j34JAAe5013129@alpha.bartels.de> <16977.37552.149509.909833@roam.psg.com> Message-ID: <20050404222522.GW84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 09:17:04AM -1000, Randy Bush wrote: > and we once thought 32 bits of address should be enough for ever *I* wasn't part of that "we" - and the math is a *little* bit different here. To answer Jon Lawrence on his "address space depletion worries": please *do* the math, just once, and then stop this often repeated but invalid argument. There are 4 *billion* /32 prefixes. Handing out (globally visible) /32s will not be a mistake because the *addresses* run out - the problem space is "number of AS numbers" and "number of routing table entries". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From randy at psg.com Tue Apr 5 01:38:10 2005 From: randy at psg.com (Randy Bush) Date: Mon, 4 Apr 2005 13:38:10 -1000 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria References: <200504041813.54279.jon@lawrence.org.uk> <200504041910.j34JAAe5013129@alpha.bartels.de> <16977.37552.149509.909833@roam.psg.com> <20050404222522.GW84850@Space.Net> Message-ID: <16977.53218.266593.318146@roam.psg.com> >> and we once thought 32 bits of address should be enough for ever > *I* wasn't part of that "we" - and the math is a *little* bit different > here. > *I* wasn't part of that "we" one of the few benefits of age is perspective > To answer Jon Lawrence on his "address space depletion worries": please > *do* the math, just once, and then stop this often repeated but invalid > argument. gert, i am too busy to find the quote for you right now, but the essence is that EVERY size limit that has EVER been done in computing has proved to be to small in the long run. so perhape prudence in the presence of finite resource is not stupid. if v6's only feature is that you can be wasteful of the space, that is still not going to sell it. this too wa known at the time. but the ivtf was driven by a rush to silence "the internet is running out of addresses space" press and dropped the variable address length proposal, and also decided routing was not as important as political expedience. randy From randy at psg.com Tue Apr 5 01:48:53 2005 From: randy at psg.com (Randy Bush) Date: Mon, 4 Apr 2005 13:48:53 -1000 Subject: [address-policy-wg] Re: [Ticket #1032183] Autoreply: viadomains References: Message-ID: <16977.53861.200371.123371@roam.psg.com> i have plonked all mail from vianetworks.co.uk. if they ever get a clue and have something useful to say, someone please tell me. randy > From: via-domains > RT-Ticket: Ticket #1032183 > Managed-by: RT 3.2.3 (http://www.bestpractical.com/rt/) > RT-Originator: randy at psg.com > To: randy at psg.com > > Thank you for your enquiry concerning "Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria", a summary > of which appears below. It has been logged with our automated ticketing > system and will be forwarded on to the appropriate department. > > You have been allocated a unique reference number - [Ticket > #1032183] - for this query that should be used in all further > correspondence relating to this matter. If replying by email, please > make sure that the ticket number is in the subject header. > > Thank you for your query, > > VIA Networks UK Support Administration > domains at vianetworks.co.uk > ------------------------------------------------------------------------- > Spam detection software, running on the system "he401war", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or block > similar future email. If you have any questions, see > sysadmin at vianetworks.co.uk for details. > > Content preview: >> and we once thought 32 bits of address should be > enough for ever > *I* wasn't part of that "we" - and the math is a > *little* bit different > here. > *I* wasn't part of that "we" one of > the few benefits of age is perspective [...] > > Content analysis details: (6.1 points, 5.0 required) > > pts rule name description > ---- ---------------------- -------------------------------------------------- > 1.0 RCVD_FROM_SECONDARY Went through secondary MX record > 0.1 TW_VT BODY: Odd Letter Triples with VT > 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% > [score: 1.0000] > -0.4 AWL AWL: Auto-whitelist adjustment > > > From hpholen at tiscali.no Tue Apr 5 07:18:23 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Tue, 05 Apr 2005 07:18:23 +0200 Subject: [address-policy-wg] Draft Agenda for Address Policy WG @ RIPE 50 Thursday 5th May Message-ID: <42521F9F.2050404@tiscali.no> Dear all, Please find enclosed a first Draft Agenda for the upcoming Address Policy meeting. -hph A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 49: http://www.ripe.net/ripe/wg/address-policy/r49-minutes.html B. Policy overview - Regional policy overview -- presentation of the status of the current regional proposals under the "beta test of the PDP" -- status of the PDP and transition to the PDP - Gloobal policy overview C. Policy proposal: #alpha: TLD Anycast Allocation Policy D. Policy proposal: #beta: IPv4-HD-Ratio E. Policy proposal: #gamma: IPv6 remove 200 customer requirement F. Other v6 issues ? G. Status of the IPv4 Global Policy H. Status of the IPv6 Global Policy I. Any other Business From oliver at bartels.de Tue Apr 5 07:38:06 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 07:38:06 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16977.53218.266593.318146@roam.psg.com> Message-ID: <200504050538.j355c9e5021695@alpha.bartels.de> On Mon, 4 Apr 2005 13:38:10 -1000, Randy Bush wrote: >gert, i am too busy to find the quote for you right now, but >the essence is that EVERY size limit that has EVER been done >in computing has proved to be to small in the long run. *Please* do math. The limit is the number of atoms on earth, however we should consider the aliens ... It has also been proven that EVERY memory size problem has been solved so far. >so perhape prudence in the presence of finite resource is not >stupid. >if v6's only feature is that you can be wasteful of >the space, that is still not going to sell it. To some degree I agree: - If IPv6 only feature is that you have a large address space, *which can't be routed*, it won't sell. The equivalent would be a 20 digit postal zip code with just 5 digits used by the postman, but the other 15 validated by an address controller just to check that post office customers have fully read and understood the zip code rules book with it's 1000 pages ;-/ We don't need a protocol with 128 Bit address space (a decimal number with *38* decimal digits) nor 64 Bit (a decimal number with *19* decimal digits) global addresses *if we can't route this space globally* and thus *again* have all the renumbering pain which we have with IPv4 in the case of a technical or ISP change. *Either* we are sure that engineers and vendors will be able to provide at least the routing performance of IPv4 for IPv6 and hopefully *significantly better*, then we should stop this "let us restrict everything" discussion. We can sell products, but we can't sell restrictions. Or we don't believe this, then we should stop considering IPv6 as new protocol for the global internet. Best Regards Oliver P.s.: And no, there are not enough *intranet* VPN's to justify switching to a new *internet* protocol. In such cases IPv6 may be used internally up to the gateway. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From randy at psg.com Tue Apr 5 07:46:32 2005 From: randy at psg.com (Randy Bush) Date: Mon, 4 Apr 2005 19:46:32 -1000 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria References: <16977.53218.266593.318146@roam.psg.com> <200504050538.j355c9e5021695@alpha.bartels.de> Message-ID: <16978.9784.177929.791108@roam.psg.com> >> gert, i am too busy to find the quote for you right now, but >> the essence is that EVERY size limit that has EVER been done >> in computing has proved to be to small in the long run. > It has also been proven that EVERY memory size problem > has been solved so far. by changing the addressing. and that is exactly where we got into trouble last time. and our grandchildren will have the same problem again. george santayana was not a fool. randy From oliver at bartels.de Tue Apr 5 09:06:22 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 09:06:22 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16978.9784.177929.791108@roam.psg.com> Message-ID: <200504050706.j3576Je5023112@alpha.bartels.de> On Mon, 4 Apr 2005 19:46:32 -1000, Randy Bush wrote: >by changing the addressing. and that is exactly where we got >into trouble last time. and our grandchildren will have the >same problem again. What trouble ? The IPv4 is a *success story*, there are *few* products with more success. The whole world adoped this protocol and addressing and it is and still will be *functional* for a long time. Compared to this success the few "we need CIDR and some address assignment policy" issues are *minor* and can be seen as small corrections implied with every success story. Even the FA board does apply minor changes to the >100 years old football rule after regulary scheduled meetings ... Compared with these IPv6 is currently *not* a success story, it is over ten years old and still experimental. For the technology of the '90s it makes indeed sense to use a 32 bit address space with 24 bit international routing: - The address can be handled in one step by standard processors designed for 32 bit - 32 bit as a reasonable 2^n multiple of an 8 bit byte (character unit and again 2^k) is => large enough to provide at least one IP adddress per stationary end user site on this world => small enough for efficiently wirable bus widths and *fast* handling by ALU's (carry lock ahead etc.) ( remember the market failure of the Itanium, a pure/mainly 64 bit engine has no market, as 32 bit is a reasonable integer and pointer width in *most* cases, 16 bit is too small for pointers, on the other side more than 4GB address space per task is required just by very few programming tasks ) - 24 bit can be completely internationally forwarded by a very fast radix tree structure: - Take the first byte, look up in a table, either find a next hop or a pointer to the next second level table. If there is a next hop, you are done. - Repeat this for the second, third byte and the second and third level table. This requires 3 table accesses, an easy job for even a small microprocessor. An access list is much more complicated. This means: Worst case is 1 + 256 + 256*256 tables with e.g. four bytes per entry (ptr.) and 256 entries each, this means *worst case* 65793 tables or appx. 67MByte RAM, typical case about one third due to many /16's, unused /8s, multicast space etc. and hopefully a good next hop aggregation algorithm for /16's splitted into same destination /24's by clueless operators. Which means: This lookup can even be done in SRAM or by microcode compiled from the BGP info in real time, a static RAM area with 8...16 MWords (32 Bit/word) is affordable today, the same with DRAM is *really cheap* and even was cheap in the last century ... The 32 bit address makes absolutely sense from a technical and economical point of view and you need *very good reasons* and a *much* better performance to sell something else. At the end the customers decides, not the address-policy-wg, and if we can't provide an interesting IPv6, the customer will stay with IPv4 for the next 20 years. After that, the chance is high that there will be some completly new (intelligent, on the fly search, combined-multi-any-whatever-cast) IPv_new. If you want make IPv6 an success, it must be *better* than IPv4, not worse and more restricted. Arguments could be (Ceterum Censeo ;-) - no renumbering pain due to get-once-stay-with-them addresses *regardless* which ISP doing the service - easy multihoming - easy VPN's - a *globally* unique *constant* address for each mobile (which again means global routing, *not* dynamic assignment, this and NAT is what we have today) and not - total dependency on your ISP or upstream due to an restrictive and pseudo-geographical addressing Think of: IPv6 was created with nearly *unlimited* address space in mind, either it can keep this promise (which means usable, thus *routable* address space) or it is dead. Greets Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From pekkas at netcore.fi Mon Apr 4 21:38:26 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 4 Apr 2005 22:38:26 +0300 (EEST) Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404164323.GV84850@Space.Net> References: <20050404134844.GL84850@Space.Net> <200504041626.j34GQ8lK007622@rotala.raleigh.ibm.com> <20050404164323.GV84850@Space.Net> Message-ID: This doesn't have much to do with policy anymore, so address-policy-wg is bcc:ed. On Mon, 4 Apr 2005, Gert Doering wrote: [...] > if that means "we'll start making progress" - because if IPv6 isn't going > to take up soon, it's dead. Well.. these policy proposals seem mainly set to enable v6 to enterprises, not to ISPs (because ISPs can basically qualify as it is). As is it, enterprises have very little incentive to deploy v6 in any case. It brings them few benefits and a lot of (bleeding edge) trouble. While enterprises may be good for ISPs to get some revenue to play with v6, and maybe to get pressure on the equipment vendors to ship v6 stuff, we shouldn't be equating enterprises' desires wrt v6 with the success or failure of v6. IPv6 will succeed or fail regardless of whether enterprises get v6 PI or 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 From jeroen at unfix.org Tue Apr 5 09:51:11 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 05 Apr 2005 09:51:11 +0200 Subject: [address-policy-wg] Re: [Ticket #1032183] Autoreply: viadomains In-Reply-To: <16977.53861.200371.123371@roam.psg.com> References: <16977.53861.200371.123371@roam.psg.com> Message-ID: <1112687471.23956.2.camel@firenze.zurich.ibm.com> On Mon, 2005-04-04 at 13:48 -1000, Randy Bush wrote: > i have plonked all mail from vianetworks.co.uk. if they ever get > a clue and have something useful to say, someone please tell me. Ah, thus I was not the only one getting those silly "you are spamming" replies, then again if you look at their Bayesian filter: > > pts rule name description > > ---- ---------------------- -------------------------------------------------- > > 1.0 RCVD_FROM_SECONDARY Went through secondary MX record > > 0.1 TW_VT BODY: Odd Letter Triples with VT > > 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% > > [score: 1.0000] > > -0.4 AWL AWL: Auto-whitelist adjustment Indeed... those folks will not get much mail. I mean if this ML result in 99% spam probability, ouch ;) Greets, Jeroen (And yes, I already send a message to address-policy-wg-owner at ripe.net and also one to ops at ripe.net with the content that they might want to throw that subscriber from the list...) -------------- 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 gert at space.net Tue Apr 5 10:18:12 2005 From: gert at space.net (Gert Doering) Date: Tue, 5 Apr 2005 10:18:12 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16978.9784.177929.791108@roam.psg.com> References: <16977.53218.266593.318146@roam.psg.com> <200504050538.j355c9e5021695@alpha.bartels.de> <16978.9784.177929.791108@roam.psg.com> Message-ID: <20050405081812.GA84850@Space.Net> Hi, On Mon, Apr 04, 2005 at 07:46:32PM -1000, Randy Bush wrote: > >> gert, i am too busy to find the quote for you right now, but > >> the essence is that EVERY size limit that has EVER been done > >> in computing has proved to be to small in the long run. > > It has also been proven that EVERY memory size problem > > has been solved so far. > > by changing the addressing. and that is exactly where we got > into trouble last time. and our grandchildren will have the > same problem again. So what do *you* propose to do now? (On the math thing: you conveniently ignored my argument that we'll run into other limits *far* earlier than into the depletion of /32s - and unless *those* are solved, address depletion by handing out routable /32s really is a non-issue) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From dr at cluenet.de Tue Apr 5 10:37:23 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 10:37:23 +0200 Subject: [address-policy-wg] Re: [Ticket #1032183] Autoreply: viadomains In-Reply-To: <1112687471.23956.2.camel@firenze.zurich.ibm.com> References: <16977.53861.200371.123371@roam.psg.com> <1112687471.23956.2.camel@firenze.zurich.ibm.com> Message-ID: <20050405083723.GA24314@srv01.cluenet.de> On Tue, Apr 05, 2005 at 09:51:11AM +0200, Jeroen Massar wrote: > (And yes, I already send a message to address-policy-wg-owner at ripe.net > and also one to ops at ripe.net with the content that they might want to > throw that subscriber from the list...) Me too, to address-policy-wg-owner on 24th of march... looks like this is a /dev/null address. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jon at lawrence.org.uk Tue Apr 5 11:00:22 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Tue, 5 Apr 2005 10:00:22 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404222522.GW84850@Space.Net> References: <200504041813.54279.jon@lawrence.org.uk> <16977.37552.149509.909833@roam.psg.com> <20050404222522.GW84850@Space.Net> Message-ID: <200504051000.22807.jon@lawrence.org.uk> On Monday 04 April 2005 23:25, Gert Doering wrote: > Hi, > > On Mon, Apr 04, 2005 at 09:17:04AM -1000, Randy Bush wrote: > > and we once thought 32 bits of address should be enough for ever > > *I* wasn't part of that "we" - and the math is a *little* bit different > here. > > To answer Jon Lawrence on his "address space depletion worries": please > *do* the math, just once, and then stop this often repeated but invalid > argument. There are 4 *billion* /32 prefixes. Handing out (globally > visible) /32s will not be a mistake because the *addresses* run out - the > problem space is "number of AS numbers" and "number of routing table > entries". > yes, there will other problems that will/should manifest themselves way before there is any address depletion worries. I also wasn't around when the initial v4 mistakes were made (well, I was but not in this industry) - but I'm willing to bet the arguments were the same (ie the address space is so large it doesn't matter what we give out). That argument is pure *bull*, as Randy points out no one has ever successfully predicted how far things in this industry will have to scale in the future. The math is vastly different, a class A was a much bigger % of the available space - and perhaps /32(/48)'s are the right places to draw the line. But that's what it is, where we (the industry) are suggesting the line is drawn. The idea that the address range is so vast that it will never be deleted is *rubbish*. Is the number of routing table entries an issue ? only the manufacturers can possibly tell us what routers may be able to handle in 10 years time. So that only question is where do we draw the line on who gets routable address space: 1) companies who provide addresses to clients (ie ISP's). 2) critical infrastructure 3) anyone who wants to multihome. or 4) anyone who can afford it. Jon From gert at space.net Tue Apr 5 11:41:24 2005 From: gert at space.net (Gert Doering) Date: Tue, 5 Apr 2005 11:41:24 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504051000.22807.jon@lawrence.org.uk> References: <200504041813.54279.jon@lawrence.org.uk> <16977.37552.149509.909833@roam.psg.com> <20050404222522.GW84850@Space.Net> <200504051000.22807.jon@lawrence.org.uk> Message-ID: <20050405094124.GF84850@Space.Net> Hi, On Tue, Apr 05, 2005 at 10:00:22AM +0100, Jon Lawrence wrote: > So that only question is where do we draw the line on who gets routable > address space: > 1) companies who provide addresses to clients (ie ISP's). This is what the policy proposal talks about. Just without the silly need to claim a *plan* for fulfillment of an arbitrary number. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Michael.Dillon at radianz.com Tue Apr 5 12:00:11 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 5 Apr 2005 11:00:11 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <1112642879.28943.1.camel@firenze.zurich.ibm.com> Message-ID: > If these policies cause 2000::/3 to be exhausted then there are 7 more > tries left to do it all over again. This is the essential characteristic of IPv6 that so many of us, weaned on IPv4, seem to forget. We need to keep this fact uppermost in our minds at all times. Even this subset of IPv6 is much bigger than the IPv4 space. So we can afford to be generous and, in fact, we can afford to make mistakes. If we err, we should err on the side of being slightly too generous because if 2000::/3 runs out, we can try again, older but wiser. This means that we should not be excessively concerned with conserving address space or wasting addresses. It is entirely appropriate to give a /32 to anyone who might be some sort of an ISP, either traditional or some new type, like Google or BMW or Cadburys. It is entirely appropriate for these ISPs to give a /48 to every customer except in the very unusual situation where a customer connects with only a single device that has a single network in it. The only such situation that I can think of is a mobile phone. However, we should not stop thinking about conservation. This is the real world and we do have limitations in router hardware and memory chip capacities and speeds. It would be foolish to allow the routing table to grow without bounds. This is where we need to be conservative and make policies which are not wasteful of routing table space. Now, a set of IPv6 policies in which no globally routable prefixes are longer than /32 allows router manufacturers to optimize memory usage and design router tables to only carry those 32 bits of the IPv6 address. This will conserve memory and allow the routers to scale easier. Of course, any such design will impose a computation penalty on prefixes longer than /32, i.e. /8 prefixes, and that would make it inappropriate to announce /48 prefixes globally for things like DNS infrastructure. Note that I am not interested in whether or not current router implementations or BGP implementations support truncated prefixes in order to realize savings of memory, bandwidth, transmission time, or computation time. That is not our job. Our job is to make a sensible policy that allows the use of IPv6 to scale smoothly so that it meets the needs of humankind for the next generation or two. Let's not be so arrogant that we try to solve all addressing problems forever. That is not necessary. There will be people who come after us and if they feel that we botched the job in 2000::/3, then they have the opportunity for a much easier transition than the transition from IPv4 to IPv6. --Michael Dillon From elmi at 4ever.de Tue Apr 5 13:52:53 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 5 Apr 2005 13:52:53 +0200 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy In-Reply-To: <20050404174108.GF1285@kerkenna.nic.fr> References: <20050404174108.GF1285@kerkenna.nic.fr> Message-ID: <20050405115253.GL43805@new.detebe.org> Mohsen.Souissi at nic.fr (Mohsen Souissi) wrote: > - comment: One /48 microallocation per TLD under a common > prefix ( a /32 or shorter per RIR) would ideally meet the goal. The > "well-known" prefix would be taken into account in BGP filters so > that /48 get the biggest chance not to be filtered. I second that, but in essence, it's down to operational issues here. Once the WG has expressed its confidence in the proposal, a few formulations are in order; yet, at this time there's no express consensus yet. Hopefully we'll reach that in Stockholm, even if I (and a couple other folks as well) would be very happy if this proposal would get the entire WG's support a bit sooner. > - suggestion: While waiting for the "ideal solution" to be > implemented. The wg should move forward with this proposal and > allocate one /32 per TLD applying for it. Probably, only a small > number of TLDs will ask for such allocations before the "ideal > solution" gets in place. In all cases, the number of requested > blocks is bounded and there must be no scaling issues since the > conditions are clearly stated: TLD + Anycast (+ potential problems > with growing DNS response size due to growing number of NS's and > glue RR's). I second this. Limiting the proposal to TLDs makes the number of potential users manageably small. I'd recommend to get the proposal done and into action instead of keeping to basic discussion of how an administrator/operator should run their services. The proposal should have a paragraph that encourages re-evaluation, so that discovered mistakes can be fixed. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From dr at cluenet.de Tue Apr 5 14:09:03 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 14:09:03 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> Message-ID: <20050405120903.GA26303@srv01.cluenet.de> On Tue, Apr 05, 2005 at 11:00:11AM +0100, Michael.Dillon at radianz.com wrote: > Now, a set of IPv6 policies in which no globally routable > prefixes are longer than /32 allows router manufacturers > to optimize memory usage and design router tables to only > carry those 32 bits of the IPv6 address. We don't have those policies. Supposed-to-be-globally-routable /48s do already exist. > This will conserve memory and allow the routers to scale easier. If we really consider crippling CIDR lookups to less than 128 Bit: I don't think that "64 bit or bit 48" makes much of a difference in terms of router scalability... but I'm guesstimating here with about nothing to back that. Other folks might comment. > Our job is to make a sensible policy that allows the use of > IPv6 to scale smoothly so that it meets the needs of humankind > for the next generation or two. Let's not be so arrogant that > we try to solve all addressing problems forever. That is not > necessary. ACK. And our job is to design something desireable, not something that has serious shortcomings compared to IPv4 (no PI for endusers). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Tue Apr 5 14:17:21 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 14:17:21 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405120903.GA26303@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> Message-ID: <7eb1d338f663501cb3828e6949e173d5@muada.com> On 5-apr-05, at 14:09, Daniel Roesen wrote: >> Our job is to make a sensible policy that allows the use of >> IPv6 to scale smoothly so that it meets the needs of humankind >> for the next generation or two. Let's not be so arrogant that >> we try to solve all addressing problems forever. That is not >> necessary. > ACK. And our job is to design something desireable, not something that > has serious shortcomings compared to IPv4 (no PI for endusers). And that's exactly the problem. This forum is more or less a marketing forum, and as such it's the wrong place to decide on these issues, as these are ENGINEERING tradeoffs. There should be an engineering forum that sets upper and lower limits on what can happen in places such as this. In addition, it makes no sense whatsoever to make these decisions for part of the network, as the results impact everyone around the world. The IETF has worked long and hard on multihoming without PI. It would be superbly stupid to throw all of that away with the finish line in sight and forever increase the cost of routing just so lazy people can get away with hardcoding IPv6 addresses in their access lists. From iljitsch at muada.com Tue Apr 5 14:27:25 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 14:27:25 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404124026.GA84850@Space.Net> References: <4250C946.5020502@tiscali.no> <20050404124026.GA84850@Space.Net> Message-ID: <59cf64c8d38804fea9a6567584167744@muada.com> On 4-apr-05, at 14:40, Gert Doering wrote: >> 9. Summary of proposal: >> The proposal is to change the IPv6 Initial Allocation criteria >> outlined in the "IPv6 Address Allocation and Assignment Policy" >> (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed >> change is to remove "have a plan for making at least 200 /48 >> assignments to other organisations within two years" and to > I'm all for removing the 200-customer rule, as it's pointless, The world would be an empty place after we remove everything that's pointless. I would be much more interested in removing things that are harmful or get in the way. Can anyone show me some examples of networks that we can agree on deserve a PA block but don't get it because of the 200 customer rule? I'm not convinced this rule actually gets in the way in practice. >> remove the reference to "/48s" as the assignment size. > This is a useful thing, even if people don't agree with it on the > first glance (but those just need more coffee) :-) Yes. Read the RFCs. > I've read other comments that say "please do not remove it, because > ISPs > will then start to assign /52, /62, and whatnots". I think this > argument > doesn't really hold, because *this* is *NOT* the place that specifies > the rules for LIR->customer assignments (!!). Ok so the policy isn't as beautiful as it can be. Who cares. The /48 thing is a good reminder for ISPs that might otherwise import their existing v4 policies in IPv6. >> b. Arguments opposing the proposal >> With such a change in the policy, every LIR operating an autonomous >> network would be able to receive an IPv6 allocation. The worst >> case scenario would be a number of allocations equal to the number >> of >> LIRs in the RIPE region. > The routing system can bear that. (Yes, I hear you shouting, but I can > count). Go for it! Where exactly is "number of LIRs in the RIPE region" defined as CONST ? We already allow people to "buy" IPv4 address space like this, which is questionable. Doing the same for IPv6 is much more harmful as people will abuse this to get around the lack of IPv6 PI space. And whatever anyone's feelings about that, having people get PA blocks instead is NOT the solution. From dr at cluenet.de Tue Apr 5 14:27:51 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 14:27:51 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <7eb1d338f663501cb3828e6949e173d5@muada.com> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> Message-ID: <20050405122751.GA26638@srv01.cluenet.de> On Tue, Apr 05, 2005 at 02:17:21PM +0200, Iljitsch van Beijnum wrote: > >ACK. And our job is to design something desireable, not something that > >has serious shortcomings compared to IPv4 (no PI for endusers). > > And that's exactly the problem. This forum is more or less a marketing > forum, and as such it's the wrong place to decide on these issues, as > these are ENGINEERING tradeoffs. Name the engineering problems of end-user PI. (Un)fortunately nobody was yet able to show convincing prove that there IS a problem. Stop FUDding. > In addition, it makes no sense whatsoever to make these decisions for > part of the network, as the results impact everyone around the world. Agreed. > The IETF has worked long and hard on multihoming without PI. It would > be superbly stupid to throw all of that away with the finish line in > sight and forever increase the cost of routing just so lazy people can > get away with hardcoding IPv6 addresses in their access lists. IETF is nowhere near any solution. They are as far away from it as they can be. Will probably take another few years to finally realize that. There is no REAL multihoming without PI yet. And the IETF recently narrowed down the road they want to take (solution space) that guarrantees that the result won't fit people's needs. The multi6=>shim6 transition was (for me and quite a few others) the "end of all hope". Don't waste time and energy waiting for shim6. The outcome won't fly. A sensible "separated locator and idenfication" approach would need a complete revamp of the operating model and (and that's the big thing) operating systems L3/L4 stacks. Won't happen, so shim6 will be a crude hack, attacking only part of the requirement space. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Tue Apr 5 14:28:43 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 14:28:43 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404124426.GC84850@Space.Net> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> Message-ID: On 4-apr-05, at 14:44, Gert Doering wrote: >> I guess that it may make sense to define a time frame here... i mean, >> an organization planning to provide IPv6 connectivity in 20 years >> would >> qualify here? > Yes. But how much harm can it do? This organization would eat up > about > 1/4294967296 of the address space, and pay a yearly fee to RIPE to > be permitted to keep it. Sounds like a fair deal to me. So where do I send the bill for the fee to take up space in my routing table? No deal. > If the address space is allocated and doesn't even end up in the > routing > tables, even better. That's what's site local ng is for. From iljitsch at muada.com Tue Apr 5 14:31:32 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 14:31:32 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050404134844.GL84850@Space.Net> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> <20050404134844.GL84850@Space.Net> Message-ID: <6146a89cfc4b39e8994430b6f1c3a42a@muada.com> On 4-apr-05, at 15:48, Gert Doering wrote: >> I don't think I agree here. So, 1-man consulting companies, providing >> web hosting for one customer could fulfill the criteria for a /32? > If that enterprise is willing to pay RIPE fees for it, it would > qualify. >> Looks like every enterprise out there would also get a /32. > If they are willing to undergo the necessary paperwork, and pay the > yearly fees, yes. Either having very many people get /32s is harmful, or it isn't. How does paying the RIPE fee move this from "harmful" to "non-harmful"? >> So, I'm opposed to the policy change. Me too. From gert at space.net Tue Apr 5 14:34:46 2005 From: gert at space.net (Gert Doering) Date: Tue, 5 Apr 2005 14:34:46 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6146a89cfc4b39e8994430b6f1c3a42a@muada.com> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> <20050404134844.GL84850@Space.Net> <6146a89cfc4b39e8994430b6f1c3a42a@muada.com> Message-ID: <20050405123446.GJ84850@Space.Net> Hi, On Tue, Apr 05, 2005 at 02:31:32PM +0200, Iljitsch van Beijnum wrote: > >If they are willing to undergo the necessary paperwork, and pay the > >yearly fees, yes. > > Either having very many people get /32s is harmful, or it isn't. How > does paying the RIPE fee move this from "harmful" to "non-harmful"? It reduces the possible amount of applicants from "anybody out there" (many billions) to "anybody who thinks this is so important to his heart / business that he's willing to shell out serious money for it". This makes quite a difference, especially as it's not "one time up-front" money, but recurring fees. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Apr 5 14:40:11 2005 From: gert at space.net (Gert Doering) Date: Tue, 5 Apr 2005 14:40:11 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <7eb1d338f663501cb3828e6949e173d5@muada.com> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> Message-ID: <20050405124011.GK84850@Space.Net> Hi, On Tue, Apr 05, 2005 at 02:17:21PM +0200, Iljitsch van Beijnum wrote: > The IETF has worked long and hard on multihoming without PI. It would > be superbly stupid to throw all of that away with the finish line in > sight and forever increase the cost of routing just so lazy people can > get away with hardcoding IPv6 addresses in their access lists. I'm not sure how this ongoing discussion relates to *access lists*? We're talking about networks like: - large-scale networks that have only BGP customers that already have their own address space (so "no 200 /48 given to customers") - 3GPP networks that assign /64s (so it's no "/48s" given to customers) - smallish ISPs that could be a good driver for new IPv6 products (because they are not old, rusty, and refusing anything new) but do not yet have 200 customers, but maybe 30 very large ones... etc. None of these can be helped with the end-user-multihoming solutions developed by the IETF (which are important, of course). (In case you haven't noticed: there are a number of different policy proposals being discussed in parallel. Please put your attacks regarding "access-list lazyness" into the correct discussion, wherever that might be) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From oliver at bartels.de Tue Apr 5 14:40:18 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 14:40:18 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <7eb1d338f663501cb3828e6949e173d5@muada.com> Message-ID: <200504051240.j35CeHe5001162@alpha.bartels.de> On Tue, 5 Apr 2005 14:17:21 +0200, Iljitsch van Beijnum wrote: >The IETF has worked long and hard on multihoming without PI. ... and still has no solution since years and there won't be a solution. At the end there is always an address and packets which require routing to said address. And this can't be done by papers, policies and oposition against everything. But it can be done by installing such little boxes called routers. Please explain: What do *you* *today* propose as a *complete* technical solution to handle the customer demand called PI ? Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From oliver at bartels.de Tue Apr 5 14:46:01 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 14:46:01 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405122751.GA26638@srv01.cluenet.de> Message-ID: <200504051245.j35Cjwe5001296@alpha.bartels.de> On Tue, 5 Apr 2005 14:27:51 +0200, Daniel Roesen wrote: >Name the engineering problems of end-user PI. (Un)fortunately nobody >was yet able to show convincing prove that there IS a problem. Stop >FUDding. Full Ack. And no router vendor would be so stupid and blame itself not beeing able to route additional 20K IPv6 prefixes. >IETF is nowhere near any solution. They are as far away from it as they >can be. Will probably take another few years to finally realize that. Full Ack. The reason is fundamental and it is not a good idea to make policies against mathematical and physical laws ... >A sensible "separated locator and idenfication" approach would need a >complete revamp of the operating model and (and that's the big thing) >operating systems L3/L4 stacks. Won't happen, so shim6 will be a crude >hack, attacking only part of the requirement space. Full Ack. At the end of the day, there is the unique and globally routable address. We already *have* a "separated locator and idenfication" system, it is called DNS. The advantages and disadvantages are well known. Greetings Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From iljitsch at muada.com Tue Apr 5 14:49:24 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 14:49:24 +0200 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy In-Reply-To: References: Message-ID: <92047af0b5c6b2556df0f3aa1a684756@muada.com> On 4-apr-05, at 18:18, Andreas B??/Denic wrote: > 1. Is there a need for anycasting at all ? > I was surprised to see this question on the list. > I think that anycasted nameservers are an accepted standard and there > is no need to discuss pros and cons anymore. Well, certainly not here. But if this is your question, answering it is easy: no, there is no NEED. Whether it's useful in a particular case is something different. > 2. /32 vs. /48 V6 prefix - routability aspect There are incorrect documents published which suggest that filtering at /32 is ok. After changing these documents and waiting some time this should no longer be an issue. BTW, from RFC 3513: 2.6 Anycast Addresses [...] For any assigned anycast address, there is a longest prefix P of that address that identifies the topological region in which all interfaces belonging to that anycast address reside. Within the region identified by P, the anycast address must be maintained as a separate entry in the routing system (commonly referred to as a "host route"); outside the region identified by P, the anycast address may be aggregated into the routing entry for prefix P. Note that in the worst case, the prefix P of an anycast set may be the null prefix, i.e., the members of the set may have no topological locality. In that case, the anycast address must be maintained as a separate routing entry throughout the entire internet, which presents a severe scaling limit on how many such "global" anycast sets may be supported. Therefore, it is expected that support for global anycast sets may be unavailable or very restricted. > 3. /32 vs. /48 V6 prefix - address conservation aspect > There is no question that a /32 is quite a big block and that this > sacrifice > to "ensure" reachability from most network places is worth it. There is at least a question here, even if we agree on the answer. However, it's not simply whether it's worth it or not, it's a question of doing the right thing. If we start changing allocation policies to accommodate laziness on the part of router operators, where does it end? > I don't think that sharing an assignment between multiple TLDs if they > outsource > their operation to an anycasting DNS provider should be a must to > separate > TLD operations from each other and that the extra address space spent > is a > good > thing keeping in mind the limited number of TLDs where talking about. Disagree. Resource conservation should be the default, this should only be changed when there is clear evidence that this is problematic. > Any comments or suggestions? Yes. I want to see a specific plan from the TLD community about what they want to do here. "Give us the prefixes" isn't good enough for me. From dr at cluenet.de Tue Apr 5 14:53:13 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 14:53:13 +0200 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy In-Reply-To: <92047af0b5c6b2556df0f3aa1a684756@muada.com> References: <92047af0b5c6b2556df0f3aa1a684756@muada.com> Message-ID: <20050405125313.GB26638@srv01.cluenet.de> On Tue, Apr 05, 2005 at 02:49:24PM +0200, Iljitsch van Beijnum wrote: > >2. /32 vs. /48 V6 prefix - routability aspect > > There are incorrect documents published which suggest that filtering at > /32 is ok. After changing these documents and waiting some time this > should no longer be an issue. Agreed. We're still in early stages. > >3. /32 vs. /48 V6 prefix - address conservation aspect > > >There is no question that a /32 is quite a big block and that this > >sacrifice > >to "ensure" reachability from most network places is worth it. > > There is at least a question here, even if we agree on the answer. > > However, it's not simply whether it's worth it or not, it's a question > of doing the right thing. If we start changing allocation policies to > accommodate laziness on the part of router operators, where does it > end? Agreed too. Sorry for such "agreed!" mails without more content, but when trying to find consensus, also expressed agreement is necessary. :-) Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Tue Apr 5 15:10:29 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:10:29 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504041910.j34JAAe5013129@alpha.bartels.de> References: <200504041910.j34JAAe5013129@alpha.bartels.de> Message-ID: Oliver, Would you please invest some time into discovering how grownups use email? The excessive funny interpunction hurts my eyes. On 4-apr-05, at 21:10, Oliver Bartels wrote: >> I'd rather see large routing tables rather than in 10 years time find >> we're >> running out of v6 space. Whatever we do, we're not going to run out of IPv6 space. Worst case, we have to start subdividing /64s and kill autoconfiguration, but that way we still have four billion times as many addresses in a single /64 as in the whole IPv4 internet. That said, the HD ratio and strange new ways to distribute from IANA to RIRs may eat up the bits from 3 - 47 much faster than we could have imagined at the time that IPv6 was designed, so we shouldn't waste v6 space like there is no tomorrow. Still, the routing table size problem is much more pressing than the depletion problem in IPv6 because even if the table size isn't fatal, it can get expensive easily, and when it gets fatal there is no way to fix it (even if we give up autoconfiguration). > Well, we will also see routers beeing capable to route more than > 150K prefixes. We can even see them today. Well, we're never going to run out of oil either, but at some point it's going to be so expensive to get it out of the ground that it's easier to leave it there and walk to work. I'm not sure what the cheapest router is that can handle a full table today, but I'm pretty sure it's more expensive than what one that could 10 years ago cost then (ie a Cisco 2501). > At these old days when these 64MB routers were designed, > RAM chips had 4 to 16 MBits of RAM. Today we are talking > about min. 256MBit SDRAM dies, smaller SDRAM's will have > their "call for last order" very soon now. Ah, but if you have N * 2 routing table entries, not only do you need 2 times the memory, but all else being equal you're going to see 2 times as many updates, so assuming you need to search N * 2 entries before you can update one (which fortunately isn't the case, the exact math is left as an excercise to the reader) you need 2 * 2 = 4 times as much memory bandwidth. It's not just a factor of more memory. > Again for multiv6: *There won't be a *full* and *unrestricted* > solution, > the we_want_multiv6_but_keep_BGP4 approach has fundamental > laws of math and computer science against it: > An *address* is an *address* and is spoken *address*, because it > addresses something, which means it guides something to a destination, > which does not mean that it just references something and let's > some unknown big wonder do the job ;-/ I have no idea what you're talking about here. > But it is possible, BGP4 is proven with existing products for appx. > 500K > prefixes, if more is needed, I would suggest thinking of an protocol > update. And what exactly would that update entail? The problem isn't BGP (although BGP has problems for sure) but the fundamental problem that if you can't derive the answer you're looking for from the information you already have, you'll have to go to the place where the information is kept. I.e., you need to search the routing table. > I do fully agree with Gert: > "because if IPv6 isn't going to take up soon, it's dead." I'm not sure how having a new techology available before the old technology implodes is a problem. From iljitsch at muada.com Tue Apr 5 15:18:22 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:18:22 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405122751.GA26638@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> Message-ID: <3e495f8a04b305dd382b91424ff18adf@muada.com> On 5-apr-05, at 14:27, Daniel Roesen wrote: >> And that's exactly the problem. This forum is more or less a marketing >> forum, and as such it's the wrong place to decide on these issues, as >> these are ENGINEERING tradeoffs. > Name the engineering problems of end-user PI. (Un)fortunately nobody > was yet able to show convincing prove that there IS a problem. Stop > FUDding. The problem is that PI isn't scalable. This is of course fine if you don't feel like scaling, but putting non-scalable aspects in technology that is supposed to be around for decades to come is a very dangerous and expensive game. > IETF is nowhere near any solution. They are as far away from it as they > can be. Believe me, they could have been much farther away from a solution. :-) > There is no REAL multihoming without PI yet. And the IETF recently > narrowed down the road they want to take (solution space) that > guarrantees that the result won't fit people's needs. The multi6=>shim6 > transition was (for me and quite a few others) the "end of all hope". Why? > A sensible "separated locator and idenfication" approach would need a > complete revamp of the operating model and (and that's the big thing) > operating systems L3/L4 stacks. Won't happen, so shim6 will be a crude > hack, attacking only part of the requirement space. Shim6 will deliver 80% of the functionality of a loc/id solution with 20% of the effort. There are plenty of hooks to attach the remaining functionality later, but making small steps first makes much more sense. From dr at cluenet.de Tue Apr 5 15:19:43 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 15:19:43 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <200504041910.j34JAAe5013129@alpha.bartels.de> Message-ID: <20050405131943.GC26638@srv01.cluenet.de> On Tue, Apr 05, 2005 at 03:10:29PM +0200, Iljitsch van Beijnum wrote: > I'm not sure what the cheapest router is that can handle a full table > today, but I'm pretty sure it's more expensive than what one that could > 10 years ago cost then (ie a Cisco 2501). A 50-EUR-off-Ebay PC can do that easily. And even if you go to the "off-the-shelf-real-routers" (actually not "routers", but "optimized forwarders with routing component") then you can have them quite cheaply... looking at JNPR J-Series and Cisco 1800 series that should be doable well below 2000 EUR. I doubt that the 2501 was much less expensive back then. :-) Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Tue Apr 5 15:20:45 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:20:45 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405123446.GJ84850@Space.Net> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> <20050404134844.GL84850@Space.Net> <6146a89cfc4b39e8994430b6f1c3a42a@muada.com> <20050405123446.GJ84850@Space.Net> Message-ID: <64d55db8d8ca39f354dc39abc788e79d@muada.com> On 5-apr-05, at 14:34, Gert Doering wrote: >> Either having very many people get /32s is harmful, or it isn't. How >> does paying the RIPE fee move this from "harmful" to "non-harmful"? > It reduces the possible amount of applicants from "anybody out there" > (many billions) to "anybody who thinks this is so important to his > heart / business that he's willing to shell out serious money for it". So you agree that an excessive number of prefixes is bad? Then the only thing we disagree about is whether the LIR fee will be enough to make the number non-excessive. It will at first, of course, but it's unlikely to do so in the long term as RIRs are not-for-profit so the more people become a LIR, the lower the fees become. From iljitsch at muada.com Tue Apr 5 15:28:13 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:28:13 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405124011.GK84850@Space.Net> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405124011.GK84850@Space.Net> Message-ID: On 5-apr-05, at 14:40, Gert Doering wrote: >> The IETF has worked long and hard on multihoming without PI. It would >> be superbly stupid to throw all of that away with the finish line in >> sight and forever increase the cost of routing just so lazy people can >> get away with hardcoding IPv6 addresses in their access lists. > I'm not sure how this ongoing discussion relates to *access lists*? They make renumbering hard. Many people want PI so they don't have to renumber. > We're talking about networks like: > - large-scale networks that have only BGP customers that already have > their own address space (so "no 200 /48 given to customers") How is this different from any other end-user? > - 3GPP networks that assign /64s (so it's no "/48s" given to > customers) I don't want no stinking /64. Give me a /48. > - smallish ISPs that could be a good driver for new IPv6 products > (because they are not old, rusty, and refusing anything new) but do > not yet have 200 customers, but maybe 30 very large ones... Show me some examples. I started an ISP with ~30 customers once and I don't think there are very many of those. They all tend to gravitate towards 0 customers or > 30 customers over time. > (In case you haven't noticed: there are a number of different policy > proposals being discussed in parallel. Please put your attacks > regarding > "access-list lazyness" into the correct discussion, wherever that > might be) Daniel was talking about PI here. Are you saying the above examples should use PI rather than PA? Doesn't make much sense to me. From iljitsch at muada.com Tue Apr 5 15:30:22 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:30:22 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504051240.j35CeHe5001162@alpha.bartels.de> References: <200504051240.j35CeHe5001162@alpha.bartels.de> Message-ID: <5f0396718f1a32f1ee3461bc705fba82@muada.com> On 5-apr-05, at 14:40, Oliver Bartels wrote: > Please explain: > What do *you* *today* propose as a *complete* technical solution > to handle the customer demand called PI ? Same thing I tell people who want to discover the IPv6 address of a DNS resolver, or want to talk to the root DNS servers over IPv6, or want to deploy mobile IPv6 or many other things: it's not ready yet, you'll have to wait a little bit longer. From dr at cluenet.de Tue Apr 5 15:33:06 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 15:33:06 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <64d55db8d8ca39f354dc39abc788e79d@muada.com> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> <20050404134844.GL84850@Space.Net> <6146a89cfc4b39e8994430b6f1c3a42a@muada.com> <20050405123446.GJ84850@Space.Net> <64d55db8d8ca39f354dc39abc788e79d@muada.com> Message-ID: <20050405133306.GD26638@srv01.cluenet.de> On Tue, Apr 05, 2005 at 03:20:45PM +0200, Iljitsch van Beijnum wrote: > >It reduces the possible amount of applicants from "anybody out there" > >(many billions) to "anybody who thinks this is so important to his > >heart / business that he's willing to shell out serious money for it". > > So you agree that an excessive number of prefixes is bad? What is excessive? Is it "anything as long as _I_ get my prefix"? > Then the only thing we disagree about is whether the LIR fee will be > enough to make the number non-excessive. It will at first, of course, > but it's unlikely to do so in the long term as RIRs are not-for-profit > so the more people become a LIR, the lower the fees become. And then there are the non-for-profit orgs who want to multihome properly. You want to keep them out because they don't have enough money to spend to RIRs for that, right? Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Tue Apr 5 15:37:49 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 15:37:49 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <3e495f8a04b305dd382b91424ff18adf@muada.com> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> Message-ID: <20050405133749.GE26638@srv01.cluenet.de> On Tue, Apr 05, 2005 at 03:18:22PM +0200, Iljitsch van Beijnum wrote: > The problem is that PI isn't scalable. It's as scalable as PA. There is no inherent difference in scaling how many ISPs there are to the number of end users. Both grow in similar progression. It's not like O(n) vs. O(n^2) or so. So now start backing your "isn't scalable" claim (in comparision to PA). And back that by hard numbers showing real problems. > >There is no REAL multihoming without PI yet. And the IETF recently > >narrowed down the road they want to take (solution space) that > >guarrantees that the result won't fit people's needs. The multi6=>shim6 > >transition was (for me and quite a few others) the "end of all hope". > > Why? Because the outcome won't provide what people do ask for. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Tue Apr 5 15:49:59 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:49:59 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405131943.GC26638@srv01.cluenet.de> References: <200504041910.j34JAAe5013129@alpha.bartels.de> <20050405131943.GC26638@srv01.cluenet.de> Message-ID: On 5-apr-05, at 15:19, Daniel Roesen wrote: >> I'm not sure what the cheapest router is that can handle a full table >> today, but I'm pretty sure it's more expensive than what one that >> could >> 10 years ago cost then (ie a Cisco 2501). > A 50-EUR-off-Ebay PC can do that easily. As Randy is fond of saying: I invite my competitors to do this. My experience with PC hardware routers is that they're fast and powerful, and fail 10 times as often as "real" routers so all the money you save on hardware is eaten up by operational expenses. > And even if you go to the > "off-the-shelf-real-routers" (actually not "routers", but "optimized > forwarders with routing component") then you can have them quite > cheaply... looking at JNPR J-Series and Cisco 1800 series that should > be doable well below 2000 EUR. > I doubt that the 2501 was much less expensive back then. :-) It was around that price. Ok I wasn't aware of the 1800 but this looks like a nice entry level BGP box. From oliver at bartels.de Tue Apr 5 15:50:42 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 15:50:42 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: Message-ID: <200504051350.j35Doce5002945@alpha.bartels.de> Dear Iljitsch, On Tue, 5 Apr 2005 15:10:29 +0200, Iljitsch van Beijnum wrote: >Would you please invest some time into discovering how grownups use >email? The excessive funny interpunction hurts my eyes. I would appreciate if you could stay with the subject and don't put things on the personal level. Doing so if arguments are missing is not a good idea. And please keep in mind that at least I am not a native English speaker. >Whatever we do, we're not going to run out of IPv6 space. Exact. >Still, the routing table size problem is much more pressing than the >depletion problem in IPv6 because even if the table size isn't fatal, >it can get expensive easily, and when it gets fatal there is no way to >fix it (even if we give up autoconfiguration). Stay with math: There are about 20K AS'es and much less RIPE members. Thus : How many prefixes will be out caused by the new policy ? ;-) >I'm not sure what the cheapest router is that can handle a full table >today, but I'm pretty sure it's more expensive than what one that could >10 years ago cost then (ie a Cisco 2501). The 2501 is for the museum. Any 50$ EBay PC is capable of handling >>200K routes. >Ah, but if you have N * 2 routing table entries, not only do you need 2 >times the memory, but all else being equal you're going to see 2 times >as many updates, so assuming you need to search N * 2 entries before >you can update one (which fortunately isn't the case, the exact math is >left as an excercise to the reader) you need 2 * 2 = 4 times as much >memory bandwidth. Believe me (we *developed our own BGP4 route server* down to the BGP packet level): Updates are not the problem on the memory bandwidth, a typical DRAM doesn't care about 100K memory accesses. We are talking of >>multiple GBit memory bandwidths. A significant load on the CPU arises if the *whole table* is dropped or rebuild due to some line going down or up. Most of the CPU power is required for policy calculations. However: At least our route server handles a complete 150K table in less than 1 second with complex policies. >I have no idea what you're talking about here. At the end we are talking about a complex (NP) shortest path problem which can't be solved by policies. *There is no way* to avoid the any-network-structure shortest-path calculation in a complex network. Not by multiv6 and *not by any other approach*. Routers can only be replaced by routers. >I'm not sure how having a new techology available before the old >technology implodes is a problem. If old technolgy means 10 year old 2501, then it is good when it implodes and providers are forced to invest into state-of-the-art hardware if they want to offer state-of-the-art services. Noone is forced to offer IPv6 services and there will be a very long transition period. But we can't make the rules for the system of tommorow based on limits imposed by technology of the day before yesterday, Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From iljitsch at muada.com Tue Apr 5 15:54:33 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 5 Apr 2005 15:54:33 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405133749.GE26638@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> Message-ID: <3656085ad69e4a195c091cee91ed6d7a@muada.com> On 5-apr-05, at 15:37, Daniel Roesen wrote: >> The problem is that PI isn't scalable. > It's as scalable as PA. There is no inherent difference in scaling how > many ISPs there are to the number of end users. Both grow in similar > progression. It's not like O(n) vs. O(n^2) or so. I grant you that there is no difference whether 10000 ISPs inject 10000 PA prefixes or 10000 end-users inject 10000 PI prefixes, but I hardly think the potential number of ISPs is similar to the potential number of end-users. (Or the actual number for both, your pick.) > So now start backing your "isn't scalable" claim (in comparision to > PA). > And back that by hard numbers showing real problems. Didn't you read my message about memory bandwidth? If that isn't real enough for you then this discussion is moot because we're obviously operating on different time scales. >>> There is no REAL multihoming without PI yet. And the IETF recently >>> narrowed down the road they want to take (solution space) that >>> guarrantees that the result won't fit people's needs. The >>> multi6=>shim6 >>> transition was (for me and quite a few others) the "end of all hope". >> Why? > Because the outcome won't provide what people do ask for. And what are people asking for? From dr at cluenet.de Tue Apr 5 15:55:52 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 15:55:52 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <200504041910.j34JAAe5013129@alpha.bartels.de> <20050405131943.GC26638@srv01.cluenet.de> Message-ID: <20050405135552.GA27629@srv01.cluenet.de> On Tue, Apr 05, 2005 at 03:49:59PM +0200, Iljitsch van Beijnum wrote: > >>I'm not sure what the cheapest router is that can handle a full table > >>today, but I'm pretty sure it's more expensive than what one that > >>could > >>10 years ago cost then (ie a Cisco 2501). > > >A 50-EUR-off-Ebay PC can do that easily. > > As Randy is fond of saying: I invite my competitors to do this. > > My experience with PC hardware routers is that they're fast and > powerful, and fail 10 times as often as "real" routers so all the money > you save on hardware is eaten up by operational expenses. That was just a comment to finally arrive HERE: > >And even if you go to the > >"off-the-shelf-real-routers" (actually not "routers", but "optimized > >forwarders with routing component") then you can have them quite > >cheaply... looking at JNPR J-Series and Cisco 1800 series that should > >be doable well below 2000 EUR. My point is that the ROUTING (BGP) thing isn't the problem. Providing quick forwarding is what you pay huge amounts of money for. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From pekkas at netcore.fi Tue Apr 5 15:58:10 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 5 Apr 2005 16:58:10 +0300 (EEST) Subject: end-user PI issues [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <20050405122751.GA26638@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> Message-ID: On Tue, 5 Apr 2005, Daniel Roesen wrote: >> And that's exactly the problem. This forum is more or less a marketing >> forum, and as such it's the wrong place to decide on these issues, as >> these are ENGINEERING tradeoffs. > > Name the engineering problems of end-user PI. (Un)fortunately nobody > was yet able to show convincing prove that there IS a problem. Stop > FUDding. I for one don't want to see the routers CPUs' screaming red when a random brazilian ISP experiences a fiber cut and I see 5,000 v6 prefixes churning in most routers in the world because of that. PI to end-users => lots of processing on routers when those sites, their ISPs, transits, ..., experience failures. -- 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 Tue Apr 5 16:11:30 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 16:11:30 +0200 Subject: end-user PI issues [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: Message-ID: <200504051411.j35EBRe5003479@alpha.bartels.de> On Tue, 5 Apr 2005 16:58:10 +0300 (EEST), Pekka Savola wrote: >I for one don't want to see the routers CPUs' screaming red when a >random brazilian ISP experiences a fiber cut and I see 5,000 v6 >prefixes churning in most routers in the world because of that. You won't see it screaming red. Because the job is done in about <50ms and this is standard business *today*. A 5000 prefix update is what happens quite often e.g. if an exchange router is restarted. What happens: *Nothing*. *No impact at all*. Question: Do you intend to implement IPv6 and BGP on a 8080 CPU ? >PI to end-users => lots of processing on routers when those sites, >their ISPs, transits, ..., experience failures. Pi works today. Pleas stop FUDing. Best regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From dr at cluenet.de Tue Apr 5 16:14:51 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 5 Apr 2005 16:14:51 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <3656085ad69e4a195c091cee91ed6d7a@muada.com> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> Message-ID: <20050405141451.GA27819@srv01.cluenet.de> On Tue, Apr 05, 2005 at 03:54:33PM +0200, Iljitsch van Beijnum wrote: > On 5-apr-05, at 15:37, Daniel Roesen wrote: > > >>The problem is that PI isn't scalable. > > >It's as scalable as PA. There is no inherent difference in scaling how > >many ISPs there are to the number of end users. Both grow in similar > >progression. It's not like O(n) vs. O(n^2) or so. > > I grant you that there is no difference whether 10000 ISPs inject 10000 > PA prefixes or 10000 end-users inject 10000 PI prefixes, but I hardly > think the potential number of ISPs is similar to the potential number > of end-users. (Or the actual number for both, your pick.) Again: you are talking about theoretical worst-case absolute numbers. I'm talking about real life. I guess you would agree with me that it's currently no problem at all to obtain an ASN and IPv4 PI if you want to multihome. Right? This has lead to about 17k active ASN out there. Which translates to 17k-20k (let's give some headroom for special routes for anycast etc) IPv6 PA/PI routes. Where is your problem? I don't see multiple million of end sites doing BGP multihoming. Not now, not in ten years. It's not that we have hundred of thousand of NEW people JUST WAITING for the availability of PI out there. So, when do you estimate will we see let's say more than 100k active ASNs out there? And even then we're talking about 100k, not 1 million, not 10 million. > >So now start backing your "isn't scalable" claim (in comparision to > >PA). And back that by hard numbers showing real problems. > > Didn't you read my message about memory bandwidth? If that isn't real > enough for you then this discussion is moot because we're obviously > operating on different time scales. I'm not into hardware design so I won't comment on that. Oliver is much more qualified in that as he actually have built those things. :-) > >>>There is no REAL multihoming without PI yet. And the IETF recently > >>>narrowed down the road they want to take (solution space) that > >>>guarrantees that the result won't fit people's needs. The > >>>multi6=>shim6 > >>>transition was (for me and quite a few others) the "end of all hope". > > >>Why? > > >Because the outcome won't provide what people do ask for. > > And what are people asking for? At least the same set of features as IPv4 PI BGP multihoming with no new added significant downsides. Perhaps folks should start listening to that instead of sticking the head into the sand. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From narten at us.ibm.com Tue Apr 5 16:26:23 2005 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 05 Apr 2005 10:26:23 -0400 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: Message from jeroen@unfix.org of "Mon, 04 Apr 2005 21:27:59 +0200." <1112642879.28943.1.camel@firenze.zurich.ibm.com> Message-ID: <200504051426.j35EQN3r017325@rotala.raleigh.ibm.com> > If these policies cause 2000::/3 to be exhausted then there are 7 more > tries left to do it all over again. No. If we find that 2000::/3 is not enough, we've botched things badly through poor choices made today. Using the remaining space a long ways from now (e.g, in 30? 50 years?) would perhaps be OK. Needing to use it anytime in the next 10-20 years means we've botched it. Thomas From slz at baycix.de Tue Apr 5 16:27:41 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 05 Apr 2005 16:27:41 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405141451.GA27819@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> Message-ID: <4252A05D.903@baycix.de> Hay, Daniel Roesen wrote: [...] > Again: you are talking about theoretical worst-case absolute numbers. > I'm talking about real life. > > I guess you would agree with me that it's currently no problem at all > to obtain an ASN and IPv4 PI if you want to multihome. Right? > This has lead to about 17k active ASN out there. Which translates to > 17k-20k (let's give some headroom for special routes for anycast etc) > IPv6 PA/PI routes. Where is your problem? I don't see multiple million > of end sites doing BGP multihoming. Not now, not in ten years. It's > not that we have hundred of thousand of NEW people JUST WAITING for the > availability of PI out there. > > So, when do you estimate will we see let's say more than 100k active > ASNs out there? And even then we're talking about 100k, not 1 million, > not 10 million. > once again: FullACK. ...but i certainly get tired having that specific discussion with always the same specific arguments every few months, so no much motivation for writing anything more than "FullACK" ATM. But probably it's better than saying nothing at all on that topic (like most people who might not even care). [...] >>>>>There is no REAL multihoming without PI yet. And the IETF recently >>>>>narrowed down the road they want to take (solution space) that >>>>>guarrantees that the result won't fit people's needs. The >>>>>multi6=>shim6 >>>>>transition was (for me and quite a few others) the "end of all hope". >> >>>>Why? >> >>>Because the outcome won't provide what people do ask for. >> >>And what are people asking for? > > > At least the same set of features as IPv4 PI BGP multihoming with no > new added significant downsides. > > Perhaps folks should start listening to that instead of sticking the > head into the sand. Time will tell, there either will be PI Space (like in the IPv4 world), or IPv6 won't get any relevance in "the Internet" within the next 20years (IMNSHO). If some folks want to stick their heads in the sand - let them. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From narten at us.ibm.com Tue Apr 5 16:32:23 2005 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 05 Apr 2005 10:32:23 -0400 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: Message from jon@lawrence.org.uk of "Tue, 05 Apr 2005 10:00:22 BST." <200504051000.22807.jon@lawrence.org.uk> Message-ID: <200504051432.j35EWNm1017382@rotala.raleigh.ibm.com> Jon Lawrence writes: > Is the number of routing table entries an issue ? only the > manufacturers can possibly tell us what routers may be able to > handle in 10 years time. That's not the whole story. I've heard on more than one occasion that there was another important component to the scaling question: operational management complexity. Technology won't necessarily solve that. Thomas From narten at us.ibm.com Tue Apr 5 16:39:29 2005 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 05 Apr 2005 10:39:29 -0400 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: Message from Michael.Dillon@radianz.com of "Tue, 05 Apr 2005 11:00:11 BST." Message-ID: <200504051439.j35EdTmv017405@rotala.raleigh.ibm.com> Michael.Dillon at radianz.com writes: > > If these policies cause 2000::/3 to be exhausted then there are 7 more > > tries left to do it all over again. > This is the essential characteristic of IPv6 that so many > of us, weaned on IPv4, seem to forget. We need to keep this > fact uppermost in our minds at all times. Even this subset > of IPv6 is much bigger than the IPv4 space. So we can afford > to be generous and, in fact, we can afford to make mistakes. > If we err, we should err on the side of being slightly too > generous because if 2000::/3 runs out, we can try again, > older but wiser. I have a very basic problem with this view point. It becomes an excuse to brush aside serious concerns about a particular policy under the "well, if we botch it, we can try again later" argument. It's one thing to have a fall back plan to deal with unforeseen problems. It's quite another to recklessly move in a direction with significant long-term implications just because "we can always try again later". > This means that we should not be excessively concerned with > conserving address space or wasting addresses. It is entirely > appropriate to give a /32 to anyone who might be some sort > of an ISP, either traditional or some new type, like Google > or BMW or Cadburys. And, do you have an estimate of how many such "ISPs" exist today, or will exist in 10-20 years? E.g., are we talking about 10,000 entities (not scary), or 1 million (scary to me). Thomas From woeber at cc.univie.ac.at Tue Apr 5 16:53:23 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 05 Apr 2005 16:53:23 +0200 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy Message-ID: <00A41D88.71307E72.41@cc.univie.ac.at> >2. /32 vs. /48 V6 prefix - routability aspect > >From a routing table perspective there is no difference if the prefix is >longer or shorter. Well, for those so keen on preserving the last bit of memory, a _shorter_ prefix would actually be more efficient ;-) > When asking around which prefix length would have a good chance to >ensure the goal of not beeing filtered I have felt consensus that a /32 >has by far the best chances. However I'm considering if it wouldn't be >best to declare a /32 microallocation block from which RIPE will assign >/48 blocks. Other than the goal of conservation (which we have beaten to death already) what is the benefit of doing that? Administrative ease to collate them from the database? I would be be more worried abut the potential of taking the whole block down in one big sweep by misconfiguration and/or leaking announcements. But maybe this isn't an issue in the world of anycast for "critical" DNS services. Otoh, for those who don't like the concept, it would make it easier to cut off connectivty to those segments by entering just 1 filter... Wilfried. From Michael.Dillon at radianz.com Tue Apr 5 17:10:56 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 5 Apr 2005 16:10:56 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504051439.j35EdTmv017405@rotala.raleigh.ibm.com> Message-ID: > It's one thing to have a fall back plan to deal with unforeseen > problems. It's quite another to recklessly move in a direction with > significant long-term implications just because "we can always try > again later". I believe that the long term implications of growing the routing table to avoid minor waste of IPv6 address space, are much more significant and worrying that the other way around. Or, to restate it the other way around, if conserving IPv6 address space causes the global routing table to grow bigger (either in entries or bits) then we risk creating problems that we do not know how to solve. However, we do know how to solve the problem of wasting too much IPv6 address space. We either extend 2000::/3 by one more bit, or we transition to a different IPv6 addressing plan. > > This means that we should not be excessively concerned with > > conserving address space or wasting addresses. It is entirely > > appropriate to give a /32 to anyone who might be some sort > > of an ISP, either traditional or some new type, like Google > > or BMW or Cadburys. > > And, do you have an estimate of how many such "ISPs" exist today, or > will exist in 10-20 years? E.g., are we talking about 10,000 entities > (not scary), or 1 million (scary to me). The point that I am making is that the ISPs of today (and the future) do not necessarily follow the same business model as the ISPs of yesterday. In the 1990's it was reasonable to define an ISP as an organization that connects 200 or more customers. That is no longer reasonable and it should be removed. If people are concerned about exponential demand for /32s then the policy change can incorporate a limit and a review period, i.e. no more than 3000 new /32's without reviewing this policy. However, all of the "ISPs" that don't fit in the current model, have something in common. They provide a service to many different physical locations or to large numbers of users. Because of this, the number of such "ISPs" will tend to be closer to 10,000 entities than to 1 million. The 200 new customer limit was meant to be a measure of largeness and seriousness. I think that in today's world, that measure fails to do the job. However, the recurring RIPE fees, do continue to serve as a measurement of size and seriousness. Assuming that we have a process for recovering IPv6 addresses from customers who cease to pay the recurring fees, I don't see that there is a problem with simplifying the policy. --Michael Dillon From randy at psg.com Tue Apr 5 18:28:36 2005 From: randy at psg.com (Randy Bush) Date: Tue, 5 Apr 2005 06:28:36 -1000 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria References: <16977.53218.266593.318146@roam.psg.com> <200504050538.j355c9e5021695@alpha.bartels.de> <16978.9784.177929.791108@roam.psg.com> <20050405081812.GA84850@Space.Net> Message-ID: <16978.48308.569971.323730@roam.psg.com> >>>> gert, i am too busy to find the quote for you right now, but >>>> the essence is that EVERY size limit that has EVER been done >>>> in computing has proved to be to small in the long run. >>> It has also been proven that EVERY memory size problem >>> has been solved so far. >> by changing the addressing. and that is exactly where we got >> into trouble last time. and our grandchildren will have the >> same problem again. > So what do *you* propose to do now? go back to paying work. if we need to give away large blocks to get folk to even ask for something that they don't seem to actually use anyway, then i think ipv6 has other issues that are a lot more pressing. > (On the math thing: you conveniently ignored my argument that > we'll run into other limits *far* earlier than into the depletion > of /32s - and unless *those* are solved, address depletion by > handing out routable /32s really is a non-issue) in ipv4, we have fixed routing many times. this is why the ivtf politicians allowed v6 to be decided independent of routing. they really believe these other issues can be fixed as we go along. as we're not really going along, we really don't know how true this is. randy From randy at psg.com Tue Apr 5 18:50:42 2005 From: randy at psg.com (Randy Bush) Date: Tue, 5 Apr 2005 06:50:42 -1000 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> Message-ID: <16978.49634.860916.791089@roam.psg.com> > On Tue, Apr 05, 2005 at 11:00:11AM +0100, Michael.Dillon at radianz.com wrote: >> Now, a set of IPv6 policies in which no globally routable >> prefixes are longer than /32 allows router manufacturers >> to optimize memory usage and design router tables to only >> carry those 32 bits of the IPv6 address. > We don't have those policies. Supposed-to-be-globally-routable /48s do > already exist. heck, the fatal flaw with this clueles idiocy is that we don't want vendors hard coding anything like this. remember when a/b/c were hard coded in routers and in rip? of the stupid ideas we seem bent on repeating, this seems one of the worst. randy From randy at psg.com Tue Apr 5 19:03:25 2005 From: randy at psg.com (Randy Bush) Date: Tue, 5 Apr 2005 07:03:25 -1000 Subject: end-user PI issues [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> Message-ID: <16978.50397.614556.323629@roam.psg.com> > I for one don't want to see the routers CPUs' screaming red when a > random brazilian ISP experiences a fiber cut and I see 5,000 v6 > prefixes churning in most routers in the world because of that. > > PI to end-users => lots of processing on routers when those sites, > their ISPs, transits, ..., experience failures. but that's what the users WANTED. and we have to give them what they want, even if it poisons them and the rest of the world because they don't understand the long term scaling implications. if we don't, ipv6 won't sell, and this is the ipv6 marketing dept, ya? randy From pekkas at netcore.fi Tue Apr 5 22:07:12 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 5 Apr 2005 23:07:12 +0300 (EEST) Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504051426.j35EQN3r017325@rotala.raleigh.ibm.com> References: <200504051426.j35EQN3r017325@rotala.raleigh.ibm.com> Message-ID: On Tue, 5 Apr 2005, Thomas Narten wrote: >> If these policies cause 2000::/3 to be exhausted then there are 7 more >> tries left to do it all over again. > > No. If we find that 2000::/3 is not enough, we've botched things badly > through poor choices made today. Yup. Just think about the 6bone address space. It's a bit unlikely that the address space gets exhausted, but it just might that at some point we would start thinking, "gee.. we really allocated these addresses badly. let's start from scratch. *those who already got addresses from the old block need to renumber*" It's not so much exhaustion I'm worried about, it's the huge amount of crap (which we later might call "legacy allocations") we could end up with. -- 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 pekkas at netcore.fi Tue Apr 5 22:13:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 5 Apr 2005 23:13:59 +0300 (EEST) Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: References: Message-ID: On Tue, 5 Apr 2005 Michael.Dillon at radianz.com wrote: > In the 1990's it was reasonable to define an ISP as an organization > that connects 200 or more customers. That is no longer reasonable and > it should be removed. [...] ... > The 200 new customer limit was meant to be a measure of largeness and > seriousness. I think that in today's world, that measure fails to do > the job. Could you clarify, why do you think "200 customers" fails as a meter for largeness ? There are some odder cases like transit only ISPs (which technically could only have very few direct organizational customers -- let's assume that those would get the IP space using some other provisions or as a matter of interpretation), but apart from that, why exactly is requiring 200 customers unreasonable? Are you referring to e.g., webhosting ISPs which don't have end-users (dialup, DSL, etc.) customers ? What do you think would be a reasonable bar then? -- 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 Tue Apr 5 23:51:21 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 05 Apr 2005 23:51:21 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: Message-ID: <200504052151.j35LpJe5014039@alpha.bartels.de> On Tue, 5 Apr 2005 23:13:59 +0300 (EEST), Pekka Savola wrote: >Could you clarify, why do you think "200 customers" fails as a meter >for largeness ? Pekka, just one question: Do you really think big is good, small is bad, and just the big ISP's will promote IPv6 ? There is one point I don't understand in the whole discussion: If every RIPE member get's an IPv6 prefix, which is true for IPv4, we are talking about plus 10K prefixes in the table. This is *nothing* compared to a single de-aggregation action of clueless over-the-ocean ISP's which indeed happend and is *proven* to be managable by the existing routers. Thus *there is no technical reason at all* to keep the rule and force smaller ISP's to promise "plans" that won't get reality or put them as "second class" RIPE members into some sort of dependency of an larger RIPE member. There is also *enough* IPv6 address space, the IPv6 was designed that way. * I like clear words: If there is no technical reason at all, could one of the promoters of the 200 customers pseudo rule please explain the *true* reasons for this "we simply don't like this" opposition. I can't withhold my impression and disapointment that some behind-the-wall "arguments" for this rule are just of anti-competitive nature and that large ISP's simply think they can force smaller ISP's into some sort of dependency to keep the market clean in their sense ?!? Do people *really* think this approach works and do they really think that such an anti-competitive 200 customer policy - does neither hit IPv6 and the idea behind it - does not hit community - will not be forced down by EU commission authorities ?!? Sorry for this clear and open words. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From randy at psg.com Wed Apr 6 00:11:26 2005 From: randy at psg.com (Randy Bush) Date: Tue, 5 Apr 2005 12:11:26 -1000 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] References: <200504052151.j35LpJe5014039@alpha.bartels.de> Message-ID: <16979.3342.36030.67554@roam.psg.com> > Do you really think big is good, small is bad, and just the > big ISP's will promote IPv6 ? go to the ipv6 forum or whatever to discuss promoting ipv6. here, we're trying to figure out how to do prudent and responsible engineering so that this thing will scale for 50+ years if anyone decides to use it. randy From pekkas at netcore.fi Wed Apr 6 00:40:24 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Apr 2005 01:40:24 +0300 (EEST) Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405141451.GA27819@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> Message-ID: On Tue, 5 Apr 2005, Daniel Roesen wrote: > I guess you would agree with me that it's currently no problem at all > to obtain an ASN and IPv4 PI if you want to multihome. Right? Umm. The proposed v6 policy seems weaker than that? AFAIR, you'll have to justify half of the v4 address space.. and you don't even need to do that to get a v6 block ? -- 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 pekkas at netcore.fi Wed Apr 6 00:48:23 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Apr 2005 01:48:23 +0300 (EEST) Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <200504052151.j35LpJe5014039@alpha.bartels.de> References: <200504052151.j35LpJe5014039@alpha.bartels.de> Message-ID: On Tue, 5 Apr 2005, Oliver Bartels wrote: > On Tue, 5 Apr 2005 23:13:59 +0300 (EEST), Pekka Savola wrote: >> Could you clarify, why do you think "200 customers" fails as a meter >> for largeness ? > > Do you really think big is good, small is bad, and just the > big ISP's will promote IPv6 ? [...] Why do you think you require a /32 to "promote IPv6". Don't answer.. it was a rhetoric question :) My own, small consulting company (with dozens of customers) can certainly promote v6, but I have no delusions of grandeour that it would be best from the global perspective to allow such or even larger companies, whether calling themselves ISPs or not, to obtain a /32. Is a bit of unselfishness too much to ask ? -- 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 jorgen at hovland.cx Wed Apr 6 01:37:28 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 06 Apr 2005 00:37:28 +0100 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] References: <200504052151.j35LpJe5014039@alpha.bartels.de> Message-ID: <002001c53a38$6e4a2660$0700000a@jhw> ----- Original Message ----- From: "Oliver Bartels" > There is one point I don't understand in the whole discussion: > If every RIPE member get's an IPv6 prefix, which is true for IPv4, > we are talking about plus 10K prefixes in the table. > > This is *nothing* compared to a single de-aggregation action > of clueless over-the-ocean ISP's which indeed happend > and is *proven* to be managable by the existing routers. > > Thus *there is no technical reason at all* to keep the rule > and force smaller ISP's to promise "plans" that won't get > reality or put them as "second class" RIPE members into > some sort of dependency of an larger RIPE member. > There is also *enough* IPv6 address space, > the IPv6 was designed that way. > > * I like clear words: > > If there is no technical reason at all, could one of the promoters > of the 200 customers pseudo rule please explain the *true* > reasons for this "we simply don't like this" opposition. > Hi I don't think anyone can give you a good reason. There is no such thing as technical limitations/reasons, only economical. I don't see an economical reason for why normal network providers shouldn't be able to handle 500,000 IPv6 routes. Very many more routes than the 150k of today will increase the cost of equipment. Which firms would this affect the most, the smaller or the larger ones? I believe equally, but the initial cost of setting up multihoming would surely increase in the long run. Existing operators may need to upgrade something or they have to downgrade to singlehoming if they do not wish to upgrade. With that in mind, isn't this what you are looking for: A natural way to limit the amount of multihomed autonomous systems/amount of prefixes without enforcing unreasonable policies? As for scaling I am sure this will scale fine until next IP and/or routing protocol. Allocate today, let the economics do all the work tomorrow. IPv6 won't survive if you keep having silly policies (and I still think that includes the fixed size /48 customer assignment policy). Joergen Hovland ENK From dr at cluenet.de Wed Apr 6 02:22:00 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 6 Apr 2005 02:22:00 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> Message-ID: <20050406002200.GA1339@srv01.cluenet.de> On Wed, Apr 06, 2005 at 01:40:24AM +0300, Pekka Savola wrote: > On Tue, 5 Apr 2005, Daniel Roesen wrote: > >I guess you would agree with me that it's currently no problem at all > >to obtain an ASN and IPv4 PI if you want to multihome. Right? > > Umm. The proposed v6 policy seems weaker than that? No, it's still too strict. It excludes "end sites" (for whatever values of that... looking at the some recent RIPE region allocations, even outspoken consulting firms with no ISP operation visible can get /32s under current policy). In IPv4, you as an end site can get an ASN and PI space without being a LIR. And that makes total sense, as an end site is not a Local Internet REGISTRY. There is no steady ongoing human work to be done (hostmaster services), there is just a one-time registration of a prefix and ASN which is being paid by the sponsoring LIR via the scoring algo (ASNs even paid yearly IIRC). I see no good reason to handle that different in IPv6 world. In IPv4, it's enough to have a valid TECHNICAL reason to need an ASN (multihoming), and you get one. Same goes for a PI. You need addresses, you get addresses. All you need is a sponsoring LIR (which you usually pay for that service, directly or indirectly). And now in IPv6 with an address space of 128 bits compared to 32 bits you suddenly say that "needing address space" is not a good enough reason anymore? > AFAIR, you'll have to justify half of the v4 address space.. and you > don't even need to do that to get a v6 block ? Even for IPv4 allocations to LIRs you don't need to justify anything anymore (aside needing any IPv4 space *g*). https://www.ripe.net/ripe/docs/ripe-324.html#first_alloc /21 without questions asked. The key difference between the proposed changed IPv6 alloc policy and the IPv4 alloc policy is that the latter doesn't exclude end sites (formerly called "enterprise LIRs"). What we have in IPv4 is two types of end sites: those who get PI space and those who like to sponsor RIPE with more money and become LIR, receive their initial alloc, do their first and single assignment and be done with it. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jon at lawrence.org.uk Wed Apr 6 03:13:40 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Wed, 6 Apr 2005 02:13:40 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050406002200.GA1339@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050406002200.GA1339@srv01.cluenet.de> Message-ID: <200504060213.41011.jon@lawrence.org.uk> On Wednesday 06 April 2005 01:22, Daniel Roesen wrote: > > > In IPv4, it's enough to have a valid TECHNICAL reason to need an ASN > (multihoming), and you get one. Same goes for a PI. You need addresses, > you get addresses. All you need is a sponsoring LIR (which you usually > pay for that service, directly or indirectly). And now in IPv6 with > an address space of 128 bits compared to 32 bits you suddenly say that > "needing address space" is not a good enough reason anymore? > erm, no. Feel free to correct me if I'm wrong, but you cannot use multihoming as a sole technical reason for PI space in the RIPE region - you've still to justify a /24. I agree with most of what you are saying Daniel. My personal opinion (after far too much wine) is that the routers will probably be able to cope with anything that is thrown at them (again, I don't have the facts to back this statement up nor the knowledge to work it out - so don't ask for them Randy, other people know far more about what's on the horizon that I could ever hope to). Iljitsch, if you choose to take full routes then the cost of memory etc is you're burden - that after all is the perk of being a provider - whether you pass it on is entirely up to you. What I think we're talking about is: 1) free for all - not a good idea, which I think everyone agrees on. 2) a compromise between routing table growth and 1), which needs policies, which in turn must be set by the RIR's. I still think policy shouldn't be made until we know for certain exactly what multi6 are proposing (shim6 or whatever) and we need to see it in writing so to speak (ie they produce the actual docs) - the routers will cope I've already said, but that doesn't mean I believe in a free for all. Throwing out conservation just because the v6 address range is so vast is plain stupidity - the past, in my mind, exists for one reason, so that we can learn from it (I might not, but that's a personal problem or at least SWMBO tells me so). ISP's might need a /32 (doubtful in most cases) but enterprises DO NOT. Yes, enterprises need to multihome (same as ISP's do) but they do not need nor will they ever need a /32 (or even a /48 for that matter). How many enterprises currently use a class 'A' in current v4 space - and I mean really use - I think that question answers itself. If the routing table grows, then surely that's part of being a provider. Iljisch, who pays for it ? - you do. And ultimately, your customers. So that's unfair to customers, so what that's life. Should we open up RIPE address space to anyone who can afford to pay and can justify the address usage - erm, sorry but, that's already the situation. You want PA space and can afford it, then you can afford to pay someone who can get it - EOS - it's not hard to justify space, a lot of hassle and creative thinking maybees but not hard. I've had far too much to drink and I don't see a need to waste address space a second time. IMHO the routers will be able to handle the growth. The providers will pass the cost of routing on (so what if that leads to a consolidation of the ISP market - it's going to happen anyway) and the world will go on, but at the end of the day v6 must happen and for that to occur we need a multi-homing solution which when it boils down to it, is what this is all about. Jon From oliver at bartels.de Wed Apr 6 08:30:31 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 06 Apr 2005 08:30:31 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: Message-ID: <200504060630.j366URe5021339@alpha.bartels.de> On Wed, 6 Apr 2005 01:48:23 +0300 (EEST), Pekka Savola wrote: >Why do you think you require a /32 to "promote IPv6". Don't answer.. >it was a rhetoric question :) No, it isn't rhetoric. For our company we require a *unique* *globally* and under our AS with definition of an AS ("own policy") routable address space. I don't care about the exact size. However I do care that it should be independent from other ISP's and upstreams as the market laws make everything else very bad. We cannot afford giving up the competition between suppliers for our upstream traffic and we cannot afford giving up the investments in connection to internet exchanges and to become dependent from the mercy of a single supplier. Thus I can clearly tell you that without independently routable address space we will not introduce IPv6 within our network. Period. Which means no IPv6 reachability for serveral well known services. And as no customer is asking for it it won't come up. >My own, small consulting company (with dozens of customers) can >certainly promote v6, but I have no delusions of grandeour that it >would be best from the global perspective to allow such or even larger >companies, whether calling themselves ISPs or not, to obtain a /32. *Please* *do math*. You probably do this when you provide consulting, too ? A /32 is the 0.000 000 000 233 part of the IPv6 address space. This is what *anyone* who asks and who don't asks receives as a mininmum assignment today because this is exactly the equivalent of *one IPv4 address* and is *required* to provide a full service connection to the internet. And thus it should be affordable to give this size to a company *providing ISP services to customers*. >Is a bit of unselfishness too much to ask ? No, and you got the answer. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From oliver at bartels.de Wed Apr 6 08:53:32 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 06 Apr 2005 08:53:32 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <16979.3342.36030.67554@roam.psg.com> Message-ID: <200504060653.j366rWe5021628@alpha.bartels.de> On Tue, 5 Apr 2005 12:11:26 -1000, Randy Bush wrote: >go to the ipv6 forum or whatever to discuss promoting ipv6. here, >we're trying to figure out how to do prudent and responsible >engineering so that this thing will scale for 50+ years if anyone >decides to use it. Aha. Do I see this right that we have list members here who are clever enough to *exactly* know what will happen with network technology in the next 50 years propably because of some intuition given personally by Him to them ? And from the discussion it sounds like He told them to pray that every household should become a RIPE NCC member and thus IPv6 address space is in great danger. No math please, no facts, just *believe and pray* :-( Btw.: I estimate about <<1 Mio. households within the RIPE NCC region. Even if there is a /32 for each household, still <1/1000 part of the IPv6 address space is given up. And when using advanced routers of today, even a routing table with 1 Mio. entries would be *possible*. It would have some economical impact, yes, of course. But it is *possible*. Clearly within a 50 years range from now ;-) But I can tell you for sure that neither my parents nor my neighbour (pet doc.) will not open an ISP as home business and thus won't apply for RIPE NCC membership, thus 999998 table entries will be sufficient with the new gamma policy proposal. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From EricS at t-com.net Wed Apr 6 08:51:11 2005 From: EricS at t-com.net (Erics) Date: Wed, 6 Apr 2005 08:51:11 +0200 Subject: [address-policy-wg] HD ratio policy proposal Message-ID: Dear colleagues, we think the IPv4-HD-Ratio is a good instrument for LIRs to manage the demand of address space. Especially in view of their internal topologies. Even though it may have some limited impact to address space consumption we support this proposal. Kind regards Eric - for de.telekom From pekkas at netcore.fi Wed Apr 6 09:50:42 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Apr 2005 10:50:42 +0300 (EEST) Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <200504060653.j366rWe5021628@alpha.bartels.de> References: <200504060653.j366rWe5021628@alpha.bartels.de> Message-ID: On Wed, 6 Apr 2005, Oliver Bartels wrote: > And from the discussion it sounds like He told them to > pray that every household should become a RIPE NCC > member and thus IPv6 address space is in great danger. > > No math please, no facts, just *believe and pray* :-( > > Btw.: I estimate about <<1 Mio. households within the > RIPE NCC region. Even if there is a /32 for each > household, still <1/1000 part of the IPv6 address space > is given up. Please re-do your math. Germany also has, what 80 or 100 million people? Would it be safe to say that equates, to, at least 30 Mio households. Do the math globally and we're maybe at 2 billion households. -- 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 elmi at 4ever.de Wed Apr 6 10:50:27 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 6 Apr 2005 10:50:27 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: References: <200504052151.j35LpJe5014039@alpha.bartels.de> Message-ID: <20050406085027.GN43805@new.detebe.org> pekkas at netcore.fi (Pekka Savola) wrote: > >Do you really think big is good, small is bad, and just the > >big ISP's will promote IPv6 ? [...] > > Why do you think you require a /32 to "promote IPv6". Don't answer.. > it was a rhetoric question :) I'm not sure whether you've gotten notice of the issue not being the size, but access to a prefix _at all_. Your sarcasm seems out of place... > My own, small consulting company (with dozens of customers) can > certainly promote v6, but I have no delusions of grandeour that it > would be best from the global perspective to allow such or even larger > companies, whether calling themselves ISPs or not, to obtain a /32. Would you - if I may ask - believe "such or even larger companies" to be eligible for an independently routable prefix at all, or, more clearly spoken, eligible for a slot int the global routing table? Under what circumstances would your idea of eligibility change? Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From oliver at bartels.de Wed Apr 6 10:55:33 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 06 Apr 2005 10:55:33 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: Message-ID: <200504060855.j368tTe5023795@alpha.bartels.de> On Wed, 6 Apr 2005 10:50:42 +0300 (EEST), Pekka Savola wrote: >Please re-do your math. Germany also has, what 80 or 100 million >people? Would it be safe to say that equates, to, at least 30 Mio >households. This is correct, I estimated the number of companies and it was early in the morning. >Do the math globally and we're maybe at 2 billion households. We are talking about RIPE. Nevertheless: It is useless, stay with your China comes to Europe theory, keep your 200 customers pseudo rule, we will clearly not invest a single cent into IPv6 and I won't bet a penny that this protocol under the current concrete head policy conditions will ever gain a anyhow usable distribution in our world. Propably it takes another ten years, then propably there has some significantly better protocol (think e.g. of embedded search queries processed by routers) been defined and the whole IPv6 effort is for this animal, which receives so much care by managers and developers with useless designs: The cat. For me this is now end of discussion, Congratulations to the concrete heads for putting IPv6 successfully to grave. Best regards Oliver 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 Wed Apr 6 11:35:11 2005 From: gert at space.net (Gert Doering) Date: Wed, 6 Apr 2005 11:35:11 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> Message-ID: <20050406093511.GS84850@Space.Net> Hi, On Wed, Apr 06, 2005 at 01:40:24AM +0300, Pekka Savola wrote: > On Tue, 5 Apr 2005, Daniel Roesen wrote: > >I guess you would agree with me that it's currently no problem at all > >to obtain an ASN and IPv4 PI if you want to multihome. Right? > > Umm. The proposed v6 policy seems weaker than that? AFAIR, you'll > have to justify half of the v4 address space.. and you don't even need > to do that to get a v6 block ? Actually, as of today, IPv4 PI is much more convenient than the proposed IPv6 policy: there is *no cost* attached to IPv4 PI. (And the need to justify the address space is obviously something that can be done - how hard is it for a not-so-small company to claim usage of 120 IPs? - and those they really don't have that many machines, just think something up, to get a "routeable" chunk) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From pekkas at netcore.fi Wed Apr 6 11:53:20 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Apr 2005 12:53:20 +0300 (EEST) Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <20050406085027.GN43805@new.detebe.org> References: <200504052151.j35LpJe5014039@alpha.bartels.de> <20050406085027.GN43805@new.detebe.org> Message-ID: On Wed, 6 Apr 2005, Elmar K. Bins wrote: >> My own, small consulting company (with dozens of customers) can >> certainly promote v6, but I have no delusions of grandeour that it >> would be best from the global perspective to allow such or even larger >> companies, whether calling themselves ISPs or not, to obtain a /32. > > Would you - if I may ask - believe "such or even larger companies" > to be eligible for an independently routable prefix at all, or, > more clearly spoken, eligible for a slot int the global routing table? They should never be in the global routing table. > Under what circumstances would your idea of eligibility change? That can be debated, but hopefully not in this thread or list. I'm asking you guys :) Getting 200 real customers is one acceptable circumtance. -- 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 Apr 6 11:55:31 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 6 Apr 2005 11:55:31 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050406093511.GS84850@Space.Net> References: <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> <20050406093511.GS84850@Space.Net> Message-ID: <20050406095531.GA6547@srv01.cluenet.de> On Wed, Apr 06, 2005 at 11:35:11AM +0200, Gert Doering wrote: > Actually, as of today, IPv4 PI is much more convenient than the proposed > IPv6 policy: there is *no cost* attached to IPv4 PI. This isn't really correct. The sponsoring LIR pays for it, and usually will charge the customer for that one way or another. Some attach a price tag for it, others see it as added customer service. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Michael.Dillon at radianz.com Wed Apr 6 12:08:41 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 6 Apr 2005 11:08:41 +0100 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: Message-ID: > Could you clarify, why do you think "200 customers" fails as a meter > for largeness ? Because it assumes that the LIRs applying for address space are following a traditional ISP model in which the customers of the LIR are being connected by the network. In the case of BMW it may be the factories, or it may be the repair centres. In the case of Google it may be some set of replicated server farms in many locations. > What do you think would be a reasonable bar then? First, I think that it would be more reasonable to have no bar but to have a number of /32 allocations which triggers a policy review. But if there has to be a bar, then perhaps it could be restated as: "the LIR intends to allocate at least 200 /48 blocks within the next two years". On a commercial level, that still allows a new startup ISP who intends to offer IPv6-only network access, to get the addresses that they need for their business plan. But it also allows for all the existing IPv4 network operators, many of whom are not ISPs, to get IPv6 addresses to transition their networks. We don't really know who is going to adopt IPv6 or how they are going to use it so the policy has to avoid making assumptions and avoid unecessary barriers to entry. --Michael Dillon From elmi at 4ever.de Wed Apr 6 12:18:49 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 6 Apr 2005 12:18:49 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: References: <200504052151.j35LpJe5014039@alpha.bartels.de> <20050406085027.GN43805@new.detebe.org> Message-ID: <20050406101848.GV43805@new.detebe.org> pekkas at netcore.fi (Pekka Savola) wrote: > >Would you - if I may ask - believe "such or even larger companies" > >to be eligible for an independently routable prefix at all, or, > >more clearly spoken, eligible for a slot int the global routing table? > > They should never be in the global routing table. You are a modest person. I feel the same about our "home network", btw.; but that's because I trust my transit providers and I know how to renumber, should the need arise. > Getting 200 real customers is one acceptable circumtance. I believe the "200" poses a problem for most of the typical early adopters, who are not among the Tier 1 folks, but in Tiers 2 and 3 (if you think in tiered terms). And of course, that still doesn't solve the "crucial end site" problems, which anyway are not the issue in this thread. I favour v6 PI, but anybodies mileage may vary. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From Michael.Dillon at radianz.com Wed Apr 6 12:40:18 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 6 Apr 2005 11:40:18 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504060213.41011.jon@lawrence.org.uk> Message-ID: > My personal opinion (after far too much wine) is that the routers will > probably be able to cope with anything that is thrown at them (again, I don't > have the facts to back this statement up nor the knowledge to work it out - > so don't ask for them Randy, other people know far more about what's on the > horizon that I could ever hope to). I happen to think that you are wrong. There are real technical issues with routers that are hard to solve. The first and most obvious is that as the size of the table gets larger, it requires more and more computing resources in the router and more bandwidth to announce/withdraw routes. It's not just a question of RAM sizes but also CPU power, circuit capacity, and the time required to process stuff. As we converge more time-sensitive applications onto the network, the time delays introduced by huge global routing tables are less acceptable than they were in 1995. The second issue is that all of us have lived through the time when Moore's law, and related laws, have caused electronic devices to get better, cheaper and faster every year. But we are now getting to the point where real physical limits are being reached, i.e. you cannot make circuits thinner than one molecule. Nobody knows the exact implications of this but we can be sure that sometime in this century, there will no longer be any increase in memory capacities, processor speed or circuit capacities. It is wrong to make policies based on the assumption that any problems with routers will be solvable just as they were in the 80's and 90's. > Throwing out conservation just because the v6 address range is so vast is > plain stupidity - the past, in my mind, exists for one reason, so that we can > learn from it (I might not, but that's a personal problem or at least SWMBO > tells me so). ISP's might need a /32 (doubtful in most cases) but enterprises > DO NOT. Yes, enterprises need to multihome (same as ISP's do) but they do not > need nor will they ever need a /32 (or even a /48 for that matter). How many > enterprises currently use a class 'A' in current v4 space - and I mean really > use - I think that question answers itself. Again, learning from history does not mean doing the same thing as was done before. An IPv6 /32 address block is vastly smaller than an IPv4 class A block because it represents a much smaller percentage of the total address space. Therefore, we have learned from history and are not making the same mistake. The other historical lesson that keeps being brought up is "the swamp" although the people who mention this almost never define what the swamp is or why it was bad. In my opinion, the swamp was a set of PI allocations of varying sizes all mixed together in such a way that it was not possible to aggregate them in routing announcements. It was bad because it meant that companies would have to announce many small disjoint blocks, thus consuming global routing table space. In IPv6 this has been fixed. Everybody gets a single /32 PI block and 99% of those LIRs will never in a hundred years grow beyond that allocation. Except for those IPv6 /48 microallocations. Are they really such a good idea? Didn't we learn from the swamp? --Michael Dillon From Michael.Dillon at radianz.com Wed Apr 6 12:46:31 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 6 Apr 2005 11:46:31 +0100 Subject: Fw: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] Message-ID: > There is one point I don't understand in the whole discussion: > If every RIPE member get's an IPv6 prefix, which is true for IPv4, > we are talking about plus 10K prefixes in the table. If RIPE really and truly believes that IPv6 will become the future core protocol of the public Internet, then RIPE should allocate an IPv6 /32 to every RIPE member who has PI addresses. But that is seperate from the question of new entrants who may, or may not, be following an ISP business model. > Do people *really* think this approach works and do they > really think that such an anti-competitive 200 customer policy > - does neither hit IPv6 and the idea behind it > - does not hit community > - will not be forced down by EU commission authorities ?!? If you want to discuss anti-competitive rules, then how about the 80% threshold which fails to recognize the technical realities of IPv4 subnetting which means that large networks can never be as efficient as smaller ones. But that is being addressed by the HD-Ratio proposal. --Michael Dillon From pekkas at netcore.fi Wed Apr 6 13:40:11 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Apr 2005 14:40:11 +0300 (EEST) Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2005 Michael.Dillon at radianz.com wrote: >> Could you clarify, why do you think "200 customers" fails as a meter >> for largeness ? > > Because it assumes that the LIRs applying for address space > are following a traditional ISP model in which the customers > of the LIR are being connected by the network. In the case > of BMW it may be the factories, or it may be the repair centres. > In the case of Google it may be some set of replicated server > farms in many locations. Do you consider BMW and Google ISPs? Do you think they should be? Note that at least according to some enterprises, folks also want to advertise more specifics from each of the network demarcation points they attack to -- not wanting to backhaul internal traffic through their internal network. Giving such enteprises /32 furthers bloats the routing table with TE-induced more specifics. For those enteprises, it might be better to have local-provider aggegatable addresses, which don't need these traffic engineering properties. > But if there has to be a bar, then perhaps it could be restated > as: "the LIR intends to allocate at least 200 /48 blocks within > the next two years". On a commercial level, that still allows > a new startup ISP who intends to offer IPv6-only network access, > to get the addresses that they need for their business plan. But > it also allows for all the existing IPv4 network operators, many > of whom are not ISPs, to get IPv6 addresses to transition their > networks. The current policy (the relevant bits wrt your idea) is: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organisations within two years. What you said, "the LIR intends to allocate at least 200 /48 blocks within the next two years" seems to be roughly equal to the above, except by removing the "other organizations" rule. Was this the intent -- because the current policy already allows a /32 to (if the other conditions are met) new ISPs which don't _yet_ have 200 customers ? Or did you mean something slightly different? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gert at space.net Wed Apr 6 14:19:52 2005 From: gert at space.net (Gert Doering) Date: Wed, 6 Apr 2005 14:19:52 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050406095531.GA6547@srv01.cluenet.de> References: <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> <20050406093511.GS84850@Space.Net> <20050406095531.GA6547@srv01.cluenet.de> Message-ID: <20050406121952.GX84850@Space.Net> Hi, On Wed, Apr 06, 2005 at 11:55:31AM +0200, Daniel Roesen wrote: > On Wed, Apr 06, 2005 at 11:35:11AM +0200, Gert Doering wrote: > > Actually, as of today, IPv4 PI is much more convenient than the proposed > > IPv6 policy: there is *no cost* attached to IPv4 PI. > > This isn't really correct. The sponsoring LIR pays for it, and usually > will charge the customer for that one way or another. Some attach a > price tag for it, others see it as added customer service. Yes, you're right here. I remembered "PI is special" but forgot in which way (only charged in the first year, not in the following years, same as for AS numbers). Still different from "becoming a LIR and paying yearly recurring fees" (which the point I wanted to make). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From dr at cluenet.de Wed Apr 6 14:39:21 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 6 Apr 2005 14:39:21 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050406121952.GX84850@Space.Net> References: <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> <20050406093511.GS84850@Space.Net> <20050406095531.GA6547@srv01.cluenet.de> <20050406121952.GX84850@Space.Net> Message-ID: <20050406123921.GA7787@srv01.cluenet.de> On Wed, Apr 06, 2005 at 02:19:52PM +0200, Gert Doering wrote: > > > Actually, as of today, IPv4 PI is much more convenient than the proposed > > > IPv6 policy: there is *no cost* attached to IPv4 PI. > > > > This isn't really correct. The sponsoring LIR pays for it, and usually > > will charge the customer for that one way or another. Some attach a > > price tag for it, others see it as added customer service. > > Yes, you're right here. I remembered "PI is special" but forgot in > which way (only charged in the first year, not in the following years, > same as for AS numbers). Correct. > Still different from "becoming a LIR and paying yearly recurring fees" > (which the point I wanted to make). This is correct too. Given that it's basically a one-time effort for RIPE NCC and the sponsoring LIR, it's not too unreasonable. Apart from the setup effort (evaluating request, creating the objects) it's just the objects lingering around in the RIPE DB (plus providing the robots to change those objects, but that's a public service anyway). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From fw at deneb.enyo.de Wed Apr 6 15:09:39 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 06 Apr 2005 15:09:39 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <20050406101848.GV43805@new.detebe.org> (Elmar K. Bins's message of "Wed, 6 Apr 2005 12:18:49 +0200") References: <200504052151.j35LpJe5014039@alpha.bartels.de> <20050406085027.GN43805@new.detebe.org> <20050406101848.GV43805@new.detebe.org> Message-ID: <873bu4vyp8.fsf@deneb.enyo.de> * Elmar K. Bins: >> Getting 200 real customers is one acceptable circumtance. > > I believe the "200" poses a problem for most of the typical early > adopters, who are not among the Tier 1 folks, but in Tiers 2 and 3 > (if you think in tiered terms). Well, if the "200" is a problem, just go ahead and open a bot shell provider (or some kind of reselling service for the actual BSPs). Using address space for the sole purpose of vanity host names is completely legit. 8-) From fw at deneb.enyo.de Wed Apr 6 15:32:54 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 06 Apr 2005 15:32:54 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: (Pekka Savola's message of "Wed, 6 Apr 2005 14:40:11 +0300 (EEST)") References: Message-ID: <87y8bwuj21.fsf@deneb.enyo.de> * Pekka Savola: > Do you consider BMW and Google ISPs? Do you think they should be? Both BMW and Google need stable internal adressing, independent of the ISPs they use because their life expectancy exceeds that of your average (large) ISP. If they can't get stable public addresses (globally routeable or not), they'll just use private ones (or even a completely different address allocation scheme), and NAT as necessary. This is not an ideal solution, especially if BMW and Google should ever merge, but it's better than complete dependence on an external entity which might turn into a competitor or go out of business. If you don't give real addresses to end sites, you cannot compete with NAT in most areas. This is sad because NAT does have its problems. If another IPv6 killer application surfaces (besides the large address spaces), both BMW and Google will be able to jump through almost any hoop to qualify as an ISP. That's why it's so strange not to give them real addresses in the first place. From Michael.Dillon at radianz.com Wed Apr 6 15:44:39 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 6 Apr 2005 14:44:39 +0100 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: Message-ID: > Do you consider BMW and Google ISPs? Do you think they should be? No and no. I also don't think that this is relevant to RIPE policies. There was a time when virtually all IP network operators were ISPs and ISPs were distinct and separate from telecoms companies. Now, most ISPs are telecoms companies, but virtually all companies in Europe operate an IP network of some sort. RIPE should be concerned with all operators of large IP networks, whether or not their business model is that of an ISP or something else. The technology of IP networking requires IP addresses. Once a company has the need to interconnect IP networks, they also have a legitimate need for globally unique IP addresses. That is where RIPE comes in. It doesn't matter whether this is a company, like mine, which operates a parallel internetwork separate from the Internet, or whether it is a company which operates their own IP extranet infrastructure, or whether it is a large multi-location company operating their own IP intranet. If they need globally unique IP addresses, they come to RIPE and RIPE policies must be fair to all of them. RIPE must not be seen to be a cabal of ISPs trying to impose a certain business model through anti-competitive policies. This is all the more important with IPv6 because real-world political organizations are taking notice and talking about becoming involved. As long as RIPE stays current with the realities of today, not the dreams of yesterday, then there will be no problems. I believe that RIPE can evolve its policies so that there is no need for the EU or ITU to become involved in IPv6 addressing. But evolution is required. > Note that at least according to some enterprises, folks also want to > advertise more specifics from each of the network demarcation points > they attack to -- not wanting to backhaul internal traffic through > their internal network. Giving such enteprises /32 furthers bloats > the routing table with TE-induced more specifics. For those > enteprises, it might be better to have local-provider aggegatable > addresses, which don't need these traffic engineering properties. If an enterprise desires that type of traffic flow then it would be a mistake for them to get a PI allocation. If there is a real danger that people will make this mistake, then RIPE could publish educational material about how different addressing scenarios affect traffic engineering, failover, etc. > c) plan to provide IPv6 connectivity to organisations to which > it will assign /48s by advertising that connectivity through its > single aggregated address allocation; and > > d) have a plan for making at least 200 /48 assignments to other > organisations within two years. > > What you said, "the LIR intends to allocate at least 200 /48 blocks > within the next two years" seems to be roughly equal to the above, > except by removing the "other organizations" rule. > > Was this the intent -- because the current policy already allows a /32 > to (if the other conditions are met) new ISPs which don't _yet_ have > 200 customers ? If you remove "to other organisations" from d) and also reword c) so that it refers to something other than organisations (sites?) then I think the policy will be much fairer. However, I still think that the plan for 200 sites within 2 years is not necessary at this point in time. If only we had a clearer definition of a network and an internetwork. I would probably say something like: "Any organization planning to operate an IPv6 internetwork connecting two or more physically discontiguous locations...". --Michael Dillon From woeber at cc.univie.ac.at Wed Apr 6 17:10:13 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 06 Apr 2005 17:10:13 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] Message-ID: <00A41E53.F60D89F2.13@cc.univie.ac.at> >If you remove "to other organisations" from d) and also reword c) so that >it refers to something other than organisations (sites?) then I think >the policy will be much fairer. Now we are getting closer to the real stuff: nobody in RIPE-Land has ever been able to agree on the definition of "ISP", much less on a definition of "customer" or "organisation" or "site". >However, I still think that the plan for 200 sites within 2 years is >not necessary at this point in time. It is not even useful or helpful, because the entities which should count up to the magical number 200, eventually, are of different make and model and lifespan. If you look at the "traditional mass-market ISP", having 200 customers is zilch. Private homes, SOHO stuff, and so on. Looking at e.g. a research network, a "customer" or "site" is something like Vienna University. Till recently (before the medical faculty was split off, I don't have the curent figures at hand) this site was serving some 60K+ students plus 6..7K facutly on the campus. The whole LAN serving that community on-site can live comfortably within a *single* /48 (yes we do have an addressing plan and our backbone is dual-stack :-). But, there are "slightly" less than 200 universities in our country... Looking at the regional school districts (9 of them, aligned with the federal states), they _could_ be run as a single site within a /48 each, and from our point of view, as a single "customer" (again 9 << 200) - or they can be treated as separate schools (=sites) leaving us with a couple of thousands to add to the tally :-). It all depends on the *operational model*, the connection technology, and the contractual relationships. Bottom line: 200 is just as good or useless as a "measure" for size of an operator, or its importance, determination to introduce IPv6, or the size of a user community served - as is 0, 5, 10, 100 or 20K. And, btw, I was involved in trying to align the evolving regional IPv6 policies across the regions: the magical mistery number "200" is merely a result of social engineering, and not a result of technical or scaling deliberations. The proposals we had on the table at that time were between "0" and a couple of "thousands". > If only we had a clearer definition >of a network How about: Some transmission equipment and physiacal channel, with more than 1 attachment point, serving some functional gadet, which require a unique identification and agreeing on the use of a common set of communication rules. those ruleswhich include using those unique identifiers on more than 1 of the attachment points. > and an internetwork. More than 1 operational domain with a "network", interconnected on at least 1, probably more, points using an "interconnection network" to provide and operate the exchange of information. > I would probably say something like: >"Any organization planning to operate an IPv6 internetwork connecting >two or more physically discontiguous locations...". You might have fun coming up with a definiton of "physically discontiguous locations...", but that's a diferent exercise :-) >--Michael Dillon Wilfried. From iljitsch at muada.com Wed Apr 6 17:52:30 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 17:52:30 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504051350.j35Doce5002945@alpha.bartels.de> References: <200504051350.j35Doce5002945@alpha.bartels.de> Message-ID: <46f10a7fb0dffdf433f247cab145981d@muada.com> On 5-apr-05, at 15:50, Oliver Bartels wrote: >> Would you please invest some time into discovering how grownups use >> email? The excessive funny interpunction hurts my eyes. > I would appreciate if you could stay with the subject and > don't put things on the personal level. > Doing so if arguments are missing is not a good idea. I think the headache I *get* #from# (/? ?reading? &your& +=$ messages is a good argument. If you choose to take that personal I can't stop you. > And please keep in mind that at least I am not a native > English speaker. So what? Most of us aren't. Does your native language use asterisks and smileys for punctuation? >> Still, the routing table size problem is much more pressing than the >> depletion problem in IPv6 because even if the table size isn't fatal, >> it can get expensive easily, and when it gets fatal there is no way to >> fix it (even if we give up autoconfiguration). > Stay with math: There are about 20K AS'es and much > less RIPE members. Again: so what? How exactly is the number of AS numbers in use today relevant to the state of the network in the year 2040? > Thus : How many prefixes will be out caused by the new policy ? ;-) Nobody knows. And it's irresponsible to adopt a policy if you can't know in advance what the result of adopting that policy is going to be. >> Ah, but if you have N * 2 routing table entries, not only do you need >> 2 >> times the memory, but all else being equal you're going to see 2 times >> as many updates, so assuming you need to search N * 2 entries before >> you can update one (which fortunately isn't the case, the exact math >> is >> left as an excercise to the reader) you need 2 * 2 = 4 times as much >> memory bandwidth. > Believe me (we *developed our own BGP4 route server* > down to the BGP packet level): > Updates are not the problem on the memory bandwidth, > a typical DRAM doesn't care about 100K memory accesses. > We are talking of >>multiple GBit memory bandwidths. Well, worst case a 10 Gbps router has 67.2 nanoseconds to forward a packet before the next one comes in. At these speeds every single memory cycle is relevant. However, I must admit that I was a bit careless with updating the table and forwarding, things will have to get pretty bad before updating will run into memory bandwidth problems. But if and when that happens, we're in a deep pile of brown stuff as read random access memory bandwidth for large memories hasn't been able to keep up with progress in other areas in the past and it's unlikely that this will happen in the future. > *There is no way* to avoid the any-network-structure > shortest-path calculation in a complex network. Can you please point me to the part in the BGP spec that explains where in BGP the SPF calculations are done? >> I'm not sure how having a new techology available before the old >> technology implodes is a problem. > If old technolgy means 10 year old 2501, then it is good when it > implodes and providers are forced to invest into state-of-the-art > hardware if they want to offer state-of-the-art services. Yes, if you sell hardware. Not so much if you're the person who has to foot the bill. Obvously I'm not saying we should be able to run core networks on 15 year old hardware. From iljitsch at muada.com Wed Apr 6 18:04:51 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 18:04:51 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405141451.GA27819@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> Message-ID: <540d102bae8bf22f91185e359dba48c2@muada.com> On 5-apr-05, at 16:14, Daniel Roesen wrote: > Again: you are talking about theoretical worst-case absolute numbers. > I'm talking about real life. Real life has a tendency to reflect theoretical worst-case absolute numbers, given enough time. > I guess you would agree with me that it's currently no problem at all > to obtain an ASN and IPv4 PI if you want to multihome. Right? For me or for the IPv4 BGP table? > This has lead to about 17k active ASN out there. Which translates to > 17k-20k (let's give some headroom for special routes for anycast etc) > IPv6 PA/PI routes. Nonsense. The number of active ASes in the IPv6 table is around 500, and the number of active prefixes around 700. However, none of the 100 largest web sites is reachable over IPv6, so this is all meaningless. The only thing we know from experience with IPv4 is that there are way too many people who don't care about the routing table, so if it's POSSIBLE to do bad things, there will be someone who DOES bad things. > Where is your problem? I don't see multiple million > of end sites doing BGP multihoming. Not now, not in ten years. It's > not that we have hundred of thousand of NEW people JUST WAITING for the > availability of PI out there. Then why do we need it? I see no natural limit on the number of potential multihomers. What if Linksys puts BGP in their home gateways, with a nice wizzard to take care of setting everything up? You may very well be right that the number of multihomers will grow slower than the capacity of the routers, but without knowing this for sure making this possible is irresponsible. ISPs have a very bad reputation for reliability and more and more business critical stuff happens over the internet. I think it's only a matter of time before multihoming will be all the rage, especially if it's easy to do. >> And what are people asking for? > At least the same set of features as IPv4 PI BGP multihoming with no > new added significant downsides. > Perhaps folks should start listening to that instead of sticking the > head into the sand. Read the multi6 documents. This stuff has been discussed to death. Giving some people PI until the routers almost break isn't the solution. From iljitsch at muada.com Wed Apr 6 18:13:12 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 18:13:12 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <002001c53a38$6e4a2660$0700000a@jhw> References: <200504052151.j35LpJe5014039@alpha.bartels.de> <002001c53a38$6e4a2660$0700000a@jhw> Message-ID: <3ed6f8daa3d12c17b3dc4507eea9aff3@muada.com> On 6-apr-05, at 1:37, J?rgen Hovland wrote: > There is no such thing as technical limitations/reasons, only > economical. Nobody can transport an IP packet faster than 300000 km/s (well, more like 200000 km/s in practice) no matter how much money they have. > I don't see an economical reason for why normal network providers > shouldn't be able to handle 500,000 IPv6 routes. It's too expensive. Don't forget that a typical router takes a bunch of full feeds (or equivalent in partial feeds) from different peers, so 0.5M routes probably means your router needs to support 2 - 5 M BGP routes. And of course you need a FIB that's large enough and can be searched fast enough. > Existing operators may need to upgrade something or they have to > downgrade to singlehoming if they do not wish to upgrade. It's not just the multihomers that need a router that supports a full BGP table. Medium-sized and larger ISPs need to have routers that hold full tables too, they don't have a choice. > With that in mind, isn't this what you are looking for: A natural way > to limit the amount of multihomed autonomous systems/amount of > prefixes without enforcing unreasonable policies? That's why I proposed "provider-internal aggregation based on geography" but this fell on deaf ears. Go for the quick fix PI block and let someone else clean up the mess seems to be the prevailing attitude. > IPv6 won't survive if you keep having silly policies (and I still > think that includes the fixed size /48 customer assignment policy). What's silly about that? A fixed prefix length is very useful because that way you only have to renumber the top 48 bits when you switch ISPs. This makes life much easier. From iljitsch at muada.com Wed Apr 6 18:22:06 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 18:22:06 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <200504060630.j366URe5021339@alpha.bartels.de> References: <200504060630.j366URe5021339@alpha.bartels.de> Message-ID: On 6-apr-05, at 8:30, Oliver Bartels wrote: > For our company we require a *unique* *globally* and under > our AS with definition of an AS ("own policy") routable > address space. I don't care about the exact size. No you don't. That's just the easiest way to get what you really need (stability, independence, failover, whatever). > Thus I can clearly tell you that without independently > routable address space we will not introduce IPv6 within > our network. Period. See you in IPv7 then. Bye. From iljitsch at muada.com Wed Apr 6 18:24:18 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 18:24:18 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <87y8bwuj21.fsf@deneb.enyo.de> References: <87y8bwuj21.fsf@deneb.enyo.de> Message-ID: On 6-apr-05, at 15:32, Florian Weimer wrote: >> Do you consider BMW and Google ISPs? Do you think they should be? > Both BMW and Google need stable internal adressing, independent of the > ISPs Everyone needs that. We can't give everyone a globally visible PI block. > If they can't get stable public addresses > (globally routeable or not), they'll just use private ones That's why unique site local addresses are in the works. From randy at psg.com Wed Apr 6 19:14:45 2005 From: randy at psg.com (Randy Bush) Date: Wed, 6 Apr 2005 07:14:45 -1000 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] References: <200504060855.j368tTe5023795@alpha.bartels.de> Message-ID: <16980.6405.698665.398369@roam.psg.com> > We are talking about RIPE. no. we're talking about the global internet. that's one part of what we mean by words like prudence, stewardship, ... and another part is we're not just talking about this year. randy From mike at linx.net Wed Apr 6 19:20:19 2005 From: mike at linx.net (Mike Hughes) Date: Wed, 06 Apr 2005 18:20:19 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria Message-ID: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> The 200 /48s rule does fail the job, in the present environment. We should abolish it for the arbitrary, plucked from the air number, that it is. Why? Because there are networks which are not end sites, who do make assignments to customers (just not 200 of them right now - or within 2 years), which cannot wait for the i*tf to get off the pot with whatever multi6/shim6 thing they are doing, which cannot wait the N years it will take for vendors to implement whatever comes out of the i*tf. They need fully-functioning IPv6 connectivity which is not dependant on (the address space, services, operational stability, etc., of) an upstream carrier, right now, for whom large scale renumbering whenever they have to change upstream is not a realistic option. This can be achieved through an IPv6 address allocation which is functionally similar to the IPv4 PA allocation they are currently entitled to. Currently, the RIRs issue these in /32 chunks. Sure, routing tables will grow. A bit. That's because the Internet is (still) growing. IPv6 is part of that growth, yet I don't really think we've had a substantial sunrise period yet. The sun seems to be very low on the horizon from where I'm sat. I don't think we're talking about floodgates here. The majority seem to think there are enough safeguards to prevent "casual" users from successfully receiving an IPv6 allocation. I agree. Right now, the only strong objections I'm seeing appear to be somewhat Canutist, despite being otherwise well-informed. In case my opinion isn't clear, I support the proposal as it stands. If there is a genuine and well-founded concern about pulling the "200 number" without some other form of safeguard, maybe we go with the proposal as it stands, but add a commitment (by the Chairs? group as a whole? NCC?) to table a review of the situation once the i*tf do come up with something, and there is vendor support for it? Would that help to allay fears of wet feet? Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From randy at psg.com Wed Apr 6 19:53:27 2005 From: randy at psg.com (Randy Bush) Date: Wed, 6 Apr 2005 07:53:27 -1000 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> Message-ID: <16980.8727.643422.694994@roam.psg.com> > The 200 /48s rule does fail the job, in the present > environment. We should abolish it for the arbitrary, plucked from > the air number, that it is. care to do some plucking? > add a commitment (by the Chairs? group as a whole? NCC?) to > table a review of the situation once the i*tf do come up with > something, and there is vendor support for it? american readers beware the brits have the opposite meaning of 'table'. randy From andy at linx.net Wed Apr 6 20:34:30 2005 From: andy at linx.net (Andy Furnell) Date: Wed, 6 Apr 2005 19:34:30 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16980.8727.643422.694994@roam.psg.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <16980.8727.643422.694994@roam.psg.com> Message-ID: <20050406183430.GA31352@linx.net> On Wed, Apr 06, 2005 at 07:53:27AM -1000, Randy Bush wrote: > > > The 200 /48s rule does fail the job, in the present > > environment. We should abolish it for the arbitrary, plucked from > > the air number, that it is. > > care to do some plucking? > Surely 'more than 1' should suffice? The air it comes from may be unusually logical, but since one of the main arguments AGAINST changing the policy seems to come down to a fear of making allocations to 'end-sites', then (assuming we can agree on it) the simplest resolution is to rely on the definition of an end-site for our answer. Taking a step back to a more general observation, I don't see how the proposed changes open the gates (flood-bearing or otherwise) for end-site allocations any wider than they already are.. If we're going to look at things so simplistically then I guess the only potential 'problem' I see is that smaller LIRs (in a world where size is apparently judged on a scale where the size of an ISP is exactly proportional to its customer headcount) will find themselves able to get an allocation so they can (gasp!) start making Serious v6 service offerings... ...and wouldn't that suck? Andy -- Andy Furnell Mob: +44 (0) 7909 680019 London Internet Exchange http://www.linx.net From fw at deneb.enyo.de Wed Apr 6 21:10:19 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 06 Apr 2005 21:10:19 +0200 Subject: Fw: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: (Michael Dillon's message of "Wed, 6 Apr 2005 11:46:31 +0100") References: Message-ID: <87k6nfoh5w.fsf@deneb.enyo.de> * Michael Dillon: > If RIPE really and truly believes that IPv6 will become > the future core protocol of the public Internet, then RIPE > should allocate an IPv6 /32 to every RIPE member who has > PI addresses. No, if everyone believed that IPv6 is the future, policies would not matter much, and there would be little fighting. Everyone would jump through almost any hoop to get what they think they need. 8-) But this is not the case. I don't follow the v6 wars closely, but it appears that several promised improvements over v4 won't be delivered (look at the A6/bitlabel/DNAME deprecation, or even the protocol design optimized for forwarding implementations which now are being phased out). From iljitsch at muada.com Wed Apr 6 22:22:49 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 22:22:49 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> Message-ID: <6bf9497dbe8d2fa49631569440ab03d3@muada.com> On 6-apr-05, at 19:20, Mike Hughes wrote: > The 200 /48s rule does fail the job, in the present environment. Still waiting for the evidence on this one... Can someone show me a request that has been turned down that shouldn't have? You all know my feelings about IPv4-like PI in IPv6 by now, but on the issue of making PA available to people who should have them (= not used as stealth PI) I'm keeping an open mind. Still, just repeating "200 is a problem" to eachother doesn't help, we need to know where the 200 limit gets in the way in the real world. > Because there are networks which are not end sites, who do make > assignments > to customers (just not 200 of them right now - or within 2 years), > which > cannot wait for the i*tf to get off the pot with whatever multi6/shim6 > thing they are doing, which cannot wait the N years it will take for > vendors to implement whatever comes out of the i*tf. Just curious: why is waiting suddenly a problem? IPv6 has been a long time in coming for a long time. (And the letter you're looking for is "E".) > This can be achieved through an IPv6 address allocation which is > functionally similar to the IPv4 PA allocation they are currently > entitled > to. Currently, the RIRs issue these in /32 chunks. "Entitled to"??? > Right now, the only strong objections I'm seeing appear to be somewhat > Canutist, despite being otherwise well-informed. Wow, that word apears only 4 times on the entire internet. What does it mean? > In case my opinion isn't clear, I support the proposal as it stands. > If there is a genuine and well-founded concern about pulling the "200 > number" without some other form of safeguard, maybe we go with the > proposal > as it stands, but add a commitment (by the Chairs? group as a whole? > NCC?) > to table a review of the situation once the i*tf do come up with > something, > and there is vendor support for it? I'm still waiting for those requests that were turned down, but in the mean time I think it might be a good idea to instruct the hostmasters that for a limited time (such as 2 years) and limited number of prefixes (say 256) they should evaluate PA requests that don't meet the 200 requirement and determine that it's not for "stealth PI" or some other less than legitimate purpose without specifying explicit limits. When this experimental period is finished we can then evaluate which requests were granted and which were denied and distill a new policy at that point. Remember that very few organizations are adopting IPv6 wholesale, and IPv6 is relatively easy to renumber, so if a few organizations have to gain experience with provider address space now and we change the policy later so those organizations can get their own block at that point rather than immediately, that's not a disaster. From jorgen at hovland.cx Wed Apr 6 22:23:17 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 6 Apr 2005 21:23:17 +0100 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] References: <200504052151.j35LpJe5014039@alpha.bartels.de> <002001c53a38$6e4a2660$0700000a@jhw> <3ed6f8daa3d12c17b3dc4507eea9aff3@muada.com> Message-ID: <00b501c53ae6$78072370$0700000a@jhw> ----- Original Message ----- From: "Iljitsch van Beijnum" >Nobody can transport an IP packet faster than 300000 km/s (well, more like >200000 km/s in practice) no matter how much money they have. You can't proof I can, so telling me what I can and can not based on todays technology isn't too clever. (sidenote: the speed of light is not relevant to how fast you can transport IP packets) It breaks down to time and money and how much you want to spend of it. >> I don't see an economical reason for why normal network providers >> shouldn't be able to handle 500,000 IPv6 routes. >It's too expensive. Don't forget that a typical router takes a bunch of >full feeds (or equivalent in partial feeds) from different peers, so 0.5M >routes probably means your router needs to support 2 - 5 M BGP routes. And >of course you need a FIB that's large enough and can be searched fast >enough. If you think it is too expensive, then I think I just made my point? :) > With that in mind, isn't this what you are looking for: A natural way to > limit the amount of multihomed autonomous systems/amount of prefixes > without enforcing unreasonable policies? >That's why I proposed "provider-internal aggregation based on geography" >but this fell on deaf ears. Go for the quick fix PI block and let someone >else clean up the mess seems to be the prevailing attitude. I guess it was either a messy idea or the internet isn't ready for it yet. (I did hear your speech but never made up my mind about it so I can't tell) >A fixed prefix length is very useful because that way you only have to >renumber the top 48 bits when you switch ISPs. And you still don't see why I think it's silly? >This makes life much easier. Well. Easier than what? The number 48 is arbitrary. Renumbering will be just as easy with any number between 0 and 127 as long as the new prefix is equal or larger to the previous. With dhcp it doesn't matter. You can allocate a 48 on the paper for all I care, but you can't enforce customers of a LIR on how their network should look. Not even LIRs (usually) do that. I am aware of rfc3177 saying "a company with several nets gets a /48 and allocate /64s for each of their subnets". But let's not mix the word recommendation with must. Why we allocate a /124 on our lan instead of /64 is not of anyones concern but us and therefore the enforced 48 number is unreasonable. Since the 48 number is in generally only for looking good on the allocation paper, then whats the point of it? I know the whole point with IPv6 is to waste as many IPv6 addresses as possible, but for a network using /124s subnets per lan then a /48 prefix is pretty much 100% waste. I am sure some of the old folks said something similar back in 1983 with IPv4. IPv6 _will_ run out of addresses. No need to argue on that. A more specific problem with this allocation policy: You would expect that if a /64 is the standard allocation size of a lan, then we can all start filtering on /64s instead of /128s if we want to do per-ipv6 filtering, right? Cause I am sure we can all agree on that we still want per-ip filtering, right? What do we do with the /128 assignments recommended by rfc3177 on lans with a single device then? Cheers, Joergen Hovland ENK From iljitsch at muada.com Wed Apr 6 22:28:01 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 22:28:01 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <16980.8727.643422.694994@roam.psg.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <16980.8727.643422.694994@roam.psg.com> Message-ID: <075c4ce5747b4705301b8d07df9ad728@muada.com> On 6-apr-05, at 19:53, Randy Bush wrote: > > american readers beware the brits have the opposite meaning of > 'table'. Randy, you forgot to close your tag... You wouldn't want to stay in pedantry mode indefinitely, would you? From randy at psg.com Wed Apr 6 22:41:46 2005 From: randy at psg.com (Randy Bush) Date: Wed, 6 Apr 2005 10:41:46 -1000 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] References: <200504052151.j35LpJe5014039@alpha.bartels.de> <002001c53a38$6e4a2660$0700000a@jhw> <3ed6f8daa3d12c17b3dc4507eea9aff3@muada.com> <00b501c53ae6$78072370$0700000a@jhw> Message-ID: <16980.18826.879181.168761@roam.psg.com> > (sidenote: the speed of light is not relevant to how fast you can transport > IP packets) > It breaks down to time and money and how much you want to spend of it. i am sure i can get you a USD 1,000,000 award for transporting at faster than the speed of light. is that enough money? heck it's probably worth a nobel. can we cut the hyperbole and try to seal with engineering reality. that's hard enough without the bs. randy From oliver at bartels.de Wed Apr 6 22:49:40 2005 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 06 Apr 2005 22:49:40 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <46f10a7fb0dffdf433f247cab145981d@muada.com> Message-ID: <200504062049.j36KnZe5008007@alpha.bartels.de> On Wed, 6 Apr 2005 17:52:30 +0200, Iljitsch van Beijnum wrote: >So what? Most of us aren't. Does your native language use asterisks and >smileys for punctuation? If you don't like them, ignore them. >Well, worst case a 10 Gbps router has 67.2 nanoseconds to forward a >packet before the next one comes in. At these speeds every single >memory cycle is relevant. This is simply wrong. In know this for sure because we are designing such boxes. The key point is that packet forwarding is a process which can (and is in current designs) perfectly pipelined and parallelized. What you do is e.g.: - Convert the table to a radix tree or to microcode representing a radix tree - Wait until the packet header is complete - Extract the destination of packet 1, add some cyclic local id., to address and packet buffer (or take the buffer id. as local id.) put both in the pipeline for checking the first tree level - In the meantime do the same for packet 2, 3 etc. - With the first level decision done, re-schedule the address of the packets for level 2, 3 etc. - At the end there is a decision for the packet referenced by the local id. Flush the packet buffer to the next hop and release it for new packets. Typically one would implement an online compiler to translate the table into microcode and would have multiple "threads" running on the same engine. The response time is not critical, just the throughput, which can be easily increased by adding additional processing units. Another approach is using multiple network CPU's on a single chip. But if you like, you may also do a forwarding decision on a 256K table in one TCAM cycle. IDT delivers such devices and they are happy to sell them. >However, I must admit that I was a bit careless with updating the table >and forwarding, things will have to get pretty bad before updating will >run into memory bandwidth problems. But if and when that happens, we're >in a deep pile of brown stuff as read random access memory bandwidth >for large memories hasn't been able to keep up with progress in other >areas in the past and it's unlikely that this will happen in the >future. I can give you numbers: Standard PC, 1,5GHz, nothing really fast, full table, full policy test of our implementation : Full table (150K) read and processed in less than 1 second if the other side can deliver it as fast as we read it. >Can you please point me to the part in the BGP spec that explains where >in BGP the SPF calculations are done? It is a shortest inter-AS path calculation which is applied if there is no policy which enforces other rules. The selection rules are outside the scope of RFC1771 (see para 9.3) but they are implemented by all vendors in a similar way: If no other policy enforces other selections, the path list provided is evaluated and the shortest list is taken. As this (hopefully, if there are no politics and thus specific policies active) happens within other AS's too, typically a shortest inter AS path is determinated. Please keep in mind that local policies (e.g. localpref) are active, they are prefered, because of this and of the missing AS internal knowledge the route determination does not have the same quality as e.g. intra-area OSPF. >Yes, if you sell hardware. Not so much if you're the person who has to >foot the bill. Obvously I'm not saying we should be able to run core >networks on 15 year old hardware. The 2501 is of the 10 to 15 years class ... Take *any* PC from Ebay, put a Zebra/Quagga on it and you will have a *much* better routing performance and all your problems with the "large" table are solved. A table with 100K to 200K entries is not large for actual hardware. If we talk about >>1 Mio. Prefixes and PI for everyone, then we should consider an update of the BGP. Greetings Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From iljitsch at muada.com Wed Apr 6 22:52:08 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Apr 2005 22:52:08 +0200 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <00b501c53ae6$78072370$0700000a@jhw> References: <200504052151.j35LpJe5014039@alpha.bartels.de> <002001c53a38$6e4a2660$0700000a@jhw> <3ed6f8daa3d12c17b3dc4507eea9aff3@muada.com> <00b501c53ae6$78072370$0700000a@jhw> Message-ID: <4f6478ee33c9fc93bb2613ecb136ca38@muada.com> On 6-apr-05, at 22:23, J?rgen Hovland wrote: >> Nobody can transport an IP packet faster than 300000 km/s (well, more >> like 200000 km/s in practice) no matter how much money they have. > You can't proof I can, so telling me what I can and can not based on > todays technology isn't too clever. Ah, has the topic changed to philosophy? It's as clever as we get to be today... Maybe we're more clever tomorrow, but it's like buying a computer: if you wait, you can buy a more powerful one for less money. But you have to do without a computer while you wait. So I'll use today's knowledge and not second-guess myself. > (sidenote: the speed of light is not relevant to how fast you can > transport IP packets) It breaks down to time and money and how much > you want to spend of it. No matter how much money you have, you're not going to get a packet from London to New York in (say) 10 ms. Sure, if you spend more money you can get MORE packets from London to New York in 100 ms, but that's not what I call "faster". >> That's why I proposed "provider-internal aggregation based on >> geography" but this fell on deaf ears. Go for the quick fix PI block >> and let someone else clean up the mess seems to be the prevailing >> attitude. > I guess it was either a messy idea or the internet isn't ready for it > yet. > (I did hear your speech but never made up my mind about it so I can't > tell) Apparently you're not the only one. I would have expected people who want PI to be all for it, because the aggregation is optional and they get the PI anyway. >> A fixed prefix length is very useful because that way you only have >> to renumber the top 48 bits when you switch ISPs. > And you still don't see why I think it's silly? No. >> This makes life much easier. > Well. Easier than what? Easier than when you get a /48 from an ISP, then move to another ISP but now you get a /56. > The number 48 is arbitrary. Sure. Anyone trained in computer science knows there are only three numbers anyway: 0, 1 and arbitrary... > Renumbering will be just as easy with any number between 0 and 127 as > long as the new prefix is equal or larger to the previous. So how would that happen if everyone would have their own policy for this? > With dhcp it doesn't matter. Most people aren't going to use DHCP in IPv6. > I am aware of rfc3177 saying "a company with several nets gets a /48 > and allocate /64s for each of their subnets". But let's not mix the > word recommendation with must. Why we allocate a /124 on our lan > instead of /64 is not of anyones concern but us From RFC 3513: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. In theory I agree with you as IPv6 is supposed to be classless, but in practice the above makes sense as it would probably be too difficult to support address autoconfiguration with variable subnet sizes. > and therefore the enforced 48 number is unreasonable. I don't see why it's unreasonable. At least this way everyone gets the same, regardless of which ISP they use. (It's always possible to request a bigger block for those who need it.) > A more specific problem with this allocation policy: > You would expect that if a /64 is the standard allocation size of a > lan, then we can all start filtering on /64s instead of /128s if we > want to do per-ipv6 filtering, right? I don't understand what you're getting at... From jon at lawrence.org.uk Wed Apr 6 23:05:11 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Wed, 6 Apr 2005 22:05:11 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6bf9497dbe8d2fa49631569440ab03d3@muada.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> Message-ID: <200504062205.11941.jon@lawrence.org.uk> On Wednesday 06 April 2005 21:22, Iljitsch van Beijnum wrote: > > Right now, the only strong objections I'm seeing appear to be somewhat > > Canutist, despite being otherwise well-informed. > > Wow, that word apears only 4 times on the entire internet. What does it > mean? > I assume it's somekind of reference to King Canute - the chap who supposedly tried to order the tide not to come in. What it's supposed to mean in this thread lord only knows. Jon From pekkas at netcore.fi Wed Apr 6 23:06:45 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 7 Apr 2005 00:06:45 +0300 (EEST) Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <200504062049.j36KnZe5008007@alpha.bartels.de> References: <200504062049.j36KnZe5008007@alpha.bartels.de> Message-ID: On Wed, 6 Apr 2005, Oliver Bartels wrote: > I can give you numbers: Standard PC, 1,5GHz, nothing really fast, > full table, full policy test of our implementation : > > Full table (150K) read and processed in less than 1 second > if the other side can deliver it as fast as we read it. Are there results of such a test w/ hardware and software that's actually deployed out there (take a Cisco GSR or Juniper M/T series for example) ? What if you add (for example) 20,000 lines of prefix-lists per peer? -- 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 jorgen at hovland.cx Thu Apr 7 00:21:06 2005 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Thu, 07 Apr 2005 00:21:06 +0200 Subject: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <4f6478ee33c9fc93bb2613ecb136ca38@muada.com> Message-ID: <0IEJ00MUKQ5AE160@bgo1sminn1.broadpark.no> -----Opprinnelig melding----- Fra: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] P? vegne av Iljitsch van Beijnum >No matter how much money you have, you're not going to get a packet >from London to New York in (say) 10 ms. Sure, if you spend more money >you can get MORE packets from London to New York in 100 ms, but that's >not what I call "faster". I think Randy said it all. I'll buy you a beer when I get my $1 mil then. >> Renumbering will be just as easy with any number between 0 and 127 as >> long as the new prefix is equal or larger to the previous. > >So how would that happen if everyone would have their own policy for >this? As long as you get one billion times more addresses than you need, the size of your new allocation will depend on the current address policy which will change over time as the amount of free IPv6 addresses gets reduced. This is (mostly) why the early birds on the Internet got a class /8 IPv4 block, and I bet some of them don't even use close to all of it. How long do you think this /48 policy will last? I was hoping for at least 60 years++ so I don't need to have the same discussion again with IPv8. >> With dhcp it doesn't matter. > >Most people aren't going to use DHCP in IPv6. Which is another discussion. >> I am aware of rfc3177 saying "a company with several nets gets a /48 >> and allocate /64s for each of their subnets". But let's not mix the >> word recommendation with must. Why we allocate a /124 on our lan >> instead of /64 is not of anyones concern but us > From RFC 3513: > > For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > >In theory I agree with you as IPv6 is supposed to be classless, but in >practice the above makes sense as it would probably be too difficult to >support address autoconfiguration with variable subnet sizes. > >> and therefore the enforced 48 number is unreasonable. > >I don't see why it's unreasonable. At least this way everyone gets the >same, regardless of which ISP they use. (It's always possible to >request a bigger block for those who need it.) So you are saying that documenting your need of a /48 will be rejected by future LIRs due to their own address policy and they will give you a /56 instead because that?s what their policy says? I don't believe that will happen as long as the RIRs have somewhat loose policies. ARIN allocates you a netblock and you do whatever you want with it. With RIPE you need to apply for allocations within your assigned netblock. I can see that this might impact on the different policies in the US. But what about you document the need of a /40 but will only get a /48 (/47)? > >> A more specific problem with this allocation policy: >> You would expect that if a /64 is the standard allocation size of a >> lan, then we can all start filtering on /64s instead of /128s if we >> want to do per-ipv6 filtering, right? > >I don't understand what you're getting at... I see I was a bit unclear. Limitation of 1 ftp connection per user, 1 registration per user on our website and so on.. Simple techniques to reduce abuse++ often take advantage of the one machine to one IP address ratio with IPv4 today. With IPv6 you get one address, or you get a billion. You can't tell anymore cause you can grab thousand extra ips on the /64 lan and use it for whatever you like. We are sure going to miss this feature. Joergen Hovland ENK From andy at linx.net Thu Apr 7 03:54:43 2005 From: andy at linx.net (Andy Furnell) Date: Thu, 7 Apr 2005 02:54:43 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6bf9497dbe8d2fa49631569440ab03d3@muada.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> Message-ID: <20050407015443.GA21722@linx.net> On Wed, Apr 06, 2005 at 10:22:49PM +0200, Iljitsch van Beijnum wrote: > > On 6-apr-05, at 19:20, Mike Hughes wrote: > > >The 200 /48s rule does fail the job, in the present environment. > > Still waiting for the evidence on this one... Can someone show me a > request that has been turned down that shouldn't have? I've seen an application fail from an LIR planning to make a large (/35) allocation to a downstream ISP, who would then be making (2000+) end-user /48 assignments. The direct assignments from the LIR itself would not total more than 20, and as such either the ISP would have to become an LIR to receive its own allocation (which could then have an allocation made for its upstream's use) or for the upstream LIR to assign directly to the ISP's customers. Perhaps more relevant to this particular discussion is that we (uk.linx) house a number of other projects to whom we currently make v4 assignments. But since our primary area of business is not being an ISP, getting 200 customers to service in this manner is not exactly our top priority.. 10 is probably closer to the mark. Even so, our needs and the needs of our customers are the same as those of any 200-customer-plus organisation, so what other differences are there (engineering or otherwise) between the 'us' and the 'them'? There are others. Perhaps the NCC have some useful stats.. > >Because there are networks which are not end sites, who do make > >assignments > >to customers (just not 200 of them right now - or within 2 years), > >which > >cannot wait for the i*tf to get off the pot with whatever multi6/shim6 > >thing they are doing, which cannot wait the N years it will take for > >vendors to implement whatever comes out of the i*tf. > > Just curious: why is waiting suddenly a problem? IPv6 has been a long > time in coming for a long time. (And the letter you're looking for is > "E".) Well, the noise from customers about when they can have IPv6 is certainly getting louder. Deals are being made and broken by an ISP's ability to offer a viable IPv6 solution, and it hurts especially badly when an ISP is unable to receive an allocation in the first place because their customer count simply isn't worthy enough. > >In case my opinion isn't clear, I support the proposal as it stands. > > >If there is a genuine and well-founded concern about pulling the "200 > >number" without some other form of safeguard, maybe we go with the > >proposal > >as it stands, but add a commitment (by the Chairs? group as a whole? > >NCC?) > >to table a review of the situation once the i*tf do come up with > >something, > >and there is vendor support for it? > > I'm still waiting for those requests that were turned down, but in the > mean time I think it might be a good idea to instruct the hostmasters > that for a limited time (such as 2 years) and limited number of > prefixes (say 256) they should evaluate PA requests that don't meet the > 200 requirement and determine that it's not for "stealth PI" or some > other less than legitimate purpose without specifying explicit limits. So how exactly do you propose to determine what's 'stealth PI' and what's not? Surely if an LIR is going to be assigning to other end-site organisations we're looking at a genuine PA request, regardless of how many assignments will be made. > When this experimental period is finished we can then evaluate which > requests were granted and which were denied and distill a new policy at > that point. And when the NCC do come back with this magic metric as to what (exactly) a PA-worthy LIR is, for how long do you expect that data to be accurate? Do we really want to have to review this policy every 2 years as we discover another corner case that disproves the last batch of changes? Andy -- Andy Furnell Mob: +44 (0) 7909 680019 London Internet Exchange http://www.linx.net From jeroen at unfix.org Thu Apr 7 11:37:05 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 07 Apr 2005 11:37:05 +0200 Subject: What you miss in IPv6.... (Was: Re: Fw: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]) In-Reply-To: <87k6nfoh5w.fsf@deneb.enyo.de> References: <87k6nfoh5w.fsf@deneb.enyo.de> Message-ID: <1112866626.23344.5.camel@firenze.zurich.ibm.com> On Wed, 2005-04-06 at 21:10 +0200, Florian Weimer wrote: > * Michael Dillon: > > > If RIPE really and truly believes that IPv6 will become > > the future core protocol of the public Internet, then RIPE > > should allocate an IPv6 /32 to every RIPE member who has > > PI addresses. > > No, if everyone believed that IPv6 is the future, policies would not > matter much, and there would be little fighting. Everyone would jump > through almost any hoop to get what they think they need. 8-) > > But this is not the case. I don't follow the v6 wars closely, but it > appears that several promised improvements over v4 won't be delivered > (look at the A6/bitlabel/DNAME deprecation, or even the protocol > design optimized for forwarding implementations which now are being > phased out). A6 could cause a long chain of servers to be asked where 1 lookup is enough for normal reverse queries. Also things as signing would become a large Bitlabel is just a different way of writing down reverses, which btw would be incompatible with A6. DNAME exists and is being used. It is sort of a Domain CNAME :) How else did you think I aliased ip6.int to ip6.arpa for silly slow people who do not upgrade their DNS resolvers. The "protocol design optimized for forwarding implementations". You can be referring to a couple of things here, though I can tell you that the header structure is aligned and there is no checksumming anymore, as the hardware layer usually already does that. This speeds IPv6 up already by a couple of factors compared to IPv4, even though one has to look at a 128bit address instead of a IPv4 one. Anything else? 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 jeroen at unfix.org Thu Apr 7 11:58:08 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 07 Apr 2005 11:58:08 +0200 Subject: Limitting based on IP address is not useful (Was: Re: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]) In-Reply-To: <0IEJ00MUKQ5AE160@bgo1sminn1.broadpark.no> References: <0IEJ00MUKQ5AE160@bgo1sminn1.broadpark.no> Message-ID: <1112867888.23344.18.camel@firenze.zurich.ibm.com> On Thu, 2005-04-07 at 00:21 +0200, J?rgen Hovland wrote: > >> A more specific problem with this allocation policy: > >> You would expect that if a /64 is the standard allocation size of a > >> lan, then we can all start filtering on /64s instead of /128s if we > >> want to do per-ipv6 filtering, right? > > > >I don't understand what you're getting at... > > I see I was a bit unclear. > Limitation of 1 ftp connection per user, 1 registration per user on > our website and so on.. > Simple techniques to reduce abuse++ often take advantage of the one > machine to one IP address ratio with IPv4 today. With IPv6 you get > one address, or you get a billion. > You can't tell anymore cause you can grab thousand extra ips on the > /64 lan and use it for whatever you like. > We are sure going to miss this feature. Nope, even better. You *know* that the endsite falls inside the same /48, which you can lookup in whois, who owns it, then check if it is a house (avg 8 people) or a big company with indeed 10k orso users. With RFC3041 being standard, the same /64 can produce a *lot* of different IP's to your webserver or whatever connector, thus indeed for stats you might want to aggregate those. Of course you can see that an IP is based on RFC3041 by checking the relevant bits, but people could of course also make their bots do it for you. For limiting automatic requests to your website use Captcha's*. Robots can do a lot, but they can't read (yet). Thus for FTP and other services, limit per /48. You then limit per site btw and not per user, which is actually better than what you actually wanted. What if I would have a /24 and let '256 users' in. Remember also that I could have my fridge use an IP, walk there and let it order from your site etc... they are different devices with the same user, /me ;) Simply saying 'that user is the same IP' does not work, but has it ever? (NAT anyone :) Greets, Jeroen * = http://en.wikipedia.org/wiki/Captcha -------------- 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 woeber at cc.univie.ac.at Thu Apr 7 11:58:15 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 07 Apr 2005 11:58:15 +0200 Subject: [address-policy-wg] Policies interact Message-ID: <00A41EF1.8B3EA982.33@cc.univie.ac.at> Sidetracking #2: >Savings in IPv4 space, do not carry over into IPv6. That is why >we lose these savings. But the size of the routing table increases >by 4 times therefore requiring 4 times as much RAM and 4 times as >much time to send/receive full routes. If this is the case we are looking at a poor implementation (memory-consumption-wise), imho. For a routing decision you don't need 32 bits for an IPv4 prefix, and you do not need 128 bits for an IPv6 prefix. My wild guess would be that the ratio is rather on the order of 1:1.5 than 1:4. [ Anyone having statistics about the average length of an IPv4 prefix? Probably in the range of (20..)21..22(..23) ] Wilfried. From Michael.Dillon at radianz.com Thu Apr 7 12:22:53 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 7 Apr 2005 11:22:53 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6bf9497dbe8d2fa49631569440ab03d3@muada.com> Message-ID: > > Right now, the only strong objections I'm seeing appear to be somewhat > > Canutist, despite being otherwise well-informed. > > Wow, that word apears only 4 times on the entire internet. What does it > mean? You have to know the story of King Canute to understand. Read this: http://www.inspirationalstories.com/0/91.html --Michael Dillon From mvyskocil at highway.telekom.at Thu Apr 7 12:34:36 2005 From: mvyskocil at highway.telekom.at (Martin Vyskocil) Date: Thu, 7 Apr 2005 12:34:36 +0200 Subject: [address-policy-wg] Policies interact In-Reply-To: <00A41EF1.8B3EA982.33@cc.univie.ac.at> Message-ID: Hi Wilfried, > [ Anyone having statistics about the average length of an > IPv4 prefix? Probably in the range of (20..)21..22(..23) ] > you can find this information in Philip Smiths "Weekly Routing Table Report": # routing-wg-admin at ripe.net wrote: # # This is an automated weekly mailing describing the state of the Internet # Routing Table as seen from APNIC's router in Japan. # Daily listings are sent to bgp-stats at lists.apnic.net # # If you have any comments please contact Philip Smith . # # Routing Table Report 04:00 +10GMT Sat 19 Mar, 2005 # #<...> # # Number of prefixes announced per prefix length (Global) # ------------------------------------------------------- # # /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 # /7:0 /8:19 /9:3 /10:8 /11:14 /12:62 # /13:152 /14:305 /15:573 /16:8321 /17:2477 /18:4186 # /19:10131 /20:10825 /21:8727 /22:12051 /23:13167 /24:86110 # /25:264 /26:257 /27:110 /28:53 /29:26 /30:90 # /31:0 /32:44 Martin VM404-RIPE From groeskens at bluewin.ch Tue Apr 5 21:15:27 2005 From: groeskens at bluewin.ch (Guido Roeskens) Date: Tue, 05 Apr 2005 21:15:27 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050405141451.GA27819@srv01.cluenet.de> References: <1112642879.28943.1.camel@firenze.zurich.ibm.com> <20050405120903.GA26303@srv01.cluenet.de> <7eb1d338f663501cb3828e6949e173d5@muada.com> <20050405122751.GA26638@srv01.cluenet.de> <3e495f8a04b305dd382b91424ff18adf@muada.com> <20050405133749.GE26638@srv01.cluenet.de> <3656085ad69e4a195c091cee91ed6d7a@muada.com> <20050405141451.GA27819@srv01.cluenet.de> Message-ID: <4252E3CF.90601@bluewin.ch> Daniel Roesen wrote: > On Tue, Apr 05, 2005 at 03:54:33PM +0200, Iljitsch van Beijnum wrote: > >>On 5-apr-05, at 15:37, Daniel Roesen wrote: >> >> >>>>The problem is that PI isn't scalable. >> >>>It's as scalable as PA. There is no inherent difference in scaling how >>>many ISPs there are to the number of end users. Both grow in similar >>>progression. It's not like O(n) vs. O(n^2) or so. >> >>I grant you that there is no difference whether 10000 ISPs inject 10000 >>PA prefixes or 10000 end-users inject 10000 PI prefixes, but I hardly >>think the potential number of ISPs is similar to the potential number >>of end-users. (Or the actual number for both, your pick.) > > > Again: you are talking about theoretical worst-case absolute numbers. > I'm talking about real life. > > I guess you would agree with me that it's currently no problem at all > to obtain an ASN and IPv4 PI if you want to multihome. Right? Yes, but maybe this should change with IPv6. However if IPv6 has adequate solutions for organizations which now want PI. > This has lead to about 17k active ASN out there. Which translates to > 17k-20k (let's give some headroom for special routes for anycast etc) > IPv6 PA/PI routes. Where is your problem? I don't see multiple million > of end sites doing BGP multihoming. Not now, not in ten years. It's > not that we have hundred of thousand of NEW people JUST WAITING for the > availability of PI out there. > > So, when do you estimate will we see let's say more than 100k active > ASNs out there? And even then we're talking about 100k, not 1 million, > not 10 million. > Your tenfold of ASN's etc. could come in 10-20 years easily (maybe even sooner). Many regions in the world until now have only little Internet coverage, don't have the IP space they would like, etc. Some examples: - China (people of 1 Billion, now restricted by political and economical circumstances) - India (soon to be 1 Billion), raising economically (especially in IT technology) - rest of Asia is also demanding more IP space - South America will also adopt the Internet in the future - Africa may develop also > >>>So now start backing your "isn't scalable" claim (in comparision to >>>PA). And back that by hard numbers showing real problems. >> >>Didn't you read my message about memory bandwidth? If that isn't real >>enough for you then this discussion is moot because we're obviously >>operating on different time scales. > > > I'm not into hardware design so I won't comment on that. Oliver is > much more qualified in that as he actually have built those things. > :-) > > >>>>>There is no REAL multihoming without PI yet. And the IETF recently >>>>>narrowed down the road they want to take (solution space) that >>>>>guarrantees that the result won't fit people's needs. The >>>>>multi6=>shim6 >>>>>transition was (for me and quite a few others) the "end of all hope". >> >>>>Why? >> >>>Because the outcome won't provide what people do ask for. >> >>And what are people asking for? > > > At least the same set of features as IPv4 PI BGP multihoming with no > new added significant downsides. > > Perhaps folks should start listening to that instead of sticking the > head into the sand. > > > Regards, > Daniel > Regards, Guido From sascha at eirconnect.net Wed Apr 6 20:34:07 2005 From: sascha at eirconnect.net (Sascha Luck) Date: Wed, 6 Apr 2005 19:34:07 +0100 Subject: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: References: Message-ID: <200504061934.07528.sascha@eirconnect.net> On Wed 06 Apr 2005 14:44, Michael.Dillon at radianz.com wrote: > RIPE must not be seen to be a cabal of ISPs trying to impose > a certain business model through anti-competitive policies. Thank you. This sentence should be inserted, verbatim, into the RIPE statutes. rgds, Sascha Luck From clive at demon.net Thu Apr 7 10:02:53 2005 From: clive at demon.net (Clive D.W. Feather) Date: Thu, 7 Apr 2005 09:02:53 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6bf9497dbe8d2fa49631569440ab03d3@muada.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> Message-ID: <20050407080253.GB3324@finch-staff-1.thus.net> Iljitsch van Beijnum said: >> Right now, the only strong objections I'm seeing appear to be somewhat >> Canutist, despite being otherwise well-informed. > Wow, that word apears only 4 times on the entire internet. What does it > mean? King Cnut 'the Great' ruled England, Denmark, and Norway [1] in the 11th century. The story is told that his courtiers flattered him to the extent of claiming that the king was all-powerful. To prove them wrong, he had his throne set on the beach and pointed out that even the king could not stop the tide coming in. [1] By 1013 the English nobility were so disillusioned by the existing king, Ethelred II 'the Unready' [2], that they deposed him and acknowledged Sweyn "Forkbeard" as king. Following Sweyn's death the next year, Ethelred returned from exile in Normandy but died in April 1016. His son Edmund II "Ironside" took the throne but was defeated at the Battle of Ashingdon by Sweyn's son Cnut. Under the resulting peace treaty Edmund ruled Wessex while Cnut took the rest of England. Edmund died in November leaving Cnut undisputed master of the country. Cnut died in 1035. His sons Harold I "Harefoot" and Harthacanute split the country, the former taking Mercia and Northumbria and the latter Wessex. Up to Harold's death in 1040 [3], Harthacanute spent most of his time in Denmark (which he was also king of) leaving Harold to effectively rule England. Harthacanute died in 1042, to be succeeded by his half-brother (Ethelred's son) Edward III "the Confessor". On Edward's death in 1066 the throne was claimed by both Harold II (his brother-in-law) and William I (a relative by marriage); the matter was decided near Hastings. [2] This word actually means "un-wise" or "ill-advised", not "unprepared". [3] Also the year in which Macbeth succeeded Duncan I in Scotland. Macbeth died in 1057, succeeded by his son Lulach. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From oliver at bartels.de Thu Apr 7 12:39:58 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 07 Apr 2005 12:39:58 +0200 Subject: [address-policy-wg] Policies interact In-Reply-To: <00A41EF1.8B3EA982.33@cc.univie.ac.at> Message-ID: <200504071039.j37Adre5021239@alpha.bartels.de> On Thu, 07 Apr 2005 11:58:15 +0200, Wilfried Woeber, UniVie/ACOnet wrote: > For a routing decision you don't need 32 bits for an IPv4 prefix, > and you do not need 128 bits for an IPv6 prefix. Exact. A international routing decision can be limited to the first 64 Bits. The remaining 64 Bits are some sort of ARP-replacement. > My wild guess would be that the ratio is rather on the order of > 1:1.5 than 1:4. It can be 1:1 (TCAM or sparse tries) for good implementations up to 1:4 or even worse for poor implementations. *Of course* the IPv4 approach with 32 bits has clear advantages regarding real world implementations and a worlwide unique 32 bit address is a reasonable choice. Thus IPv6 makes only sense if: - the remaining address part can be used and internationally routed - there is a clear advantage for using larger addresses - none of these is restricted as it currently is (200 customers rule, no PI) - all important IPv4 features are available with IPv6 Face it: Either IPv6 can be used with its full advantages, which means - full and true routing support for the first 64 bits - Multihoming, PI, reasonable global table processing which imposes: - using state of the art routing hardware and yes, this means spending money, like it or not, - removing unnecessary address assignment restrictions to gain the best results from the large address space, yes, this means trusting the engineers that they will be able to handle larger tables, or IPv6 will die. The market will not accept a IPv6 with address bits overhead not usable for reasonable international connectivity. The market then will stay with IPv4, which is a reasonable choice. Greetings Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From vuori at magenta.net Thu Apr 7 12:42:37 2005 From: vuori at magenta.net (Valtteri Vuorikoski) Date: 07 Apr 2005 10:42:37 +0000 Subject: [address-policy-wg] Re: how 200 /48's fails the job In-Reply-To: Pekka Savola's message of "Tue, 5 Apr 2005 23:13:59 +0300 (EEST)" References: Message-ID: Pekka Savola writes: > On Tue, 5 Apr 2005 Michael.Dillon at radianz.com wrote: > ... > > The 200 new customer limit was meant to be a measure of largeness and > > seriousness. I think that in today's world, that measure fails to do > > the job. > > Could you clarify, why do you think "200 customers" fails as a meter for largeness ? > > There are some odder cases like transit only ISPs (which technically could only have very few direct > organizational customers -- let's assume that those would get the IP space using some other provisions or > as a matter of interpretation), but apart from that, why exactly is requiring 200 customers unreasonable? I think Mr. Bartels already made some of these points, but I'll still add my two (euro)cents to this discussion. I would think that the concept of lumping all "customers" into a single class is flawed. I work for a managed hosting provider, and we currently have POPs in three countries with multiple transit providers and peerings. Obviously we have our own IPv4 allocation. However, our focus is on medium-size and large customers, which are quite unlike residential end-user customers where 200 would be next to nothing. I doubt we'll have 200 such customers (without creative accounting, that is) in a while yet, but we are still doing active business. The current rule effectively prevents us from deploying IPv6 to our customers. In the long run, I believe that as long as the current policy prevents hosting companies who serve content to end-users from deploying IPv6, it removes motivation from the end-user ISPs (who would have no problem getting the allocation) to actually deploy it to their users. While routing table growth is a concern, not having (v6) routing table growth is in my opinion an even larger concern. Therefore my view is that the arbitrary fixed criterion of having to be "large" (for whatever value of large) for a v6 allocation should be dispensed with. -- Valtteri Vuorikoski MagentaSites Oy From Michael.Dillon at radianz.com Thu Apr 7 15:29:44 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 7 Apr 2005 14:29:44 +0100 Subject: [address-policy-wg] Re: how 200 /48's fails the job In-Reply-To: Message-ID: > However, our focus is on medium-size and large customers, which are > quite unlike residential end-user customers where 200 would be next to > nothing. I doubt we'll have 200 such customers (without creative > accounting, that is) in a while yet, but we are still doing active > business. The current rule effectively prevents us from deploying IPv6 > to our customers. I think that the current rule puts RIPE in violation of the EU guidelines on horizontal cooperation agreements. http://europa.eu.int/scadplus/leg/en/lvb/l26062.htm In particular, I believe that it is an unfair limitation of ouput. Of course, I am not a lawyer, but nevertheless, the 200 limitation seems rather dodgy and artificial. I realize that RIPE serves more than just the EU but I think that even in Russia, central Asia and the middle East, there are similar competition laws. As policymakers, we have to be concerned with the legal environment around us, and therefore this limit must be removed. From an engineering viewpoint there is no clear justification for this limit. In all the discussion to date the only thing that seems to have solid engineering justification is that IPv6 /32 addresses cannot be handed out to everyone who wants one. There must be some technical justification for the request, such as the plan to run an IPv6 network that internetworks at least two IPv6 networks. In most cases these two or more networks can be distinguished by being physically disjoint, i.e. two separate buildings or cities. But Internet exchanges and large hosting facilities are in a single location but they are clearly internetworks from the engineering point of view. So if we want a policy that includes a limitation based on real engineering, how do we word it? And how do we ensure that the terms we use are clearly defined. In the past, many such policies have use very ill-defined and vague terminology that often conflicts with the normal English usage of words. Is there a way to define an IPv6 internetwork so that the policy gives clear guidance to RIPE hostmasters but does not fall afoul of EU competition rules? > While routing table growth is a concern, not having (v6) routing table > growth is in my opinion an even larger concern. Therefore my view is > that the arbitrary fixed criterion of having to be "large" (for > whatever value of large) for a v6 allocation should be dispensed with. I really think that the original makers of the policy were not trying to define "large" but were trying to find a way to define an internetwork as distinct from an end site. If we look at the IPv6 Internet as a hierarchy with large high-bandwidth international networks near the root and individual offices at the leaves, then we can see that leaves have a single connection but all other nodes in the hierarchy have two or three or more connections. All the non-leaf nodes are internetworks. The natural processes of corporate growth and consolidation will limit the number of non-leaf nodes in this hierarchy so that it will form some type of flat pyramid. These same mechanisms limit the growth of the global routing table and therefore I feel confident that giving out a /32 to any internetwork with plans to deploy IPv6 will not create a routing table crisis. It would be nice if RIPE could find some university to do a study of the network economy to understand this hierarchy better and give us the information to predict the future number of nodes in the hierarchy. I will note that Merit in the USA recently got a graduate student to do an analysis of questionnaires from several years of NANOG meetings. It's not network engineering but this kind of research is still very useful to policymakers. --Michael Dillon From iljitsch at muada.com Thu Apr 7 15:59:40 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 7 Apr 2005 15:59:40 +0200 Subject: [address-policy-wg] Re: how 200 /48's fails the job In-Reply-To: References: Message-ID: <72095e94f26065a9d83271b608be42a9@muada.com> On 7-apr-05, at 15:29, Michael.Dillon at radianz.com wrote: > I am not a lawyer [...] > As policymakers, we have to be concerned with the legal > environment around us, and therefore this limit must be > removed. This policy has been in use around the world for years and apparently nobody bothered to challenge it in court. So either nobody cares or the legality is just fine. > There must be some technical justification > for the request, such as the plan to run an IPv6 network > that internetworks at least two IPv6 networks. [...] > I feel confident that giving out a /32 to > any internetwork with plans to deploy IPv6 will not create > a routing table crisis. So being an internetwork gets you a /32, and you're an internetwork if you (inter)connect at least two "IPv6 networks". Care to define "IPv6 network"? Would that be another organization (so 200 becomes 2)? Or just a subnet (so 200 becomes 0)? The trouble with all of this is that if we lower the bar so entities that we all feel should be able to have their own prefix can get one, this immediately opens the door for a whole bunch of other people who shouldn't. For instance, we've seen some messages from different LINX people. Apparently they have a number of projects (the number being smaller than 200) that require IPv6 addresses and they would like to assign those addresses from a prefix of their own. Since internet exchanges already get a prefix for the exchange fabric it seems reasonable to give them a larger prefix than just one for the exchange fabric so they can accommodate these other assignments as well as their own stuff from this same prefix. But what qualifies as an "internet exchange"? There are already many "internet exchanges" with members that can be comfortably counted on the fingers of one hand. So rather than just remove the 200 limit and brag that we're so good at predicting the future that this will NEVER pose a problem, it would be good to come up with something that's actually BETTER than the current policy. I'm still waiting for examples of PA requests that were turned down but, in our collective opinion, shouldn't have, BTW. I was thinking about simply reusing the IPv6 policies and requiring applicants to show the need for a certain number of addresses. But the problem is that with IPv6 you can renumber thousands of hosts with a couple of lines of router configuration. What is exactly the circumstance that makes the difference between getting PA space from an ISP being just inconvenient, and being too problematic to reasonably ask people to do so? From Michael.Dillon at radianz.com Thu Apr 7 16:36:14 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 7 Apr 2005 15:36:14 +0100 Subject: [address-policy-wg] Re: how 200 /48's fails the job In-Reply-To: <72095e94f26065a9d83271b608be42a9@muada.com> Message-ID: > This policy has been in use around the world for years and apparently > nobody bothered to challenge it in court. So either nobody cares or the > legality is just fine. Perhaps it means that nobody cares yet. On the other hand, we have a proposed change to the policy and two people on the list today have mentioned that they know cases in which this policy has actually created a commercial problem. So perhaps it means that the people who care are willing to work within the RIPE policy process first. Also, I believe that it puts them in a stronger position to win a lawsuit if they can show that they did try to resolve the problem outside the courts first. > So being an internetwork gets you a /32, and you're an internetwork if > you (inter)connect at least two "IPv6 networks". > > Care to define "IPv6 network"? I think we can leverage the existing rules for allocating a /48 and say that a /48 allocation is an IPv6 network. Or, more precisely, an IPv6 network is a network which meets the requirements for a /48 allocation. Those requirements are defined elsewhere. > The trouble with all of this is that if we lower the bar so entities > that we all feel should be able to have their own prefix can get one, > this immediately opens the door for a whole bunch of other people who > shouldn't. Policies are rarely 100% perfect. If we can make this one better than it was, then we have succeeded. If future experience shows that there are a whole bunch of /32 allocations going to people who shouldn't get them, then we can change the policy at that time, when we have the benefit of greater knowledge. > Since internet exchanges > already get a prefix for the exchange fabric it seems reasonable to > give them a larger prefix than just one for the exchange fabric so they > can accommodate these other assignments as well as their own stuff from > this same prefix. It does not seem reasonable to me. I don't like to see the policy behaviour dependent on business models. If a company has a business model that includes internet exchange and something else, then I think we should be prepared to deal with both aspects of the business seperately. We treat internet exchanges as special cases so if the same company wants to do other business then they really should not use the same allocation for the other business. > But what qualifies as an "internet exchange"? There are already many > "internet exchanges" with members that can be comfortably counted on > the fingers of one hand. > > So rather than just remove the 200 limit and brag that we're so good at > predicting the future that this will NEVER pose a problem, it would be > good to come up with something that's actually BETTER than the current > policy. If we can come up with something a LOT better, that is good. But if we cannot come up with something a lot better then we should make things a little bit better by removing the 200 limit. Internet exchanges are IPv6 interconnection points that allow companies to exchange traffic locally to avoid tromboning it out of the local area and back again. If an exchange has 4 members but achieves this "path shortening" then it is an exchange. > I was thinking about simply reusing the IPv6 policies and requiring > applicants to show the need for a certain number of addresses. But the > problem is that with IPv6 you can renumber thousands of hosts with a > couple of lines of router configuration. You make a good case here for removing the 200 limit. If, at a future time, we find that there are too many /32s and we need to de-list some of the allocations, then the affected operators can easily renumber as you have pointed out. --Michael Dillon From mike at linx.net Thu Apr 7 16:35:11 2005 From: mike at linx.net (Mike Hughes) Date: Thu, 07 Apr 2005 15:35:11 +0100 Subject: [address-policy-wg] Re: how 200 /48's fails the job In-Reply-To: <72095e94f26065a9d83271b608be42a9@muada.com> References: <72095e94f26065a9d83271b608be42a9@muada.com> Message-ID: <15D1C6D614880A369338E0E1@Mike_HP.linx.net> --On 07 April 2005 15:59 +0200 Iljitsch van Beijnum wrote: > I'm still waiting for examples of PA requests that were turned down but, > in our collective opinion, shouldn't have, BTW. For what reason? If we dive into specifics, all we will end up doing is "legislating" for (and wasting time over) corner cases. Maybe there aren't any requests which have been rejected, because most people who would be at risk of being turned down either, read the initial allocation criteria, and either: a) Realise they won't make the "200 number", don't bother applying, or, b) Realise they won't make the "200 number", fabricate/lie/whatever on their application and get the /32. Can the NCC help by supplying some general statistics on IPv6 allocations (such as number rejected, and for what reason)? I seem to recall that we only seem to hear about successful allocations made in the NCC reports. The number of rejections would probably make far more interesting reading/viewing. I think we had a show of hands in Manchester along similar lines, showing that there was some frustrated demand from networks which clearly weren't end sites but were also not prepared to fabricate their v6 requests. Maybe this will help us better understand the scale of the "problem". Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1" From leo at ripe.net Thu Apr 7 17:23:17 2005 From: leo at ripe.net (leo vegoda) Date: Thu, 7 Apr 2005 12:23:17 -0300 Subject: [address-policy-wg] Re: how 200 /48's fails the job In-Reply-To: <15D1C6D614880A369338E0E1@Mike_HP.linx.net> References: <72095e94f26065a9d83271b608be42a9@muada.com> <15D1C6D614880A369338E0E1@Mike_HP.linx.net> Message-ID: <02f346d910936e360b11f7f46c9c1e1e@ripe.net> Hi Mike, On Apr 7, 2005, at 11:35 am, Mike Hughes wrote: [...] > Can the NCC help by supplying some general statistics on IPv6 > allocations > (such as number rejected, and for what reason)? > > I seem to recall that we only seem to hear about successful allocations > made in the NCC reports. The number of rejections would probably make > far > more interesting reading/viewing. We are working on producing some statistics along these lines. If you'd like, I can prepare a presentation for RIPE 50 in May. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC From randy at psg.com Thu Apr 7 18:10:55 2005 From: randy at psg.com (Randy Bush) Date: Thu, 7 Apr 2005 06:10:55 -1000 Subject: [address-policy-wg] Policies interact References: <00A41EF1.8B3EA982.33@cc.univie.ac.at> <200504071039.j37Adre5021239@alpha.bartels.de> Message-ID: <16981.23439.210391.295467@roam.psg.com> >> For a routing decision you don't need 32 bits for an IPv4 prefix, >> and you do not need 128 bits for an IPv6 prefix. > Exact. > A international routing decision can be limited to the first 64 Bits. > The remaining 64 Bits are some sort of ARP-replacement. nope. folk are using /126s internally, and have igp or ibgp carrying those prefixes. of course, they also have the classic loopbacks for bgp, which can be /128s. real hardware vendors know this and don't make the same mistakes as were made in the old a/b/c days. randy From oliver at bartels.de Thu Apr 7 18:59:56 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 07 Apr 2005 18:59:56 +0200 Subject: [address-policy-wg] Policies interact In-Reply-To: <16981.23439.210391.295467@roam.psg.com> Message-ID: <200504071659.j37Gxpe5029972@alpha.bartels.de> On Thu, 7 Apr 2005 06:10:55 -1000, Randy Bush wrote: >nope. folk are using /126s internally, and have igp or ibgp carrying >those prefixes. of course, they also have the classic loopbacks for >bgp, which can be /128s. real hardware vendors know this and don't >make the same mistakes as were made in the old a/b/c days. TCAM IC's typically process 72 address lines per cycle, which means 64 bit for the address plus 8 bit policy etc. Even if the hardware permits it, I don't think it is a good idea to put /65 and more specific prefixes into the IGP. This has nothing to do with a/b/c mistakes, you would just throw away a possible optimization path for no additional gain at all. There is a good chance some day (in the next 50 years) these additional 8 bytes will have a better use than the current "we already know where you are" adresses. Best Regards Oliver 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 Thu Apr 7 20:25:51 2005 From: gert at space.net (Gert Doering) Date: Thu, 7 Apr 2005 20:25:51 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6bf9497dbe8d2fa49631569440ab03d3@muada.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> Message-ID: <20050407182551.GJ84850@Space.Net> Hi, On Wed, Apr 06, 2005 at 10:22:49PM +0200, Iljitsch van Beijnum wrote: > as stealth PI) I'm keeping an open mind. Still, just repeating "200 is > a problem" to eachother doesn't help, we need to know where the 200 > limit gets in the way in the real world. People are not making IPv6 allocation requests because they assume that they won't have 200 active IPv6 customers in two years time. Those that *do* make requests usually find a way to word their "plan" in a way that the request is granted, but a fair number of smaller ISPs have told me that they didn't send in a request at all, due to not wishing to tell lies. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Thu Apr 7 21:00:33 2005 From: gert at space.net (Gert Doering) Date: Thu, 7 Apr 2005 21:00:33 +0200 Subject: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <0IEJ00MUKQ5AE160@bgo1sminn1.broadpark.no> References: <4f6478ee33c9fc93bb2613ecb136ca38@muada.com> <0IEJ00MUKQ5AE160@bgo1sminn1.broadpark.no> Message-ID: <20050407190033.GK84850@Space.Net> Hi, On Thu, Apr 07, 2005 at 12:21:06AM +0200, J?rgen Hovland wrote: > How long do you think this /48 policy will last? I was hoping for > at least 60 years++ so I don't need to have the same discussion > again with IPv8. While I personally dislike /64s and /48s (for some other reasons that do not need discussion here, as there are good reasons for /64 and /48, and I can accept these), your argumentation is still flawed. Everybody that tells me "we will run out of IPv6 address space!!!!" has pretty obviously not done the math - just count how many /48s are there, and then do some estimation on how many people earth can suffice, and how many /48s per person for each of those we have. Out of 2000::/3. *Then* come back and tell me (with a straight face) "we will run out of IPv6 addresses because /48s are such a great waste". [..] > So you are saying that documenting your need of a /48 will be > rejected by future LIRs due to their own address policy and they > will give you a /56 instead because that???s what their policy says? The whole point of the /48s is that you do NOT need to argue with your LIR. You'll *always* get a /48 when changing ISPs, and that's big enough for all but the largest customers. This is why /48s are *good*. (Unless, of course, your network is too large for a /48 - provisions for that case exist). > I don't believe that will happen as long as the RIRs have somewhat > loose policies. ARIN allocates you a netblock and you do whatever > you want with it. With RIPE you need to apply for allocations within > your assigned netblock. You're seriously confused about terminology and about RIPE IPv6 policy. [..] > But what about you document the need of a /40 but will only get a /48 (/47)? Show me the network plan that documents the need for a /40. 16 million independent multiaccess networks ("LAN")??? (There are some, but it's going to be "few"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jon at lawrence.org.uk Thu Apr 7 22:57:53 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 7 Apr 2005 21:57:53 +0100 Subject: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <20050407190033.GK84850@Space.Net> References: <4f6478ee33c9fc93bb2613ecb136ca38@muada.com> <0IEJ00MUKQ5AE160@bgo1sminn1.broadpark.no> <20050407190033.GK84850@Space.Net> Message-ID: <200504072157.53629.jon@lawrence.org.uk> On Thursday 07 April 2005 20:00, Gert Doering wrote: > Hi, > > On Thu, Apr 07, 2005 at 12:21:06AM +0200, J?rgen Hovland wrote: > > How long do you think this /48 policy will last? I was hoping for > > at least 60 years++ so I don't need to have the same discussion > > again with IPv8. > > While I personally dislike /64s and /48s (for some other reasons that > do not need discussion here, as there are good reasons for /64 and /48, > and I can accept these), your argumentation is still flawed. > > Everybody that tells me "we will run out of IPv6 address space!!!!" has > pretty obviously not done the math - just count how many /48s are there, > and then do some estimation on how many people earth can suffice, and > how many /48s per person for each of those we have. Out of 2000::/3. > > *Then* come back and tell me (with a straight face) "we will run out > of IPv6 addresses because /48s are such a great waste". > While I understand and accept your argument here, whether we'd ever run out of address space imho has nothing to do with /48's. How many /32's have we got to play with ( 536870912 per /3 by my calculations) OK, that's still a big number. But if we allow everyone who wants to multihome a /32, there is the possibility that we could run out - not in the near future that's for sure. Many companies are still discovering how/if they can use the internet. As more and more uses for the 'net are thought up, companies are going to become more and more reliant on the 'net to the point where they will/may struggle to function without it - somewhere around that point, all companies will need to have a permanent connection and in my mind a permanent connection means multihoming. How many companies are there in this world ? Thus how many potential multihomers have we got ? - more than the number of /32's available, I doubt it (I don't think there are 4 billion companies). We're a along way off home users multihoming, so perhaps we'll never run out of /32's. But I for one would not like to bet on it. Jon From m.hallgren at free.fr Thu Apr 7 23:08:06 2005 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 7 Apr 2005 23:08:06 +0200 Subject: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <200504072157.53629.jon@lawrence.org.uk> Message-ID: <20050407210813.D647C1C00164@mwinf0504.wanadoo.fr> > > > While I understand and accept your argument here, whether > we'd ever run out of address space imho has nothing to do > with /48's. How many /32's have we got to play with ( > 536870912 per /3 by my calculations) OK, that's still a big > number. But if we allow everyone who wants to multihome a > /32, there is the possibility that we could run out - not in > the near future that's for sure. > > Many companies are still discovering how/if they can use the > internet. As more and more uses for the 'net are thought up, > companies are going to become more and more reliant on the > 'net to the point where they will/may struggle to function > without it - somewhere around that point, all companies will > need to have a permanent connection and in my mind a > permanent connection means multihoming. > > How many companies are there in this world ? > Thus how many potential multihomers have we got ? - more > than the number of /32's available, I doubt it (I don't think > there are 4 billion companies). > We're a along way off home users multihoming, so perhaps > we'll never run out of /32's. But I for one would not like to > bet on it. Shared reluctancy to bet on it, as a basis of building policy at least. Cheers, mh (as6453) > > Jon > > From jorgen at hovland.cx Fri Apr 8 00:05:58 2005 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Fri, 08 Apr 2005 00:05:58 +0200 Subject: SV: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <20050407190033.GK84850@Space.Net> Message-ID: <0IEL002FOK3YR2I0@bgo1sminn1.broadpark.no> -----Opprinnelig melding----- Fra: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] P? vegne av Gert Doering Sendt: 7. april 2005 21:01 > > >Everybody that tells me "we will run out of IPv6 address space!!!!" has >pretty obviously not done the math - just count how many /48s are there, >and then do some estimation on how many people earth can suffice, and >how many /48s per person for each of those we have. Out of 2000::/3. > >*Then* come back and tell me (with a straight face) "we will run out >of IPv6 addresses because /48s are such a great waste". I will have no problem telling you that. I agree with Randy (every size limit that has ever been done in computing has proved to be too small in the long run). I am not implying that we will run out of addresses tomorrow, only that we will run out. >Show me the network plan that documents the need for a /40. 16 million >independent multiaccess networks ("LAN")??? (There are some, but it's >going to be "few"). Well then I can show you a plan that doesn't work: The 200 /48 customer assignment policy plan (which was what I argued about in the first place) LIRs need IPv6 prefixes in order to use IPv6. What are you waiting for, RIPE? A better IP protocol? Since it is not due to the infinite, as you say it, resource of IPv6 addresses the reason for this policy must be due to the problem with a large, global routing table. The economical side of an enormous routing table will affect anyone. I am sure we can agree on that this won't kill the entire Internet. If you truly need multihoming, you can afford it whatever it cost. The whole multihoming issue is one big economical reason anyway. Therefore I can't see the problem with my open policy suggestion. I believe it to be better than the existing one although perhaps not 110% perfect. You will simply charge the customer more if it really comes to it in 100 years, but by then I, and you should too, expect better cost-effective routing hardware. The customer will pay, they always do. Joergen Hovland ENK From gert at space.net Fri Apr 8 10:13:07 2005 From: gert at space.net (Gert Doering) Date: Fri, 8 Apr 2005 10:13:07 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <64d55db8d8ca39f354dc39abc788e79d@muada.com> References: <4250C946.5020502@tiscali.no> <73d65be4f7ba37beea7c7f4c55913836@it.uc3m.es> <20050404124426.GC84850@Space.Net> <20050404134844.GL84850@Space.Net> <6146a89cfc4b39e8994430b6f1c3a42a@muada.com> <20050405123446.GJ84850@Space.Net> <64d55db8d8ca39f354dc39abc788e79d@muada.com> Message-ID: <20050408081307.GM84850@Space.Net> Hi, On Tue, Apr 05, 2005 at 03:20:45PM +0200, Iljitsch van Beijnum wrote: > On 5-apr-05, at 14:34, Gert Doering wrote: > > >>Either having very many people get /32s is harmful, or it isn't. How > >>does paying the RIPE fee move this from "harmful" to "non-harmful"? > > >It reduces the possible amount of applicants from "anybody out there" > >(many billions) to "anybody who thinks this is so important to his > >heart / business that he's willing to shell out serious money for it". > > So you agree that an excessive number of prefixes is bad? Of course. The question is "how many is excessive" and "is there real danger that the number of LIRs will reach 'excessive' any time soon" (5 years)? I pick "5 years", because I guess that's the time it will need to develop significant changes in the IPv6 protocol stacks, like "shim6" or whatever will come up - and then we certainly need to reconsider the policy. > Then the only thing we disagree about is whether the LIR fee will be > enough to make the number non-excessive. It will at first, of course, > but it's unlikely to do so in the long term as RIRs are not-for-profit > so the more people become a LIR, the lower the fees become. I'm sure ncc-services will find ways to keep up the fees :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Michael.Dillon at radianz.com Fri Apr 8 12:58:13 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 8 Apr 2005 11:58:13 +0100 Subject: SV: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <0IEL002FOK3YR2I0@bgo1sminn1.broadpark.no> Message-ID: > I am not implying that we will run out of addresses tomorrow, only > that we will run out. For the purposes of making policy, magnitude matters. I agree that we will eventually run out of IPv6 addresses. Will it be 1000 years from now? 500 years? 100 years? The magnitude of the time period matters because I do not believe that RIPE is making policy for 1000 years or 500 years or even 100 years. If RIPE can repair the IPv6 policy into something that will work for the next 5 years, then RIPE is doing a fine job. If that results in accelerated uptake of /32's which leads to a projected runout of 2000::/3 50 years from now, then I do not see any problem whatsoever from the point of view of IPv6 address space exhaustion. If that were the case, then the prudent way to deal with it is to run with the new relaxed policy for 5 years, 1/10th of the runout period, and then decide what to do with the benefits of hindsight. Anybody who claims that there is an issue with waste of addresses or with conservation of addresses, MUST demonstrate that issue with hard numbers and projected runout dates, otherwise we should ignore them because they do not know what they are talking about. IPv6 is not IPv4. Quantity changes into quality. It is like adding heat to water. At some point the quantity of heat causes the water to undergo a qualitative transformation and we no longer have water any more. The size of the IPv6 address space means that IPv6 is qualitatively different from IPv4 and our policies must recognize that reality. --Michael Dillon From ncc at ripe.net Fri Apr 8 14:10:07 2005 From: ncc at ripe.net (Axel Pawlik) Date: Fri, 08 Apr 2005 14:10:07 +0200 Subject: [address-policy-wg] ICANN Calls for Comments on the Proposed Review Procedure for ASO Policy Proposal Message-ID: <5.2.1.1.2.20050408140251.0441b6a0@mailhost.ripe.net> Dear Colleagues, The RIPE NCC invites all members of the community to comment on ICANN's proposed Review Procedure for Address Supporting Organization (ASO) policy proposals. On April 6, 2005, ICANN called for public comments on this proposed Review Procedure. Further information and a link for submitting comments are available on the ICANN website at: http://www.icann.org/announcements/announcement-06apr05.htm Regards, Axel Pawlik Managing Director RIPE NCC From woeber at cc.univie.ac.at Fri Apr 8 17:07:40 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 08 Apr 2005 17:07:40 +0200 Subject: [address-policy-wg] Policies interact Message-ID: <00A41FE5.EF9F38F2.11@cc.univie.ac.at> >>> For a routing decision you don't need 32 bits for an IPv4 prefix, >>> and you do not need 128 bits for an IPv6 prefix. >> Exact. >> A international routing decision can be limited to the first 64 Bits. >> The remaining 64 Bits are some sort of ARP-replacement. > >nope. folk are using /126s internally, and have igp or ibgp carrying >those prefixes. of course, they also have the classic loopbacks for >bgp, which can be /128s. real hardware vendors know this and don't >make the same mistakes as were made in the old a/b/c days. > >randy I thought we were talking about the routing table size and memory requirements for the DFZ. Are you implying that we will see those more specific /126s or /128s in the global routing table? Wilfried. From jorgen at hovland.cx Fri Apr 8 22:36:45 2005 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Fri, 08 Apr 2005 22:36:45 +0200 Subject: SV: SV: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria] In-Reply-To: <200504072157.53629.jon@lawrence.org.uk> Message-ID: <0IEN006SYAN626E1@bgo1sminn1.broadpark.no> -----Opprinnelig melding----- Fra: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] P? vegne av Jon Lawrence >While I understand and accept your argument here, whether we'd ever run out >of >address space imho has nothing to do with /48's. How many /32's have we got >to play with ( 536870912 per /3 by my calculations) OK, that's still a big >number. But if we allow everyone who wants to multihome a /32, there is the >possibility that we could run out - not in the near future that's for sure. FYI: There are LIRs with larger prefixes than /32 (/19, /20, /23++) because they argued that 65536 /48s wasn't enough. Expect more of these larger allocations. Cheers, Joergen Hovland ENK From groeskens at bluewin.ch Mon Apr 11 10:41:29 2005 From: groeskens at bluewin.ch (Guido Roeskens) Date: Mon, 11 Apr 2005 10:41:29 +0200 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio Message-ID: <425A3839.6050104@bluewin.ch> Hello, we from Bluewin fully support the proposal Policy proposal: #beta: IPv4-HD-Ratio LIR: ch.bluewindow Vote: YES Comment: ISP's providing access services to many customers face several problems - Usage in different PoP's changes; at one time you have many customers in one PoP, at another time in others. You need to supply enough adresses to all PoPs even though they aren't needed all the time. - Assymetric usage of pools and redundancy To provide redundancy you overallocate some IP addresses to be able to handle the failure of single devices The pool usage on the devices and device groups are not balanced - RFC 3194 is as true for IPv4 as for IPv6 - consistency between IPv4 and IPv6 policies Kind regards, Guido Roeskens Swisscom Fixnet AG Bluewin From adiel at akplogan.com Wed Apr 13 19:15:24 2005 From: adiel at akplogan.com (Adiel AKPLOGAN) Date: Wed, 13 Apr 2005 19:15:24 +0200 Subject: [address-policy-wg] Policy proposal for changes in RIPE policy Documents. Message-ID: <6.1.2.0.2.20050413191421.059c1a88@207.44.238.73> Hello, This is a policy proposal to modify RIPE NCC policy documents to take in account the full recognition of AfriNIC. === 1.Number (assigned by the RIPE NCC) 2.Policy Proposal Name: Policy text modifications to take account of ICANN recognition of AfriNIC as a fully functioning RIR. 3.Author a.name: Adiel Akplogan b.e-mail: adiel at afrinic.net c.telephone:+230 259 2409 d.organisation: AfriNIC 4.Proposal Version: 1.0 5.Submission Date: 6.Suggested WG for discussion and publication Address Policy Working Group 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: renewable a.temporary, permanent, or renewable. 9.Summary of proposal To modify the policy document text to reflect full recognition of AfriNIC as a functioning RIR. 10. Policy text a.Current (if modify): "1.0 Introduction The RIPE NCC is an independent association and serves as one of four Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator." b.New: "1.0 Introduction The RIPE NCC is an independent association and serves as one of /five/ Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia." a.Current (if modify): "5.1 First Allocation The RIPE NCC's minimum allocation size is /21. The minimum allocation size for countries in Africa is /22." b.New: "5.1 First Allocation The RIPE NCC's minimum allocation size is /21." 11. Rationale: a.Arguments supporting the proposal With the recognition of AfriNIC as a fully functioning and independant RIR there is a need to modify this document reflecting this change. b.Arguments opposing the proposal None. == Kind regards. From randy at psg.com Wed Apr 13 19:21:32 2005 From: randy at psg.com (Randy Bush) Date: Wed, 13 Apr 2005 13:21:32 -0400 Subject: [address-policy-wg] Policy proposal for changes in RIPE policy Documents. References: <6.1.2.0.2.20050413191421.059c1a88@207.44.238.73> Message-ID: <16989.21788.11758.111536@roam.psg.com> simple, to the point, correct, and seemingly useful. randy From tim.streater at dante.org.uk Thu Apr 14 12:49:25 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 14 Apr 2005 11:49:25 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <20050407182551.GJ84850@Space.Net> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> <20050407182551.GJ84850@Space.Net> Message-ID: <6.2.1.2.2.20050414113901.03a3b9c8@mail.dante.org.uk> At 19:25 07/04/2005, Gert Doering wrote: >Hi, > >On Wed, Apr 06, 2005 at 10:22:49PM +0200, Iljitsch van Beijnum wrote: >> as stealth PI) I'm keeping an open mind. Still, just repeating "200 is >> a problem" to eachother doesn't help, we need to know where the 200 >> limit gets in the way in the real world. > >People are not making IPv6 allocation requests because they assume that >they won't have 200 active IPv6 customers in two years time. > >Those that *do* make requests usually find a way to word their "plan" >in a way that the request is granted, but a fair number of smaller ISPs >have told me that they didn't send in a request at all, due to not >wishing to tell lies. We are probably in this camp. We manage two transit networks, one of which is intended to manage itself in 2-3 years. I was able to get PI v4 space to address its PoPs, but the existing policies won't allow me to do the same for v6, so no point in applying. Or does a transit network count as an exchange? We think the 200-customer criterion should be scrapped, and so support the proposal. -- Tim From jeroen at unfix.org Thu Apr 14 13:51:10 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 14 Apr 2005 13:51:10 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <6.2.1.2.2.20050414113901.03a3b9c8@mail.dante.org.uk> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> <20050407182551.GJ84850@Space.Net> <6.2.1.2.2.20050414113901.03a3b9c8@mail.dante.org.uk> Message-ID: <1113479471.7135.8.camel@firenze.zurich.ibm.com> On Thu, 2005-04-14 at 11:49 +0100, Tim Streater wrote: > At 19:25 07/04/2005, Gert Doering wrote: > >Hi, > > > >On Wed, Apr 06, 2005 at 10:22:49PM +0200, Iljitsch van Beijnum wrote: > >> as stealth PI) I'm keeping an open mind. Still, just repeating "200 is > >> a problem" to eachother doesn't help, we need to know where the 200 > >> limit gets in the way in the real world. > > > >People are not making IPv6 allocation requests because they assume that > >they won't have 200 active IPv6 customers in two years time. > > > >Those that *do* make requests usually find a way to word their "plan" > >in a way that the request is granted, but a fair number of smaller ISPs > >have told me that they didn't send in a request at all, due to not > >wishing to tell lies. > > We are probably in this camp. We manage two transit networks, > one of which is intended to manage itself in 2-3 years. > I was able to get PI v4 space to address its PoPs, but the existing > policies won't allow me to do the same for v6, so no point in applying. Question, do you need: * Globally Unique Address Space or: * Globally Unique Address Space that is meant to be in the global routing tables(*1). > Or does a transit network count as an exchange? IMHO, one can see it indeed as an exchange, in which case you will get the first option from the above question. But as it is a IX block it is not supposed to be in the routing tables as a single /48 and thus might not be globally routed. Greets, Jeroen (*1) because for eg a /48 there is no aggregate that would lead it to be sent to your box. Global Routing tables = a prefix which is available in most networks. -------------- 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 tim.streater at dante.org.uk Thu Apr 14 15:30:55 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 14 Apr 2005 14:30:55 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria In-Reply-To: <1113479471.7135.8.camel@firenze.zurich.ibm.com> References: <81EABA0BE0941D5F094021A0@Mike_HP.linx.net> <6bf9497dbe8d2fa49631569440ab03d3@muada.com> <20050407182551.GJ84850@Space.Net> <6.2.1.2.2.20050414113901.03a3b9c8@mail.dante.org.uk> <1113479471.7135.8.camel@firenze.zurich.ibm.com> Message-ID: <6.2.1.2.2.20050414133419.039a6c58@mail.dante.org.uk> At 12:51 14/04/2005, Jeroen Massar wrote: >On Thu, 2005-04-14 at 11:49 +0100, Tim Streater wrote: >> At 19:25 07/04/2005, Gert Doering wrote: >> >Hi, >> > >> >On Wed, Apr 06, 2005 at 10:22:49PM +0200, Iljitsch van Beijnum wrote: >> >> as stealth PI) I'm keeping an open mind. Still, just repeating "200 is >> >> a problem" to eachother doesn't help, we need to know where the 200 >> >> limit gets in the way in the real world. >> > >> >People are not making IPv6 allocation requests because they assume that >> >they won't have 200 active IPv6 customers in two years time. >> > >> >Those that *do* make requests usually find a way to word their "plan" >> >in a way that the request is granted, but a fair number of smaller ISPs >> >have told me that they didn't send in a request at all, due to not >> >wishing to tell lies. >> >> We are probably in this camp. We manage two transit networks, >> one of which is intended to manage itself in 2-3 years. >> I was able to get PI v4 space to address its PoPs, but the existing >> policies won't allow me to do the same for v6, so no point in applying. > >Question, do you need: > * Globally Unique Address Space >or: > * Globally Unique Address Space that is meant to > be in the global routing tables(*1). > >> Or does a transit network count as an exchange? > >IMHO, one can see it indeed as an exchange, in which case you will get >the first option from the above question. But as it is a IX block it is >not supposed to be in the routing tables as a single /48 and thus might >not be globally routed. It does need to be globally routeable. Our customer networks may have access to some of our infrastructure items. Now, they could make a hole in their policy and accept a /48, but exceptions are best avoided. In addition, we may host our web-servers at a PoP, and occasionally host third-party workstations at PoPs when we collaborate with the third parties on research projects. Cheers, -- Tim From hpholen at tiscali.no Sat Apr 16 09:02:42 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sat, 16 Apr 2005 09:02:42 +0200 Subject: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy In-Reply-To: <4228B939.2020509@tiscali.no> References: <4228B939.2020509@tiscali.no> Message-ID: <4260B892.2050901@tiscali.no> Dear all, After concideration and consultation with mu co-chairs I propose to exted the discussion period to May 6th so we still have oportunity to discuss this at the RIPE meeting. Best Regards, Hans Petter Holen Address Policy Chair Hans Petter Holen wrote: > Dear all, > Please find enclosed a policy proposal. As per my previous message I > will "beta-test" the new PDP on this proposal. > The current proposal has been discussed previously and has now been > re-formulated after that discussion. > My proposal is to enter this proposal into the Discussion Phase with a > time line of 2 weeks ending on April 4th. > > Best Regards, > > Hans Petter > > > 1.Number (assigned by the RIPE NCC) > alpha > > 2.Policy Proposal Name: TLD Anycast Allocation Policy > > 3.Author > a.name: Andreas Baess > b.e-mail: baess at denic.de > c.telephone: +49 69 27235 0 > d.organisation: DENIC e.G. > > 4.Proposal Version: 1 > > 5.Submission Date: > > 6.Suggested WG for discussion and publication: > Address Policy Working Group > > 7.Proposal type: new > > 8.Policy term: renewable > > 9.Summary of proposal > > To enable ccTLD and gTLD nameserver operators to provide their DNS > service > using shared unicast technology, RIPE NCC is able to assign one IPv4 and > IPv6 prefix per operator that is not likely to be filtered by common > practise for anycast-operation of their DNS services. > > 10. Policy text > > a.Current: N/A > > b.New: > > "If the nameserverset of a TLD without anycasting technology applied > would > not pass the IANA Administrative Procedure for Nameserver Delegation and > Glue Data (http://www.iana.org/procedures/delegation-data.html) may > receive > dedicated network prefixes for the sole purpose of anycasting name > servers, > as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one > /32 IPv6 prefix per operator. The prefixes shall be tagged as > 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the > RIPE NCC > if not in use for anycast DNS any longer." > > 11. Rationale: > > PROS > > A. Acceptance of DNS for special treatment > > Studies like > http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.pdf > > shows clearly that ccTLD and gTLD nameservers are a critical network > infrastructure that justify special policies to guarantee operability of > Internet applications. > > B. Policy Harmonization > > Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing > assignments to network critical infrastructure. All three policies > classify > TLDs as critical infrastructure. Extracts from these policies can be > found > in Appendices I through III. > C. Scalability of DNS > To serve the projected increase of DNS queries and to ensure sufficient > network topological coverage and diversity TLD managers need to deploy > an increasing number of nameservers. > > D. Resilience > Internet has become part of the daily life and their availabilty is as > important as the availability of all public services. Anycasting is > currently the state-of-the-art solution to lower the impact of DDoS > attacks. > > E. IPv6 Support > > As the world starts exploiting IPv6, the DNS infrastructure should > support > IPv6 natively. However it is not yet possible to reduce the number of > nameservers in the IPv4 cloud. > > CONS > F. Waste of Address Space > > Accepting a number of IPv4/24 and IPv6/32 allocations for critical > network > infrastructures does not align with the traditional address conservation > efforts. With anycasting it is very likely that only a few addresses from > the entire assignment would be used. > > 2. Root DNS are special, others are not > > RIPE document 233 dated from 24th May 2002 says: "Although it is > undesirable > to give special status to any IP (IPv4 or IPv6) address block, it was > agreed > by the community that the particular need defined in this document is > the only > justifiable exception to that general principle." > > 3. Assigning an own network prefix is just a workaround to ensure global > reachability which could also be achieved by adjusting currently deployed > route filter practices. > > Appendix I > > APNIC Policy > > (Following section is taken from > http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3) > > 11.3 Critical infrastructure > > The following critical infrastructure networks, if operating in the > Asia Pacific region, are eligible to receive a portable assignment: > > * root domain name system (DNS) server; > * global top level domain (gTLD) nameservers; > * country code TLD (ccTLDs) nameservers; > * IANA; > * Regional Internet Registry (RIRs); and > * National Internet Registry (NIRs). > > Assignments to critical infrastructure are available only to the actual > operators of the network infrastructure performing such functions. > Registrar organisations which do not actually host the network housing > the registry infrastructure, will not be eligible for an assignment > under this policy. > > The minimum assignment made under these terms is /24. > > > > Appendix II > > ARIN Policy > > (Following section taken from > http://ww2.arin.net/policy/index.html#four4) > > 4.4. Micro-allocation - ARIN will make micro-allocations to critical > infrastructure providers of the Internet, including public exchange > points, > core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD > operators) as well as the RIRs and IANA. These allocations will be no > longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations > may be granted in certain situations. > > Appendix III > > LACNIC > > (Following section is taken from http://lacnic.net/policy-en.pdf) > > 3.3.3 Micro Allocations > > Micro allocation is the name given to those allocations that imply blocks > smaller than /20 but always larger than or equal to /24. > > LACNIC can grant this type of allocation in case of projects and > infrastructure > for networks that are key or critical for the region, such as IXPs > (Internet > Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among > others. > > In the case of IXPs or NAPs, in order to be able to apply for this > type of > allocation, organizations shall meet the following requirements: > > 1. Duly document the following aspects: > 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The > organization shall have at least three members and an open policy in > relation to the association of new members. > 1. 2Submit a company structure organizational diagram. > 1. 3Document the numbering plan to be implemented. > 2. Provide a usage plan for the following three and six months. > > The rest of the applications shall be studied based on the analysis of > the > documentation justifying the critical and/or key aspects of the project. > Organizations receiving micro allocations are not authorized to > suballocate > these addresses. > > > From hpholen at tiscali.no Sat Apr 16 09:03:49 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sat, 16 Apr 2005 09:03:49 +0200 Subject: [address-policy-wg] Policy Proposal: #epsilon Policy text modifications to take account of,ICANN recognition of AfriNIC as a fully functioning RIR. Message-ID: <4260B8D5.4090308@tiscali.no> Dear All, With the formal recognition of AfriNIC as a fully functioning RIR there is no need to still have special policy provisions for the AfriNIC region in the RIPE NCC region. http://www.nro.net/archive/news/20050411-afrinic-final-recognition.html As I do not expect much discussion on this Item I propose to end the discussion period by May 1st. 1.Number (assigned by the RIPE NCC) #epsilon 2.Policy Proposal Name: Policy text modifications to take account of ICANN recognition of AfriNIC as a fully functioning RIR. 3.Author a.name: Adiel Akplogan b.e-mail: adiel at afrinic.net c.telephone:+230 259 2409 d.organisation: AfriNIC 4.Proposal Version: 1.0 5.Submission Date: 6.Suggested WG for discussion and publication Address Policy Working Group 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: renewable a.temporary, permanent, or renewable. 9.Summary of proposal To modify the policy document text to reflect full recognition of AfriNIC as a functioning RIR. 10. Policy text a.Current (if modify): "1.0 Introduction The RIPE NCC is an independent association and serves as one of four Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator." b.New: "1.0 Introduction The RIPE NCC is an independent association and serves as one of /five/ Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia." a.Current (if modify): "5.1 First Allocation The RIPE NCC's minimum allocation size is /21. The minimum allocation size for countries in Africa is /22." b.New: "5.1 First Allocation The RIPE NCC's minimum allocation size is /21." 11. Rationale: a.Arguments supporting the proposal With the recognition of AfriNIC as a fully functioning and independant RIR there is a need to modify this document reflecting this change. b.Arguments opposing the proposal None. From hpholen at tiscali.no Sat Apr 16 09:13:45 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sat, 16 Apr 2005 09:13:45 +0200 Subject: [address-policy-wg] Policy Proposal: #Zeta Adding Regional Boundaries to policy documents Message-ID: <4260BB29.1040606@tiscali.no> Dear Address Policy WG, This policy proposal is nothing more than an editorial change - but we still feel it is fair to run it trough the PDP. As I do not expect much discussion I propose the discussion phase to end by May 1st. While I am voicing this proposal the suggestion actualy comes from our excellent RIPE NCC staff. Thanks leo for pointing this out. Best Regards Hans Petter Holen Address Policy 1. Number Zeta 2. Policy Proposal Name: Adding Regional Boundaries to policy documents 3. Author a. name: Hans Petter Holen b. e-mail: hpholen at tiscali.no c. telephone: +47 45066054 d. organisation: Visma IT AS 4. Proposal Version: 5. Submission Date: 16/4-2005 6. Suggested WG for discussion and publication Address policy type 7. Proposal type: a. modify 8. Policy term: a. permanent 9. Summary of proposal Our AS assignment policy has the following statement in it: "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region" Neither the IPv4 nor the IPv6 policy documents have such a clear statement in them. It might be a good idea to add a similar statement to those documents when they are updated. 10. Policy text a. Current (if modify): b. New: 11. Rationale: a. Arguments supporting the proposal Clearification of the scope of the documents b. Arguments opposing the proposal n/a From kurtis at kurtis.pp.se Mon Apr 18 21:14:19 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 18 Apr 2005 21:14:19 +0200 Subject: [address-policy-wg] Policy proposal for changes in RIPE policy Documents. In-Reply-To: <16989.21788.11758.111536@roam.psg.com> References: <6.1.2.0.2.20050413191421.059c1a88@207.44.238.73> <16989.21788.11758.111536@roam.psg.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-04-13, at 19.21, Randy Bush wrote: > simple, to the point, correct, and seemingly useful. Agreed. And I support the porposal. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQmQHFKarNKXTPFCVEQI/gQCg5mBYxhAsass4imXNd/jki/3k4x0AoJEw 5xEuEAyfDNUwqAm79j5T/9eC =2aCb -----END PGP SIGNATURE----- From EricS at t-com.net Tue Apr 19 07:29:01 2005 From: EricS at t-com.net (Erics) Date: Tue, 19 Apr 2005 07:29:01 +0200 Subject: [address-policy-wg] Policy proposal for changes in RIPE policy Do cuments. Message-ID: ... that meets the point. I agree and support this proposal. - Eric From ncc at ripe.net Tue Apr 19 10:48:04 2005 From: ncc at ripe.net (Axel Pawlik) Date: Tue, 19 Apr 2005 10:48:04 +0200 Subject: [address-policy-wg] NRO Response to WGIG Paper on IP Numbers Message-ID: <5.2.1.1.2.20050419104019.01a82d48@mailhost.ripe.net> Dear Colleagues, The Number Resource Organization (NRO), on behalf of the Regional Internet Registries including the RIPE NCC, published a document consisting of comments to the Working Group on Internet Governance (WGIG) on the draft working paper on IP Numbers (April 2005). The NRO document submitted to the WGIG can be found on the NRO website at: http://www.nro.net/documents/nro23.html The original draft WGIG paper can be found at: http://wgig.org/docs/WGIGPaperCluster1IPnumbers-Final.pdf Regards, Axel Pawlik Managing Director RIPE NCC From ncc at ripe.net Tue Apr 19 10:48:04 2005 From: ncc at ripe.net (Axel Pawlik) Date: Tue, 19 Apr 2005 10:48:04 +0200 Subject: [address-policy-wg] [local-ir@ripe.net]NRO Response to WGIG Paper on IP Numbers Message-ID: <5.2.1.1.2.20050419104019.01a82d48@mailhost.ripe.net> Dear Colleagues, The Number Resource Organization (NRO), on behalf of the Regional Internet Registries including the RIPE NCC, published a document consisting of comments to the Working Group on Internet Governance (WGIG) on the draft working paper on IP Numbers (April 2005). The NRO document submitted to the WGIG can be found on the NRO website at: http://www.nro.net/documents/nro23.html The original draft WGIG paper can be found at: http://wgig.org/docs/WGIGPaperCluster1IPnumbers-Final.pdf Regards, Axel Pawlik Managing Director RIPE NCC From webmaster at ripe.net Tue Apr 19 11:38:19 2005 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Tue, 19 Apr 2005 11:38:19 +0200 Subject: [address-policy-wg] New Document available: RIPE-344 Message-ID: <200504190938.j3J9cJet014237@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-344 Title: Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries Author: APNIC, ARIN, LACNIC, RIPE NCC Date: 19 April 2005 Format: PDF=74310 TXT=4719 Short content description ------------------------- On 8 April 2005, during the ICANN Board meeting in Mar del Plata, Argentina, the ICANN Board formally approved the adoption of a global policy on IANA Allocation of IPv4 address space to the Regional Internet Registries developed by the Address Supporting Organisation (ASO) and the Number Resource Organisation (NRO). The ICANN Board resolution is available from the ICANN website at: http://www.icann.org/minutes/resolutions-08apr05.htm The document "Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries" describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). Accessing the RIPE document store --------------------------------- You can access this new RIPE document in HTML format via our website at the following URL: http://www.ripe.net/ripe/docs/iana-rir-allocation-policies.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-344.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-344.txt plain text version From hpholen at tiscali.no Wed Apr 20 12:06:51 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 20 Apr 2005 12:06:51 +0200 Subject: [address-policy-wg] Policy Proposal: #Zeta Adding Regional Boundaries to policy documents In-Reply-To: <4260BB29.1040606@tiscali.no> References: <4260BB29.1040606@tiscali.no> Message-ID: <426629BB.9040505@tiscali.no> I got an interesting question for clearification, which I had not thought about. My intention when posting this proposal is that you cannot use RIPE policies to get internet resouces from other RIRs. It should however not change the current policy that a global provider can use thesse resources globally. Ie - I can announce a RIPE AS number all over the world - and use IP addresses in all of my network - and for all of my customers. I may still choose to have a relationship with multiple RIRs - but that is not mandtory. maybe the wordning needs clearification. -hph Hans Petter Holen wrote: > Dear Address Policy WG, > This policy proposal is nothing more than an editorial change - but we > still feel it is fair to run it trough the PDP. > As I do not expect much discussion I propose the discussion phase to > end by May 1st. > > While I am voicing this proposal the suggestion actualy comes from our > excellent RIPE NCC staff. Thanks leo for pointing this out. > > Best Regards > Hans Petter Holen > Address Policy > > 1. Number Zeta > > 2. Policy Proposal Name: Adding Regional Boundaries to policy > documents > > 3. Author > > a. name: Hans Petter Holen > > b. e-mail: hpholen at tiscali.no > > c. telephone: +47 45066054 > > d. organisation: Visma IT AS > > 4. Proposal Version: > > > > 5. Submission Date: 16/4-2005 > > > > 6. Suggested WG for discussion and publication > > Address policy type > > > > 7. Proposal type: > > a. modify > > > > 8. Policy term: > > a. permanent > > > > 9. Summary of proposal > > > > Our AS assignment policy has the following statement in it: > > > > "The RIPE NCC assigns AS Numbers for Autonomous Systems > located in the RIPE NCC service region" > > > > Neither the IPv4 nor the IPv6 policy documents have such a > clear statement in them. It might be a good idea to add a > similar statement to those documents when they are updated. > > > > 10. Policy text > > a. Current (if modify): > > b. New: > > > > 11. Rationale: > > a. Arguments supporting the proposal > > Clearification of the scope of the documents > > > b. Arguments opposing the proposal > > n/a > From filiz at ripe.net Wed Apr 20 14:46:01 2005 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 20 Apr 2005 14:46:01 +0200 Subject: [address-policy-wg] New IPv6 Address Block Allocated to the RIPE NCC Message-ID: <20050420124601.GJ32080@x13.ripe.net> Dear Colleagues, The RIPE NCC received the IPv6 address range 2A00::/21 from the IANA in April 2005. 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, -- Filiz Yilmaz RIPE NCC From addpolicywg-cgray at netegral.co.uk Wed Apr 20 18:05:04 2005 From: addpolicywg-cgray at netegral.co.uk (Cameron Gray (RIPE Address Policy WG)) Date: Wed, 20 Apr 2005 17:05:04 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria Message-ID: <42667DB0.8010308@netegral.co.uk> Collective, This originated from a thread I started on ipv6-ops... As the archives seem to bear out shim6/mhap/multi6 or whatever the new *thing* will be is not ready. We (uk.netegral) have a /32 already (2001:4bf0::) however many of the recipients of sub-allocations will be using the resources in conjunction with their other providers. My, now somewhat aging, e-mail to lir-help asked what happens to LIRs that cannot get/justify/plan for 200 /48s their reply was simple: get it off another LIR. This now leads into a problem with routing policies: if /32s are only to be allowed in the backbone, how doe these sub-lir allocations get announced. My idea is to simply allow internetwork /48 to be announced to the backbone, or aggregates thereof (i.e. to adjacent /48s for the same ASN as a /47 and so on...). I know the first response will be that this will grow the routing table infinitely and I agree, however with 629-ish from my view there isn't much of a table to speak of. Are there any considerations I'm missing, why can't IPv6 prefixes be treated in the same way as IPv4? I'm not advocating announcing every /64 from here to timbuktu but otherwise I can't see anything to allow the "little guys" from actually benefitting therefore deploying IPv6. One of our customers has a /48 allocation and is now refusing to issue to customers as he can't announce this to the second upstream (they refuse to pass it on as it isn't a /32), they have also hit peers that refused the prefix as it hit their "this route is internal" prefix filter. I assume the end goal here is to encourage the uptake of v6 not hinder it... Can this disparity in policies not be addressed using current protocols and technologies simply by increasing the allowable boundary for the backbone? This has a neat side effect of not having to alter the issuing policy for /32s :) . From Michael.Dillon at radianz.com Thu Apr 21 12:22:17 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 21 Apr 2005 11:22:17 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <42667DB0.8010308@netegral.co.uk> Message-ID: > Can this disparity in policies not be addressed using current protocols > and technologies simply by increasing the allowable boundary for the > backbone? This has a neat side effect of not having to alter the > issuing policy for /32s :) . If there is going to be a route in the global routing table then it is better for that route to be a /32 rather than to ambiguously allow for longer prefixes. Therefore, RIPE, and all other RIRs, should give organizations a /32 if they intend to announce routes in the global IPv6 routing table. This does not waste IPv6 space since a /32 is a very small fraction of the IPv6 address space. In fact, it is the same as an IPv4 /32 when measured as a percentage of the total IPv4 address space. --Michael Dillon From addpolicywg-cgray at netegral.co.uk Thu Apr 21 12:27:32 2005 From: addpolicywg-cgray at netegral.co.uk (Cameron Gray (RIPE Address Policy WG)) Date: Thu, 21 Apr 2005 11:27:32 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: References: Message-ID: <42678014.1060209@netegral.co.uk> Michael.Dillon at radianz.com wrote: > If there is going to be a route in the global routing table > then it is better for that route to be a /32 rather than > to ambiguously allow for longer prefixes. Therefore, RIPE, and > all other RIRs, should give organizations a /32 if they intend > to announce routes in the global IPv6 routing table. > > This does not waste IPv6 space since a /32 is a very small fraction > of the IPv6 address space. In fact, it is the same as an IPv4 > /32 when measured as a percentage of the total IPv4 address space. I appreciate that, but how then does an organisation that can only qualify for a /48 from x upstream participate? Many Hosting providers (rather than connectivity providers) are going to end up shafted by that ideal. Or are we simply moving everybody up a subnet, i.e. LIRs now get /24...? Either way we end up with the same argument, just with longer or shorter prefixes. Or are we lobbying for the criteria as a LIR to be relaxed...? Hosting suppliers are seemingly getting the raw end of this deal and seen as IPv6 will be de fact one day and they need redundancy and multi-path, etc. I would think now would be the time to accomodate them. -- Best regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | cgray at netegral.co.uk 0871 277 NTGL (6845) From Michael.Dillon at radianz.com Thu Apr 21 12:58:11 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 21 Apr 2005 11:58:11 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <42678014.1060209@netegral.co.uk> Message-ID: > Or are we lobbying for the criteria as a LIR to be relaxed...? YES! > Hosting suppliers are seemingly getting the raw end of this deal and > seen as IPv6 will be de fact one day and they need redundancy and > multi-path, etc. I would think now would be the time to accomodate them. Then they should come to Stockholm in May and state their case at the meeting. If they want to take RIPE to court or make a complaint to the European Competition Commission, they first have to attempt to solve the problem using the channels that exist for changing RIPE policies. It's that simple. --Michael Dillon From gert at space.net Thu Apr 21 14:41:06 2005 From: gert at space.net (Gert Doering) Date: Thu, 21 Apr 2005 14:41:06 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <42678014.1060209@netegral.co.uk> References: <42678014.1060209@netegral.co.uk> Message-ID: <20050421124106.GP84850@Space.Net> Hi, On Thu, Apr 21, 2005 at 11:27:32AM +0100, Cameron Gray (RIPE Address Policy WG) wrote: > Or are we lobbying for the criteria as a LIR to be relaxed...? Actually there are no big hurdles for becoming a LIR. Prove your existance, fill in paperwork, pay startup fee, done. This alone doesn't give you an IPv6 allocation yet, though - the biggest hurdle there is that you have to claim a plan to supply 200 customers with IPv6. As it is only a *plan*, it's possible to achieve for most LIRs that actually provide addresses to customers. OTOH, there's an ongoing policy change proposal to drop the 200-customer rule. Please read up the specifics of the proposal in the archive, and voice your opinion... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From addpolicywg-cgray at netegral.co.uk Fri Apr 22 00:41:20 2005 From: addpolicywg-cgray at netegral.co.uk (Cameron Gray (RIPE Address Policy WG)) Date: Thu, 21 Apr 2005 23:41:20 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria Message-ID: <42682C10.9000205@netegral.co.uk> Gert Doering wrote: > Hi, > > On Thu, Apr 21, 2005 at 11:27:32AM +0100, Cameron Gray (RIPE Address Policy WG) wrote: > >>Or are we lobbying for the criteria as a LIR to be relaxed...? > > > Actually there are no big hurdles for becoming a LIR. Prove your existance, > fill in paperwork, pay startup fee, done. I think my phrasing was misunderstood. What I meant was the 200 rule, not to become a de facto LIR. > This alone doesn't give you an IPv6 allocation yet, though - the biggest > hurdle there is that you have to claim a plan to supply 200 customers with > IPv6. As it is only a *plan*, it's possible to achieve for most LIRs > that actually provide addresses to customers. Well not if we're sticking to the letter of the policy, and especially as in perticular *our* customers will require multi-homing, therefore a /32 to themselves... (this is a YMMV comment, but asbestos underwear donned anyway). > OTOH, there's an ongoing policy change proposal to drop the 200-customer > rule. Please read up the specifics of the proposal in the archive, and > voice your opinion... I disagree with the policy change, I think that the policy change should be on allowed prefixed into the backbone. First a little background, recently in the London Webhosting world, a big drive has occured to become multi-homed and isolated from any one providers screwups, downtime, incompetence, etc. The problem with this is that very few of them have any of the necessary skills to liase with the NCC to do requests or even understand why its necessary [tangent: the number of times I see "because ARIN gave us a /24 per box" as a justification from the same group is silly]. I firmly believe in leaving the important things to those who know what they are doing, present company (I hope ;)). The small providers can have either IPv6 PI (currently disallowed and frowned upon) or become a LIR and wreak havoc on the hostmasters. I'm against dishing out /32s to Joe Blogs because I believe the subnet recommendation/guidelines as published are a good balance. In theory a /48 for any customer site should be several orders of magnitude to many for most customers in two years. But the ongoing problem is that of what should be allowed into the public v6 Internet. As much as I would like to attend RIPE 50 I have other commitments as well as government to select half-way through so I am unable to. Could we continue the discussion here or is this very much an in person topic? -- Best regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | cgray at netegral.co.uk 0871 277 NTGL (6845) From david.kessens at nokia.com Fri Apr 22 03:16:14 2005 From: david.kessens at nokia.com (David Kessens) Date: Thu, 21 Apr 2005 18:16:14 -0700 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050421124106.GP84850@Space.Net> References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> Message-ID: <20050422011614.GE3521@nokia.com> Gert, On Thu, Apr 21, 2005 at 02:41:06PM +0200, Gert Doering wrote: > > OTOH, there's an ongoing policy change proposal to drop the 200-customer > rule. Please read up the specifics of the proposal in the archive, and > voice your opinion... We have been discussing this proposal now for years. What is it that is needed to get a decision made regarding rejection or approval of this proposal? David Kessens --- From gert at space.net Fri Apr 22 09:39:26 2005 From: gert at space.net (Gert Doering) Date: Fri, 22 Apr 2005 09:39:26 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050422011614.GE3521@nokia.com> References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> <20050422011614.GE3521@nokia.com> Message-ID: <20050422073926.GK84850@Space.Net> Hi, On Thu, Apr 21, 2005 at 06:16:14PM -0700, David Kessens wrote: > On Thu, Apr 21, 2005 at 02:41:06PM +0200, Gert Doering wrote: > > OTOH, there's an ongoing policy change proposal to drop the 200-customer > > rule. Please read up the specifics of the proposal in the archive, and > > voice your opinion... > > We have been discussing this proposal now for years. Indeed, but the discussion always died down after a while, and nobody did everything necessary to make it an actual policy change. I think one of the reasons for that was that the RIPE policy process just wasn't formal enough, to say "*this* is the timeline, we make a decision *now*" - which should be easier now, with the new formalized policy process. OTOH... > What is it that is needed to get a decision made regarding rejection or > approval of this proposal? ... I am not sure whether I can see any sort of consensus yet. We have very loud voices that oppose the change, other voices want much more than that, and a number of people agree with it. If I do some sort of "averaging", the "average opionion" from this could be "yes, go for it", but basically it comes down to "what's our definition of consensus" now. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Fri Apr 22 09:43:39 2005 From: gert at space.net (Gert Doering) Date: Fri, 22 Apr 2005 09:43:39 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <42682A4A.4040109@netegral.co.uk> References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> <42682A4A.4040109@netegral.co.uk> Message-ID: <20050422074339.GL84850@Space.Net> Hi, On Thu, Apr 21, 2005 at 11:33:46PM +0100, Cameron Gray wrote: > First a little background, recently in the London Webhosting world, a > big drive has occured to become multi-homed and isolated from any one > providers screwups, downtime, incompetence, etc. The problem with this > is that very few of them have any of the necessary skills to liase with > the NCC to do requests or even understand why its necessary [tangent: > the number of times I see "because ARIN gave us a /24 per box" as a > justification from the same group is silly]. I firmly believe in > leaving the important things to those who know what they are doing, > present company (I hope ;)). > > The small providers can have either IPv6 PI (currently disallowed and > frowned upon) or become a LIR and wreak havoc on the hostmasters. This is something that I really don't understand. The hostmasters are here to help educate LIRs that don't know what they are doing - and it will be for the better of everyone. If they are so clueless, then they shouldn't be allowed to do BGP, and possible "wreak havoc" on everybody else's routing tables. > I'm against dishing out /32s to Joe Blogs because I believe the subnet > recommendation/guidelines as published are a good balance. In theory a > /48 for any customer site should be several orders of magnitude to many > for most customers in two years. > > But the ongoing problem is that of what should be allowed into the > public v6 Internet. Indeed. The idea behind the proposed change is (sort of) "those who can be bothered to understand the system and become a LIR are allowed". What you are asking for ("those people are clueless but so important that they need to be visible in everyones routing table") is a different proposal. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From addpolicywg-cgray at netegral.co.uk Fri Apr 22 09:53:14 2005 From: addpolicywg-cgray at netegral.co.uk (Cameron Gray (RIPE Address Policy WG)) Date: Fri, 22 Apr 2005 08:53:14 +0100 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050422074339.GL84850@Space.Net> References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> <42682A4A.4040109@netegral.co.uk> <20050422074339.GL84850@Space.Net> Message-ID: <4268AD6A.2070000@netegral.co.uk> Gert Doering wrote: > Hi, > This is something that I really don't understand. The hostmasters are > here to help educate LIRs that don't know what they are doing - and it > will be for the better of everyone. I whole heartedly agree. > If they are so clueless, then they shouldn't be allowed to do BGP, and > possible "wreak havoc" on everybody else's routing tables. Exactly (and DO), part of what Netegral does is clear up after this sort of stupidity. I'm in favour of IQ tests with a rising scale at every level of IT. Maybe that'll kill off the spammers. > Indeed. The idea behind the proposed change is (sort of) "those who can be > bothered to understand the system and become a LIR are allowed". A perfectly good philosophy. > What you are asking for ("those people are clueless but so important that > they need to be visible in everyones routing table") is a different > proposal. Well not quite, personally if the /32 rule goes ahead (pretty much as good as any other suggestion to date) there is no problem. However, I also have to battle their mindset on a daily basis and that will hamper the uptake of IPv6. Remember in the web hosting world, the attitude of "I can get it for free so screw the rules" is extremely prevalent. It's very much they want the cake and to eat it too. We have to remember that most of these individuals and companies have no clue of the impact that they can cause (and frequently do). I wondered if we could pre-empt this in policy instead of having them again flaunting the rules and doing it anyway. -- Best regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | cgray at netegral.co.uk 0871 277 NTGL (6845) From dr at cluenet.de Fri Apr 22 10:45:43 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 22 Apr 2005 10:45:43 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050422074339.GL84850@Space.Net> References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> <42682A4A.4040109@netegral.co.uk> <20050422074339.GL84850@Space.Net> Message-ID: <20050422084543.GA5431@srv01.cluenet.de> On Fri, Apr 22, 2005 at 09:43:39AM +0200, Gert Doering wrote: > Indeed. The idea behind the proposed change is (sort of) "those who can be > bothered to understand the system and become a LIR are allowed". I cannot see any requirement of "understanding the system", just "become a LIR", which boils down to "shell out enough money to RIPE NCC". Do you follow the illusion that LIRs are more clued on average than non-LIRs? Basically the proposal wants to change: "People who pay enough money to RIPE NCC and are ISPs (or lie convincingly enough) and claim a certain customer count projection" to "People who pay enough money to RIPE NCC and are ISPs (or lie convincingly enough)" Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jwkckid1 at ix.netcom.com Sat Apr 23 05:41:06 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Fri, 22 Apr 2005 20:41:06 -0700 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> <42682A4A.4040109@netegral.co.uk> <20050422074339.GL84850@Space.Net> <20050422084543.GA5431@srv01.cluenet.de> Message-ID: <4269C3D1.2A1492C5@ix.netcom.com> Daniel and all, I have to agree with Daniel's assesment here, unfortunately... Daniel Roesen wrote: > On Fri, Apr 22, 2005 at 09:43:39AM +0200, Gert Doering wrote: > > Indeed. The idea behind the proposed change is (sort of) "those who can be > > bothered to understand the system and become a LIR are allowed". > > I cannot see any requirement of "understanding the system", just > "become a LIR", which boils down to "shell out enough money to RIPE > NCC". Do you follow the illusion that LIRs are more clued on average > than non-LIRs? > > Basically the proposal wants to change: > > "People who pay enough money to RIPE NCC and are ISPs (or lie > convincingly enough) and claim a certain customer count projection" > > to > > "People who pay enough money to RIPE NCC and are ISPs (or lie > convincingly enough)" > > Regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From iljitsch at muada.com Sun Apr 24 11:12:08 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Apr 2005 11:12:08 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050422073926.GK84850@Space.Net> References: <42678014.1060209@netegral.co.uk> <20050421124106.GP84850@Space.Net> <20050422011614.GE3521@nokia.com> <20050422073926.GK84850@Space.Net> Message-ID: <21E599E0-B54D-4CAF-9BBE-F713DF2FD7A2@muada.com> On 22-apr-2005, at 9:39, Gert Doering wrote: >> What is it that is needed to get a decision made regarding >> rejection or >> approval of this proposal? > ... I am not sure whether I can see any sort of consensus yet. I am sure: there isn't any. > We have very loud voices that oppose the change, other voices want > much more > than that, and a number of people agree with it. If I do some sort of > "averaging", the "average opionion" from this could be "yes, go for > it", > but basically it comes down to "what's our definition of consensus" > now. Well, my definition of "consensus" doesn't include any averaging... I'm thinking: why don't we get a group of people representing the different viewpoints together in Stockholm and try to hash out a compromise? However, this means the "free for all" proponents need to be willing to do some compromising. Dropping the 200 limit and giving everyone who pays the LIR fee a /32 isn't my idea of a compromise. Iljitsch From iljitsch at muada.com Sun Apr 24 11:26:12 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Apr 2005 11:26:12 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <42667DB0.8010308@netegral.co.uk> References: <42667DB0.8010308@netegral.co.uk> Message-ID: On 20-apr-2005, at 18:05, Cameron Gray (RIPE Address Policy WG) wrote: > My, now somewhat aging, e-mail to lir-help asked what happens to > LIRs that cannot get/justify/plan for 200 /48s their reply was > simple: get it off another LIR. This now leads into a problem with > routing policies: if /32s are only to be allowed in the backbone, > how doe these sub-lir allocations get announced. Well, there are no rules as to what is and isn't "allowed in the backbone". There is RFC 2772, which provides "6bone backbone routing GUIDELINES" and there are is a remark in the RIR/IANA IPv6 policies that the RIRs will only allocate blocks of /32 and bigger for the benefit of prefix length filtering. (But some root DNS servers have / 48 blocks...) At the end of the day, it's individual ISPs who decide what they allow and don't allow in their routing tables. It's true that if you announce a smaller block than a /32 you'll be filtered in many places. However, this isn't necessarily a problem. For instance, if someone in Asia sends your customer who has a /48 from you and also announces this /48 to another ISP, and the Asian network filters the / 48, the packet will flow towards Europe as per your /32. Then when it gets to Europe, it's pretty likely that the packet will hit an ISP who actually has the /48 in their routing table. After all, what's allowing a few /48s from the people you get drunk with at all those RIPE meetings? If then the link between you and your customer is down the packets still get to the customer. (Obviously if you drop the /32 announcement for whatever reason this is no longer true.) So I would encourage you, your customers and your customer's other ISPs to announce these smaller blocks over regional exchange points. This will give your customers 80% of the advantages of having PI space with only 20% of the downsides. (Note that it would be good if those customers had a bigger block than a /48. Even a /47 would be better, as it's likely that ISPs will leak /48s that shouldn't be announced at some point, which will make others want to filter /48s. But since customers generally don't have bigger blocks than a /48 there is no reason to disallow /47s in anti- leak filters.) From iljitsch at muada.com Sun Apr 24 11:43:44 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Apr 2005 11:43:44 +0200 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio In-Reply-To: <425A3839.6050104@bluewin.ch> References: <425A3839.6050104@bluewin.ch> Message-ID: On 11-apr-2005, at 10:41, Guido Roeskens wrote: > we from Bluewin fully support the proposal > Policy proposal: #beta: IPv4-HD-Ratio > LIR: ch.bluewindow > Vote: YES > Comment: > ISP's providing access services to many customers face several > problems > - Usage in different PoP's changes; > at one time you have many customers in one PoP, at another > time in others. You need to supply enough adresses to all PoPs even > though they aren't needed all the time. > - Assymetric usage of pools and redundancy > To provide redundancy you overallocate some IP addresses to > be able to handle the failure of single devices > The pool usage on the devices and device groups are not balanced > - RFC 3194 is as true for IPv4 as for IPv6 > - consistency between IPv4 and IPv6 policies What are you proposing? RFC 3194 is a descriptive RFC, it doesn't proscribe anything. What kind of HD ratio would you want to apply to IPv4 allocations? Note that the current HD ratio for all IPv4 address space that isn't reserved by IANA is 90.45%. From iljitsch at muada.com Sun Apr 24 12:26:58 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Apr 2005 12:26:58 +0200 Subject: [address-policy-wg] Mega-allocations Message-ID: <7F38B76C-F625-4ABC-9147-13F12AB10AE2@muada.com> Hi, It seems there is a new trend in RIR-land: mega-allocations. This year APNIC, ARIN and the RIPE NCC have made the following allocations: # whois -h whois 126.0.0.0 whois.apnic.net inetnum: 126.0.0.0 - 126.255.255.255 netname: BBTEC descr: Japan Nation-wide Network of Softbank BB Corp. country: JP status: ALLOCATED PORTABLE # whois -h whois.arin.net 73.0.0.0 NetRange: 73.0.0.0 - 73.191.255.255 CIDR: 73.0.0.0/9, 73.128.0.0/10 NetName: CABLE-1 NetType: Direct Allocation # whois -h whois.ripe.net 86.192.0.0 inetnum: 86.192.0.0 - 86.255.255.255 netname: FR-TELECOM-20050302 descr: France Telecom status: ALLOCATED PA That's a total of 33 million IP addresses in 3 allocations (and as many months). The total population for these three countries is 127 + 293 + 60 = 480 million, so that's an IP address for nearly 7% of those country's inhabitants. If I were a conspiracy theorist I would think that IPv6 proponents are trying to burn up the remaining IPv4 space as fast as they can so we'll all be running IPv6 at the end of the decade. If that's the case: good job! :-) Seriously: what's going on here? From dr at cluenet.de Sun Apr 24 13:34:57 2005 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 24 Apr 2005 13:34:57 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: References: <42667DB0.8010308@netegral.co.uk> Message-ID: <20050424113457.GA6329@srv01.cluenet.de> On Sun, Apr 24, 2005 at 11:26:12AM +0200, Iljitsch van Beijnum wrote: > At the end of the day, it's individual ISPs who decide what they > allow and don't allow in their routing tables. It's true that if you > announce a smaller block than a /32 you'll be filtered in many > places. However, this isn't necessarily a problem. For instance, if > someone in Asia sends your customer who has a /48 from you and also > announces this /48 to another ISP, and the Asian network filters the / > 48, the packet will flow towards Europe as per your /32. Then when it > gets to Europe, it's pretty likely that the packet will hit an ISP > who actually has the /48 in their routing table. After all, what's > allowing a few /48s from the people you get drunk with at all those > RIPE meetings? The filtering out there IS a problem. For an example what happens when you try multihoming with /32" and /40s do pass, but in general your AS_PATHs for the more-specifics can get VERY long. So borderline is that you have worse to MUCH worse connectivity by announcing the more-specific than via the aggregate, thanks to the filtering done out there. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Sun Apr 24 14:27:58 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Apr 2005 14:27:58 +0200 Subject: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria In-Reply-To: <20050424113457.GA6329@srv01.cluenet.de> References: <42667DB0.8010308@netegral.co.uk> <20050424113457.GA6329@srv01.cluenet.de> Message-ID: <1FEA0223-75AB-4C20-9987-A75F2F43A69F@muada.com> On 24-apr-2005, at 13:34, Daniel Roesen wrote: > The filtering out there IS a problem. Yes, but it's getting better. > in general your AS_PATHs > for the more-specifics can get VERY long. So borderline is that you > have > worse to MUCH worse connectivity by announcing the more-specific than > via the aggregate, thanks to the filtering done out there. There are still people out there who announce everything to everyone over tunnels. It was much worse in the past but it's important that not only the people who do this are encouraged to stop, but also that the people who are feeding them cut their BGP feeds off if they don't. This is all BGP 101 so there is absolutely no reason for this to persist, people just have to flip the "test/production" switch on their IPv6 stuff in the "production" direction and take away peering privileges from well-meaning but clue-challenged amateurs. From gert at space.net Sun Apr 24 21:10:43 2005 From: gert at space.net (Gert Doering) Date: Sun, 24 Apr 2005 21:10:43 +0200 Subject: [address-policy-wg] Mega-allocations In-Reply-To: <7F38B76C-F625-4ABC-9147-13F12AB10AE2@muada.com> References: <7F38B76C-F625-4ABC-9147-13F12AB10AE2@muada.com> Message-ID: <20050424191043.GW84850@Space.Net> Hi, On Sun, Apr 24, 2005 at 12:26:58PM +0200, Iljitsch van Beijnum wrote: > Seriously: what's going on here? Looks like "serious large-scale broad-band roll out", and unfortunately they are doing it IPv4-only... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From internetplumber at gmail.com Mon Apr 25 17:54:23 2005 From: internetplumber at gmail.com (Rob Evans) Date: Mon, 25 Apr 2005 16:54:23 +0100 Subject: [address-policy-wg] Mega-allocations In-Reply-To: <7F38B76C-F625-4ABC-9147-13F12AB10AE2@muada.com> References: <7F38B76C-F625-4ABC-9147-13F12AB10AE2@muada.com> Message-ID: <426D12AF.8070107@gmail.com> > Seriously: what's going on here? They filled in the forms and justified the address usage? Would you prefer they were using NATs? I'm thinking large allocations of real address space is a good thing. :-) Cheers, Rob From iljitsch at muada.com Mon Apr 25 18:22:32 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 25 Apr 2005 18:22:32 +0200 Subject: [address-policy-wg] Mega-allocations In-Reply-To: <426D12AF.8070107@gmail.com> References: <7F38B76C-F625-4ABC-9147-13F12AB10AE2@muada.com> <426D12AF.8070107@gmail.com> Message-ID: <79FD2418-7DF2-4F51-B279-9EA727201FB3@muada.com> On 25-apr-2005, at 17:54, Rob Evans wrote: >> Seriously: what's going on here? > They filled in the forms and justified the address usage? > Would you prefer they were using NATs? I'm thinking large > allocations of real address space is a good thing. :-) I'm sure there are projections that indicate this level of address use in the future for the allocatees in question. But does that necessitate giving out /10 or even larger blocks? At some point, the growth will end. When that happens, it's better that half a /12 remains unused than half a /10. It's not like having /12s in the routing table rather than /10s is going to lead to undue growth in the routing tables... Another look at the data shows that 1M and bigger allocations aren't entirely new: there are currently 80 allocations/assignments of a million or more addresses for a total of 172 million addresses. However, there is a significant upward trend. The number of addresses allocated/assigned in these blocks is: Year APNIC ARIN LACNIC RIPENCC Total 2000 1.05 9.44 0.00 2.10 12.58 2001 8.39 10.49 0.00 4.19 23.07 2002 11.53 4.78 0.00 6.29 22.61 2003 12.58 4.19 1.05 10.49 28.31 2004 15.73 9.76 1.05 11.93 38.47 2005 16.78 14.02 0.00 16.19 46.99 (That's right: we're already well past last year before the end of april.) From groeskens at bluewin.ch Mon Apr 25 08:55:48 2005 From: groeskens at bluewin.ch (Guido Roeskens) Date: Mon, 25 Apr 2005 08:55:48 +0200 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio In-Reply-To: References: <425A3839.6050104@bluewin.ch> Message-ID: <426C9474.2020701@bluewin.ch> Iljitsch van Beijnum wrote: > On 11-apr-2005, at 10:41, Guido Roeskens wrote: > >> we from Bluewin fully support the proposal > > >> Policy proposal: #beta: IPv4-HD-Ratio >> LIR: ch.bluewindow >> Vote: YES > > >> Comment: >> ISP's providing access services to many customers face several problems >> - Usage in different PoP's changes; >> at one time you have many customers in one PoP, at another >> time in others. You need to supply enough adresses to all PoPs even >> though they aren't needed all the time. >> - Assymetric usage of pools and redundancy >> To provide redundancy you overallocate some IP addresses to >> be able to handle the failure of single devices >> The pool usage on the devices and device groups are not balanced >> - RFC 3194 is as true for IPv4 as for IPv6 >> - consistency between IPv4 and IPv6 policies > > > What are you proposing? RFC 3194 is a descriptive RFC, it doesn't > proscribe anything. What kind of HD ratio would you want to apply to > IPv4 allocations? > Look for the mail by alain.bidron at francetelecom.com with the subject "HD ratio policy proposal" In the mail is a formal proposal entitled "IPv4-HD-Ratio" which has the key sentence "The proposed value of the HD ratio for IPv4 is 0.96" > Note that the current HD ratio for all IPv4 address space that isn't > reserved by IANA is 90.45%. > As you see the HD Ratio propsed is much higher but would help LIR's with bigger allocations to justify their IP usage. Guido Roeskens Swisscom Fixnet AG Bluewin From Michael.Dillon at radianz.com Tue Apr 26 15:22:10 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 26 Apr 2005 14:22:10 +0100 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio In-Reply-To: <426C9474.2020701@bluewin.ch> Message-ID: > which has the key sentence > "The proposed value of the HD ratio for IPv4 is 0.96" > > > Note that the current HD ratio for all IPv4 address space that isn't > > reserved by IANA is 90.45%. > > As you see the HD Ratio propsed is much higher but > would help LIR's with bigger allocations to justify > their IP usage. You are comparing apples and oranges. Or maybe you have painted all your apples with orange paint. The proposal suggests that the HD ratio should be 0.96 It does not mention a percentage. In fact, a percentage is a kind of ratio but it is not the same kind of ratio as the HD ratio. The comment regarding all IP address space that is not reserved by IANA is not clear whether it is talking about an HD ratio or an allocation percentage. And the most important thing is that it does not say what is the source of the numbers that lead to the 90.45 result. HD ratio for IPv4 is intended to count the number of addresses assigned by an LIR and compare that to the number of addresses that RIPE (or another RIR) has allocated to the LIR. When discussing "all IPv4 address space" or "IANA reserved address space" we are talking about address attributes that are not covered by the HD ratio as we know it. --Michael Dillon From iljitsch at muada.com Tue Apr 26 19:53:53 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 26 Apr 2005 19:53:53 +0200 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio In-Reply-To: References: Message-ID: On 26-apr-2005, at 15:22, Michael.Dillon at radianz.com wrote: >>> Note that the current HD ratio for all IPv4 address space that isn't >>> reserved by IANA is 90.45%. >> As you see the HD Ratio propsed is much higher but >> would help LIR's with bigger allocations to justify >> their IP usage. > You are comparing apples and oranges. Or maybe you have painted > all your apples with orange paint. > > The proposal suggests that the HD ratio should be 0.96 > It does not mention a percentage. In fact, a percentage > is a kind of ratio but it is not the same kind of ratio > as the HD ratio. From RFC 3194: log(number of allocated objects) HD = ------------------------------------------ log(maximum number of allocatable objects) This ratio is defined for any number of allocatable objects greater than 1 and any number of allocated objects greater or equal than 1 and less than or equal the maximum number of allocatable objects. The ratio is usually presented as a percentage, e.g. 70%. It varies between 0 (0%), when there is just one allocation, and 1 (100%), when there is one object allocated to each available address. > The comment regarding all IP address space that is not > reserved by IANA is not clear whether it is talking about > an HD ratio or an allocation percentage. And the most important > thing is that it does not say what is the source of the > numbers that lead to the 90.45 result. Out of the 256 /8 blocks 32 are class D (224 - 239, multicast) and E (240 - 255, reserved) and three others are also unusable: 0, 10 and 127. Of the 221 usable /8s 72 were unused as of March 2005. See http://www.iana.org/assignments/ipv4-address-space . According to the ISC Domain Survey at http://www.isc.org/ds/ 317 million IPv4 hosts had a domain name in January 2005. So that's 149 * 2^24 = 2.5 billion allocatable objects with 317 million objects allocated, or: 8.501 / 9.397 = 0.9047. (log base 10.) > HD ratio for IPv4 is intended to count the number of addresses > assigned by an LIR and compare that to the number of addresses > that RIPE (or another RIR) has allocated to the LIR. No, the intent of the HD ratio is to show that we need IPv6 even though only some 9% of all usable IPv6 addresses are in use. (Throw in standard disclaimer about the host count.) > When discussing > "all IPv4 address space" or "IANA reserved address space" we are > talking about address attributes that are not covered by the > HD ratio as we know it. The HD ratio is just a rule of thumb that says on everage, we waste one fifth to an eighth of the address length. The fact that we're now apparently using more than 90% oof the address length while including sparsely populated pre-1993 address space shows that the HD ratio isn't all that useful, although it's main point, that there are losses at allocation boundaries, is of course very true. From iljitsch at muada.com Tue Apr 26 20:04:45 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 26 Apr 2005 20:04:45 +0200 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio In-Reply-To: <426C9474.2020701@bluewin.ch> References: <425A3839.6050104@bluewin.ch> <426C9474.2020701@bluewin.ch> Message-ID: On 25-apr-2005, at 8:55, Guido Roeskens wrote: >> What are you proposing? RFC 3194 is a descriptive RFC, it doesn't >> proscribe anything. What kind of HD ratio would you want to apply >> to IPv4 allocations? > The proposed value of the HD ratio for IPv4 is 0.96" >> Note that the current HD ratio for all IPv4 address space that >> isn't reserved by IANA is 90.45%. > As you see the HD Ratio propsed is much higher but > would help LIR's with bigger allocations to justify > their IP usage. Ah, but the crucial question then becomes: what size allocation are these LIRs going to receive? For a /16 a HD ratio of 96% means 42k out of 66k addresses must be used = 64% (where k = 1000), but for a / 12 it means 602k out of 1049k = 57% and for a /8 8.6M out of 16.8M = 51%. So this means that if this proposal is accepted, it's important for the NCC to allocate the smallest possible blocks, and certainly not blocks of a million addresses or more, which seems to be the latest trend that nobody in the know seems to want to comment on. Also, it seems counter-intuitive that the more addreses you have, the more you're going to waste. Sure, a big ISP may have one or even two more aggregation levels than a small one, but it's easier to reroute part of 8.2M unused addresses to somewhere else in your network than some of 20 unused addresses as would happen in a very small network. From randy at psg.com Tue Apr 26 21:40:01 2005 From: randy at psg.com (Randy Bush) Date: Tue, 26 Apr 2005 09:40:01 -1000 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio References: <425A3839.6050104@bluewin.ch> <426C9474.2020701@bluewin.ch> Message-ID: <17006.39185.775519.528906@roam.psg.com> look, the hd ratio is simple. because it is log, rather than linear, it gives bigger allocations to those with bigger allocations, the rich get richer. all the rest of the discussion is high-sugar, low protein icing. randy From david.kessens at nokia.com Wed Apr 27 13:23:04 2005 From: david.kessens at nokia.com (David Kessens) Date: Wed, 27 Apr 2005 04:23:04 -0700 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio In-Reply-To: <17006.39185.775519.528906@roam.psg.com> References: <425A3839.6050104@bluewin.ch> <426C9474.2020701@bluewin.ch> <17006.39185.775519.528906@roam.psg.com> Message-ID: <20050427112304.GC3738@nokia.com> On Tue, Apr 26, 2005 at 09:40:01AM -1000, Randy Bush wrote: > look, the hd ratio is simple. because it is log, rather than > linear, it gives bigger allocations to those with bigger > allocations, the rich get richer. all the rest of the discussion > is high-sugar, low protein icing. And the rich will claim they have a right to a larger share of the resource since they have a justified tendency to be less efficient with these resources than the poor ... David Kessens --- From jwkckid1 at ix.netcom.com Thu Apr 28 05:11:33 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 27 Apr 2005 20:11:33 -0700 Subject: [address-policy-wg] Policy proposal: #beta: IPv4-HD-Ratio References: <425A3839.6050104@bluewin.ch> <426C9474.2020701@bluewin.ch> <17006.39185.775519.528906@roam.psg.com> <20050427112304.GC3738@nokia.com> Message-ID: <42705461.8209A017@ix.netcom.com> David and all, IPv4 or IPv6 resources and their use of distribution should not be determined by the economic status or those requesting them, but rather based upon in part, on need and effective use for the greater good.. David Kessens wrote: > On Tue, Apr 26, 2005 at 09:40:01AM -1000, Randy Bush wrote: > > look, the hd ratio is simple. because it is log, rather than > > linear, it gives bigger allocations to those with bigger > > allocations, the rich get richer. all the rest of the discussion > > is high-sugar, low protein icing. > > And the rich will claim they have a right to a larger share of the > resource since they have a justified tendency to be less efficient > with these resources than the poor ... > > David Kessens > --- Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From Patrick.Arkley at se.mci.com Thu Apr 28 13:01:28 2005 From: Patrick.Arkley at se.mci.com (Patrick Arkley) Date: Thu, 28 Apr 2005 12:01:28 +0100 Subject: [address-policy-wg] Summary TLD Anycast Allocation Policy Message-ID: <960F7470312B2C46B6EBCC76F77E9616013B5B62@stoexch1.stk.se.uu.net> Hi WG. We at MCI are requesting a /24 PI-range to use for an anycast service (DNS) but the request has been rejected in accordance to the current assignment policy. We need PI-space belonging to a separate AS so we can't use existing MCI space. The need for this range is if course routing reasons which is prohibited by the policy. I've been reading Andreas Baess e-mail on this issue and I hope this issue will be addressed on the RIPE 50 and rule in favour of changing the policy. I don't judge on the routability aspects but more on the fact that we need a change in the policy to accomodate a setup for anycast services. Myself I can't attend the WG meeting on Thursday 5/5 due to other engagements so this e-mail is my support for the proposal. Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Arm?gatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley at se.mci.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at ripe.net Thu Apr 28 16:51:22 2005 From: leo at ripe.net (leo vegoda) Date: Thu, 28 Apr 2005 16:51:22 +0200 Subject: [address-policy-wg] New Draft Document: RIPE Whois Registration in 2005: What should be in Whois and Why? Message-ID: <4270F86A.2000107@ripe.net> Dear Colleagues, At RIPE 49, Eva Ericsson Rabete (TeliaSonera) made a presentation to the Address Policy Working Group in which she asked some questions about the state of the RIPE Whois Database. Following the discussion at the meeting, Eva was asked to take the discussion onto this list (Action Point 49.4). A draft document discussing the uses of the RIPE Whois Database, and detailing questions to consider, has been published in the "Latest Draft Documents" section of the RIPE Document Store. The purpose of this draft document is to encourage discussion about what elements should be in the Whois Database and why they should be there. This draft document is available at: http://www.ripe.net/ripe/draft-documents/whois2005.html Regards, -- leo vegoda Registration Services Manager RIPE NCC