From randy at psg.com Wed Jun 1 08:37:32 2011 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jun 2011 09:37:32 +0300 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <4DE4C434.4070806@linx.net> <603FB174-29EA-42EE-827C-984AA59863B0@steffann.nl> Message-ID: > One guy makes some gunpowder. Another a shell casing. A third puts > some of the former in the latter. A fourth makes a chamber. A fifth > makes a coil. .... Eventually there's a gun. For good or bad. let's outlaw metal. it will also solve the knife problem. guns can not be used for good. knives can be used for good and bad, and are mostly used for good. perhaps we should treat knives and guns differently. and, perhaps, the root problem lies in we silly humans and intent. which was the point of my preso, ripe should signal as constructive intent as reasonably possible. randy From fweimer at bfk.de Wed Jun 1 10:17:13 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 01 Jun 2011 08:17:13 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DE49F8D.7010900@linx.net> (Malcolm Hutty's message of "Tue, 31 May 2011 08:58:05 +0100") References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> Message-ID: <827h96neye.fsf@mid.bfk.de> * Malcolm Hutty: > Sarkozy has clearly described the political imperative. 2008-08 > provides (some of) the tools to carry it out. The difference between 2008-08 and the current situation is that once 2008-08 is widely implemented, withdrawing someone's Internet access at the BGP level requires some sort of court or law enforcement action (the latter under public order legislation). Right now, nearly anybody can play with announcements, with potentially global impact. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From randy at psg.com Wed Jun 1 11:02:25 2011 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jun 2011 12:02:25 +0300 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <827h96neye.fsf@mid.bfk.de> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> Message-ID: > The difference between 2008-08 and the current situation is that once > 2008-08 is widely implemented, withdrawing someone's Internet access > at the BGP level requires some sort of court or law enforcement action > (the latter under public order legislation). Right now, nearly > anybody can play with announcements, with potentially global impact. s/can/does/. happens daily. though almost all are accidents. randy From ronak at nav6.org Wed Jun 1 12:40:36 2011 From: ronak at nav6.org (Ronak Banka) Date: Wed, 01 Jun 2011 18:40:36 +0800 Subject: [address-policy-wg] Regarding fragmentation and aggregation of IPv4 address space Message-ID: <11ffa707411ab94dfe2224479cf925da@mail.nav6.org> Respected Team members, Myself Ronak banka currently doing my internship at NAv6, USM Malaysia under the supervision of Dr. Raja Kumar. I am presently conducting a Research on estimating the fragmentation and aggregation of IPv6 address space by comparing it with fragmentation and aggregation of IPv4 address space under RIPE, so I was in search of data regarding reasons for fragmentation of the address space and % contribution of those different reasons to fragmentation. If you could help me in this matter by providing any important details I would be thankful to you. Waiting for your reply in anticipation. -- Ronak Banka Internship student National Advance IPv6 Centre (NAv6) USM Malaysia contact: +60143064063 From rogerj at gmail.com Wed Jun 1 19:50:39 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Wed, 1 Jun 2011 19:50:39 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110531085727.GW45955@Space.Net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> Message-ID: On Tue, May 31, 2011 at 10:57 AM, Gert Doering wrote: > I just hope that the community will eventually agree on something. > > (And no, as far as things go, it does not look like the community will > agree on anything here - one side sees real problems in the addressing > hijack realm and considers that important to have spend a number of years > in building a technical solution to that, while the other side sees that > as a minor nuisance compared to the percieved dangers of a government > doing bad things. ?How can you ever agree?) How can the "risk" of the government being minimized or limited? Or maybe being build in such a way that its not easy/possible for government to do damange? (quite impossible task since the government pretty much can do whatever they want when they are in power... and the power are giving to them by the people in most countries) ... and yes, the problem are there on the hijack side, don't think many disagree on that.. -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From sander at steffann.nl Wed Jun 1 23:04:05 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 1 Jun 2011 23:04:05 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> Message-ID: <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> Hi, > How can the "risk" of the government being minimized or limited? Or maybe > being build in such a way that its not easy/possible for government to do > damange? (quite impossible task since the government pretty much can > do whatever they want when they are in power... and the power are giving > to them by the people in most countries) My personal opinion is that the best way to stop any abuse in the future is to leave open the possibility of reverting 2008-08 in the future when such abuse becomes a reality. And we already have that possibility already: a proposal to withdraw or change a policy will always be handled according to the PDP (Policy Development Process). If things go really bad we can change the policy, the NCC can shut down the CA and all certificates can be withdrawn. The end result will be the same internet as we have today: one without (valid) certificates for resources. As long as the certificate system doesn't get abused we get to enjoy the benefits... It will take some time (it can be done in about 10 weeks) to do this should the need ever occur, but as this is a last-resort exit strategy I think this is acceptable. Is this an acceptable solution for everybody? > ... and yes, the problem are there on the hijack side, don't think many > disagree on that.. And I would really like to get a solution for this problem, because I am much more afraid of IPv4 address space hijacks once the NCC IPv4 pool runs out... Thanks, Sander Explicitly not speaking as WG chair! From lists-ripe at c4inet.net Wed Jun 1 23:11:16 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 1 Jun 2011 21:11:16 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> Message-ID: <20110601211116.GA16343@cilantro.c4inet.net> On Wed, Jun 01, 2011 at 12:02:25PM +0300, Randy Bush wrote: >> anybody can play with announcements, with potentially global impact. > >s/can/does/. happens daily. though almost all are accidents. So, a few accidents with rarely any noticeable impact (At least I don't notice any major connectivity issues every day) Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access. You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix advertisement... rgds, s. From lists-ripe at c4inet.net Wed Jun 1 23:21:40 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 1 Jun 2011 21:21:40 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> References: <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> Message-ID: <20110601212140.GB16343@cilantro.c4inet.net> On Wed, Jun 01, 2011 at 11:04:05PM +0200, Sander Steffann wrote: > It will take some time (it can be done in about 10 weeks) to do > this should the need ever occur, but as this is a last-resort exit > strategy I think this is acceptable. Is this an acceptable solution > for everybody? the absolute minimum I would accept is a sunset clause (ie the policy will run to a fixed date (say 2 years away) and will not be in force unless explicitly prorogued thereafter) > And I would really like to get a solution for this problem, because > I am much more afraid of IPv4 address space hijacks once the NCC > IPv4 pool runs out... In my book that is an argument against it. Anything that prolongs the IPv4 pain, especially at the cost of having a censorship infrastructure imposed on *all* internet routing (not just v4) can't be good... rgds, s. From sander at steffann.nl Wed Jun 1 23:29:22 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 1 Jun 2011 23:29:22 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110601211116.GA16343@cilantro.c4inet.net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> Message-ID: <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> Hi, > So, a few accidents with rarely any noticeable impact (At least I don't notice any major connectivity issues every day) That you haven't noticed any impact doesn't mean it does not happen. That is a rather selfish attitude... Think of what will happen when someone else starts announcing *your* prefix. > Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access. Well, I can't deny this. Governments regulate. That is their job... If you don't agree with what they choose to do I think voting for a different party is a good way to start. > You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix advertisement... Fat-fingering, intentionally mis-announcing (hijacking address space, announcing address space of a customer after they left, ...), etc. But let's stick to facts instead of belief... :-) Sander From sander at steffann.nl Wed Jun 1 23:33:35 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 1 Jun 2011 23:33:35 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110601212140.GB16343@cilantro.c4inet.net> References: <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> <20110601212140.GB16343@cilantro.c4inet.net> Message-ID: <6B43A050-AD21-4F54-A9DB-0D4D4EEEDC7C@steffann.nl> > In my book that is an argument against it. Anything that prolongs the IPv4 pain, especially at the cost of having a censorship infrastructure imposed on *all* internet routing (not just v4) can't be good... Sorry, you lost me there... I was talking about preventing IPv4 pain. IPv4 will still be important for many years. I wish there was enough IPv6 deployed to avoid this, but there isn't. A year from now the NCC won't have any new IPv4 addresses to hand out, while the majority of communication on the internet will still use IPv4. Our task is to keep the internet running as smoothly as possible. (Unfortunately) this still includes IPv4. Sander From drc at virtualized.org Wed Jun 1 23:49:04 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 1 Jun 2011 11:49:04 -1000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110601211116.GA16343@cilantro.c4inet.net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> Message-ID: Sascha, On Jun 1, 2011, at 11:11 AM, Sascha Luck wrote: > On Wed, Jun 01, 2011 at 12:02:25PM +0300, Randy Bush wrote: >>> anybody can play with announcements, with potentially global impact. >> >> s/can/does/. happens daily. though almost all are accidents. > > So, a few accidents with rarely any noticeable impact (At least I don't notice any major connectivity issues every day) This could either mean your prefix isn't getting hijacked (others are) or the hijacking is being done in such a way that you don't notice. It doesn't mean that hijacking doesn't occur and isn't a significant problem. RPKI provides an infrastructure that would allow for tools to be built that could address this problem. > Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access. Not sure about daily, but yes, this is a problem. I have absolutely no doubt that if a tool exists that allows politicians to claim they're doing something to solve "a problem", they'll use it. > You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix > advertisement... It really does have something to do with preventing fat-fingering (or perhaps more accurately, reduces the impact of that fat-fingering). The main arguments I've heard (some cynical, some not) for RPKI have been: - allow for SIDR deployment - allow for the RIRs to enforce their policies - allow for the RIRs to have a viable business model after IPv4 is exhausted - allow the existing address hierarchy model to be enforced (disallow 'alternative address registries') Other folks might have heard other arguments. Regards, -drc From millnert at gmail.com Thu Jun 2 00:01:01 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 1 Jun 2011 18:01:01 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> Message-ID: Hi, On Wed, Jun 1, 2011 at 5:04 PM, Sander Steffann wrote: > Hi, > >> How can the "risk" of the government being minimized or limited? Or maybe >> being build in such a way that its not easy/possible for government to do >> damange? (quite impossible task since the government pretty much can >> do whatever they want when they are in power... and the power are giving >> to them by the people in most countries) > > My personal opinion is that the best way to stop any abuse in the future is to leave open the possibility of reverting 2008-08 in the future when such abuse becomes a reality. And we already have that possibility already: a proposal to withdraw or change a policy will always be handled according to the PDP (Policy Development Process). If things go really bad we can change the policy, the NCC can shut down the CA and all certificates can be withdrawn. The end result will be the same internet as we have today: one without (valid) certificates for resources. As long as the certificate system doesn't get abused we get to enjoy the benefits... > It will take some time (it can be done in about 10 weeks) to do this should the need ever occur, but as this is a last-resort exit strategy I think this is acceptable. Is this an acceptable solution for everybody? No. First and foremost I do not want a hierarchical, centralized routing control infrastructure on the Internet. I think the bad outweigh the good by far. I do not oppose a fully decentralized secure/trusted routing, but by design, my peers should provide me this information. No single authority should be allowed to speak on behalf of others, unless *they* grant that power to it. And for this, the core issue to solve is resource holder/ownership identification -- which seems to me to contradict the current RIR model. And this tells me that we have a much, much larger problem at our hands for the future, made blatantly evident by these debates. By extension, this means that the RIPE NCC cannot run a trust anchor in the intended way, and there should be no deployed technology in routers supporting a trust anchor such as the proposals today in the first place, since it invites abuse and censorship even if the RIPE NCC itself does not run one, because someone else could. If, for argument's sake, doing the right thing is impossible, and consensus really is that doing something is better than doing nothing in this matter, the RIPE NCC should have very clearly defined (but not limited-to) set of rules for when the hierarchical, centralized routing control infrastructure self-destructs *up front*, such that it would be pointless to attempt to abuse it in this way. This suggests that the "self-regulation" we perform, overrules law, since abusive laws is what we fear. Additionally, since the attack will be on the integrity of registry itself, this essentially means we need a complete fail-over registry... If you think this can work, then this may be a useful approach. :) >> ... and yes, the problem are there on the hijack side, don't think many >> disagree on that.. > > And I would really like to get a solution for this problem, because I am much more afraid of IPv4 address space hijacks once the NCC IPv4 pool runs out... I'm not afraid at all. It's quite easy to detect incorrect origins today, not sure why that would change. Run-out suggests further incentives to ramp up the traditional IRR filtering. (I'm not suggesting IRR filtering is the optimal solution to securing routing on the Internet, but that should be pretty obvious given what I wrote above.) Increased censorship is a clear and present danger. It's our duty to confront this danger wherever we can. Best, Martin From lists-ripe at c4inet.net Thu Jun 2 00:04:12 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 1 Jun 2011 22:04:12 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> References: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> Message-ID: <20110601220411.GC16343@cilantro.c4inet.net> On Wed, Jun 01, 2011 at 11:29:22PM +0200, Sander Steffann wrote: >Hi, > > That you haven't noticed any impact doesn't mean it does not happen. > That is a rather selfish attitude... Think of what will happen when > someone else starts announcing *your* prefix. That has already happened (due to a misunderstanding). The world didn't end. Didn't end when .pk announced youtube either. The internet has survived for 40 years without such an infrastructure , in fact probably *because* there was no such infrastructure. > Well, I can't deny this. Governments regulate. That is their job... > If you don't agree with what they choose to do I think voting for a > different party is a good way to start. LOL, tell that to the people in Syria, Belorus, Iran... Once upon a time I, too, was naive enough to think the "other party" isn't being paid by the exact same people... cheers, s. From lists-ripe at c4inet.net Thu Jun 2 00:11:10 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 1 Jun 2011 22:11:10 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> Message-ID: <20110601221110.GD16343@cilantro.c4inet.net> On Wed, Jun 01, 2011 at 11:49:04AM -1000, David Conrad wrote: >- allow for SIDR deployment >- allow for the RIRs to enforce their policies >- allow for the RIRs to have a viable business model after IPv4 is exhausted >- allow the existing address hierarchy model to be enforced (disallow 'alternative address registries') Well, probably time someone actually said it. It makes more sense than some global government conspiracy, however: the fact that NCC had a happy-clappy "very cordial" meeting with SOCA (yes, the Internet is Serious and Organised Crime in the UK) makes me wonder. rgds, s. From randy at psg.com Thu Jun 2 10:11:00 2011 From: randy at psg.com (Randy Bush) Date: Thu, 02 Jun 2011 11:11:00 +0300 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> Message-ID: > How can the "risk" of the government being minimized or limited? i think the belgians are the only ones to successfully deal with this problem at the root. if society allows people who have guns, bombs, or a lot of trademark lawyers, playing junior lawyer with silly policies is pretty irrelevant. as we are seeing time and time again in egypt, the united states, the uk, france, ... randy From randy at psg.com Thu Jun 2 10:12:37 2011 From: randy at psg.com (Randy Bush) Date: Thu, 02 Jun 2011 11:12:37 +0300 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> Message-ID: > First and foremost I do not want a hierarchical, centralized routing > control infrastructure on the Internet. nice words, but let's see the reality. when will you be closing the IRR? and how will you decentralize address allocation so the hierarchy can not revoke your addresses? randy From rogerj at gmail.com Thu Jun 2 10:28:19 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 2 Jun 2011 10:28:19 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> Message-ID: I've lately been more and more convinced that the basic idea, technical, is good. But it miss on two quite important points so I can not support it in its current form as stated earlier. However, more comments inline: On Wed, Jun 1, 2011 at 11:49 PM, David Conrad wrote: > Sascha, > On Jun 1, 2011, at 11:11 AM, Sascha Luck wrote: >> Yet, also daily, I read about an attempt by $someone to censor, cut off or >> otherwise regulate somebody else's internet access. > > Not sure about daily, but yes, this is a problem. ?I have absolutely no doubt > that if a tool exists that allows politicians to claim they're doing something > to solve "a problem", they'll use it. I am quite sure this is one of the bigger issue with this policy. How can it be made clear for everyone that this is not a tool for that area? It should not be any opening for it being used for that really. (... and it's not that long ago an entire /16 or something I think, was used solely by a company to host every form of malware, abuse source, control centers for trojans etc... this tool would be excellent for removing That from Internet as it really was hurting almost everyone. But not sure it would be the Right tool for it.....) >> You have to excuse me for not quite believing that this attempt to impose >> a centralised structure upon internet routing has anything to do with >> preventing someone from fat-fingering a prefix >> advertisement... > > It really does have something to do with preventing fat-fingering (or perhaps > more accurately, reduces the impact of that fat-fingering). ?The main > arguments I've heard (some cynical, some not) for RPKI have been: > > - allow for SIDR deployment > - allow for the RIRs to enforce their policies > - allow for the RIRs to have a viable business model after IPv4 is > exhausted > - allow the existing address hierarchy model to be enforced (disallow > 'alternative address registries') Excellent, this is probably the "other" side of the problem with this policy, the more technical side that we should spend most of our time solving:) I do not believe it is a good idea at all to start building one central that can control who can, who can not be seen on Internet. What happen when the people running this registry/central database are being fat-fingered? It did happen not that long ago with .se, they went offline even with lost of procedures and routines in place to make sure it never happen. It's not possible to guard against human mistakes really, atleast very very difficult. I rather see someone at an ISP make a mistake once in a while, even often than even make it possible for someone central make a fat-fingered mistake. The difference and the effect on _everyone_ are order of magnitude different. I think both issues I see, the government one, and the technical one, can be solved but this policy do not address these two issues good enough. Both Martin Miller and Sascha Luck have in their last emails listed more reasons why this policy is not good enough on the technical side, that is, central control on what can and can not be used on Internet. Especial Martin's mail on the hierarchical control... -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From gert at space.net Thu Jun 2 11:20:50 2011 From: gert at space.net (Gert Doering) Date: Thu, 2 Jun 2011 11:20:50 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110601221110.GD16343@cilantro.c4inet.net> References: <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> <20110601221110.GD16343@cilantro.c4inet.net> Message-ID: <20110602092050.GG45955@Space.Net> Hi, On Wed, Jun 01, 2011 at 10:11:10PM +0000, Sascha Luck wrote: > Well, probably time someone actually said it. It makes more sense > than some global government conspiracy, however: > the fact that NCC had a happy-clappy "very cordial" meeting with > SOCA (yes, the Internet is Serious and Organised Crime in the UK) > makes me wonder. One of the tasks the NCC is mandated by the NCC members to do is "make sure that the governments of our region understands how the Internet works, how Internet self-regulation works, and that it's better to leave us alone". This is why those good people attend ITU meetings, meet with LEAs, etc. - to make sure those "political accidents" that everybody is afraid of do *not* happen. There's serious dangers here, like "why should a private entity be allowed to rule address governance in Europe? The european commission and the national governments are much better suited to do that!" - and the NCC works togethe with these folks to make them see that our way *works* and we need no extra regulation... Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From heldal at eml.cc Thu Jun 2 11:26:21 2011 From: heldal at eml.cc (Per Heldal) Date: Thu, 02 Jun 2011 11:26:21 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <20110531080640.GT45955@Space.Net> <4DE4AA28.4000505@linx.net> <20110531085727.GW45955@Space.Net> <15E1C4D9-D219-4286-B117-02033B5E53BD@steffann.nl> Message-ID: <4DE7573D.1040202@eml.cc> On 02/06/11 00:01, Martin Millnert wrote: > > Increased censorship is a clear and present danger. It's our duty to > confront this danger wherever we can. I agree, but don't forget that trust goes both ways. In that sense it is essential to note that the RIR's registrants are not isolated to one particular jurisdiction. Your worry would be valid for any national IP resource registry, but not for any of today's regional registries. Several countries already operate a centrally managed list of prefixes which all ISP's who operate within the country are required to block (in practise peer with a BGP-box and null-route any pfx it announces). Yet more governments are considering/planning such activities. Lawyers and politicians involved with such schemes may initially be excited by the idea of using centralised/international registers, but quickly realise that an attempt to corner the operator of a central registry may destroy its authority outside the jurisdiction within which the particular registry operates. Not only would it undermine their filtering/censoring efforts, but it would also ruin the technical/operational value of the registry's certificates. The big threat to freedom of speech through censorship would come via global or regional treaties in which case all bets are off. The existence of a central registry might simplify censoring efforts initially, while the absence of such is no long term guarantee against it. //per From malcolm at linx.net Thu Jun 2 11:52:04 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Thu, 02 Jun 2011 10:52:04 +0100 Subject: [address-policy-wg] Has 2008-08 passed? If not, what now? In-Reply-To: <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> Message-ID: <4DE75D44.6070700@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somewhat inevitably, starting a discussion about how 2008-08 would be received by those with legal power (not just governments), led us if not off-topic then at least into a broad discussion that confuses the real issue before us. I believe the question that this WG has to answer is "Do we believe that, on balance, adopting this policy will do more harm than good?". I suggested that adopting and deploying 2008-08 might over time result in more route hijacking rather than less, when you include the risk of hijacks conducted under legal compulsion. If I may summarise the answers I've heard by way of caricature, they are: - - "you're imagining things you silly conspiracy theorist" - - "if you don't like what the government does vote for someone else" - - "this will help prevent hijack attempts by criminals, which is our responsibility; preventing hijack attempts by lawyers is not our responsibility". (There was also "we've been working on this for years and spent loads of money, we can't stop now" and "do you have a better idea?", but neither of these address the question of whether this does more harm than good). Like most people, I don't want to continue reciting the arguments indefinitely. Nonetheless, I should say clearly that I don't find that any of the arguments that fall within the categories caricatured above make me feel any more comfortable that 2008-08 is a good and necessary proposal or that the world will be a better place if it is adopted. It seems that a number of other people also believe 2008-08 is negative on balance. Presumably the WG chairs will therefore conclude there is no consensus in its favour. I remain interested to hear the answer to my question about what the RIPE NCC intends to do if there is no consensus to approve 2008-08. Malcolm. - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3nXUQACgkQJiK3ugcyKhT7vwCgu6AnSQzUUcvMV9gw8OYNLEog Fi8AoN1miGAlveZObNsUkFGlPcPNURD8 =SI5N -----END PGP SIGNATURE----- From sander at steffann.nl Thu Jun 2 12:40:03 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 2 Jun 2011 12:40:03 +0200 Subject: [address-policy-wg] Has 2008-08 passed? If not, what now? In-Reply-To: <4DE75D44.6070700@linx.net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> <4DE75D44.6070700@linx.net> Message-ID: <602EF4B3-801A-4130-975F-F3898F0C8F31@steffann.nl> Hi Malcolm, > It seems that a number of other people also believe 2008-08 is negative > on balance. Presumably the WG chairs will therefore conclude there is no > consensus in its favour. Correct. Based on the current input we can definitely not declare consensus. > I remain interested to hear the answer to my question about what the > RIPE NCC intends to do if there is no consensus to approve 2008-08. So am I. Sander From jim at rfc1035.com Thu Jun 2 13:05:13 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 2 Jun 2011 12:05:13 +0100 Subject: [address-policy-wg] RIPE (NCC) engagement with LEA and government In-Reply-To: <20110602092050.GG45955@Space.Net> References: <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> <20110601221110.GD16343@cilantro.c4inet.net> <20110602092050.GG45955@Space.Net> Message-ID: On 2 Jun 2011, at 10:20, Gert Doering wrote: > On Wed, Jun 01, 2011 at 10:11:10PM +0000, Sascha Luck wrote: >> the fact that NCC had a happy-clappy "very cordial" meeting with >> SOCA (yes, the Internet is Serious and Organised Crime in the UK) >> makes me wonder. About what Sacha? Do you think it's a Bad Idea for the NCC to engage with law enforcement and have a good relationship with them? If so, why? FYI SOCA currently has responsibility for dealing with computer crime in the UK. From a practical point of view, this is very helpful. For example, there's a single point of contact and a clear process to follow, both for the NCC and the cops. The NCC doesn't have to deal with local UK law enforcement or figure out if a request from Detective Sherlock Holmes of Strathclyde Police is genuine or not. We've also had SOCA come to the co-op WG at RIPE meetings a few times, something we should welcome and encourage because that helps develop mutual understanding. I wish other LEAs would do this too. > One of the tasks the NCC is mandated by the NCC members to do is > "make sure > that the governments of our region understands how the Internet works, > how Internet self-regulation works, and that it's better to leave us > alone". This is why those good people attend ITU meetings, meet with > LEAs, etc. - to make sure those "political accidents" that everybody > is > afraid of do *not* happen. Exactly! > There's serious dangers here, like "why should a private entity be > allowed > to rule address governance in Europe? The european commission and the > national governments are much better suited to do that!" - and the NCC > works togethe with these folks to make them see that our way *works* > and > we need no extra regulation... I'd express this a little more diplomatically Gert. [What?! Me diplomatic?! :-)] By engaging with governments, regulators and LEAs, we can show how their concerns about the usual public interest things -- fairness, transparency, consumer confidence, monopoly considerations, etc -- are being addressed and that the mechanisms which are in place are satisfactory to deal with those issues. Followups on this thread probably should move to the co-op WG list. From axel.pawlik at ripe.net Thu Jun 2 13:39:29 2011 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Thu, 02 Jun 2011 13:39:29 +0200 Subject: [address-policy-wg] Has 2008-08 passed? If not, what now? In-Reply-To: <4DE75D44.6070700@linx.net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <4DE49F8D.7010900@linx.net> <827h96neye.fsf@mid.bfk.de> <20110601211116.GA16343@cilantro.c4inet.net> <701DEDD2-1009-4305-A1EB-BEBC2B71D555@steffann.nl> <4DE75D44.6070700@linx.net> Message-ID: <4DE77671.6040208@ripe.net> On 02/06/2011 11:52, Malcolm Hutty wrote: > I remain interested to hear the answer to my question about what the > RIPE NCC intends to do if there is no consensus to approve 2008-08. Malcolm, all, This issue will be on the agenda for the next Executive board meeting, during the second week of June. You are asking an interesting question. We have been doing the development work on the basis of our Activity Plan, which in turn is based on community requests to implement the RPKI system. How and in which direction do we progress with hundreds of members showing active interest in using the system, while others are debating the dangers? The policy you are discussing is needed to regulate operations of the system. Until we have an agreed policy in place, we can only operate a sandbox system that should not be relied upon. The ongoing discussion is crucial, I am actually very happy that it happens. Those present at the Lisbon meeting will remember that we tried to stimulate exactly what is happening now. Having talked to Rob recently, we agree that making RPKI / resource certification a programmatic focus throughout the Vienna meeting might be a good idea. cheers, Axel From shane at time-travellers.org Tue Jun 21 11:58:33 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 21 Jun 2011 11:58:33 +0200 Subject: [address-policy-wg] IETF working group on renumbering in IPv6 Message-ID: <1308650313.3570.19.camel@shane-desktop> All, There is some idea to work on the renumbering problem in IPv6. This is certainly of interest to IPv6 folks, but I am including the address policy folks as this may ultimately have impact there. Cheers, -- Shane -------------- next part -------------- An embedded message was scrubbed... From: IESG Secretary Subject: WG Review: IPv6 Site Renumbering (6renum) Date: Thu, 2 Jun 2011 10:54:54 -0700 (PDT) Size: 9592 URL: From emadaio at ripe.net Fri Jun 24 17:05:18 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 24 Jun 2011 17:05:18 +0200 Subject: [address-policy-wg] 2011-01 New Draft Document Published (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA) Message-ID: <20110624154538.AED1F6A013@postboy.ripe.net> Dear Colleagues The draft document for the proposal described in 2011-01 has been published. The impact analysis that was conducted for this proposal has also been published You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2011-01 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-01/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 22 July 2011. Regards Emilio Madaio Policy Development Officer From tjc at ecs.soton.ac.uk Fri Jun 24 17:36:55 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 24 Jun 2011 16:36:55 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IETF working group on renumbering in IPv6 In-Reply-To: <1308650313.3570.19.camel@shane-desktop> References: <1308650313.3570.19.camel@shane-desktop> <8FDC0030-D1E7-4197-9070-CAB7ABAD145C@ecs.soton.ac.uk> Message-ID: Hi Shane, Many thanks for advertising the new WG to these lists. The charter was refined further since the one below, the final one being listed here: http://datatracker.ietf.org/wg/6renum/charter/ We would welcome any contributions to the renum mail list, see: https://www.ietf.org/mailman/listinfo/renum Currently I am one chair for the WG, another is being sought. I'm very happy to take any comments or inputs directly if people have views but do not wish to join the mail list. There should be a 6renum WG slot in Quebec at IETF81. I hope to attend RIPE63, so perhaps we can also have a slot for this in the IPv6 WG session there. Many thanks, Tim On 21 Jun 2011, at 10:58, Shane Kerr wrote: > All, > > There is some idea to work on the renumbering problem in IPv6. > > This is certainly of interest to IPv6 folks, but I am including the > address policy folks as this may ultimately have impact there. > > Cheers, > > -- > Shane > > From: IESG Secretary > Date: 2 June 2011 18:54:54 GMT+01:00 > To: IETF Announcement list > Cc: renum at ietf.org > Subject: WG Review: IPv6 Site Renumbering (6renum) > Reply-To: iesg at ietf.org > > > A new IETF working group has been proposed in the Operations and > Management Area. The IESG has not made any determination as yet. The > following draft charter was submitted, and is provided for informational > purposes only. Please send your comments to the IESG mailing list > (iesg at ietf.org) by Thursday, June 9, 2011 > > IPv6 Site Renumbering (6renum) > ------------------------------- > Last Modified: 2011-06-02 > > Current Status: Proposed Working Group > > Chairs: TBD > > Area Director: Ron Bonica > > Mailing list > Address: renum at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/renum > Archive: http://www.ietf.org/mail-archive/web/renum/ > > Description of Working Group > ----------- > > As outlined in RFC 5887, renumbering, especially for medium to large > sites and networks, is currently viewed as an expensive, painful, and > error-prone process, avoided by network managers as much as possible. > > As IPv6 adoption begins to gather momentum, those managers may turn to > PI addressing for IPv6 to attempt to minimise the need for future > renumbering. However, such an approach would create very serious BGP4 > scaling problems if used by millions of end sites; it is thus desirable > to develop tools, techniques and practices that may make renumbering a > simpler process, to reduce demand for IPv6 PI space. In addition, as > RFC 5887 describes, there are other triggers that mean some cases of > renumbering are unavoidable, so it should be considered a given that > a site may need partial or complete renumbering at some stage. > > Strategically it is thus important to implement and deploy techniques > that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes > universally deployed, renumbering can be viewed as a more routine event. > This includes consideration of how the initial assignment and subsequent > management of address information is performed, as this will affect > future renumbering operations. > > For renumbering to become more routine, a systematic address management > approach will be essential. A large site with a short prefix will be > divided into subnets with longer prefixes. In this scenario, renumbering > or partial renumbering can be complicated. Aggregation, synchronisation, > coordination, etc., need to be carefully managed, and the use of > manually inserted address literals minimised. In unmanaged scenarios, > consideration may need to be made for 'flag day' renumbering (in > contrast to the procedure described in RFC4192). > > The task of the 6RENUM working group is to document existing renumbering > practices for managed (enterprise) and unmanaged (SOHO) networks, to > identify specific renumbering problems in the context of site-wide > renumbering, and to then recharter with a view to develop point > solutions and system solutions to address those problems or to stimulate > such development in other working groups if appropriate. The principal > target will be solutions for IPv6. > > RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are > starting points for this work. > > Goals/deliverables > ------------------ > > The goals of the 6RENUM working group are: > > 1. To undertake scenario descriptions, including documentation of > current capability inventories and existing BCPs for managed > (enterprise) and unmanaged (SOHO) networks. These texts should > contribute towards the gap analysis and provide an agreed basis for > subsequent WG rechartering towards development of solutions > (potentially in other WGs) and improved practices. Operator input > will be of particularly high value for this stage. > > 2. To examine fully automatic, self-organising networks (manet/autoconf) > as a possible third scenario. > > 3. To perform a gap analysis for renumbering practices, drawing on RFCs > 4192 and 5887, to identify generic issues for network design, network > management, and renumbering operations. The scenario texts will > contribute to the analysis. > > 4. To document existing IP address management models and practices with > a view to proposing (at a high level) an appropriate model to allow > simplification of any partial or full site renumbering process > (this would likely be applicable to managed rather than unmanaged > scenarios). > > The general methodology for the WG will be to first build managed and > unmanaged baseline scenario descriptions, while in parallel undertaking > an initial gap analysis from existing work in (at least) RFC4192 and > RFC5877. As the scenario texts harden, their contributions will be > incorporated into the gap analysis, which can be published once the > scenarios are completed. > > The following topics are out of scope for the working group: > > 1. Renumbering avoidance; this can perhaps be considered by appropriate > IRTF groups. As documented in RFC5887, renumbering cannot be > completely avoided. The WG is limited to dealing with how to renumber > when it is unavoidable. > > 2. IPv4 renumbering. While many sites are likely to run dual-stack, > IPv6 is the future and, especially given concerns over extensive use > of IPv6 PI, the most appropriate place to focus effort. > > 3. ISP renumbering; this is potentially the most complex renumbering > case. More benefit can be achieved by focusing effort on site > renumbering. The site analysis should include the ISP's role in its > own renumbering event. > > A recharter of the WG will be possible once the gap analysis and > scenario descriptions are completed, and the IP address management > ('numbering tool') review and (high level) proposal have been published. > The rechartering will identify more specific work items within the > 6RENUM WG or appropriate protocol WGs. > > Milestones > ---------- > > Aug 2011 managed (enterprise) scenario draft ready for WG adoption > (partly based on draft-jiang-ipv6-site-renum-guideline) > > Aug 2011 unmanaged (SOHO) scenario draft ready for WG adoption > > Oct 2011 gap analysis document ready for WG adoption (already some > considerations in RFC5887 and > draft-jiang-ipv6-site-renum-guideline) > > Oct 2011 management model draft ready for WG adoption > > Jan 2012 managed (enterprise) scenario draft ready for WGLC > > Jan 2012 unmanaged (SOHO) scenario draft ready for WGLC > > Feb 2012 management model ready for WGLC > > Mar 2012 gap analysis document ready for WGLC > > Apr 2012 recharter WG towards solution space > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Tue Jun 28 12:58:50 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 28 Jun 2011 12:58:50 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) Message-ID: <20110628105851.940F46A003@postboy.ripe.net> Dear Colleagues, The draft document for the proposal described in 2011-02 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2011-02 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 26 July. Regards Emilio Madaio Policy Development Officer RIPE NCC From slz at baycix.de Tue Jun 28 13:40:23 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 28 Jun 2011 13:40:23 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <20110628105851.940F46A003@postboy.ripe.net> References: <20110628105851.940F46A003@postboy.ripe.net> Message-ID: <96EE5772-C7C4-4506-B0A7-D70F243E22F9@baycix.de> Hi, Am 28.06.2011 um 12:58 schrieb Emilio Madaio: > > Dear Colleagues, > > The draft document for the proposal described in 2011-02 has been > published. The impact analysis that was conducted for this proposal > has also been published. > > > You can find the full proposal and the impact analysis at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2011-02/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 26 July. for now, i support this proposal for the reasons mentioned in all those threads we had before about the situation. But just for the record: i don't think it's "a good thing", but i do see the problems with the current situation. Fortunately we can and should closely monitor the outcome over the next years and rethink any policy again then if necessary. It's a bitch, but we know we can retroactively change policies, see the damned 2007-01 thing! :-) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From boggits at gmail.com Tue Jun 28 13:35:03 2011 From: boggits at gmail.com (boggits) Date: Tue, 28 Jun 2011 12:35:03 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <20110628105851.940F46A003@postboy.ripe.net> References: <20110628105851.940F46A003@postboy.ripe.net> Message-ID: On 28 June 2011 11:58, Emilio Madaio wrote: > > You can find the full proposal and the impact analysis at: > ? ?http://www.ripe.net/ripe/policies/proposals/2011-02 Okay I'll bite... "Although the Board is unconvinced that the chosen approach is the best possible solution for the described problem, the decision is of course deferred to the RIPE community." do they have another suggestion? J -- James Blessing 07989 039 476 From Remco.vanMook at eu.equinix.com Wed Jun 29 15:25:40 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Wed, 29 Jun 2011 14:25:40 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: Message-ID: This is a bit of a complicated hat situation. The RIPE NCC merely executes policy set by the community, so with my board hat on I find it difficult to go as far as even offering suggestions. While I do sympathise with the rationale behind the proposal, doing it this way strikes me as having an awful lot of (unintended?) side effects. I personally don't have a better suggestion to achieve resolution of the problem that this proposal aims to fix, but at the same time I'm unconvinced that everybody's who's been supporting the proposal has been doing so for the problem this policy aims to fix, and not one of its (again, unintended?) side effects. Remco van Mook On 28-06-11 13:35, "boggits" wrote: >On 28 June 2011 11:58, Emilio Madaio wrote: >> >> You can find the full proposal and the impact analysis at: >> http://www.ripe.net/ripe/policies/proposals/2011-02 > >Okay I'll bite... > >"Although the Board is unconvinced that the chosen approach is the >best possible solution for the described problem, the decision is of >course deferred to the RIPE community." > >do they have another suggestion? > >J > >-- > >James Blessing >07989 039 476 > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From james.blessing at despres.co.uk Wed Jun 29 15:50:23 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 29 Jun 2011 14:50:23 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: Message-ID: On 29 June 2011 14:25, Remco Van Mook wrote: > This is a bit of a complicated hat situation. The RIPE NCC merely executes > policy set by the community, so with my board hat on I find it difficult > to go as far as even offering suggestions. While I do sympathise with the > rationale behind the proposal, doing it this way strikes me as having an > awful lot of (unintended?) side effects. I personally don't have a better > suggestion to achieve resolution of the problem that this proposal aims to > fix, but at the same time I'm unconvinced that everybody's who's been > supporting the proposal has been doing so for the problem this policy aims > to fix, and not one of its (again, unintended?) side effects. Okay can we be clear about the reason for doing this before we continue with the discussion... A single IPv6 route will consume 4 x the space of a v4 route, whilst we are in the transition phase between v4 and v6 and having to allocate memory to both protocols adding potentially the equivalent to 70k to the routing table 'just because its easier' doesn't strike me as the most sensible thing to do in the world. Transition between 2 IPv6 suppliers (unlike IPv4) "shouldn't" require the same level of manual reconfiguration due IPv6's complexity crying out for some form of automation in its deployment in the first place. What I believe we should be looking at is education of the differences between v4 and v6 rather than changing policy. J -- James Blessing 07989 039 476 From david.freedman at uk.clara.net Wed Jun 29 15:34:01 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 29 Jun 2011 14:34:01 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <96EE5772-C7C4-4506-B0A7-D70F243E22F9@baycix.de> References: <20110628105851.940F46A003@postboy.ripe.net> <96EE5772-C7C4-4506-B0A7-D70F243E22F9@baycix.de> Message-ID: <4E0B29C9.2070406@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Fortunately we can and should closely monitor > the outcome over the next years and rethink any policy again then if > necessary. > It's a bitch, but we know we can retroactively change policies, see the > damned 2007-01 thing! :-) > Agreed, I support the proposal even though I'm uncomfortable with the possible outcomes, would like to see close monitoring of the situation. Dave. - -- David Freedman Group Network Engineering david.freedman at uk.clara.net Tel +44 (0) 20 7685 8000 Claranet Group 21 Southampton Row London - WC1B 5HA - UK http://www.claranet.com Company Registration: 3152737 - Place of registration: England All the information contained within this electronic message from Claranet Ltd is covered by the disclaimer at http://www.claranet.co.uk/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4LKckACgkQtFWeqpgEZrK0uQCfe76rn71iajRlYE5o6Zswk0QH OOkAoIK3TLuxqZqeW0bqdgsRUo5wE58J =AcVE -----END PGP SIGNATURE----- From jim at rfc1035.com Wed Jun 29 16:04:12 2011 From: jim at rfc1035.com (Jim Reid) Date: Wed, 29 Jun 2011 15:04:12 +0100 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> Message-ID: <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> On 28 Jun 2011, at 12:35, boggits wrote: > Okay I'll bite... > > "Although the Board is unconvinced that the chosen approach is the > best possible solution for the described problem, the decision is of > course deferred to the RIPE community." > > do they have another suggestion? James, the NCC Board does not make policy. For address management policy-making, it's this WG which does that. [The name of the WG is a big hint... :-)] I hoped everyone knew that. The Board's job is to oversee the NCC on behalf of its members but not get involved in operational matters. Besides, by the time a policy proposal gets in front of the Board (impact assessment, etc), the PDP is in the end- game and the proposal is pretty much the settled will of the RIPE community. In this case, the Board seems to be saying it doesn't think the proposed solution is ideal but will go along with what the RIPE community decides. I'm sure that if the Board felt that decision was not in the best interests of the NCC, they wouldn't keep quiet about the matter. From shane at time-travellers.org Wed Jun 29 21:04:20 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 29 Jun 2011 21:04:20 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: Message-ID: <1309374260.2558.72.camel@shane-desktop> James, I know this has been discussed several times, but I can't stop myself... On Wed, 2011-06-29 at 14:50 +0100, James Blessing wrote: > A single IPv6 route will consume 4 x the space of a v4 route, whilst > we are in the transition phase between v4 and v6 and having to > allocate memory to both protocols adding potentially the equivalent to > 70k to the routing table 'just because its easier' doesn't strike me > as the most sensible thing to do in the world. My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming. So while routing table growth is a concern, PI policies are probably not a large factor. > Transition between 2 IPv6 suppliers (unlike IPv4) "shouldn't" require > the same level of manual reconfiguration due IPv6's complexity crying > out for some form of automation in its deployment in the first place. > What I believe we should be looking at is education of the differences > between v4 and v6 rather than changing policy. My further understanding is that desire for PI is mostly for non-technical reasons. I don't think anything can make this motivation go away. Companies want it. -- Shane From james.blessing at despres.co.uk Wed Jun 29 21:19:12 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 29 Jun 2011 20:19:12 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <1309374260.2558.72.camel@shane-desktop> References: <1309374260.2558.72.camel@shane-desktop> Message-ID: On 29 June 2011 20:04, Shane Kerr wrote: > James, > > I know this has been discussed several times, but I can't stop myself... > > On Wed, 2011-06-29 at 14:50 +0100, James Blessing wrote: >> A single IPv6 route will consume 4 x the space of a v4 route, whilst >> we are in the transition phase between v4 and v6 and having to >> allocate memory to both protocols adding potentially the equivalent to >> 70k to the routing table 'just because its easier' doesn't strike me >> as the most sensible thing to do in the world. > > My understanding is that routing table growth is largely fueled by > traffic engineering rather than multihoming. So while routing table > growth is a concern, PI policies are probably not a large factor. True, but thats no excuse to pour fuel onto the fire. >> Transition between 2 IPv6 suppliers (unlike IPv4) "shouldn't" require >> the same level of manual reconfiguration due IPv6's complexity crying >> out for some form of automation in its deployment in the first place. >> What I believe we should be looking at is education of the differences >> between v4 and v6 rather than changing policy. > > My further understanding is that desire for PI is mostly for > non-technical reasons. I don't think anything can make this motivation > go away. Companies want it. Okay but the point about the allocation of resources is that it should be done for technical rather than just pure business/political/paranoid reasons. Everyone is saying that IPv6 will 'last forever' but they said the same thing about oil too J -- James Blessing 07989 039 476 From randy at psg.com Thu Jun 30 01:45:03 2011 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jun 2011 08:45:03 +0900 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <1309374260.2558.72.camel@shane-desktop> References: <1309374260.2558.72.camel@shane-desktop> Message-ID: > My understanding is that routing table growth is largely fueled by > traffic engineering rather than multihoming. got cites? randy From turchanyi.geza at gmail.com Thu Jun 30 08:43:34 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Thu, 30 Jun 2011 08:43:34 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> Message-ID: Hello Jim, Your comments are 100% valid, however one of your conclusion might be misleading. James, the NCC Board does not make policy. For address management > policy-making, it's this WG which does that. [The name of the WG is a big > hint... :-)] I hoped everyone knew that. The Board's job is to oversee the > NCC on behalf of its members but not get involved in operational matters. > Besides, by the time a policy proposal gets in front of the Board (impact > assessment, etc), the PDP is in the end-game and the proposal is pretty much > the settled will of the RIPE community. > This is 100% valid. > > In this case, the Board seems to be saying it doesn't think the proposed > solution is ideal but will go along with what the RIPE community decides. What else the Board could do? > I'm sure that if the Board felt that decision was not in the best interests > of the NCC, they wouldn't keep quiet about the matter. > ??? Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Thu Jun 30 09:22:08 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 30 Jun 2011 09:22:08 +0200 (CEST) Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> Message-ID: On Thu, 30 Jun 2011, Randy Bush wrote: >> My understanding is that routing table growth is largely fueled by >> traffic engineering rather than multihoming. > > got cites? I think the routing table report "aggregation ratio" shows some of this. It might also be incompetence rather than intentional traffic engineering, that is fueling the growth. I know people who deaggregate their /19 into /24s and announce it to all their providers, because they have one per city and if that city is isolated, it still has connectivity even if their internal network is partitioned. If this should be called "traffic engineering" or not is debatable. >From the routing table report: BGP routing table entries examined: 361681 Prefixes after maximum aggregation: 164222 I don't have figures showing these metrics over time, but I feel that de-aggregation ratio has increased, but not hugely. As long as announcing routes to the DFZ doesn't incur a cost per route, we're going to see the current situation continue, I guess. Luckily it seems core routing platforms keep up with the growth, even though platforms need to be upgraded prematurely due to them not being able to handle the current DFZ size. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Thu Jun 30 09:30:37 2011 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jun 2011 16:30:37 +0900 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> Message-ID: >>> My understanding is that routing table growth is largely fueled by >>> traffic engineering rather than multihoming. >> got cites? > I think the routing table report "aggregation ratio" shows some of > this. where 'some' does not seem to include multihoming. so we can not compare. > I don't have figures showing these metrics over time, but I feel that > de-aggregation ratio has increased, but not hugely. my too subtle point is that someone should write a paper, with measurements, not feelings. randy From ggm at apnic.net Thu Jun 30 09:32:08 2011 From: ggm at apnic.net (George Michaelson) Date: Thu, 30 Jun 2011 17:32:08 +1000 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> Message-ID: <764E0D83-77A0-4D21-8DE2-A8B1611054EF@apnic.net> On 30/06/2011, at 5:30 PM, Randy Bush wrote: >>>> My understanding is that routing table growth is largely fueled by >>>> traffic engineering rather than multihoming. >>> got cites? >> I think the routing table report "aggregation ratio" shows some of >> this. > > where 'some' does not seem to include multihoming. so we can not > compare. > >> I don't have figures showing these metrics over time, but I feel that >> de-aggregation ratio has increased, but not hugely. > > my too subtle point is that someone should write a paper, with > measurements, not feelings. > > randy > From shane at time-travellers.org Thu Jun 30 10:22:16 2011 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 30 Jun 2011 10:22:16 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> Message-ID: <1309422136.2793.35.camel@shane-desktop> Randy, On Thu, 2011-06-30 at 08:45 +0900, Randy Bush wrote: > > My understanding is that routing table growth is largely fueled by > > traffic engineering rather than multihoming. > > got cites? As you know, I'm not a routing guy, so I tried to be careful with my language here. I'm neither an operator nor a researcher, so if I sound ignorant it is because I am. Having said that... One simple way to look at it is to consider how much PI space there is, versus routing table size. Looking at the latest copy of the RIPE Database, we find just under 29k PI assignments. I am told that the RIPE PI policy is the most lenient in the world, but if we assume that similar policies are in place throughout the world that still leaves less than 100k routes for all PI holders combined, compared to the 350k routes total. This does not tell us anything about the *growth* exactly, but it serves as a worst-case analysis: in the current Internet, most routes come from non-PI allocations. Further, a quick google for "routing table growth deaggregation" turns up the following paper: http://people.ee.ethz.ch/~wmuehlba/jsac-10.pdf It is a couple years old, and I don't know if the authors are trustworthy, but it seems nicely done. ;) The authors were looking for trends in changes in traffic engineering practices, and summarize: To sum up, given the differences in the two plots of Figure 7, we conclude that traffic engineering is a significant driver for address space deaggregation. However, based on the evolution since 2001, we cannot identify any sudden shift towards a more aggressive and widespread use of prefix deaggregation in order to achieve traffic engineering. This suggests that it is not an increasing demand for traffic engineering that inflates routing tables: rather, inflation is a consequence of the topological growth of the Internet combined with the lack of support for traffic engineering in the current routing system. Nevertheless, if we look at Fig. 3., we see that the percentage of prefixes from deaggregated routes has gone from like 17% in 2001 to 31% in 2008 - almost double. So while the amount of routes due to traffic engineering is not due to a fundamental change in practice, it seems probable to me that it is nevertheless the source of a lot of routing table growth. Regarding the implications on policy... we seem to have a situation where the people for and against increased IPv6 PI seem to think that the other side must prove their position somehow. These ideas are all based on potential future impact, and historically predictions about the future have been very difficult. Since we are talking about theories about future impact, we're kind of like economists: the only real way to test a theory is to implement it and see what happens. I will note that *not* changing the policy is also implementing a policy, so no matter what we do, we're running an experiment based on half-baked theories of how the Internet works. More research will certainly inform the discussion and possibly lead to better policies, but policies will never be based on perfect understanding. -- Shane From randy at psg.com Thu Jun 30 10:29:24 2011 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jun 2011 17:29:24 +0900 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: <1309422136.2793.35.camel@shane-desktop> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> Message-ID: > http://people.ee.ethz.ch/~wmuehlba/jsac-10.pdf well, there you go! > It is a couple years old, and I don't know if the authors are > trustworthy some are, some are not. at ripe/rome, luca sent a bunch of us to a *really* horrible and disgusting restaurant. figure 7a is pretty telling. randy From jim at rfc1035.com Thu Jun 30 10:31:23 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 30 Jun 2011 09:31:23 +0100 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> Message-ID: On 30 Jun 2011, at 07:43, Turchanyi Geza wrote: > Your comments are 100% valid, however one of your conclusion might be > misleading. Only one? :-) >> In this case, the Board seems to be saying it doesn't think the >> proposed >> solution is ideal but will go along with what the RIPE community >> decides. > > What else the Board could do? Depends. Is your question what can the Board do about this specific policy proposal or in a wider (theoretical?) context? Though my answer's still the same: it depends. >> I'm sure that if the Board felt that decision was not in the best >> interests >> of the NCC, they wouldn't keep quiet about the matter. > > ??? We had this issue a few years ago over the proposal that required all PI holders to have a contract with the NCC. Which was before the current PDP had been finalised IIRC. The policy had reached consensus in the WG and it was then a simple matter of implementation. Until the Board and management realised what that entailed: hiring a small army of people to handle all the paperwork for thousands of PI holders. The Board decided this was a Bad Idea and asked the WG to reconsider. There is this ugly little gap in our policy making. The community which makes policy (RIPE) is not necessarily the same as the people who pay for that policy to be implemented (the NCC membership). The Board has to straddle that gap somehow. OTOH, it can't "make policy" or get involved in operational matters. On the other the Board has the usual responsibilities to look after the interests of the organisation (the NCC) and its members. From ebais at A2B-Internet.com Thu Jun 30 10:42:11 2011 From: ebais at A2B-Internet.com (Erik Bais) Date: Thu, 30 Jun 2011 10:42:11 +0200 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> Message-ID: <415B399E-B3EF-4B84-887B-EA5789792367@A2B-Internet.com> Perhaps we should have an aggregation day and see if we can shift the tide by education & implementing better router configs. I dare to say that a lot of de-aggregation is due to bad configs, just look at the amount of leaking /28's-/32's and private AS's .. If people can't (don't) even filter intern internal subnets, no wonder you see /18's cut up into /24's or worse .. Erik Bais From boggits at gmail.com Thu Jun 30 10:34:56 2011 From: boggits at gmail.com (boggits) Date: Thu, 30 Jun 2011 09:34:56 +0100 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <1309422136.2793.35.camel@shane-desktop> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> Message-ID: On 30 June 2011 09:22, Shane Kerr wrote: > Regarding the implications on policy... we seem to have a situation > where the people for and against increased IPv6 PI seem to think that > the other side must prove their position somehow. These ideas are all > based on potential future impact, and historically predictions about the > future have been very difficult. > > Since we are talking about theories about future impact, we're kind of > like economists: the only real way to test a theory is to implement it > and see what happens. I will note that *not* changing the policy is also > implementing a policy, so no matter what we do, we're running an > experiment based on half-baked theories of how the Internet works. More > research will certainly inform the discussion and possibly lead to > better policies, but policies will never be based on perfect > understanding. Okay let me put the case from this side, the number of 70k was based on quoted figure of current v4 PI assignments and the assumption (which I think is only logical) that each one of those assignments will want a v6 assignment at some point soon. This does not account for any growth in the desire for PI space that might appear based on people deciding that PI would a "better route" for their network design. The current global routing table for IPv6 is 5-6k (give or take) implementing this policy (as currently structured) would see that grow to around 20k (just with v4 -> v6 requirements) in a vert short space of time, now I don't know about your network but slow gradual growth is okay as you can budget for replacing and upgrading a normal cycle. A sudden spike like this is likely to cause two things to happen, first it'll trip over a raft of memory bugs that vendors haven't found yet because they didn't think the v6 table would grow so quickly and secondly it'll put those people with less available capital off deploying v6 as their hardware won't be up to scratch. I am happy to be convinced that I'm wrong and this won't be a problem *but* I'm still not convinced that this change is the best approach to solving "the problem" maybe the authors could pitch in with their problem statement so we can see what the actual problem is in the first place. J -- James Blessing 07989 039 476 From slz at baycix.de Thu Jun 30 11:04:36 2011 From: slz at baycix.de (Sascha Lenz) Date: Thu, 30 Jun 2011 11:04:36 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> Message-ID: <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> Hi, [...] > The current global routing table for IPv6 is 5-6k (give or take) > implementing this policy (as currently structured) would see that grow > to around 20k (just with v4 -> v6 requirements) in a vert short space > of time, now I don't know about your network but slow gradual growth > is okay as you can budget for replacing and upgrading a normal cycle. > A sudden spike like this is likely to cause two things to happen, > first it'll trip over a raft of memory bugs that vendors haven't found > yet because they didn't think the v6 table would grow so quickly and > secondly it'll put those people with less available capital off > deploying v6 as their hardware won't be up to scratch. > > I am happy to be convinced that I'm wrong and this won't be a problem > *but* I'm still not convinced that this change is the best approach to > solving "the problem" maybe the authors could pitch in with their > problem statement so we can see what the actual problem is in the > first place. why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up! So, i'm a little confused now why this is bad. I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-) And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes? I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion... -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From jan at go6.si Thu Jun 30 11:10:04 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 30 Jun 2011 11:10:04 +0200 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> Message-ID: <4E0C3D6C.70804@go6.si> On 6/30/11 10:29 AM, Randy Bush wrote: >> It is a couple years old, and I don't know if the authors are >> trustworthy > > some are, some are not. at ripe/rome, luca sent a bunch of us to a > *really* horrible and disgusting restaurant. ROTFL... I must be careful which restaurant I choose for you in November in Ljubljana then, as this seems pretty unforgiving :) cheers, /jan From randy at psg.com Thu Jun 30 15:18:49 2011 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jun 2011 22:18:49 +0900 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: <415B399E-B3EF-4B84-887B-EA5789792367@A2B-Internet.com> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <415B399E-B3EF-4B84-887B-EA5789792367@A2B-Internet.com> Message-ID: > Perhaps we should have an aggregation day and see if we can shift the > tide by education & implementing better router configs. > > I dare to say that a lot of de-aggregation is due to bad configs, just > look at the amount of leaking /28's-/32's and private AS's .. > > If people can't (don't) even filter intern internal subnets, no wonder > you see /18's cut up into /24's or worse .. ahhhh youth. i am soooo jealous of your optimism. not kidding. randy From ebais at a2b-internet.com Thu Jun 30 15:52:05 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 30 Jun 2011 15:52:05 +0200 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <415B399E-B3EF-4B84-887B-EA5789792367@A2B-Internet.com> Message-ID: <004d01cc372c$e5fc55f0$b1f501d0$@com> > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Thursday, June 30, 2011 3:19 PM > To: Erik Bais > ahhhh youth. i am soooo jealous of your optimism. not kidding. Thanks Randy, after my 39th b-day last week, that was just what I needed :) And yes, it might be optimistic to think we could turn the tide, however the numbers speak for themselves. And if we (as a community) could look at ourselves and improve what we advertize, it's a start. How many times did you check what you receive from certain peers and asked them to update their filtering, just because they are not looking at what they advertize ? I do this on a regular basis and often people send a reply back that they forgot, blame a colleague or what not, but the 'moral' of the story is that people have no clue and their routers just spit out whatever they like. Erik From randy at psg.com Thu Jun 30 16:00:18 2011 From: randy at psg.com (Randy Bush) Date: Thu, 30 Jun 2011 23:00:18 +0900 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: <004d01cc372c$e5fc55f0$b1f501d0$@com> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <415B399E-B3EF-4B84-887B-EA5789792367@A2B-Internet.com> <004d01cc372c$e5fc55f0$b1f501d0$@com> Message-ID: > Thanks Randy, after my 39th b-day last week, that was just what I > needed :) wanna trade? > How many times did you check what you receive from certain peers and > asked them to update their filtering and then depeered the worst > just because they are not looking at what they advertize ? they are looking. it is intentional. > I do this on a regular basis and often people send a reply back that > they forgot, blame a colleague or what not, but the 'moral' of the > story is that people have no clue and their routers just spit out > whatever they like. often true at the smaller end. at medium/large there is a lot of intentional slicing to /24s, not for te but for hijack reduction. i am hoping that, over the years, rpki-based origin validation will remove some of the motivation for this. but that's my silly form of optimism. randy From sander at steffann.nl Thu Jun 30 23:04:14 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 30 Jun 2011 23:04:14 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> Message-ID: <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> Hi, > We had this issue a few years ago over the proposal that required all PI holders to have a contract with the NCC. Which was before the current PDP had been finalised IIRC. The policy had reached consensus in the WG and it was then a simple matter of implementation. Until the Board and management realised what that entailed: hiring a small army of people to handle all the paperwork for thousands of PI holders. The Board decided this was a Bad Idea and asked the WG to reconsider. Just for the record: we had the PDP already at that point in time and the objection was raised during last call. At no point in time has the board asked the working group to reconsider a policy that had already reached full consensus. The members of the board are also members of this community of course, so they can object to a policy in the same way everybody can... > There is this ugly little gap in our policy making. The community which makes policy (RIPE) is not necessarily the same as the people who pay for that policy to be implemented (the NCC membership). The Board has to straddle that gap somehow. OTOH, it can't "make policy" or get involved in operational matters. On the other the Board has the usual responsibilities to look after the interests of the organisation (the NCC) and its members. At some point we refined the PDP to include an impact analysis by the RIPE NCC. Communication between the board and the WG and WG chairs has improved a lot as well. So I feel confident that any potential problems in this area will be openly discussed. Thanks, Sander