From gert at space.net Mon May 1 17:43:42 2006 From: gert at space.net (Gert Doering) Date: Mon, 1 May 2006 17:43:42 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <87wtd7me5b.fsf@mid.deneb.enyo.de> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> Message-ID: <20060501154342.GO60910@Space.Net> Hi, On Sun, Apr 30, 2006 at 02:38:56PM +0200, Florian Weimer wrote: > > Most (if not all) larger hosting providers I know are LIRs, so this > > question really doesn't apply. > Then we will arrive at "LIRs are global pain to everybody else", and > nothing has changed. Which is touching the core of the problem: "can we agree upon who should be allowed to put a route into my routers"? LIRs seem to be a good choice, because many (most?) of them *do* allocate for third parties (which is a good thing for global aggregation) - and even for those that don't, the fact that there is a recurring fee involved shifts the balance a bit away from "PI is purely convenient for the holder and puts the costs only on everybody else" to "a portable IP block *does* have some costs attached". So in the end, we might want to abandon the "IPv6 PI" approaches, and radically change (loosen) the "IPv6 PA" policy. But *I* am not the one to decide that - I follow the discussions, and try to extract some sort of workable (for the next few years) compromise between the extreme positions, which will then re-enter the discussion. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 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 ripe-lst at eirconnect.net Mon May 1 19:25:19 2006 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 1 May 2006 18:25:19 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060501154342.GO60910@Space.Net> References: <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> Message-ID: <200605011825.20018.ripe-lst@eirconnect.net> On Monday 01 May 2006 16:43, Gert Doering wrote: > a recurring fee involved shifts the balance a bit away from "PI is > purely convenient for the holder and puts the costs only on everybody > else" to "a portable IP block *does* have some costs attached". Am I completely wrong here, or does a LIR pay for the privilege of assigning IP space to end-users? Which, looking at some "ISP"s insane business models ( ?200/year for a /29 - hello?) could be a profitable business in itself. Having said that, there is no technical reason why PA and PI should be different at all - if anyone with routable IPv[46] space would be required to be a RIR member that should appease the "It's unfair that we should pay and have to deal with RIRs and others don't" faction. It would also give them access to the relevant training and tools. The LIR function would then be altogether separate from the IP space request function. I predict some opposition from the RIRs, though... rgds, s. From gert at space.net Mon May 1 20:00:40 2006 From: gert at space.net (Gert Doering) Date: Mon, 1 May 2006 20:00:40 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605011825.20018.ripe-lst@eirconnect.net> References: <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <200605011825.20018.ripe-lst@eirconnect.net> Message-ID: <20060501180040.GP60910@Space.Net> Hi, On Mon, May 01, 2006 at 06:25:19PM +0100, Sascha Luck wrote: > Am I completely wrong here, or does a LIR pay for the privilege of > assigning IP space to end-users? Which, looking at some "ISP"s insane > business models ( ???200/year for a /29 - hello?) could be a profitable > business in itself. The sum of the LIR fees pays for the RIPE NCC budget (which is non-profit, but is permitted to build some savings). The fees are explicitely not "per IP address" (so "two times the address space" doesn't mean "twice the fee") - *but* there is a address space dependent component, to better balance the fees between "small LIRs" and "large LIRs" - and there is no other easily applicable metric to measure a LIR's size than "internet resources used" (this model could be changed by the members in the RIPE AGM, btw). Even for large LIRs, the total yearly fee is not that much, compared to "having a few competent employees looking after their network". If some ISPs have funny business models, pick a different one. There are enough in the market place - but don't complain that your favourite "internet free for 2 EUR/month" ISP isn't offering everything that you'd like to see included in that 2 EUR... > Having said that, there is no technical reason why PA and PI should be > different at all - if anyone with routable IPv[46] space would be > required to be a RIR member that should appease the "It's unfair that > we should pay and have to deal with RIRs and others don't" faction. It > would also give them access to the relevant training and tools. The LIR > function would then be altogether separate from the IP space request > function. Yes. > I predict some opposition from the RIRs, though... I can't speak for other regions, but the RIPE NCC is there to serve the needs of the RIPE members - so if *we* decide that we want to change something, the RIPE NCC will implement it. And usually in a friendly and competent way. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 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 kurtis at kurtis.pp.se Mon May 1 20:12:18 2006 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 1 May 2006 20:12:18 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060501154342.GO60910@Space.Net> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> Message-ID: <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> On 1 maj 2006, at 17.43, Gert Doering wrote: > Hi, > > On Sun, Apr 30, 2006 at 02:38:56PM +0200, Florian Weimer wrote: >>> Most (if not all) larger hosting providers I know are LIRs, so this >>> question really doesn't apply. >> Then we will arrive at "LIRs are global pain to everybody else", and >> nothing has changed. > > Which is touching the core of the problem: > > "can we agree upon who should be allowed to put a route into my > routers"? > > LIRs seem to be a good choice, because many (most?) of them *do* > allocate > for third parties (which is a good thing for global aggregation) - and > even for those that don't, the fact that there is a recurring fee > involved > shifts the balance a bit away from "PI is purely convenient for the > holder > and puts the costs only on everybody else" to "a portable IP block > *does* > have some costs attached". > > So in the end, we might want to abandon the "IPv6 PI" approaches, and > radically change (loosen) the "IPv6 PA" policy. > > But *I* am not the one to decide that - I follow the discussions, > and try > to extract some sort of workable (for the next few years) compromise > between the extreme positions, which will then re-enter the > discussion. I actually agree with Gert. If we for a moment ignores who has the right to a slot in the routing table, I think the entire notion of PI should be abandoned as we have it today. I want holders of address space to have a recurring contact with the RIRs to make sure contact data is accurate and the holder still exists. I further think that all address-space holders should be subject to the same rules. Now, changing the rules for what is already out there does not seem doable, but at least we should change for the future. If PA space policy is broken, let's fix that. As for who have a right to a slot in my routing table, I think a minimum requirement is that they can be bothered to fulfil the duties as an LIR. If they can't be bothered with that, I can't be bothered to carry their route. So, let's move to a discussion on who should be able to get PA space.... I think being an LIR is a minimum requirement, that includes paying the associated fees. The 200 rule is questionable to me, it's arbitrary and more or less impossible to enforce. The demand that the space actually be used on the public routable Internet seems good if we could define this clearly. Leo told me that the NCC receives approx ~1400 requests a year for IPv4 PI space. I wonder how much of that is going to ISPs becuase it's "cheaper" than PA space...which is a claim that is hard to quantify. Well, this might be enough to start a discussion... - kurtis - From Michael.Dillon at btradianz.com Tue May 2 11:17:25 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 2 May 2006 10:17:25 +0100 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: <7.0.1.0.0.20060430203808.01e0c238@telenor.net> Message-ID: Perhaps someone can clear up my understanding on the ETNO question. Torunn Narvestad wrote on 30/04/2006 19:44:35: > I do not at all support this policy proposal. > >And I also have to agree with Gert Doering who said in the address policy > >WG that there has been very quiet around this proposal, and that the > >reason for this can be that ETNO claims thay "unanimously support this > >proposal". According to this page: http://www.etno.be/Default.aspx?tabid=1239 Telenor is a member of ETNO. Does this mean that ETNO has falsely claimed unanimous support among its members? Or has Telenor changed its mind? Earlier Per Heldal asked: >Does this mean that ETNO assume they have some form of veto in the RIPE >community? I can't see any reason why ETNO's vote should count for more >than any other _individual's_ opinion regardless of who they claim to >represent. Again, perhaps I misunderstand how RIPE works. Per refers to ETNO's vote but I thought that ETNO had no vote at all in RIPE working groups. My understanding was that individuals have a vote, not organizations. Have I misunderstood something here? --Michael Dillon From jeroen at unfix.org Tue May 2 11:47:41 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 02 May 2006 11:47:41 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> Message-ID: <1146563261.13927.104.camel@firenze.zurich.ibm.com> On Mon, 2006-05-01 at 20:12 +0200, Kurt Erik Lindqvist wrote: > On 1 maj 2006, at 17.43, Gert Doering wrote: > [..] > I actually agree with Gert. If we for a moment ignores who has the > right to a slot in the routing table, I think the entire notion of PI > should be abandoned as we have it today. I want holders of address > space to have a recurring contact with the RIRs to make sure contact > data is accurate and the holder still exists. I further think that > all address-space holders should be subject to the same rules. Now, > changing the rules for what is already out there does not seem > doable, but at least we should change for the future. If PA space > policy is broken, let's fix that. PA is what it says: Provider Address space, thus address space for end-users provided by their provider. These get >/32+ PI is provider independent, and thus for endsites, typically /48's, maybe upto a /44 or so. I would keep them seperate names because of this. Though one could also merge them. The thing is that they will, at some point, pop up both in the routing tables, assuming no other solution arrives, and they are both based on the amount of address space usage. Having the seperate might later on easily allow them to be seperated. > As for who have a right to a slot in my routing table, I think a > minimum requirement is that they can be bothered to fulfil the duties > as an LIR. If they can't be bothered with that, I can't be bothered > to carry their route. So, let's move to a discussion on who should be > able to get PA space.... Being LIR makes at least sure that somebody (or a consultant) at the organisation has some RIR clue and most likely also some routing clue. This is already a reasonable financial and work-load barrier. The people who decide on that one gets an entry in the routing table are the folks who accept the route. Not the community. Though one could set a sort of default community policy or so. The IPv4 /24-/32 filtering is not a carved in stone standard either but most ISP's are doing it anyway. > I think being an LIR is a minimum requirement, that includes paying > the associated fees. Ack. And if you can't pay the fees or pay a LIR then you most likely can't pay for proper hardware and maintainance either ;) > The 200 rule is questionable to me, it's > arbitrary and more or less impossible to enforce. The PA 200 is currently more a stopper for very small sites of getting PA space in a /32 chunk which they will never use. > The demand that the > space actually be used on the public routable Internet seems good if > we could define this clearly. That would be COMPLETELY silly. It's address space, no routability is guaranteed and then you require it to be routed onto the internet? What do you want, people to announce their space and then blackhole it? ISP's request address space, for what they use it is their right. As long as they actually use the space they requested of course. > Leo told me that the NCC receives > approx ~1400 requests a year for IPv4 PI space. I wonder how much of > that is going to ISPs becuase it's "cheaper" than PA space...which is > a claim that is hard to quantify. PI is for folks wanting to be independent. Independency is most of the time a bit more expensive. Thus IMHO in very short: - PA policy is for Providers, these provide access to endsites. - PI policy is for Endsites. Pricing should be LIR-fee + annual renenewal depending on the size of the space received. That said RIR's don't say who gets a slot in the routing space and policy should not forbid people getting address space, if it is meant for the internet or for other use. As long as an entity can show the demand for the amount of requested address space and is willing to pay the price they should be able to get it. The routability factor they can guarantee by being cool enough and persuading other ISP's to accept their announcements. Currently (peeing at GRH) that means if you have a /48 it will simply work(tm). This might change over the coming years though, solutions will come... also see my longer message about address space & routing slots on ppml at arin... My couple of rappen... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From marc.van.selm at nc3a.nato.int Tue May 2 12:00:11 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Tue, 2 May 2006 12:00:11 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> References: <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> Message-ID: <200605021200.11369.marc.van.selm@nc3a.nato.int> On Monday 01 May 2006 20:12, Kurt Erik Lindqvist wrote: > On 1 maj 2006, at 17.43, Gert Doering wrote: [...] > I actually agree with Gert. If we for a moment ignores who has the > right to a slot in the routing table, I think the entire notion of PI > should be abandoned as we have it today. I want holders of address > space to have a recurring contact with the RIRs to make sure contact > data is accurate and the holder still exists. Good point. Why don't we approach it from that way then. We have a holder of an IP block. A LIR hands them out on behalf of others and is also an aggregation point. An org. that needs a block of its own (ignoring the criteria for a moment) has the same aggregation responsibility. They also have a payment responsibility towards the RIR (or a LIR (why not have a mediator role for the LIR with handing out a PI block if they like that business model)). So LIR or organization: same responsibilities and payment scheme. Getting IP space from a LIR generally means getting connectivity also. If you get PI space, you get no connectivity but you get that elsewhere. So same rules for routing and payment but the difference is address block + connectivity and address block - connectivity. Then a PI policy is more or less a copy of the LIR policy without the posibility/requirement to allocate on behalf of others. I guess the PI "owner's" transmission provider or peering partner will keep him sane with respect to doing the right routing thing. Does this approach make sense? [...] > > Well, this might be enough to start a discussion... > > - kurtis - -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From thk at telenor.net Tue May 2 13:03:43 2006 From: thk at telenor.net (Thor-Henrik Kvandahl) Date: Tue, 2 May 2006 13:03:43 +0200 (MEST) Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: On Tue, 2 May 2006 Michael.Dillon at btradianz.com wrote: > Perhaps someone can clear up my understanding on the ETNO > question. > > Torunn Narvestad wrote on 30/04/2006 19:44:35: > > I do not at all support this policy proposal. > > > >And I also have to agree with Gert Doering who said in the address > policy > > >WG that there has been very quiet around this proposal, and that the > > >reason for this can be that ETNO claims thay "unanimously support this > > >proposal". > > According to this page: http://www.etno.be/Default.aspx?tabid=1239 > Telenor is a member of ETNO. Does this mean that ETNO has > falsely claimed unanimous support among its members? > Or has Telenor changed its mind? In my email I emphasized that I expressed my *personal* opinion. -- Thor-Henrik Kvandahl From heldal at eml.cc Tue May 2 16:02:41 2006 From: heldal at eml.cc (Per Heldal) Date: Tue, 02 May 2006 16:02:41 +0200 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: <1146578561.11167.260421899@webmail.messagingengine.com> On Tue, 2 May 2006 10:17:25 +0100, Michael.Dillon at btradianz.com said: > According to this page: http://www.etno.be/Default.aspx?tabid=1239 > Telenor is a member of ETNO. Does this mean that ETNO has > falsely claimed unanimous support among its members? I don't know for sure, but it would be no surprise. These telecoms organisations are known to have a mind of their own unlike what we're used to in our consensus-driven community. > Or has Telenor changed its mind? Only Telenor can tell ;) > > Earlier Per Heldal asked: > >Does this mean that ETNO assume they have some form of veto in the RIPE > >community? I can't see any reason why ETNO's vote should count for more > >than any other _individual's_ opinion regardless of who they claim to > >represent. > > Again, perhaps I misunderstand how RIPE works. Per refers to ETNO's vote > but I thought that ETNO had no vote at all in RIPE working groups. > My understanding was that individuals have a vote, not organizations. > Have I misunderstood something here? I should have used the term "voice" instead of "vote". Sorry about the confusion. Point is; ETNO members should have to stand up for themselves, individually, if they want to be heard in the community ... just like everybody else has to. //per -- Per Heldal http://heldal.eml.cc/ From ornulf.storm at npt.no Tue May 2 16:16:58 2006 From: ornulf.storm at npt.no (=?iso-8859-1?Q?Storm=2C_=D8rnulf?=) Date: Tue, 2 May 2006 16:16:58 +0200 Subject: VS: [address-policy-wg] IPv4-HD-Ratio proposal Message-ID: <6C33D43309355C4995DD2473FBDEFFB0046B760F@angus.npta.no> -----Opprinnelig melding----- Fra: Storm, ?rnulf Sendt: 28. april 2006 10:37 Til: address-policy-wg at ripe.net Kopi: 'Thor-Henrik Kvandahl' Emne: SV: [address-policy-wg] IPv4-HD-Ratio proposal I also support Thor-Henrik comments. I think it would be a bad idea to make a policy change now that increases the consumption, especially now when it is going towards the end of the lifetime of the IPv4 address space, relatively speaking reference to the work that Geoff Houston has done on predictions of the lifetime of the IPv4 address space. This proposal could be seen as favouring the large ISPs and is working in disfavour of the small ISPs. The IP address space should be assigned in a fairly manner and it appears that this proposal could change this. All participants should have the same conditions when competing with each other. A small ISP in a small country should have same possibilities to get new IP address space as a large ISP in a large country. Therefore, I think that establishing this policy would be the wrong message for the RIPE community to send in these WSIS days with the "world watching". Regards, ?rnulf Storm Network Addresses and Electronic Signatues Norwegian Post and Telecommunications Authority E-mail: ors at npt.no Telephone: +47 22824600 Web: www.npt.no -----Opprinnelig melding----- Fra: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] P? vegne av Thor-Henrik Kvandahl Sendt: Thursday, April 27, 2006 9:48 AM Til: address-policy-wg at ripe.net Emne: [address-policy-wg] IPv4-HD-Ratio proposal Hi all, here are my *personal* opinion on this proposal. I do not support this proposal, and my reasons for this are: * This proposal increases the rate of consumption of IPv4. * It favourises the large ISPs. * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told that this proposal was abandoned by ARIN and APNIC, and one representative from LacNIC also stood up and expressed their conserns. I have not heard anything from AfriNIC, but I cannot see why they would want to implement this policy. I feel if will be arrogant of the RIPE community to disregard the other RIRs conserns and implement this policy. And I also have to agree with Gert Doering who said in the address policy WG that there has been very quiet around this proposal, and that the reason for this can be that ETNO claims thay "unanimously support this proposal". -- Thor-Henrik Kvandahl no.telenor From Michael.Dillon at btradianz.com Tue May 2 17:16:56 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 2 May 2006 16:16:56 +0100 Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: <1146578561.11167.260421899@webmail.messagingengine.com> Message-ID: > I should have used the term "voice" instead of "vote". Sorry about the > confusion. > > Point is; ETNO members should have to stand up for themselves, > individually, if they want to be heard in the community ... just like > everybody else has to. Let me see if I understand this correctly. 1. ETNO has no vote at all regarding RIPE policies. 2. ETNO doesn't even have a voice in making or changing RIPE policies. 3. Telenor also has no voice in making or changing RIPE policies. 4. RIPE policies are made by the individuals who participate in the working groups and meetings. 5. ETNO, Telenor and any other organization can only influence RIPE policies if individuals from those organizations participate in RIPE working groups and meetings. I know this may seem like very basic stuff to old-timers but I think this needs to be said because some people, in particular those who participate in ETNO, do not seem to have a correct understanding of how RIPE functions. In order to be fair to all, RIPE has to make it clear how to participate in the RIPE decision-making process. --Michael Dillon From tna at telenor.net Tue May 2 18:01:52 2006 From: tna at telenor.net (Torunn Narvestad) Date: Tue, 02 May 2006 18:01:52 +0200 Subject: [address-policy-wg] IPv4-HD-Ratio proposal References: Message-ID: <44578270.1030900@telenor.net> Thor-Henrik Kvandahl wrote: >On Tue, 2 May 2006 Michael.Dillon at btradianz.com wrote: > >>Perhaps someone can clear up my understanding on the ETNO >>question. >> >>Torunn Narvestad wrote on 30/04/2006 19:44:35: >> >>>I do not at all support this policy proposal. >>> >>>>And I also have to agree with Gert Doering who said in the address >>>> >>policy >> >>>>WG that there has been very quiet around this proposal, and that the >>>>reason for this can be that ETNO claims thay "unanimously support this >>>>proposal". >>>> >>According to this page: http://www.etno.be/Default.aspx?tabid=1239 >>Telenor is a member of ETNO. Does this mean that ETNO has >>falsely claimed unanimous support among its members? >>Or has Telenor changed its mind? >> > >In my email I emphasized that I expressed my *personal* opinion. > I also expressed my *personal* opinion, although I didn't emphasize it so clearly as Thor-Henrik :-) - Torunn -- Torunn Narvestad Telenor Nordic tna at telenor.net +47 47 90 00 96 From kurtis at kurtis.pp.se Tue May 2 22:08:02 2006 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 2 May 2006 22:08:02 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1146563261.13927.104.camel@firenze.zurich.ibm.com> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> <1146563261.13927.104.camel@firenze.zurich.ibm.com> Message-ID: <09E46164-D99C-4057-A73F-14D6AA622201@kurtis.pp.se> On 2 maj 2006, at 11.47, Jeroen Massar wrote: > On Mon, 2006-05-01 at 20:12 +0200, Kurt Erik Lindqvist wrote: >> On 1 maj 2006, at 17.43, Gert Doering wrote: >> [..] >> I actually agree with Gert. If we for a moment ignores who has the >> right to a slot in the routing table, I think the entire notion of PI >> should be abandoned as we have it today. I want holders of address >> space to have a recurring contact with the RIRs to make sure contact >> data is accurate and the holder still exists. I further think that >> all address-space holders should be subject to the same rules. Now, >> changing the rules for what is already out there does not seem >> doable, but at least we should change for the future. If PA space >> policy is broken, let's fix that. > > PA is what it says: Provider Address space, thus address space for > end-users provided by their provider. These get >/32+ > > PI is provider independent, and thus for endsites, typically /48's, > maybe upto a /44 or so. It's more than that. PA comes with an annual cost and contact with the RIPE NCC. PI is free more or less for life with no guaranteed record keeping or guarnatee that the owner even exists. See experiences from ERX. > I would keep them seperate names because of this. Though one could > also > merge them. The thing is that they will, at some point, pop up both in > the routing tables, assuming no other solution arrives, and they are > both based on the amount of address space usage. Having the seperate > might later on easily allow them to be seperated. I am less concerned about what you end up calling it than I am with 1) Keeping track of it 2) Having the owners follow the same policy >> As for who have a right to a slot in my routing table, I think a >> minimum requirement is that they can be bothered to fulfil the duties >> as an LIR. If they can't be bothered with that, I can't be bothered >> to carry their route. So, let's move to a discussion on who should be >> able to get PA space.... > > Being LIR makes at least sure that somebody (or a consultant) at the > organisation has some RIR clue and most likely also some routing clue. > This is already a reasonable financial and work-load barrier. Yes, that is the point. >> The 200 rule is questionable to me, it's >> arbitrary and more or less impossible to enforce. > > The PA 200 is currently more a stopper for very small sites of getting > PA space in a /32 chunk which they will never use. Whatever it is, it's arbitrary and comes with it's own set of problems. >> The demand that the >> space actually be used on the public routable Internet seems good if >> we could define this clearly. > > That would be COMPLETELY silly. It's address space, no routability is > guaranteed and then you require it to be routed onto the internet? > What do you want, people to announce their space and then blackhole > it? > ISP's request address space, for what they use it is their right. As > long as they actually use the space they requested of course. It's not that long ago this was the requirement for IPv4 space... >> Leo told me that the NCC receives >> approx ~1400 requests a year for IPv4 PI space. I wonder how much of >> that is going to ISPs becuase it's "cheaper" than PA space...which is >> a claim that is hard to quantify. > > PI is for folks wanting to be independent. Independency is most of the > time a bit more expensive. PI space is free for life. > Thus IMHO in very short: > - PA policy is for Providers, these provide access to endsites. > - PI policy is for Endsites. Look, it's the same routing table slot, and it's the same addresses. Just that one is yours to keep forever, free of charge, and no requirement to keep uptodate records. PI as we know it should go. Or be subject to the same conditions as PA space. I wouldn't be surprise to find ISPs using PI space.... > Pricing should be LIR-fee + annual renenewal depending on the size of > the space received. Yupp. - kurtis - From gert at space.net Tue May 2 22:16:15 2006 From: gert at space.net (Gert Doering) Date: Tue, 2 May 2006 22:16:15 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <09E46164-D99C-4057-A73F-14D6AA622201@kurtis.pp.se> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> <1146563261.13927.104.camel@firenze.zurich.ibm.com> <09E46164-D99C-4057-A73F-14D6AA622201@kurtis.pp.se> Message-ID: <20060502201615.GF3510@Space.Net> Hi, On Tue, May 02, 2006 at 10:08:02PM +0200, Kurt Erik Lindqvist wrote: > I wouldn't be surprise to find ISPs using PI space.... Which happened quite frequently during the time where we had the idea to conserve IPv4 addresses by requiring a minimum utilization before a new LIR could get an initial PA block. Which ended up hurting routing, and not conserving very many addresses. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 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 thk at telenor.net Wed May 3 09:54:10 2006 From: thk at telenor.net (Thor-Henrik Kvandahl) Date: Wed, 3 May 2006 09:54:10 +0200 (MEST) Subject: [address-policy-wg] IPv4-HD-Ratio proposal In-Reply-To: References: Message-ID: Hi all. If issues regarding rfc2050 has been discussed before, then please excuse me. I see that ARIN and LACNIC has discussed rfc2050 conflicts in this proposal, but I cannot remember that this topic is discussed in the RIPE region. This proposal breaks the 80% rule in rfc2050. The proposal mentions the 80% rule, but it does not mention or discuss the fact that this rule is stated in rfc 2050. The proposal says: d. Arguments opposing the proposal. This proposal will have some limited impact on IPV4 address consumption. I think conflicts with rfc2050 also should have been listed in the proposal item d. -- Thor-Henrik Kvandahl no.telenor On Thu, 27 Apr 2006, Thor-Henrik Kvandahl wrote: > > Hi all, > > here are my *personal* opinion on this proposal. > > I do not support this proposal, and my reasons for this are: > > * This proposal increases the rate of consumption of IPv4. > * It favourises the large ISPs. > * In the presentation on RIPE 52, Tuesday by Filiz Yilmaz, we where told > that this proposal was abandoned by ARIN and APNIC, and one > representative from LacNIC also stood up and expressed their conserns. > I have not heard anything from AfriNIC, but I cannot see why they would > want to implement this policy. I feel if will be arrogant of the RIPE > community to disregard the other RIRs conserns and implement this policy. > > And I also have to agree with Gert Doering who said in the address policy > WG that there has been very quiet around this proposal, and that the > reason for this can be that ETNO claims thay "unanimously support this > proposal". > > -- > Thor-Henrik Kvandahl > no.telenor > From leo at ripe.net Wed May 3 15:40:47 2006 From: leo at ripe.net (leo vegoda) Date: Wed, 03 May 2006 15:40:47 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> Message-ID: <4458B2DF.2040807@ripe.net> Hi, Kurt Erik Lindqvist wrote: [...] > this clearly. Leo told me that the NCC receives approx ~1400 requests a > year for IPv4 PI space. I wonder how much of that is going to ISPs > becuase it's "cheaper" than PA space...which is a claim that is hard to > quantify. You can see some historical information about PI assignments (and other information) in slides 5, 6 and 7 of the RIPE NCC Numbers Update I presented last week: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-ripe_ncc_numbers_update.pdf We also have numbers showing the numbers of PI assignments per prefix length last year. These numbers include a few assignments made to trade fairs, conferences and so on. /18 1 /19 5 /20 24 /21 54 /22 268 /23 400 /24 730 /25 10 /26 9 /27 5 /29 2 I hope these data are useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC From Woeber at CC.UniVie.ac.at Wed May 3 16:09:01 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 03 May 2006 14:09:01 +0000 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <09E46164-D99C-4057-A73F-14D6AA622201@kurtis.pp.se> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> <1146563261.13927.104.camel@firenze.zurich.ibm.com> <09E46164-D99C-4057-A73F-14D6AA622201@kurtis.pp.se> Message-ID: <4458B97D.308@CC.UniVie.ac.at> Just a technical/financial clarification.... Kurt Erik Lindqvist wrote: [ ... ] >> PI is for folks wanting to be independent. Independency is most of the >> time a bit more expensive. > > > PI space is free for life. Not really. Quite a while ago the NCC stopped accepting PI requests from "walk-in" applicants (as we told them to do). Since then an application for PI (and ASNs) can only be submitted by way of an LIR. And those assignments do count against their "size" calculation: http://www.ripe.net/ripe/docs/charging.html The table with the scoring units and the formula for category determination can be found close to the end of that page. >> Thus IMHO in very short: >> - PA policy is for Providers, these provide access to endsites. >> - PI policy is for Endsites. > [ ... ] > > - kurtis - Wilfried. From berni at birkenwald.de Wed May 3 16:26:06 2006 From: berni at birkenwald.de (Bernhard Schmidt) Date: Wed, 03 May 2006 16:26:06 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4458B97D.308@CC.UniVie.ac.at> References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> <12627C89-9960-4E22-A18E-F4CDD757AA3D@kurtis.pp.se> <1146563261.13927.104.camel@firenze.zurich.ibm.com> <09E46164-D99C-4057-A73F-14D6AA622201@kurtis.pp.se> <4458B97D.308@CC.UniVie.ac.at> Message-ID: <4458BD7E.5070706@birkenwald.de> Wilfried Woeber, UniVie/ACOnet schrieb: Hi, >>> PI is for folks wanting to be independent. Independency is most of the >>> time a bit more expensive. >> PI space is free for life. > Not really. > > Quite a while ago the NCC stopped accepting PI requests from "walk-in" > applicants (as we told them to do). > > Since then an application for PI (and ASNs) can only be submitted by way > of an LIR. And those assignments do count against their "size" calculation: Yes, but only in the first year (no way else to do it, the LIR will not have a customer/billing-relationship with the PI "owner" forever). And at least a few LIRs don't even charge their customer in the first year if they don't get pushed in the next billing category due to PI requests. I know of a few ISPs that chose PI space over PA space (for example with a subsidiary company as applicant) because it is cheaper in the long term. The RIRs either need to have a direct billing relationship with PI holders or PI has to be transferable between LIRs (on whose bill it is with a fixed amout, this billing point scheme is imho not suitable for this), otherwise a recurring fee is not possible. Regards, Bernhard From fw at deneb.enyo.de Mon May 8 07:28:23 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 08 May 2006 07:28:23 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060501154342.GO60910@Space.Net> (Gert Doering's message of "Mon, 1 May 2006 17:43:42 +0200") References: <444C8EC2.1070703@inex.ie> <20060423115913.GK60910@Space.Net> <200604241316.30188.president@ukraine.su> <20060424103855.GT60910@Space.Net> <87wtd7me5b.fsf@mid.deneb.enyo.de> <20060501154342.GO60910@Space.Net> Message-ID: <87psip2ih4.fsf@mid.deneb.enyo.de> * Gert Doering: > Which is touching the core of the problem: > > "can we agree upon who should be allowed to put a route into my routers"? Ideally, that would be someone who pays for this kind of service. The fewer prefixes there are, the more feasible this approach will be. 8-) > LIRs seem to be a good choice, because many (most?) of them *do* allocate > for third parties (which is a good thing for global aggregation) - and > even for those that don't, the fact that there is a recurring fee involved > shifts the balance a bit away from "PI is purely convenient for the holder > and puts the costs only on everybody else" to "a portable IP block *does* > have some costs attached". In principle, such an effect is desirable. But I would be very surprised if the majority of end users with IPv4 PI didn't pay a monthly fee for non-mass-market Internet connectivity. This means that they actually need PI, or they don't care that much because the price difference still isn't large enough. In the latter case, a rather significant fee is needed to turn global inconvenience into a local one. From ripe-lst at eirconnect.net Mon May 8 20:01:46 2006 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Mon, 8 May 2006 19:01:46 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <87psip2ih4.fsf@mid.deneb.enyo.de> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> Message-ID: <200605081901.46565.ripe-lst@eirconnect.net> On Monday 08 May 2006 06:28, Florian Weimer wrote: > In the latter case, a > rather significant fee is needed to turn global inconvenience into a > local one. An arbitrary fee, specifically designed to block someone's entry into *any* market, is *illegal*, at least in any non-communist country that I know. I also don't understand the whole decision circling back, endlessly, to restrictive policies when nobody actually seems to want IPv6 (assuming this is still what we're talking about) rgds, s. From marc.van.selm at nc3a.nato.int Tue May 9 09:09:01 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Tue, 9 May 2006 09:09:01 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <87psip2ih4.fsf@mid.deneb.enyo.de> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> Message-ID: <200605090909.01814.marc.van.selm@nc3a.nato.int> On Monday 08 May 2006 07:28, Florian Weimer wrote: > * Gert Doering: > > Which is touching the core of the problem: > > > > "can we agree upon who should be allowed to put a route into my > > routers"? > > Ideally, that would be someone who pays for this kind of service. The > fewer prefixes there are, the more feasible this approach will be. 8-) To be routed one needs at least one relationship with an ISP (in whatever form). My organization has PI (and PA) space. The PI space used to be routed via DRA (UK) via a milnet to the US, later via NL-Net, later via UU-net and now via Surfnet. In all occasions we pay for the service to be routed. Now how our provider(s) arrange with their peers to get our blocks routed is their business but I assume there is some form of agreement that takes care of it. So it is not like PI users just connect to the net for free. The fee be able to add routes is in what one pays to the connectivity provider. The use of PI space also implies that the PI holder can't just order a DSL from somewhere and get it routed. To get PI routed one needs a more serious contract (like we have) but that's ok because PI is part of a business continuity plan and one looks at the business case. The connectivity provider (generally an ISP) has to make sure all other parties are happy. That's the role of an ISP. In my view, regardless if one pays for the right to use a PI block, the fact that a PI holder has one does not load it into the routing table. Being connected does. Being connected is not free and costs money and is provided by ISP's or other organizations that connect somehow to the core of the Internet. [..] -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From tim.streater at dante.org.uk Tue May 9 11:03:09 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Tue, 09 May 2006 10:03:09 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605081901.46565.ripe-lst@eirconnect.net> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> Message-ID: <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> At 19:01 08/05/2006, Sascha Luck wrote: >On Monday 08 May 2006 06:28, Florian Weimer wrote: > > In the latter case, a > > rather significant fee is needed to turn global inconvenience into a > > local one. > >An arbitrary fee, specifically designed to block someone's entry into >*any* market, is *illegal*, at least in any non-communist country that >I know. > >I also don't understand the whole decision circling back, endlessly, to >restrictive policies when nobody actually seems to want IPv6 (assuming >this is still what we're talking about) At the moment I would like to get an IPv6 block for one of the transit networks we manage. They are being prevented from trying IPv6 because I can't get a PI block for it and it doesn't, as such, have any customers to which it allocates space. I want PI space for it because the intention is for this network to be "spun off" and become self-managing. And, I see no reason that management of this network might not be out-sourced to some distant country, so I want this block to be routed, please. Folks are going to come to terms with the fact that the v6 routing table is going to have large numbers of entries. Attempts to prevent this can only be done with restrictive policies, as you say. If we *don't* want the v6 routing table to have more than a few entries, we better adopt strictly geographical addressing (like the phone system) and hand the whole thing over to the ITU. -- Tim From nick at inex.ie Tue May 9 11:44:38 2006 From: nick at inex.ie (Nick Hilliard) Date: Tue, 09 May 2006 10:44:38 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> Message-ID: <1147167878.88439.17.camel@crumpet.netability.ie> On Tue, 2006-05-09 at 10:03 +0100, Tim Streater wrote: > At 19:01 08/05/2006, Sascha Luck wrote: > >An arbitrary fee, specifically designed to block someone's entry into > >*any* market, is *illegal*, at least in any non-communist country that > >I know. > > [...] > Folks are going to come to terms with the fact that the v6 routing > table is going to have large numbers of entries. IPv6 will be much better aggregated than ipv4, because the allocation blocks are larger, and the requirement for LIRs to request multiple non-contiguous blocks of space will be much lower. This necessarily means that ipv6 table growth is going to be lesser than the ipv4 table growth, which has also lagged behind hardware speed increases. What's the problem here?? As regards cost, PI space requires RIR administration, and that costs money. Additionally, there needs to be a means for RIRs to legitimately reclaim PI space. Charging a fee appears to be good way of dealing with both problems. It doesn't need to be a huge amount of money, but money needs to be involved. I would like to suggest that after initial liaison with the local LIR, that the end-user relationship would then revert to the RIR. The RIR would then be responsible for charging the end-user, and the LIR would be removed from the equation. This will require time and resources to set up, and that means that charging a fee will be completely justified. This will fix two things which completely fail to make sense about the current RIPE (ipv4) assignment policy: 1. there is no default means of returning PI space to the RIR if the end-user disappears 2. the LIR is effectively charged for the assignment, even if the end-user moves to another LIR's domain. Problem #1 is a really serious issue and needs to be tackled urgently. Nick From tim.streater at dante.org.uk Tue May 9 11:55:05 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Tue, 09 May 2006 10:55:05 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <1147167878.88439.17.camel@crumpet.netability.ie> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> Message-ID: <6.2.3.4.2.20060509104736.04d964f8@mail.dante.org.uk> At 10:44 09/05/2006, Nick Hilliard wrote: >On Tue, 2006-05-09 at 10:03 +0100, Tim Streater wrote: > > At 19:01 08/05/2006, Sascha Luck wrote: > > >An arbitrary fee, specifically designed to block someone's entry into > > >*any* market, is *illegal*, at least in any non-communist country that > > >I know. > > > >[...] > > Folks are going to come to terms with the fact that the v6 routing > > table is going to have large numbers of entries. > >IPv6 will be much better aggregated than ipv4, because the allocation >blocks are larger, and the requirement for LIRs to request multiple >non-contiguous blocks of space will be much lower. This necessarily >means that ipv6 table growth is going to be lesser than the ipv4 table >growth, which has also lagged behind hardware speed increases. What's >the problem here?? The fact that there are many more bits to allocate. >As regards cost, PI space requires RIR administration, and that costs >money. Additionally, there needs to be a means for RIRs to legitimately >reclaim PI space. Charging a fee appears to be good way of dealing with >both problems. It doesn't need to be a huge amount of money, but money >needs to be involved. > >I would like to suggest that after initial liaison with the local LIR, >that the end-user relationship would then revert to the RIR. The RIR >would then be responsible for charging the end-user, and the LIR would >be removed from the equation. > >This will require time and resources to set up, and that means that >charging a fee will be completely justified. This will fix two things >which completely fail to make sense about the current RIPE (ipv4) >assignment policy: > > 1. there is no default means of returning PI space to the RIR if > the end-user disappears > 2. the LIR is effectively charged for the assignment, even if the > end-user moves to another LIR's domain. > >Problem #1 is a really serious issue and needs to be tackled urgently. I think these are very good suggestions; there should be an annual fee for use of the PI block. This will fix the administrative aspects and should be retro-fitted to v4. Moving to the RIR administering the PI space also protects against the LIR disappearing. -- Tim From ripe-lst at eirconnect.net Tue May 9 11:59:53 2006 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Tue, 9 May 2006 10:59:53 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1147167878.88439.17.camel@crumpet.netability.ie> References: <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> Message-ID: <200605091059.53581.ripe-lst@eirconnect.net> On Tuesday 09 May 2006 10:44, Nick Hilliard wrote: > As regards cost, PI space requires RIR administration, and that costs > money. Additionally, there needs to be a means for RIRs to > legitimately reclaim PI space. Charging a fee appears to be good way > of dealing with both problems. It doesn't need to be a huge amount > of money, but money needs to be involved. Don't get me wrong, I've already said I agree fully with the need for PI-holders to become RIR-members (with associated cost). It's a fee, set arbitrarily high specifically to deter PI as suggested in the post I was responding to, that I have a problem with. rgds, s. -- DDO Eirconnect From nick at inex.ie Tue May 9 12:13:59 2006 From: nick at inex.ie (Nick Hilliard) Date: Tue, 09 May 2006 11:13:59 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <6.2.3.4.2.20060509104736.04d964f8@mail.dante.org.uk> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <6.2.3.4.2.20060509104736.04d964f8@mail.dante.org.uk> Message-ID: <1147169639.88439.34.camel@crumpet.netability.ie> On Tue, 2006-05-09 at 10:55 +0100, Tim Streater wrote: > The fact that there are many more bits to allocate. The actual number of bits is largely irrelevant to what we're talking about here. The real determinant of the problem is the number of discrete allocations and assignments announced, and this will be a function of the number of discrete networks required to service the globe. This will increase as connectivity increases, but it will ultimately plateau at some stage, or at least it will reach a stage where growth (i.e. rate of increase) will drop significantly. And as I said already, because of the allocation policies in place, ipv6 table growth will always trail the equivalent network prefix requirement for ipv4. Nick From sascha at eirconnect.net Tue May 9 11:56:09 2006 From: sascha at eirconnect.net (Sascha Luck) Date: Tue, 9 May 2006 10:56:09 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1147167878.88439.17.camel@crumpet.netability.ie> References: <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> Message-ID: <200605091056.09552.sascha@eirconnect.net> On Tuesday 09 May 2006 10:44, Nick Hilliard wrote: > As regards cost, PI space requires RIR administration, and that costs > money. Additionally, there needs to be a means for RIRs to > legitimately reclaim PI space. Charging a fee appears to be good way > of dealing with both problems. It doesn't need to be a huge amount > of money, but money needs to be involved. Don't get me wrong, I've already said I agree fully with the need for PI-holders to become RIR-members (with associated cost). It's a fee, set arbitrarily high specifically to deter PI as suggested in the post I was responding to, that I have a problem with. rgds, s. From mohta at necom830.hpcl.titech.ac.jp Tue May 9 13:16:47 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 09 May 2006 20:16:47 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1147167878.88439.17.camel@crumpet.netability.ie> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> Message-ID: <44607A1F.8010502@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >>Folks are going to come to terms with the fact that the v6 routing >>table is going to have large numbers of entries. > IPv6 will be much better aggregated than ipv4, because the allocation > blocks are larger, and the requirement for LIRs to request multiple > non-contiguous blocks of space will be much lower. It merely means difference of a small constant factor. > This necessarily > means that ipv6 table growth is going to be lesser than the ipv4 table > growth, which has also lagged behind hardware speed increases. What's > the problem here?? IPv4 routing table is already too large that its convergence is prohibitively slow. Moreover, as hardware becomes more and more optical, large routing table becomes slower and slower to lookup. > 1. there is no default means of returning PI space to the RIR if > the end-user disappears > Problem #1 is a really serious issue and needs to be tackled urgently. Not at all. If the end-user disappears, its entries in global routing tables are tackled automatically. Masataka Ohta From nick at inex.ie Tue May 9 13:48:37 2006 From: nick at inex.ie (Nick Hilliard) Date: Tue, 09 May 2006 12:48:37 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <44607A1F.8010502@necom830.hpcl.titech.ac.jp> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> Message-ID: <1147175317.88439.58.camel@crumpet.netability.ie> On Tue, 2006-05-09 at 20:16 +0900, Masataka Ohta wrote: > Nick Hilliard wrote: > > IPv6 will be much better aggregated than ipv4, because the allocation > > blocks are larger, and the requirement for LIRs to request multiple > > non-contiguous blocks of space will be much lower. > > It merely means difference of a small constant factor. I disagree. Most ISPs I know of announce a large number of non- contiguous address blocks. With ipv6, this will drop to just one or two in the short term; longer term, it will grow, but not even nearly at the same rate as ipv4 allocations. > IPv4 routing table is already too large that its convergence is > prohibitively slow. Geoff Huston's talk about this at RIPE was rather interesting. Yes, the routing table will grow. But that's only part of the problem; a bigger part of the problem is routing churn. Take a look at pages 37 and 38 of: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-bgp-review.pdf You can see that there is a small number of organisations responsible for massive numbers of updates. I can tell you that If I were supreme ruler of the universe, these organisations would get a smack on the face. > Not at all. If the end-user disappears, its entries in global routing > tables are tackled automatically. The prefix announcement disappears, but the space is lost to the available address pool forever (under current rules). Nick From mohta at necom830.hpcl.titech.ac.jp Tue May 9 16:25:26 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 09 May 2006 23:25:26 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1147175317.88439.58.camel@crumpet.netability.ie> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> <1147175317.88439.58.camel@crumpet.netability.ie> Message-ID: <4460A656.5080108@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >>It merely means difference of a small constant factor. > > > I disagree. Most ISPs I know of announce a large number of non- > contiguous address blocks. With ipv6, this will drop to just one or two > in the short term; longer term, it will grow, but not even nearly at > the same rate as ipv4 allocations. According to your favourite: >?http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-bgp-review.pdf each ISP announces, in average, about 8 blocks, which is the small constant factor. >>IPv4 routing table is already too large that its convergence is >>prohibitively slow. > > > Geoff Huston's talk about this at RIPE was rather interesting. Yes, the > routing table will grow. But that's only part of the problem; So, you have found the problem. That's enough to answer the quesiton in your previous mail of: What's the problem here?? >>Not at all. If the end-user disappears, its entries in global routing >>tables are tackled automatically. > The prefix announcement disappears, but the space is lost to the > available address pool forever (under current rules). It's not a serious issue for IPv6 and no urgent response necessary, though you said in your previous mail Problem #1 is a really serious issue and needs to be tackled urgently. Masataka Ohta From nick at inex.ie Tue May 9 17:22:06 2006 From: nick at inex.ie (Nick Hilliard) Date: Tue, 09 May 2006 16:22:06 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4460A656.5080108@necom830.hpcl.titech.ac.jp> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> <1147175317.88439.58.camel@crumpet.netability.ie> <4460A656.5080108@necom830.hpcl.titech.ac.jp> Message-ID: <1147188126.88439.109.camel@crumpet.netability.ie> > each ISP announces, in average, about 8 blocks, which is the small > constant factor. Yes, but in an ipv6 world, i don't really see why the average would be much more than 2 or 3. Most AS's will announce just one. > > Geoff Huston's talk about this at RIPE was rather interesting. Yes, the > > routing table will grow. But that's only part of the problem; > > So, you have found the problem. We all know that the two problems are routing table size and churn. But the two are not particularly related. A large routing table does not necessarily mean extra churn. Nick From david.conrad at icann.org Tue May 9 17:47:48 2006 From: david.conrad at icann.org (David Conrad) Date: Tue, 9 May 2006 08:47:48 -0700 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1147188126.88439.109.camel@crumpet.netability.ie> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> <1147175317.88439.58.camel@crumpet.netability.ie> <4460A656.5080108@necom830.hpcl.titech.ac.jp> <1147188126.88439.109.camel@crumpet.netability.ie> Message-ID: <90594687-C136-499F-AFDF-E13AFA1A79D1@icann.org> On May 9, 2006, at 8:22 AM, Nick Hilliard wrote: > Yes, but in an ipv6 world, i don't really see why the average would be > much more than 2 or 3. Most AS's will announce just one. How do you believe folks will do traffic engineering? Rgds, -drc From nick at inex.ie Wed May 10 21:28:34 2006 From: nick at inex.ie (Nick Hilliard) Date: Wed, 10 May 2006 20:28:34 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <90594687-C136-499F-AFDF-E13AFA1A79D1@icann.org> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> <1147175317.88439.58.camel@crumpet.netability.ie> <4460A656.5080108@necom830.hpcl.titech.ac.jp> <1147188126.88439.109.camel@crumpet.netability.ie> <90594687-C136-499F-AFDF-E13AFA1A79D1@icann.org> Message-ID: <44623EE2.1040105@inex.ie> David Conrad wrote: > How do you believe folks will do traffic engineering? This is an interesting point which occurred to me as I was writing my last email. Outside as-path prepending, I don't have a good answer. Where the relevant organisations have multiple connections to the same upstream, it can be managed using no-export subnet announcements alongside the main supernet announcement. But where there are multiple upstreams involved this will, of course, not work. AS path prepending will continue work to the extent that it does today, which is to say not very well. But the point remains. The default LIR allocation size is /32, which allows for 65K /48's. That is a large number of distinct networks, and will easily satisfy the long-term requirements of small to medium sized ISPs, which - I am going to speculate - comprise the bulk of both AS's and prefix announcements. And if the recommended assignment size were to be changed from /48 to /56 - again allowing ample block size for many organisations, that would optimise address space utilisation further, making a /32 allocation last much longer than previously. Nick From fw at deneb.enyo.de Tue May 9 21:51:52 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 09 May 2006 21:51:52 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605081901.46565.ripe-lst@eirconnect.net> (Sascha Luck's message of "Mon, 8 May 2006 19:01:46 +0100") References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> Message-ID: <873bfjvuw7.fsf@mid.deneb.enyo.de> * Sascha Luck: > On Monday 08 May 2006 06:28, Florian Weimer wrote: >> In the latter case, a >> rather significant fee is needed to turn global inconvenience into a >> local one. > > An arbitrary fee, specifically designed to block someone's entry into > *any* market, is *illegal*, at least in any non-communist country that > I know. Have a look at frequency auctions and how they are used to lock out competition from small players. Many drastic measures are completely legal. > I also don't understand the whole decision circling back, endlessly, to > restrictive policies when nobody actually seems to want IPv6 (assuming > this is still what we're talking about) The majority of those who post on the RIPE mailing lists deeply fear that there is a real demand for IPv6, so much that their routers are overloaded. I don't know why. From fw at deneb.enyo.de Tue May 9 21:58:49 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 09 May 2006 21:58:49 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <1147175317.88439.58.camel@crumpet.netability.ie> (Nick Hilliard's message of "Tue, 09 May 2006 12:48:37 +0100") References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> <1147175317.88439.58.camel@crumpet.netability.ie> Message-ID: <87y7xbug06.fsf@mid.deneb.enyo.de> * Nick Hilliard: > Geoff Huston's talk about this at RIPE was rather interesting. Yes, the > routing table will grow. But that's only part of the problem; a bigger > part of the problem is routing churn. > > Take a look at pages 37 and 38 of: > > http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-bgp-review.pdf Interesting. But -- obviously, it's not a significant problem. Otherwise, there would be peer pressure to fix it. Unlike things like BCP38, it's clear where the unnecessary BGP announcements/withdrawals come from. > You can see that there is a small number of organisations responsible > for massive numbers of updates. I can tell you that If I were supreme > ruler of the universe, these organisations would get a smack on the > face. The number of origin ASNs may be small, but their uplinks and peering partners support this behavior, at least passively. From gih at apnic.net Wed May 10 00:30:53 2006 From: gih at apnic.net (Geoff Huston) Date: Wed, 10 May 2006 08:30:53 +1000 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <44623EE2.1040105@inex.ie> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <6.2.3.4.2.20060509094819.04c936e8@mail.dante.org.uk> <1147167878.88439.17.camel@crumpet.netability.ie> <44607A1F.8010502@necom830.hpcl.titech.ac.jp> <1147175317.88439.58.camel@crumpet.netability.ie> <4460A656.5080108@necom830.hpcl.titech.ac.jp> <1147188126.88439.109.camel@crumpet.netability.ie> <90594687-C136-499F-AFDF-E13AFA1A79D1@icann.org> <44623EE2.1040105@inex.ie> Message-ID: <6.2.0.14.2.20060510082702.03214ac0@kahuna.telstra.net> At 05:28 AM 11/05/2006, Nick Hilliard wrote: >David Conrad wrote: >>How do you believe folks will do traffic engineering? > >This is an interesting point which occurred to me as I was writing my last >email. Outside as-path prepending, I don't have a good answer. And of course there are more specifics to play with as well, as well as AS sets and AS Path poisioning, as well as BGP communities of course. Playing with the routing system to attempt to achieve local optimizations at the expense of the global system is a well understood conventional path here. Geoff From mohta at necom830.hpcl.titech.ac.jp Wed May 10 02:26:04 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 May 2006 09:26:04 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <873bfjvuw7.fsf@mid.deneb.enyo.de> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <873bfjvuw7.fsf@mid.deneb.enyo.de> Message-ID: <4461331C.5070004@necom830.hpcl.titech.ac.jp> Florian Weimer wrote: >>I also don't understand the whole decision circling back, endlessly, to >>restrictive policies when nobody actually seems to want IPv6 (assuming >>this is still what we're talking about) > The majority of those who post on the RIPE mailing lists deeply fear > that there is a real demand for IPv6, so much that their routers are > overloaded. I don't know why. My understanding is that the IPv4 Internet failed to limit the size of DFZ that BGP convergence is taking prphibitively long time for mission critical applications. Moreover, considering bandwidth requirement for the next 5 or 10 years, I don't think backbone routers can have huge routing tables. Masataka Ohta From gert at space.net Wed May 10 09:32:33 2006 From: gert at space.net (Gert Doering) Date: Wed, 10 May 2006 09:32:33 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4461331C.5070004@necom830.hpcl.titech.ac.jp> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <873bfjvuw7.fsf@mid.deneb.enyo.de> <4461331C.5070004@necom830.hpcl.titech.ac.jp> Message-ID: <20060510073233.GN3510@Space.Net> Hi, On Wed, May 10, 2006 at 09:26:04AM +0900, Masataka Ohta wrote: > Moreover, considering bandwidth requirement for the next 5 or > 10 years, I don't think backbone routers can have huge routing > tables. Looking at the architecture of modern routing gear I fail to understand how "forwarding plane speed" relates to "control plane convergence time". That is: whether the forwarding plane has 1 Gbit/s or 1 Tbit/s has no influence on the convergence time, if the control plane is the same. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 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 mohta at necom830.hpcl.titech.ac.jp Wed May 10 09:59:31 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 May 2006 16:59:31 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <20060510073233.GN3510@Space.Net> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <873bfjvuw7.fsf@mid.deneb.enyo.de> <4461331C.5070004@necom830.hpcl.titech.ac.jp> <20060510073233.GN3510@Space.Net> Message-ID: <44619D63.30708@necom830.hpcl.titech.ac.jp> Gert Doering wrote: > Hi, Hi, >>Moreover, considering bandwidth requirement for the next 5 or >>10 years, I don't think backbone routers can have huge routing >>tables. > Looking at the architecture of modern routing gear I fail to understand > how "forwarding plane speed" relates to "control plane convergence time". I'm not saying such a thing. I'm saying that, given a so short duration for routing table lookup, we must make memory for routing table smaller and simpler. Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns. If you try to solve the problem by parallelizm, you must provide tens or hundreds copies of routing table hardware, which consumes a lot of money and power. That is, there are at least two reasons, one is convergence time and the other is look up time, to make backbone routing table small. Masataka Ohta From oliver at bartels.de Wed May 10 10:17:55 2006 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 10 May 2006 10:17:55 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <44619D63.30708@necom830.hpcl.titech.ac.jp> Message-ID: <200605100817.k4A8HNip024574@alpha.bartels.de> On Wed, 10 May 2006 16:59:31 +0900, Masataka Ohta wrote: >I'm saying that, given a so short duration for routing table lookup, >we must make memory for routing table smaller and simpler. Note that, >at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns. Have you ever heared of multi stage lookup using _pipelining_ ? If not, please don't spread FUD. If yes, you should be able to understand why your problem isn't a problem at all. 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 slz at baycix.de Wed May 10 10:50:48 2006 From: slz at baycix.de (Sascha Lenz) Date: Wed, 10 May 2006 10:50:48 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4461331C.5070004@necom830.hpcl.titech.ac.jp> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <873bfjvuw7.fsf@mid.deneb.enyo.de> <4461331C.5070004@necom830.hpcl.titech.ac.jp> Message-ID: <4461A968.3080400@baycix.de> Hi, Masataka Ohta wrote: > Florian Weimer wrote: > >>> I also don't understand the whole decision circling back, endlessly, to >>> restrictive policies when nobody actually seems to want IPv6 (assuming >>> this is still what we're talking about) > >> The majority of those who post on the RIPE mailing lists deeply fear >> that there is a real demand for IPv6, so much that their routers are >> overloaded. I don't know why. > > My understanding is that the IPv4 Internet failed to limit the > size of DFZ that BGP convergence is taking prphibitively long > time for mission critical applications. Based on what? Please elaborate. (I run Corporate Networks with routing table sizes >> Internet DFZ due to /32 announcements and such stuff, no BGP Problems on good setups.) > Moreover, considering bandwidth requirement for the next 5 or > 10 years, I don't think backbone routers can have huge routing > tables. I think i don't need to add anything here, other's already replied to that. It's - sorry - nonsense. But yes, of course, the smaller the table, the better. There is just no agreement on how to achieve a "small table". I say (like others), there is no problem at all, IPv6 Addressing Scheme and additional Multihoming solutions solve all problems on their own. One should rather care for the IPv4 table, it will continue to grow for a decade or so. THAT is the problem which fills your TCAM memories, not the growing IPv6 table. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From mohta at necom830.hpcl.titech.ac.jp Wed May 10 10:53:36 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 May 2006 17:53:36 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605100817.k4A8HNip024574@alpha.bartels.de> References: <200605100817.k4A8HNip024574@alpha.bartels.de> Message-ID: <4461AA10.30803@necom830.hpcl.titech.ac.jp> Oliver Bartels wrote: >>I'm saying that, given a so short duration for routing table lookup, >>we must make memory for routing table smaller and simpler. Note that, >>at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns. > Have you ever heared of multi stage lookup using _pipelining_ ? Yes, of course. Sometimes, pipelining can improve performance by a small constant factor with a small amount of additional hardware. > If yes, you should be able to understand why your problem > isn't a problem at all. Pipelining requires pipeline resigters. If you have too much stages of pipelining, additional amount of pipeline registers kills the benefit. Masataka Ohta From oliver at bartels.de Wed May 10 11:22:29 2006 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 10 May 2006 11:22:29 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4461AA10.30803@necom830.hpcl.titech.ac.jp> Message-ID: <200605100921.k4A9Lvip027725@alpha.bartels.de> On Wed, 10 May 2006 17:53:36 +0900, Masataka Ohta wrote: >Sometimes, pipelining can improve performance by a small constant >factor with a small amount of additional hardware. Sorry: *LOL* With this statement ("small constant factor") you have just proven that you are far away with your routing table lookup theory from any real design. With today's CPU's we are talking of about 20 pipeline stages ... The advances in processing speed in the last ten years are - to a significant degree - based on advanced in multi- level and parallel pipelined CPU architectures (called superscalar processors). >Pipelining requires pipeline resigters. > >If you have too much stages of pipelining, additional amount of >pipeline registers kills the benefit. Sorry, but it seems to me that you are talking about developments you have never been involved in. Pipeline registers are D-Flipflops, build as Master Slave static or e.g. using transfer gates, they are the _basic_ elements of any real IC design. These elements determinate - together with the conditional logic between them - the maximum permitted clock frequency. RAM is never ever faster than a single D-Flipflop using the same technology. Pipeline _stalls_ are a problem with CPU's, if we talk about an conditional instruction and if the branch prediction fails. With IP routing with multistage lookup there simply aren't such conditional instructions. IP routing fits ideal with pipelining, as there is no dependence between different IP packets, the first section of the pipeline decodes the first portion of the IP address, then passes the packet header to the next section responsible for the next portion of the address, at this time the first section starts decoding the next packet etc. If a delay is required, e.g. opening a new RAM page based on the first decode, then the packet header is put in the loop for one cycle. This is the difference between _throughput_ and _latency_ required by a forwarding engine. Thus if constructed the right way, handling reasonably large tables should not be a problem at all. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From mohta at necom830.hpcl.titech.ac.jp Wed May 10 13:44:32 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 May 2006 20:44:32 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4461A968.3080400@baycix.de> References: <20060501154342.GO60910@Space.Net> <87psip2ih4.fsf@mid.deneb.enyo.de> <200605081901.46565.ripe-lst@eirconnect.net> <873bfjvuw7.fsf@mid.deneb.enyo.de> <4461331C.5070004@necom830.hpcl.titech.ac.jp> <4461A968.3080400@baycix.de> Message-ID: <4461D220.3050109@necom830.hpcl.titech.ac.jp> Sascha Lenz wrote: Hi, >>My understanding is that the IPv4 Internet failed to limit the >>size of DFZ that BGP convergence is taking prphibitively long >>time for mission critical applications. > Based on what? I think you can use google with keywords like "BGP convergence". But, I should show you an extreme example. That is, if we have only 1 AS, there is no convergence problem of BGP. > (I run Corporate Networks with routing table sizes >> Internet DFZ due > to /32 announcements and such stuff, no BGP Problems on good setups.) Convergence heavily depends on your policy. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Wed May 10 13:58:19 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 May 2006 20:58:19 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605100921.k4A9Lvip027725@alpha.bartels.de> References: <200605100921.k4A9Lvip027725@alpha.bartels.de> Message-ID: <4461D55B.7060303@necom830.hpcl.titech.ac.jp> Oliver Bartels wrote: > IP routing fits ideal with pipelining, as there is no dependence > between different IP packets, the first section of the > pipeline decodes the first portion of the IP address, then > passes the packet header to the next section responsible > for the next portion of the address, at this time the first > section starts decoding the next packet etc. It merely means that pipeline clock can be as short as memory clock regardless of the number of memory references. However, as I said > Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns. and as there are a lot of shorter packets, we should be able to lookup routing tables for, say, every 1ns or 0.1ns. If we have a 1Tbps port and a pipelined memory with pipeline clock of 200MHz, we need 5 copies of routing tables lnterleaved 5 ways for the port. If we have a router with 10 1Tbps ports, we need 50 copies for the router. So, it's better to have 50 copies of small memory than large memory. Or, can you make already pipelined memory operating at 200MHz 5 or 50 times more faster by 5 or 50 times more stages of pipeline? Note that, if you assume GaAs and/or full custom chips for further performance, please don't forget costs associated for it considering the number of backbone routers. Note also that, if you want to put everything on a chip to increase clock, there is a very hard limit on the routing table size. Masataka Ohta From oliver at bartels.de Wed May 10 14:22:53 2006 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 10 May 2006 14:22:53 +0200 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <4461D55B.7060303@necom830.hpcl.titech.ac.jp> Message-ID: <200605101222.k4ACMLip005967@alpha.bartels.de> On Wed, 10 May 2006 20:58:19 +0900, Masataka Ohta wrote: >> Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns. If we are able to provide 1Tbps at a single port in a single data stream, then for sure we will have the memory. Otherwise we won't have packet buffers and thus the whole discussion is senseless. Today we use DWDM, as we neither have 1 THz optics nor packet buffers ... Until then this here: >Or, can you make already pipelined memory operating at 200MHz >5 or 50 times more faster by 5 or 50 times more stages >of pipeline? http://www.idt.com/products/files/10154/FLYR-NSE-00104.pdf http://www.idt.com/products/files/9838/18MbDDRB4.pdf solves your "problem" which isn't one. Add a piece of DDRAM or RDRAM and make your table as large as you like. Spend anyone on this world a PI, it still will work if build properly ... Technology is not the PI/PA<200 problem. The problem is just a "I DO NOT WANT THIS", "I BELIEVE", "I DON'T LIKE" by certain people. In my personal view the main reason for this is a "loss of face" conflict by those who claim we can't build routers which handle large tables. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From mohta at necom830.hpcl.titech.ac.jp Wed May 10 14:52:32 2006 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 May 2006 21:52:32 +0900 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605101222.k4ACMLip005967@alpha.bartels.de> References: <200605101222.k4ACMLip005967@alpha.bartels.de> Message-ID: <4461E210.7090301@necom830.hpcl.titech.ac.jp> Oliver Bartels wrote: > If we are able to provide 1Tbps at a single port in a single data > stream, then for sure we will have the memory. Of course. And, it's doable even with packet buffers with realistic size and packet loss possibility. Otherwise, parallel datapath requires so much money and power that those for routing table is negligible from the beginning. > Today we use DWDM, That's fine. The point is to switch all the wave lengths at once, just like EDFAs amplify all the wave lengths at once. >>Or, can you make already pipelined memory operating at 200MHz >>5 or 50 times more faster by 5 or 50 times more stages >>of pipeline? > > > http://www.idt.com/products/files/10154/FLYR-NSE-00104.pdf > http://www.idt.com/products/files/9838/18MbDDRB4.pdf > > solves your "problem" which isn't one. It's merely 1.25 times faster than my example that it is no solution. > The problem is just a "I DO NOT WANT THIS", "I BELIEVE", > "I DON'T LIKE" by certain people. The problem is merely that you don't know the capability of combined photonic/electric circuit. Masataka Ohta From filiz at ripe.net Wed May 10 15:00:50 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 10 May 2006 15:00:50 +0200 Subject: [address-policy-wg] 2005-02 New Draft Document Published (IP Assignments for anycasting DNS) Message-ID: <20060510130050.D9AF52F599@herring.ripe.net> PDP Number: 2005-02 IP Assignments for anycasting DNS Dear Colleagues We have published two draft documents for the proposal described in 2005-02. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2005-2.html and the draft documents at: http://ripe.net/ripe/draft-documents/2005-02-draft.html http://ripe.net/ripe/draft-documents/2005-02-v6-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 7 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Wed May 10 15:05:03 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 10 May 2006 15:05:03 +0200 Subject: [address-policy-wg] 2005-12 New Draft Document Published (4-Byte AS Number Policy) Message-ID: <20060510130503.84DF42F599@herring.ripe.net> PDP Number: 2005-12 4-Byte AS Number Policy Dear Colleagues We have published a draft document for the proposal described in 2005-12. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2005-12.html and the draft document at: http://ripe.net/ripe/draft-documents/2005-12-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 7 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From fw at deneb.enyo.de Thu May 11 20:53:11 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 11 May 2006 20:53:11 +0200 Subject: [address-policy-wg] The flexibility of IPv4 routing Message-ID: <87u07wjsvc.fsf@mid.deneb.enyo.de> According to this article: Connexion uses BGP and the Internet routing table to implement IP mobility: | So how did they solve it? They assigned a /24 (256 globally visible IP | addresses) to each plane. They announce that network from the origin | site (in my case, Europe since I took off from Germany). When the | plane is between the two satellites and in view of each, it is | programmed to re-connect to the North American satellite. So traffic | is always getting to the ground the fastest it can, minimizing | latency. Certainly a cool hack, although I'm not sure if the leak of the /24s to the global routing table is intended. It's not necessary to minimize latency. Perhaps Connexion does not operate an intercontinental AS, though -- which would mean that two planes using different head stations could not communicate with each other at the IP layer. Anyway, I wish you guys could bring this kind of flexibility to the IPv6 world. 8-) From jeroen at unfix.org Thu May 11 21:51:26 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 May 2006 21:51:26 +0200 Subject: [address-policy-wg] The flexibility of IPv4 routing In-Reply-To: <87u07wjsvc.fsf@mid.deneb.enyo.de> References: <87u07wjsvc.fsf@mid.deneb.enyo.de> Message-ID: <1147377086.21495.33.camel@firenze.zurich.ibm.com> On Thu, 2006-05-11 at 20:53 +0200, Florian Weimer wrote: [ .. story about routing .. ] > Anyway, I wish you guys could bring this kind of flexibility to the > IPv6 world. 8-) Too bad a lot of people seem to mix up Address Space with Routing Slots. The RIR's are for the first, not the latter (yet). RIPE and all the other RIR's assign/allocate _Address Space_ to their clients based on their need. How/if that _Address Space_ is actually _Routed_ is not of any concern to the RIR's, that is the task of the one who received the _Address Space_ to make it be like they require it. If you want to make organisations use less routing slots then let them pay for it (business opportunity) and/or filter them out. Unless in the RIPE NCC case RIPE membership demands from RIPE NCC that they start acting as the ITU-TT does. But that is nearly impossible fortunately unless some big ISP's put their hands together and force all you little folks out of the routing tables. (Which will result most likely that small ISP's team up and we get a very cool split internet, but at least with globally unique address space, pfew ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From fw at deneb.enyo.de Thu May 11 22:10:25 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 11 May 2006 22:10:25 +0200 Subject: [address-policy-wg] The flexibility of IPv4 routing In-Reply-To: <1147377086.21495.33.camel@firenze.zurich.ibm.com> (Jeroen Massar's message of "Thu, 11 May 2006 21:51:26 +0200") References: <87u07wjsvc.fsf@mid.deneb.enyo.de> <1147377086.21495.33.camel@firenze.zurich.ibm.com> Message-ID: <87lkt8iaq6.fsf@mid.deneb.enyo.de> * Jeroen Massar: > On Thu, 2006-05-11 at 20:53 +0200, Florian Weimer wrote: > [ .. story about routing .. ] >> Anyway, I wish you guys could bring this kind of flexibility to the >> IPv6 world. 8-) > > Too bad a lot of people seem to mix up > Address Space > with > Routing Slots. > > The RIR's are for the first, not the latter (yet). For IPv4, there are prefix filtering guidelines, and the RIR assignments are compatible with them. Otherwise, you'd end up with PI space (or even provider allocations) which are not globally reachable to a significant degree. So the two concepts are not entirely separated -- and one stated goal for IPv6 is to mesh them together ("better aggregation"). > RIPE and all the other RIR's assign/allocate _Address Space_ to their > clients based on their need. How/if that _Address Space_ is actually > _Routed_ is not of any concern to the RIR's, that is the task of the one > who received the _Address Space_ to make it be like they require it. I wonder how one would get along with a /23 PI in 62/8. 8-> > But that is nearly impossible fortunately unless some big ISP's put > their hands together and force all you little folks out of the > routing tables. See, in the IPv6 world as envisioned by you (and others, of course), these little folks are called "waste" -- see <439442BE.2010509 at unfix.org>. From nick at inex.ie Fri May 12 13:46:38 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 12 May 2006 12:46:38 +0100 Subject: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive In-Reply-To: <200605101222.k4ACMLip005967@alpha.bartels.de> References: <200605101222.k4ACMLip005967@alpha.bartels.de> Message-ID: <1147434398.22840.14.camel@pancake.netability.ie> [cc: line trimmed] > The problem is just a "I DO NOT WANT THIS", "I BELIEVE", > "I DON'T LIKE" by certain people. This opinion was based on the memory of a time when routing table size threatened to exceed the maximum capacity of the routers of the day, and would have exceeded this capacity without the introduction of CIDR and strong aggregation. Once bitten, twice shy. So we are left with a legacy that strong aggregation is good policy, and our addressing allocation requirements are substantially based on this policy. We don't have such a problem with routing table size these days, but the engineering point was made and is still valid. Nick From john.crain at icann.org Sat May 13 14:29:56 2006 From: john.crain at icann.org (John L Crain) Date: Sat, 13 May 2006 05:29:56 -0700 Subject: [address-policy-wg] Proposal 2005-2 comment Message-ID: <4465D144.3090309@icann.org> Just one brief comment in that section A.2. needs to be updated. There are currently five RIR's since the addition of AfriNIC. Here is the section: A.2. Policy Harmonisation Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLD name servers as critical infrastructure. Extracts from these policies can be found in Appendices I through III. John From e.byaru at gmail.com Mon May 22 12:46:17 2006 From: e.byaru at gmail.com (Ernest B. M ) Date: Mon, 22 May 2006 12:46:17 +0200 Subject: [address-policy-wg] 41/8 announcement Message-ID: <44719679.3030707@gmail.com> Apologies for duplicates] Dear Colleagues, Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. Reachability tests can be conducted with 41.223.252.1 as a target IP address. Kind Regards, Ernest, AfriNIC. From nick at inex.ie Mon May 22 13:05:25 2006 From: nick at inex.ie (Nick Hilliard) Date: Mon, 22 May 2006 12:05:25 +0100 Subject: [address-policy-wg] 41/8 announcement In-Reply-To: <44719679.3030707@gmail.com> References: <44719679.3030707@gmail.com> Message-ID: <1148295925.30021.37.camel@pancake.netability.ie> Ernest, The rest of the world probably won't doubt that this is a legitimate announcement, but could I suggest that future messages of this form: 1. originate from an "@afrinic.net" email address, 2. are digitally signed with either an appropriate X.509 certificate or else a PGP key which is also signed by another RIR or two, and 3. attach the sender's full name and contact details. It takes very little for some 3l33t h4x0r to forge emails like this, and while the consequences are not in any way terminal, it would mean a lot of egg on a lot of peoples' faces. Nick On Mon, 2006-05-22 at 12:46 +0200, Ernest B. M wrote: > Apologies for duplicates] > > Dear Colleagues, > > Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from > the IANA in April 2005. > > You may wish to adjust any filters you have in place accordingly. > > Reachability tests can be conducted with 41.223.252.1 as a target IP > address. > > Kind Regards, > > Ernest, > AfriNIC. -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | INOC-DBA: 2128*NH7 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From catherine at ripe.net Thu May 25 22:05:40 2006 From: catherine at ripe.net (Catherine Carr) Date: Thu, 25 May 2006 22:05:40 +0200 Subject: [address-policy-wg] Draft Minutes: RIPE 52 Address Policy WG session Message-ID: <44760E14.1030105@ripe.net> Dear Colleagues Draft Minutes from the Address Policy Working Group session at RIPE 52 can be found at: http://www.ripe.net/ripe/wg/address-policy/r52-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, archives of the webcast can be found at: mms://webcast.ripe.net/ripe-52/ap.wmv http://www.ripe.net/ripe/meetings/ripe-52/webcast-files/ap.wmv http://www.ripe.net/ripe/meetings/ripe-52/podcasts/ap.mp3 There is also a copy of the Jabber/IRC session available at: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/ap.txt Kind regards, -- Catherine Carr RIPE NCC IP Resource Analyst From jscribner at asienterprises.com Sat May 27 18:42:31 2006 From: jscribner at asienterprises.com (Jeff Scribner) Date: Sat, 27 May 2006 12:42:31 -0400 Subject: [address-policy-wg] Contact e-mail Address Requirements at RIPE et al. Message-ID: <0b4a01c681ac$8e2e6100$6501a8c0@PC236745275100> BlankGentlemen: >From time to time our security department has had to expend considerable effort to find working e-mail addresses for organizations responsible for IP addresses controlled by RIPE. In some instances, no working address could be found or a time consuming visit to a web site form was required for contact. Every organization controlling an IP address with a listing at RIPE should be required to list at least one working contact e-mail address where notifications of abuse emanating from that IP address can be sent. RIPE should be allocated money and personnel to enforce this rule. In addition, all persons and organizations assigned an IP address should be required to take vigorous action to prevent abusive messages from originating at that IP address. RIPE should be allocated money and personnel to enforce this rule and, if necessary, to shut down any IP address or group of addresses having excessive instances of abuse. This policy should also be followed by ARIN, APNIC, AFRNIC, LACNIC, etc. and would result in less spam and abuse and more rapid correction thereof. Regards, Jeffrey L. Scribner ASI Enterprises, Inc. 9660 Falls of the Neuse Road Suite 138-123 Raleigh, North Carolina 27615-2473 Telephone 919-844-6404 Cell 919-264-6404 Fax Server 501-643-9064 jscribner at asienterprises.com http://www.asienterprises.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Blank Bkgrd.gif Type: image/gif Size: 145 bytes Desc: not available URL: From Mike.Simkins at sungard.com Mon May 29 12:03:30 2006 From: Mike.Simkins at sungard.com (Mike.Simkins at sungard.com) Date: Mon, 29 May 2006 06:03:30 -0400 Subject: [address-policy-wg] Mike Simkins is out of the office. Message-ID: I will be out of the office starting 26/05/2006 and will not return until 30/05/2006. I will respond to your message when I return. If you have an urgent issue - please call the IOC at 1-800-41-1181 where someone will be able to help you immediately From filiz at ripe.net Tue May 30 16:52:10 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 30 May 2006 16:52:10 +0200 Subject: [address-policy-wg] 2005-01 Policy Proposal Withdrawn (HD-ratio Proposal) Message-ID: <20060530145210.1B7A32F596@herring.ripe.net> PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The proposal 2005-01 has been withdrawn. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer From feedback at ripe.net Wed May 31 12:14:24 2006 From: feedback at ripe.net (Paul Rendek) Date: Wed, 31 May 2006 12:14:24 +0200 Subject: [address-policy-wg] RIPE 52 Report available Message-ID: <447D6C80.7000207@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE 52 Meeting Report is now online at: http://www.ripe.net/ripe/meetings/ripe-52/report.html Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From leo at ripe.net Wed May 31 14:36:03 2006 From: leo at ripe.net (leo vegoda) Date: Wed, 31 May 2006 14:36:03 +0200 Subject: [address-policy-wg] New ROUTE-SET and RIPE document: Address Space Managed by the RIPE NCC Message-ID: <447D8DB3.4010102@ripe.net> [Apologies for duplicates] Dear Colleagues, We have updated the RIPE document "Address Space Managed by the RIPE NCC" to include references to a ROUTE-SET object describing the address space allocated to the RIPE NCC by the IANA. The new version is ripe-380 and can be found on our web site at: https://www.ripe.net/docs/ripe-ncc-managed-address-space.html We hope the ROUTE-SET object is useful. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC From filiz at ripe.net Wed May 31 14:37:43 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 31 May 2006 14:37:43 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 28 June 2006 (Provider Independent (PI) IPv6 Assignments for End User Organisations) Message-ID: <20060531123743.51FBF2F592@herring.ripe.net> PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues The Discussion Period for the proposal 2006-01 has been extended until 28 June 2006 as the proposal text has been edited. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Wed May 31 14:43:05 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 31 May 2006 14:43:05 +0200 Subject: [address-policy-wg] 2006-02 New Policy Proposal (IPv6 Address Allocation and Assignment Policy) Message-ID: <20060531124305.C2B972F592@herring.ripe.net> PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues A proposed change to RIPE Document ripe-267 is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review this proposal and send your comments to before 28 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer