From immo.ripe at be.free.de Sun May 1 20:16:42 2011 From: immo.ripe at be.free.de (Immo 'FaUl' Wehrenberg) Date: Sun, 1 May 2011 20:16:42 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> Message-ID: <20110501181642.GZ18210@benabuFaUl.be.free.de> Martin wrote: > On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera wrote: > > hello, > > > > Is it possible to discuss ability of getting second IPv6 PA allocation as a > > LIR without filling first one ? > See below. > > > The reason for such a need is a change of IPv6 PI rules, it is no longer > > possible to use IPv6 PI as ISP (/128 for subscibers). > > So, solution is that LIR segment /32 into smaller units an assigning them to > > their SponsorLIR agreement customers. > > > > However, first /32 IPv6 allocation is in our case advertized as whole by our > > AS13000. Once some internal policy for suballocations is used, this prefix > > can not be divided into smaller prefixes. > > I doubt this is correct. You mentioned that you had not filled the > /32. In other words, there should be /48s left over unallocated > internally. > > These /48s can be (sub-)allocated to customers (please forgive my > flawed internet-numbers-delegation-vocabulary), who are free to > announce them over BGP sessions. > > It is then up to your customers to find transit providers willing to > accept these announcements, which may be helped by them having route6 > objects registered. My question there would be wether larger prefixes then /32 from the pa-ranges would be generally accepted? As far as I understand, that would be a problem. > If they have trouble with connectivity due to AS:es filtering out > these long prefixes from IPv6 PA regions, they will have to get their > own PA by becoming a LIR member themselves. Or forcing their customers to apply for PIv6 for their purposes. > > For SponsorLIR agreement customers - little ISPs, willing to advertise their > > i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA > > (not advertised as whole by LIRs ASes) would be great... > The yet-to-be properly challenged (legacy?) consensus/opinion of this > WG is that ISPs must pay to play IPv6. I.e., you must become LIR to > be allowed to announce routes into the DFZ. > > IPv6 PI (PIv6) is nearly useless, by design: > Only customer-less end-users can use PIv6 space today without stepping > into a grey zone in the policy documents. I.e., these end-users can't > have customers. There is one other solution. You apply for v6-PI for your own infrastructure and encourage your customers apply for their own pi-space in order to get v6. This is what the non-profit-organization I work for is now going to do (since we cannot afford becoming LIR). Obviously, this blows up the routing table (which I strongly dislike), but policy is clear that this is the only way to continue what we are doing without willingly violating the current policy. IMHO obviously, changing PI policy would be a more elegant solution. > Presumably, the more ISPs that sign up for this Internet tax (the LIR > membership fees), the lower it will become (#LIRs is most definitely > sub-linearly proportional to the RIPE NCC:s operational costs). It is > fairly obvious to me that this attempt to (at least partially) solve a > *perceived* network model problem with taxes is not long-term stable > in itself.* Yea, that would be nice. But that will only help eventually, not now. > Personally I'd much prefer if the policies were aligned with reality > better, since it would allow us to get rid of the more or less > arbitrary policy-interpreting role the IPRA:s at the RIPE NCC has for > v6 resources today. This would make the landscape much more honest and > just. After all, it's just bits anyway. I strongly support that! > * This is *the* major source for all this head ache. There is a > considerable fear among many AP-WG participants that making IPv6 PI > easier to get will (1) lead to an uncontrolled explosion of IPv6 > prefixes in the DFZ (2), which hardware will fail to handle (3) and > the IPv6(**) internet will break down (4). I don't really see why suddenly a lot of organizations should come up wanting PIv6. I think the need of PIv6 would be quite compareable to PIv4, and at least nowadays, the PI-Prefixes aren't really that problem as far as I see. And, as pointed out before, the current PIv6 policy can even be interpreted as source of much more v6-routes in the DFZ anyways. regards, Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From millnert at gmail.com Sun May 1 22:46:59 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 1 May 2011 16:46:59 -0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110501181642.GZ18210@benabuFaUl.be.free.de> References: <4DB73E46.1000605@leon.pl> <20110501181642.GZ18210@benabuFaUl.be.free.de> Message-ID: Immo, On Sun, May 1, 2011 at 2:16 PM, Immo 'FaUl' Wehrenberg wrote: >> IPv6 PI (PIv6) is nearly useless, by design: >> Only customer-less end-users can use PIv6 space today without stepping >> into a grey zone in the policy documents. I.e., these end-users can't >> have customers. I'm surprised that I had not realized that myself. IPv6-hosting ::= (bring-your-own-PIv6-prefix, @ 50EUR/year+registry fees | buy from a LIR) At 65536 /48s in a /32, that's a big source of revenue for RIPE right there. :) Current break-even seems to be around 50 customers (for when it's cheaper to be LIR). Which in other words means 50:1 prefixes in DFZ, before break-even. And I'm betting there's a significant long-tail of hosting providers who have less than 50 customers. Oh the joy of DFZ :) Regards, Martin From marcin at leon.pl Sun May 1 22:59:57 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Sun, 01 May 2011 22:59:57 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> Message-ID: <4DBDC9CD.9030003@leon.pl> Martin Millnert wrote: > Marcin, > > On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera wrote: >> hello, >> >> Is it possible to discuss ability of getting second IPv6 PA allocation as a >> LIR without filling first one ? > > See below. > >> The reason for such a need is a change of IPv6 PI rules, it is no longer >> possible to use IPv6 PI as ISP (/128 for subscibers). >> So, solution is that LIR segment /32 into smaller units an assigning them to >> their SponsorLIR agreement customers. >> >> However, first /32 IPv6 allocation is in our case advertized as whole by our >> AS13000. Once some internal policy for suballocations is used, this prefix >> can not be divided into smaller prefixes. > > I doubt this is correct. You mentioned that you had not filled the > /32. In other words, there should be /48s left over unallocated > internally. > > These /48s can be (sub-)allocated to customers (please forgive my > flawed internet-numbers-delegation-vocabulary), who are free to > announce them over BGP sessions. Indeed, however there is one "little" issue. /32 is already advertised @AS13000 as whole. So there are 2 possibilities: - add paralel route objects, but then MNT-LOWER must be added and all related inter-ISP communiaction problems. - not adverising /32 @ AS13000, adverising only prefixes in use. Both cases I would like to avoid. So, I would prefer to have /32 for own purposes, eventually customers who buy Internet from us, and other, who are just SponsorLIR customers. > Presumably, the more ISPs that sign up for this Internet tax (the LIR > membership fees), the lower it will become (#LIRs is most definitely > sub-linearly proportional to the RIPE NCC:s operational costs). It is > fairly obvious to me that this attempt to (at least partially) solve a > *perceived* network model problem with taxes is not long-term stable > in itself.* You can't use this argument for people who earn around 500-1000 euro per month with their business... Post comunistic block is much different than old EU, and most people from old EU do not realize that... Marcin From marcin at leon.pl Sun May 1 23:03:34 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Sun, 01 May 2011 23:03:34 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110427063600.GL30227@Space.Net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> Message-ID: <4DBDCAA6.6070701@leon.pl> > (And towards Marcin: if these policies stop you from assigning /128 to > end customers, that was partly the intention. Customers are supposed to > receive at least a /64, or better a /56 or /48 - which is why LIRs can get > a huge block of addresses quite easily. Don't return into IPv4 > "single-address-plus-NAT" land!) Well, we have never had used NAT, that's not good when you want to be serious ISP. /128 is just an example. Probably the simplest way will be subnet /64 or smaller, where part of IP will be MAC address of enduser. Marcin From millnert at gmail.com Sun May 1 23:06:25 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 1 May 2011 17:06:25 -0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBDC9CD.9030003@leon.pl> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> Message-ID: Hi Marcin, On Sun, May 1, 2011 at 4:59 PM, Marcin Kuczera wrote: >> These /48s can be (sub-)allocated to customers (please forgive my >> flawed internet-numbers-delegation-vocabulary), who are free to >> announce them over BGP sessions. > > Indeed, however there is one "little" issue. > /32 is already advertised @AS13000 as whole. > > So there are 2 possibilities: > - add paralel route objects, but then MNT-LOWER must be added and all > related inter-ISP communiaction problems. > - not adverising /32 @ AS13000, adverising only prefixes in use. 3: - at 50 EUR/year/customer, retrieve 1 PIv6 prefix, per customer. >> Presumably, the more ISPs that sign up for this Internet tax (the LIR >> membership fees), the lower it will become (#LIRs is most definitely >> sub-linearly proportional to the RIPE NCC:s operational costs). ?It is >> fairly obvious to me that this attempt to (at least partially) solve a >> *perceived* network model problem with taxes is not long-term stable >> in itself.* > > You can't use this argument for people who earn around 500-1000 euro per > month with their business... > Post comunistic block is much different than old EU, and most people from > old EU do not realize that... To which I wonder, how painful is 50 EUR/year per business ("additional fees may apply"), to bring its own prefix to someone else's hosting/network infrastructure? Regards, Martin From marcin at leon.pl Sun May 1 23:12:55 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Sun, 01 May 2011 23:12:55 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110501181642.GZ18210@benabuFaUl.be.free.de> References: <4DB73E46.1000605@leon.pl> <20110501181642.GZ18210@benabuFaUl.be.free.de> Message-ID: <4DBDCCD7.6030101@leon.pl> > > I don't really see why suddenly a lot of organizations should come > up wanting PIv6. I think the need of PIv6 would be quite compareable > to PIv4, and at least nowadays, the PI-Prefixes aren't really that > problem as far as I see. And, as pointed out before, the current > PIv6 policy can even be interpreted as source of much more > v6-routes in the DFZ anyways. That is not so simple in post-communist countries. As I know, there are around 200 ISPs in Germany. In Poland, we have - 2000-3000 of ISPs.. however they are very little sometimes - i.e. serving 300 or 700 customers. let's say - 10 euro /month per customer (+ VAT) * 700 = 7000 euro of a budget. Pay taxes, pay salaries, pay lawyers, office, investments, upstreams, infrastructure... I's just a little for the owner if you compare it to large ISPs. So, if there is no possibility to use IPv6 PI for own customers (/128 for customer) any more, the only way is to use other LIR's part of PA space. There is NO WAY that they will pay for beeing LIR. Regards, Marcin From marcin at leon.pl Sun May 1 23:17:07 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Sun, 01 May 2011 23:17:07 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> Message-ID: <4DBDCDD3.90000@leon.pl> > To which I wonder, how painful is 50 EUR/year per business > ("additional fees may apply"), to bring its own prefix to someone > else's hosting/network infrastructure? ok, we still do not understand each other. My SponsorLIR customer is and ISP who has their own customers. For IPv4 PI this works great. For IPv6 PI, arguments that addresses will be used for customers (same way as in IPv4 PI) results rejection of the IPv6 PI request. So - 50 euro is ok, but we can't get IPv6 PI with the same explanations as for IPv4 PI.... Regards, Marcin From millnert at gmail.com Sun May 1 23:44:25 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 1 May 2011 17:44:25 -0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBDCDD3.90000@leon.pl> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: Marcin, On Sun, May 1, 2011 at 5:17 PM, Marcin Kuczera wrote: > >> To which I wonder, how painful is 50 EUR/year per business >> ("additional fees may apply"), to bring its own prefix to someone >> else's hosting/network infrastructure? > > ok, we still do not understand each other. Yes, sorry, I forgot you were talking about ISPs. Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;) Cheers, Martin From marcin at leon.pl Sun May 1 23:54:07 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Sun, 01 May 2011 23:54:07 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: <4DBDD67F.7060202@leon.pl> Martin Millnert wrote: > Marcin, > > On Sun, May 1, 2011 at 5:17 PM, Marcin Kuczera wrote: >>> To which I wonder, how painful is 50 EUR/year per business >>> ("additional fees may apply"), to bring its own prefix to someone >>> else's hosting/network infrastructure? >> ok, we still do not understand each other. > > Yes, sorry, I forgot you were talking about ISPs. > > Though, 50 EUR/year for PIv6 for each one of the ISPs customer is > merely 4 EUR/month per customer. And they get their own /48 PIv6 > prefix! ;) ha ha ha.... Seriously, is there ANY resonable reason why policy for IPv6 PI can not be same as for IPv4 PI ? Regards, Marcin From Remco.vanMook at eu.equinix.com Mon May 2 00:18:41 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Sun, 1 May 2011 23:18:41 +0100 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBDD67F.7060202@leon.pl> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBDD67F.7060202@leon.pl> Message-ID: Marcin Kuczera wrote: > Seriously, is there ANY resonable reason why policy for IPv6 PI can not be > same as for IPv4 PI ? Because the IPv4 PI policy is an unfortunate relic that has seen much uhm, creative use that required a policy such as 2007-01 to clean up and has so far taken dozens of man years to implement? If you don't want to or can't pay for resources you use, you should be asking yourself questions. If you're not running a sustainable business, you're exercising a hobby. Why would somebody else pay for your hobby? As far as I've seen, the cost of utility power and network hardware in what you describe as 'post communistic block' is not that different from what you describe as 'old Europe', so I'm intrigued how those (I think far more significant) costs affect you. Remco No hats. 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 millnert at gmail.com Mon May 2 02:03:57 2011 From: millnert at gmail.com (Martin Millnert) Date: Sun, 1 May 2011 20:03:57 -0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBDD67F.7060202@leon.pl> Message-ID: Remco, On Sun, May 1, 2011 at 6:18 PM, Remco Van Mook wrote: > Marcin Kuczera wrote: >> Seriously, is there ANY resonable reason why policy for IPv6 PI can not be >> same as for IPv4 PI ? > > Because the IPv4 PI policy is an unfortunate relic that has seen much uhm, creative use that required a policy such as 2007-01 to clean up and has so far taken dozens of man years to implement? Isn't 2007-01 in place for IPv6 PI today already? > If you don't want to or can't pay for resources you use, you should be asking yourself questions. > > If you're not running a sustainable business, you're exercising a hobby. Why would somebody else pay for your hobby? The business *is* sustainable, with IPv4! They're even paying for it according to the policies of the community. How is it even possible that a IPv6 resource, which are practically infinite, can bear a cost which is ~50x higher for the same use, than the cost of a IPv4 resource, which is about to run out? If anything, these are *not* values derived from a market. The cost with prefixes that I think you refer to, comes not from the act of registering them in a registry, but from the use of them with a routing protocol, like BGP. If the cost in the core of BGP cannot scale with the size of the internetwork, I'd say this is primarily a problem with the routing protocol and not the mere fact that some chunks of space has names next to them in a database, chunks of space which may or may not participate in this voluntary routing activity. > As far as I've seen, the cost of utility power and network hardware in what you describe as 'post communistic block' is not that different from what you describe as 'old Europe', so I'm intrigued how those (I think far more significant) costs affect you. Power/network hardware scales closer to number of customers than the LIR cost, which is a *much* more stepwise cost at small sizes, do. Maybe we can get one such example ISP with 300-700 customers to show its books to prove this point. Now, assuming that point can be proven: that 50 EUR/year is a bearable cost for IPv4 resources, but ~2000+ EUR for IPv6 is not(*), the question becomes: Would the RIPE community like to adjust this unbalance between IPv4 and IPv6 somehow? Any decision/agreement, or lack thereof, has consequences. Regards, Martin * It's also not very hard to imagine that the highly competitive market (good thing, no?) may make it very hard for one ISP to increase its prices, just to offer IPv6 to its customers via means of being a LIR, when another may find a much cheaper way to obtain an IPv6 prefix (from some sponsoring LIR/co-op LIR in some fashion, say, for example). If that scales up, two things will occur: 1) RIPE's policies will be overrun, 2) filtering praxis's will be eroded. I think it's quite optimistic to believe any *registration* policies are going to hold off this particular piece of reality. From gert at space.net Mon May 2 16:44:33 2011 From: gert at space.net (Gert Doering) Date: Mon, 2 May 2011 16:44:33 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBDCAA6.6070701@leon.pl> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> Message-ID: <20110502144433.GL30227@Space.Net> Hi, On Sun, May 01, 2011 at 11:03:34PM +0200, Marcin Kuczera wrote: > > (And towards Marcin: if these policies stop you from assigning /128 to > > end customers, that was partly the intention. Customers are supposed to > > receive at least a /64, or better a /56 or /48 - which is why LIRs can get > > a huge block of addresses quite easily. Don't return into IPv4 > > "single-address-plus-NAT" land!) > > Well, > we have never had used NAT, that's not good when you want to be serious > ISP. /128 is just an example. If you give your customers a single /128, you're forcing *them* to use NAT. This is bad. > Probably the simplest way will be subnet /64 or smaller, where part of > IP will be MAC address of enduser. The strong recommendation is to give your customers something between a /48 and a /64. NO LESS, unless you know for sure(!) that they only have a single machine, and no network behind it. IPv6 is not IPv4, and we have enough addresses. Let's make good use out of it. (And the math has been done: giving a /56 to every single end customers out in the world will use up well below 0.0001% of the global address space) Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Mon May 2 16:50:03 2011 From: gert at space.net (Gert Doering) Date: Mon, 2 May 2011 16:50:03 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <20110502144433.GL30227@Space.Net> Message-ID: <20110502145003.GM30227@Space.Net> Hi, On Mon, May 02, 2011 at 02:48:42PM +0000, David Freedman wrote: > >unless you know for sure(!) > > I know for sure, for instance, under our policy, if you are purchasing web > hosting and want a real SSL/TLS endpoint (i.e you can't use the shared one > via SNI), we'll give you a /128 to bind the cert to. > > I think that this pretty well matches the criteria of "knowing for sure", no? :-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From leo.vegoda at icann.org Mon May 2 16:55:15 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 2 May 2011 07:55:15 -0700 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110502144433.GL30227@Space.Net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> Message-ID: <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> You wrote: > If you give your customers a single /128, you're forcing *them* to use NAT. This is bad. And they wouldn't be able to use stateless auto-configuration or RFC 3041 privacy extensions. > > Probably the simplest way will be subnet /64 or smaller, where part of > > IP will be MAC address of enduser. > > The strong recommendation is to give your customers something between a /48 and a /64. > NO LESS, unless you know for sure(!) that they only have a single machine, and no network > behind it. Even if they only have one machine there are advantages to assigning at least a /64. Regards, Leo From david.freedman at uk.clara.net Mon May 2 16:48:42 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 2 May 2011 14:48:42 +0000 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110502144433.GL30227@Space.Net> Message-ID: >unless you know for sure(!) I know for sure, for instance, under our policy, if you are purchasing web hosting and want a real SSL/TLS endpoint (i.e you can't use the shared one via SNI), we'll give you a /128 to bind the cert to. Dave. From gert at space.net Mon May 2 17:04:15 2011 From: gert at space.net (Gert Doering) Date: Mon, 2 May 2011 17:04:15 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> Message-ID: <20110502150415.GN30227@Space.Net> Hi, On Mon, May 02, 2011 at 07:55:15AM -0700, Leo Vegoda wrote: > Even if they only have one machine there are advantages to assigning at least a /64. Indeed. Thanks for reminding me (and all of us :-) ). Gert Doering -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From marcin at leon.pl Mon May 2 20:37:35 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Mon, 02 May 2011 20:37:35 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110502144433.GL30227@Space.Net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> Message-ID: <4DBEF9EF.5080104@leon.pl> > If you give your customers a single /128, you're forcing *them* to use > NAT. This is bad. > >> Probably the simplest way will be subnet /64 or smaller, where part of >> IP will be MAC address of enduser. > > The strong recommendation is to give your customers something between > a /48 and a /64. NO LESS, unless you know for sure(!) that they only > have a single machine, and no network behind it. ok, I understand the concept.. still have to wait for proper BRAS and CPE implementations... And I understand, that i.e. /64 for subscribers network is something that in IPv4 PI world would be forbidden (i.e. /29). If all of us agree, that there is enough address space for every toothbrush, subscribers can get something between /48 an /64 and this is will be usual, and even in IPv6 PA space there will be no every subnet registration (as I understand, and as it is requiured for IPv4 PA) - why IPv6 PI can not be similar to IPv6 PA then ??? Regards, Marcin From marcin at leon.pl Mon May 2 20:55:07 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Mon, 02 May 2011 20:55:07 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBDD67F.7060202@leon.pl> Message-ID: <4DBEFE0B.8030604@leon.pl> Martin Millnert wrote: > Remco, > > On Sun, May 1, 2011 at 6:18 PM, Remco Van Mook > wrote: >> Marcin Kuczera wrote: >>> Seriously, is there ANY resonable reason why policy for IPv6 PI can not be >>> same as for IPv4 PI ? >> Because the IPv4 PI policy is an unfortunate relic that has seen much uhm, creative use that required a policy such as 2007-01 to clean up and has so far taken dozens of man years to implement? > > Isn't 2007-01 in place for IPv6 PI today already? > >> If you don't want to or can't pay for resources you use, you should be asking yourself questions. >> >> If you're not running a sustainable business, you're exercising a hobby. Why would somebody else pay for your hobby? > > The business *is* sustainable, with IPv4! They're even paying for it > according to the policies of the community. > > How is it even possible that a IPv6 resource, which are practically > infinite, can bear a cost which is ~50x higher for the same use, than > the cost of a IPv4 resource, which is about to run out? If anything, > these are *not* values derived from a market. That's the point ! >> As far as I've seen, the cost of utility power and network hardware in what you describe as 'post communistic block' is not that different from what you describe as 'old Europe', so I'm intrigued how those (I think far more significant) costs affect you. > > Power/network hardware scales closer to number of customers than the > LIR cost, which is a *much* more stepwise cost at small sizes, do. > Maybe we can get one such example ISP with 300-700 customers to show > its books to prove this point. I have asked some of the small ISP's to provide me some simplified data about their businesses. If I get some more, I'll put them on the list. > Now, assuming that point can be proven: that 50 EUR/year is a bearable > cost for IPv4 resources, but ~2000+ EUR for IPv6 is not(*), the > question becomes: > Would the RIPE community like to adjust this unbalance between IPv4 > and IPv6 somehow? > > Any decision/agreement, or lack thereof, has consequences. I.e. RIPE (willing or not) may lead to massive closing of little ISPs, their businesses will be incorporated by those who are LIRs.. Ok, similar process happens all the time, however - RIPE should not act as "regulator"/cathalysator in business domain... Regards, Marcin > > Regards, > Martin > > * It's also not very hard to imagine that the highly competitive > market (good thing, no?) may make it very hard for one ISP to increase > its prices, just to offer IPv6 to its customers via means of being a > LIR, when another may find a much cheaper way to obtain an IPv6 prefix > (from some sponsoring LIR/co-op LIR in some fashion, say, for > example). If that scales up, two things will occur: 1) RIPE's > policies will be overrun, 2) filtering praxis's will be eroded. I > think it's quite optimistic to believe any *registration* policies are > going to hold off this particular piece of reality. > > From swmike at swm.pp.se Tue May 3 07:47:07 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 07:47:07 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: On Sun, 1 May 2011, Martin Millnert wrote: > Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely > 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;) Is this really true? IPv6 PI at 50EUR/year? In the last discussion we had on this list, it was indicated that it was NOT the case, and it would be a lot more expensive (1000+ EUR per year). I am all for raising the yearly IPv4 PI price to the same level as well. Also, if you have a /32 PA it was my understanding that generally the encompassing /29 is already reserved for you as soon as you provide justification, so this will keep down the number of DFZ announcements for PA blocks. That's the main reason I don't want to see IPv6 PI proliferation, we're trying hard to keep down the number of IPv6 DFZ routes, let's not explode it by allowing easy PI. Let's keep the pressure up on other ways to multihome instead. -- Mikael Abrahamsson email: swmike at swm.pp.se From Tero.Toikkanen at nebula.fi Tue May 3 08:41:26 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Tue, 3 May 2011 06:41:26 +0000 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: > Is this really true? IPv6 PI at 50EUR/year? http://www.ripe.net/ripe/docs/ripe-499 "set fee of EUR 50 for each independent Internet number resource assignment" ____________________________________ Tero Toikkanen Nebula Oy From swmike at swm.pp.se Tue May 3 08:50:38 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 08:50:38 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: On Tue, 3 May 2011, Tero Toikkanen wrote: >> Is this really true? IPv6 PI at 50EUR/year? > > http://www.ripe.net/ripe/docs/ripe-499 "set fee of EUR 50 for each independent Internet number resource assignment" Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble. And regarding per-item billing being low, I refer to: No Single Raindrop Belives It Is To Blame For The Flood. -- Mikael Abrahamsson email: swmike at swm.pp.se From leo.vegoda at icann.org Tue May 3 09:09:36 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 3 May 2011 00:09:36 -0700 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBF17F0.3090008@trifle.net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> Message-ID: <05B243F724B2284986522B6ACD0504D7E5D60FD77B@EXVPMBX100-1.exc.icann.org> Hi Andrey, You wrote: > So, the strong recommendation to give customers between a /48 and > a /64 (and /64 even for a single machine) - is the right way to lay the > foundation of a new address space exhaustion Can you describe your concerns in numbers? Thanks, Leo From andrey at trifle.net Mon May 2 22:45:36 2011 From: andrey at trifle.net (Andrey Semenchuk) Date: Mon, 02 May 2011 23:45:36 +0300 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> Message-ID: <4DBF17F0.3090008@trifle.net> Hello Leo Vegoda wrote: >>> Probably the simplest way will be subnet /64 or smaller, where part of >>> IP will be MAC address of enduser. >>> >> The strong recommendation is to give your customers something between a /48 and a /64. >> NO LESS, unless you know for sure(!) that they only have a single machine, and no network >> behind it. >> > > Even if they only have one machine there are advantages to assigning at least a /64. > Actually about 50% of all IPv4 address space was allocated from 1990 till 1995 (five years). Yes, IPv6 provide much more address space but if this address space will be wastefully allocated as IPv4, history will repeat itself Community should be more farseeing to avoid similar situation in future (and if we hope that any toothbrush will pretend for its own IPv6 address - near future) So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From swmike at swm.pp.se Tue May 3 09:46:32 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 09:46:32 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBF17F0.3090008@trifle.net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> Message-ID: On Mon, 2 May 2011, Andrey Semenchuk wrote: > So, the strong recommendation to give customers between a /48 and a /64 > (and /64 even for a single machine) - is the right way to lay the > foundation of a new address space exhaustion If 10 billion people on earth has 10 devices with a /48 for each device, you will have spent approximately one 1/2800th of the IPv6 address space. There are 281 thousand billion /48s. Let's use this current allocation policy until the first /3 is used up, then we have 7 more tries to "get it right" if we decide we need to change something. -- Mikael Abrahamsson email: swmike at swm.pp.se From jim at rfc1035.com Tue May 3 09:53:28 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 3 May 2011 08:53:28 +0100 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: <4DBF17F0.3090008@trifle.net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> Message-ID: <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> On 2 May 2011, at 21:45, Andrey Semenchuk wrote: > Yes, IPv6 provide much more address space but if this address space > will be wastefully allocated as IPv4, history will repeat itself This is just a statement of the bleedin' obvious Andrey. However you don't seem to have any data that shows how current IPv6 allocation policies could repeat those earlier mistakes. > So, the strong recommendation to give customers between a /48 and a / > 64 (and /64 even for a single machine) - is the right way to lay the > foundation of a new address space exhaustion If the Internet doles out a billion /64s every day -- several orders of magnitude more than any forseeable assignment rate -- it will take 50 million years to deplete the IPv6 address space. I'm happy to leave that problem to the next generation. :-) From fweimer at bfk.de Tue May 3 10:10:21 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 03 May 2011 08:10:21 +0000 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> (Jim Reid's message of "Tue\, 3 May 2011 08\:53\:28 +0100") References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> Message-ID: <82liyoxl02.fsf@mid.bfk.de> * Jim Reid: > If the Internet doles out a billion /64s every day -- several orders > of magnitude more than any forseeable assignment rate -- it will take > 50 million years to deplete the IPv6 address space. I'm happy to leave > that problem to the next generation. :-) There have been suggestions to use multiple /24s for each ISP using certain IPv6 deployment strategies. Exhaustion isn't so remote anymore if such efforts become widespread. -- 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 fweimer at bfk.de Tue May 3 10:13:48 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 03 May 2011 08:13:48 +0000 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: (Mikael Abrahamsson's message of "Tue\, 3 May 2011 08\:50\:38 +0200 \(CEST\)") References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: <82hb9cxkub.fsf@mid.bfk.de> * Mikael Abrahamsson: > Oki, I don't know enough about the ripe billing system , but I do know > that if we get many more hundreds of thousands of PI assignments > (regardless of v4 or v6), the global routing system is going to be in > real trouble. And why wouldn't the Internet work with 600,000 prefixes in the DFZ? -- 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 slz at baycix.de Tue May 3 10:08:05 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 3 May 2011 10:08:05 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBF17F0.3090008@trifle.net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> Message-ID: <26D75958-CD50-4BC8-BD0F-1142FB187124@baycix.de> Hay, Am 02.05.2011 um 22:45 schrieb Andrey Semenchuk: [...] > So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion That's not the case. PLEASE use your favorite search engine to find the last thousand discussions about this and do the math yourself. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From turchanyi.geza at gmail.com Tue May 3 10:26:09 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 3 May 2011 10:26:09 +0200 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: <82liyoxl02.fsf@mid.bfk.de> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> <82liyoxl02.fsf@mid.bfk.de> Message-ID: Hi, I support the concerns of Florian. We need addresses for addressing AND ROUTING. In the original design a few bits had been reserved for routing purposes in the IPv6 address scheme just to facilitate routing in the future. These bits completely disappeared -- which is not a a problem in the first phase of the transition, where we are now; however the missing functinality will case problems as the Internet will further grow. Jim, probably you are better expert in this field than me - what do you foresee about scaling of routing and the possibilities of chosing between different backbone service providers in the future? Best, G?za On Tue, May 3, 2011 at 10:10 AM, Florian Weimer wrote: > * Jim Reid: > > > If the Internet doles out a billion /64s every day -- several orders > > of magnitude more than any forseeable assignment rate -- it will take > > 50 million years to deplete the IPv6 address space. I'm happy to leave > > that problem to the next generation. :-) > > There have been suggestions to use multiple /24s for each ISP using > certain IPv6 deployment strategies. Exhaustion isn't so remote > anymore if such efforts become widespread. > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue May 3 10:31:34 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 3 May 2011 09:31:34 +0100 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> <82liyoxl02.fsf@mid.bfk.de> Message-ID: <45FA60DD-C7B1-4D3D-8DFE-5983F839B83E@rfc1035.com> On 3 May 2011, at 09:26, Turchanyi Geza wrote: > Jim, probably you are better expert in this field than me I very much doubt that. > - what do you > foresee about scaling of routing and the possibilities of chosing > between > different backbone service providers in the future? If I knew the answers to your question, I would have a much more lucrative career as a commodities trader or buying lottery tickets. :-) One thing that does worry me is the use of very long prefixes for v6 "to save address space" which then causes the size of DFZ to explode. From marcin at leon.pl Tue May 3 10:46:41 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 03 May 2011 10:46:41 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: <4DBFC0F1.60101@leon.pl> > That's the main reason I don't want to see IPv6 PI proliferation, we're > trying hard to keep down the number of IPv6 DFZ routes, let's not > explode it by allowing easy PI. Let's keep the pressure up on other ways > to multihome instead. ok, look @ this scenario: 1. I'am a SponsorLIR 2. I open second LIR to get next /32, and I merge it immediatelly with my LIR - so I will have x2 /32 3. first of my /32 is used under my main AS only 4. second of my /32 is segmented into /48. Every /48 is advertised under different AS number, of a different little ISP who receives these /48 from me. So - this little (and expansive in first moment) trick also causes that routing table grows up. Now - the money. I'll charge for each /48 50 euro yearly. If /48 would be PI, then RIPE would charge me 50 euro, and I would recharge 50 euro + something. - first case - I earn a lot of money, RIPE - no extra money (except opening a new LIR, just once) - second case - we share ;) I can provide /48 for every operator in PL, exaclty the same way as I do it today with SponsorLIR and IPv4 PI. They don't have to be my downstreams. And you know what, I suppose that this already happens and RIPE can't stop it. If new policy will try to block it, people will find our legal workaround. People are smarter than any institution. Regards, Marcin From turchanyi.geza at gmail.com Tue May 3 10:48:01 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 3 May 2011 10:48:01 +0200 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: <45FA60DD-C7B1-4D3D-8DFE-5983F839B83E@rfc1035.com> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> <82liyoxl02.fsf@mid.bfk.de> <45FA60DD-C7B1-4D3D-8DFE-5983F839B83E@rfc1035.com> Message-ID: > > One thing that does worry me is the use of very long prefixes for v6 "to > save address space" which then causes the size of DFZ to explode. > ??? If an ISP receive max 2 IPv6 blocks, this is just two entries in the (current BGP) routing table. The use of long prefixes in the costumer's network means more costumers served from the same block. Is there a point where we disagree? G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue May 3 11:12:14 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 3 May 2011 10:12:14 +0100 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> <82liyoxl02.fsf@mid.bfk.de> <45FA60DD-C7B1-4D3D-8DFE-5983F839B83E@rfc1035.com> Message-ID: On 3 May 2011, at 09:48, Turchanyi Geza wrote: > If an ISP receive max 2 IPv6 blocks, this is just two entries in the > (current BGP) routing table. > > The use of long prefixes in the costumer's network means more > costumers > served from the same block. > > Is there a point where we disagree? Not with the above. However the initial context of this discussion was about issing PI space to end customers. [For some definition of PI space and end customer.] So if one of those customers was to get one of these long prefixes, they might want to keep it if they switch providers => an extra route for a mickey-mouse amount of space. We know from v4 that this is a Bad Thing. From turchanyi.geza at gmail.com Tue May 3 11:17:47 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 3 May 2011 11:17:47 +0200 Subject: [address-policy-wg] "too many" /64 or /48 assignments causing address space exhaustion In-Reply-To: References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <531E7B5F-D95B-44FB-952C-1AE7E96B8406@rfc1035.com> <82liyoxl02.fsf@mid.bfk.de> <45FA60DD-C7B1-4D3D-8DFE-5983F839B83E@rfc1035.com> Message-ID: On Tue, May 3, 2011 at 11:12 AM, Jim Reid wrote: > On 3 May 2011, at 09:48, Turchanyi Geza wrote: > > If an ISP receive max 2 IPv6 blocks, this is just two entries in the >> (current BGP) routing table. >> >> The use of long prefixes in the costumer's network means more costumers >> served from the same block. >> >> Is there a point where we disagree? >> > > Not with the above. However the initial context of this discussion was > about issing PI space to end customers. [For some definition of PI space and > end customer.] So if one of those customers was to get one of these long > prefixes, they might want to keep it if they switch providers => an extra > route for a mickey-mouse amount of space. We know from v4 that this is a Bad > Thing. > Fully agree. The IPv6 PI space concept is Bad Thing, because creates routing table fragmantation. Short prefix or long prefix - it does not matter. Routing table fragmentation do matter. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Tue May 3 11:16:59 2011 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 03 May 2011 11:16:59 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: <4DBFC80B.6090609@danysek.cz> On 05/03/2011 08:50 AM, Mikael Abrahamsson wrote: > Oki, I don't know enough about the ripe billing system , but I do know > that if we get many more hundreds of thousands of PI assignments > (regardless of v4 or v6), the global routing system is going to be in > real trouble. You'll not solve this problem by any RIPE policy. Deaggregation of assigned address space is here in both IPv4 and IPv6. >40% of announced IPv4 prefixes into global table are unnecessary and this is NOT problem of PI address existence, it's human problem - people are deaggregating their address space. Almost the same thing starts to be happening in IPv6 table. And comercial ISPs simply will NOT filter these deaggregated blocks, because of money - there're only few operators, where clean network setup is necessary - but majority just accepts and announces to the world anything from the customer, because customer is paying money for that. Almost nobody realy cares about PI/PA separation or aggregation, address is just a number from the router point of view. CIDR reports are good proof of this - that's the reality of internet routing. If there will not be regular PI from RIPE (or very limited by the policy), market just finds another "solution" of the problem. And the easy solution is - yes, yes... deaggregation of assigned /32. Some LIRs started carving their /32 IPv6 PA already. I don't think, that blocking IPv6 PI assigments will reduce table growth or bring more members/LIRs. 2007-01 is just cleanup of historic mess. If we'll apply this to IPv6 PI assigments, I don't see reason for blocking IPv6 PI assigments using similar rules, as we have in IPv4 already. Policies for IPv6 should not bring more limitations for assigment compared to IPv4 policies - this will simply slow down IPv6 deployment in networks, where IPv4 PI is used these days. And I'm not supporting any policy, what will slow down IPv6 deployment in real words. And yes, I understand troubles mentioned, I'm aware about hardware limitations of many routing platforms used worldwide. But as I mentioned already, I don't think, that problem of growing global table can be solved just by reducing PI assigments, this is minor part of whole issue... With regards, Daniel From gert at space.net Tue May 3 11:53:37 2011 From: gert at space.net (Gert Doering) Date: Tue, 3 May 2011 11:53:37 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBEF9EF.5080104@leon.pl> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <4DBEF9EF.5080104@leon.pl> Message-ID: <20110503095337.GY30227@Space.Net> Hi On Mon, May 02, 2011 at 08:37:35PM +0200, Marcin Kuczera wrote: > And I understand, that i.e. /64 for subscribers network is something > that in IPv4 PI world would be forbidden (i.e. /29). > If all of us agree, that there is enough address space for every > toothbrush, subscribers can get something between /48 an /64 and this is > will be usual, and even in IPv6 PA space there will be no every subnet > registration (as I understand, and as it is requiured for IPv4 PA) Mostly, yes. > - why IPv6 PI can not be similar to IPv6 PA then ??? This is pretty much what we're going to propose in Thursday's APWG session, reorganize the whole PA/PI structure, possibly completely doing away with the distinction. I'm going to bring up some background info, and then we'll go into the discussion what *the working group* thinks the goal should be - and then we'll take it to the formal policy process to put the ideas in writing. Planned time frame: Thursday, 11:00-12:00, main room (and webcast, of course) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Tue May 3 11:57:06 2011 From: gert at space.net (Gert Doering) Date: Tue, 3 May 2011 11:57:06 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBF17F0.3090008@trifle.net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> Message-ID: <20110503095706.GZ30227@Space.Net> Hi, On Mon, May 02, 2011 at 11:45:36PM +0300, Andrey Semenchuk wrote: > So, the strong recommendation to give customers between a /48 and a /64 > (and /64 even for a single machine) - is the right way to lay the > foundation of a new address space exhaustion Please do some basic math. Number of /56s in FP001, number of people the earth can sustain. How many /56s per person. Add to that that we're only assigning from FP001, so even if it turns out that the world can sustain 1000x more humans than everybody thinks possible today, we have 6 more FPs to try again. Right now, we should try to get rid of conservationist IPv4 thinking, and *do the math* that clearly shows that with IPv6, you can affort that. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From swmike at swm.pp.se Tue May 3 12:39:05 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 12:39:05 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <82hb9cxkub.fsf@mid.bfk.de> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> Message-ID: On Tue, 3 May 2011, Florian Weimer wrote: > * Mikael Abrahamsson: > >> Oki, I don't know enough about the ripe billing system , but I do know >> that if we get many more hundreds of thousands of PI assignments >> (regardless of v4 or v6), the global routing system is going to be in >> real trouble. > > And why wouldn't the Internet work with 600,000 prefixes in the DFZ? Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k). Also, IPv6 uses twice the TCAM resources as IPv4... -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Tue May 3 12:40:57 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 12:40:57 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBFC0F1.60101@leon.pl> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: On Tue, 3 May 2011, Marcin Kuczera wrote: > And you know what, I suppose that this already happens and RIPE can't > stop it. If new policy will try to block it, people will find our legal > workaround. People are smarter than any institution. That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. -- Mikael Abrahamsson email: swmike at swm.pp.se From slz at baycix.de Tue May 3 12:53:06 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 3 May 2011 12:53:06 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> Message-ID: Am 03.05.2011 um 12:39 schrieb Mikael Abrahamsson: > On Tue, 3 May 2011, Florian Weimer wrote: > >> * Mikael Abrahamsson: >> >>> Oki, I don't know enough about the ripe billing system , but I do know >>> that if we get many more hundreds of thousands of PI assignments >>> (regardless of v4 or v6), the global routing system is going to be in >>> real trouble. >> >> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? > > Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k). > > Also, IPv6 uses twice the TCAM resources as IPv4... so, basically what you are saying is that you know that your routers need an upgrade in 5 years and you don't want to pay for an upgrade or you can't figure out a business plan which covers the costs for that? But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get their business plan right if they don't can afford paying $$$ for PI space or rather would prefer to pay other bills with the money? WTF?! Guys, don't discriminate. The cost for independent resources is there just to remind the people that they should give them back if they don't need it anymore (in contrast to the former solution where just abandoning resources didn't cost anyone anything), not to hinder anyone from actually getting them in the first place. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From fweimer at bfk.de Tue May 3 12:55:35 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 03 May 2011 10:55:35 +0000 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: (Mikael Abrahamsson's message of "Tue\, 3 May 2011 12\:39\:05 +0200 \(CEST\)") References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> Message-ID: <82bozkvys8.fsf@mid.bfk.de> * Mikael Abrahamsson: > On Tue, 3 May 2011, Florian Weimer wrote: > >> * Mikael Abrahamsson: >> >>> Oki, I don't know enough about the ripe billing system , but I do know >>> that if we get many more hundreds of thousands of PI assignments >>> (regardless of v4 or v6), the global routing system is going to be in >>> real trouble. >> >> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? > > Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). But this happens every couple of years. The global table has outgrown the capacity of the PFC3C, and before that, of the PFC2. So despite seemingly unescapable hardware limitations, a gradual growth of the prefix count is not much of a problem in itself for the network as a whole. > Also, IPv6 uses twice the TCAM resources as IPv4... This is an implementation detail of one particular vendor. 8-) -- 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 swmike at swm.pp.se Tue May 3 12:59:25 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 12:59:25 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> Message-ID: On Tue, 3 May 2011, Sascha Lenz wrote: > The cost for independent resources is there just to remind the people > that they should give them back if they don't need it anymore (in > contrast to the former solution where just abandoning resources didn't > cost anyone anything), not to hinder anyone from actually getting them > in the first place. That's your opinion, I don't agree. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Tue May 3 13:01:37 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 13:01:37 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <82bozkvys8.fsf@mid.bfk.de> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> <82bozkvys8.fsf@mid.bfk.de> Message-ID: On Tue, 3 May 2011, Florian Weimer wrote: > But this happens every couple of years. The global table has outgrown > the capacity of the PFC3C, and before that, of the PFC2. So despite > seemingly unescapable hardware limitations, a gradual growth of the > prefix count is not much of a problem in itself for the network as a > whole. This is definitely solvable, it just costs money. Money it seems the "polluter" doesn't pay. Sure, one can see it as "cost of doing business" to be an ISP, but it's also easy to see that a prefix in the DFZ most likely costs more than 50EUR per year in equipment having to be paid by SOMEONE. There is no free lunch. -- Mikael Abrahamsson email: swmike at swm.pp.se From danny at danysek.cz Tue May 3 13:16:47 2011 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 03 May 2011 13:16:47 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: <4DBFE41F.2080609@danysek.cz> On 05/03/2011 12:40 PM, Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Marcin Kuczera wrote: > >> And you know what, I suppose that this already happens and RIPE can't >> stop it. If new policy will try to block it, people will find our >> legal workaround. People are smarter than any institution. > > That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. > This doesn't making sense at all. Or then each (!!) PA assigment also must cost 2000EUR (or more, depending on assigment size, as PA assignments are generally larger than PI assignments). If you only increase cost of PI, "smart people" just starts using their PA block divided into several parts... As mentioned by Marcin Kuczera today, this is happening ALREADY... just look into your BGP table, his scenario isn't fiction (just is hapening on their 1st IPv6 PA)... Any policy doesn't block organisation from becoming LIR, obtain maybe in some case "cheaper" PA and then split it into several blocks (and resell it). And nothing will block deaggregated advertisments in the BGP table in effect, as any policy doesn't imply real filtering... Global table will grow anyway, independently of the policy. Restrictions doesn't make sense here, on paper you can wrote anything and each limitation can be circumvented, some people are very creative... Daniel From swmike at swm.pp.se Tue May 3 13:21:56 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 13:21:56 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBFE41F.2080609@danysek.cz> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> <4DBFE41F.2080609@danysek.cz> Message-ID: On Tue, 3 May 2011, Daniel Suchy wrote: > This doesn't making sense at all. Or then each (!!) PA assigment also > must cost 2000EUR (or more, depending on assigment size, as PA > assignments are generally larger than PI assignments). Well, you're already getting charged for the LIR cost, I don't have a problem giving discount for LIR+PA costing the same as PA. > If you only increase cost of PI, "smart people" just starts using their > PA block divided into several parts... As mentioned by Marcin Kuczera > today, this is happening ALREADY... just look into your BGP table, his > scenario isn't fiction (just is hapening on their 1st IPv6 PA)... Well, then I guess we'll just have to make sure we filter at RIR allocation size. If people announce /36 from /32 PA space, we won't accept their routes. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Tue May 3 13:24:13 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 13:24:13 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: On Tue, 3 May 2011, Alex Vishnyakov wrote: > They will rather use NAT IPv4 or PA IPv6, as Marcin Kuczera described. > Also I fully agree with Daniel Suchy. I'm fine with them using NAT. > We have now around 350 customers with PI IPv4 blocks and our customers > decided to NOT implement IPv6 till IPv6 PI policy will not change. > Just imagine - we have now around 350 PI IPv4 blocks and 10 PI IPv6, > it doesn't look like a "IPv6 act now " ! Listen, I don't care about your issues. I'm looking global here. PI is a way to cut costs for future renumbering, for some this is a real issue and they'll be prepared to pay. For some it's just a "nice to have" and they won't use it, and then we won't have to carry their PI in the DFZ. > So, during last year no one user of PI IPv4 became a LIR. They simply > ignore it. So if we will not change the IPv6 policy, these customers > will not implement IPv6 in their networks, or will implement it with > using of PA IPv6 addresses of LIR, but routing table will still growth. No, because people who sub-delegate from /32 PA space won't get their routes spread, just like the /24 situation for IPv4. -- Mikael Abrahamsson email: swmike at swm.pp.se From alexnvis at gmail.com Tue May 3 13:17:54 2011 From: alexnvis at gmail.com (Alex Vishnyakov) Date: Tue, 3 May 2011 13:17:54 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: Hello, Mikael. > That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. Please understand, that it will never happen. People, who are using now PI IPv4 space will never pay extra 2K Euro for IPv6 addresses. It's a historical issue of PI addresses, it's impossible describe to these users the difference between PI v 4 and PI v 6. They will rather use NAT IPv4 or PA IPv6, as Marcin Kuczera described. Also I fully agree with Daniel Suchy. We have now around 350 customers with PI IPv4 blocks and our customers decided to NOT implement IPv6 till IPv6 PI policy will not change. Just imagine - we have now around 350 PI IPv4 blocks and 10 PI IPv6, it doesn't look like a "IPv6 act now " ! So, during last year no one user of PI IPv4 became a LIR. They simply ignore it. So if we will not change the IPv6 policy, these customers will not implement IPv6 in their networks, or will implement it with using of PA IPv6 addresses of LIR, but routing table will still growth. best regards, Alexander Vishnyakov, Tel.: (+420) 257 218 437 | (+420) 603 109 280 Fax: (+420) 257 218 437 ICQ: 164 695 837 Skype: isp-servis-cz Vissado s.r.o. | Hevl?nsk? 435/8, 155 21 Praha 5 www.isp-servis.cz On Tue, May 3, 2011 at 12:40 PM, Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Marcin Kuczera wrote: > >> And you know what, I suppose that this already happens and RIPE can't stop >> it. If new policy will try to block it, people will find our legal >> workaround. People are smarter than any institution. > > That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. > > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > > From alexnvis at gmail.com Tue May 3 13:35:21 2011 From: alexnvis at gmail.com (Alex Vishnyakov) Date: Tue, 3 May 2011 13:35:21 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: > Listen, I don't care about your issues. I'm looking global here. It's your mistake that you don't care, because it's not just my issue - I can bring here to this discussion more then 1000 ISPs from Russia and Ukraine, who are using PIs IPv4 now and want to move to IPv6 technology, but cannot, because of the policy and people like you, and then it will become very quickly a global issue. Or 1000 of ISPs is still a small number for you ? It's more than million potential IPv6 users, content servers etc. best regards, Alex Vishnyakov On Tue, May 3, 2011 at 1:24 PM, Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Alex Vishnyakov wrote: > >> They will rather use NAT IPv4 or PA IPv6, as Marcin Kuczera described. >> Also I fully agree with Daniel Suchy. > > I'm fine with them using NAT. > >> We have now around 350 customers with PI IPv4 blocks and our customers >> decided to NOT implement IPv6 till IPv6 PI policy will not change. >> Just imagine - we have now around 350 PI IPv4 blocks and 10 PI IPv6, >> it doesn't look like a "IPv6 act now " ! > > Listen, I don't care about your issues. I'm looking global here. PI is a way > to cut costs for future renumbering, for some this is a real issue and > they'll be prepared to pay. For some it's just a "nice to have" and they > won't use it, and then we won't have to carry their PI in the DFZ. > >> So, during last year no one user of PI IPv4 became a LIR. They simply >> ignore it. So if we will not change the IPv6 policy, these customers will >> not implement IPv6 in their networks, or will implement it with using of PA >> IPv6 addresses of LIR, but routing table will still growth. > > No, because people who sub-delegate from /32 PA space won't get their routes > spread, just like the /24 situation for IPv4. > > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > From malcolm at linx.net Tue May 3 13:31:51 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Tue, 03 May 2011 12:31:51 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call Message-ID: <4DBFE7A7.7050608@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am afraid I don't believe this policy should be adopted at this time. My reason is that I think it creates a legal and political risk that is substantial and as yet uninvestigated in the PDP, but which may in the long term reduce the overall robustness of Internet infrastructure to an extent that greatly outweigh the security benefits of the policy. This is not a minor, administrative policy. It is (even if not intended as such) the first step in a process the end result of which would be a major change to the Internet architecture. I am afraid that the ultimate outcome could be that the Internet becomes more fragile as a consequence. True, it's only the first step. But if it's a step in the wrong direction, let's not do it. I don't think we should approve this policy until we are certain that this approach is necessary, worth the risk, that no acceptable alternative solutions (or partial solutions) to the problem exist, and that we've also established all appropriate measures to mitigate the foreseeable risks. The complete argument about why I fear a bad outcome will be too long and complex for a first post on this subject, so let me try to give the briefest summary I can manage instead: I believe that if this policy is adopted, and if it is taken up significantly be operators, it will encourage a dramatic increase in the number of demands from law enforcement and private litigants to the RIPE NCC to revoke both allocation of resources and their certificates, without the consent of the person to whom the resource is delegated. Once legislators realise that the NCC has a more effective power to revoke allocations than previously existed, and has become more capable of making networks appear to "go offline" than it currently is able, legislators will likely respond by creating new powers for law enforcement to oblige the NCC to revoke resource allocations as a tool to address undesired behaviour by network users. In short, in a world where reachability is significantly affected by the ability to produce a valid certificate under this policy, the RIPE NCC will be seen as a "one-stop-shop" for knocking networks offline, to control illicit content and online activity. (Perhaps reachability will not be affected because network operators will ignore these certificates, but if we believe that then isn't this policy a waste of time and effort? And operators may not have a free choice: new legal powers were created by the EU last year that could easily be used to compel adoption). Thus, the RIPE NCC would be gradually transformed into a much more political body; indeed, I think at least as political as ICANN currently is. My concerns are not merely academic, they are immediate and practical. We know that many countries, including the EU, have adopted or are actively considering adopting legal requirements for network operators to block packet transit to/from network addresses outside their network in order to inhibit illicit content or activity (e.g. copyright infringement). LEAs already attend RIPE meetings (Co-operation WG) to ask the community to develop policies to transfer allocations of network blocks to the LEA following an allegation by the LEA that the netblock is being used for illicit purposes, the idea being to seize control of routing. Earlier this year the RIPE NCC attended at least one meeting that I know of to discuss this with EU officials. So far the NCC has fended off such requests, I understand, on the grounds that it doesn't have control over routing. If this policy proceeds, is adopted and successful, that argument will be greatly weakened. Would making RIPE NCC such an attractive single point of failure really make the Internet more secure and robust? I believe that before this policy is adopted the community should consider in depth: i) whether these concerns are at least potentially valid (I am convinced they are); ii) If so, whether the problem that this policy addresses is sufficiently serious to warrant accepting these new risks [1]; and iii) Even if the problem is serious enough, whether alternative means to address it could be found that would mitigate these risks [2]. (For example, if the problem could be 80% solved using a model that does not give RIRs a power to revoke and expire certificates "needed" for routing, is the residual 20% of the problem really serious enough to warrant creating the risks I describe). iv) Even if the problem still justifies adopting the approach taken in this policy proposal, what other steps should be taken simultaineously to mitigate these risks. For myself, I am convinced about (i). I have serious doubts about (ii) and (iii) myself, and perhaps more importantly can see no evidence on the list archive that the community has actively assessed whether (ii) is true, and no evidence that other potential architectures or system designs have been considered as a possible alternative that might better mitigate the risks I describe. Nor has there been any visible discussion of (iv). Even if I've missed something, do we really think the community has considered these issues in depth? Or have they been shunted off as a problem to be looked at later, or elsewhere? The presentation at yesterdays RIPE meeting plenary by Randy Bush and the discussion that followed convinced me that there is much more for the community to discuss. I have raised this issue at previous RIPE meetings but only recently become aware that to affect the PDP it was necessary to post on this list, for which my apologies. However I now see such objections are the explicit purpose of the Last Call, so I hope you'll consider this objection carefully. There is much more I could say, but for a first post on the subject I'll leave it at that; I don't want to create a bigger "wall of text" than absolutely necessary. I would be grateful if those who agree with me that this discussion warrants delaying adoption of the proposal would say so now, so that the WG Chair can see whether there is a "serious objection" that prevents a rough consensus being declared at this time. My apologies to those who have worked so long and hard on this, with only the best of motives, on the assumption that there was general support for this approach. But I'm afraid this issue is too important to let this pass without raising my concerns, and asking the community to stand with me. Malcolm. [1] Yes, route hijacking does happen, sometimes by mistake and sometimes by malice. But how often? Are current responses sufficient to deal with it proportionately? Could they be made more effective without any kind of certification scheme? Would something new, that's not a certification scheme suffice? [2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? Could a PKI for address allocations work sufficiently well without investing the hierarchy with authority to revoke certificates? Should we consider an architecture with a distributed issuer/revoker, spread across multiple jurisdictions? What other models exist? - -- 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/ iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O =z7io -----END PGP SIGNATURE----- From danny at danysek.cz Tue May 3 13:41:58 2011 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 03 May 2011 13:41:58 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> <4DBFE41F.2080609@danysek.cz> Message-ID: <4DBFEA06.5010304@danysek.cz> On 05/03/2011 01:21 PM, Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Daniel Suchy wrote: > >> This doesn't making sense at all. Or then each (!!) PA assigment also >> must cost 2000EUR (or more, depending on assigment size, as PA >> assignments are generally larger than PI assignments). > > Well, you're already getting charged for the LIR cost, I don't have a > problem giving discount for LIR+PA costing the same as PA. Not really. As LIR, I can obtain second, third, fourth PA and I'll pay almost the same membership fee. Well, there will be slight change due to category change - but extra large LIR pays 5500EUR - that's less than cost of three PI blocks in your pricing scheme and much larger address space available for anything... > Well, then I guess we'll just have to make sure we filter at RIR > allocation size. If people announce /36 from /32 PA space, we won't > accept their routes. And who does that, in reality? Just look into global BGP table, look on prefixes advertised by Google, for example. Reality is, that people deaggregates right now and nobody filters them. Prefixes are announced by customers and customers are paying for that to their upstream providers. In the fact, not policy, but sales department controls, what is announced in global tables. Daniel From swmike at swm.pp.se Tue May 3 13:43:29 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 13:43:29 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: On Tue, 3 May 2011, Alex Vishnyakov wrote: > It's your mistake that you don't care, because it's not just my issue - > I can bring here to this discussion more then 1000 ISPs from Russia and > Ukraine, who are using PIs IPv4 now and want to move to IPv6 technology, > but cannot, because of the policy and people like you, and then it will > become very quickly a global issue. Or 1000 of ISPs is still a small > number for you ? It's more than million potential IPv6 users, content > servers etc. You're seriously saying 2EUR per year per customer (1000 customers) breaks their back? If it does, then they should look into other solutions such as renumbering each time they switch upstream provider instead of externalising the cost to the rest of the world. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Tue May 3 13:45:49 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 13:45:49 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DBFEA06.5010304@danysek.cz> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> <4DBFE41F.2080609@danysek.cz> <4DBFEA06.5010304@danysek.cz> Message-ID: On Tue, 3 May 2011, Daniel Suchy wrote: > Not really. As LIR, I can obtain second, third, fourth PA and I'll pay > almost the same membership fee. Well, there will be slight change due to > category change - but extra large LIR pays 5500EUR - that's less than > cost of three PI blocks in your pricing scheme and much larger address > space available for anything... I surely hope not, then the current policy is defective. Last I heard, RIPE made reservation for growth when handing out first /32, so next it'll be /31, /30 etc, up to the reserved /29. -- Mikael Abrahamsson email: swmike at swm.pp.se From alexnvis at gmail.com Tue May 3 13:53:45 2011 From: alexnvis at gmail.com (Alex Vishnyakov) Date: Tue, 3 May 2011 13:53:45 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: > If it does, then they should look into other solutions such as renumbering > each time they switch upstream provider instead of externalising the cost to > the rest of the world. > Thank you for your link, I appreciate your help in this issue... > You're seriously saying 2EUR per year per customer (1000 customers) breaks > their back? Try to explain it to them. You don't understand that few thousands of ISPs are using PI IPv4 and your policy limitation will not change their behaviour. You had to forbid PI IPv4 to end-users in the past, but not to make some prohibitions in the IPv6 policy. Regarding filtering IPv6 prefixes I agree with Daniel Suchy, I think there will be a lot of people (let's say 99% ?:-)) who will not do it. best regards, Alex Vishnyakov On Tue, May 3, 2011 at 1:43 PM, Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Alex Vishnyakov wrote: > >> It's your mistake that you don't care, because it's not just my issue - I >> can bring here to this discussion more then 1000 ISPs from Russia and >> Ukraine, who are using PIs IPv4 now and want to move to IPv6 technology, but >> cannot, because of the policy and people like you, and then it will become >> very quickly a global issue. Or 1000 of ISPs is still a small number for you >> ? It's more than million potential IPv6 users, content servers etc. > > You're seriously saying 2EUR per year per customer (1000 customers) breaks > their back? > > If it does, then they should look into other solutions such as renumbering > each time they switch upstream provider instead of externalising the cost to > the rest of the world. > > > > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > From danny at danysek.cz Tue May 3 14:04:32 2011 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 03 May 2011 14:04:32 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> <4DBFE41F.2080609@danysek.cz> <4DBFEA06.5010304@danysek.cz> Message-ID: <4DBFEF50.7070009@danysek.cz> On 05/03/2011 01:45 PM, Mikael Abrahamsson wrote: > > I surely hope not, then the current policy is defective. Last I heard, > RIPE made reservation for growth when handing out first /32, so next > it'll be /31, /30 etc, up to the reserved /29. > But, PI has minimum at /48. In /32, there're 65536 /48 blocks. And costs of LIR doesn't increase so much, if he moves from /32 to /31, 30... (and similary in IPv4). Thats' the point... And probably nobody will support change in current billing policy of RIPE NCC towards higher cost of larger PA assignments (=increase it's own costs). Daniel From marcin at leon.pl Tue May 3 14:32:28 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 03 May 2011 14:32:28 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> Message-ID: <4DBFF5DC.6040709@leon.pl> Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Florian Weimer wrote: > >> * Mikael Abrahamsson: >> >>> Oki, I don't know enough about the ripe billing system , but I do know >>> that if we get many more hundreds of thousands of PI assignments >>> (regardless of v4 or v6), the global routing system is going to be in >>> real trouble. >> >> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? > > Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). > > Also, IPv6 uses twice the TCAM resources as IPv4... good, I think that all hardware vendors will be happy to sell new equimpment Marcin From marcin at leon.pl Tue May 3 14:34:13 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 03 May 2011 14:34:13 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBFC0F1.60101@leon.pl> Message-ID: <4DBFF645.8010009@leon.pl> Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Marcin Kuczera wrote: > >> And you know what, I suppose that this already happens and RIPE can't >> stop it. If new policy will try to block it, people will find our >> legal workaround. People are smarter than any institution. > > That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. Yeap, do what all the stupid governments do, increase taxes, if it doesn't work - put people into a prison and add more taxes (prisons are expansive)... Marcin From marcin at leon.pl Tue May 3 14:38:14 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 03 May 2011 14:38:14 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <82hb9cxkub.fsf@mid.bfk.de> Message-ID: <4DBFF736.6040002@leon.pl> Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Sascha Lenz wrote: > >> The cost for independent resources is there just to remind the people >> that they should give them back if they don't need it anymore (in >> contrast to the former solution where just abandoning resources didn't >> cost anyone anything), not to hinder anyone from actually getting them >> in the first place. > > That's your opinion, I don't agree. Well, if you don't agree (you have a right to) please list some arguments that will change others opinion. I personally support Sascha arguments. Regards, Marcin From boggits at gmail.com Tue May 3 14:30:59 2011 From: boggits at gmail.com (boggits) Date: Tue, 3 May 2011 14:30:59 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DBFE7A7.7050608@linx.net> References: <4DBFE7A7.7050608@linx.net> Message-ID: On 3 May 2011 13:31, Malcolm Hutty wrote: > I am afraid I don't believe this policy should be adopted at this time. I agree that it should at least re-visited as some of the wider implications might have been missed in the process as the focus has been with the technical solution to the 'problem' rather than potential for 'outside influence'. I'm also worried that the discussion seem to have moved to an automated router based implementation rather than an abstracted policy implementation that an operator can make an informed decision on with the ability to override it (in the same way that someone would build per peer filters today). I always understood (possibly wrongly) that this was about improving the quality of the RIPE (and other IRR) dbs rather than automating a DoS/LEA toy that *will* cause problems in the same way fat fingering today causes these issues. J -- James Blessing 07989 039 476 From millnert at gmail.com Tue May 3 15:22:01 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 3 May 2011 09:22:01 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DBFE7A7.7050608@linx.net> References: <4DBFE7A7.7050608@linx.net> Message-ID: APWG, I agree completely with what Malcolm says and wholeheartedly share his concerns in this area. We should all think real long and hard about the possible long-term implications of what this proposal sets the foundation for. In its essence this is a philosophical (which often intersects with political views) question that goes to the roots of each and every one of us. Personally, I firmly believe the strength and resilience of the Internet and the communication it enables (a tremendous asset for humanity in itself) lies in its distributed nature; not just in redundant communication links and routing protocols providing resilient routing, but a diverse political control. BGP hijack *is* a concern, but, it is most definitely a secondary or tertiary problem to the system at large IMNSHO. While I'm by no means suggesting we should not improve ourselves, I do believe we've handled these problems pretty well so far. The Internet *will not* fall over and die if we step back and take a deep breath on this topic. We have our RIS/BGPlay/Cyclops and pretty active BGP operators for the most part - I think we can "hold down the fort" while we convince ourselves that we have covered *all* aspects of this issue, and not mistakenly hasten anything through. I have not seen the concerns that Malcolm raises thoroughly debated or researched anywhere. The only debate I've seen has been a few threads on NANOG... I'd appreciate pointers to more of such research/debates if I have missed it (didn't find it on APWG, for instance.) I've personally initiated some early contact with the Tor community, because they are a very good bunch of people in analyzing Internet security from a privacy/freedom standpoint. I think more and similar contacts should be engaged. Rest assured, the people who have these concerns are *not* trying to stall RPKI just for the sake of stalling it! The concerns Malcom bring up, which I share, are very legitimate and I fully recommend we do not adopt this proposal until these issues have been more thoroughly addressed. And for the record, I do not believe surrendering to bureaucrats/lawmakers' pressure by doing their bidding is a positive evolution of our society. I'm far from any anarchist - I strongly believe in democracy with all its flaws, but a free, open and democratic society is not self-preserving by its own momentum as far as I have learned in life (seems to be quite the contrary). There actually has to be people constantly working to keep it this way, else it wither and rust away. We are those people. Or at least should be, IMO. The Internet is far too important for us not to be. Convince me these concerns are not valid, and this proposal has my support. Kind regards, Martin On Tue, May 3, 2011 at 7:31 AM, Malcolm Hutty wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am afraid I don't believe this policy should be adopted at this time. > > My reason is that I think it creates a legal and political risk that is > substantial and as yet uninvestigated in the PDP, but which may in the > long term reduce the overall robustness of Internet infrastructure to an > extent that greatly outweigh the security benefits of the policy. > > This is not a minor, administrative policy. It is (even if not intended > as such) the first step in a process the end result of which would be a > major change to the Internet architecture. I am afraid that the ultimate > outcome could be that the Internet becomes more fragile as a > consequence. True, it's only the first step. But if it's a step in the > wrong direction, let's not do it. > > I don't think we should approve this policy until we are certain that > this approach is necessary, worth the risk, that no acceptable > alternative solutions (or partial solutions) to the problem exist, and > that we've also established all appropriate measures to mitigate the > foreseeable risks. > > The complete argument about why I fear a bad outcome will be too long > and complex for a first post on this subject, so let me try to give the > briefest summary I can manage instead: > > I believe that if this policy is adopted, and if it is taken up > significantly be operators, it will encourage a dramatic increase in the > number of demands from law enforcement and private litigants to the RIPE > NCC to revoke both allocation of resources and their certificates, > without the consent of the person to whom the resource is delegated. > > Once legislators realise that the NCC has a more effective power to > revoke allocations than previously existed, and has become more capable > of making networks appear to "go offline" than it currently is able, > legislators will likely respond by creating new powers for law > enforcement to oblige the NCC to revoke resource allocations as a tool > to address undesired behaviour by network users. > > In short, in a world where reachability is significantly affected by the > ability to produce a valid certificate under this policy, the RIPE NCC > will be seen as a "one-stop-shop" for knocking networks offline, to > control illicit content and online activity. > > ? ? (Perhaps reachability will not be affected because network > ? ? operators will ignore these certificates, but if we believe that > ? ? then isn't this policy a waste of time and effort? And operators > ? ? may not have a free choice: new legal powers were created by the > ? ? EU last year that could easily be used to compel adoption). > > Thus, the RIPE NCC would be gradually transformed into a much more > political body; indeed, I think at least as political as ICANN currently is. > > My concerns are not merely academic, they are immediate and practical. > We know that many countries, including the EU, have adopted or are > actively considering adopting legal requirements for network operators > to block packet transit to/from network addresses outside their network > in order to inhibit illicit content or activity (e.g. copyright > infringement). LEAs already attend RIPE meetings (Co-operation WG) to > ask the community to develop policies to transfer allocations of network > blocks to the LEA following an allegation by the LEA that the netblock > is being used for illicit purposes, the idea being to seize control of > routing. Earlier this year the RIPE NCC attended at least one meeting > that I know of to discuss this with EU officials. So far the NCC has > fended off such requests, I understand, on the grounds that it doesn't > have control over routing. If this policy proceeds, is adopted and > successful, that argument will be greatly weakened. > > Would making RIPE NCC such an attractive single point of failure really > make the Internet more secure and robust? > > I believe that before this policy is adopted the community should > consider in depth: > > i) whether these concerns are at least potentially valid (I am convinced > they are); > > ii) If so, whether the problem that this policy addresses is > sufficiently serious to warrant accepting these new risks [1]; and > > iii) Even if the problem is serious enough, whether alternative means to > address it could be found that would mitigate these risks [2]. (For > example, if the problem could be 80% solved using a model that does not > give RIRs a power to revoke and expire certificates "needed" for > routing, is the residual 20% of the problem really serious enough to > warrant creating the risks I describe). > > iv) Even if the problem still justifies adopting the approach taken in > this policy proposal, what other steps should be taken simultaineously > to mitigate these risks. > > For myself, I am convinced about (i). I have serious doubts about (ii) > and (iii) myself, and perhaps more importantly can see no evidence on > the list archive that the community has actively assessed whether (ii) > is true, and no evidence that other potential architectures or system > designs have been considered as a possible alternative that might better > mitigate the risks I describe. Nor has there been any visible discussion > of (iv). > > Even if I've missed something, do we really think the community has > considered these issues in depth? Or have they been shunted off as a > problem to be looked at later, or elsewhere? > > The presentation at yesterdays RIPE meeting plenary by Randy Bush and > the discussion that followed convinced me that there is much more for > the community to discuss. > > I have raised this issue at previous RIPE meetings but only recently > become aware that to affect the PDP it was necessary to post on this > list, for which my apologies. However I now see such objections are the > explicit purpose of the Last Call, so I hope you'll consider this > objection carefully. > > There is much more I could say, but for a first post on the subject I'll > leave it at that; I don't want to create a bigger "wall of text" than > absolutely necessary. > > I would be grateful if those who agree with me that this discussion > warrants delaying adoption of the proposal would say so now, so that the > WG Chair can see whether there is a "serious objection" that prevents a > rough consensus being declared at this time. > > My apologies to those who have worked so long and hard on this, with > only the best of motives, on the assumption that there was general > support for this approach. But I'm afraid this issue is too important to > let this pass without raising my concerns, and asking the community to > stand with me. > > Malcolm. > > [1] Yes, route hijacking does happen, sometimes by mistake and sometimes > by malice. But how often? Are current responses sufficient to deal with > it proportionately? Could they be made more effective without any kind > of certification scheme? Would something new, that's not a certification > scheme suffice? > > [2] For example, could we creates "webs of trust" rather than a single > hierarchy? Would that be "good enough" or is a hierarchy essential? > Could a PKI for address allocations work sufficiently well without > investing the hierarchy with authority to revoke certificates? Should we > consider an architecture with a distributed issuer/revoker, spread > across multiple jurisdictions? What other models exist? > > - -- > ? ? ? ? ? ?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/ > > iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l > ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O > =z7io > -----END PGP SIGNATURE----- > > From poty at iiat.ru Tue May 3 15:37:08 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Tue, 3 May 2011 17:37:08 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: >> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? > > Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k). > > Also, IPv6 uses twice the TCAM resources as IPv4... so, basically what you are saying is that you know that your routers need an upgrade in 5 years and you don't want to pay for an upgrade or you can't figure out a business plan which covers the costs for that? But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get their business plan right if they don't can afford paying $$$ for PI space or rather would prefer to pay other bills with the money? WTF?! ------ No, the problem that the small ISPs you are speaking about will have to spend that money to swallow such routing table. And it is not $2000, "slightly" more... From ebais at a2b-internet.com Tue May 3 15:42:04 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 3 May 2011 15:42:04 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> Message-ID: <001f01cc0997$e3a5fe40$aaf1fac0$@com> Hi James & Malcolm, > I agree that it should at least re-visited as some of the wider > implications might have been missed in the process as the focus has > been with the technical solution to the 'problem' rather than > potential for 'outside influence'. The policy by itself doesn't require you to automate the process within your network to accept / deny / discard prefixes. If I speak for myself, I know that I won't be the first to start using in network prefix alterations based on the information within the RPKI db. I will however use the repository to check if what my customers want to start to announce to our network. And when PI is going to be accepted after this policy, also PI. The question is not what you are planning to do within your network with this or how paranoid you plan to be in regards to the tools around this. If you don't want to use the provided tools from RIPE NCC, run your own CA. If you don't want to use RPKI, fine as well, no-body is forcing you. However with the hijacking of (legacy) IP space and ownership of especially pre-rir IP space, we need to get a policy in place that will allow us to do this. Is the current policy perfect ? As in, final and all inclusive etc ? nope.. Is it a good start ? Imho.. a full YES ! I would strongly suggest to get on the RPKI support bandwagon and get the current policy in front of us approved and work together on how we can get the other stuff included in the next version. I'm on the RIPE meeting atm, let's have a cup of coffee if needed on the topic. Regards, Erik Bais From swmike at swm.pp.se Tue May 3 16:03:56 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 16:03:56 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: On Tue, 3 May 2011, poty at iiat.ru wrote: > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you don't want to pay for an upgrade or > you can't figure out a business plan which covers the costs for that? Paying for the upgrade by having higher prices towards end-customer is what is going to happen all across the world if we get hundreds of thousands of Ipv6 PI. So everybody pays, just not the ones causing the problem. Classic externalising of costs. See my earlier links. > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right if they don't can afford paying $$$ for PI > space or rather would prefer to pay other bills with the money? WTF?! I guess you don't belive in "polluter pays". -- Mikael Abrahamsson email: swmike at swm.pp.se From richih.mailinglist at gmail.com Tue May 3 16:13:29 2011 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 3 May 2011 16:13:29 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: On Tue, May 3, 2011 at 16:03, Mikael Abrahamsson wrote: > Paying for the upgrade by having higher prices towards end-customer is what > is going to happen all across the world if we get hundreds of thousands of > Ipv6 PI. So everybody pays, just not the ones causing the problem. Classic > externalising of costs. See my earlier links. You did not establish any proof that there will be hundreds of thousands of additional PI prefixes in global routing tables. I find this claim questionable, at best. > I guess you don't belive in "polluter pays". It seems to me that ? 50 / year * PI prefix is a cost that's being paid today. Of course, you are free to argue that this is not enough. Maybe more people would agree with you if you wouldn't use ridiculously inflated numbers, both for the projected PI prefixes and your desired price of ? 2000 / year * PI prefix. Or tried to write your emails in a slightly less heated manner. Best regards, Richard From swmike at swm.pp.se Tue May 3 16:20:42 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 3 May 2011 16:20:42 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: On Tue, 3 May 2011, Richard Hartmann wrote: > Maybe more people would agree with you if you wouldn't use ridiculously > inflated numbers, both for the projected PI prefixes and your desired > price of ? 2000 / year * PI prefix. Or tried to write your emails in a > slightly less heated manner. I am not stupid, I of course know RIPE is never going to charge 2kEUR per year for PI even if I want them to. Also, I am going to save this email and bring it out in 5 years and let's see how many 50EUR/year PIs there are in the world then. I guess that's the only way to find out. I am not heated, I am resigned about nobody here caring about the common good. Seems shared cost is "someone elses problem". As long as "my hobby project" is important to me, I should get to pollute without paying. And at 50EUR per year, heck, I'd PI my home connection in a blink. Why wouldn't anyone? -- Mikael Abrahamsson email: swmike at swm.pp.se From pk336u at intl.att.com Tue May 3 16:12:40 2011 From: pk336u at intl.att.com (Kovac, Pavol) Date: Tue, 3 May 2011 07:12:40 -0700 Subject: [address-policy-wg] help Message-ID: <4D802C4079A49043A299A53593DCCF797A07B372D8@skcbcmsx01.emea.att.com> Dear RIPE wg, I would like to ask you about present proposal "Removal of Multihomed requirement for IPv6 PI" version 1.0 12 April 2011. I see Current Phase Ends: 13 May 2011. What will happened after 13rd May ? I registered as a subscriber of this mailing list. Will I receive any info about changes on this proposal ? Thank you Pavol Kovac -------------- next part -------------- An HTML attachment was scrubbed... URL: From millnert at gmail.com Tue May 3 16:23:29 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 3 May 2011 10:23:29 -0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: On Tue, May 3, 2011 at 9:37 AM, wrote: >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Not really; normal PC RAM is pretty cheap. 16GB ECC/REG ~400 EUR. /M From gert at space.net Tue May 3 16:31:43 2011 From: gert at space.net (Gert Doering) Date: Tue, 3 May 2011 16:31:43 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <20110503143143.GG30227@Space.Net> Hi, On Tue, May 03, 2011 at 04:20:42PM +0200, Mikael Abrahamsson wrote: > And at 50EUR per year, heck, I'd PI my home connection in a blink. Why > wouldn't anyone? Well, it's a bit more to it than just the 50 EUR - as of today, most cheap end user DSL connections will not route arbitrary PI networks for customers, but instead will insist on automatic assignment of addresses (coming from a block aggregated by the ISP, whatever you call it) to the end users. So you need a "business connection" and that will be more than 50 EUR/year. Of course one of the big Telcos might decide that this is *the* product to compensate for loss of customers due to , but I seriously don't really see it happen any time soon, not for the large masses of end customers. We'll have some "PI" in the global table, of course. But please look at Alex Le Heux' numbers that will be presented on Thursday morning (about 10:00) on what makes up the bulk of the current IPv4 routing table - and you might be surprised. 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 millnert at gmail.com Tue May 3 16:31:43 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 3 May 2011 10:31:43 -0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: Mikael, On Tue, May 3, 2011 at 10:20 AM, Mikael Abrahamsson wrote: > On Tue, 3 May 2011, Richard Hartmann wrote: > >> Maybe more people would agree with you if you wouldn't use ridiculously >> inflated numbers, both for the projected PI prefixes and your desired price >> of ? 2000 / year * PI prefix. Or tried to write your emails in a slightly >> less heated manner. > > I am not stupid, I of course know RIPE is never going to charge 2kEUR per > year for PI even if I want them to. > > Also, I am going to save this email and bring it out in 5 years and let's > see how many 50EUR/year PIs there are in the world then. I guess that's the > only way to find out. > > I am not heated, I am resigned about nobody here caring about the common > good. Seems shared cost is "someone elses problem". As long as "my hobby > project" is important to me, I should get to pollute without paying. > > And at 50EUR per year, heck, I'd PI my home connection in a blink. Why > wouldn't anyone? Why don't you? :) I'll just re-iterate an earlier point I made in this thread: If a routing protocol can't scale in the core, it's either applied wrong or there is a problem with the protocol design itself. I don't think taxing people away is a good sustainable/stable approach to solving the problem of the routing protocol in question. In the context of a potential (not certain) explosion of *both* IPv4 and IPv6 prefixes in the BGP DFZ's, LISP or other specific solutions to the expensive core *may* become necessary. My view is that *if* this explosion comes, it does so fully regardless of RIPE's PI/PA IPv6 policies. Regards, Martin From lists-ripe at c4inet.net Tue May 3 16:36:26 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 3 May 2011 14:36:26 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy Message-ID: <20110503143626.GB26053@cilantro.c4inet.net> Hi ap-wg, I do NOT support this proposal for the very same reasons that Malcolm so eruditely laid out in his post. All that's left for me is to state that, in this case, the cure is infinitely worse than the disease. Kind Regards, Sascha Luck From richih.mailinglist at gmail.com Tue May 3 16:40:57 2011 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 3 May 2011 16:40:57 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: On Tue, May 3, 2011 at 16:20, Mikael Abrahamsson wrote: > I am not stupid, I of course know RIPE is never going to charge 2kEUR per > year for PI even if I want them to. Wouldn't it make sense to argue for goals you have a chance of achieving instead of dragging out a fringe discussion about things that will not happen anyway? > Also, I am going to save this email and bring it out in 5 years and let's > see how many 50EUR/year PIs there are in the world then. I guess that's the > only way to find out. Fine by me. To put my money where my mouth is and as "hundreds of thousands" implies 200,001 or more, how about this bet: If, on the 1st of May, 2016, there are 200,001 or more IPv6 PI routes (1/5th of which need to be from RIPE space) in the global routing table, I will owe you one good bottle of rum. If this condition is not met, you owe me a good bottle of rum. "Good" means all rums in the blend need to be at least 8 years old and it must not be from any company manufacturing industrial paint solvents like Bacardi or Havanna Club. I maintain a separate calendar for bets so this would not get lost. > I am not heated, I am resigned about nobody here caring about the common > good. Your definition of the common good seems to diverge from the one most of the other people posting in this thread. Disagreement is fine, implying others are careless and ignorant, not so much. > Seems shared cost is "someone elses problem". As long as "my hobby > project" is important to me, I should get to pollute without paying. Again, ? 50 / year * PI prefix is not free. > And at 50EUR per year, heck, I'd PI my home connection in a blink. Why > wouldn't anyone? Mainly because you do not have a need and will not get it routed on a normal home connection. Same as for almost all other home, or business, connections. Richard PS: Arguably, "hundreds of thousands" means 300,001 or more, but I am confident 200,001 will not be reached so the point is moot. From lists at c4inet.net Tue May 3 16:26:43 2011 From: lists at c4inet.net (Mailing List Account) Date: Tue, 3 May 2011 14:26:43 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DBFE7A7.7050608@linx.net> References: <4DBFE7A7.7050608@linx.net> Message-ID: <20110503142643.GA26053@cilantro.c4inet.net> Hi ap-wg, I do NOT support this proposal for the very same reasons that Malcolm so eruditely laid out in his post. All that's left for me is to state that, in this case, the cure is infinitely worse than the disease. Kind Regards, Sascha Luck From marcin at leon.pl Tue May 3 16:46:48 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 03 May 2011 16:46:48 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <4DC01558.4090702@leon.pl> poty at iiat.ru wrote: >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... frankly... small ISPs run on Linux/BSD... 4 core, 8 core, 16 core, 64G of memory, more and more stable kernels, drivers etc... If they don't want to pay LIR expanses, they will also resist to buy Cisco/Juniper/Ericssn/whatever based on ASICs.. Regards, Marcin From fweimer at bfk.de Tue May 3 16:49:24 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 03 May 2011 14:49:24 +0000 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: (Mikael Abrahamsson's message of "Tue\, 3 May 2011 16\:20\:42 +0200 \(CEST\)") References: Message-ID: <82ei4fvnyj.fsf@mid.bfk.de> * Mikael Abrahamsson: > I am not heated, I am resigned about nobody here caring about the > common good. Equal access to IP addresses for a nominal fee (covering registration processing costs) is a common good, too. 8-) -- 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 ms at uakom.sk Tue May 3 16:38:25 2011 From: ms at uakom.sk (Martin Stanislav) Date: Tue, 3 May 2011 16:38:25 +0200 Subject: [address-policy-wg] help In-Reply-To: <4D802C4079A49043A299A53593DCCF797A07B372D8@skcbcmsx01.emea.att.com> References: <4D802C4079A49043A299A53593DCCF797A07B372D8@skcbcmsx01.emea.att.com> Message-ID: <20110503143825.GF22679@moon.uakom.sk> Hi Pavol, On Tue, May 03, 2011 at 07:12:40AM -0700, Kovac, Pavol wrote: > > I would like to ask you about present proposal "Removal of Multihomed requirement for IPv6 PI" version 1.0 12 April 2011. I see Current Phase Ends: 13 May 2011. What will happened after 13rd May ? See "Policy Development Process in RIPE", Appendix A: Policy Development Process Diagram http://www.ripe.net/ripe/docs/ripe-500#appendixa & AP-WG mailing list archives. > I registered as a subscriber of this mailing list. Will I receive any info about changes on this proposal ? Short answer ? Yes. Martin From slz at baycix.de Tue May 3 17:06:02 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 3 May 2011 17:06:02 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <6F958C4B-17D3-4D4C-9337-172506553B92@baycix.de> Hay, Am 03.05.2011 um 15:37 schrieb : >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Small companies start with small routers, PC based Linux Quagga Boxes, or Routerboards, or Juniper J-Series or whatever - not really much costs here (see other replies). If they become bigger, they need to take into account that bigger boxes cost more money, or they decide to stay small. In any way, PI space is about END-USERS, not about ISPs so much anyways. So if you're a small ISP, with this thinking in mind that you don't want more prefixes in the DFZ, you are basically saying that you don't want any more highlevel customers by raising the entry level for such endusers who require this kind of service (full BGP redundancy)? You rather serve homeusers for cheap money which never get you enough revenue? You don't want new startups competing with your company? ...or what? What's the point about all you guys who want to prevent new people to be in the DFZ? Is there any reasonable point which isn't selfish? I just don't get it for some years now. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From slz at baycix.de Tue May 3 17:22:36 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 3 May 2011 17:22:36 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: Hay, Am 03.05.2011 um 16:03 schrieb Mikael Abrahamsson: > On Tue, 3 May 2011, poty at iiat.ru wrote: > >> so, basically what you are saying is that you know that your routers need an upgrade in 5 years and you don't want to pay for an upgrade or you can't figure out a business plan which covers the costs for that? > > Paying for the upgrade by having higher prices towards end-customer is what is going to happen all across the world if we get hundreds of thousands of Ipv6 PI. So everybody pays, just not the ones causing the problem. Classic externalising of costs. See my earlier links. > It's exactly the other way round. The big ISPs sell Internet at ridiculous low price points, just to have the most customers in their market or just to win a bid over a multi million $$$ project over their competitors. Now they complain that they cannot keep up with the growth of the Internet/the DFZ and want to stop new people or even competitors to join in? (Not to forget: Try to make content providers pay for transporting date to their own customers, see "net neutrality...") And you really think you have a valid argument there that the prices need to be raised for everyone? They shouldn't have gone down so far in the first place if you had a good business plan! But of course, now that is too late. It's like the financial crisis all over again... big companies complaining they are out of money, please someone else pay for us and protect us from new competitors. >> But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get their business plan right if they don't can afford paying $$$ for PI space or rather would prefer to pay other bills with the money? WTF?! > > I guess you don't belive in "polluter pays". You first have to prove to us that adding prefixes to the DFZ is pollution as long as it's not useless de-aggregates. Who are you to decide which entity is allowed to be in the DFZ and which isn't - the god of the internet? If you decide to get multihomed in your bedroom, get two BGP Upstreams and multihome. I don't care. I guess you are educated enough that you know what you are doing and why you need to do this and the RIPE NCC hostmas...i mean... IPRAs :-) will have double checked that you have valid reasons so i'm fine! Probably you will set up the next Facebook or the next Twitter in your bedroom...wouldn't that be great for the Internet? -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From boggits at gmail.com Tue May 3 16:59:23 2011 From: boggits at gmail.com (boggits) Date: Tue, 3 May 2011 16:59:23 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <001f01cc0997$e3a5fe40$aaf1fac0$@com> References: <4DBFE7A7.7050608@linx.net> <001f01cc0997$e3a5fe40$aaf1fac0$@com> Message-ID: On 3 May 2011 15:42, Erik Bais wrote: > Hi James & Malcolm, > >> I agree that it should at least re-visited as some of the wider >> implications might have been missed in the process as the focus has >> been with the technical solution to the 'problem' rather than >> potential for 'outside influence'. > > The policy by itself doesn't require you to automate the process within your > network to accept / deny / discard prefixes. No but listening to people describing it as an automated tool for routers to make decisions really scared me... > I will however use the repository to check if what my customers want to > start to announce to our network. And when PI is going to be accepted after > this policy, also PI. This a useful function of the RPKI (and the use that I expected this for, when it moves to automation then I have the fear. > The question is not what you are planning to do within your network with > this or how paranoid you plan to be in regards to the tools around this. > If you don't want to use the provided tools from RIPE NCC, run your own CA. > If you don't want to use RPKI, fine as well, no-body is forcing you. Actually they way its being described (as a security tool) its being pushed as a "must use" rather than nice tool. > However with the hijacking of (legacy) IP space and ownership of especially > pre-rir IP space, we need to get a policy in place that will allow us to do > this. Really? Would a policy to get the legacy space under control and ownership more tightly recorded be more useful for the community as a whole. > Is the current policy perfect ? As in, final and all inclusive etc ? ?nope.. Agreed > Is it a good start ? Imho.. a full YES ! Er, there is a difference - its a good idea, but I don't think its ready for showtime considering how people are talking about using it... Is bit-torrent a good idea? Is it an efficient way of distributing content for the content owner? Shouldn't all content be distributed using bit-torrent? depending on who you are and where you sit in the value chain you'll give different answers to the above questions but you'll agree that bit-torrent is a really clever solution to the problem of content distribution. > I'm on the RIPE meeting atm, let's have a cup of coffee if needed on the :) /me sets phaser on lightly disintegrate... J -- James Blessing 07989 039 476 From lists-ripe at c4inet.net Tue May 3 17:44:22 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 3 May 2011 15:44:22 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <001f01cc0997$e3a5fe40$aaf1fac0$@com> References: <4DBFE7A7.7050608@linx.net> <001f01cc0997$e3a5fe40$aaf1fac0$@com> Message-ID: <20110503154422.GA27143@cilantro.c4inet.net> On Tue, May 03, 2011 at 03:42:04PM +0200, Erik Bais wrote: >The question is not what you are planning to do within your network with >this or how paranoid you plan to be in regards to the tools around this. >If you don't want to use the provided tools from RIPE NCC, run your own CA. >If you don't want to use RPKI, fine as well, no-body is forcing you. There is no policy that determines that "everything longer than a /24 is not routable" either. If all your transits insist on rpki-signed advertisements, it becomes de-facto mandatory. The fundamental issue with this proposal is that it, like the block-lists that some governemnts dream of, establishes an infrastructure that is open to abuse. Everything that *can* be abused, no matter how well- intentioned it may have been, *will* be abused. And the last thing, in my opinion, that the DFZ needs is *another* attack vector. Kind Regards, Sascha Luck From millnert at gmail.com Tue May 3 18:29:54 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 3 May 2011 12:29:54 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <001f01cc0997$e3a5fe40$aaf1fac0$@com> Message-ID: James, Erik, On Tue, May 3, 2011 at 10:59 AM, boggits wrote: > On 3 May 2011 15:42, Erik Bais wrote: >> Hi James & Malcolm, >> I will however use the repository to check if what my customers want to >> start to announce to our network. And when PI is going to be accepted after >> this policy, also PI. > > This a useful function of the RPKI (and the use that I expected this > for, when it moves to automation then I have the fear. This is essentially not a property of RPKI however. It is a property of the RIPE DB itself. Let me quickly illustrate: To check what your customers wants to announce to you -- you talk to *them*. To check if what the customers wants to announce is also listed in $IRROFCHOICE, you check $IRROFCHOICE. I don't see what problem RPKI solves here. Kind Regards, Martin From drc at virtualized.org Tue May 3 18:38:46 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 3 May 2011 09:38:46 -0700 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110503154422.GA27143@cilantro.c4inet.net> References: <4DBFE7A7.7050608@linx.net> <001f01cc0997$e3a5fe40$aaf1fac0$@com> <20110503154422.GA27143@cilantro.c4inet.net> Message-ID: <24DFE626-7183-4F40-9444-F38AE2F1A572@virtualized.org> Sascha, On May 3, 2011, at 8:44 AM, Sascha Luck wrote: > There is no policy that determines that "everything longer than a /24 is not routable" either. If all your transits insist on rpki-signed advertisements, it becomes de-facto mandatory. Agreed. > The fundamental issue with this proposal is that it, like the block-lists that some governemnts dream of, establishes an infrastructure that is open to abuse. Everything that *can* be abused, no matter how well-intentioned it may have been, *will* be abused. And the last thing, in my opinion, that the DFZ needs is *another* attack vector. At an abstract level, RPKI merely provides a way of validating the contents of the address registration database(s) that is (more) amenable to automation than current systems. The implication of this is that it will give the signers of resources anywhere in the chain the ability to impose policy on those beneath them in the chain of trust. In theory, that power exists today, e.g., RIPE could revoke an allocation and remove it from the registration database, resulting in an implicit revocation of all addresses assigned with the address space that had been allocated. I'm not aware of any abuse of the current system. Is your concern that the new system will make abuse somehow easier? Regards, -drc From immo.ripe at be.free.de Tue May 3 19:05:44 2011 From: immo.ripe at be.free.de (Immo 'FaUl' Wehrenberg) Date: Tue, 3 May 2011 19:05:44 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DBFE7A7.7050608@linx.net> References: <4DBFE7A7.7050608@linx.net> Message-ID: <20110503170543.GD18210@benabuFaUl.be.free.de> Malcolm wrote: > I am afraid I don't believe this policy should be adopted at this time. I agree with that. > This is not a minor, administrative policy. It is (even if not intended > as such) the first step in a process the end result of which would be a > major change to the Internet architecture. I am afraid that the ultimate > outcome could be that the Internet becomes more fragile as a > consequence. True, it's only the first step. But if it's a step in the > wrong direction, let's not do it. I'd like to add to the ones argueing that you are not forced to implement a policy based on the rpki: What point does this have if noone implements that? None, right, so all arguing in favour of this policy are convinced that one will imlement something based on that. So concider that: Once a serious amount of ASes (and exspecially carriers) have implemented policies based on RPKI, we will never get rid of that, at least not easyly. Just look at how good IPv6 is beeing adapted and how good we are getting rid of v4. ;) So before we push that huge responsability that comes along with that RPKI certificates (and especially with the power of revocation either by not renewing an expired certificate or by CRL or something like that) into the RIRs, we should double and tripple think wether we are really willing to do that and wether the RIRs are stable and resistable enough to the political preassure that no matter will fall upon them really soon after gouvernments (and lobby groups, ...) notice. [stuff where I pretty much agree with Malcolm deleted] > iii) Even if the problem is serious enough, whether alternative means to > address it could be found that would mitigate these risks [2]. (For > example, if the problem could be 80% solved using a model that does not > give RIRs a power to revoke and expire certificates "needed" for > routing, is the residual 20% of the problem really serious enough to > warrant creating the risks I describe). In order to respond to [2] here (and following a short discussion i had with Geoff after his talk yesterday): as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. In general, both approaches works poorly to say the least and giving away the power to some "trusted third partys" get us the mess we today have with traditional ssl certificates (where we have a system that is seriously broken beyond all repair). However, I'd like to take Randys point from his talk that the validatity of certificates should be long, but would even say that thay should not be only two to five years, but instead at least 20 years and no possible revocation in order to protect the RIRs from being smashed by political preassure. From the security point of view, lang validity times are indeed just a question of chosing reasonable security parameters and there is a good consenseous about that in the security and crypto research about what that should be and these are (with a large safety margin) available in various recommendadiots (for example by NIST[1]). [even more stuff from Malcolm where i generally agree deleted] regards, Immo [1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf Page 66 I'd just keep Malcolms [2] here > [2] For example, could we creates "webs of trust" rather than a single > hierarchy? Would that be "good enough" or is a hierarchy essential? > Could a PKI for address allocations work sufficiently well without > investing the hierarchy with authority to revoke certificates? Should we > consider an architecture with a distributed issuer/revoker, spread > across multiple jurisdictions? What other models exist? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lists-ripe at c4inet.net Tue May 3 19:04:52 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 3 May 2011 17:04:52 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <24DFE626-7183-4F40-9444-F38AE2F1A572@virtualized.org> References: <4DBFE7A7.7050608@linx.net> <001f01cc0997$e3a5fe40$aaf1fac0$@com> <20110503154422.GA27143@cilantro.c4inet.net> <24DFE626-7183-4F40-9444-F38AE2F1A572@virtualized.org> Message-ID: <20110503170452.GB27143@cilantro.c4inet.net> On Tue, May 03, 2011 at 09:38:46AM -0700, David Conrad wrote: > In theory, that power exists today, e.g., RIPE could revoke > an allocation and remove it from the registration database, > resulting in an implicit revocation of all addresses assigned > with the address space that had been allocated. If the NCC (or even a third party) revoke an allocation, nothing happens automatically and immediately. (there might be some SPs that, periodically, check advertisements against the ripedb, I'm not aware of anything like that.) In an automatic RPKI environment, the cert gets revoked and your routing goes away. > I'm not aware of any abuse of the current system. It's not efficiently abusable, in my opinion. Too many sanity checks. > Is your concern that the new system will make abuse somehow easier? Hell yes. It not only makes it easier, it makes it *automatic* Kind Regards, Sascha Luck From millnert at gmail.com Tue May 3 19:22:39 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 3 May 2011 13:22:39 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110503170543.GD18210@benabuFaUl.be.free.de> References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> Message-ID: Hi Immo, On Tue, May 3, 2011 at 1:05 PM, Immo 'FaUl' Wehrenberg wrote: > Malcolm wrote: >> I am afraid I don't believe this policy should be adopted at this time. > > I agree with that. > >> This is not a minor, administrative policy. It is (even if not intended >> as such) the first step in a process the end result of which would be a >> major change to the Internet architecture. I am afraid that the ultimate >> outcome could be that the Internet becomes more fragile as a >> consequence. True, it's only the first step. But if it's a step in the >> wrong direction, let's not do it. > > I'd like to add to the ones argueing that you are not forced to implement > a policy based on the rpki: > What point does this have if noone implements that? None, right, so > all arguing in favour of this policy are convinced that one will imlement > something based on that. So concider that: > Once a serious amount of ASes (and exspecially carriers) have implemented > policies based on RPKI, we will never get rid of that, at least not > easyly. Just look at how good IPv6 is beeing adapted and how good > we are getting rid of v4. ?;) > > So before we push that huge responsability that comes along with that > RPKI certificates (and especially with the power of revocation either > by not renewing an expired certificate or by CRL ?or something like that) > into the RIRs, we should double and tripple think wether we are > really willing to do that and wether the RIRs are stable and resistable > enough to the political preassure that no matter will fall upon them > really soon after gouvernments (and lobby groups, ...) notice. > > [stuff where I pretty much agree with Malcolm deleted] > >> iii) Even if the problem is serious enough, whether alternative means to >> address it could be found that would mitigate these risks [2]. (For >> example, if the problem could be 80% solved using a model that does not >> give RIRs a power to revoke and expire certificates "needed" for >> routing, is the residual 20% of the problem really serious enough to >> warrant creating the risks I describe). > > In order to respond to [2] here (and following a short discussion i had > with Geoff after his talk yesterday): > as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. Here I'd like to raise a minor, quite theoretical, objection. The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 and AS numbers, is to organize resources globally so that there are no collisions (uniqueness). WIth IPv4 and to some extent AS numbers, there's an additional point of rationing them out, but that is mainly a side-effect of them being varying degrees of finite resources. IPv6 however, while not infinite, is certainly sufficient for every person on the planet. And so it is conceivable that another, distributed, system for uniqueness verification could exist. Whether or not any change like what I'm describing has any chance to fly or not, is a slightly different question. That, and what routing it would require. Returning to present day reality, address assignment policy and routing policy has rather successfully been kept apart so far, I think. Joining them up with a glue of censorship, which is what RPKI is (dropping prefix announcements, right?), is not very appealing to me. And what censorship it could become -- internetwide nearly instant censorship. > In general, both approaches works poorly to say > the least and giving away the power to some "trusted third partys" get > us the mess we today have with traditional ssl certificates (where > we have a system that is seriously broken beyond all repair). However, > I'd like to take Randys point from his talk that the validatity of > certificates should be long, but would even say that thay should not > be only two to five years, but instead at least 20 years and > no possible revocation in order to protect the RIRs from being smashed > by political preassure. The really-long-term validity is appealing, but nevertheless falls short from personal preference since I don't see the actual need for RPKI to begin with. Thanks, Kind Regards, Martin > > From the security point of view, lang validity times are indeed just > a question of chosing reasonable security parameters and there is a > good consenseous about that in the security and crypto research about > what that should be and these are (with a large safety margin) available > in various recommendadiots (for example by NIST[1]). > > [even more stuff from Malcolm where i generally agree deleted] > > regards, > > Immo > > [1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf > ? ?Page 66 > > I'd just keep Malcolms [2] here >> [2] For example, could we creates "webs of trust" rather than a single >> hierarchy? Would that be "good enough" or is a hierarchy essential? >> Could a PKI for address allocations work sufficiently well without >> investing the hierarchy with authority to revoke certificates? Should we >> consider an architecture with a distributed issuer/revoker, spread >> across multiple jurisdictions? What other models exist? > From immo.ripe at be.free.de Tue May 3 19:47:56 2011 From: immo.ripe at be.free.de (Immo 'FaUl' Wehrenberg) Date: Tue, 3 May 2011 19:47:56 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> Message-ID: <20110503174755.GE18210@benabuFaUl.be.free.de> Martin wrote: > > In order to respond to [2] here (and following a short discussion i had > > with Geoff after his talk yesterday): > > as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. > > Here I'd like to raise a minor, quite theoretical, objection. > The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 > and AS numbers, is to organize resources globally so that there are no > collisions (uniqueness). WIth IPv4 and to some extent AS numbers, > there's an additional point of rationing them out, but that is mainly > a side-effect of them being varying degrees of finite resources. > IPv6 however, while not infinite, is certainly sufficient for every > person on the planet. And so it is conceivable that another, > distributed, system for uniqueness verification could exist. Whether > or not any change like what I'm describing has any chance to fly or > not, is a slightly different question. > That, and what routing it would require. While I agree with you at some point, i don't think we get any further when starting to discuss at this level here. > > In general, both approaches works poorly to say > > the least and giving away the power to some "trusted third partys" get > > us the mess we today have with traditional ssl certificates (where > > we have a system that is seriously broken beyond all repair). However, > > I'd like to take Randys point from his talk that the validatity of > > certificates should be long, but would even say that thay should not > > be only two to five years, but instead at least 20 years and > > no possible revocation in order to protect the RIRs from being smashed > > by political preassure. > The really-long-term validity is appealing, but nevertheless falls > short from personal preference since I don't see the actual need for > RPKI to begin with. Well, we had that Youtube incedent and there where a few more, so there are people demanding it. I don't think that denying that fact and just walk away would get us any further here again. In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns. Regards, Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dr at cluenet.de Tue May 3 19:51:52 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 May 2011 19:51:52 +0200 Subject: [address-policy-wg] Re: getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <20110503175152.GA24780@srv03.cluenet.de> On Tue, May 03, 2011 at 04:20:42PM +0200, Mikael Abrahamsson wrote: > I am not heated, I am resigned about nobody here caring about the common > good. The common good is an Internet which allows nondiscriminatory access to whoever wants, with no ARTIFICIAL (and that's your PI tax) barriers. No matter how financially potent they are, wether they are a business or non-commercial org or even just a private person. People tend to forget that Internet is more than "ISPs trying to get revenue out of the big content players and the million numb eyeballs". Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From lists-ripe at c4inet.net Tue May 3 19:56:46 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 3 May 2011 17:56:46 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110503174755.GE18210@benabuFaUl.be.free.de> References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> <20110503174755.GE18210@benabuFaUl.be.free.de> Message-ID: <20110503175646.GC27143@cilantro.c4inet.net> On Tue, May 03, 2011 at 07:47:56PM +0200, Immo 'FaUl' Wehrenberg wrote: >just walk away would get us any further here again. In contrary, if >people seriously start to demand it and we are going to say "well, >we will not do something here" then they will start doing that in >some other forum, which i would presume is much worse as we here >can discuss and raise our concerns. Then that battle will have to be fought elsewhere. While it is good tactics to choose the battleground yourself, it is pointless if you're just going to surrender anyway... rgds, Sascha Luck From millnert at gmail.com Tue May 3 19:58:25 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 3 May 2011 13:58:25 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110503174755.GE18210@benabuFaUl.be.free.de> References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> <20110503174755.GE18210@benabuFaUl.be.free.de> Message-ID: On Tue, May 3, 2011 at 1:47 PM, Immo 'FaUl' Wehrenberg wrote: > Martin wrote: >> > In order to respond to [2] here (and following a short discussion i had >> > with Geoff after his talk yesterday): >> > as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. >> >> Here I'd like to raise a minor, quite theoretical, objection. >> The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 >> and AS numbers, is to organize resources globally so that there are no >> collisions (uniqueness). WIth IPv4 and to some extent AS numbers, >> there's an additional point of rationing them out, but that is mainly >> a side-effect of them being varying degrees of finite resources. >> ? IPv6 however, while not infinite, is certainly sufficient for every >> person on the planet. ?And so it is conceivable that another, >> distributed, system for uniqueness verification could exist. ?Whether >> or not any change like what I'm describing has any chance to fly or >> not, is a slightly different question. >> That, and what routing it would require. > > While I agree with you at some point, i don't think we get any further > when starting to discuss at this level here. > >> > In general, both approaches works poorly to say >> > the least and giving away the power to some "trusted third partys" get >> > us the mess we today have with traditional ssl certificates (where >> > we have a system that is seriously broken beyond all repair). However, >> > I'd like to take Randys point from his talk that the validatity of >> > certificates should be long, but would even say that thay should not >> > be only two to five years, but instead at least 20 years and >> > no possible revocation in order to protect the RIRs from being smashed >> > by political preassure. >> The really-long-term validity is appealing, but nevertheless falls >> short from personal preference since I don't see the actual need for >> RPKI to begin with. Immo, > Well, we had that Youtube incedent and there where a few more, so there > are people demanding it. I am well aware that there is a demand by powerful forces for RPKI or something similar. I do not think the youtube incident and a handful other motivate such a drastic system. As you argued, the point of RPKI is to see it spread and implement else it is pointless. We agree here. > I don't think that denying that fact and just walk away would get us any further here again. I welcome research and debate of this and alternative solutions to achieve the goal of avoiding the Youtube incident or making its impact less hurtful. > In contrary, if people seriously start to demand it and we are going to say "well, > we will not do something here" then they will start doing that in > some other forum, which i would presume is much worse as we here > can discuss and raise our concerns. Hopefully, the respective WG's at RIPE will remain in charge of the PDP process of their respective areas? I partly understand what you mean and partly don't. So far, I've seen one voice in favor of the proposal in this thread and several against. FWIW, I do not accept the argument "If we don't give up now they'll win somewhere else", it's completely mad IMHO. It would be quite appropriate that the general public became more aware of keeping an open internet anyway. Kind Regards, Martin From dr at cluenet.de Tue May 3 20:08:50 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 May 2011 20:08:50 +0200 Subject: [address-policy-wg] Re: getting second IPv6 PA as a LIR In-Reply-To: <20110503095706.GZ30227@Space.Net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <20110503095706.GZ30227@Space.Net> Message-ID: <20110503180850.GB24780@srv03.cluenet.de> On Tue, May 03, 2011 at 11:57:06AM +0200, Gert Doering wrote: > Right now, we should try to get rid of conservationist IPv4 thinking, You mean like /56 and (much worse) HD-ratio 0.94? :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From immo.ripe at be.free.de Tue May 3 20:21:12 2011 From: immo.ripe at be.free.de (Immo 'FaUl' Wehrenberg) Date: Tue, 3 May 2011 20:21:12 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> <20110503174755.GE18210@benabuFaUl.be.free.de> Message-ID: <20110503182112.GF18210@benabuFaUl.be.free.de> Martin wrote: > > Well, we had that Youtube incedent and there where a few more, so there > > are people demanding it. > I am well aware that there is a demand by powerful forces for RPKI or > something similar. I do not think the youtube incident and a handful > other motivate such a drastic system. I don't see that further. However, engineering tends to overengineer things to not only solve the imminent problems, but also problems that could occure somewhen in the future. I don't see RPKI designed as an evil censorship tool. I'd bet it isn't even bad engineered (eventhough i haven't had a deeper look on the design yet). The only point is that its implementation has implications that from my point of view hasn't been taken into account properly until now. > > I don't think that denying that fact and just walk away would get us any further here again. > I welcome research and debate of this and alternative solutions to > achieve the goal of avoiding the Youtube incident or making its impact > less hurtful. Fine. Thats exactly what I think should be done. Take the concerns mentioned seriously and put further work to resolve the problems. > > In contrary, if people seriously start to demand it and we are going to say "well, > > we will not do something here" then they will start doing that in > > some other forum, which i would presume is much worse as we here > > can discuss and raise our concerns. > Hopefully, the respective WG's at RIPE will remain in charge of the > PDP process of their respective areas? If the WG is just sticking their head into the sand and just says 'no, we're against it' without supplying any strategy to archive a solution everybody can live with, this may well change. And that was exactly my point here. Work must be going towards that solution and not just discarding the current one. I hope that clarifys things. Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dr at cluenet.de Tue May 3 21:41:55 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 May 2011 21:41:55 +0200 Subject: [address-policy-wg] Re: getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBDD67F.7060202@leon.pl> Message-ID: <20110503194155.GA12233@srv03.cluenet.de> On Sun, May 01, 2011 at 11:18:41PM +0100, Remco Van Mook wrote: > Why would somebody else pay for your hobby? Why do businesses pay for their competitor's business? Assuming LIRs are generally businesses (first order approximation), LIRs seem to be totally fine to pay for hardware to support all their competitors DFZ deaggregation pollution. I'm missing any call to arms to get THAT in check. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Tue May 3 21:54:29 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 May 2011 21:54:29 +0200 Subject: [address-policy-wg] Re: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: Message-ID: <20110503195429.GA14380@srv03.cluenet.de> On Tue, Apr 26, 2011 at 01:46:01PM +0200, Sander Steffann wrote: > Based on this feedback we (the address policy working group chairs) have > decided to move this policy proposal to the Concluding Phase and start the > Last Call for Comments. I do object to the proposal on the grounds much better described by Malcolm Hutty and Martin Millnert than I could. My feeling is that we're dealing here with a possible Pandora's box, and the implications of RPKI are not fully and widely discussed and understood. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gert at space.net Tue May 3 22:31:08 2011 From: gert at space.net (Gert Doering) Date: Tue, 3 May 2011 22:31:08 +0200 Subject: [address-policy-wg] Re: getting second IPv6 PA as a LIR In-Reply-To: <20110503180850.GB24780@srv03.cluenet.de> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <20110503095706.GZ30227@Space.Net> <20110503180850.GB24780@srv03.cluenet.de> Message-ID: <20110503203108.GK30227@Space.Net> Hi, On Tue, May 03, 2011 at 08:08:50PM +0200, Daniel Roesen wrote: > On Tue, May 03, 2011 at 11:57:06AM +0200, Gert Doering wrote: > > Right now, we should try to get rid of conservationist IPv4 thinking, > > You mean like /56 and (much worse) HD-ratio 0.94? :) Well, I remain to convinced that a typical end-user household can find uses for more than a 100 different *networks* - but then, it's by no means mandatory to assign /56s, as the policy explicitely allows assignments of /48 (which we discussed last year in Rome to make it very clear how that is currently counted regarding usage ratio). I can't actually say for which classes of networks a HD-Ratio of 0.94 will work, and for which classes it might fail. It does give the ISP quite some slack (for example, a /32 is considered "full" if an efficiency of 37% is reached - as opposed to the 80% in IPv4 today [RIPE-512, Appendix A]). If that is not sufficient or does not really "fit" real-world networks, maybe we need a different HD-Ratio, or a different "fullnesss" metric altogether - your suggestions are welcome. 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 dr at cluenet.de Tue May 3 23:06:17 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 May 2011 23:06:17 +0200 Subject: [address-policy-wg] Re: Re: getting second IPv6 PA as a LIR In-Reply-To: <20110503203108.GK30227@Space.Net> References: <4DB73E46.1000605@leon.pl> <20110427063600.GL30227@Space.Net> <4DBDCAA6.6070701@leon.pl> <20110502144433.GL30227@Space.Net> <05B243F724B2284986522B6ACD0504D7E5D60FD2B6@EXVPMBX100-1.exc.icann.org> <4DBF17F0.3090008@trifle.net> <20110503095706.GZ30227@Space.Net> <20110503180850.GB24780@srv03.cluenet.de> <20110503203108.GK30227@Space.Net> Message-ID: <20110503210617.GC14380@srv03.cluenet.de> On Tue, May 03, 2011 at 10:31:08PM +0200, Gert Doering wrote: > Well, I remain to convinced that a typical end-user household can > find uses for more than a 100 different *networks* - but then, it's by > no means mandatory to assign /56s, as the policy explicitely allows > assignments of /48 (which we discussed last year in Rome to make it > very clear how that is currently counted regarding usage ratio). Right, but that doesn't help, as your allocation size is still being judged by looking at /56s (that a /48 assignment is counted as 256 assigned /56 doesn't help at all). Think of prefix delegation pool sizing when you have a lot of aggregation points. > I can't actually say for which classes of networks a HD-Ratio of 0.94 > will work, and for which classes it might fail. It does give the ISP > quite some slack (for example, a /32 is considered "full" if an > efficiency of 37% is reached - as opposed to the 80% in IPv4 today > [RIPE-512, Appendix A]). If that is not sufficient or does not really > "fit" real-world networks, maybe we need a different HD-Ratio, or a > different "fullnesss" metric altogether - your suggestions are welcome. The point is, that HD ratio 0.8 allowed MUCH cleaner, nicer addressing schemes with semantic/geographic/technical hierarchy encoded on nibble boundaries than HD ratio 0.94. With the latter, far less encoding with "one size fits all" approach on a certain level is possible, otherwise we'd be screwed later. When you go off-nibble, things become cumbersome for anyone reading, planning, delegating (revDNS), routing - basically DEALING - with IPv6 addressing. This may be viewed as "less luxury", but also as added operational cost. Anyway, all off-topic in this thread. I just wanted to point out that people already started to apply "IPv4 mindset" to IPv6 policy, even before any significant deployment has taken place and operational experience has been collected. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From drc at virtualized.org Wed May 4 00:23:30 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 3 May 2011 15:23:30 -0700 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> Message-ID: Martin, On May 3, 2011, at 10:22 AM, Martin Millnert wrote: > The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 > and AS numbers, is to organize resources globally so that there are no > collisions (uniqueness). If uniqueness was the primary role of the IR system, it would be far easier/cheaper/more efficient to have a trivial web service that allocates numbers sequentially on demand. We don't have that because the IR system is also concerned with conservation and routability. Since both of these latter two concerns are subjective, an elaborate (some might even say Byzantine) policy definition structure has evolved to define 'appropriate' (for some value of that variable) levels of both. (One might argue that at least in the context of IPv4, the conservation goal no longer applies since there is no longer anything to conserve, but that's probably a topic for a different thread). Today, since the IR system has little in the way of enforcement capability, this system primarily works via the "consent of the governed" (where 'the governed' tends to be the larger ISPs). RPKI+SIDR potentially provides for a more effective enforcement mechanism than has existed to date. The advantages of this are clear: it would allow for increased security in the routing system, permitting greater control in how numbering resources are interpreted by relying parties. The downsides are that it allows for increased security in the routing system, theoretically permitting the imposition of policies that may be objectionable to some. > WIth IPv4 and to some extent AS numbers, > there's an additional point of rationing them out, but that is mainly > a side-effect of them being varying degrees of finite resources. > IPv6 however, while not infinite, is certainly sufficient for every > person on the planet. There is no finite resource that folks can't come up with policies that result in the resource becoming scarce. Regards, -drc From swmike at swm.pp.se Wed May 4 07:34:01 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 4 May 2011 07:34:01 +0200 (CEST) Subject: [address-policy-wg] Re: getting second IPv6 PA as a LIR In-Reply-To: <20110503194155.GA12233@srv03.cluenet.de> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBDD67F.7060202@leon.pl> <20110503194155.GA12233@srv03.cluenet.de> Message-ID: On Tue, 3 May 2011, Daniel Roesen wrote: > Why do businesses pay for their competitor's business? I'm going to sum up my reasons for my views in this email and then most likely stop writing as this is going nowhere. I started using the Internet in early 90ties and as soon as I heard about PI, I thought it was a great idea and why shouldn't I have one? It's great for me, I never have to renumber. Then I started working with routing and udnerstood how this global system worked, and all of a sudden I understood the global implications of PI. I still think it's a great idea for each individual, but bad for the humanity as a whole. It's just like driving a hummer to go shoe-shopping is a bad idea in that it's wasteful to use this resource. A DFZ route has to be carried by everybody, meaning as the DFZ increases, everybody has to upgrade their platforms, whether they might need it for bandwidth reasons or not. It also means people have to buy more expensive platforms. The largest 1U L3 switch FIB size I know of is the Extreme Summit 480X, it can do almost 512k IPv4 routes. With IPv4 and IPv6 table still growing, I'd hesitate to recommend anyone to buy it right now because it won't be able to handle DFZ in 3-5 years. This means someone who wants to take the DFZ needs a bigger and more expensive platform that most likely uses more energy over its lifetime, not to talk about what it costs to manufacture it. In my 10-15 years in core routing, I've seen the table rise from ~100 to ~350k routes, but the platforms haven't gotten very much faster compared to the routing table size. They still take tens of seconds to converge when it comes to programming all these routes into FIB, and the algorithms we use to calculate the routes are from the 1980ies or earlier. As far as I know, there are no magical new much better ways of doing this on the horizon, most of the improvement suggestions involves doing overlay networks or having end systems be more flexible on their behaviour regarding how tightly services are bound to addresses. So to sum it all up. I don't trust moores law to keep up with routing table growth if we let "everybody" get PI, but it seems I am in very much minority here with that view. -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Wed May 4 09:09:20 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 4 May 2011 09:09:20 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110503182112.GF18210@benabuFaUl.be.free.de> References: <4DBFE7A7.7050608@linx.net> <20110503170543.GD18210@benabuFaUl.be.free.de> <20110503174755.GE18210@benabuFaUl.be.free.de> <20110503182112.GF18210@benabuFaUl.be.free.de> Message-ID: <68B4BFE8-1990-4A2B-9074-CCE0BAC56A7F@steffann.nl> Hello Immo, >>> I don't think that denying that fact and just walk away would get us any further here again. >> I welcome research and debate of this and alternative solutions to >> achieve the goal of avoiding the Youtube incident or making its impact >> less hurtful. > > Fine. Thats exactly what I think should be done. Take the concerns > mentioned seriously and put further work to resolve the problems. > >>> In contrary, if people seriously start to demand it and we are going to say "well, >>> we will not do something here" then they will start doing that in >>> some other forum, which i would presume is much worse as we here >>> can discuss and raise our concerns. >> Hopefully, the respective WG's at RIPE will remain in charge of the >> PDP process of their respective areas? > > If the WG is just sticking their head into the sand and just says > 'no, we're against it' without supplying any strategy to archive a > solution everybody can live with, this may well change. > > And that was exactly my point here. Work must be going towards that > solution and not just discarding the current one. > > I hope that clarifys things. Thank you for your reply. As co-chair of this working group I can only add extra emphasis here: this is a working group, let's work towards a solution. If you are in favor of this policy proposal or agains it: please provide arguments that we can discuss. Thank you, Sander Steffann APWG co-chair From gert at space.net Wed May 4 09:19:36 2011 From: gert at space.net (Gert Doering) Date: Wed, 4 May 2011 09:19:36 +0200 Subject: [address-policy-wg] Re: getting second IPv6 PA as a LIR In-Reply-To: <20110503194155.GA12233@srv03.cluenet.de> References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> <4DBDD67F.7060202@leon.pl> <20110503194155.GA12233@srv03.cluenet.de> Message-ID: <20110504071936.GL30227@Space.Net> Hi, On Tue, May 03, 2011 at 09:41:55PM +0200, Daniel Roesen wrote: > Assuming LIRs are generally businesses (first order approximation), LIRs > seem to be totally fine to pay for hardware to support all their > competitors DFZ deaggregation pollution. > > I'm missing any call to arms to get THAT in check. Different orders of magnitude. How many "ISP-like" operations can you have, and how many "just end users" can you have? So what we have tried to work for is a reasonable(*) balance - that end users *can* have independent address space, but not all end users would actually *want* it. To stress the obvious: not all "end users" are identical - there's "medium sized businesses" and "my mom's computer at home". I don't think my mom should have PI addresses being globally visible in the DFZ... (and as far as I remember, Daniel's employer isn't offering to route PI addresses to their customer base either). Just something to keep in mind. Gert Doering APWG chair (*) reasonable = some think it's too loose, others think it's too strict, but generally mostly workable and nothing has exploded yet -- 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 poty at iiat.ru Wed May 4 09:26:54 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 4 May 2011 11:26:54 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: -----Original Message----- From: Martin Millnert [mailto:millnert at gmail.com] Sent: Tuesday, May 03, 2011 6:23 PM To: Potapov Vladislav Cc: slz at baycix.de; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] getting second IPv6 PA as a LIR On Tue, May 3, 2011 at 9:37 AM, wrote: >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Not really; normal PC RAM is pretty cheap. 16GB ECC/REG ~400 EUR. /M -------- It's not about storing, it's all about using. And here we get to the problem. From poty at iiat.ru Wed May 4 09:49:05 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 4 May 2011 11:49:05 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: Hay, Am 03.05.2011 um 15:37 schrieb : >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Sascha Lenz [SLZ-RIPE] ---------------------- Small companies start with small routers, PC based Linux Quagga Boxes, or Routerboards, or Juniper J-Series or whatever - not really much costs here (see other replies). -------------- They will not be able to "start with small routers", because calculating constantly changing routes (presumable from several sources) costs processing power, routing decisions with huge routing table cost processing power, even receiving and sending plain packets costs processing power. And all this costs money. PC-based routers are not able to do all of this at once and in this anount. The "selfish" small ISPs could easily drive himself into trap of trouble when they have to spent much more money for equipment (and made all others do it) rather than using PA from LIR. From gert at space.net Wed May 4 09:49:00 2011 From: gert at space.net (Gert Doering) Date: Wed, 4 May 2011 09:49:00 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DB73E46.1000605@leon.pl> <4DBDC9CD.9030003@leon.pl> <4DBDCDD3.90000@leon.pl> Message-ID: <20110504074900.GM30227@Space.Net> Hi, to come back to one specific question here: On Tue, May 03, 2011 at 07:47:07AM +0200, Mikael Abrahamsson wrote: > > Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely > > 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;) > > Is this really true? IPv6 PI at 50EUR/year? Right now, the price for an "independent numbering resource" is 50 EUR / year per piece - that's IPv4 PI assignments, IPv6 PI assignments and AS numbers. This price is decided upon by the RIPE general meeting (AGM), where the actual paying members decide how they want the fee structure to be. The address policy working group can influence this decision by giving input to the RIPE NCC / NCC board as in "the community thinks that this price is too low / too high / should be dependent on the size / ...", but we don't get to actually *decide* this - money is decided by paying members. Now, something else to keep in mind regarding PI space: you need someone who is actually willing to route that space for you - which usually isn't done on "mass market end user" type contracts (at least, over here in .DE, none of the big DSL or cable ISPs would route someone else's PI for them), so you need a "business ISP contract", which adds indeed cost that "the polluter" has to bear. This discussion is drifting back and forth between "I'm a hosting provider, I run a business providing IP connectivity to the content my customers want to be visible in the Internet, and I need space for that" and "if millions of end users all get PI into the DFZ, routers will explode". Which both is correct - but somewhat unrelated, as this is talking about different types of "internet entities" that come in vastly different numbers. 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 slz at baycix.de Wed May 4 10:06:39 2011 From: slz at baycix.de (Sascha Lenz) Date: Wed, 4 May 2011 10:06:39 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: Hay, Am 04.05.2011 um 09:49 schrieb : [...] > Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. > > do you have any numbers on that? because i don't see it. Even my old Pentium4 route servers do very nicely with that. And look at the processing power of the Route Engines of the hardware routers... wow are they slow! So, where does this come from? Will there be a break even point where current CPUs won't handle that anymore? My bigger problem with that actually is FORWARDING, not route calculation. The only reason i have hardware routers with ASICS is the wirespeed throughput, they still all have low-end CPU route engines for route calculation.... (But yes, slower CPUs == bringing up a BGP session takes 20min or so, we know that) And unfortunately i just now notices that this drifts a bit off topic. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From poty at iiat.ru Wed May 4 10:25:33 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 4 May 2011 12:25:33 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: [...] > Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. > > do you have any numbers on that? because i don't see it. Even my old Pentium4 route servers do very nicely with that. --------------------- With what? My company is very small and even currently used hardware routers can't handle 3-4 (1Gbit|sec) upstream connections efficiently (doing BGP in addition of course). When we add several hundred thousands IPV6 routes we are going to extremely upgrades our infrastructure, but smaller ISP (business...) which can't pay $100/month will not be able to do so definitely. > Sascha Lenz [SLZ-RIPE] ------------------------ And look at the processing power of the Route Engines of the hardware routers... wow are they slow! ------------------------ You know - they are different. :) Mostly they have distributed computing environment and hardware programmed to do specific operations, huge backbones and many-many other things which PC lacks. The widespread PI will definitely adds significant amount to the number of routes, so your forwarding problem will be much worse. Regards, Vladislav Potapov IIAT, Ltd. P.S. Sorry for some earlier messages without signature. From rogerj at jorgensen.no Wed May 4 10:32:48 2011 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Wed, 4 May 2011 10:32:48 +0200 (CEST) Subject: [address-policy-wg] Re: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110503195429.GA14380@srv03.cluenet.de> References: <20110503195429.GA14380@srv03.cluenet.de> Message-ID: On Tue, 3 May 2011, Daniel Roesen wrote: > On Tue, Apr 26, 2011 at 01:46:01PM +0200, Sander Steffann wrote: > > Based on this feedback we (the address policy working group chairs) have > > decided to move this policy proposal to the Concluding Phase and start the > > Last Call for Comments. > > I do object to the proposal on the grounds much better described by > Malcolm Hutty and Martin Millnert than I could. > > My feeling is that we're dealing here with a possible Pandora's box, and > the implications of RPKI are not fully and widely discussed and > understood. I Think to call it a Pandora's box is to put it lightly... so I'm also against this proposal for reasons given better by Malcolm Hutty and others. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From danny at danysek.cz Wed May 4 10:44:40 2011 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 04 May 2011 10:44:40 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <4DC111F8.1000004@danysek.cz> On 05/04/2011 10:25 AM, poty at iiat.ru wrote: > When we add several hundred thousands IPV6 routes we are going to > extremely upgrades our infrastructure, but smaller ISP (business...) > which can't pay $100/month will not be able to do so definitely. > You know - they are different. :) Mostly they have distributed computing > environment and hardware programmed to do specific operations, huge > backbones and many-many other things which PC lacks. Not really. BGP table calculation isn't distributed (you need single place for this calculation final table). If we imagine your hundred thousands IPV6 routes scenario, CPU on these "hardware" routers will have troubles, too. > The widespread PI will definitely adds significant amount to the number > of routes, so your forwarding problem will be much worse. Deaggregation of PA address space causes similar problems and nobody really can do anything with this. And routers aren't making difference between PI and PA. Look into IPv4 routing table, what mess is here caused not by PI assignments, but by announced /24 from aggregatable /20, /19, from PA blocks... same thing is already happening in IPv6, where're more specifics than /32 announced from PA blocks. With blocking PI you cause only one thing - people will start deaggregation of PA space more widely. And any kind of (RIPE) policy cannot forbid this. For each restriction in RIPE policy people discover some policy-conforming workaround... PI vs PA separation is just administrative thing for RIPE NCC evidence. It's impossible to force network operators filter some prefixes, just because prefix is deaggregated. You can filter in your own network, but probably nobody will filter his paying customer - money are on the first place... With regards, Daniel From marcin at leon.pl Wed May 4 10:47:54 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 04 May 2011 10:47:54 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <4DC112BA.8000109@leon.pl> > Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. Don't worry about computing power, small ISPs usually are less than 200Mbit/s total upstreams, to even if they handle 1G with today's CPUs it is not a big deal (rather stability can be a problem). More, probably within 1-2 years there will be a set of drivers/kernel support of handling packets by high efficients processors from... graphics ;) Regards, Marcin From poty at iiat.ru Wed May 4 11:06:59 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 4 May 2011 13:06:59 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: On 05/04/2011 10:25 AM, poty at iiat.ru wrote: > When we add several hundred thousands IPV6 routes we are going to > extremely upgrades our infrastructure, but smaller ISP (business...) > which can't pay $100/month will not be able to do so definitely. > You know - they are different. :) Mostly they have distributed computing > environment and hardware programmed to do specific operations, huge > backbones and many-many other things which PC lacks. Not really. BGP table calculation isn't distributed (you need single place for this calculation final table). If we imagine your hundred thousands IPV6 routes scenario, CPU on these "hardware" routers will have troubles, too. --------------- I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too. But BGP table calculation is only one process in the router. As Sascha Lenz have pointed out - the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact. /////////////////////////// > The widespread PI will definitely adds significant amount to the number > of routes, so your forwarding problem will be much worse. Deaggregation of PA address space causes similar problems and nobody really can do anything with this. And routers aren't making difference between PI and PA. Look into IPv4 routing table, what mess is here caused not by PI assignments, but by announced /24 from aggregatable /20, /19, from PA blocks... same thing is already happening in IPv6, where're more specifics than /32 announced from PA blocks. With blocking PI you cause only one thing - people will start deaggregation of PA space more widely. And any kind of (RIPE) policy cannot forbid this. For each restriction in RIPE policy people discover some policy-conforming workaround... PI vs PA separation is just administrative thing for RIPE NCC evidence. It's impossible to force network operators filter some prefixes, just because prefix is deaggregated. You can filter in your own network, but probably nobody will filter his paying customer - money are on the first place... --------------------- While I could agree with you in some point I cannot agree fully. We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs). On the other hand: if the problem arises in the future the more organized (and less in numbers) LIRs can come to agreement easier than much more "independent" crowd of PI-holders which are even now deaf to any arguments, just claiming "independence" for any cost. Of course some "clever people" will break the rules in some "smart" ways, but I don't think it would be so widespread comparing to the "get as much as you want for free" paradigm. Regards, Vladislav Potapov IIAT, Ltd. From poty at iiat.ru Wed May 4 11:10:20 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 4 May 2011 13:10:20 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: > Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. Don't worry about computing power, small ISPs usually are less than 200Mbit/s total upstreams, to even if they handle 1G with today's CPUs it is not a big deal (rather stability can be a problem). More, probably within 1-2 years there will be a set of drivers/kernel support of handling packets by high efficients processors from... graphics ;) ------------------ I'm waiting for the event some 10 years by now. Until now it is only bad predictions. Even at 200Mbit|s with 2 upstreams it is almost impossible to deal with full table. Regards, Vladislav Potapov IIAT, Ltd. From danny at danysek.cz Wed May 4 11:38:48 2011 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 04 May 2011 11:38:48 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <4DC11EA8.9090506@danysek.cz> On 05/04/2011 11:06 AM, poty at iiat.ru wrote: > I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too. I don't expect any huge explosion. Reasons was described already in the list. Growth will copy current IPv4 curve... On 05/04/2011 11:10 AM, poty at iiat.ru wrote: > Even at 200Mbit|s with 2 upstreams it is almost impossible to deal > with full table. On 05/04/2011 11:06 AM, poty at iiat.ru wrote: > the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact. With proper hardware not really. It's not a problem handle 10Gbps interface on PC these days. And I know about real deployment, where PC is used for routing >8Gbps of traffic. > We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs). Minimum PI assignment in IPv6 is /48 - see RIPE 512. Also assigned anycasts in IPv6 are /48 - i expect, that /48 for IPv6 becames similar well-know minimum rule as /24 in IPv4 world. There're legal operational /48 assignments these days - for anycasted TLD-DNS, for example. And /48 can be assigned from /32 PA easily, there's lot of space available. And then easily announced into the BGP and almost nobody will filter it (see current IPv6 table)... Daniel From poty at iiat.ru Wed May 4 11:55:39 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 4 May 2011 13:55:39 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: On 05/04/2011 11:06 AM, poty at iiat.ru wrote: > I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too. I don't expect any huge explosion. Reasons was described already in the list. Growth will copy current IPv4 curve... ----------------- Both "sides" doesn't have arguments and reasons, just predictions. PI in IPv4 was a long developed decision, with a lot of restrictions from the beginning, several tuning across its life. So IPv6 PIs will not have the same curve definitely. You have ignored all other my arguments. \\\\\\\\\\\\\\\\\\\\\\\\\\\\ On 05/04/2011 11:10 AM, poty at iiat.ru wrote: > Even at 200Mbit|s with 2 upstreams it is almost impossible to deal > with full table. On 05/04/2011 11:06 AM, poty at iiat.ru wrote: > the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact. With proper hardware not really. It's not a problem handle 10Gbps interface on PC these days. And I know about real deployment, where PC is used for routing >8Gbps of traffic. ------------------------- To HAVE the interface doesn't mean to USE it fully. Routing 8Gbps on a PC is unrealistic definitely, even in theory. Many people (try to) pass the desirable for reality. You can certainly incorporate some hardware port accelerators in a PC, additional interfaces, make a cluster... But it seems it would be not cheap at first and claim a competence which small ISPs can't afford at second. It is not a cheap PC with common OS we are speaking about. ///////////////////////////////// > We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs). Minimum PI assignment in IPv6 is /48 - see RIPE 512. Also assigned anycasts in IPv6 are /48 - i expect, that /48 for IPv6 becames similar well-know minimum rule as /24 in IPv4 world. There're legal operational /48 assignments these days - for anycasted TLD-DNS, for example. And /48 can be assigned from /32 PA easily, there's lot of space available. And then easily announced into the BGP and almost nobody will filter it (see current IPv6 table)... ------------------- If it is so easy - use it! Why then you should apply for PI? In case of problems RIPE (for example) would speak with a single LIR, not with thousands of widespread customers. Regards, Vladislav From danny at danysek.cz Wed May 4 12:21:31 2011 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 04 May 2011 12:21:31 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: Message-ID: <4DC128AB.1000701@danysek.cz> On 05/04/2011 11:55 AM, poty at iiat.ru wrote: > Why then you should apply for PI? In case of problems RIPE (for example) would speak with a single LIR, not with thousands of widespread customers. RIPE is always speaking with the LIR, in accordance to 2007-01 policy. All new PI users are always connected with some LIR. If you want obtain PI directly from RIPE, you'll pay additional money for the contract with RIPE, it's documented on the website. And generally, I don't prefer crapping PA space with such deaggregation caused just by the PI-blocking policy. If someone has good technical reason for provider-independent address usage, I don't see reason not to assign it from defined (dedicated-for-PI) range. Current typical IPv4 PI user has some reason for that and I'm not here for judging it. I trust RIPE employees in verification of request validity. I rather prefer controlled PI assignments by RIPE instead of some kind of LIR creativity here. There's known demand for for PI on the market. Daniel From swmike at swm.pp.se Wed May 4 12:21:52 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 4 May 2011 12:21:52 +0200 (CEST) Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <4DC11EA8.9090506@danysek.cz> References: <4DC11EA8.9090506@danysek.cz> Message-ID: On Wed, 4 May 2011, Daniel Suchy wrote: > And /48 can be assigned from /32 PA easily, there's lot of space > available. And then easily announced into the BGP and almost nobody will > filter it (see current IPv6 table)... Currently, yes. Long-term, no. There are plenty of ISPs who do not filter on /24 IPv4 either, but a lot do. I expect in a few years that most will filter on /32 for PA space and /48 for PI space. The only reason it's not done today is that people haven't made it a priority because there are so few IPv6 routes. So advising subnetting /32 further and announcing them in the DFZ might work short-term, but you do it at your own risk long-term. -- Mikael Abrahamsson email: swmike at swm.pp.se From danny at danysek.cz Wed May 4 12:50:31 2011 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 04 May 2011 12:50:31 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: References: <4DC11EA8.9090506@danysek.cz> Message-ID: <4DC12F77.8010400@danysek.cz> On 05/04/2011 12:21 PM, Mikael Abrahamsson wrote: > Currently, yes. Long-term, no. There are plenty of ISPs who do not > filter on /24 IPv4 either, but a lot do. > I expect in a few years that most will filter on /32 for PA space and > /48 for PI space. The only reason it's not done today is that people > haven't made it a priority because there are so few IPv6 routes. Similar thing can be done on IPv4 these days. You can filter on PA minimal assignments to LIRs too - RIRs in general documents that and public examples of these filters are also available. But this expect, that you'll mantain this kind of filter - this is nothing like setup & forget. If network operators aren't filtering routing mess in IPv4 (even they can), they generally will not magically change their mind for IPv6. Filtering in IPv4 isn't happening, even you can reduce table by ~40% of prefixes - and this is not small number within >350000 IPv4 prefixes announced. Transit customers also expect this number on their peers, if you reduce your table in such manner, they'll complain to you, because your competitor will not filter and they expect similar number of prefixes on both their transit peers... > So advising subnetting /32 further and announcing them in the DFZ might > work short-term, but you do it at your own risk long-term. I'm not advising that. I'm just talking about something I already see in the global routing table. Deaggregation is a risk in both IPv4 and IPv6. Hohever, deaggregation works, in both worlds... And we cannot change minds of the operators by any policy. Keep in mind, that not so many comercial ISPs are involved in these policy discussions. They'll just setup their networks in accordance to customer needs, regardless of the policy made here. Daniel From pk336u at intl.att.com Wed May 4 13:50:56 2011 From: pk336u at intl.att.com (Kovac, Pavol) Date: Wed, 4 May 2011 13:50:56 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 PI Message-ID: <4D802C4079A49043A299A53593DCCF797A07B6E6D7@skcbcmsx01.emea.att.com> Hi, what is the current status for this topic ? Best regards _____________________________________ Pavol Kovac -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed May 4 14:43:55 2011 From: gert at space.net (Gert Doering) Date: Wed, 4 May 2011 14:43:55 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 PI In-Reply-To: <4D802C4079A49043A299A53593DCCF797A07B6E6D7@skcbcmsx01.emea.att.com> References: <4D802C4079A49043A299A53593DCCF797A07B6E6D7@skcbcmsx01.emea.att.com> Message-ID: <20110504124355.GT30227@Space.Net> Hi, On Wed, May 04, 2011 at 01:50:56PM +0200, Kovac, Pavol wrote: > what is the current status for this topic ? You can check the current status of all open policy proposals here: http://www.ripe.net/ripe/policies/current-proposals This specific proposal is in discussion phase, which ends at May 13 - after that we'll likely decide to go forward to review phase (possibly amending the text at that point). 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 malcolm at linx.net Wed May 4 15:24:40 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Wed, 04 May 2011 14:24:40 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <1304514280.1932.330.camel@ntitley-laptop> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> Message-ID: <4DC15398.8070304@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2011 14:04, Nigel Titley wrote: > Mrtin, Malcolm > On Tue, 2011-05-03 at 09:22 -0400, Martin Millnert wrote: >> APWG, > >> We should all think real long and hard about the possible long-term >> implications of what this proposal sets the foundation for. > > We *have* been thinking long and hard about this. This proposal is > nearly three years old. Working diligently on one particular solution is not the same thing. If you've investigated other approaches to inhibiting route hijacking and discarded them, please share. If you've merely assumed that this is the only/best/obvious/~ approach, I don't think it's unreasonable to suggest we should pause to see if we can come up with something else that doesn't turn control of routing from a distributed to a hierarchical system. 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/ iEYEARECAAYFAk3BU5cACgkQJiK3ugcyKhS2yQCfZMU0xL1blDWWKcDoKhEWEHHR jWkAoMeV6gW8wdk/Uhnt2s8MrellZTOq =mXh/ -----END PGP SIGNATURE----- From nigel at titley.com Wed May 4 15:04:40 2011 From: nigel at titley.com (Nigel Titley) Date: Wed, 04 May 2011 14:04:40 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> Message-ID: <1304514280.1932.330.camel@ntitley-laptop> Mrtin, Malcolm On Tue, 2011-05-03 at 09:22 -0400, Martin Millnert wrote: > APWG, > We should all think real long and hard about the possible long-term > implications of what this proposal sets the foundation for. We *have* been thinking long and hard about this. This proposal is nearly three years old. The operational community seems to think it is a good thing (there are over 400 LIRs using it already). Every other RIR has or will introduce it shortly. My knowledge of economics says that if there is a demand then someone will step in to satisfy it. If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region. Everyone happy with that? Good.... then let's reject this proposal and continue to gaze at our own navels for the next three years. Nigel From randy at psg.com Wed May 4 16:01:22 2011 From: randy at psg.com (Randy Bush) Date: Wed, 04 May 2011 16:01:22 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC15398.8070304@linx.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <4DC15398.8070304@linx.net> Message-ID: > If you've investigated other approaches to inhibiting route hijacking > and discarded them, please share. well, an approach i and some others studied using the reverse dns can be found in draft-bates-bgp4-nlri-orig-verif-00.txt. you might be educated by discovering why it did not fly. randy From randy at psg.com Wed May 4 16:02:34 2011 From: randy at psg.com (Randy Bush) Date: Wed, 04 May 2011 16:02:34 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <1304514280.1932.330.camel@ntitley-laptop> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> Message-ID: > If the community (as evidenced by this WG) tells the RIPE NCC not to > implement this (or more precisely to withdraw the service they are > already offering) then we simply open the way for private > certification companies in the RIPE region. in which case, i would prefer to arrange a pro-bono one. randy From pk336u at intl.att.com Wed May 4 16:01:50 2011 From: pk336u at intl.att.com (Kovac, Pavol) Date: Wed, 4 May 2011 07:01:50 -0700 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 PI In-Reply-To: <20110504124355.GT30227@Space.Net> References: <4D802C4079A49043A299A53593DCCF797A07B6E6D7@skcbcmsx01.emea.att.com> <20110504124355.GT30227@Space.Net> Message-ID: <4D802C4079A49043A299A53593DCCF797A07B6E936@skcbcmsx01.emea.att.com> Hi Gert, Thanks for your response. I am interested on this topic as our company is LIR (we use IPv6) and received a request from our customer to provide IPv6 PI space. Best regards _____________________________________ Pavol Kovac -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Wednesday, May 04, 2011 2:44 PM To: Kovac, Pavol Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Removal of multihomed requirement for IPv6 PI Hi, On Wed, May 04, 2011 at 01:50:56PM +0200, Kovac, Pavol wrote: > what is the current status for this topic ? You can check the current status of all open policy proposals here: http://www.ripe.net/ripe/policies/current-proposals This specific proposal is in discussion phase, which ends at May 13 - after that we'll likely decide to go forward to review phase (possibly amending the text at that point). 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 nigel at titley.com Wed May 4 17:13:54 2011 From: nigel at titley.com (Nigel Titley) Date: Wed, 04 May 2011 16:13:54 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> Message-ID: <1304522034.1932.337.camel@ntitley-laptop> On Wed, 2011-05-04 at 16:02 +0200, Randy Bush wrote: > > If the community (as evidenced by this WG) tells the RIPE NCC not to > > implement this (or more precisely to withdraw the service they are > > already offering) then we simply open the way for private > > certification companies in the RIPE region. > > in which case, i would prefer to arrange a pro-bono one. So would I. But I can imagine going to my boss and saying "there are two alternatives for securing my address space: a pro-bono, best effort thing run by Randy or a professional one run on a commercial basis by Mega-Certicates Plc. Which would you like me to use? Nigel From randy at psg.com Wed May 4 17:18:07 2011 From: randy at psg.com (Randy Bush) Date: Wed, 04 May 2011 17:18:07 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <1304522034.1932.337.camel@ntitley-laptop> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> Message-ID: >>> If the community (as evidenced by this WG) tells the RIPE NCC not to >>> implement this (or more precisely to withdraw the service they are >>> already offering) then we simply open the way for private >>> certification companies in the RIPE region. >> >> in which case, i would prefer to arrange a pro-bono one. > > So would I. But I can imagine going to my boss and saying "there are two > alternatives for securing my address space: a pro-bono, best effort > thing run by Randy or a professional one run on a commercial basis by > Mega-Certicates Plc. Which would you like me to use? first, i did not say 'run' i said 'arrange.' my life is already insanely overloaded. second, your boss will get what she deserves randy From teun at bit.nl Wed May 4 17:07:26 2011 From: teun at bit.nl (Teun Vink) Date: Wed, 4 May 2011 17:07:26 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <20110415092235.748716A0A7@postboy.ripe.net> References: <20110415092235.748716A0A7@postboy.ripe.net> Message-ID: <41CB2CD8-0C13-4FB6-920A-4C73B36875A8@bit.nl> On Apr 15, 2011, at 11:22 AM, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > Hello, I support this proposal. Regards, -- Teun Vink, Network & UNIX Engineer BIT BV | teun at bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0x5A04F4E2 | RIPE: TEUN-RIPE From ebais at a2b-internet.com Wed May 4 17:50:06 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 4 May 2011 17:50:06 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <1304522034.1932.337.camel@ntitley-laptop> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> Message-ID: <006801cc0a72$f0b7ab20$d2270160$@com> Hi Nigel & Randy, > On Wed, 2011-05-04 at 16:02 +0200, Randy Bush wrote: > > If the community (as evidenced by this WG) tells the RIPE NCC not to > > implement this (or more precisely to withdraw the service they are > > already offering) then we simply open the way for private > > certification companies in the RIPE region. > > in which case, i would prefer to arrange a pro-bono one. > So would I. But I can imagine going to my boss and saying "there are two > alternatives for securing my address space: a pro-bono, best effort > thing run by Randy or a professional one run on a commercial basis by > Mega-Certicates Plc. Which would you like me to use? And why would that be better than having a not-for-profit org like RIPE NCC that we are all a part of as a member, already doing this ? It's not that RIPE NCC is owned by a government or that ROA's or certificates are something that the Dutch government could seize or that an evil government would/could do so (under Dutch law), in order to shutdown the internet or an ISP.. There are far better (more effective) ways of doing so, if you remember what happened in Egypt / Libya etc.. Power down datacenter (y/n) ... Last time I checked, the NCC is operating on behalf of all of us. There are tools to be released in a couple weeks (according to the preso from Alex this afternoon.) that will allow you to run your own CA. If I would speak for myself, I would not trust any random company doing this, except the RIR's and I'm not planning to run my own CA due to the hassle. Until proven otherwise I don't have a reason to think that RIPE NCC isn't capable of providing this service. I'm not saying that you shouldn't run your own setup if you like, but what I am saying is that I don't like that you are trying to stop a working platform that is already working for me and hundreds of LIR's who have been using the system already since Jan 2011. I'm all pro-choice and that also means that I don't like it if someone is taking my choice away ... Erik Bais From lists-ripe at c4inet.net Wed May 4 17:57:13 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 4 May 2011 15:57:13 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <006801cc0a72$f0b7ab20$d2270160$@com> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> Message-ID: <20110504155713.GD27143@cilantro.c4inet.net> On Wed, May 04, 2011 at 05:50:06PM +0200, Erik Bais wrote: > It's not that RIPE NCC is owned by a government or that ROA's or > certificates are something that the Dutch government could seize > or that an evil government would/could do so (under Dutch law), > in order to shutdown the internet or an ISP.. There are far better > (more effective) ways of doing so, if you remember what happened in > Egypt / Libya etc.. Power down datacenter (y/n) ... The egyptian ex-government had to ring each SP and tell them to pull their advertisements. At least one of whom (for a while) appears to have told them to go shite. Having a central authority (especially one that's beholden to 20+ governments via the EU) makes that *much* easier. > I'm all pro-choice and that also means that I don't like it if > someone is taking my choice away ... As long as the choice actually exists - in practice. rgds, Sascha Luck From brian.nisbet at heanet.ie Wed May 4 18:24:12 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 04 May 2011 17:24:12 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110504155713.GD27143@cilantro.c4inet.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> Message-ID: <4DC17DAC.7040600@heanet.ie> On 04/05/2011 16:57, Sascha Luck wrote: > On Wed, May 04, 2011 at 05:50:06PM +0200, Erik Bais wrote: >> It's not that RIPE NCC is owned by a government or that ROA's or >> certificates are something that the Dutch government could seize or >> that an evil government would/could do so (under Dutch law), in order >> to shutdown the internet or an ISP.. There are far better >> (more effective) ways of doing so, if you remember what happened in >> Egypt / Libya etc.. Power down datacenter (y/n) ... > > The egyptian ex-government had to ring each SP and tell them to pull > their advertisements. At least one of whom (for a while) appears to have > told them to go shite. > > Having a central authority (especially one that's beholden to 20+ > governments via the EU) makes that *much* easier. I really don't think it does. You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real. I suspect that a for profit global megacorp running such a certification system would be far more vulnerable to such measures, but even then, I don't see this as a large risk. Brian. From davidm at futureinquestion.net Wed May 4 19:28:43 2011 From: davidm at futureinquestion.net (David Monosov) Date: Wed, 04 May 2011 19:28:43 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DBFE7A7.7050608@linx.net> References: <4DBFE7A7.7050608@linx.net> Message-ID: <4DC18CCB.1040202@futureinquestion.net> Dear address-policy-wg, I, too, share many of the concerns Malcolm (and others following on his comments) voiced here. I do not feel that this policy should be adopted. In addition to many of the philosophical and political concerns outlined by Malcolm (whom I would like to thank for putting them down in writing so eloquently) as to why this policy might effectively be a Pandora's box of undesirable outcomes - I also find the resources allocated by the RIPE NCC internally to RPKI efforts would be much better used if applied to furthering the usability, tooling, and user education for RPSL, which, in my opinion offers many of the capabilities the proponents of RPKI expect to see from the implementation of this policy. RPSL as a mechanism is at least partially implemented by many participants in the DFZ today, and it can be reasonably argued that by adding as little as a scalable and SSL/TLS-secured interface to the RIPE whois database, the goal of a single trust anchor containing 'definitive' information on the ownership of each allocated and assigned resource in machine-readable format is already achieved. This information, in turn, can be used both by BSS/OSS systems and, if implemented, directly by network devices to make decisions on the validity of routing information. With all this in mind, I can not support this policy. -- Respectfully yours, David Monosov On 05/03/2011 01:31 PM, Malcolm Hutty wrote: > I am afraid I don't believe this policy should be adopted at this time. > From millnert at gmail.com Wed May 4 19:45:44 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 4 May 2011 13:45:44 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC17DAC.7040600@heanet.ie> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: Brian, On Wed, May 4, 2011 at 12:24 PM, Brian Nisbet wrote: > On 04/05/2011 16:57, Sascha Luck wrote: >> >> On Wed, May 04, 2011 at 05:50:06PM +0200, Erik Bais wrote: >>> >>> It's not that RIPE NCC is owned by a government or that ROA's or >>> certificates are something that the Dutch government could seize or >>> that an evil government would/could do so (under Dutch law), in order >>> to shutdown the internet or an ISP.. There are far better >>> (more effective) ways of doing so, if you remember what happened in >>> Egypt / Libya etc.. Power down datacenter (y/n) ... >> >> The egyptian ex-government had to ring each SP and tell them to pull >> their advertisements. At least one of whom (for a while) appears to have >> told them to go shite. >> >> Having a central authority (especially one that's beholden to 20+ >> governments via the EU) makes that *much* easier. > > I really don't think it does. You seem to be imagining a scenario where a > national governement would just ring up the NCC and say, "revoke these > certs." I have seen no evidence to suggest this risk is anything close to > real. I suspect that a for profit global megacorp running such a > certification system would be far more vulnerable to such measures, but even > then, I don't see this as a large risk. It's not about "not seeing a risk" as much as it is about _making sure_, in the very design of the system, that it is *not possible* to abuse. Or at the very least extremely hard (global conspiracy kind of hard), to abuse. That would lend a bit more credit to the system. That would mean, of course, that no revocation of any certificate from any single central authority can affect routing on multiple networks. (This list goes on.) The success of deployment RPKI&siblings is inversely proportional to the amount of abuse it makes possible -- I very much would like a much, much different balance than the proposals as they are. As David suggests, much if not all of this can already be achieved using RPSL - save BGP integration... Kind Regards, Martin From jcurran at arin.net Wed May 4 20:10:27 2011 From: jcurran at arin.net (John Curran) Date: Wed, 4 May 2011 18:10:27 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> On May 4, 2011, at 1:45 PM, Martin Millnert wrote: > It's not about "not seeing a risk" as much as it is about _making > sure_, in the very design of the system, that it is *not possible* to > abuse. > Or at the very least extremely hard (global conspiracy kind of hard), to abuse. > > That would lend a bit more credit to the system. > > That would mean, of course, that no revocation of any certificate from > any single central authority can affect routing on multiple networks. Martin - Given the validation that some operators already perform based on information in RIPE Database (including whois and rpsl), doesn't the same potential for network disruption due to misplaced governmental action exist today? I am trying to discern if your concern is regarding the theoretical existence of such risks, or the specifically the addition of RPKI because your view it as a more accessible mechanism for abuse? Thanks! /John From vaf at cisco.com Wed May 4 20:50:10 2011 From: vaf at cisco.com (Vince Fuller) Date: Wed, 4 May 2011 11:50:10 -0700 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110503143143.GG30227@Space.Net> References: <20110503143143.GG30227@Space.Net> Message-ID: <20110504185008.GA47653@vaf-mac1.cisco.com> > We'll have some "PI" in the global table, of course. But please look at > Alex Le Heux' numbers that will be presented on Thursday morning (about > 10:00) on what makes up the bulk of the current IPv4 routing table - and > you might be surprised. Is this presentation available online somewhere for those who can't be in Amsterdam this week and for whom the time of the prezo is not so convenient to participate remotely? There doesn't appear to be any pointer to the presentation material on the RIPE 62 meeting plan. I'm curious to see whether the drivers for global routing state have changed since I gave similar presentations a few years ago. FWIW, I'd assert that the dual role of IP addresses as both endpoint identifiers and routing locators means that finding a scalable solution that allows both provider independence and scalable routing is basically impossible without implementing separation of those roles into two separate numbering spaces. Thanks, --Vince From millnert at gmail.com Wed May 4 23:33:22 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 4 May 2011 17:33:22 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> Message-ID: On Wed, May 4, 2011 at 2:10 PM, John Curran wrote: > Martin - > > Given the validation that some operators already perform based on > information in RIPE Database (including whois and rpsl), doesn't the > same potential for network disruption due to misplaced governmental > action exist today? > > I am trying to discern if your concern is regarding the theoretical > existence of such risks, or the specifically the addition of RPKI > because your view it as a more accessible mechanism for abuse? > > Thanks! > /John Hi John, I'm concerned of a proliferation of a hierarchical routing policy structure on the Internet. I believe the RPKI scheme runs a much greater risk of proliferation than traditional RPSL, and this concerns me greatly. At the same time, I think the data already existing in for example RIPE's whois database and present technology is sufficient for the validation of customer and peer route announcements. However, I would much prefer if the power to change the holder of a prefix by design stayed with the current holder of the prefix only. This means of course that there would be no method to enforce a change of status externally. This of course becomes a bit problematic since it depends on the definition of what is a holder of a prefix. A good solution, I believe, to this question lies not in an external party declaring who's the holder or not of a prefix, but the holder of the prefix itself. In the case of the current RIR model, the RIR would transfer the rights of a prefix (by some cryptologic solution, I imagine) to the holder-now-owner of the prefix. An analogy: I pick up a very unique stone from a beach full of very individually unique stones -- I am the holder of this stone, not some other stone, and nobody else holds this stone but me. Or, I trade to myself a stone from another party, in a place where there are no unclaimed stones to be found. Only by holding a stone you have the power to speak. Nobody is able to say, certainly not prove, that I do not have the stone, that I have. Following the analogy, no central authority would be able to take my stone away from me - that would be theft. Also, no central authority is able to take the power to speak away from individuals in a room full of stone-holding people. Similarly, my peer's decision in determining whether or not I am the holder of a resource, and their decision of whether or not they accept my route announcement of said resource (or others) are *separate* issues. Acceptance of my origin route announcements, to me, seems like a decision that can be based on a number of factors, where the fact that I am the holder of the resource is one of them. A direct peer may have more reasons to accept my origin routes or not, such as whether or not I have paid my bill, and more. Another factor in accepting a route from a peer, origin or not, may be the path a route takes: Imagine the AS path contains "_64512 64513_", and for any number of reasons this specific AS hop (perhaps specific to the prefix itself, as well) becomes unfavorable to send your traffic over. It's imaginable that some kind of voting system can exist for AS paths, in addition to origin announcements (fool-proof proof of ownership could suffice here). Similarly, a voting system for AS:es themselves could exist. All this information (and more) could be used by a network to construct a multi-source based policy on what routes to accept, key being that it is the network that makes the decision itself, same as today, but with some key differences as well. Something along the lines of what I described above seems like the natural approach to this issue, to me. Many subsystems of what I mention have already been employed on the Internet to service various needs, and some of the ideas have similarities with RPKI/SIDR. And some of the things I mention are a bit different from what we do today. But an important point is that we *can* manage a system without central points of authority, which is highly desirable and preferable. Thanks, Kind Regards, Martin From jcurran at arin.net Wed May 4 23:58:18 2011 From: jcurran at arin.net (John Curran) Date: Wed, 4 May 2011 21:58:18 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> Message-ID: On May 4, 2011, at 5:33 PM, Martin Millnert wrote: > At the same time, I think the data already existing in for example > RIPE's whois database and present technology is sufficient for the > validation of customer and peer route announcements. It's likely that many feel that way, but there appears that there are also folks who wish to have an additional form of validation via RPKI. > A good solution, I believe, to this question lies not in an external > party declaring who's the holder or not of a prefix, but the holder of > the prefix itself. Are you saying that those who wish to make use of RPKI should not be able to, even if that's their choice of technology and yours is a more "multi-source peer based policy" choice? > Following the analogy, no central authority would be able to take my > stone away from me - that would be theft. Also, no central authority > is able to take the power to speak away from individuals in a room > full of stone-holding people. ... but apparently *would* be able to specify that no one may use RPKI even if that is someone else's particular preferred technology for securing their own stones? A statement that an RIR shall not support RPKI for the resources in its database is equivalent to deciding "no" on behalf those who want to make use of the optional service, correct? I understand concerns regarding cost or risk for an RIR considering RPKI (and in the ARIN region these are presently actively under consideration) and questions about return on investment also seem reasonable (since you can't support everything, and need to make sure you prioritize to services that will be actively used by the community), but this is first time I've heard an argument to the effect that simply offering the RPKI service will harm those not using it, and I really want to understand since that's not likely to be an effect specific to any one region. Thanks! /John From millnert at gmail.com Thu May 5 00:40:54 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 4 May 2011 18:40:54 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> Message-ID: Hi John, On Wed, May 4, 2011 at 5:58 PM, John Curran wrote: > On May 4, 2011, at 5:33 PM, Martin Millnert wrote: > >> At the same time, I think the data already existing in for example >> RIPE's whois database and present technology is sufficient for the >> validation of customer and peer route announcements. > > It's likely that many feel that way, but there appears that there are > also folks who wish to have an additional form of validation via RPKI. That is fine, modulo the implementation of RPKI. >> A good solution, I believe, to this question lies not in an external >> party declaring who's the holder or not of a prefix, but the holder of >> the prefix itself. > > Are you saying that those who wish to make use of RPKI should not be > able to, even if that's their choice of technology and yours is a more > "multi-source peer based policy" choice? If the proposal involves a central point of authority with the ability to revoke resources from a holder, or otherwise change, I do not wish this system implemented, no. Especially not if the central authority is a RIR, in this case RIPE. More on why below. >> Following the analogy, no central authority would be able to take my >> stone away from me - that would be theft. Also, no central authority >> is able to take the power to speak away from individuals in a room >> full of stone-holding people. > > ... but apparently *would* be able to specify that no one may use > RPKI even if that is someone else's particular preferred technology > for securing their own stones? No, that's not correct. One can not know, but one can imagine that a successful resource registry would be one where *only* the resource owner itself has the rights to register or de-register its resources. This is key, as is the resource-owning concept in this model -- there is no database which can be rewritten, somehow magically taking away someone's stone. > A statement that an RIR shall not > support RPKI for the resources in its database is equivalent to > deciding "no" on behalf those who want to make use of the optional > service, correct? Yeah, that seems correct. > I understand concerns regarding cost or risk for an RIR considering > RPKI (and in the ARIN region these are presently actively under > consideration) and questions about return on investment also seem > reasonable (since you can't support everything, and need to make > sure you prioritize to services that will be actively used by the > community), These are aspects I myself do not consider nearly as important as the greater Internet architecture aspect of these services. > but this is first time I've heard an argument to the > effect that simply offering the RPKI service will harm those not > using it, and I really want to understand since that's not likely > to be an effect specific to any one region. Right. The proliferation of any system which uses single authorities (the RIR:s databases) to form routing decisions exposes itself for abuse, more so the more it is proliferated. All it does is require a change of the database for the abuse to occur, obviously, which very likely would affect not only the users who have chosen to opt-in to this system, but also those who have not. It's already been said that in order to get the desired use out RPKI in terms of preventing youtube hijacking, a network is required to configure its RPKI-policies strictly. Thus, an abuse of the network's CA will then also possibly affect peers of this network, who may themselves not use RPKI for any number of reasons. If RPKI proliferates significantly, to the point where carriers start requiring signed resources from their customers, the abuse exposure of the single CA increases much, much more. I claim that the abuse risk exposure grows with the number of networks its removal or change of a resource can affect. (Not only revocation is a concern, but rewrite-to-other, for example, as well) Kind Regards, Martin From lists-ripe at c4inet.net Thu May 5 01:08:00 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 4 May 2011 23:08:00 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> Message-ID: <20110504230800.GE27143@cilantro.c4inet.net> On Wed, May 04, 2011 at 09:58:18PM +0000, John Curran wrote: >... but apparently *would* be able to specify that no one may use >RPKI even if that is someone else's particular preferred technology >for securing their own stones? A statement that an RIR shall not >support RPKI for the resources in its database is equivalent to >deciding "no" on behalf those who want to make use of the optional >service, correct? 1) If RPKI *is* universally used, there is no choice for those who do not wish the RIRs to be the final arbiters of their ability to speak on the internet. 2) If RPKI *is not* universally used, it doesn't increase security and is therefore a lot of administration effort to absolutely no purpose. 3) Self-signed certificates are most likely a strawman insofar as if an upstream/IXP demands the use of a RIR-signed certificate "for sound security reasons", your self-signed cert isn't worth the paper it's most likely not printed on. 4) What do the holders of legacy space who may not care to enter into a "contractual relationship" with a RIR do? rgds, Sascha From lists-ripe at c4inet.net Thu May 5 01:18:51 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 4 May 2011 23:18:51 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC17DAC.7040600@heanet.ie> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: <20110504231851.GF27143@cilantro.c4inet.net> On Wed, May 04, 2011 at 05:24:12PM +0100, Brian Nisbet wrote: >I really don't think it does. You seem to be imagining a scenario where >a national governement would just ring up the NCC and say, "revoke these >certs." I have seen no evidence to suggest this risk is anything close >to real. This has already happened, not a week ago the DHS (who else?) seized the domains of various online poker sites. TTBOMK similar has happened in the EU as well. I even seem to remember some organisation calling for RIPE to de-register certain resources. (Possibly the NCC care to enlighten us as to whether anything came of that?) > I suspect that a for profit global megacorp running such a > certification system would be far more vulnerable to such measures, but > even then, I don't see this as a large risk. Absolutely. Wikileaks <> Visa, Mastercard, Paypal, Verisign, &c? I think that is a *very* large risk indeed and I'd never propose to host the central authority for my routing to $private_corp either. Unless there are a lot of them, preferably in a lot of different countries... rgds, Sascha From jcurran at arin.net Thu May 5 01:19:29 2011 From: jcurran at arin.net (John Curran) Date: Wed, 4 May 2011 23:19:29 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> Message-ID: <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> On May 4, 2011, at 6:40 PM, Martin Millnert wrote: > > It's already been said that in order to get the desired use out RPKI > in terms of preventing youtube hijacking, a network is required to > configure its RPKI-policies strictly. > > Thus, an abuse of the network's CA will then also possibly affect > peers of this network, who may themselves not use RPKI for any number > of reasons. I understand how it would impact the network which has decided to make use of strict RPKI-based route validation (and therefore the network's customers by extension), but can you explain how it would otherwise effect that network's peers? If a network decides to use any specific technology as the basis of its routing architecture (e.g. route reflectors, an out of band ATM network, etc.) and that technology then fails, is compromised or abused, then the network's peers will be impacted in a very similar manner. I am again left trying to understand how the use of RPKI technology for route assurance affects the networks of those who don't use it (other than in the normal manner that all the routing technology is relied on) Thanks! /John From drc at virtualized.org Thu May 5 02:07:59 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 4 May 2011 17:07:59 -0700 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> Message-ID: <24EC7C8D-4285-406D-83C6-1E14F43774B3@virtualized.org> On May 4, 2011, at 4:19 PM, John Curran wrote: > I am again left trying to understand how the use of RPKI technology for > route assurance affects the networks of those who don't use it (other > than in the normal manner that all the routing technology is relied on) This sounds suspiciously like you are saying the goal of RPKI is for it not to be used. Regards, -drc From millnert at gmail.com Thu May 5 02:48:07 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 4 May 2011 20:48:07 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> Message-ID: Hi John, On Wed, May 4, 2011 at 7:19 PM, John Curran wrote: > On May 4, 2011, at 6:40 PM, Martin Millnert wrote: >> >> It's already been said that in order to get the desired use out RPKI >> in terms of preventing youtube hijacking, a network is required to >> configure its RPKI-policies strictly. >> >> Thus, an abuse of the network's CA will then also possibly affect >> peers of this network, who may themselves not use RPKI for any number >> of reasons. > > I understand how it would impact the network which has decided to make > use of strict RPKI-based route validation (and therefore the network's > customers by extension), but can you explain how it would otherwise > effect that network's peers? I'm glad you understand there is a risk an abuse of "RPKI" can have significant effects on the internet, since no doubt you are aware of "Tier 1" internet transit providers. I used the term "peer" in the general meaning, not applying any special significance to what kind of route or monetary exchange occurs using it. > I am again left trying to understand how the use of RPKI technology for > route assurance affects the networks of those who don't use it (other > than in the normal manner that all the routing technology is relied on) Nonetheless, I can illustrate it realistically for you, in an example using clear present-day industry terms: Network A is a transit customer of tier-1 network B. Network C and D are transit customers of tier-1 network E. Network C is exchanging full table with A, without any monetary exchange. Network B and E are exchanging full table with each other, also without any monetary exchange (they are tier-1). Network D announces prefix 1 to E. Transit provider E, being a very large company, has after some government pressure decided to enable strict RPKI filtering because of some tax breaks it received for doing so. It did not wish to enable it otherwise, because of some strong internal voices. But money speaks. Network E's CA is called Z. Prefix 1 is now suddenly removed from Z, after pressure on Z from unidentified entity X. Network E consequently ceases to forward prefix 1 to their non-paying peer network, B, and their other customer C. As a result, A, B, C, E all now have no way to reach D's prefix 1: this internet has now been partitioned, by unidentified entity X. Only a single network, E, implemented strict filtering of RPKI, yet A, not being a customer of E, lost access to 1, and all involved hardware is still functional. Unidentified entity X did not have to communicate with E at all. Kind Regards, Martin From randy at psg.com Thu May 5 08:50:54 2011 From: randy at psg.com (Randy Bush) Date: Thu, 05 May 2011 08:50:54 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <006801cc0a72$f0b7ab20$d2270160$@com> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> Message-ID: >>> If the community (as evidenced by this WG) tells the RIPE NCC not to >>> implement this (or more precisely to withdraw the service they are >>> already offering) then we simply open the way for private >>> certification companies in the RIPE region. >> >> in which case, i would prefer to arrange a pro-bono one. > >> So would I. But I can imagine going to my boss and saying "there are two >> alternatives for securing my address space: a pro-bono, best effort >> thing run by Randy or a professional one run on a commercial basis by >> Mega-Certicates Plc. Which would you like me to use? > > And why would that be better than having a not-for-profit org like > RIPE NCC that we are all a part of as a member, already doing this ? no one said otherwise. more careful reading would notice >>> If the community (as evidenced by this WG) tells the RIPE NCC not to >>> implement this (or more precisely to withdraw the service they are >>> already offering) then we simply open the way for private >>> certification companies in the RIPE region. randy From randy at psg.com Thu May 5 09:36:38 2011 From: randy at psg.com (Randy Bush) Date: Thu, 05 May 2011 09:36:38 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: > It's not about "not seeing a risk" as much as it is about _making > sure_, in the very design of the system, that it is *not possible* to > abuse. after all, we have been so successful with this approach in so many other aspects of the internet technology. shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything? randy From randy at psg.com Thu May 5 09:37:51 2011 From: randy at psg.com (Randy Bush) Date: Thu, 05 May 2011 09:37:51 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110504230800.GE27143@cilantro.c4inet.net> References: <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> <20110504230800.GE27143@cilantro.c4inet.net> Message-ID: > 4) What do the holders of legacy space who may not care to enter > into a "contractual relationship" with a RIR do? i try to secure routing as best i can randy From swmike at swm.pp.se Thu May 5 09:39:50 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 May 2011 09:39:50 +0200 (CEST) Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: On Thu, 5 May 2011, Randy Bush wrote: > shall we have a policy that covers black helicopters and sci-fi attacks > as well as demanding perfection in everything? No. Right now it's a bigger problem that people can announce other peoples address space (intentionally or not), so let's get that fixed. Put in a recommendation in the implementation descriptions that there should be the possibility of local policies for whitelisting, meaning it doesn't rely on the central authority for some resources, or we could have parallell authorities in multiple juristictions. -- Mikael Abrahamsson email: swmike at swm.pp.se From jim at rfc1035.com Thu May 5 09:45:04 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 5 May 2011 08:45:04 +0100 Subject: [address-policy-wg] the implications of RPKI certificate revokation In-Reply-To: <4DC17DAC.7040600@heanet.ie> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> On 4 May 2011, at 17:24, Brian Nisbet wrote: > You seem to be imagining a scenario where a national governement > would just ring up the NCC and say, "revoke these certs." I have > seen no evidence to suggest this risk is anything close to real. I suppose this depends on the definition of "real" and "evidence" Brian. If the NCC gets told to revoke a cert -- eg via a Dutch court order or equivalent -- it will have to do that. It would be sensible to assume that well-funded and/or litigious organisations might well be minded to pursue that avenue if they think getting a cert revoked will either disrupt or shut down some activities they dislike. Or bury their opponents in legal costs before it gets to the point where a court order gets issued. Certificates for routing will provide another vector for these sorts of layer-9 and up attacks. IMO it's foolish to assume or pretend otherwise. There are parallels with existing "control" mechanisms that governments and others use to restrict access to illegal content (for some definition of illegal content). If another control mechanism is made available, it will be used: that's the nature of the beast. [In this context RPKI has that control property as a side-effect.] Assuming that it won't or suggesting there's no real risk is just not credible, sorry. And from a practical perspective, is there really a material difference between a blacklist of naughty IP address blocks (commonly used today) and address blocks that have revoked certs (probably commonly used tomorrow) as control mechanisms? Personally, I'm not too fussed by this. The bad guys are not likely to be forming an orderly queue to get their certs from the NCC. And I think/hope the Dutch courts would take a robust view when governments or the Scientologists come looking for a court order. But in the final analysis, I struggle to see how an RPKI cert revocation would be any different from adding a prefix to the "official" blacklist that ISPs are encouraged to implement today. PS: Apologies for changing the Subject: header to something meaningful. From garry at nethinks.com Thu May 5 09:57:00 2011 From: garry at nethinks.com (Garry Glendown) Date: Thu, 05 May 2011 09:57:00 +0200 Subject: [address-policy-wg] the implications of RPKI certificate revokation In-Reply-To: <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> Message-ID: <4DC2584C.9030900@nethinks.com> On 05.05.2011 09:45, Jim Reid wrote: > On 4 May 2011, at 17:24, Brian Nisbet wrote: > >> You seem to be imagining a scenario where a national governement >> would just ring up the NCC and say, "revoke these certs." I have seen >> no evidence to suggest this risk is anything close to real. > > I suppose this depends on the definition of "real" and "evidence" Brian. > > If the NCC gets told to revoke a cert -- eg via a Dutch court order or > equivalent -- it will have to do that. It would be sensible to assume > that well-funded and/or litigious organisations might well be minded > to pursue that avenue if they think getting a cert revoked will either > disrupt or shut down some activities they dislike. Or bury their > opponents in legal costs before it gets to the point where a court > order gets issued. Certificates for routing will provide another > vector for these sorts of layer-9 and up attacks. IMO it's foolish to > assume or pretend otherwise. The question is whether there is some other way of ensuring routing consistency ... But given the current track record of many countries' legislative and legal developments, e.g. "hostage-taking" of domains in the US, internet filters in many European countries, etc., I must concur that the threat to the Internet once RPKI is introduced will be very real ... so, what alternatives can we come up with from a technical standpoint that is not prone to government or legal pressure? -garry From randy at psg.com Thu May 5 10:04:38 2011 From: randy at psg.com (Randy Bush) Date: Thu, 05 May 2011 10:04:38 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: >> shall we have a policy that covers black helicopters and sci-fi attacks >> as well as demanding perfection in everything? > No. :) > Right now it's a bigger problem that people can announce other peoples > address space (intentionally or not), so let's get that fixed. trying > Put in a recommendation in the implementation descriptions that there > should be the possibility of local policies for whitelisting, meaning > it doesn't rely on the central authority for some resources, or we > could have parallell authorities in multiple juristictions. i do appreciate contributions to draft-ietf-sidr-origin-ops randy From sander at steffann.nl Thu May 5 10:09:19 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 5 May 2011 10:09:19 +0200 Subject: [address-policy-wg] the implications of RPKI certificate revokation In-Reply-To: <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> Message-ID: <33FD600D-BE46-4AA1-BAA9-0FF24391A4BA@steffann.nl> Hi Jim, > Personally, I'm not too fussed by this. The bad guys are not likely to be forming an orderly queue to get their certs from the NCC. And I think/hope the Dutch courts would take a robust view when governments or the Scientologists come looking for a court order. But in the final analysis, I struggle to see how an RPKI cert revocation would be any different from adding a prefix to the "official" blacklist that ISPs are encouraged to implement today. I have been told that the Dutch law explicitly makes revocation and/or confiscation of 'our type' of certificates impossible, so a law change is necessary it make it possible at all. Not impossible, but it's another hurdle in the path of bad guys. I will try to get a formal statement from a lawyer to confirm this. If for some reason we need to fear intervention from the Dutch government we can look into the suggestion of Mikael about parallel authorities in multiple jurisdictions. And I would like to thank everybody for providing feedback on this proposal. Thank you, Sander Steffann APWG co-chair From fweimer at bfk.de Thu May 5 10:11:52 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 05 May 2011 08:11:52 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC17DAC.7040600@heanet.ie> (Brian Nisbet's message of "Wed, 04 May 2011 17:24:12 +0100") References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: <82zkn1o9br.fsf@mid.bfk.de> * Brian Nisbet: > I really don't think it does. You seem to be imagining a scenario > where a national governement would just ring up the NCC and say, > "revoke these certs." I have seen no evidence to suggest this risk is > anything close to real. It happens with domain names all the time. I don't see what so different about IP addresses. (Neither are content, but means to address content.) But why would this be a bad thing, as long as the required legal process is followed? -- 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 swmike at swm.pp.se Thu May 5 10:21:26 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 May 2011 10:21:26 +0200 (CEST) Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <82zkn1o9br.fsf@mid.bfk.de> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <82zkn1o9br.fsf@mid.bfk.de> Message-ID: On Thu, 5 May 2011, Florian Weimer wrote: > But why would this be a bad thing, as long as the required legal process > is followed? The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region. So basically it might make sense to bake a safety-valve into the system so that it's fairly easy to replace RIPE with something else in case meddling starts to happen. In DNS, one can choose not to use a US based domain name or registrar to avoid what's going on in DNS there, what would the similar action be in case the dutch legal system starts doing things we don't agree with, without turning off RPKI totally? -- Mikael Abrahamsson email: swmike at swm.pp.se From brian.nisbet at heanet.ie Thu May 5 10:21:55 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 05 May 2011 09:21:55 +0100 Subject: [address-policy-wg] Re: the implications of RPKI certificate revokation In-Reply-To: <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> Message-ID: <4DC25E23.2050905@heanet.ie> On 05/05/2011 08:45, Jim Reid wrote: > On 4 May 2011, at 17:24, Brian Nisbet wrote: > >> You seem to be imagining a scenario where a national governement would >> just ring up the NCC and say, "revoke these certs." I have seen no >> evidence to suggest this risk is anything close to real. > > I suppose this depends on the definition of "real" and "evidence" Brian. > > If the NCC gets told to revoke a cert -- eg via a Dutch court order or > equivalent -- it will have to do that. It would be sensible to assume > that well-funded and/or litigious organisations might well be minded to > pursue that avenue if they think getting a cert revoked will either > disrupt or shut down some activities they dislike. Or bury their > opponents in legal costs before it gets to the point where a court order > gets issued. Certificates for routing will provide another vector for > these sorts of layer-9 and up attacks. IMO it's foolish to assume or > pretend otherwise. My point was not that the cert could not be revoked (although Sander's follow-up post would suggest that might be the case), rather that it would be a long and difficult process. Certainly far, far more difficult than a government picking up the phone and saying "We are in a state of national emergency/rebellion/worried our citizens are learning things, shut down the Internet now." Brian. From fweimer at bfk.de Thu May 5 10:29:39 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 05 May 2011 08:29:39 +0000 Subject: [address-policy-wg] The implications of RPKI certificate revocation In-Reply-To: (Mikael Abrahamsson's message of "Thu, 5 May 2011 10:21:26 +0200 (CEST)") References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <82zkn1o9br.fsf@mid.bfk.de> Message-ID: <82r58do8i4.fsf_-_@mid.bfk.de> * Mikael Abrahamsson: > On Thu, 5 May 2011, Florian Weimer wrote: > >> But why would this be a bad thing, as long as the required legal >> process is followed? > > The problem here is that all of a sudden dutch courts might have > direct operational influence in all of the RIPE region. Only indirect influence. Direct influence is when you inject prefixes into the global table, which many of us can do (including RIPE NCC). > In DNS, one can choose not to use a US based domain name or registrar > to avoid what's going on in DNS there, what would the similar action > be in case the dutch legal system starts doing things we don't agree > with, without turning off RPKI totally? Add additional trust anchors? -- 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 jim at rfc1035.com Thu May 5 10:31:38 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 5 May 2011 09:31:38 +0100 Subject: [address-policy-wg] legal input into NCC operations In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <82zkn1o9br.fsf@mid.bfk.de> Message-ID: On 5 May 2011, at 09:21, Mikael Abrahamsson wrote: > The problem here is that all of a sudden dutch courts might have > direct operational influence in all of the RIPE region. You seem surprised that an organisation established in tbe Netherlands is subject to the jurisdiction of the Dutch courts. Perhaps you'd like me to tell you what bears do in the woods? From millnert at gmail.com Thu May 5 10:44:07 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 5 May 2011 04:44:07 -0400 Subject: [address-policy-wg] Re: the implications of RPKI certificate revokation In-Reply-To: <4DC25E23.2050905@heanet.ie> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> <4DC25E23.2050905@heanet.ie> Message-ID: On Thu, May 5, 2011 at 4:21 AM, Brian Nisbet wrote: > On 05/05/2011 08:45, Jim Reid wrote: >> >> On 4 May 2011, at 17:24, Brian Nisbet wrote: >> >>> You seem to be imagining a scenario where a national governement would >>> just ring up the NCC and say, "revoke these certs." I have seen no >>> evidence to suggest this risk is anything close to real. >> >> I suppose this depends on the definition of "real" and "evidence" Brian. >> >> If the NCC gets told to revoke a cert -- eg via a Dutch court order or >> equivalent -- it will have to do that. It would be sensible to assume >> that well-funded and/or litigious organisations might well be minded to >> pursue that avenue if they think getting a cert revoked will either >> disrupt or shut down some activities they dislike. Or bury their >> opponents in legal costs before it gets to the point where a court order >> gets issued. Certificates for routing will provide another vector for >> these sorts of layer-9 and up attacks. IMO it's foolish to assume or >> pretend otherwise. > > My point was not that the cert could not be revoked (although Sander's > follow-up post would suggest that might be the case), rather that it would > be a long and difficult process. Certainly far, far more difficult than a > government picking up the phone and saying "We are in a state of national > emergency/rebellion/worried our citizens are learning things, shut down the > Internet now." Simply by having the possibility to revoke certifications or db entries, the RIPE NCC invites gunned madmen, be them from governments or not, to enter their offices and make them make certain unwanted sites/prefixes on the internet disappear. I'd prefer if there was no reason for them to attempt this, since there would be no technical way to do it. Why is revocation of assigned addresses in this manner necessary? Kind Regards, Martin From swmike at swm.pp.se Thu May 5 10:49:58 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 May 2011 10:49:58 +0200 (CEST) Subject: [address-policy-wg] Re: legal input into NCC operations In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <82zkn1o9br.fsf@mid.bfk.de> Message-ID: On Thu, 5 May 2011, Jim Reid wrote: > On 5 May 2011, at 09:21, Mikael Abrahamsson wrote: > >> The problem here is that all of a sudden dutch courts might have direct >> operational influence in all of the RIPE region. > > You seem surprised that an organisation established in tbe Netherlands is > subject to the jurisdiction of the Dutch courts. No I am not, but I am not happy to hand them the power to influence my routing global table without possibility of overriding their decision because what they think is good for .nl doesn't necessarily have to be good for the rest of the countries my employer is active in. -- Mikael Abrahamsson email: swmike at swm.pp.se From alexb at ripe.net Thu May 5 10:19:55 2011 From: alexb at ripe.net (Alex Band) Date: Thu, 5 May 2011 10:19:55 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: On 5 May 2011, at 10:04, Randy Bush wrote: >>> shall we have a policy that covers black helicopters and sci-fi attacks >>> as well as demanding perfection in everything? >> No. > > :) > >> Right now it's a bigger problem that people can announce other peoples >> address space (intentionally or not), so let's get that fixed. > > trying > >> Put in a recommendation in the implementation descriptions that there >> should be the possibility of local policies for whitelisting, meaning >> it doesn't rely on the central authority for some resources, or we >> could have parallell authorities in multiple juristictions. > > i do appreciate contributions to draft-ietf-sidr-origin-ops Good point, because the implementation that the RIRs are making is based on the work that is being done here. Some elements of Certification that people are discussing here should actually be held in the IETF SIDR WG. Some of the concerns have actually already been taken into account there. In a nutshell: My take is that Resource Certification drives routing *preferences*. If a network operator sees an expired or invalid prefix, they can investigate and *choose* to take action. This also applies to decisions when using router hardware, as described in section 5 of "BGP Prefix Origin Validation": http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-01#section-5 "Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." (Emphasis mine) -Alex From millnert at gmail.com Thu May 5 11:05:42 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 5 May 2011 05:05:42 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <82zkn1o9br.fsf@mid.bfk.de> Message-ID: Mikael, On Thu, May 5, 2011 at 4:21 AM, Mikael Abrahamsson wrote: > On Thu, 5 May 2011, Florian Weimer wrote: > >> But why would this be a bad thing, as long as the required legal process >> is followed? > > The problem here is that all of a sudden dutch courts might have direct > operational influence in all of the RIPE region. > > So basically it might make sense to bake a safety-valve into the system so > that it's fairly easy to replace RIPE with something else in case meddling > starts to happen. In DNS, one can choose not to use a US based domain name > or registrar to avoid what's going on in DNS there, what would the similar > action be in case the dutch legal system starts doing things we don't agree > with, without turning off RPKI totally? While I appreciate the idea of safety-valves and a sort of reactive safety process, is it not inherently better to implement them from the beginning? Ie, your idea about placing multiple trust anchors in multiple jurisdictions from the beginning. But you still have not solved the core of the problem in this way: >From where will they get their prefix information? Since you're not suggesting any modifications to the current internet numbers role of the RIPE NCC, the information is going to be sourced from RIPE's DB somehow, anyway. Do you suggest independent and open review of all changes of data before installation in the 2nd-tier trust anchors? Essentially a human-involving process will absolutely be required before a revocation, or change to $FOO, of a resource and its resource certificate will be allowed to spread from the source (RIPE's DB) to its 2nd-tier trust anchors. Who will vote on whether a change is OK or not? A pretty decent amount of persons will have to be involved to guard well against abuse (think EU/EC/EG court decisions / laws.) You must assume from the start that the legal process at the source is flawed -- how do you protect the mirrors from abuse? And if the legal process at the source is broken, how do you move the source IRR information away from it? Or, are you suggesting multiple independent IRRs covering the same data, where a user now has to keep individual and separate communications with each and one of them to update the IRR data, negotiate change of ownership of a resource, etc. I do appreciate a very useful discussion on this topic and seeking constructive solutions to the concerns outlined. And for the record I prefer making it completely pointless for someone to even consider sending black helicopters (this can be done), than to consider how to best protect oneself from them. :) Note well that my voting / change process questions raised above apply equally well whether there is only one IRR and one trust-anchor at RIPE NCC, or multiple 2nd-tier ones. Kind Regards, Martin From millnert at gmail.com Thu May 5 11:11:33 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 5 May 2011 05:11:33 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: Alex, On Thu, May 5, 2011 at 4:19 AM, Alex Band wrote: > In a nutshell: My take is that Resource Certification drives routing *preferences*. If a network operator sees an expired or invalid prefix, they can investigate and *choose* to take action. This also applies to decisions when using router hardware, as described in section 5 of "BGP Prefix Origin Validation": > http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-01#section-5 > > "Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." ?(Emphasis mine) I am hoping you can give some practical examples on how one goes about considering routes invalid with utmost care. Kind Regards, Martin From andrei.robachevsky at gmail.com Thu May 5 11:17:56 2011 From: andrei.robachevsky at gmail.com (Andrei Robachevsky) Date: Thu, 05 May 2011 11:17:56 +0200 Subject: [address-policy-wg] the implications of RPKI certificate revokation In-Reply-To: <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <366F9D36-CA64-4B5E-90DD-67D346CDE707@rfc1035.com> Message-ID: <4DC26B44.2070903@gmail.com> Jim Reid wrote on 5/5/11 09:45 : [...] > Personally, I'm not too fussed by this. The bad guys are not likely to > be forming an orderly queue to get their certs from the NCC. And I > think/hope the Dutch courts would take a robust view when governments or > the Scientologists come looking for a court order. But in the final > analysis, I struggle to see how an RPKI cert revocation would be any > different from adding a prefix to the "official" blacklist that ISPs are > encouraged to implement today. > Yes. At the end of the day application of RPKI or BGPsec is a local ISP policy decision. If filtering based on the current RIR registry databases were ubiquitous among the ISPs, these databases would have had the same effect as the RPKI. I doubt application of the RPKI will become ubiquitous in the near future. And if a common local policy is that is just increases the preference of the route, absence of a validatable ROA means that the system falls back to insecure, which is what we have now. But it will still protect (modulo no path protection) against address hijacking. Andrei From malcolm at linx.net Thu May 5 11:39:14 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Thu, 05 May 2011 10:39:14 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: <4DC27042.6040909@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/05/2011 08:36, Randy Bush wrote: > shall we have a policy that covers black helicopters and sci-fi attacks > as well as demanding perfection in everything? Black helicopters in slides presentations are amusing. But if you seriously think the governments, law enforcement and private litigants won't see this as a new capability to prevent traffic to certain networks you haven't (note to self: be polite, Malcolm) all the facts. Fact 1. In the Co-operation WG where British law enforcement officials have /already/ been asking for procedures to re-assign netblocks to their agency because they think that would help prevent traffic flowing to places where crimes occur. Of course, as a community we could refuse to cooperate, unless/until the NCC is compelled. Nonetheless, this demonstrates LEAs do have both the awareness and the intent; it's not a wild conspiracy theory. Fact 2. There is draft legislation ALREADY going through the EU that if passed would require all EU governments (including the Dutch) to introduce laws to "take the necessary measures to obtain the blocking of access" to certain Internet locations [1]. It could be argued that this would give Dutch LEAs sufficient power to require the RIPE NCC to revoke a certificate - or perhaps not; it probably depends on how the Netherlands chooses to implement this European law if/when it goes through. I would say that this shows that the risk, although not certain, is pressing and immediate, not a vague worry for the distant future. Fact 3. There is continuous lobbying within the EU, to which Dutch law is subject, for greater measures to require Internet intermediaries to prevent the reachability of certain Internet locations. This has mainly focussed on network operators, but more recently EU officials have opened dialogue with ccTLD registries and the RIPE NCC too. There's no end of topics for which some people believe controlling access to Internet locations would be a useful means of fighting some social evil - child pornography and copyright infringement have in my estimation the largest and most organised lobbying in favour of such measures, but there's also active work in the areas of terrorism, "cybercrime" generally, gambling, xenophobia racism and hate-speech, just off the top of my head. In my view the range of actors who would seek to use any new capability is wide, and they are outside our control as a technical community. They operate at the political level, and they have no interest in the technical community's opinions, apart from an answer to the question "What is it technically possible for the RIPE NCC to do to impede reachability to the locations we specify?" Once the RIPE NCC comes to be seen as a "gateway controller" that can significantly impact the reachability of "bad" networks, it will irrevocably become a ongoing target for use as a tool of public policy enforcement. Malcolm [1] I'm referring to Article 21 of the Draft Directive on Child Sexual Exploitation, which is currently in Trialogue negotiations between the European Parliament, Commission, and Council of Ministers. http://bit.ly/9D5cg8 - -- 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/ iEYEARECAAYFAk3CcEIACgkQJiK3ugcyKhQ1TACfW/MetiGeGRB7/vg+59K3JjVS OmsAni1rVleSySJbJ8ZFlviv+tiqTkdL =eYwd -----END PGP SIGNATURE----- From boggits at gmail.com Thu May 5 10:47:07 2011 From: boggits at gmail.com (boggits) Date: Thu, 5 May 2011 10:47:07 +0200 Subject: [address-policy-wg] legal input into NCC operations In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <82zkn1o9br.fsf@mid.bfk.de> Message-ID: On 5 May 2011 10:31, Jim Reid wrote: > On 5 May 2011, at 09:21, Mikael Abrahamsson wrote: > >> The problem here is that all of a sudden dutch courts might have direct >> operational influence in all of the RIPE region. > > You seem surprised that an organisation established in tbe Netherlands is > subject to the jurisdiction of the Dutch courts. Maybe we should start a discussion about alternative (new or old) legal entities (and their locations) that might be more suited to running the RPKI db /me runs J -- James Blessing 07989 039 476 From jcurran at arin.net Thu May 5 11:50:16 2011 From: jcurran at arin.net (John Curran) Date: Thu, 5 May 2011 09:50:16 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> Message-ID: On May 4, 2011, at 8:48 PM, Martin Millnert wrote: > ... > Network C and D are transit customers of tier-1 network E. > ... > Network D announces prefix 1 to E. > > Transit provider E, being a very large company, has after some > government pressure decided to enable strict RPKI filtering > ... > Only a single network, E, implemented strict filtering of RPKI, yet A, > not being a customer of E, lost access to 1, and all involved hardware > is still functional. Prefix 1 is for customer D (of network E); ergo, A lost access to D because D's choice of service provider. D voluntarily choose its service provider, and can always choose another. There is no party that was impacted without a choice; D choose A because of their much discussed "route assurance" technology, and that turned out (in your example) to be a bad choice. Another example might have it be a wise choice, but there's still no one impacted who didn't get any choice. How is this different than network D deciding to build a network with with an innovative routing technology, which may serve to distinguish it in a positive (or negative) manner based on actual performance? Back to my original question: "I understand how it would impact the network which has decided to make use of strict RPKI-based route validation (and therefore the network's customers by extension), but can you explain how it would otherwise effect that network's peers?" Thanks, /John From malcolm at linx.net Thu May 5 12:07:53 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Thu, 05 May 2011 11:07:53 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> Message-ID: <4DC276F9.9080405@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/05/2011 10:50, John Curran wrote: > How is this different than network D deciding to build a network with > with an innovative routing technology, which may serve to distinguish > it in a positive (or negative) manner based on actual performance? This is different because it introduces a new party into the equation, X, who wants to impede reachability rather than improve it, and because X has legal power to supersede E's choices and override their self-interest. In your example, A is affected by the consequences of E trying to build a better network. Maybe E gets it wrong, and A suffers as a result too, but at least E is trying to do better and is likely to correct their behaviour or will gradually decline in influence. In Martin's example A is also affected by the consequences of X forcing E to reduce the connectivity of their network. E no longer has a choice, so he cannot "correct" his behaviour. Nor will E be easily superseded by competitor networks, because all his competitors are also subject to X. This could of course happen now - and I spend a large chunk of my time working to avoid this. In my view, handing X on a plate a mechanism to direct many Es all at once will greatly increase X's propensity to intervene. Political/legal control does make a qualitative difference. - -- 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/ iEYEARECAAYFAk3CdvkACgkQJiK3ugcyKhSjswCff7AGd+KvBUXZASJCK/qMmq6e jM8An0JvaSVih6nIGIp1Cf5F88rsOXna =VTdq -----END PGP SIGNATURE----- From millnert at gmail.com Thu May 5 12:19:49 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 5 May 2011 06:19:49 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <65ABB5EF-3EAD-4DE3-97B2-A377E2C14096@corp.arin.net> <070645A3-D06F-4D32-9A5A-6014107A65E8@arin.net> Message-ID: Hi John, On Thu, May 5, 2011 at 5:50 AM, John Curran wrote: > On May 4, 2011, at 8:48 PM, Martin Millnert wrote: > >> ... >> Network C and D are transit customers of tier-1 network E. >> ... >> Network D announces prefix 1 to E. >> >> Transit provider E, being a very large company, has after some >> government pressure decided to enable strict RPKI filtering >> ... >> Only a single network, E, implemented strict filtering of RPKI, yet A, >> not being a customer of E, lost access to 1, and all involved hardware >> is still functional. > > Prefix 1 is for customer D (of network E); ergo, A lost access to D > because D's choice of service provider. ?D voluntarily choose its > service provider, and can always choose another. Can it always choose one which is not using this new "route assurance technology"? > There is no party > that was impacted without a choice; D choose A because of their much > discussed "route assurance" technology, and that turned out (in your > example) to be a bad choice. ?Another example might have it be a wise > choice, but there's still no one impacted who didn't get ?any choice. > > How is this different than network D deciding to build a network with > with an innovative routing technology, which may serve to distinguish > it in a positive (or negative) manner based on actual performance? Are you suggesting that the more ways we have to break the internet, the better? You would probably argue that RPKI can improve performance by removing intentional and un-intentional route hijacking. But to this I must ask: Can we quantify how often this happen? It would be a very useful data point going forward. We could also quantify how many jurisdictions have some form of internet filtering legislation in place today. And take a look at what's in the legal pipeline. A well known block list (the existence of it, not its content) was tested at one point: 98% false-positives. (the remaining 2% was permanently fixed via simple email, and a ~3h response time...) Using this metric as the track record for gov internet filtering, and extending it to our discussion, mistakes will frequently happen, and the entire endeavor is flawed to its very bones. But this is not the debate of the specifics of the legal processes in various jurisdictions, I'm merely showing (and #include Malcom's posts) a real big risk of having a larger stream of failures coming from the abuse of a highly proliferated RPKI than the failures it was designed to fix. As Sascha put it earlier in the discussion: "the cure is infinitely worse than the disease" Key in my example is otherwise what was not written out: If you scale the example up, and use of RPKI with strict filtering has proliferated, X has a good vector to negatively and widely affect internet routing via Z, which is a completely new thing on the Internet from today. > Back to my original question: ?"I understand how it would impact the > network which has decided to make use of strict RPKI-based route > validation (and therefore the network's customers by extension), but > can you explain how it would otherwise effect that network's peers?" I thought I did explain this in my example: B lost access to D, B *is a peer* of E, who uses strict RPKI-based route validation. This is a technicality in the bigger scheme as described above and by Malcom, however. Kind Regards, Martin From poty at iiat.ru Thu May 5 12:20:57 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Thu, 5 May 2011 14:20:57 +0400 Subject: [address-policy-wg] getting second IPv6 PA as a LIR Message-ID: On 05/04/2011 11:55 AM, poty at iiat.ru wrote: > Why then you should apply for PI? In case of problems RIPE (for example) would speak with a single LIR, not with thousands of widespread customers. RIPE is always speaking with the LIR, in accordance to 2007-01 policy. All new PI users are always connected with some LIR. If you want obtain PI directly from RIPE, you'll pay additional money for the contract with RIPE, it's documented on the website. ----------------- Yes, but it means that RIPE is not always "speak" exclusively with LIRs. More than that, the "customer" has rights to change the hosting LIR in every moment. It further complicates things. //////////// And generally, I don't prefer crapping PA space with such deaggregation caused just by the PI-blocking policy. ----------------- It was my idea behind the lines. Most Internet players are not so bad to do illegal and harmful things. It's not only money matters. From jcurran at arin.net Thu May 5 12:29:57 2011 From: jcurran at arin.net (John Curran) Date: Thu, 5 May 2011 10:29:57 +0000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC27042.6040909@linx.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <4DC27042.6040909@linx.net> Message-ID: On May 5, 2011, at 5:39 AM, Malcolm Hutty wrote: > ... > Once the RIPE NCC comes to be seen as a "gateway controller" that can > significantly impact the reachability of "bad" networks, it will > irrevocably become a ongoing target for use as a tool of public policy > enforcement. Malcolm - Is the existing RIPE Database (both as address and routing registry) seen or not seen as a "gateway controller" per above? I think it would be helpful to the point to outline why the current system has not been an ongoing target, and why one based on RPKI will irrevocably become one. Thanks! /John From swmike at swm.pp.se Thu May 5 12:35:34 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 May 2011 12:35:34 +0200 (CEST) Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <4DC27042.6040909@linx.net> Message-ID: On Thu, 5 May 2011, John Curran wrote: > Is the existing RIPE Database (both as address and routing registry) > seen or not seen as a "gateway controller" per above? Not. Right now there is a very low coupling between the contents of the RIPE database and what is actually allowed for routing on the Internet, very few operators actually use RPSL or alike to create filters, thus whatever is in the RIPE database doesn't have an immediate short term operational impact. With a tighter coupling between RIPE database contents and Internet Routing, this changes. -- Mikael Abrahamsson email: swmike at swm.pp.se From melchior.aelmans at kpn.com Thu May 5 15:13:25 2011 From: melchior.aelmans at kpn.com (melchior.aelmans at kpn.com) Date: Thu, 5 May 2011 15:13:25 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) References: <002501cc0b25$745c8e20$5d15aa60$@com> Message-ID: <406DC20365FF4D4D9082F1AF529651E4839026F982@W2056.kpnnl.local> Dear Emilio, We support this proposal from Erik and Jordi. Thanks and regards, Melchior Aelmans KPN Mobile CARE Continuity Core Data From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Emilio Madaio Sent: Friday, April 15, 2011 11:23 AM To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Dear Colleagues, A proposed change to the RIPE Document ripe-512,"IPv6 Address Allocation and Assignment Policy", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-02 We encourage you to review this proposal and send your comments to before 13 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamed at skydsl.ir Thu May 5 15:50:26 2011 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Thu, 5 May 2011 18:20:26 +0430 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: References: <002501cc0b25$745c8e20$5d15aa60$@com> <406DC20365FF4D4D9082F1AF529651E4839026F982@W2056.kpnnl.local> Message-ID: I agree with this proposal. Best Regards -- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrei.robachevsky at gmail.com Thu May 5 16:36:37 2011 From: andrei.robachevsky at gmail.com (Andrei Robachevsky) Date: Thu, 05 May 2011 16:36:37 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC27042.6040909@linx.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <4DC27042.6040909@linx.net> Message-ID: <4DC2B5F5.4060500@gmail.com> Malcolm, There was an IGF workshop in Vilnius last year "Routing and Resource Certification: Self-governance and security at the core of Internet operations" (http://www.intgovforum.org/cms/component/content/article/102-transcripts2010/632-158) I found Paul Vixie's remark he made there very useful in articulating the trade-offs we are facing here. He said: "I'd like to move from the situation we're in now, where the good guys have no recourse against the bad guys, to a new situation where the good guys will have some recourse against other good guys if these powers are misused, and that is the choice I'd rather see discussed [...]" Andrei Malcolm Hutty wrote on 5/5/11 11:39 : > On 05/05/2011 08:36, Randy Bush wrote: >> shall we have a policy that covers black helicopters and sci-fi attacks >> as well as demanding perfection in everything? > > Black helicopters in slides presentations are amusing. But if you > seriously think the governments, law enforcement and private litigants > won't see this as a new capability to prevent traffic to certain > networks you haven't (note to self: be polite, Malcolm) all the facts. > > Fact 1. In the Co-operation WG where British law enforcement officials > have /already/ been asking for procedures to re-assign netblocks to > their agency because they think that would help prevent traffic flowing > to places where crimes occur. Of course, as a community we could refuse > to cooperate, unless/until the NCC is compelled. > > Nonetheless, this demonstrates LEAs do have both the awareness and the > intent; it's not a wild conspiracy theory. > > Fact 2. There is draft legislation ALREADY going through the EU that if > passed would require all EU governments (including the Dutch) to > introduce laws to "take the necessary measures to obtain the blocking of > access" to certain Internet locations [1]. It could be argued that this > would give Dutch LEAs sufficient power to require the RIPE NCC to revoke > a certificate - or perhaps not; it probably depends on how the > Netherlands chooses to implement this European law if/when it goes through. > > I would say that this shows that the risk, although not certain, is > pressing and immediate, not a vague worry for the distant future. > > Fact 3. There is continuous lobbying within the EU, to which Dutch law > is subject, for greater measures to require Internet intermediaries to > prevent the reachability of certain Internet locations. This has mainly > focussed on network operators, but more recently EU officials have > opened dialogue with ccTLD registries and the RIPE NCC too. > > There's no end of topics for which some people believe controlling > access to Internet locations would be a useful means of fighting some > social evil - child pornography and copyright infringement have in my > estimation the largest and most organised lobbying in favour of such > measures, but there's also active work in the areas of terrorism, > "cybercrime" generally, gambling, xenophobia racism and hate-speech, > just off the top of my head. > > In my view the range of actors who would seek to use any new capability > is wide, and they are outside our control as a technical community. They > operate at the political level, and they have no interest in the > technical community's opinions, apart from an answer to the question > "What is it technically possible for the RIPE NCC to do to impede > reachability to the locations we specify?" > > Once the RIPE NCC comes to be seen as a "gateway controller" that can > significantly impact the reachability of "bad" networks, it will > irrevocably become a ongoing target for use as a tool of public policy > enforcement. > > > Malcolm > > [1] I'm referring to Article 21 of the Draft Directive on Child Sexual > Exploitation, which is currently in Trialogue negotiations between the > European Parliament, Commission, and Council of Ministers. > http://bit.ly/9D5cg8 > From sander at steffann.nl Thu May 5 16:44:41 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 5 May 2011 16:44:41 +0200 Subject: [address-policy-wg] On the agenda for tomorrow: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Message-ID: <7789FF98-C44F-4C10-8AC7-49BAFE454602@steffann.nl> Hello WG, We will have a discussion about 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) on the agenda for tomorrow's address policy session at RIPE 62. We also will have a short presentation there about the issues that have been discussed on this mailing list over the last couple of days. The session is from 9:00 to 10:30 and remote participation is possible at http://ripe62.ripe.net/live/main. Thank you, Sander Steffann APWG co-chair From swmike at swm.pp.se Thu May 5 19:30:27 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 May 2011 19:30:27 +0200 (CEST) Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <20110415092235.748716A0A7@postboy.ripe.net> References: <20110415092235.748716A0A7@postboy.ripe.net> Message-ID: On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Fri May 6 08:43:56 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 6 May 2011 08:43:56 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Message-ID: Hello WG, I asked the RIPE NCC to get legal counsel on the possibilities of a court ordering the RIPE NCC to revoke or confiscate RPKI certificates. Here is the full answer we received: ========== The RIPE NCC is an association under Dutch law and therefore subject to the Dutch legislation. RIPE NCC has consulted several external lawyers, and has obtained an analysis of the legal situation based on current, existing Dutch legislation. This analysis takes into account Dutch Criminal, Civil and Administrative law. Certificates are directly linked to the registration of the Internet number resources. There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources. In the absence of such legislation, a court cannot order the revocation of certificates. It is the RIPE NCC?s view, based on this analysis, that the RIPE NCC cannot be ordered to revoke resource certificates. ========== Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. Sander Steffann APWG co-chair From poty at iiat.ru Fri May 6 08:59:44 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Fri, 6 May 2011 10:59:44 +0400 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Message-ID: According to my messages to the WG earlier and taking into good consideration of the point of view of Mikael Abrahamsson I oppose the policy too. Vladislav Potapov IIAT, Ltd. -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Mikael Abrahamsson Sent: Thursday, May 05, 2011 9:30 PM To: address-policy-wg at ripe.net Cc: policy-announce at ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Fri May 6 09:01:27 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 6 May 2011 09:01:27 +0200 (CEST) Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: Message-ID: On Fri, 6 May 2011, Sander Steffann wrote: > In the absence of such legislation, a court cannot order the revocation > of certificates. In several countries, we've seen courts ordering ISPs to block accessibility to certain sites involving not using DNS names (denmark and thepiratebay.org for instance, or the domain names transferred to US authorities just a few months ago) or block access IP-wise (Black Internet in Sweden). I am sure there was no specific law handling this, but the laws at least in these countries are flexible enough that other laws can be used to order things around. > Of course laws can change, but the advice above may address some of the > concerns raised about the RPKI infrastructure. It's good that it has been answered for dutch law, I wonder what equivalent question would have been answered in Sweden and Denmark or the US 5 years ago. -- Mikael Abrahamsson email: swmike at swm.pp.se From vegar at rentarack.no Fri May 6 09:13:49 2011 From: vegar at rentarack.no (=?ISO-8859-1?Q?Vegar_L=F8v=E5s?=) Date: Fri, 06 May 2011 09:13:49 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <20110415092235.748716A0A7@postboy.ripe.net> References: <20110415092235.748716A0A7@postboy.ripe.net> Message-ID: <4DC39FAD.7000802@rentarack.no> I agree with this proposal. -- Best regards Vegar L?v?s Rent a Rack AS On 15.04.2011 11:22, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > From malcolm at linx.net Fri May 6 09:28:44 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Fri, 06 May 2011 08:28:44 +0100 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: Message-ID: <4DC3A32C.2030704@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/2011 07:43, Sander Steffann wrote: > There is no specific Dutch legislation that can be used to order the > deregistration of Internet number resources or change the > registration details of Internet number resources. Nor is there any > legislation that applies to the revocation of certificates over > Internet number resources. > > In the absence of such legislation, a court cannot order the > revocation of certificates. > > It is the RIPE NCC?s view, based on this analysis, that the RIPE NCC > cannot be ordered to revoke resource certificates. There are a couple of other possible current vectors, as well as the question of future legislation. 1. Legal counsel referred to the lack of legislation that specifically mentioned revocation of certificates. Most of the existing and draft legislation I know of (not Dutch, but some EU) refers instead to "preventing access to Internet [locations/sites/content]". As a generalisation, courts will not normally order someone to do something utterly outside their power, but may order someone to take such steps as they are able to achieve an end if they are seen as being able to make a significant contribution, even if that contribution won't be wholly successful. For example, courts sometimes order newspapers and broadcasters not to publish information, even though they know the information may end up being published online. Right now it is commonly said that RIPE NCC does not have control over routing, so a court would be unlikely to order the RIPE NCC to prevent access to an Internet location. If, as a result of this policy, RIPE NCC is seen to have the capability to significantly reduce the reachability of an Internet location, a court might be willing to order it to "prevent access to the location" to the extent that it is able. No explicit mention need be made of certificate revocation. 2. Within some jurisdictions LEAs argue that Internet intermediaries are themselves criminally liable if they "facilitate" criminal activity by refusing to prevent access to an Internet location where criminal activity is ongoing, once they have been informed of the criminal activity. Intermediaries are thus induced to block access without a court order being necessary. Within the EU, network operators have special protection against this threat from the E-Commerce Directive as "mere conduits", but unfortunately registries like the RIPE NCC probably do not fit the definition of "mere conduit". In the UK, Nominet (the .uk ccTLD registry) has been induced to suspend domain registrations using this argument. RIPE NCC might in future be exposed to the same pressure. 3. Finally, new legislation not only /could/ be created, but most certainly will. The Netherlands is subject to EU law. Whether such new law would affect the RIPE NCC we cannot be certain, but I am certain that the only thing restraining lobbyists is a lack of awareness of the existence of RIPE NCC (and awareness is increasing), and a belief that the RIPE NCC has no relevant technical capability, which this policy would change. - -- 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/ iEYEARECAAYFAk3DoywACgkQJiK3ugcyKhSlSACdGyEFtxJUai+xrWtGB/vwZjoJ VnUAoLpgRXaghPiUTTDwF3SIoQxgCEa+ =eFIF -----END PGP SIGNATURE----- From randy at psg.com Fri May 6 10:23:36 2011 From: randy at psg.com (Randy Bush) Date: Fri, 06 May 2011 10:23:36 +0200 Subject: [address-policy-wg] pointer to ietf sidr wg Message-ID: as requested by gert, here are pointers to the work of the sidr wg of the ietf main page of wg == documents http://datatracker.ietf.org/wg/sidr/ charter of sidr wg http://datatracker.ietf.org/wg/sidr/charter/ mailing list http://www.ietf.org/mail-archive/web/sidr/current/maillist.html if i can be of help in navigation or interpretation, feel free to write to me randy, just another bozo on the routing security bus From boggits at gmail.com Fri May 6 11:06:44 2011 From: boggits at gmail.com (boggits) Date: Fri, 6 May 2011 11:06:44 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: Message-ID: On 6 May 2011 08:43, Sander Steffann wrote: > Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. > This is indeed true but misses the point that laws tend to exist either when there is an actual 'thing' to make laws about or are framed in such a way to allow the courts the latitude to include 'new things' in the same piece of legislation. Since RPKI is not currently a 'thing' but rather a 'new thing' I would be wary of relying on legal opinion that says: "There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources." What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level J -- James Blessing 07989 039 476 From lists-ripe at c4inet.net Fri May 6 12:24:58 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 6 May 2011 10:24:58 +0000 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Message-ID: <20110506102458.GG27143@cilantro.c4inet.net> I support this proposal. rgds, sascha Luck From davidm at futureinquestion.net Fri May 6 12:28:42 2011 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 06 May 2011 12:28:42 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <20110415092235.748716A0A7@postboy.ripe.net> References: <20110415092235.748716A0A7@postboy.ripe.net> Message-ID: <4DC3CD5A.7050405@futureinquestion.net> Dear address-policy-wg, I would like to express my support for this policy proposal. The promise of auto-configuration making transitioning between v6 prefixes seamless is not yet fully delivered, and eliminating the manual renumbering overhead when moving between service providers, as well as having a clear path to multihoming ("just add ASN") should assure a lively Internet services market for years to come. -- Respectfully yours, David Monosov On 04/15/2011 11:22 AM, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > From job at instituut.net Fri May 6 12:40:27 2011 From: job at instituut.net (Job Snijders) Date: Fri, 6 May 2011 12:40:27 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <4DC3CD5A.7050405@futureinquestion.net> References: <20110415092235.748716A0A7@postboy.ripe.net> <4DC3CD5A.7050405@futureinquestion.net> Message-ID: Dear All, I agree with removing the multi-homing requirement for IPv6 PI. Its pretty awkward to send your customers to a competitor because to deploy IPv6 PI space he or she needs to be multi-homed. Also, rising technologies such as LISP allow end-users to be multi-homed in a way that is transparent to the DFZ, so why bother restricting people to BGP multi-homing. Kind regards, Job Snijders On 04/15/2011 11:22 AM, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > From michiel at klaver.it Fri May 6 13:08:35 2011 From: michiel at klaver.it (Michiel Klaver) Date: Fri, 06 May 2011 13:08:35 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <4DC3CD5A.7050405@futureinquestion.net> References: <20110415092235.748716A0A7@postboy.ripe.net> <4DC3CD5A.7050405@futureinquestion.net> Message-ID: <4DC3D6B3.2030005@klaver.it> Considering the arguments from both David and Job, I would also like to express my support. With kind regards, Michiel Klaver At 06-05-2011 12:40, Job Snijders wrote: > Dear All, > > I agree with removing the multi-homing requirement for IPv6 PI. > > Its pretty awkward to send your customers to a competitor because to deploy IPv6 PI space he or she needs to be multi-homed. Also, rising technologies such as LISP allow end-users to be multi-homed in a way that is transparent to the DFZ, so why bother restricting people to BGP multi-homing. > > Kind regards, > > Job Snijders At 06-05-2011 12:28, David Monosov wrote: > Dear address-policy-wg, > > I would like to express my support for this policy proposal. > > The promise of auto-configuration making transitioning between v6 prefixes > seamless is not yet fully delivered, and eliminating the manual renumbering > overhead when moving between service providers, as well as having a clear path > to multihoming ("just add ASN") should assure a lively Internet services market > for years to come. > > -- > Respectfully yours, > > David Monosov From euabsipa at emea.att.com Fri May 6 14:52:32 2011 From: euabsipa at emea.att.com (ABS EMEA NIC - IPA Support AT&T) Date: Fri, 6 May 2011 14:52:32 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: <20110506100004.30551.78140.Mailman@postboy.ripe.net> References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> Message-ID: <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> Hi All, I support this proposal. To have 2 ISPs is not a cheap solution. What in case if you have 2-ISPs and you are not satisfied with offered services with one of them and decide to have only 1-ISP. You cannot use IPv6 PI space. What in case if you want to change another ISP ? You have to renumber a lot of ip addresses and update firewalls and more. I think that keeping multihoming requirement for IPv6 PI space prevent to deploy of IPv6 especially for small end users (customers). Mikael Abrahamsson, Why do you think: "50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book." ? 50 Eur works today for IPv4 PI space as well. Thank you Best regards _____________________________________ Pavol Kovac -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of address-policy-wg-request at ripe.net Sent: Friday, May 06, 2011 12:00 PM To: address-policy-wg at ripe.net Subject: address-policy-wg digest, Vol 1 #1313 - 14 msgs Send address-policy-wg mailing list submissions to address-policy-wg at ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request at ripe.net You can reach the person managing the list at address-policy-wg-admin at ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. On the agenda for tomorrow: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Sander Steffann) 2. Re: 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) (Mikael Abrahamsson) 3. Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Sander Steffann) 4. RE: 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) (poty at iiat.ru) 5. Re: Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Mikael Abrahamsson) 6. Re: 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) (=?ISO-8859-1?Q?Vegar_L=F8v=E5s?=) 7. Re: Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Malcolm Hutty) 8. pointer to ietf sidr wg (Randy Bush) 9. Re: Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (boggits) --__--__-- Message: 1 From: Sander Steffann Date: Thu, 5 May 2011 16:44:41 +0200 To: "address-policy-wg at ripe.net Working Group" Subject: [address-policy-wg] On the agenda for tomorrow: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Hello WG, We will have a discussion about 2008-08 (Initial Certification Policy in = the RIPE NCC Service Region) on the agenda for tomorrow's address policy = session at RIPE 62. We also will have a short presentation there about = the issues that have been discussed on this mailing list over the last = couple of days. The session is from 9:00 to 10:30 and remote = participation is possible at http://ripe62.ripe.net/live/main. Thank you, Sander Steffann APWG co-chair --__--__-- Message: 2 Date: Thu, 5 May 2011 19:30:27 +0200 (CEST) From: Mikael Abrahamsson To: address-policy-wg at ripe.net cc: policy-announce at ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Organization: People's Front Against WWW On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. -- Mikael Abrahamsson email: swmike at swm.pp.se --__--__-- Message: 3 From: Sander Steffann Date: Fri, 6 May 2011 08:43:56 +0200 To: "address-policy-wg at ripe.net Working Group" Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Hello WG, I asked the RIPE NCC to get legal counsel on the possibilities of a = court ordering the RIPE NCC to revoke or confiscate RPKI certificates. = Here is the full answer we received: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The RIPE NCC is an association under Dutch law and therefore subject to = the Dutch legislation. RIPE NCC has consulted several external lawyers, = and has obtained an analysis of the legal situation based on current, = existing Dutch legislation. This analysis takes into account Dutch = Criminal, Civil and Administrative law. Certificates are directly linked to the registration of the Internet = number resources. There is no specific Dutch legislation that can be used to order the = deregistration of Internet number resources or change the registration = details of Internet number resources. Nor is there any legislation that = applies to the revocation of certificates over Internet number = resources. In the absence of such legislation, a court cannot order the revocation = of certificates. It is the RIPE NCC=92s view, based on this analysis, that the RIPE NCC = cannot be ordered to revoke resource certificates. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Of course laws can change, but the advice above may address some of the = concerns raised about the RPKI infrastructure. Sander Steffann APWG co-chair --__--__-- Message: 4 Subject: RE: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Date: Fri, 6 May 2011 10:59:44 +0400 From: To: , Cc: According to my messages to the WG earlier and taking into good consideration of the point of view of Mikael Abrahamsson I oppose the policy too. Vladislav Potapov IIAT, Ltd. -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Mikael Abrahamsson Sent: Thursday, May 05, 2011 9:30 PM To: address-policy-wg at ripe.net Cc: policy-announce at ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to=20 > before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements=20 for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. --=20 Mikael Abrahamsson email: swmike at swm.pp.se --__--__-- Message: 5 Date: Fri, 6 May 2011 09:01:27 +0200 (CEST) From: Mikael Abrahamsson To: Sander Steffann cc: "address-policy-wg at ripe.net Working Group" Subject: Re: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Organization: People's Front Against WWW On Fri, 6 May 2011, Sander Steffann wrote: > In the absence of such legislation, a court cannot order the revocation > of certificates. In several countries, we've seen courts ordering ISPs to block accessibility to certain sites involving not using DNS names (denmark and thepiratebay.org for instance, or the domain names transferred to US authorities just a few months ago) or block access IP-wise (Black Internet in Sweden). I am sure there was no specific law handling this, but the laws at least in these countries are flexible enough that other laws can be used to order things around. > Of course laws can change, but the advice above may address some of the > concerns raised about the RPKI infrastructure. It's good that it has been answered for dutch law, I wonder what equivalent question would have been answered in Sweden and Denmark or the US 5 years ago. -- Mikael Abrahamsson email: swmike at swm.pp.se --__--__-- Message: 6 Date: Fri, 06 May 2011 09:13:49 +0200 From: =?ISO-8859-1?Q?Vegar_L=F8v=E5s?= To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) I agree with this proposal. --=20 Best regards Vegar L=F8v=E5s Rent a Rack AS On 15.04.2011 11:22, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > --__--__-- Message: 7 Date: Fri, 06 May 2011 08:28:44 +0100 From: Malcolm Hutty To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/2011 07:43, Sander Steffann wrote: > There is no specific Dutch legislation that can be used to order the > deregistration of Internet number resources or change the > registration details of Internet number resources. Nor is there any > legislation that applies to the revocation of certificates over > Internet number resources. >=20 > In the absence of such legislation, a court cannot order the > revocation of certificates. >=20 > It is the RIPE NCC=92s view, based on this analysis, that the RIPE NCC > cannot be ordered to revoke resource certificates. There are a couple of other possible current vectors, as well as the question of future legislation. 1. Legal counsel referred to the lack of legislation that specifically mentioned revocation of certificates. Most of the existing and draft legislation I know of (not Dutch, but some EU) refers instead to "preventing access to Internet [locations/sites/content]". As a generalisation, courts will not normally order someone to do something utterly outside their power, but may order someone to take such steps as they are able to achieve an end if they are seen as being able to make a significant contribution, even if that contribution won't be wholly successful. For example, courts sometimes order newspapers and broadcasters not to publish information, even though they know the information may end up being published online. Right now it is commonly said that RIPE NCC does not have control over routing, so a court would be unlikely to order the RIPE NCC to prevent access to an Internet location. If, as a result of this policy, RIPE NCC is seen to have the capability to significantly reduce the reachability of an Internet location, a court might be willing to order it to "prevent access to the location" to the extent that it is able. No explicit mention need be made of certificate revocation. 2. Within some jurisdictions LEAs argue that Internet intermediaries are themselves criminally liable if they "facilitate" criminal activity by refusing to prevent access to an Internet location where criminal activity is ongoing, once they have been informed of the criminal activity. Intermediaries are thus induced to block access without a court order being necessary. Within the EU, network operators have special protection against this threat from the E-Commerce Directive as "mere conduits", but unfortunately registries like the RIPE NCC probably do not fit the definition of "mere conduit". In the UK, Nominet (the .uk ccTLD registry) has been induced to suspend domain registrations using this argument. RIPE NCC might in future be exposed to the same pressure. 3. Finally, new legislation not only /could/ be created, but most certainly will. The Netherlands is subject to EU law. Whether such new law would affect the RIPE NCC we cannot be certain, but I am certain that the only thing restraining lobbyists is a lack of awareness of the existence of RIPE NCC (and awareness is increasing), and a belief that the RIPE NCC has no relevant technical capability, which this policy would change. - --=20 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/ iEYEARECAAYFAk3DoywACgkQJiK3ugcyKhSlSACdGyEFtxJUai+xrWtGB/vwZjoJ VnUAoLpgRXaghPiUTTDwF3SIoQxgCEa+ =3DeFIF -----END PGP SIGNATURE----- --__--__-- Message: 8 Date: Fri, 06 May 2011 10:23:36 +0200 From: Randy Bush To: RIPE address policy WG Subject: [address-policy-wg] pointer to ietf sidr wg as requested by gert, here are pointers to the work of the sidr wg of the ietf main page of wg == documents http://datatracker.ietf.org/wg/sidr/ charter of sidr wg http://datatracker.ietf.org/wg/sidr/charter/ mailing list http://www.ietf.org/mail-archive/web/sidr/current/maillist.html if i can be of help in navigation or interpretation, feel free to write to me randy, just another bozo on the routing security bus --__--__-- Message: 9 Date: Fri, 6 May 2011 11:06:44 +0200 Subject: Re: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) From: boggits Cc: "address-policy-wg at ripe.net Working Group" On 6 May 2011 08:43, Sander Steffann wrote: > Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. > This is indeed true but misses the point that laws tend to exist either when there is an actual 'thing' to make laws about or are framed in such a way to allow the courts the latitude to include 'new things' in the same piece of legislation. Since RPKI is not currently a 'thing' but rather a 'new thing' I would be wary of relying on legal opinion that says: "There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources." What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level J -- James Blessing 07989 039 476 End of address-policy-wg Digest From swmike at swm.pp.se Fri May 6 15:24:55 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 6 May 2011 15:24:55 +0200 (CEST) Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> Message-ID: On Fri, 6 May 2011, ABS EMEA NIC - IPA Support AT&T wrote: > Why do you think: "50 EUR PI with no technical requirements for > multihoming or other is a recipe for longterm disaster in my book." ? 50 > Eur works today for IPv4 PI space as well. As far as I know there is still multihoming requirement for IPv4 PI. And if you have read my other email, I am extremely sceptical about the global routing system being able to handle the hundreds of thousands of PI blocks I believe we're going to see if this policy changes. We need other means for people to easily change addresses and multihome, shoving this into the global routing system is not the right longterm solution. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Fri May 6 17:16:04 2011 From: gert at space.net (Gert Doering) Date: Fri, 6 May 2011 17:16:04 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> Message-ID: <20110506151604.GU30227@Space.Net> Hi, On Fri, May 06, 2011 at 03:24:55PM +0200, Mikael Abrahamsson wrote: > On Fri, 6 May 2011, ABS EMEA NIC - IPA Support AT&T wrote: > > > Why do you think: "50 EUR PI with no technical requirements for > > multihoming or other is a recipe for longterm disaster in my book." ? 50 > > Eur works today for IPv4 PI space as well. > > As far as I know there is still multihoming requirement for IPv4 PI. No. Never was. http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space The IPv6 PI policy that we currently have is significantly more restrictive than the IPv4 PI policy, specifically because the working group at that time decided that we don't know whether the routing table will explode. We still don't know, but given that IPv4 PI is much less restrictive, IPv4 PI is only contributing 21% of the BGP routes in the RIPE region, and the restrictive IPv6 PI policy is holding up deployment plans, people are asking to get this changed. 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 danny at danysek.cz Fri May 6 18:18:54 2011 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 06 May 2011 18:18:54 +0200 Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) In-Reply-To: <20110415092235.748716A0A7@postboy.ripe.net> References: <20110415092235.748716A0A7@postboy.ripe.net> Message-ID: <4DC41F6E.7080404@danysek.cz> I'm supporting this proposal, as policy for IPv6 PI should be similar to existing IPv4 PI policy and similar rules should be applied for request processing. With regards, Daniel On 04/15/2011 11:22 AM, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > From randy at psg.com Fri May 6 22:49:30 2011 From: randy at psg.com (Randy Bush) Date: Fri, 06 May 2011 22:49:30 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> Message-ID: >> Why do you think: "50 EUR PI with no technical requirements for >> multihoming or other is a recipe for longterm disaster in my book." ? >> 50 Eur works today for IPv4 PI space as well. > > As far as I know there is still multihoming requirement for IPv4 PI. > > And if you have read my other email, I am extremely sceptical about > the global routing system being able to handle the hundreds of > thousands of PI blocks I believe we're going to see if this policy > changes. > > We need other means for people to easily change addresses and > multihome, shoving this into the global routing system is not the > right longterm solution. i am extremely wary of people changing addresses and multi-homing. what if, while they were changing addresses, a gang of hooligans stole the addresses just as they were changing them? or, if while they were multi-homing, a dutch court reposessed one of the homes? while this would not be a traditional home, being a new kind of home, the courts would have great latitude in its action. randy From swmike at swm.pp.se Sat May 7 05:31:53 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 7 May 2011 05:31:53 +0200 (CEST) Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: <20110506151604.GU30227@Space.Net> References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> <20110506151604.GU30227@Space.Net> Message-ID: On Fri, 6 May 2011, Gert Doering wrote: > We still don't know, but given that IPv4 PI is much less restrictive, > IPv4 PI is only contributing 21% of the BGP routes in the RIPE region, > and the restrictive IPv6 PI policy is holding up deployment plans, > people are asking to get this changed. seems to indicate that it's 59% ? Is there newer data available that shows what's happened since 2011 that could be had? -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sat May 7 08:18:12 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 7 May 2011 08:18:12 +0200 (CEST) Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> <20110506151604.GU30227@Space.Net> Message-ID: On Sat, 7 May 2011, Alex Le Heux wrote: > In the BGP routing table the de-aggregation levels are much higher for > PA allocations than for PI assignments though, 1:3.8 for PA allocations > and 1:1.1 for PI assignments. This is the 21% number that Gert quotes. Ok. So the expectation from these numbers is that since v4 PI doesn't require multihoming, removing this from the v6 PI requirement wouldn't really mean that more people getting v6 PI than are currently doing v4 PI? Is there anything else that might be different with v6 PI without multihoming compared to v4 PI that means current and historic v4 PI numbers might not be indicative of future v6 PI behaviour? -- Mikael Abrahamsson email: swmike at swm.pp.se From slz at baycix.de Sat May 7 08:45:45 2011 From: slz at baycix.de (Sascha Lenz) Date: Sat, 7 May 2011 08:45:45 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> <20110506151604.GU30227@Space.Net> Message-ID: Hay, Am 07.05.2011 um 08:18 schrieb Mikael Abrahamsson: > On Sat, 7 May 2011, Alex Le Heux wrote: > >> In the BGP routing table the de-aggregation levels are much higher for PA allocations than for PI assignments though, 1:3.8 for PA allocations and 1:1.1 for PI assignments. This is the 21% number that Gert quotes. > > Ok. > > So the expectation from these numbers is that since v4 PI doesn't require multihoming, removing this from the v6 PI requirement wouldn't really mean that more people getting v6 PI than are currently doing v4 PI? > > Is there anything else that might be different with v6 PI without multihoming compared to v4 PI that means current and historic v4 PI numbers might not be indicative of future v6 PI behaviour? maybe the fact that IPv4 PI (+ASNs) were for free until very recently and now actually cost money AND - much worse - you have to hassle with a stupid contract? (i still hate the NCC for the latter :-) but - that's another story). So i expect actually LESS IPv6 PI deployment overall anyways for the foreseeable future. ...and then i hope we get rid of the PI vs. PA distinction as per Gert's presented suggestion during RIPE62. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From alexlh at ripe.net Sat May 7 07:50:18 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Sat, 7 May 2011 07:50:18 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: <20110506100004.30551.78140.Mailman@postboy.ripe.net> <4D802C4079A49043A299A53593DCCF797A07BB016E@skcbcmsx01.emea.att.com> <20110506151604.GU30227@Space.Net> Message-ID: On May 7, 2011, at 05:31, Mikael Abrahamsson wrote: > On Fri, 6 May 2011, Gert Doering wrote: > >> We still don't know, but given that IPv4 PI is much less restrictive, IPv4 PI is only contributing 21% of the BGP routes in the RIPE region, and the restrictive IPv6 PI policy is holding up deployment plans, people are asking to get this changed. > > seems to indicate that it's 59% ? Is there newer data available that shows what's happened since 2011 that could be had? Dear Mikael, The 59% is the number of IPv4 PI assignments that the RIPE NCC made at the time. Looking at the IPv4 numbers today, we find: - Using 1996 as a start date for counting, the RIPE NCC has allocated 15k prefixes to LIRs and assigned 16k prefixes as PI - In 2011 so far, 57% of all prefixes given out were PI In the BGP routing table the de-aggregation levels are much higher for PA allocations than for PI assignments though, 1:3.8 for PA allocations and 1:1.1 for PI assignments. This is the 21% number that Gert quotes. Best regards, Alex Le Heux RIPE NCC From tore.anderson at redpill-linpro.com Sat May 7 09:05:00 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sat, 7 May 2011 09:05:00 +0200 (CEST) Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: Message-ID: <435187944.34232.1304751900385.JavaMail.root@claudius.linpro.no> * Mikael Abrahamsson > Is there anything else that might be different with v6 PI without > multihoming compared to v4 PI that means current and historic v4 PI > numbers might not be indicative of future v6 PI behaviour? Well, anyone can easily justify the need for an IPv6 /48 as that's the minimum assignment size. The minimum IPv4 assignment size, on the other hand, is smaller than a /24, which means that an applicant would require 100s of devices on his network in order to to qualify for an IPv4 PI assignment that can be actually routed on the internet. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From swmike at swm.pp.se Sat May 7 09:39:46 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 7 May 2011 09:39:46 +0200 (CEST) Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: <435187944.34232.1304751900385.JavaMail.root@claudius.linpro.no> References: <435187944.34232.1304751900385.JavaMail.root@claudius.linpro.no> Message-ID: On Sat, 7 May 2011, Tore Anderson wrote: > Well, anyone can easily justify the need for an IPv6 /48 as that's the > minimum assignment size. The minimum IPv4 assignment size, on the other > hand, is smaller than a /24, which means that an applicant would require > 100s of devices on his network in order to to qualify for an IPv4 PI > assignment that can be actually routed on the internet. Wow, I thought was already passed to take care of that. Seems I was wrong again. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Sat May 7 11:58:46 2011 From: gert at space.net (Gert Doering) Date: Sat, 7 May 2011 11:58:46 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: <435187944.34232.1304751900385.JavaMail.root@claudius.linpro.no> Message-ID: <20110507095846.GY30227@Space.Net> Hi, On Sat, May 07, 2011 at 09:39:46AM +0200, Mikael Abrahamsson wrote: > Wow, I thought was > already passed to take care of that. Seems I was wrong again. Got stuck in the apparatus. Sorry for that, we're working on it again. It doesn't really keep people from getting a /24 if they really want it, and do not shy away from making up numbers - which is basically what the proposal about: discourage lying to the NCC to work around policy restrictions. Gert Doering -- NetMaster -- 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 gih at apnic.net Sat May 7 11:38:25 2011 From: gih at apnic.net (Geoff Huston) Date: Sat, 7 May 2011 19:38:25 +1000 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DC15398.8070304@linx.net> References: <4DBFE7A7.7050608@linx.net> <1304514280.1932.330.camel@ntitley-laptop> <4DC15398.8070304@linx.net> Message-ID: <7D864DE9-2067-4D13-8763-9A81E91CE8A1@apnic.net> On 04/05/2011, at 11:24 PM, Malcolm Hutty wrote: > > > If you've investigated other approaches to inhibiting route hijacking > and discarded them, please share. http://www.potaroo.net/papers/BGP_Security_Literature_Review.pdf Geoff From rhe at nosc.ja.net Sun May 8 13:28:57 2011 From: rhe at nosc.ja.net (Rob Evans) Date: Sun, 8 May 2011 12:28:57 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: Message-ID: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> A few idle thoughts on this without being fuelled by Krasnapolsky coffee and chocolates... 2008-08 is about creating a mechanism to use public key cryptography to verify the contents of the RIPE database. Both the allocation records (inet(6)nums) via certificates and the RPSL records (route objects) via ROAs. It does not yet cover aut-nums or any other objects. One of the strengths of the RIPE database has been that of all the RIRs it was the only one to tie those together in the same database. Ironically, this tie now appears to be the stumbling block for moving the resource certification process forward in our region. The thought that in a system where allocation and routing records are tied together by certificates and signed objects the enforced withdrawal of one could lead to isolation from "the Internet." However, 2008-08 does not cover routing, it simply concerns itself with providing a way of cryptographically verifying (I have no idea if that is a real term) the contents of the RIPE database's allocation records. Mechanisms for coupling the allocation records more tightly to routing do indeed need ways for operators to influence the policy they apply -- "my network, my rules." That is currently there with the suggested way to implement this via routing policy, but nobody thinks this solution won't be improved in the future. If there is a requirement to show revoked certificates, that will be part of it. If "law enforcement" mandates the NCC to withdraw an allocation, could it also not mandate that the NCC originates a competing route with a valid ROA that will "trump" the now-invalid ROA? Is this necessarily a problem? By the time it gets to that stage won't the legal system have performed sufficient due process that it believes this is the right way to go? The law is, after all, the law. I fear that is a much more involved discussion though. I value Malcolm's opinion greatly, and when he is this concerned about a proposal it scares me, it scares me a lot, but I think calling a halt to 2008-08 is cutting off our nose to spite our face. 2008-08 is about as simple as it can get, "the certificates will reflect the registration status of the resource." There are many people that are far more expert in creating complicated policy than we are, we should do what we do best, simple policy and flexibility in the technical mechanisms of how this is implemented that leaves control in the hands of the operators (for some definition of "best"). This, though, is in the mechanisms of how we tie this to the routing system. I support a way of being able to verify the holder of address space and 2008-08 is the first step forward in that for some limited set of resources, and I support its progress. It does not require universal deployment to be useful for those that choose to use it, whether for verifying the "owner" of address space, or giving the routing systems hints over preference. All the best, Rob From a.baghir at mobily.com.sa Sat May 7 21:06:08 2011 From: a.baghir at mobily.com.sa (Adil H. Baghir) Date: Sat, 7 May 2011 22:06:08 +0300 Subject: [address-policy-wg] PP - 2011-02 - Removal of multihomed requirement for IPv6 Message-ID: <5C0C794DC4117644AE7580F2C58A88BF097E874C08@RUH-003-MX-002.prod.mobily.lan> Hi, I highly support the policy... Adil H. Baghir Chief Engineer, Internet Development Data & Solutions Planning and Design P.O.Box 69179 Riyadh 11423 Kingdom of Saudi Arabia Tel: +966 56 031 3263 Fax: +966 56 041 3263 Mobile: +966 542 33 66 00 eMail: a.baghir at mobily.com.sa [cid:image002.jpg at 01CC0D02.F7D02210] ------Disclaimer------ This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 2445 bytes Desc: image002.jpg URL: From jim at rfc1035.com Mon May 9 12:05:31 2011 From: jim at rfc1035.com (Jim Reid) Date: Mon, 9 May 2011 11:05:31 +0100 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> Message-ID: <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> On 8 May 2011, at 12:28, Rob Evans wrote: > If "law enforcement" mandates the NCC to withdraw an allocation, > could it also not mandate that the NCC originates a competing route > with a valid ROA that will "trump" the now-invalid ROA? Is this > necessarily a problem? By the time it gets to that stage won't the > legal system have performed sufficient due process that it believes > this is the right way to go? Rob, I think this is an interesting but probably irrelevant question. The NCC would almost definitely be in contempt of court -- ie jail time for Axel and the Board -- if it issued some kind of alternate certificate after being given a court order to revoke one. However since Sander said the lawyer says there's no way the Dutch courts could issue such a court order, this seems to be unrealistic unless there's new legislation. Though I wonder about the EU dimension here. Perhaps a court order in one EU state can be enforced in another along the lines of the European Arrest Warrant? I'm thinking here about forum shopping, eg something comparable to starting libel actions in the very accommodating English courts because of the stupid laws they have. > I value Malcolm's opinion greatly, and when he is this concerned > about a proposal it scares me, it scares me a lot Same here. Since none of us here are lawyers (thankfully), I think the next stage will be to get relevant legal advice and have it published on the list. Perhaps the WG could help to compose the questions or scenarios for the lawyer to consider. In light of Malcolm's comments, we should go carefully here. The PDP allows for an impact assessment. The current state of this proposal is why it's there. I would hope too that the NCC Board formally approves implementation of this policy if/ when we reach that point. I am not worried about the RPKI being used as a vector for takedown requests by law enforcement or others. I am worried about more informal situations. What does the NCC do when the cops knock on the door and say "We don't have a court order and *really* want you to revoke this cert. Please co-operate."? And although I mentioned law enforcement, there may well be others who would wish to push those boundaries. From randy at psg.com Mon May 9 12:15:56 2011 From: randy at psg.com (Randy Bush) Date: Mon, 09 May 2011 12:15:56 +0200 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> Message-ID: > Since none of us here are lawyers (thankfully) that is not clearly the case > I think the next stage will be to get relevant legal advice and have > it published on the list. i thought sander and gert did that and we now seem to be in the stage of second-guessing it. randy From jim at rfc1035.com Mon May 9 12:39:46 2011 From: jim at rfc1035.com (Jim Reid) Date: Mon, 9 May 2011 11:39:46 +0100 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> Message-ID: <6CF5082D-5F19-4111-B424-08730473A142@rfc1035.com> On 9 May 2011, at 11:15, Randy Bush wrote: >> I think the next stage will be to get relevant legal advice and have >> it published on the list. > > i thought sander and gert did that and we now seem to be in the > stage of > second-guessing it. Please point me/us at the email containing the brief given to the lawyer and the one containing their reply. Sander and Gert will of course have done a competent and responsible job here, as will the lawyer. But that has to be seen to have been done. From malcolm at linx.net Mon May 9 12:49:22 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Mon, 09 May 2011 11:49:22 +0100 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> Message-ID: <4DC7C6B2.7060701@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/05/2011 11:15, Randy Bush wrote: >> I think the next stage will be to get relevant legal advice and have >> it published on the list. > > i thought sander and gert did that and we now seem to be in the stage of > second-guessing it. Nothing I said disagreed with the legal advice given. I did disagree with the inferences the RIPE NCC apparently drew from it (which Sander appended to the legal advice). That's quite different. Any good lawyer will do as the NCC's one did and limit their advice to what is current and known, and the question asked. He can't be blamed if his advice is represented as meaning something more than he said. 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/ iEYEARECAAYFAk3HxrIACgkQJiK3ugcyKhTrNACfUJXoOt8iY9p4DozX108bgLpQ kSEAoJoMzuBFNiJu0DWfWPxNJPlM8xjR =nMn1 -----END PGP SIGNATURE----- From ebais at a2b-internet.com Mon May 9 12:52:15 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 9 May 2011 12:52:15 +0200 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> Message-ID: <001501cc0e37$28a6c530$79f44f90$@com> Hi Jim, > On 8 May 2011, at 12:28, Rob Evans wrote: > > > If "law enforcement" mandates the NCC to withdraw an allocation, > > could it also not mandate that the NCC originates a competing route > > with a valid ROA that will "trump" the now-invalid ROA? Is this > > necessarily a problem? By the time it gets to that stage won't the > > legal system have performed sufficient due process that it believes > > this is the right way to go? > > Rob, I think this is an interesting but probably irrelevant question. > The NCC would almost definitely be in contempt of court -- ie jail > time for Axel and the Board -- if it issued some kind of alternate > certificate after being given a court order to revoke one. That isn't the case under Dutch law. The certificate isn't a seizable asset ... or something law-enforcement could force to revoke. Ask anyone who was involved in the actual process from within RIPE NCC, that they have done the legal checks and the feedback from the lawyers in a really THICK document was that what you are second guessing here isn't an issue. It simply can't be revoked by 'law enforcement' ... > > I value Malcolm's opinion greatly, and when he is this concerned > > about a proposal it scares me, it scares me a lot > > Same here. I have great respect for others their opinion, having said that I make my own decisions on what would actually scare me. In this case, all the 'scary' questions have already been answered in the past, the legal part was already looked at. > Since none of us here are lawyers (thankfully), I think the next stage > will be to get relevant legal advice and have it published on the > list. Perhaps you should have a look in the archive. This has already been done the first time those questions came up. And all questions have been answered. > Perhaps the WG could help to compose the questions or scenarios > for the lawyer to consider. In light of Malcolm's comments, we should > go carefully here. The PDP allows for an impact assessment. Again, I'm repeating myself here .. That was already done. > I am not worried about the RPKI being used as a vector for takedown > requests by law enforcement or others. I am worried about more > informal situations. What does the NCC do when the cops knock on the > door and say "We don't have a court order and *really* want you to > revoke this cert. Please co-operate."? And although I mentioned law > enforcement, there may well be others who would wish to push those > boundaries. That is a good one :) That one really made me smile. As a Dutch LIR we get questions like this, but come on, get real. Kind requests like these get waived at the reception, even before someone would look at it. I'm sure someone from RIPE NCC could provide a summary of their policy in requests like that. Erik Bais From andreas at schachtner.eu Mon May 9 12:50:16 2011 From: andreas at schachtner.eu (Andreas Schachtner) Date: Mon, 9 May 2011 12:50:16 +0200 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> Message-ID: <20110509125016.5cff259e@foohome.schachtner.eu> Hi, Am Mon, 9 May 2011 11:05:31 +0100 schrieb Jim Reid : ... > However since Sander said the lawyer says there's no way the Dutch > courts could issue such a court order, this seems to be unrealistic > unless there's new legislation. Though I wonder about the EU Go and ask the lawyers if a court can order "effective measures" to stop a certain route being announced. This can be a filtering at AMS-IX and other exchanges, blocking it at a peer level or revoking a certificate. I a worst case szenarion, interpretation is up the the LEA and the NCC the most likely target. Regards, Andreas -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund From sander at steffann.nl Mon May 9 13:32:53 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 May 2011 13:32:53 +0200 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <4DC7C6B2.7060701@linx.net> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> <4DC7C6B2.7060701@linx.net> Message-ID: <11EB3318-38A4-4220-AEB3-184909F78F8E@steffann.nl> Hi Malcolm, > Nothing I said disagreed with the legal advice given. I did disagree > with the inferences the RIPE NCC apparently drew from it (which Sander > appended to the legal advice). That's quite different. I didn't add anything to the legal advise. The text that I sent comes as-is from the legal department: ========== The RIPE NCC is an association under Dutch law and therefore subject to the Dutch legislation. RIPE NCC has consulted several external lawyers, and has obtained an analysis of the legal situation based on current, existing Dutch legislation. This analysis takes into account Dutch Criminal, Civil and Administrative law. Certificates are directly linked to the registration of the Internet number resources. There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources. In the absence of such legislation, a court cannot order the revocation of certificates. It is the RIPE NCC?s view, based on this analysis, that the RIPE NCC cannot be ordered to revoke resource certificates. ========== Thanks, Sander From ebais at a2b-internet.com Mon May 9 13:33:45 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 9 May 2011 13:33:45 +0200 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <20110509125016.5cff259e@foohome.schachtner.eu> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> <20110509125016.5cff259e@foohome.schachtner.eu> Message-ID: <002501cc0e3c$f4ccf080$de66d180$@com> Hi Andreas, > > However since Sander said the lawyer says there's no way the Dutch > > courts could issue such a court order, this seems to be unrealistic > > unless there's new legislation. Though I wonder about the EU > > Go and ask the lawyers if a court can order "effective measures" to > stop a certain route being announced. This can be a filtering at AMS-IX > and other exchanges, blocking it at a peer level or revoking a > certificate. I a worst case szenarion, interpretation is up the the LEA > and the NCC the most likely target. I strongly disagree with you here. If one would like to stop a route to be announced, the best way is at the originating router. The AMS-IX or any other IX don't have ANYTHING to say in what an ISP is announcing. They don't want too and since they are not in the AS path of the routes, they simply can't. Trying to depeering a party is 'probably' the second best option, especially if the originating router / infrastructure is owned by the same (offending ?) party. However the experiences with that in the past with parties like McColo and alikes, that isn't something that will happen overnight. Erik From gert at space.net Mon May 9 15:02:40 2011 From: gert at space.net (Gert Doering) Date: Mon, 9 May 2011 15:02:40 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> Message-ID: <20110509130240.GI30227@Space.Net> Hi, On Thu, May 05, 2011 at 05:11:33AM -0400, Martin Millnert wrote: > > "Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." ?(Emphasis mine) > > I am hoping you can give some practical examples on how one goes about > considering routes invalid with utmost care. You could, for example, adjust routing preference in accordance to the availability of an RPKI signature - prefer routes with a valid RPKI ROA - if no routes with a valid ROA can be found, consider routes with no ROA (neither matching nor invalid) - if no such routes can be found, accept any route, even if the ROA lists a wrong origin AS Randy has demonstrated in the workshop on last Monday morning how to do that in IOS. The implementation is such that the BGP engine doesn't *care* about the validity of a route/ROA, it will just mark the prefix with the result of the validation check - and then you can use the normal local policy language to influence your policy with that result. One *choice* could be "drop all routes that have a ROA mismatch" - or, as outlined above "accept everything, but only use those routes as last-resort". Local policy decision. The workshop was very enlightening, to actually see how the pieces fit together and how local policy is applied to the data coming from the (various) RPKI data stores. 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 boggits at gmail.com Mon May 9 15:24:15 2011 From: boggits at gmail.com (boggits) Date: Mon, 9 May 2011 14:24:15 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110509130240.GI30227@Space.Net> References: <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <20110509130240.GI30227@Space.Net> Message-ID: On 9 May 2011 14:02, Gert Doering wrote: > Hi, > > On Thu, May 05, 2011 at 05:11:33AM -0400, Martin Millnert wrote: >> > "Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." ?(Emphasis mine) >> >> I am hoping you can give some practical examples on how one goes about >> considering routes invalid with utmost care. > > You could, for example, adjust routing preference in accordance to > the availability of an RPKI signature Yes, this is a good use for RPKI from a technical PoV it means that those routes that are signed are given a better chance of attracting the traffic... ... but some would say that splitting your networking to /24 for traffic management purposes is good from a technical PoV. I like the idea of the contents of the DB being signed so people can check the accuracy (and validity) of the contents - what I don't like is the move to an automated on router solution that checks for validity on the fly (and that seems to be where people want this to go) because that leads to a system where someone controlling the source of the data can then influence my routing decisions. Maybe its the fact that RIPE are providing the full solution as well as the ability to publish the information thats the issue, if rather than the NCC creating a tool for validation it just published the keys and the software tools for people to do the validation themselves then I might be happier. J -- James Blessing 07989 039 476 From Woeber at CC.UniVie.ac.at Mon May 9 15:27:35 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 09 May 2011 13:27:35 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: Message-ID: <4DC7EBC7.3070604@CC.UniVie.ac.at> At least for me, part of my worries is this "awareness thing" and the use of terms - both within the framework of the discussion and in the tools, UIs, plus documentation: ROA: Route Origin Authorization. What is the message, that this sends out to the various lobbying and other "pressure groups"? In particular, when the RIPE NCC is offering the creation of ROAs as a hosted service by way of the LIR Portal.... Folks (like me) who have seen things and threats happening in the past, in real life, without *any* regard to "legislation" being there or not, or being seen as applicable, tend to be just a tad more paranoid than some others ;-) Wilfried boggits wrote: > On 6 May 2011 08:43, Sander Steffann wrote: > >>Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. >> > > > This is indeed true but misses the point that laws tend to exist > either when there is an actual 'thing' to make laws about or are > framed in such a way to allow the courts the latitude to include 'new > things' in the same piece of legislation. Since RPKI is not currently > a 'thing' but rather a 'new thing' I would be wary of relying on legal > opinion that says: > > "There is no specific Dutch legislation that can be used to order the > deregistration of Internet number resources or change the registration > details of Internet number resources. Nor is there any legislation > that applies to the revocation of certificates over Internet number > resources." > > What you are looking for is legislation (as pointed out by Malcom) > that can be used to restrict/control access to the internet which > appears to exist at least at a European level > > J From Woeber at CC.UniVie.ac.at Mon May 9 15:32:09 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 09 May 2011 13:32:09 +0000 Subject: [address-policy-wg] 2008-08 Most recent version of the CPS? Message-ID: <4DC7ECD9.2060307@CC.UniVie.ac.at> Folks, is the document RIPE NCC RPKI (without a ripe document ID :-/ ), labelled "Last updated December 2010" the most recent addition? If it is, I do have quite some issues with this text, in particular in its formal relationship to the 2008-08 draft policy text. If there's a more recent version I'd be grateful to be given a pointer or a reference. Tnx, Wilfried. From sander at steffann.nl Mon May 9 16:02:44 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 May 2011 16:02:44 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <20110509130240.GI30227@Space.Net> Message-ID: <50CCB602-30EE-4B0C-8D5F-C072C648334A@steffann.nl> Hi James, > Maybe its the fact that RIPE are providing the full solution as well > as the ability to publish the information thats the issue, if rather > than the NCC creating a tool for validation it just published the keys > and the software tools for people to do the validation themselves then > I might be happier. Euhm. The NCC *are* publishing the tools to do the validation on your own system. The certificates are currently created and managed in a hosted environment on an NCC server. Once the Up/Down implementation is finished you can also host this part on your own server if you don't want all the private keys to be on an NCC server. Then you install your own validation/cache software on your own server that checks the certificates, and your routers pull their information from that cache. Then the route maps on the router determine what is done with that information. I think that Malcolm is afraid that governments will force ISPs to do this validation and route-mapping in a certain way that takes away freedom-of-choice about what to route and what not to route. Malcolm: please correct me if I am wrong. Sander From gert at space.net Mon May 9 16:32:34 2011 From: gert at space.net (Gert Doering) Date: Mon, 9 May 2011 16:32:34 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: References: <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <20110509130240.GI30227@Space.Net> Message-ID: <20110509143233.GK30227@Space.Net> Hi, On Mon, May 09, 2011 at 02:24:15PM +0100, boggits wrote: > Maybe its the fact that RIPE are providing the full solution as well > as the ability to publish the information thats the issue, if rather > than the NCC creating a tool for validation it just published the keys > and the software tools for people to do the validation themselves then > I might be happier. Uh. As far as I understand, the validation is always done by your local setup, and various software options(!) exist for that. The NCC provides a trusted data store where it signs which IP resources belong to what certificate (not "entity"). Based on that, the network holder can sign a ROA "I authorize this AS to announce my network" (and of course that would not be overly useful without some who has that authority to actually attest that "my" bit there). That ROA would currently be stored in the RIPE database, but it could be stored anywhere, with a pointer in your certificate "look *there* for my ROAs". Then whoever is interested runs a software that collects the various bits and pieces from whever they are stored - guided by referrals, or (again!) by local policy - "this guys I trust, their networks I always grab from *that* store, authenticated by *this* trust anchor". One such solution is Randy's RCynic, another one would be what BBN (Steve Kent) has developed, and a third one would be the RIPE NCC validator. Google sends me to these links for a list of RPKI validation tools and their interop tests: http://www.ietf.org/proceedings/80/slides/sidr-12.pdf http://www.ietf.org/proceedings/80/slides/sidr-10.pdf This stuff then generates a list of pairs from the data, and sends it to your routers - no crypto involved on the routers, no 10000-lines-prefixlists for peer validation, very lightweight operation - where it is then used for policy decisions. Gert Doering -- Address Policy WG -- 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 millnert at gmail.com Mon May 9 19:23:45 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 9 May 2011 13:23:45 -0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110509130240.GI30227@Space.Net> References: <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <20110509130240.GI30227@Space.Net> Message-ID: Gert, thank you for answering this question. On Mon, May 9, 2011 at 9:02 AM, Gert Doering wrote: > Hi, > > On Thu, May 05, 2011 at 05:11:33AM -0400, Martin Millnert wrote: >> > "Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." ?(Emphasis mine) >> >> I am hoping you can give some practical examples on how one goes about >> considering routes invalid with utmost care. > > You could, for example, adjust routing preference in accordance to > the availability of an RPKI signature > > ?- prefer routes with a valid RPKI ROA > > ?- if no routes with a valid ROA can be found, consider routes with no ROA > ? (neither matching nor invalid) > > ?- if no such routes can be found, accept any route, even if the ROA lists > ? a wrong origin AS So if some random LEA convinces the RIPE NCC (via means of legislation already under way according to Malcolm (transfer resources to LEA), or some $lawyer-soup not foreseen today), the abuser could, with the intent of a DDoS of the overtaken resources, start announcing routes of a valid RPKI ROA, and this way steal traffic from anyone implementing at a minimum the above policy. The DDoS is successful and RPKI just censored a network off the Internet from those who implement at a minimum the above policy, which is the minimum you have to, else RPKI is pointless. In other words: influencing route preference from a single point of authority remains an abuse-vector. The only way to completely negate this abuse vector from the relying party's side is to not implement any policy based on any RPKI information. This is obvious since the reverse side of the coin, securing routing, requires automatic policy handling (else why develop RPKI?). Assuming large carriers are compliant to LEAs under nearly all circumstances, this remains a threatening scenario. It clearly suggests that great, great care must go into the choice of sources for the RPKI information. And having just one origin source of data, RIPE's database, should there not be some process of peer-review* before any revocation or re-assignment can go into effect? Not just of resource certifications, but resources over all? Should there not be a public, easily accessible log providing transparency and insight into the motivations of why these changes are done? (*By peer-review I mean per-event-peer review, performed by normal citizens, via more or less direct influence.) In response to a call on the APWG session last Friday to the critics of RPKI to "help out, propose solutions": My preferred way of securing routing relies on heavy decentralization, which by necessity must include that of the RIR's registry function since this is an apparent single point of failure. The most obvious way to me right now to go about this is to transform todays resource allocations to resource ownerships, which can pave the way for a truly decentralized registry function. I'm not convinced that a single point of failure is the most natural way to organize internet uniqueness as we go forward, and I'm not alone in identifying RIR's motivation for RPKI as a way for them to establish ownership of the Internet and secure their future business, and recognize that community opinion on whether this is good or bad differs. I think it is helpful to discuss this in more depth. The future is anything but certain in this area: in particular, it is going to be interesting to see what happens with regards to egistry accuracy and relevance once legacy resources starts to be traded without any RIR involvement. With this I'm passing the ball: I'd appreciate to see more cycles spent on considering plausible recovery-protocols once the first abuse is a fact, in the one-trust-anchor model. There goal ought to be an abuse-resistant system, and in this it must be assumed the RIPE NCC, or any other single trust anchor, will not be able to withstand the abuse previously discussed. A measure of an abuse-resistant system is, obviously, one where an abuse, a DDoS, fails. The bar must be set a bit higher. Going down this route still discomforts me greatly since an absolutely foreseeable problem/flaw is knowingly being designed into the system from scratch. A backup registry (of the RIPE NCC in case it goes bad) was mentioned in the APWG session last Friday. Why stop with 1? Why not 1000s of them, or, say, 1 per ASN? To me it is now clear (since a recent epiphany :) ) that the underlying internet infrastructure wants a distributed registry and I don't think this desire is about to go away as IPv4 starts to be traded, quite the contrary. > Randy has demonstrated in the workshop on last Monday morning how to do > that in IOS. ?The implementation is such that the BGP engine doesn't *care* > about the validity of a route/ROA, it will just mark the prefix with the > result of the validation check - and then you can use the normal local > policy language to influence your policy with that result. > > One *choice* could be "drop all routes that have a ROA mismatch" - or, > as outlined above "accept everything, but only use those routes as > last-resort". ?Local policy decision. See above. > The workshop was very enlightening, to actually see how the pieces fit > together and how local policy is applied to the data coming from the > (various) RPKI data stores. Can the software handle multiple (not 2, not 3, but n) competing trust anchors, possibly assign weights to them and compare matching resources and produce a resulting set of non-conflicting resources, another set with conflicting resources / odd-cases? Seems called for to answer the above discussion, to me, at least. Kind Regards, Martin From lists-ripe at c4inet.net Mon May 9 21:28:09 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 9 May 2011 19:28:09 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: Message-ID: <20110509192809.GA87495@cilantro.c4inet.net> On Fri, May 06, 2011 at 11:06:44AM +0200, boggits wrote: >"There is no specific Dutch legislation that can be used to order the >deregistration of Internet number resources or change the registration >details of Internet number resources. Nor is there any legislation >that applies to the revocation of certificates over Internet number >resources." > >What you are looking for is legislation (as pointed out by Malcom) >that can be used to restrict/control access to the internet which >appears to exist at least at a European level There is an unfortunate tendency in lawmaking these days towards formulating legislation is such a broad way that it includes "use cases" they may have forgotten about or not thought of when writing it. Not the word "specific" in the above, this does not mean that applicable legislation does not exist! rgds, Sascha Luck From sander at steffann.nl Mon May 9 21:34:21 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 May 2011 21:34:21 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110509192809.GA87495@cilantro.c4inet.net> References: <20110509192809.GA87495@cilantro.c4inet.net> Message-ID: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> Sascha, >> "There is no specific Dutch legislation that can be used to order the >> deregistration of Internet number resources or change the registration >> details of Internet number resources. Nor is there any legislation >> that applies to the revocation of certificates over Internet number >> resources." >> >> What you are looking for is legislation (as pointed out by Malcom) >> that can be used to restrict/control access to the internet which >> appears to exist at least at a European level > > There is an unfortunate tendency in lawmaking these days towards formulating legislation is such a broad way that it includes "use > cases" they may have forgotten about or not thought of when writing > it. > Not the word "specific" in the above, this does not mean that applicable > legislation does not exist! You miss the next sentence of the legal advise: "In the absence of such legislation, a court cannot order the revocation of certificates." I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. Sander From lists-ripe at c4inet.net Mon May 9 21:48:04 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 9 May 2011 19:48:04 +0000 Subject: [address-policy-wg] layer 10+ issues with 2008-08 In-Reply-To: <001501cc0e37$28a6c530$79f44f90$@com> References: <8C160C76-4257-4083-885B-4E43A546EB04@nosc.ja.net> <3AA4B6CB-6A3E-4070-A135-B9B80002A662@rfc1035.com> <001501cc0e37$28a6c530$79f44f90$@com> Message-ID: <20110509194804.GB87495@cilantro.c4inet.net> On Mon, May 09, 2011 at 12:52:15PM +0200, Erik Bais wrote: >> I am not worried about the RPKI being used as a vector for >> takedown requests by law enforcement or others. I am >> worried about more informal situations. What does the NCC >> do when the cops knock on the door and say "We don't have >> a court order and *really* want you to revoke this cert. >> Please co-operate."? And although I mentioned law >> enforcement, there may well be others who would wish to >> push those boundaries. > Kind requests like these get waived at the reception, even > before someone would look at it. I guarantee you they won't if someone shows up with a "National Security Letter" or whatever the EU equivalent may be that orders you to comply *and keep your mouth shut about it*. http://en.wikipedia.org/wiki/Nicholas_Merrill You may also want to watch his presentation at 27C3... > I'm sure someone from RIPE NCC could provide a summary of their > policy in requests like that. If they can, see above. Folks, this proposal fundamentally changes the very nature of the internet as a loose association of independent networks without any central or hierarchical authority other than that of the network owners over *their* network. I think it is only right to perform a detailed and very careful technical *and political* risk assessment of all and any "unintended" consequences of such a change. rgds, Sascha Luck From millnert at gmail.com Mon May 9 21:52:56 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 9 May 2011 15:52:56 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> Message-ID: On Mon, May 9, 2011 at 3:34 PM, Sander Steffann wrote: > Sascha, > >>> "There is no specific Dutch legislation that can be used to order the >>> deregistration of Internet number resources or change the registration >>> details of Internet number resources. Nor is there any legislation >>> that applies to the revocation of certificates over Internet number >>> resources." >>> >>> What you are looking for is legislation (as pointed out by Malcom) >>> that can be used to restrict/control access to the internet which >>> appears to exist at least at a European level >> >> There is an unfortunate tendency in lawmaking these days towards formulating legislation is such a broad way that it includes "use >> cases" they may have forgotten about or not thought of when writing >> it. >> Not the word "specific" in the above, this does not mean that applicable >> legislation does not exist! > > You miss the next sentence of the legal advise: > "In the absence of such legislation, a court cannot order the revocation of certificates." > > I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. > Sander Now if the statement could only guarantee for the future that it no court could do anything of the sort, it'd actually be useful. Since it doesn't, I think the sensible thing to do is to account for the fact that laws can change (and that lawyers are... highly creative, and can launch attacks that force you to prove them wrong just to get back to status quo) when choosing what model to use for securing the internet. I remember Gordon Brown of the UK used then-recent British anti-terror laws to cease Icelandic money, btw. I wonder how many legal counsels could foresee that. :) Kind Regards, Martin From randy at psg.com Mon May 9 21:55:57 2011 From: randy at psg.com (Randy Bush) Date: Mon, 09 May 2011 21:55:57 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <20110509130240.GI30227@Space.Net> References: <1304522034.1932.337.camel@ntitley-laptop> <006801cc0a72$f0b7ab20$d2270160$@com> <20110504155713.GD27143@cilantro.c4inet.net> <4DC17DAC.7040600@heanet.ie> <20110509130240.GI30227@Space.Net> Message-ID: > You could, for example, adjust routing preference in accordance to > the availability of an RPKI signature > > - prefer routes with a valid RPKI ROA > > - if no routes with a valid ROA can be found, consider routes with no ROA > (neither matching nor invalid) > > - if no such routes can be found, accept any route, even if the ROA lists > a wrong origin AS from draft-ietf-sidr-origin-ops-07 Announcements with Valid origins SHOULD be preferred over those with NotFound or Invalid origins, if the latter are accepted at all. Announcements with NotFound origins SHOULD be preferred over those with Invalid origins. Announcements with Invalid origins MAY be used, but SHOULD be less preferred than those with Valid or NotFound. randy From lists-ripe at c4inet.net Mon May 9 21:55:59 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 9 May 2011 19:55:59 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> Message-ID: <20110509195559.GC87495@cilantro.c4inet.net> On Mon, May 09, 2011 at 09:34:21PM +0200, Sander Steffann wrote: >You miss the next sentence of the legal advise: >"In the absence of such legislation, a court cannot order > the revocation of certificates." > >I think the legal statement (when read as a whole, not cherry- >picking the parts you like) was clear enough. Hmmm, do you have much experience with lawyer-speak? This means that a court cannot order the revocation of a ROA cert *specifically* as there is no legislation covering that. What it *can* do, is order the NCC to do everything possible to stop this prefix from being announced. o I know nothing about Dutch law but I would be highly surprised if that wasn't possible in .nl. rgds, Sascha From sander at steffann.nl Mon May 9 22:01:14 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 May 2011 22:01:14 +0200 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> Message-ID: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> Hi Martin, >> You miss the next sentence of the legal advise: >> "In the absence of such legislation, a court cannot order the revocation of certificates." >> >> I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. >> Sander > > Now if the statement could only guarantee for the future that it no > court could do anything of the sort, it'd actually be useful. Since > it doesn't, I think the sensible thing to do is to account for the > fact that laws can change I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) - Sander From lists-ripe at c4inet.net Mon May 9 22:06:47 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 9 May 2011 20:06:47 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> Message-ID: <20110509200647.GD87495@cilantro.c4inet.net> On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote: >I fully agree. Mind you, they could just as well just make a law that says >"You may not route any packets to/from addresses that appear on list X" and we >would have exactly the situation everyone seems to be afraid of, and it doesn't >need RPKI. As soon as laws don't allow 'your network, your rules' anymore then >anything can happen... But that is something that we'll have to steer through >voting, not address policy :) > >- Sander > Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. rgds, Sascha Luck From sander at steffann.nl Mon May 9 22:20:14 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 May 2011 22:20:14 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110509200647.GD87495@cilantro.c4inet.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> Message-ID: <1E41BAD7-1995-4649-B335-0D7BB26637A9@steffann.nl> Hi, > Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. Not really. You would also need laws in each country that force network operators to use RPKI evaluation without applying any whitelisting or exceptions. If such laws can exist, laws that do the same according to a government-defined blacklist can also exist. - Sander From alexb at ripe.net Mon May 9 22:21:21 2011 From: alexb at ripe.net (Alex Band) Date: Mon, 9 May 2011 22:21:21 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110509200647.GD87495@cilantro.c4inet.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> Message-ID: <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> On 9 May 2011, at 22:06, Sascha Luck wrote: > On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote: >> I fully agree. Mind you, they could just as well just make a law that says >> "You may not route any packets to/from addresses that appear on list X" and we >> would have exactly the situation everyone seems to be afraid of, and it doesn't >> need RPKI. As soon as laws don't allow 'your network, your rules' anymore then >> anything can happen... But that is something that we'll have to steer through >> voting, not address policy :) > >- Sander > > > Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever. In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her. Accepting an invalid prefix because of a revoked certificate is always an option, unless the law is changed in *every* country where this system is used. Reread Randy's post from just now where draft-ietf-sidr-origin-ops-07 is quoted. -Alex From millnert at gmail.com Mon May 9 22:33:58 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 9 May 2011 16:33:58 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> Message-ID: Sander, thank you for your reply. On Mon, May 9, 2011 at 4:01 PM, Sander Steffann wrote: > Hi Martin, > >>> You miss the next sentence of the legal advise: >>> "In the absence of such legislation, a court cannot order the revocation of certificates." >>> >>> I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. >>> Sander >> >> Now if the statement could only guarantee for the future that it no >> court could do anything of the sort, it'd actually be useful. ?Since >> it doesn't, I think the sensible thing to do is to account for the >> fact that laws can change > > I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) Now we're getting to a useful point in the discussion I think. :) See, I've come to learn so far in life that whenever something "becomes possible", lawyers, eavesdroppers and other state machinery wants to do it, and it's a very rough machine. How well does that "You may not route any packets to/from addresses that appear on list X" thing scale today? Is it technologically feasible? Does it stretch outside of judicial boundaries? And, the slippery slope has already been started upon, some nations have decayed further than others: See various block lists, DNS and other. "Your network, your rules", you said? I agree with what you said earlier about how LEA's ought to go for the source if they want to shut something done, and that is not a power I think it is reasonable to campaign for having taken from them. I did read http://www.intgovforum.org/cms/component/content/article/102-transcripts2010/632-158 , where Andrew isn't all too happy about RPKI by the looks of it. One thing he says, is: "So my question is, are we sure that RPKI would not produce the same problems? I'm very happy to be convinced to the contrary, but please do not -- more technology, because very frankly I cannot go back and tell that to the powers that be and (off microphone) the next three years hoping that nothing will happen, because something that will happen, then I will have to pay the price. I will go back to you and tell you, why didn't you tell me the truth? What were the risks? And we can discuss and try to find a solution." in reference to a technology that gave more power to one government than others. You can sort of conclude from this that the EU will want EU to have equal access to this new technology, and I can only infer/guess to their actual motives. Furthermore I do see relevance between the citation above and the discussion we're having, but it's possible me and Andrew are coming from two 180 degree separated vectors on this question. :) Sander, I remain fully unconvinced that lowering the effort for censoring the internet will make no or negative effect on the amount of censorship done. If you really think different, perhaps we should make a bet. :) Kind Regards, Martin From millnert at gmail.com Mon May 9 22:39:19 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 9 May 2011 16:39:19 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: On Mon, May 9, 2011 at 4:21 PM, Alex Band wrote: > > On 9 May 2011, at 22:06, Sascha Luck wrote: > >> On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote: >>> I fully agree. Mind you, they could just as well just make a law that says >>> "You may not route any packets to/from addresses that appear on list X" and we >>> would have exactly the situation everyone seems to be afraid of, and it doesn't >>> need RPKI. As soon as laws don't allow 'your network, your rules' anymore then >>> anything can happen... But that is something that we'll have to steer through >>> voting, not address policy :) > >- Sander > >> >> Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. > > Again, it doesn't change that. > > Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever. In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her. Accepting an invalid prefix because of a revoked certificate is always an option, unless the law is changed in *every* country where this system is used. Yeah, new laws, and regarding the Internet, has that ever happened? Oh wait. See block-lists in various countries. > Reread Randy's post from just now where draft-ietf-sidr-origin-ops-07 is quoted. > > -Alex RIPE NCC re-assigns resource R from ISP A to LEA L, and issues it a new resource certificate. A does not use RPKI. LEA L creates a ROA and starts announcing R. In accordance with Randy's post, this means the *minimum* RPKI policy will impose the DDoS. Kind Regards, Martin From millnert at gmail.com Mon May 9 22:51:05 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 9 May 2011 16:51:05 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <1E41BAD7-1995-4649-B335-0D7BB26637A9@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> <1E41BAD7-1995-4649-B335-0D7BB26637A9@steffann.nl> Message-ID: On Mon, May 9, 2011 at 4:20 PM, Sander Steffann wrote: > Hi, > >> Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. > > Not really. You would also need laws in each country that force network operators to use RPKI evaluation without applying any whitelisting or exceptions. If the technology is seen as feasible for legislators (where feasible means: control the Internet from one point (for your own safety, of course).), it's not a very distant thought that they'd go for their own list of bad prefixes that you should/could/MUST drop. > If such laws can exist, laws that do the same according to a government-defined blacklist can also exist. (Feels like I'm repeating myself here) Such laws *do* exists. Denmark, Italy, from the top of my head, and I'm not even an activist in this matter. Kind Regards, Martin From drc at virtualized.org Mon May 9 23:03:14 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 9 May 2011 11:03:14 -1000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: Alex, On May 9, 2011, at 10:21 AM, Alex Band wrote: > On 9 May 2011, at 22:06, Sascha Luck wrote: >> Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. > Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever. Of course, because no one is using it right now. Presumably, the point of deploying RPKI is that people are going to use it. My understanding is that once people start using it, ISPs, under their own free will, will presumably implement routing policy based on certification status. At that point, revoking a certification would have an effect on routing. That effect can be anything from dropping de-certified objects on the floor to making them last resort to not doing anything special. Yes, it is my decision as a network operator what I choose. However, if "most" ISPs make the decision that a de-certified resource should be dropped on the floor, then the result is that every entity in the resource certification chain above that resource (LIR, {NIR,} RIR, IANA/ICANN) has the ability to cause that resource to be ignored for "most" ISPs. Is my understanding wrong? > In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her. Of course. And RPKI is providing a hierarchical system to provide information regarding resource certification. The implication of the hierarchical authorization model chosen by the RIRs for RPKI is that parents (and grandparents, etc) can impose policy on their children. Or do I misunderstand the technology here (entirely possible -- been buried under other things and have lost track of RPKI/SIDR developments)? Thanks, -drc From alexb at ripe.net Mon May 9 23:57:37 2011 From: alexb at ripe.net (Alex Band) Date: Mon, 9 May 2011 23:57:37 +0200 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: On 9 May 2011, at 23:03, David Conrad wrote: > Alex, > > On May 9, 2011, at 10:21 AM, Alex Band wrote: >> On 9 May 2011, at 22:06, Sascha Luck wrote: >>> Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. >> Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever. > > > Of course, because no one is using it right now. Presumably, the point of deploying RPKI is that people are going to use it. I meant now in legislative terms, not in adoption terms. :) Even with 100% adoption today, every network operator still has a *choice*. Only legislation can change that. It's just like basing routing decisions on 'route' objects in the IRR, but just more reliable because of the design of RPKI. > My understanding is that once people start using it, ISPs, under their own free will, will presumably implement routing policy based on certification status. At that point, revoking a certification would have an effect on routing. That effect can be anything from dropping de-certified objects on the floor to making them last resort to not doing anything special. Yes, it is my decision as a network operator what I choose. However, if "most" ISPs make the decision that a de-certified resource should be dropped on the floor, then the result is that every entity in the resource certification chain above that resource (LIR, {NIR,} RIR, IANA/ICANN) has the ability to cause that resource to be ignored for "most" ISPs. > > Is my understanding wrong? No. But if I look at this from an RIR perspective, it would of course never be in their interest to do so or play a part in that process. Our goal is to provide an infrastructure and make sure only the registered holder of an Internet resource can create a valid attestation. Other than that, network operators are free to add any routing policy they like, and other network operators are free to base any decision on the available information. Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way. Now that we've finally launched this as a usable, tangible service, this discussion erupts. I'll leave it up to you to to draw a conclusion from that. > >> In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her. > > Of course. And RPKI is providing a hierarchical system to provide information regarding resource certification. The implication of the hierarchical authorization model chosen by the RIRs for RPKI is that parents (and grandparents, etc) can impose policy on their children. Or do I misunderstand the technology here (entirely possible -- been buried under other things and have lost track of RPKI/SIDR developments)? Allocating resources and registering them in the Registry is a function the RIRs have been fulfilling for years already. The same goes for IANA allocations. We've been using that information to for example lock down the creation of route objects in the RIPE Database. But by no means is the Internet Routing Registry system as a whole water tight. The power of it being a distributed system with more than 34 databases is its weakness at the same time. With RPKI, the only thing the RIR locks down is that only the registered holder of an Internet resource can create a valid Route Origin Authorisation. Yes, this is hierarchical in nature, but there is really no other way to make sure only the *legitimate holder* can make a *valid* attestation. This information is validatable by anyone on the Internet using public, open source tools from various parties. In this respect, RPKI makes the routing decision making process more robust. -Alex From andrei.robachevsky at gmail.com Tue May 10 00:57:43 2011 From: andrei.robachevsky at gmail.com (Andrei Robachevsky) Date: Tue, 10 May 2011 00:57:43 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110509200647.GD87495@cilantro.c4inet.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> Message-ID: <4DC87167.9010306@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sascha Luck wrote on 5/9/11 22:06 : > On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote: >> I fully agree. Mind you, they could just as well just make a law that >> says >> "You may not route any packets to/from addresses that appear on list >> X" and we >> would have exactly the situation everyone seems to be afraid of, and >> it doesn't >> need RPKI. As soon as laws don't allow 'your network, your rules' >> anymore then >> anything can happen... But that is something that we'll have to steer >> through >> voting, not address policy :) > >- Sander > > > Right now, this does *not* work effectively because the internet routes > around such censorship attempts and there is no LEA that can reach > *everyone* in the world. This policy proposal changes that. > I am a bit surprised that the whole discussion is around only this part of the equation. What about the added benefit of the routing security this policy and subsequently deployed and adopted system can add? Today, your network can be taken down by a simple misconfiguration or malicious attack without any court order. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3IcWcACgkQljz5tZmtij80NACeICSLzqpBW+jzWsh7AYzlRGP3 tqIAn1Gu5vkMDXJYmMyOnZvEVMGcWKuw =SOQ/ -----END PGP SIGNATURE----- From drc at virtualized.org Tue May 10 03:09:29 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 9 May 2011 15:09:29 -1000 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: Alex, On May 9, 2011, at 11:57 AM, Alex Band wrote: > Even with 100% adoption today, every network operator still has a *choice*. I remember similar arguments being made about DNSSEC in the context of the NTIA/ICANN/VeriSign signing of the root: resolver operators always have the option of not using the trust anchor published by IANA. This argument generally isn't very realistic. > But if I look at this from an RIR perspective, it would of course never be in their interest to do so or play a part in that process. Of course. However, realistically, it would be in the RIRs' (or at least their staff's) interests to abide by lawful requests of law enforcement in the venues in which they are incorporated. Folks at the RIRs might not be happy about it, but you will play a part in that process or get fined/go to jail. > Our goal is to provide an infrastructure and make sure only the registered holder of an Internet resource can create a valid attestation. If this was the extent of what was possible, I doubt anyone would have significant worries. I believe the concern is more that once that infrastructure is built, it will be used for additional, less desirable purposes. > Now that we've finally launched this as a usable, tangible service, this discussion erupts. I'll leave it up to you to to draw a conclusion from that. That people don't deal with stuff until they're forced to? > With RPKI, the only thing the RIR locks down is that only the registered holder of an Internet resource can create a valid Route Origin Authorisation. Having a bit of (excruciatingly painful) personal experience at the other end of this in a past life, why were (are?) the RIRs so reticent about being under the IANA in the RPKI hierarchy? Would not the same arguments apply to RIPE from the LIR's perspective? > Yes, this is hierarchical in nature, but there is really no other way to make sure only the *legitimate holder* can make a *valid* attestation. I would agree that a hierarchical trust model is the simplest and easiest implemented. I'm unclear as to whether no other models exist. However, more concretely, I question whether regardless of whether other trust models exist, it is politically feasible to impose the hierarchical allocation model onto the more peer-to-peer relationships found in the routing system. Personally, I've always been a bit skeptical of the idea that (even theoretically) an RIR could impose a direct and immediate impact on the routability of operational networks relating to sovereign interest (e.g., UK MoD networks), even if that impact would be merely to de-pref their routes in the routers of cooperating ISPs. > This information is validatable by anyone on the Internet using public, open source tools from various parties. In this respect, RPKI makes the routing decision making process more robust. Yes. There is no doubt (at least in my mind) that RPKI could provide benefits. I think what some are saying is that this comes at a risk/cost and some are not confident either that the risk/cost is justified or that there might not be other ways of gaining similar benefit without that risk/cost. Regards, -drc From randy at psg.com Tue May 10 09:30:43 2011 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2011 09:30:43 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DC87167.9010306@gmail.com> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> <4DC87167.9010306@gmail.com> Message-ID: > I am a bit surprised that the whole discussion is around only this part > of the equation. What about the added benefit of the routing security > this policy and subsequently deployed and adopted system can add? > > Today, your network can be taken down by a simple misconfiguration or > malicious attack without any court order. not "can be." essentially, every day someone's prefix is mis-announced by someone else. some have been bad enough to make the press or nanog. most are unintentional. some are malicious. you don't have to swollow the pill that lets you see black helicopters to see this problem. you just have to be a network operator, not a wannabe net lawyer. randy From sander at steffann.nl Tue May 10 09:44:49 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 10 May 2011 09:44:49 +0200 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> Message-ID: <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> Hi Martin, > Sander, I remain fully unconvinced that lowering the effort for > censoring the internet will make no or negative effect on the amount > of censorship done. If you really think different, perhaps we should > make a bet. :) I personally think that law enforcement will find a way to do whatever it needs/wants/etc to do. With or without RPKI. I don't think RPKI makes a big difference in that in the long run. What is more important I think is what can be done when things go terribly wrong in some way (intentionally leaving the meaning of 'wrong' and 'some way' undefined here). If the NCC revokes all certificates and destroys the private key we will have the same internet as we have now: no validated routes, all routes are equal. Sounds like a possible emergency exit strategy... - Sander From millnert at gmail.com Tue May 10 14:37:02 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 10 May 2011 08:37:02 -0400 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: Hi Alex, On Mon, May 9, 2011 at 5:57 PM, Alex Band wrote: > Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way. Purely out of curiosity here, does the complete openness and transparency of the process so far include the code that the RIPE NCC has developed together with external consultants? I've been looking around at http://www.ripe.net/ but I couldn't find an URL to the subversion repository mentioned in the CPS [1]. I do remember hearing from the meeting that some code was planned to be released. Are you going to be releasing all of the code, or will some be kept for obscurity or other reasons? Kind Regards, Martin [1] http://www.ripe.net/lir-services/resource-management/certification/cps/view From millnert at gmail.com Tue May 10 14:58:01 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 10 May 2011 08:58:01 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> Message-ID: Hi Sander, On Tue, May 10, 2011 at 3:44 AM, Sander Steffann wrote: > Hi Martin, > >> Sander, I remain fully unconvinced that lowering the effort for >> censoring the internet will make no or negative effect on the amount >> of censorship done. ?If you really think different, perhaps we should >> make a bet. :) > > I personally think that law enforcement will find a way to do whatever it needs/wants/etc to do. With or without RPKI. I don't think RPKI makes a big difference in that in the long run. I still hold that availability of technology is an enabler for policies, and free-will implementation removes the need to make laws, which may or may not be subject to public scrutiny/affecting election outcomes, etc. > What is more important I think is what can be done when things go terribly wrong in some way (intentionally leaving the meaning of 'wrong' and 'some way' undefined here). If the NCC revokes all certificates and destroys the private key we will have the same internet as we have now: no validated routes, all routes are equal. Sounds like a possible emergency exit strategy... It does, for RPKI, and it would be extremely useful if it was written in ink and published in very public places under under what circumstances it will be enacted. But it still does leave unhandled possible recourses or exit strategies for when things go terribly wrong in some way with the registry itself. What are our options in this case? Kind Regards, Martin From andy at nosignal.org Tue May 10 14:57:29 2011 From: andy at nosignal.org (Andy Davidson) Date: Tue, 10 May 2011 13:57:29 +0100 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <4DBFE7A7.7050608@linx.net> References: <4DBFE7A7.7050608@linx.net> Message-ID: <658902F9-8B8D-433D-9A9C-7E421DB80BC9@nosignal.org> On 3 May 2011, at 12:31, Malcolm Hutty wrote: > [2] For example, could we creates "webs of trust" rather than a single > hierarchy? Would that be "good enough" or is a hierarchy essential? I am strongly in favour of resource certification, but appeared (until RIPE62) to be labouring under the misapprehension that this web (rather than hierarchy) system was the thing that we are building. Thank you for raising the point, Malcolm. The Utopia, for me, is that a certificate would be valid if the NCC, *or* ARIN, *or* APNIC, *or* ..., *or* MOON-NIC, *or* Certs Inc, *or* Randy, or even my private CA had signed it, because no single regulator in any jurisdiction would be able to revoke my certificate and prevent routing. I get the benefits of automation, and the benefits of certification, without having to carry the risk of an 'internet off' switch. Is it too late for this ? Please say not. Andy From sander at steffann.nl Tue May 10 15:13:02 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 10 May 2011 15:13:02 +0200 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> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> Message-ID: Hi, > But it still does leave unhandled possible recourses or exit > strategies for when things go terribly wrong in some way with the > registry itself. What are our options in this case? Stop using them :) If it's not an LEA forcing you to do something then you always have this choice. Sander From rhe at nosc.ja.net Tue May 10 15:20:47 2011 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 10 May 2011 14:20:47 +0100 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> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> Message-ID: <4DC93BAF.1080704@nosc.ja.net> > Stop using them :) If it's not an LEA forcing you to do something then you always have this choice. ...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-) Rob From millnert at gmail.com Tue May 10 15:40:50 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 10 May 2011 09:40:50 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DC93BAF.1080704@nosc.ja.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> Message-ID: Hi, On Tue, May 10, 2011 at 9:20 AM, Rob Evans wrote: >> Stop using them :) ?If it's not an LEA forcing you to do something then >> you always have this choice. > > ...and this is a point worth stressing. ?If things do "go bad," it isn't the > end of the Internet, but we can bail on using the RPKI as it is implemented > at the time. ?It's all about co-operation. :-) What's the required escape velocity for the world to bail on RPKI if it is universally deployed? DNSSEC? A significant hurdle I believe, meaning not just a little but a substantial abuse must be on-going to reach that point. It's the inverse network effect. To me it seems you are both suggesting that we should start developing an alternative that we can bail to already, so that there is an actual meaningful exit strategy. What I'm wondering is, if the alternative is better than the original, why not go to it directly? Enabling a technology that enables an unfortunate legal lock-down, for example, is a grave error. At least in my book. Kind Regards, Martin From tim at ripe.net Tue May 10 16:51:33 2011 From: tim at ripe.net (Tim Bruijnzeels) Date: Tue, 10 May 2011 16:51:33 +0200 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: Hi Martin, On May 10, 2011, at 2:37 PM, Martin Millnert wrote: > I do remember hearing from the meeting that some code was planned to > be released. Are you going to be releasing all of the code, or will > some be kept for obscurity or other reasons? The validation tool is available in both binary form and as open source (bsd), here: http://www.ripe.net/lir-services/resource-management/certification/validation-information The plan is to start a pilot in a few weeks where members can run their own local CA instead of the hosted service that is offered now. When this pilot starts it is planned to release an initial standalone CA, again under a BSD license, with limited functionality (eg not able to issue certificates to child CAs of its own). In the long term nothing has been decided yet. This depends on feedback from the community as well of course. We could extend the features of this standalone CA, or when we are sure that interoperability with the ISC 'rpkid' works, members can use that.. Regards, Tim Bruijnzeels Senior Software Engineer RIPE NCC From tim at ripe.net Tue May 10 16:06:00 2011 From: tim at ripe.net (Tim Bruijnzeels) Date: Tue, 10 May 2011 16:06:00 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DC93BAF.1080704@nosc.ja.net> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> Message-ID: Hello WG, I am RIPE NCC staff, but having worked on this subject for some time now I have some technical input to the discussion that I would really like to share: On May 10, 2011, at 3:20 PM, Rob Evans wrote: >> Stop using them :) If it's not an LEA forcing you to do something then you always have this choice. > > ...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-) The 'risk' of the RIPE NCC going rogue under legal coercion could be modeled as the product of the (1) 'likelihood' and the (2) 'impact' (1) Regarding likelihood: - revoking certs is not enough - a top entity in the pki chain like the ripe ncc would also have to reallocate resources so that a new valid roa may be made for a different as and that network be announced This is both against all current ripe policies and several people have pointed out that legal feasibility is very low at this time. However I understand from the thread that not everyone is convinced. So that leaves: (2) Regarding impact (i.e. affecting real routing) The RPKI is not enabled automatically in routers. In fact if it is enabled the *information* is available in routers, but decisions are up to local policy. There are at least three layers where local policy may be enforced: 1) ROUTER ...by having additional configuration that overrides the rpki governed local preferences you just added yourself. Essentially this is not so different from what's going on now. People use many rules, some are maintained manually, others are scripted eg based on IRR. The rpki adds a powerful default rule set that people can use, but it is not the end of all configuration. Just don't think that one should just set up the default 'prefer certified routes' rules and forget about all other rules and exceptions... 2) VALIDATION TOOLS If people express the demand it's fairly easy to add whitelisting functionality to validation tools. This would mean that the router would not know the difference between an AS-Prefix tuple coming from a ROA in the RPKI or an entry on the whitelist. The same router config could be used in both cases. Having said that, please realise that the whitelist (presumably maintained by a 'trusted' third party), is in itself an attack vector. But the choice is yours... 3) LOCAL TRUST ANCHOR (LTA) See here: http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/ This draft explains a method that allows a 'relying party' to take information from one (or more) source RPKI trees and build up a locally consistent tree. The party doing this will essentially copy data and use his own keys. This allows the party to be *more* restrictive, or *less* restrictive with regards to ROAs, certificates, validity times etc. (many more details in the draft) BBN has a reference implementation for this Local Trust Anchor handling. Note that existing validation tools can use this new Trust Anchor as a starting point without any modification needed to the tools. This technique can be used in two ways: a) more restrictive This technique enables LEA to set up their own TA tree under their own control. This can easily be done in the absence of a community run repository. In fact it's easiest on LEAs if the techniques are available (and they are coming out of the IETF now), and there are no disturbing other versions of the truth out there.. a whole lot less to delete.. b) less restrictive Third parties (many in theory) can set up and maintain public LTAs for others. If the RIPE NCC or any other player in the rpki is found to have inappropriately done something like revoking a certificate and re-allocating to someone else (as determined by the maintainer of the local trust anchor), then the maintainer can choose to keep using the old stuff. Please note that if you trust someone else to maintain such an LTA for you, they may also be susceptible to LEAs, bribes, threats, mistakes etc. But the choice is yours... and if in fact more than one party is doing this it will be fairly easy to switch. You will have to ask yourself who *you* trust most. Regards, Tim Bruijnzeels Senior Software Engineer RIPE NCC From dburk at burkov.aha.ru Tue May 10 15:54:07 2011 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Tue, 10 May 2011 17:54:07 +0400 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <658902F9-8B8D-433D-9A9C-7E421DB80BC9@nosignal.org> References: <4DBFE7A7.7050608@linx.net> <658902F9-8B8D-433D-9A9C-7E421DB80BC9@nosignal.org> Message-ID: <4DC9437F.5080109@burkov.aha.ru> Andy, as I seen this process - one have tried to design this tool with secure BGP in mind, second one thought about Certificates as a tool to protect current address management system (aka RIRs), third group - as you - think about it as a tool to protect your resource and make routing for himself more safe. In general all three think about safe routing - but each one has his own special requirements and goals - what is really important for him personally. And practically only today we began public discussion - is it the same for all of us? Can we satisfy all needs by one design? This policy is as a some kind of test for me - can we find a common compromise? Dima On 10.05.2011 16:57, Andy Davidson wrote: > On 3 May 2011, at 12:31, Malcolm Hutty wrote: > >> [2] For example, could we creates "webs of trust" rather than a single >> hierarchy? Would that be "good enough" or is a hierarchy essential? > I am strongly in favour of resource certification, but appeared (until RIPE62) to be labouring under the misapprehension that this web (rather than hierarchy) system was the thing that we are building. Thank you for raising the point, Malcolm. > > The Utopia, for me, is that a certificate would be valid if the NCC, *or* ARIN, *or* APNIC, *or* ..., *or* MOON-NIC, *or* Certs Inc, *or* Randy, or even my private CA had signed it, because no single regulator in any jurisdiction would be able to revoke my certificate and prevent routing. I get the benefits of automation, and the benefits of certification, without having to carry the risk of an 'internet off' switch. Is it too late for this ? Please say not. > > Andy > From millnert at gmail.com Tue May 10 17:38:46 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 10 May 2011 11:38:46 -0400 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> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> Message-ID: Hi Tim, thank you for bringing forth clarity on LTA and answering the question of the availability of the code. On Tue, May 10, 2011 at 10:06 AM, Tim Bruijnzeels wrote: > Hello WG, > > I am RIPE NCC staff, but having worked on this subject for some time now I have some technical input to the discussion that I would really like to share: > > On May 10, 2011, at 3:20 PM, Rob Evans wrote: >>> Stop using them :) ?If it's not an LEA forcing you to do something then you always have this choice. >> >> ...and this is a point worth stressing. ?If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. ?It's all about co-operation. :-) > > > The 'risk' of the RIPE NCC going rogue under legal coercion could be modeled as the product of the (1) 'likelihood' and the (2) 'impact' > > (1) Regarding likelihood: > > - revoking certs is not enough > - a top entity in the pki chain like the ripe ncc would also have to reallocate resources so that a new valid roa may be made for a different as and that network be announced (snip) > ? ? ? ?3) LOCAL TRUST ANCHOR (LTA) > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/ > This technique can be used in two ways: > > ? ? ? ?a) more restrictive > > This technique enables LEA to set up their own TA tree under their own control. This can easily be done in the absence of a community run repository. In fact it's easiest on LEAs if the techniques are available (and they are coming out of the IETF now), and there are no disturbing other versions of the truth out there.. a whole lot less to delete.. Excellent argument against hierarchical policy on the Internet, from my point of view. > ? ? ? ?b) less restrictive > > Third parties (many in theory) can set up and maintain public LTAs for others. (threats to hierarchical systems removed) > But the choice is yours... and if in fact more than one party is doing this it will be fairly easy to switch. > You will have to ask yourself who *you* trust most. What I trust *the most* is for the proper holders of a resource to attest to their own resource(s) *themselves*. If we allow ourselves the thought exercise to design a (BGP) routing security system without constraints and from scratch, would you agree the base model is something along the lines of the following? - "I can prove I have resource X and the right to originate it [into the network]", for origination, which may be a subset of: - "I can prove I have the right to announce resource X", for propagation/paths (which may or may not scale badly -- for example, the right or endorsement to re-announce a resource could be conceived as transferable from A to B, (!= NO_EXPORT, but related), possibly with transferability of the right to transfer the right to announce, as well :) (and if we get real picky A may steer the endorsement to only certain peers of B) ), in combination with, - a method for B to verify A:s proof of right to announce X, and, - for C (a peer of B), a method to verify B's right-to-announce X (functioning as endorsements). The gravest failure mode in this model I can think of is that A may lose its X against its will. Kind Regards, Martin From gert at space.net Tue May 10 17:47:23 2011 From: gert at space.net (Gert Doering) Date: Tue, 10 May 2011 17:47:23 +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> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> Message-ID: <20110510154723.GZ30227@Space.Net> Hi, On Tue, May 10, 2011 at 11:38:46AM -0400, Martin Millnert wrote: > What I trust *the most* is for the proper holders of a resource to > attest to their own resource(s) *themselves*. So how do you determine which of the following attestations is true? "I permit 195.30.0.0/16 to be announced by AS5539" "I permit 80.81.192.0/22 to be announced by AS5539" AS5539 is my AS number, and one of those netblocks is mine, while the other one isn't. If I were trustworthy, and wouldn't make typing mistakes, you just would believe me that I'll only ever announce my netblocks - but reality shows that mis-announcements do happen, so the attestations are only useful if there is an authority that tells you that I'm indeed the holder of one of those blocks, and can do attestations about them... ... and that would be a hierarchical attestation following the allocation/assignment hierarchy. (Of course, my friends would know that I'm to be trusted, and could point a local trust anchor my way, but how would a network on the other end of the world know that?) Gert Doering -- 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 lutz at iks-jena.de Tue May 10 17:57:03 2011 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 10 May 2011 15:57:03 +0000 (UTC) Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) References: <20110510154723.GZ30227@Space.Net> Message-ID: * Gert Doering wrote: > ... and that would be a hierarchical attestation following the > allocation/assignment hierarchy. So we need an hierarchical certification system ... Welcome to DNSSEC. http://tools.ietf.org/html/draft-donnerhacke-sidr-bgp-verification-dnssec From sander at steffann.nl Tue May 10 18:05:08 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 10 May 2011 18:05:08 +0200 Subject: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call In-Reply-To: <658902F9-8B8D-433D-9A9C-7E421DB80BC9@nosignal.org> References: <4DBFE7A7.7050608@linx.net> <658902F9-8B8D-433D-9A9C-7E421DB80BC9@nosignal.org> Message-ID: Hi Andy, > I am strongly in favour of resource certification, but appeared (until RIPE62) to be labouring under the misapprehension that this web (rather than hierarchy) system was the thing that we are building. Thank you for raising the point, Malcolm. > > The Utopia, for me, is that a certificate would be valid if the NCC, *or* ARIN, *or* APNIC, *or* ..., *or* MOON-NIC, *or* Certs Inc, *or* Randy, or even my private CA had signed it, because no single regulator in any jurisdiction would be able to revoke my certificate and prevent routing. I get the benefits of automation, and the benefits of certification, without having to carry the risk of an 'internet off' switch. Is it too late for this ? Please say not. I think this presentation of Stephen Kent shows some possibilities: http://meetings.apnic.net/__data/assets/pdf_file/0019/18910/Routing-Security_03_Local-Trust-Anchor-Management-for-the-RPKI-_Stephen-Kent.pdf - Sander From malcolm at linx.net Tue May 10 18:20:04 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Tue, 10 May 2011 17:20:04 +0100 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: <4DC965B4.6030405@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/2011 15:51, Tim Bruijnzeels wrote: > > The plan is to start a pilot in a few weeks where members can run > their own local CA instead of the hosted service that is offered > now. Will that only occur if rough consensus in favour of the policy is achieved in this Working Group? Or will it proceed even if not/in advance of such consensus being achieved? What will happen to the existing hosted solution if this policy does not achieve consensus during this Last Call? Is there another policy that has already been approved that authorises the RIPE NCC hosted RKPI? 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/ iEYEARECAAYFAk3JZbQACgkQJiK3ugcyKhRq/QCgkqdosdSYfVloDTtn78ZY08iW nagAnRRXNEKS6g6lXAkPTS42h8b98CQR =Ro8E -----END PGP SIGNATURE----- From randy at psg.com Tue May 10 19:12:40 2011 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2011 19:12:40 +0200 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> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> Message-ID: > thank you for bringing forth clarity on LTA and answering the question > of the availability of the code. to repeat what i said at the mic. the lta doc merely describes how the existing specs can be used in a twisted manner to let a part have their special view of reality. it is inherent in *all* relying party code. randy From randy at psg.com Tue May 10 19:14:22 2011 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2011 19:14:22 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <20110510154723.GZ30227@Space.Net> Message-ID: > So we need an hierarchical certification system ... Welcome to DNSSEC. > http://tools.ietf.org/html/draft-donnerhacke-sidr-bgp-verification-dnssec you are over a decade too late draft-bates-bgp4-nlri-orig-verif-00.txt randy From randy at psg.com Tue May 10 19:16:40 2011 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2011 19:16:40 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: References: <20110510154723.GZ30227@Space.Net> Message-ID: > So we need an hierarchical certification system ... Welcome to DNSSEC. > http://tools.ietf.org/html/draft-donnerhacke-sidr-bgp-verification-dnssec you are over a decade too late. see draft-bates-bgp4-nlri-orig-verif-00.txt randy From millnert at gmail.com Tue May 10 19:25:21 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 10 May 2011 13:25:21 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110510154723.GZ30227@Space.Net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> <20110510154723.GZ30227@Space.Net> Message-ID: Hi Gert, On Tue, May 10, 2011 at 11:47 AM, Gert Doering wrote: > Hi, > > On Tue, May 10, 2011 at 11:38:46AM -0400, Martin Millnert wrote: >> What I trust *the most* is for the proper holders of a resource to >> attest to their own resource(s) *themselves*. > > So how do you determine which of the following attestations is true? > > ?"I permit 195.30.0.0/16 to be announced by AS5539" > ?"I permit 80.81.192.0/22 to be announced by AS5539" > > AS5539 is my AS number, and one of those netblocks is mine, while the > other one isn't. > > If I were trustworthy, and wouldn't make typing mistakes, you just would > believe me that I'll only ever announce my netblocks - but reality shows > that mis-announcements do happen, so the attestations are only useful if > there is an authority that tells you that I'm indeed the holder of one > of those blocks, and can do attestations about them... Yes, this is indeed the key issue. I'd like to single out the registry function you mention above, and separate it from that authority also having the power to lease out resources under some kind of notion that they can be called back. Clearly, as long as [people are in agreement that] resources are leased, the lessor will remain the single dominant authority over said resources, but this only works if there is also agreement that resources have been called back. This is quite different from stating that the only solution to my base routing security model is to lease out resources. So, are there other ways to organize a registry? (I don't want you to get stuck at too specific details since the following suggestion would need development work no doubt, but) the general idea is something along the lines of: Imagine you have a data file, let's say XML since it allows types and is reasonably clear-text, which states: 5539 ... ... Now imagine you sign this file with a PKI crypt-system, using your private key. Following this you send this signed object to the RIPE NCC, because they're your current RIR. RIPE signs this blob irrevocably, with their own private key and may attach some other useful data, like perhaps a time stamp. You can now show up a signed object, signed *irrevocably* by the RIPE NCC (set validity=inf, /etc/init.d/crl-server stop), which now for all intents and purposes has become your ASN - it's come to life in this file and in doing so you can now do what you want with it, including sending out copies of it anyway you wish or running it through /usr/bin/shred . When the RIPE NCC signs this object, they in effect sign it over to you and should update their records accordingly. Repeat the same process for the netblock which is yours. The RIPE NCC won't sign the one which isn't registered to you over to you, though. There are issues with the RIPE NCC losing their key(s), signing away a previously un-signed-away resource to the wrong recipient, and also, later signing someone else's XML file signed with their private key, stating your ASN. A possible and interesting mitigation to part of the above may be to include your blob into a distributed database system, which perhaps use some time windowing to the effect that, at T=435 , there were 25644 incorporated objects, yours not included. Then, when you add one of your own, it will eventually after some form of system agreement get rolled into the ddb, which then rolls over to T=436 where it now has 25645 objects and yours is one of them. Doing something similar to this, I imagine you can be able to trace the existence of your resource or any later duplicates of your object in this system, which presumably would not get accepted into the system since they previously already exists. How to organize transfer of resources between parties is another chapter, but soluble no doubt. There are likely attacks possible against this system, both known and unforeseeable, and hopefully known ones can be mitigated (reaching agreement in rolling forward and ensuring correctness of data that is entered are the two single biggest issue I can think of right now). For correctness, there is probably no way to remove an object from the ddb without organizing sufficient a-prior agreement amongst the participants. It does not have any removeObject() calls. As always, you have to be careful with your private key. I guess it is free for people to organize their private keys best they wish. Perhaps some put a backup at the RIPE NCC? (Or under their pillow?) It's worthwhile to note that this ddb does not care whether or not the RIPE NCC did mark their records correctly (and that they stay that way) after they signed away a resource which then got incorporated into the ddb. The real remaining issue with the above is the RIPE NCC "signing away a previously un-signed-away resource", a problem it shares with RPKI, for which it was proposed there would be sanity checks in place. In the above, more than sanity checks are required to keep the ddb correct, however. Interesting topic that. If anything similar has been proposed before, I must have missed it. > ... and that would be a hierarchical attestation following the > allocation/assignment hierarchy. > > (Of course, my friends would know that I'm to be trusted, and could point > a local trust anchor my way, but how would a network on the other end > of the world know that?) See ddb above. Kind Regards, Martin From Woeber at CC.UniVie.ac.at Tue May 10 22:10:54 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 10 May 2011 20:10:54 +0000 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110510154723.GZ30227@Space.Net> References: <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> <20110510154723.GZ30227@Space.Net> Message-ID: <4DC99BCE.7080008@CC.UniVie.ac.at> Gert Doering wrote: [...] > ... and that would be a hierarchical attestation following the > allocation/assignment hierarchy. An attempt to KISS: What we (at least some of us) want to avoid is a single-point-of-failure. Looking back in history, I can remember discussions to find ways around the (then perceived) SPoF of ICANN + US.fed.law, regarding management of the DNS Root. What some of us pondered was to get the whole system easily replicated. Thus - how about leveraging the fact that we do have *5* such entities, around the world, both geographically as well as jurisdiction-wise well- distributed. What prevents us from obtaining *more than one* attestation proving proper resource holdership? I'd assume that any single pressure or interst group would then not consider it easy - and thus useful - to try to cripple all of those valid copies at the same time. > (Of course, my friends would know that I'm to be trusted, and could point > a local trust anchor my way, but how would a network on the other end > of the world know that?) > > Gert Doering Wilfried. From Woeber at CC.UniVie.ac.at Tue May 10 22:18:43 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 10 May 2011 20:18:43 +0000 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: <4DC99DA3.7030508@CC.UniVie.ac.at> Hi Alex, Alex Band wrote: [...] > Also, you have to realise that we've been working on this since 2006, > by our Community's request. The system is based on open IETF standards > in the SIDR working group which has been active even longer. All of this > has been done in a completely open and transparent way. Now that we've > finally launched this as a usable, tangible service, this discussion erupts. > I'll leave it up to you to to draw a conclusion from that. Neither trying to make a statement in favour or against, just as an observation. 2011 - 2006 = 5 years = an awefully long period of time in NetLand. In 2006 "nobody" was interested in taking control of the 'net or the information accessible over this tech. Since then the world has moved on and we can now observe many attempts, by many different parties (not exlusively governments!), to get a "better grip" on the Internet. Things have changed a bit since 2006, I'm afraid... Wilfried. From gert at space.net Tue May 10 22:54:59 2011 From: gert at space.net (Gert Doering) Date: Tue, 10 May 2011 22:54:59 +0200 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> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> <20110510154723.GZ30227@Space.Net> Message-ID: <20110510205459.GB30227@Space.Net> Hi, On Tue, May 10, 2011 at 01:25:21PM -0400, Martin Millnert wrote: > > ?"I permit 195.30.0.0/16 to be announced by AS5539" > > ?"I permit 80.81.192.0/22 to be announced by AS5539" > > > > [and needing some sort of document from RIPE NCC to say which > > one is true] > > Yes, this is indeed the key issue. I'd like to single out the > registry function you mention above, and separate it from that > authority also having the power to lease out resources under some kind > of notion that they can be called back. Well, that's the IP resource assignment framework we have today: numbers are given out as long as they are needed, and given back when they are no longer needed (or under special circumstances, e.g. fraud involved). If you change that model to something where number blocks are actually traded ("Sold by the NCC to entity A, which can do then with the numbers whatever it want, e.g. sell to entity B without registering with the RIPE NCC"), the model would look different - and a trade could, for example, be done in your model by adding an "eternal signature" to the hand-over XML blob. So, assuming we want to keep the existing model of number resource allocations from the RIRs (and giving them *back* to the RIRs eventually), what can we do to have that reflected in whatever attestation system? It should be pointed out that the nice folks over at the anti-abuse WG would scream bloody murder if they hear about the notion of resources being given to spammers, scammers, phishers and whatnot, with no way to take them back... (and that's not "LEA type" anti-abuse folks, but "netizen" anti-abuse folks). Gert Doering -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From millnert at gmail.com Wed May 11 00:02:43 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 10 May 2011 18:02:43 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110510205459.GB30227@Space.Net> References: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <2371F0FF-D0BD-4F7E-B57F-4EFFBAC95BB5@steffann.nl> <4DC93BAF.1080704@nosc.ja.net> <20110510154723.GZ30227@Space.Net> <20110510205459.GB30227@Space.Net> Message-ID: Hi Gert, On Tue, May 10, 2011 at 4:54 PM, Gert Doering wrote: > Hi, > > On Tue, May 10, 2011 at 01:25:21PM -0400, Martin Millnert wrote: >> > ?"I permit 195.30.0.0/16 to be announced by AS5539" >> > ?"I permit 80.81.192.0/22 to be announced by AS5539" >> > >> > [and needing some sort of document from RIPE NCC to say which >> > ?one is true] >> >> Yes, this is indeed the key issue. ?I'd like to single out the >> registry function you mention above, and separate it from that >> authority also having the power to lease out resources under some kind >> of notion that they can be called back. > > Well, that's the IP resource assignment framework we have today: numbers > are given out as long as they are needed, and given back when they are > no longer needed (or under special circumstances, e.g. fraud involved). Yes, I agree with your description of the current model. And maybe it can be an healthy exercise to consider alternative solutions, if only to broaden the horizon a little on threats / possible mitigations, or, to reinforce the perception that what we do have is the best of what we can accomplish. There will soon be virtually no IPv4 for the RIRs to give out, despite need. And if we please may save ourselves from a "Internet Fairness Re-appropriation and Re-assignment Committe", clearly money will play a role in assessing IPv4 holders relative needs of address blocks in the future. Considering legacy resources, these may well trade hands without the involvement of a RIR if it is seen as too complex/expensive/pointless. So even if RIR transfer policy is infinitely simple and free, we still have to worry about how to keep transferred resources up-to-date in the registry. I understand that resource certification may come to play a role in this too. (The ddb solves this aspect too.) > If you change that model to something where number blocks are actually > traded ("Sold by the NCC to entity A, which can do then with the numbers > whatever it want, e.g. sell to entity B without registering with the > RIPE NCC"), the model would look different - and a trade could, for example, > be done in your model by adding an "eternal signature" to the hand-over > XML blob. I imagine something like that could be done, yes. > So, assuming we want to keep the existing model of number resource > allocations from the RIRs (and giving them *back* to the RIRs eventually), > what can we do to have that reflected in whatever attestation system? First, I think it is quite hard to combine the goals of having the ability to revoke resources, with a fault-tolerant hierarchical routing registry/security system. Second, yes, we can polish up copies of resource certifications, even have lots of independent copies of them, and even the RIR data, but as long as resource registrations may be changed in the original registry without a method of rejecting unfortunate changes, we're left with copies of the duplicated data that over time increasingly will be disagreeing with the registry data. Thus, if ever so slowly, we will move towards a somewhat ad-hoc ("distributed") chaos model. ("with t->\inf, quality(rir data) -> 0" points to a flaw in the model IMHO.) I think Sander and Rob started up on a good trail, when working within the current model of number resource allocations, by having emergency exit-strategies. But it's hard to see how this can work in practice without some effective method to implement them. I do like the LTA magic of rewriting the root (or somewhere else) of a hierarchical system onto yourself. As I've expressed before, if the community does end up going for RPKI, I'd seriously like to see more software which can cook up alternative trees, ignoring certain changes, comparing source data trees and so on and so forth. (diluting accuracy of RIR data) > It should be pointed out that the nice folks over at the anti-abuse WG > would scream bloody murder if they hear about the notion of resources > being given to spammers, scammers, phishers and whatnot, with no way > to take them back... ?(and that's not "LEA type" anti-abuse folks, but > "netizen" anti-abuse folks). If a network wants to filter out certain prefixes they have the choice of doing so, right? Not sure how this is at all relevant in an automated filtering world of free choice. Kind Regards, Martin From shane at time-travellers.org Wed May 11 10:32:34 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 11 May 2011 10:32:34 +0200 Subject: [address-policy-wg] Address/ASN certificates and RIPE NCC Transparency Report?, was 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> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: <1305102754.2512.11.camel@shane-desktop> Martin, On Tue, 2011-05-10 at 08:37 -0400, Martin Millnert wrote: > Hi Alex, > > On Mon, May 9, 2011 at 5:57 PM, Alex Band wrote: > > > Also, you have to realise that we've been working on this since > > 2006, by our Community's request. The system is based on open > > IETF standards in the SIDR working group which has been active even > > longer. All of this has been done in a completely open and > > transparent way. > > Purely out of curiosity here, does the complete openness and > transparency of the process so far include the code that the RIPE NCC > has developed together with external consultants? I've been looking > around at http://www.ripe.net/ but I couldn't find an URL to the > subversion repository mentioned in the CPS [1]. > > I do remember hearing from the meeting that some code was planned to > be released. Are you going to be releasing all of the code, or will > some be kept for obscurity or other reasons? Speaking of openness... :) It would be nice if the RIPE NCC could commit to something like the Google Transparency Report, where all government requests for legal action are published openly: http://www.google.com/transparencyreport/ Looking at those numbers makes it pretty clear to me that governments will be mucking around with routing policy eventually, whether or not we have certificates. It might be nice to have something like this independent of any eventual certification policy. -- Shane From jim at rfc1035.com Wed May 11 12:25:52 2011 From: jim at rfc1035.com (Jim Reid) Date: Wed, 11 May 2011 11:25:52 +0100 Subject: [address-policy-wg] Address/ASN certificates and RIPE NCC Transparency Report?, was Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <1305102754.2512.11.camel@shane-desktop> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> <1305102754.2512.11.camel@shane-desktop> Message-ID: <67EA084B-8657-4490-B18A-2E5C0B0EBD50@rfc1035.com> On 11 May 2011, at 09:32, Shane Kerr wrote: > It would be nice if the RIPE NCC could commit to something like the > Google Transparency Report, where all government requests for legal > action are published openly Shane, it doesn't work like that. There will be occasions when the existence of a government (or law enforcement) request cannot be mentioned. BTW, google and transparency: that's an interesting combination. From hank at efes.iucc.ac.il Wed May 11 12:40:08 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 11 May 2011 13:40:08 +0300 Subject: [address-policy-wg] Address/ASN certificates and RIPE NCC Transparency Report?, was Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <1305102754.2512.11.camel@shane-desktop> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> <20110509200647.GD87495@cilantro.c4inet.net> <7D31BFB4-5177-4475-8EBA-771B715690DF@ripe.net> Message-ID: <5.1.0.14.2.20110511133951.0370aa18@efes.iucc.ac.il> At 10:32 11/05/2011 +0200, Shane Kerr wrote: >Content-Transfer-Encoding: 7bit > >Martin, > >On Tue, 2011-05-10 at 08:37 -0400, Martin Millnert wrote: > > Hi Alex, > > > > On Mon, May 9, 2011 at 5:57 PM, Alex Band wrote: > > > > > Also, you have to realise that we've been working on this since > > > 2006, by our Community's request. The system is based on open > > > IETF standards in the SIDR working group which has been active even > > > longer. All of this has been done in a completely open and > > > transparent way. > > > > Purely out of curiosity here, does the complete openness and > > transparency of the process so far include the code that the RIPE NCC > > has developed together with external consultants? I've been looking > > around at http://www.ripe.net/ but I couldn't find an URL to the > > subversion repository mentioned in the CPS [1]. > > > > I do remember hearing from the meeting that some code was planned to > > be released. Are you going to be releasing all of the code, or will > > some be kept for obscurity or other reasons? > >Speaking of openness... :) > >It would be nice if the RIPE NCC could commit to something like the >Google Transparency Report, where all government requests for legal >action are published openly: +1. -Hank >http://www.google.com/transparencyreport/ > >Looking at those numbers makes it pretty clear to me that governments >will be mucking around with routing policy eventually, whether or not we >have certificates. > >It might be nice to have something like this independent of any eventual >certification policy. > >-- >Shane From germann at global-village.de Thu May 12 22:36:16 2011 From: germann at global-village.de (Elmar Germann) Date: Thu, 12 May 2011 22:36:16 +0200 (CEST) Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 Message-ID: Hello, we do not support this policy. Removing the requirement for multihomed announcements would simply result in more unnecessary PI assignments which will increase the prefix table. We were already asked from several customers for new PI assignments just to draw down the work in case of an ISP change. PI address space should always be bound to technical requirements so that only end users with real requirements are able to request an assignment. I agree that there's currently a discriminating between IPv6 PA und PI address space, but the conculsion should be changeing the policy for the PA address space and not offering PI address space without technical requirements. Kind regards, Elmar Germann. -- Global Village GmbH Tel +49 2855 9651 0 GF Marcus Faure Mehrumer Str. 16 Fax +49 2855 9651 110 Amtsgericht Duisburg HRB9987 D-46562 Voerde eMail info at globvill.de Ust-Id DE180295363 From slz at baycix.de Fri May 13 09:47:34 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 13 May 2011 09:47:34 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: Message-ID: Hay, Am 12.05.2011 um 22:36 schrieb Elmar Germann: > Hello, > > we do not support this policy. Removing the requirement for multihomed announcements would simply result in more unnecessary PI assignments which will increase the prefix table. We were already asked from several customers for new PI assignments just to draw down the work in case of an ISP change. PI address space should always be bound to technical requirements so that only end users with real requirements are able to request an assignment. > I agree that there's currently a discriminating between IPv6 PA und PI address space, but the conculsion should be changeing the policy for the PA address space and not offering PI address space without technical requirements. that might be a rather shortsighted and possibly dangerous view on the matter. Because instead of just getting a PI prefix which you as clueful ISP will inject in the DFZ, this just leads to most of them asking for a happy-meal including an ASN and you have to deal with another unmaintained and possibly unstable AS in the DFZ because they just pay a consultant once to set up BGP on their router and the Tunnel to he.net as a 2nd Upstream for free and never care about it anymore. Or worse, they do it themselves with help from their favorite search-engine *shudder*. ...just my 0.01 EUR And yes i don't understand the whining about the requirement anyways. It's easy to circumvent. So it's not at all doing anything good at all. (I indeed support the proposal for various non-technical reasons. If things with PI vs. PA might change anyways in the foreseeable future, this IPv4 vs. IPv6 PI policy distinction is doing nothing but hinder the desperately needed widespread IPv6 deployment at the very moment. One has to set the right priorities here.) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From poty at iiat.ru Fri May 13 10:44:42 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Fri, 13 May 2011 12:44:42 +0400 Subject: FW: [address-policy-wg] Removal of multihomed requirement for IPv6 Message-ID: Hello, I do not support this proposal. We are speaking about real possibilities and real impact. The proposers doesn't know exactly the impact of the changes and are deaf to the other people pointing to the real troubles relating the grooving number of prefixes. Their na?ve assumptions about cheap BGP routers show their inability to broader the mind just outside their small nets needs. Technical requirements should be the only way of making decisions. If someone has tendency to lie - it would lie anyway - one thing or another. Regards, Vladislav Potapov Ru.iiat From thabet at gmail.com Fri May 13 10:47:20 2011 From: thabet at gmail.com (thabet at gmail.com) Date: Fri, 13 May 2011 08:47:20 +0000 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 In-Reply-To: References: Message-ID: <265676710-1305276442-cardhu_decombobulator_blackberry.rim.net-287557887-@b14.c9.bise7.blackberry> I agree with Vladislav Potapov Sent from my BlackBerry? smartphone from du -----Original Message----- From: Sender: address-policy-wg-admin at ripe.net Date: Fri, 13 May 2011 12:44:42 To: Subject: FW: [address-policy-wg] Removal of multihomed requirement for IPv6 Hello, I do not support this proposal. We are speaking about real possibilities and real impact. The proposers doesn't know exactly the impact of the changes and are deaf to the other people pointing to the real troubles relating the grooving number of prefixes. Their na?ve assumptions about cheap BGP routers show their inability to broader the mind just outside their small nets needs. Technical requirements should be the only way of making decisions. If someone has tendency to lie - it would lie anyway - one thing or another. Regards, Vladislav Potapov Ru.iiat From euabsipa at emea.att.com Fri May 13 14:53:21 2011 From: euabsipa at emea.att.com (ABS EMEA NIC - IPA Support AT&T) Date: Fri, 13 May 2011 14:53:21 +0200 Subject: [address-policy-wg] RE: address-policy-wg digest, Vol 1 #1326 - 4 msgs In-Reply-To: <20110513100005.826.76092.Mailman@postboy.ripe.net> References: <20110513100005.826.76092.Mailman@postboy.ripe.net> Message-ID: <4D802C4079A49043A299A53593DCCF797A07C5093E@skcbcmsx01.emea.att.com> What is different when customer get PA instead of PI ? Don't you have to update the same prefix table ? Do you see any compromise between approve/deny this proposal ? let's say limited number of PI addresses for each End user ? Best regards _____________________________________ Pavol Kovac -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of address-policy-wg-request at ripe.net Sent: Friday, May 13, 2011 12:00 PM To: address-policy-wg at ripe.net Subject: address-policy-wg digest, Vol 1 #1326 - 4 msgs Send address-policy-wg mailing list submissions to address-policy-wg at ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request at ripe.net You can reach the person managing the list at address-policy-wg-admin at ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Removal of multihomed requirement for IPv6 (Elmar Germann) 2. Re: Removal of multihomed requirement for IPv6 (Sascha Lenz) 3. FW: [address-policy-wg] Removal of multihomed requirement for IPv6 (poty at iiat.ru) 4. Re: Removal of multihomed requirement for IPv6 (thabet at gmail.com) --__--__-- Message: 1 Date: Thu, 12 May 2011 22:36:16 +0200 (CEST) From: Elmar Germann To: address-policy-wg at ripe.net Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 Hello, we do not support this policy. Removing the requirement for multihomed announcements would simply result in more unnecessary PI assignments which will increase the prefix table. We were already asked from several customers for new PI assignments just to draw down the work in case of an ISP change. PI address space should always be bound to technical requirements so that only end users with real requirements are able to request an assignment. I agree that there's currently a discriminating between IPv6 PA und PI address space, but the conculsion should be changeing the policy for the PA address space and not offering PI address space without technical requirements. Kind regards, Elmar Germann. -- Global Village GmbH Tel +49 2855 9651 0 GF Marcus Faure Mehrumer Str. 16 Fax +49 2855 9651 110 Amtsgericht Duisburg HRB9987 D-46562 Voerde eMail info at globvill.de Ust-Id DE180295363 --__--__-- Message: 2 Subject: Re: [address-policy-wg] Removal of multihomed requirement for IPv6 From: Sascha Lenz Date: Fri, 13 May 2011 09:47:34 +0200 To: address-policy-wg at ripe.net Hay, Am 12.05.2011 um 22:36 schrieb Elmar Germann: > Hello, >=20 > we do not support this policy. Removing the requirement for multihomed = announcements would simply result in more unnecessary PI assignments = which will increase the prefix table. We were already asked from several = customers for new PI assignments just to draw down the work in case of = an ISP change. PI address space should always be bound to technical = requirements so that only end users with real requirements are able to = request an assignment. > I agree that there's currently a discriminating between IPv6 PA und PI = address space, but the conculsion should be changeing the policy for the = PA address space and not offering PI address space without technical = requirements. that might be a rather shortsighted and possibly dangerous view on the = matter. Because instead of just getting a PI prefix which you as clueful ISP = will inject in the DFZ, this just leads to most of them asking for a happy-meal including an ASN and = you have to deal with another unmaintained and possibly unstable AS in the DFZ because they just pay a = consultant once to set up BGP on their router and the Tunnel to he.net as a 2nd Upstream for = free and never care about it anymore. Or worse, they do it themselves with help from their = favorite search-engine *shudder*. ...just my 0.01 EUR And yes i don't understand the whining about the requirement anyways. It's easy to circumvent. So it's not at all doing anything good at all. (I indeed support the proposal for various non-technical reasons. If things with PI vs. PA might change anyways in the foreseeable future, = this=20 IPv4 vs. IPv6 PI policy distinction is doing nothing but hinder the desperately needed widespread IPv6 deployment at = the very moment. One has to set the right priorities here.) --=20 Mit freundlichen Gr=FC=DFen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect --__--__-- Message: 3 Subject: FW: [address-policy-wg] Removal of multihomed requirement for IPv6 Date: Fri, 13 May 2011 12:44:42 +0400 From: To: Hello, I do not support this proposal. We are speaking about real possibilities = and real impact. The proposers doesn't know exactly the impact of the = changes and are deaf to the other people pointing to the real troubles = relating the grooving number of prefixes. Their na=EFve assumptions = about cheap BGP routers show their inability to broader the mind just = outside their small nets needs. Technical requirements should be the = only way of making decisions. If someone has tendency to lie - it would lie anyway - one thing or = another. Regards, Vladislav Potapov Ru.iiat --__--__-- Message: 4 Reply-To: thabet at gmail.com Subject: Re: [address-policy-wg] Removal of multihomed requirement for IPv6 To: poty at iiat.ru,address-policy-wg-admin at ripe.net,address-policy-wg at ripe.net From: thabet at gmail.com Date: Fri, 13 May 2011 08:47:20 +0000 SSBhZ3JlZSB3aXRoIFZsYWRpc2xhdiBQb3RhcG92DQoNCg0KU2VudCBmcm9tIG15IEJsYWNrQmVy cnmuIHNtYXJ0cGhvbmUgZnJvbSBkdQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogPHBvdHlAaWlhdC5ydT4NClNlbmRlcjogYWRkcmVzcy1wb2xpY3ktd2ctYWRtaW5AcmlwZS5u ZXQNCkRhdGU6IEZyaSwgMTMgTWF5IDIwMTEgMTI6NDQ6NDIgDQpUbzogPGFkZHJlc3MtcG9saWN5 LXdnQHJpcGUubmV0Pg0KU3ViamVjdDogRlc6IFthZGRyZXNzLXBvbGljeS13Z10gUmVtb3ZhbCBv ZiBtdWx0aWhvbWVkIHJlcXVpcmVtZW50IGZvciBJUHY2DQoNCkhlbGxvLA0KSSBkbyBub3Qgc3Vw cG9ydCB0aGlzIHByb3Bvc2FsLiBXZSBhcmUgc3BlYWtpbmcgYWJvdXQgcmVhbCBwb3NzaWJpbGl0 aWVzIGFuZCByZWFsIGltcGFjdC4gVGhlIHByb3Bvc2VycyBkb2Vzbid0IGtub3cgZXhhY3RseSB0 aGUgaW1wYWN0IG9mIHRoZSBjaGFuZ2VzIGFuZCBhcmUgZGVhZiB0byB0aGUgb3RoZXIgcGVvcGxl IHBvaW50aW5nIHRvIHRoZSByZWFsIHRyb3VibGVzIHJlbGF0aW5nIHRoZSBncm9vdmluZyBudW1i ZXIgb2YgcHJlZml4ZXMuIFRoZWlyIG5h73ZlIGFzc3VtcHRpb25zIGFib3V0IGNoZWFwIEJHUCBy b3V0ZXJzIHNob3cgdGhlaXIgaW5hYmlsaXR5IHRvIGJyb2FkZXIgdGhlIG1pbmQganVzdCBvdXRz aWRlIHRoZWlyIHNtYWxsIG5ldHMgbmVlZHMuIFRlY2huaWNhbCByZXF1aXJlbWVudHMgc2hvdWxk IGJlIHRoZSBvbmx5IHdheSBvZiBtYWtpbmcgZGVjaXNpb25zLg0KSWYgc29tZW9uZSBoYXMgdGVu ZGVuY3kgdG8gbGllIC0gaXQgd291bGQgbGllIGFueXdheSAtIG9uZSB0aGluZyBvciBhbm90aGVy Lg0KDQpSZWdhcmRzLA0KVmxhZGlzbGF2IFBvdGFwb3YNClJ1LmlpYXQNCg0K End of address-policy-wg Digest From gert at space.net Fri May 13 18:13:27 2011 From: gert at space.net (Gert Doering) Date: Fri, 13 May 2011 18:13:27 +0200 Subject: [address-policy-wg] minutes from RIPE 61 Message-ID: <20110513161327.GP52064@Space.Net> Hi APWG, since there were no more comments, we have declared the minutes from RIPE 61 (Rome) to be final. The minutes can be found here: https://www.ripe.net/ripe/apwg/minutes61 Gert Doering -- NetMaster -- 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 a.baghir at mobily.com.sa Mon May 16 08:40:19 2011 From: a.baghir at mobily.com.sa (Adil H. Baghir) Date: Mon, 16 May 2011 09:40:19 +0300 Subject: [address-policy-wg] PP - 2011-02 - Removal of multihomed requirement for IPv6 Message-ID: <5C0C794DC4117644AE7580F2C58A88BF0982C20D9A@RUH-003-MX-002.prod.mobily.lan> Hi, I highly support the policy... Adil H. Baghir Internet Development Chief Engineer Data & Solutions Planning and Design P.O.Box 69179 Riyadh 11423 Kingdom of Saudi Arabia Tel: +966 56 031 3263 Fax: +966 56 041 3263 Mobile: +966 542 33 66 00 eMail: a.baghir at mobily.com.sa [cid:image001.jpg at 01CC13AD.44C394C0] ------Disclaimer------ This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2445 bytes Desc: image001.jpg URL: From emadaio at ripe.net Fri May 20 12:11:00 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 20 May 2011 12:11:00 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) Message-ID: <20110520101101.8CA456A005@postboy.ripe.net> Dear Colleagues, A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-03/ We encourage you to review this proposal and send your comments to before 17 June 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From stolpe at resilans.se Fri May 20 13:15:15 2011 From: stolpe at resilans.se (Daniel Stolpe) Date: Fri, 20 May 2011 13:15:15 +0200 (CEST) Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: When every LIR has had their /22, there might still be address space available, right? I interpret 1 a and b as we will have a deadlock then because the same LIR can never receive another allocation. On Fri, 20 May 2011, Emilio Madaio wrote: > > Dear Colleagues, > > A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ > > We encourage you to review this proposal and send your comments to > before 17 June 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From gert at space.net Fri May 20 13:29:00 2011 From: gert at space.net (Gert Doering) Date: Fri, 20 May 2011 13:29:00 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: <20110520112900.GE45955@Space.Net> Hi, On Fri, May 20, 2011 at 01:15:15PM +0200, Daniel Stolpe wrote: > When every LIR has had their /22, there might still be address space > available, right? I interpret 1 a and b as we will have a deadlock > then because the same LIR can never receive another allocation. Well... - this is the whole *point* of the "last /8" policy - to give people that want to start a business "with Internet things!" a few years in the future the chance to get a few IPv4 addresses to run their NAT64 boxes (and whatever other migration technologies need IPv4 addresses) on. (IPv4 will still run out, though, and nothing we can do will change that). - and this part is not being discussed at all by the policy proposal here - this is to clarify that the "last /8" policy will *stay* in effect after it became active, even if some address space is returned and the NCC ends up having again more than a /8 available. While this interpretation is in line with the current policy documents, it's not explicitely written in the documents, and this proposal attempts to clarify this. 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 Remco.vanMook at eu.equinix.com Fri May 20 15:15:05 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Fri, 20 May 2011 14:15:05 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: Unsurprisingly, as the author I fully support this policy proposal and I would for the sake of the PDP encourage others to voice their agreement as well - no response means no progress. Best, Remco van Mook Senior Technical Architect, Europe remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 20-05-11 12:11, "Emilio Madaio" wrote: > >Dear Colleagues, > >A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation >and Assignment Policy for the RIPE NCC Service Region", is now >available for discussion. > > >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ > >We encourage you to review this proposal and send your comments to > before 17 June 2011. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > 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 boggits at gmail.com Fri May 20 15:20:19 2011 From: boggits at gmail.com (boggits) Date: Fri, 20 May 2011 14:20:19 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: On 20 May 2011 14:15, Remco Van Mook wrote: > > Unsurprisingly, as the author I fully support this policy proposal and I > would for the sake of the PDP encourage others to voice their agreement as > well - no response means no progress. I also support the proposal, my only thought would be if it might be better to use this change to make an overwrite of the 'current process' at the point of the first allocation of a /22 from the last /8 for the purpose of the avoidance of doubt... J -- James Blessing 07989 039 476 -- James Blessing 07989 039 476 From marcin at leon.pl Sun May 22 16:33:37 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Sun, 22 May 2011 16:33:37 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520112900.GE45955@Space.Net> References: <20110520101101.8CA456A005@postboy.ripe.net> <20110520112900.GE45955@Space.Net> Message-ID: <4DD91EC1.8060704@leon.pl> Gert Doering wrote: > Hi, > > On Fri, May 20, 2011 at 01:15:15PM +0200, Daniel Stolpe wrote: >> When every LIR has had their /22, there might still be address space >> available, right? I interpret 1 a and b as we will have a deadlock >> then because the same LIR can never receive another allocation. > > Well... > > - this is the whole *point* of the "last /8" policy - to give people that > want to start a business "with Internet things!" a few years in the > future the chance to get a few IPv4 addresses to run their NAT64 boxes > (and whatever other migration technologies need IPv4 addresses) on. > > (IPv4 will still run out, though, and nothing we can do will change that). well, how about opening new LIR, getting IPv6 + IPv4 and merging that LIR with other LIR... Then the OTHER LIR will have more than single /22 from the last /8.... Regards, Marcin From roger at jorgensen.no Sat May 21 10:58:36 2011 From: roger at jorgensen.no (Roger =?iso-8859-1?Q?J=F8rgensen?=) Date: Sat, 21 May 2011 10:58:36 +0200 (CEST) Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: <59161.193.71.255.83.1305968316.squirrel@mail.e-konsult.no> On fre, mai 20, 2011 12:11, Emilio Madaio wrote: > > Dear Colleagues, > > A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ > Hmm are we really sure we want to have this part in here? "This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself." I do see the point of it yes, but what if a huge block are returned, one that could go back to IANA and be reused for something that all can benefit from? ... and we have no idea what it can be since we can't predict the future. Do we change the policy again at that point or when thing change? other than that, support this policy. It do make it pretty clear on how IPv4 are handled in the near-comming future. -- --- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - The Future is IPv6 ------------------------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From rogerj at gmail.com Sun May 22 19:14:14 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Sun, 22 May 2011 19:14:14 +0200 Subject: Fwd: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <59161.193.71.255.83.1305968316.squirrel@mail.e-konsult.no> References: <20110520101101.8CA456A005@postboy.ripe.net> <59161.193.71.255.83.1305968316.squirrel@mail.e-konsult.no> Message-ID: On fre, mai 20, 2011 12:11, Emilio Madaio wrote: > > Dear Colleagues, > > A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > ? ? http://www.ripe.net/ripe/policies/proposals/2011-03/ > Hmm are we really sure we want to have this part in here? "This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself." I do see the point of it yes, but what if a huge block are returned, one that could go back to IANA and be reused for something that all can benefit from? ... and we have no idea what it can be since we can't predict the future. Do we change the policy again at that point or when thing change? other than that, support this policy. It do make it pretty clear on how IPv4 are handled in the near-comming future. -- --- ------------------------------ Roger Jorgensen ? ? ?| - ROJO9-RIPE ?- RJ85P-NORID roger at jorgensen.no ? ? ? ? ? | - The Future is IPv6 ------------------------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From Remco.vanMook at eu.equinix.com Sun May 22 22:25:26 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Sun, 22 May 2011 21:25:26 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: Message-ID: Hi Roger, The decision to give returned address space back to IANA is outside the scope of (this?) allocation policy. The text in this policy however explicitly leaves room for space to be returned to IANA, instead of just stating that any and all returned space MUST be placed into the "final /8 pool", which would have been a valid interpretation had the phrase you quote below not been present - that would block all options to return space to IANA, which would be bad to have in policy. Hence the 'the below is only valid for space we already decided is not going back to IANA'. Thank you for supporting the policy proposal. Best Remco On 22-05-11 19:14, "Roger J?rgensen" wrote: > >Hmm are we really sure we want to have this part in here? >"This section only applies to address space that is returned to the RIPE >NCC and that will not be returned to the IANA but re-issued by the RIPE >NCC itself." > >I do see the point of it yes, but what if a huge block are returned, one >that could go back to IANA and be reused for something that all can >benefit from? >... and we have no idea what it can be since we can't predict the future. > >Do we change the policy again at that point or when thing change? > > > >other than that, support this policy. It do make it pretty clear on how >IPv4 are handled in the near-comming future. > 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 rogerj at gmail.com Mon May 23 08:23:02 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 23 May 2011 08:23:02 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: Message-ID: On Sun, May 22, 2011 at 10:25 PM, Remco Van Mook wrote: > Hi Roger, > > The decision to give returned address space back to IANA is outside the > scope of (this?) allocation policy. The text in this policy however > explicitly leaves room for space to be returned to IANA, instead of just > stating that any and all returned space MUST be placed into the "final /8 > pool", which would have been a valid interpretation had the phrase you > quote below not been present - that would block all options to return > space to IANA, which would be bad to have in policy. > > Hence the 'the below is only valid for space we already decided is not > going back to IANA'. When I now re-reading the text again in the right context I see it. But if I'm the only one that missunderstood it I guess it's okay. -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From brian.nisbet at heanet.ie Mon May 23 10:53:16 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 23 May 2011 09:53:16 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: <4DDA207C.2040106@heanet.ie> "Emilio Madaio" wrote the following on 20/05/2011 11:11: > Dear Colleagues, > > A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. This is a necessary proposal, I certainly support it. Brian. From danny at danysek.cz Mon May 23 11:41:02 2011 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 23 May 2011 11:41:02 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: <4DDA2BAE.3040502@danysek.cz> Hello, one thing should be considered here - this proposal in section 3b states, that minimum allocation sizes for the relevant /8 blocks will be updated if necessary. There're a lot of ranges with /21 longest prefix now. Some people have filters in accordance to (currently) RIPE-510 document. This may be source of some operational troubles, if longest prefixes will be changed frequently - as filters will have to be updated in some networks. There's no such requirement these days (only new prefixes need to be added). I'll rather see no changes in terms of "allowing" longer prefixes in other subnets. Changes here will more likely help some people deaggregate their prefixes in global table and only few prefixes will be announced rightly. Aggregation should be one of major goals, and even RIPE cannot enforce it, it at least should help here (and RIPE-510 is helpfull). This proposal goes against this goal sometimes, I think. Last /8 provides quite huge number of /22 to cover future requests long-term. I think, that returned space should be reserved/used for covering potential request for more than 1024 IP addresses in one block - as we cannot imagine future these days, and someone can have good reasons to obtain larger address space... and if will be some addresses available, I don't see any reason to reject the request. Due similar reasons - I don't support section 4 of new proposal (multiple allocations up to an equivalent of a /22). This will also cause changes in RIPE-510 and this will simplify address space deaggregation for many "bad guys". So, instead of applying "last /8 policy" to returned space, reserving returned space as we have reserved /16 from last /8 seems to be better option for me (and potentially serve assignments like /21). Current policies used for reusing returned space are sufficient and these can be applied anytime. Last /8 should be applied ONLY to last /8. And aggregation should be always keeped in mind, when some change in address policy is proposed. I don't support this proposal and I suggest changes in it mentioned above. With regards, Daniel On 05/20/2011 12:11 PM, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ > > We encourage you to review this proposal and send your comments to > before 17 June 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > From gert at space.net Mon May 23 11:44:33 2011 From: gert at space.net (Gert Doering) Date: Mon, 23 May 2011 11:44:33 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DD91EC1.8060704@leon.pl> References: <20110520101101.8CA456A005@postboy.ripe.net> <20110520112900.GE45955@Space.Net> <4DD91EC1.8060704@leon.pl> Message-ID: <20110523094433.GN45955@Space.Net> Hi, On Sun, May 22, 2011 at 04:33:37PM +0200, Marcin Kuczera wrote: > > - this is the whole *point* of the "last /8" policy - to give people that > > want to start a business "with Internet things!" a few years in the > > future the chance to get a few IPv4 addresses to run their NAT64 boxes > > (and whatever other migration technologies need IPv4 addresses) on. > > > > (IPv4 will still run out, though, and nothing we can do will change that). > > well, > how about opening new LIR, getting IPv6 + IPv4 and merging that LIR with > other LIR... Then the OTHER LIR will have more than single /22 from the > last /8.... Yes, you can certainly do that. Or you can buy another company that has IPv4 addresses left. Both come with a certain price tag. Or you can deploy IPv6. At some point in time, spending heaps of money to get another small bit of IPv4 addresses is just not worth the effort anymore. And there is nothing in the address policy area that we can do to magically make IPv4 last forever. But this whole discussion is completely out of scope for the policy proposal at hand - it does not install a "last /8" policy (we already have that), just clarifies some conditions. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From Remco.vanMook at eu.equinix.com Mon May 23 12:01:45 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 23 May 2011 11:01:45 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA2BAE.3040502@danysek.cz> Message-ID: Hi Daniel, If you allow me to summarize: it is your opinion that the community is better off with the RIPE NCC not handing out address space it has available? I would have to politely disagree. I agree that aggregation is a concern as well as filtering, but given that we're appending this address space to the end of the final /8 in allocation terms, this space would only be (re)allocated after we've run out of the final /8; that is, after some 16,000 /22s have been handed out. What the default free zone will look like is anybody's guess, but I've got a pint saying that handing out /22s from other /8s is unlikely to make it a lot worse, even more so for the assorted snippets of address space that come after that. If people run filters based on RIPE documents (or any other source for that matter), they're well advised to have a procedure in place to keep those filters up to date. Best, Remco On 23-05-11 11:41, "Daniel Suchy" wrote: >Hello, >one thing should be considered here - this proposal in section 3b >states, that minimum allocation sizes for the relevant /8 blocks will be >updated if necessary. > >There're a lot of ranges with /21 longest prefix now. Some people have >filters in accordance to (currently) RIPE-510 document. This may be >source of some operational troubles, if longest prefixes will be changed >frequently - as filters will have to be updated in some networks. >There's no such requirement these days (only new prefixes need to be >added). > >I'll rather see no changes in terms of "allowing" longer prefixes in >other subnets. Changes here will more likely help some people >deaggregate their prefixes in global table and only few prefixes will be >announced rightly. Aggregation should be one of major goals, and even >RIPE cannot enforce it, it at least should help here (and RIPE-510 is >helpfull). This proposal goes against this goal sometimes, I think. > >Last /8 provides quite huge number of /22 to cover future requests >long-term. I think, that returned space should be reserved/used for >covering potential request for more than 1024 IP addresses in one block >- as we cannot imagine future these days, and someone can have good >reasons to obtain larger address space... and if will be some addresses >available, I don't see any reason to reject the request. > >Due similar reasons - I don't support section 4 of new proposal >(multiple allocations up to an equivalent of a /22). This will also >cause changes in RIPE-510 and this will simplify address space >deaggregation for many "bad guys". > >So, instead of applying "last /8 policy" to returned space, reserving >returned space as we have reserved /16 from last /8 seems to be better >option for me (and potentially serve assignments like /21). Current >policies used for reusing returned space are sufficient and these can be >applied anytime. > >Last /8 should be applied ONLY to last /8. And aggregation should be >always keeped in mind, when some change in address policy is proposed. > >I don't support this proposal and I suggest changes in it mentioned above. > >With regards, >Daniel > > >On 05/20/2011 12:11 PM, Emilio Madaio wrote: >> Dear Colleagues, >> >> A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation >> and Assignment Policy for the RIPE NCC Service Region", is now >> available for discussion. >> >> >> You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-03/ >> >> We encourage you to review this proposal and send your comments to >> before 17 June 2011. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> > 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 danny at danysek.cz Mon May 23 12:25:40 2011 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 23 May 2011 12:25:40 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: Message-ID: <4DDA3624.7050501@danysek.cz> On 05/23/2011 12:01 PM, Remco Van Mook wrote: > If you allow me to summarize: it is your opinion that the community is > better off with the RIPE NCC not handing out address space it has > available? I would have to politely disagree. RIPE NCC can handle returned address space in similar way, as it does today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE NCC can (=has other space than last /8)? Normal allocations with standard policy can be processed, instead of carving last /8. There're still other limitations in place - like 6/3month address plans etc. Reserve in last /8 is - in my oppinion - large enough. There's no reason to apply last /8 policy to other address space - this will really only hold available addresses in RIPE NCC without being really used (as last /8 policy is very restrictive). > I agree that aggregation is a concern as well as filtering, but given that > we're appending this address space to the end of the final /8 in > allocation terms, this space would only be (re)allocated after we've run > out of the final /8; that is, after some 16,000 /22s have been handed out. > What the default free zone will look like is anybody's guess, but I've got > a pint saying that handing out /22s from other /8s is unlikely to make it > a lot worse, even more so for the assorted snippets of address space that > come after that. Based on current numbers of current/new members of RIPE NCC, this will hapen sometimes after 12-18 years? If this will hapen really. In last /8, there's only one /22 per LIR, so it's quite easy calculation. Also I assume, that some LIRs will not apply for their last /22. > If people run filters based on RIPE documents (or any other source for > that matter), they're well advised to have a procedure in place to keep > those filters up to date. That's not argument for making these these things harder compared to current convetions. With regards, Daniel From Remco.vanMook at eu.equinix.com Mon May 23 13:34:55 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 23 May 2011 12:34:55 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA3624.7050501@danysek.cz> Message-ID: Hi Daniel, The beginning of article 5.6 in the current policy reads as follows (emphasis mine): "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space WILL ONLY BE DONE as follows:" This means the current allocation policy is out of the window at that point, and might as well not even exist. There is no point in time where the two separate pieces of allocation policy are both being executed. So, only a single /22 per LIR, no exceptions. This is the currently accepted final /8 policy. If you feel strongly about changing that, I would suggest you write a policy proposal. This proposal only means to clarify what happens to address space that is returned to the RIPE NCC after that point, and makes sure we have allocation policy in place for all the address space that the RIPE NCC holds. Having a policy in place that provides the ability to hand out all currently held address space, along with an upper limit that is lower than the most common minimum allocation size, will have an impact on the minimum allocation size for those blocks. If the chairs feel otherwise, and think this policy proposal means to re-evaluate the text of the current final /8 policy, I will withdraw it immediately, as is my discretion as the author. Best regards, Remco On 23-05-11 12:25, "Daniel Suchy" wrote: >On 05/23/2011 12:01 PM, Remco Van Mook wrote: >> If you allow me to summarize: it is your opinion that the community is >> better off with the RIPE NCC not handing out address space it has >> available? I would have to politely disagree. >RIPE NCC can handle returned address space in similar way, as it does >today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE >NCC can (=has other space than last /8)? Normal allocations with >standard policy can be processed, instead of carving last /8. There're >still other limitations in place - like 6/3month address plans etc. >Reserve in last /8 is - in my oppinion - large enough. There's no reason >to apply last /8 policy to other address space - this will really only >hold available addresses in RIPE NCC without being really used (as last >/8 policy is very restrictive). > >> I agree that aggregation is a concern as well as filtering, but given >>that >> we're appending this address space to the end of the final /8 in >> allocation terms, this space would only be (re)allocated after we've run >> out of the final /8; that is, after some 16,000 /22s have been handed >>out. >> What the default free zone will look like is anybody's guess, but I've >>got >> a pint saying that handing out /22s from other /8s is unlikely to make >>it >> a lot worse, even more so for the assorted snippets of address space >>that >> come after that. >Based on current numbers of current/new members of RIPE NCC, this will >hapen sometimes after 12-18 years? If this will hapen really. In last >/8, there's only one /22 per LIR, so it's quite easy calculation. Also I >assume, that some LIRs will not apply for their last /22. > >> If people run filters based on RIPE documents (or any other source for >> that matter), they're well advised to have a procedure in place to keep >> those filters up to date. >That's not argument for making these these things harder compared to >current convetions. > >With regards, >Daniel > 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 gert at space.net Mon May 23 13:43:33 2011 From: gert at space.net (Gert Doering) Date: Mon, 23 May 2011 13:43:33 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <4DDA3624.7050501@danysek.cz> Message-ID: <20110523114333.GS45955@Space.Net> Hi, On Mon, May 23, 2011 at 12:34:55PM +0100, Remco Van Mook wrote: > If the chairs feel otherwise, and think this policy proposal means to > re-evaluate the text of the current final /8 policy, I will withdraw it > immediately, as is my discretion as the author. I read your text as "clarification of the current policy documents, and not changing the existing last /8 policy". 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 Remco.vanMook at eu.equinix.com Mon May 23 13:47:16 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 23 May 2011 12:47:16 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110523114333.GS45955@Space.Net> Message-ID: Hi Gert, Thank you for clarifying :) Best, Remco On 23-05-11 13:43, "Gert Doering" wrote: >I read your text as "clarification of the current policy documents, and >not >changing the existing last /8 policy". 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 gert at space.net Mon May 23 13:57:43 2011 From: gert at space.net (Gert Doering) Date: Mon, 23 May 2011 13:57:43 +0200 Subject: [address-policy-wg] getting second IPv6 PA as a LIR In-Reply-To: <20110504185008.GA47653@vaf-mac1.cisco.com> References: <20110503143143.GG30227@Space.Net> <20110504185008.GA47653@vaf-mac1.cisco.com> Message-ID: <20110523115743.GV45955@Space.Net> Hi, sorry for the slow response: On Wed, May 04, 2011 at 11:50:10AM -0700, Vince Fuller wrote: > > We'll have some "PI" in the global table, of course. But please look at > > Alex Le Heux' numbers that will be presented on Thursday morning (about > > 10:00) on what makes up the bulk of the current IPv4 routing table - and > > you might be surprised. > > Is this presentation available online somewhere for those who can't be in > Amsterdam this week and for whom the time of the prezo is not so convenient > to participate remotely? There doesn't appear to be any pointer to the > presentation material on the RIPE 62 meeting plan. Actually, when clicking on a working group's title, it should have showed you the agenda on the left side, and all the presentations on the right side. Now all the presentations are available in a central archive: http://ripe62.ripe.net/presentations/presentation-archive and specifically, Alex' presentation is here: http://ripe62.ripe.net/presentations/160-apwg.key (keynote only, pdf conversion will be provided later, as far as I understand) Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From boggits at gmail.com Mon May 23 13:43:09 2011 From: boggits at gmail.com (boggits) Date: Mon, 23 May 2011 12:43:09 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <4DDA3624.7050501@danysek.cz> Message-ID: On 23 May 2011 12:34, Remco Van Mook wrote: > This proposal only means to clarify what happens to address space that is > returned to the RIPE NCC after that point, and makes sure we have > allocation policy in place for all the address space that the RIPE NCC > holds. Having a policy in place that provides the ability to hand out all > currently held address space, along with an upper limit that is lower than > the most common minimum allocation size, will have an impact on the > minimum allocation size for those blocks. > > If the chairs feel otherwise, and think this policy proposal means to > re-evaluate the text of the current final /8 policy, I will withdraw it > immediately, as is my discretion as the author. Please do not withdraw the proposal (otherwise I will shamelessly resubmit it moments later) as I believe it acts as strong clarification of the way the process should work rather than adding any new policy J -- James Blessing 07989 039 476 From rhe at nosc.ja.net Mon May 23 14:07:53 2011 From: rhe at nosc.ja.net (Rob Evans) Date: Mon, 23 May 2011 13:07:53 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: <699F025C-5AC4-41DF-A2E2-A9F4C56EEB13@nosc.ja.net> > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ This is an important clarification, so support from here. Rob From david.freedman at uk.clara.net Mon May 23 14:17:40 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 23 May 2011 12:17:40 +0000 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <699F025C-5AC4-41DF-A2E2-A9F4C56EEB13@nosc.ja.net> References: <20110520101101.8CA456A005@postboy.ripe.net>,<699F025C-5AC4-41DF-A2E2-A9F4C56EEB13@nosc.ja.net> Message-ID: Support ________________________________________ From: address-policy-wg-admin at ripe.net [address-policy-wg-admin at ripe.net] on behalf of Rob Evans [rhe at nosc.ja.net] Sent: 23 May 2011 13:07 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ This is an important clarification, so support from here. Rob From stolpe at resilans.se Mon May 23 14:43:16 2011 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 23 May 2011 14:43:16 +0200 (CEST) Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA3624.7050501@danysek.cz> References: <4DDA3624.7050501@danysek.cz> Message-ID: On Mon, 23 May 2011, Daniel Suchy wrote: > On 05/23/2011 12:01 PM, Remco Van Mook wrote: >> If you allow me to summarize: it is your opinion that the community is >> better off with the RIPE NCC not handing out address space it has >> available? I would have to politely disagree. > RIPE NCC can handle returned address space in similar way, as it does > today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE > NCC can (=has other space than last /8)? Normal allocations with > standard policy can be processed, instead of carving last /8. There're > still other limitations in place - like 6/3month address plans etc. > Reserve in last /8 is - in my oppinion - large enough. There's no reason > to apply last /8 policy to other address space - this will really only > hold available addresses in RIPE NCC without being really used (as last > /8 policy is very restrictive). > >> I agree that aggregation is a concern as well as filtering, but given that >> we're appending this address space to the end of the final /8 in >> allocation terms, this space would only be (re)allocated after we've run >> out of the final /8; that is, after some 16,000 /22s have been handed out. >> What the default free zone will look like is anybody's guess, but I've got >> a pint saying that handing out /22s from other /8s is unlikely to make it >> a lot worse, even more so for the assorted snippets of address space that >> come after that. > Based on current numbers of current/new members of RIPE NCC, this will > hapen sometimes after 12-18 years? If this will hapen really. In last > /8, there's only one /22 per LIR, so it's quite easy calculation. Also I > assume, that some LIRs will not apply for their last /22. > >> If people run filters based on RIPE documents (or any other source for >> that matter), they're well advised to have a procedure in place to keep >> those filters up to date. > That's not argument for making these these things harder compared to > current convetions. I guess this depends on what we want to happen. If we think it's about time to "act now" on IPv6 this is probably the right thing. As I wrote earlier, once we enter the "final /8 stage" any remaning and/or returned IPv4 space will be locked. That means it will be complete meningless to return any space to the RIPE NCC and we will surely see quite a bit of black market tradning instead. So Daniel has got a point but as Gert pointed out it might be outside the scope of this proposal. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From danny at danysek.cz Mon May 23 14:47:06 2011 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 23 May 2011 14:47:06 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: Message-ID: <4DDA574A.1010500@danysek.cz> I don't want to change policy for last /8, and I aggree with it. Current policy can be read by several ways. We're just playing with words - current policy doesn't force making single /22 allocations from other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to allocate something from 185.0.0.0/8, you can do only do this and this..." in my eyes. Section 5.6 talks just about the last /8 and this is quite clear description. Last /8 is single address block. If some address space is returned, then I don't see any reasonable argument, why not (re)allocate more than /22 to someone else, if someone needs new addresses and meets other criteria. Final decision is still on RIPE NCC - and I think they can better analyse particular case in time of real occurrence - compared to general "what-if" proposals. Maybe we can serve only new LIRs in that case, that's limitation which should be accepted - that's question. This will make startups easier - well, IPv6 is solution, but until will be IPv6 adopted by large networks/content providers having large IPv4 allocations already - these aren't under pressure, if we're talking about IPv6 migration. Even small starting ISPs will need IPv4... why restrict allocations to new networks, if there's space other than from last /8 available? Just because they came too late...? This kind of restriction/regulation will more likely support grey market - people will be trying other ways to "sell" their existing allocations to someone, who needs them (and of course, they'll find policy-conforming way). Reserve in last /8 is quite enough to cover future requirements for very long term and there's no need to block address usage in other /8 managed by RIPE NCC. Your proposal simply creates additional blocked and efectivelly unused address space in other /8 just due to the policy. RIPE NCC is here for address distribution to end users. I'm just using arguments of Remco now - addresses should be used, not reserved for something surreal. Daniel On 05/23/2011 01:34 PM, Remco Van Mook wrote: > Hi Daniel, > > The beginning of article 5.6 in the current policy reads as follows > (emphasis mine): > > "The following policies come into effect as soon as RIPE NCC is required > to make allocations from the final /8 it receives from the IANA. From then > on the distribution of IPv4 address space WILL ONLY BE DONE as follows:" > > > This means the current allocation policy is out of the window at that > point, and might as well not even exist. There is no point in time where > the two separate pieces of allocation policy are both being executed. So, > only a single /22 per LIR, no exceptions. This is the currently accepted > final /8 policy. If you feel strongly about changing that, I would suggest > you write a policy proposal. > > This proposal only means to clarify what happens to address space that is > returned to the RIPE NCC after that point, and makes sure we have > allocation policy in place for all the address space that the RIPE NCC > holds. Having a policy in place that provides the ability to hand out all > currently held address space, along with an upper limit that is lower than > the most common minimum allocation size, will have an impact on the > minimum allocation size for those blocks. > > If the chairs feel otherwise, and think this policy proposal means to > re-evaluate the text of the current final /8 policy, I will withdraw it > immediately, as is my discretion as the author. > > > Best regards, > > Remco > > On 23-05-11 12:25, "Daniel Suchy" wrote: > >> On 05/23/2011 12:01 PM, Remco Van Mook wrote: >>> If you allow me to summarize: it is your opinion that the community is >>> better off with the RIPE NCC not handing out address space it has >>> available? I would have to politely disagree. >> RIPE NCC can handle returned address space in similar way, as it does >> today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE >> NCC can (=has other space than last /8)? Normal allocations with >> standard policy can be processed, instead of carving last /8. There're >> still other limitations in place - like 6/3month address plans etc. >> Reserve in last /8 is - in my oppinion - large enough. There's no reason >> to apply last /8 policy to other address space - this will really only >> hold available addresses in RIPE NCC without being really used (as last >> /8 policy is very restrictive). >> >>> I agree that aggregation is a concern as well as filtering, but given >>> that >>> we're appending this address space to the end of the final /8 in >>> allocation terms, this space would only be (re)allocated after we've run >>> out of the final /8; that is, after some 16,000 /22s have been handed >>> out. >>> What the default free zone will look like is anybody's guess, but I've >>> got >>> a pint saying that handing out /22s from other /8s is unlikely to make >>> it >>> a lot worse, even more so for the assorted snippets of address space >>> that >>> come after that. >> Based on current numbers of current/new members of RIPE NCC, this will >> hapen sometimes after 12-18 years? If this will hapen really. In last >> /8, there's only one /22 per LIR, so it's quite easy calculation. Also I >> assume, that some LIRs will not apply for their last /22. >> >>> If people run filters based on RIPE documents (or any other source for >>> that matter), they're well advised to have a procedure in place to keep >>> those filters up to date. >> That's not argument for making these these things harder compared to >> current convetions. >> >> With regards, >> Daniel >> > > > > 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 gert at space.net Mon May 23 14:54:40 2011 From: gert at space.net (Gert Doering) Date: Mon, 23 May 2011 14:54:40 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <4DDA3624.7050501@danysek.cz> Message-ID: <20110523125440.GZ45955@Space.Net> Hi, On Mon, May 23, 2011 at 02:43:16PM +0200, Daniel Stolpe wrote: > I guess this depends on what we want to happen. If we think it's about > time to "act now" on IPv6 this is probably the right thing. As I wrote > earlier, once we enter the "final /8 stage" any remaning and/or returned > IPv4 space will be locked. That means it will be complete meningless to > return any space to the RIPE NCC and we will surely see quite a bit of > black market tradning instead. Thanks for the clarification - yes, this could be one of the possible side effects. On the other hand, it is not completely unreasonable to assume that "returning to the RIPE NCC for free" is not going to happen as long as there is paying customers to receive the address space - and if there is no longer a market, there might not be that much demand from the RIPE NCC either... I don't know what the future brings regarding IPv4 - but I can only strongly urge everybody to accept the fact that the IPv4 supply at all RIRs is running out, and investigate alternatives. > So Daniel has got a point but as Gert pointed out it might be outside the > scope of this proposal. Well. The current "last /8" policy does not really take this situation into account, and so the RIPE NCC decided how to handle that situation *should* it happen (by not going back to the old policy). At the last meeting, there was no opposition against that interpretation of the policy, but it was felt that this should be written down, to make it very explicit - and this is what Remco is proposing. If we indeed want something else to happen, a new policy proposal should be brought forward to actually change the current text to make it only apply to "addresses specifically from the last /8" - but beware, this will cause more unhappiness, and more concerns about *unfairness*. Just assume that someone generous will return a /16, and there are 5 large DSL or cable ISPs that all can document a need for at least a /12 in the next 3 months... ... so who will get the /16? What about the 20 smaller ISPs that only want a /20 each? As soon as we're down to managing the scraps, *any* policy is likely to cause major feelings of unfairness... 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 sander at steffann.nl Mon May 23 15:10:14 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 23 May 2011 15:10:14 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA574A.1010500@danysek.cz> References: <4DDA574A.1010500@danysek.cz> Message-ID: Hi Daniel, > Current policy can be read by several ways. We're just playing with > words - current policy doesn't force making single /22 allocations from > other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to > allocate something from 185.0.0.0/8, you can do only do this and > this..." in my eyes. Section 5.6 talks just about the last /8 and this > is quite clear description. Last /8 is single address block. That is not what it says. The text is: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:" It says, 'the distribution of IPv4 address space' in general. Once the RIPE NCC has to allocate addresses from the last /8, then from that point in time the distribution "will only be done as follows", which is specified in the "1. Allocations for LIRs from the last /8" and "2. Unforeseen circumstances" sections. The text is pretty clear that I think. > If some address space is returned, then I don't see any reasonable > argument, why not (re)allocate more than /22 to someone else, if someone > needs new addresses and meets other criteria. Because the current policy specifies that this is not possible. That can be changed by proposing a different policy of course. > Final decision is still on RIPE NCC The RIPE NCC can only decide what we (the community) tell them to decide. They follow the policies we set here on this mailing list. Thanks, Sander From danny at danysek.cz Mon May 23 17:15:33 2011 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 23 May 2011 17:15:33 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <4DDA574A.1010500@danysek.cz> Message-ID: <4DDA7A15.1010901@danysek.cz> Hi, On 05/23/2011 03:10 PM, Sander Steffann wrote: >> Current policy can be read by several ways. We're just playing with >> words - current policy doesn't force making single /22 allocations from >> other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to >> allocate something from 185.0.0.0/8, you can do only do this and >> this..." in my eyes. Section 5.6 talks just about the last /8 and this >> is quite clear description. Last /8 is single address block. > > That is not what it says. The text is: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:" > > It says, 'the distribution of IPv4 address space' in general. Once the RIPE NCC has to allocate addresses from the last /8, then from that point in time the distribution "will only be done as follows", which is specified in the "1. Allocations for LIRs from the last /8" and "2. Unforeseen circumstances" sections. The text is pretty clear that I think. Article name is: "Use of last /8 for PA Allocations" - that doesn't mean other /8... it's all only about last /8. >> If some address space is returned, then I don't see any reasonable >> argument, why not (re)allocate more than /22 to someone else, if someone >> needs new addresses and meets other criteria. > > Because the current policy specifies that this is not possible. That can be changed by proposing a different policy of course. Current policy keeps this question open. And new proposal is similar - if some article is named "use of last /8" (5.6), it cannot influence other /8's - or this article name doesn't make sense. Last /8 is only one and policy had to be clear. >> Final decision is still on RIPE NCC > > The RIPE NCC can only decide what we (the community) tell them to decide. They follow the policies we set here on this mailing list. And I don't see any argument, why tie RIPE NCC hands by applying this policy to other /8's. Current procedures can be used without any problem anytime - even in future on returned address space. If no addresses are available except last /8, allocations are simply proceeded in accordance to section 5.6, if there's some other address space available, standard procedure can be applied. Daniel From sander at steffann.nl Mon May 23 17:37:09 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 23 May 2011 17:37:09 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA7A15.1010901@danysek.cz> References: <4DDA574A.1010500@danysek.cz> <4DDA7A15.1010901@danysek.cz> Message-ID: <76B9E4CA-27D2-4EE5-8516-E070046F1775@steffann.nl> Hi Daniel, >> It says, 'the distribution of IPv4 address space' in general. Once the RIPE NCC has to allocate addresses from the last /8, then from that point in time the distribution "will only be done as follows", which is specified in the "1. Allocations for LIRs from the last /8" and "2. Unforeseen circumstances" sections. The text is pretty clear that I think. > > Article name is: "Use of last /8 for PA Allocations" > - that doesn't mean other /8... it's all only about last /8. No it isn't. It's about what happens when we reach the last /8. Sander From danny at danysek.cz Mon May 23 18:06:28 2011 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 23 May 2011 18:06:28 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA8208.10906@banknet.net> References: <4DDA574A.1010500@danysek.cz> <4DDA7A15.1010901@danysek.cz> <4DDA8208.10906@banknet.net> Message-ID: <4DDA8604.8080008@danysek.cz> Hi, On 05/23/2011 05:49 PM, Janos Zsako wrote: > I am afraid the text of ripe-509 is very clear: > > "The following policies come into effect as soon as RIPE NCC is required > to make > allocations from the final /8 it receives from the IANA. > From then on the distribution of IPv4 address space will only be done > as follows:" Then article name isn't clear. As it doesn't apply these days, it doesn't matter, but in future this may confuse someone, as last /8 is only one. > I personally do not think it would be wise to allocate returned addresses > in accordance with policies applicable before the last /8, if we already > started to allocate from the last /8 (i.e. I do not think it would be wise > to have two sets of policies, both live at the same time, one applicable to > the last /8 and an other one to the returned address space). >From database point of view, there will be two sets of policies on single /8 - in future on all except 185.0.0.0/8 (the last one). One "historic" (for allocations made before some not-yet-known date) and some "current" for new allocations after that magic date - with real influence to RIPE-510 (operational impact I mentioned already). Current system is very clear in terms of each new /8 usage, proposed change will introduce new uncertainty to other exising /8. Daniel From zsako at banknet.net Mon May 23 17:49:28 2011 From: zsako at banknet.net (Janos Zsako) Date: Mon, 23 May 2011 17:49:28 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA7A15.1010901@danysek.cz> References: <4DDA574A.1010500@danysek.cz> <4DDA7A15.1010901@danysek.cz> Message-ID: <4DDA8208.10906@banknet.net> Dear Daniel, > On 05/23/2011 03:10 PM, Sander Steffann wrote: >>> Current policy can be read by several ways. We're just playing with >>> words - current policy doesn't force making single /22 allocations from >>> other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to >>> allocate something from 185.0.0.0/8, you can do only do this and >>> this..." in my eyes. Section 5.6 talks just about the last /8 and this >>> is quite clear description. Last /8 is single address block. >> That is not what it says. The text is: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:" >> >> It says, 'the distribution of IPv4 address space' in general. Once the RIPE NCC has to allocate addresses from the last /8, then from that point in time the distribution "will only be done as follows", which is specified in the "1. Allocations for LIRs from the last /8" and "2. Unforeseen circumstances" sections. The text is pretty clear that I think. > > Article name is: "Use of last /8 for PA Allocations" > - that doesn't mean other /8... it's all only about last /8. I am afraid the text of ripe-509 is very clear: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:" This says two things: 1. These policies do not have to be applied as long as the RIPE NCC has other available addresses than the last /8 2. Once these policies have been triggered, there is no way back (see "From then on..."). > And I don't see any argument, why tie RIPE NCC hands by applying this > policy to other /8's. Current procedures can be used without any problem > anytime - even in future on returned address space. If no addresses are > available except last /8, allocations are simply proceeded in accordance > to section 5.6, if there's some other address space available, standard > procedure can be applied. The current policies do not allow this. You may want to submit a new proposal. I personally do not think it would be wise to allocate returned addresses in accordance with policies applicable before the last /8, if we already started to allocate from the last /8 (i.e. I do not think it would be wise to have two sets of policies, both live at the same time, one applicable to the last /8 and an other one to the returned address space). For the record, I support the "Post-depletion IPv4 address recycling" policy. Best regards, Janos From gert at space.net Mon May 23 18:43:59 2011 From: gert at space.net (Gert Doering) Date: Mon, 23 May 2011 18:43:59 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA8604.8080008@danysek.cz> References: <4DDA574A.1010500@danysek.cz> <4DDA7A15.1010901@danysek.cz> <4DDA8208.10906@banknet.net> <4DDA8604.8080008@danysek.cz> Message-ID: <20110523164359.GT45955@Space.Net> Hi, On Mon, May 23, 2011 at 06:06:28PM +0200, Daniel Suchy wrote: > Then article name isn't clear. As it doesn't apply these days, it > doesn't matter, but in future this may confuse someone, as last /8 is > only one. To clear up this confusion, we have the policy propsal 2011-03 (this one) on the table. That's the point. [..] > >From database point of view, there will be two sets of policies on > single /8 - in future on all except 185.0.0.0/8 (the last one). One > "historic" (for allocations made before some not-yet-known date) and > some "current" for new allocations after that magic date - with real > influence to RIPE-510 (operational impact I mentioned already). Current > system is very clear in terms of each new /8 usage, proposed change will > introduce new uncertainty to other exising /8. minimum allocation sizes for certain /8 have changed in the past, for example when the minimum allocation size was reduced to a /21, and people have adapted their filters accordingly. 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 millnert at gmail.com Tue May 24 01:44:14 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 23 May 2011 19:44:14 -0400 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: Hi! On Fri, May 20, 2011 at 6:11 AM, Emilio Madaio wrote: > ? ?http://www.ripe.net/ripe/policies/proposals/2011-03/ I support this proposal, provided I see satisfactory clarifications according to the below. :) 1) I note that the proposal specifically does not address transfers between entities under contract with the RIPE NCC. Am I correct in concluding the above and following? That this proposal does not affect or impede the transfer of an IPv4 resource from entity X to Y, while keeping the RIPE registry accurate, in any way? This is a strong and vital function of RIPE NCC's registry function as we go into the darkness IMO. I.e.., that this only addresses resource holders who specifically chooses to return resources to the RIPE NCC without any other party involved? While I cannot support a policy proposal which would damage the RIPE NCC registry in such a way, I don't think this is the intention, but I'd like to make it dead certain! 2) I'd also like a clarification regarding clause 3b: "b. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary." Updated to what? It is not explicitly defined. Is this intentional or not? I see two ways to read this: a) The policy proposal intends to declare that address blocks returned to RIPE that are to be handed out according to LIR's without such an assignment according to clause 1 (in other words, assignments by way of clause 3a), shall have the same fixed assignment size as those in clause 1, i.e. that of a /22. b) The policy proposal intends to declare that the fixed assignment size, /22, in clause 1 can "be updated if necessary", i.e be changed to something else, likely/presumably longer? Either is fine with me, but I think it's a bit too ambiguous right now. Thank you, Regards, Martin From rogerj at gmail.com Tue May 24 08:13:54 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Tue, 24 May 2011 08:13:54 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDA574A.1010500@danysek.cz> References: <4DDA574A.1010500@danysek.cz> Message-ID: On Mon, May 23, 2011 at 2:47 PM, Daniel Suchy wrote: > > Reserve in last /8 is quite enough to cover future requirements for very > long term and there's no need to block address usage in other /8 managed > by RIPE NCC. Your proposal simply creates additional blocked and > efectivelly unused address space in other /8 just due to the policy. > RIPE NCC is here for address distribution to end users. I'm just using > arguments of Remco now - addresses should be used, not reserved for > something surreal. I think you might missed the same fine point I did... RIPE NCC can still return addresses to IANA and those addresses will not fall in under the /8 rule? -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From andreas at schachtner.eu Tue May 24 09:17:56 2011 From: andreas at schachtner.eu (Andreas Schachtner) Date: Tue, 24 May 2011 09:17:56 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: <4DDA574A.1010500@danysek.cz> Message-ID: <20110524091756.48339ff9@foohome.schachtner.eu> Am Tue, 24 May 2011 08:13:54 +0200 schrieb Roger J?rgensen : > On Mon, May 23, 2011 at 2:47 PM, Daniel Suchy > wrote: > ... > > I think you might missed the same fine point I did... RIPE NCC can > still return addresses to IANA and those addresses will not fall in > under the /8 rule? If IANA in such a case redistributes resources to the RIR, e.g. RIPE NCC, they will fall under the /8 policy as it is right now. BTW, I do support the proposal. Regards, Andreas -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund From marcin at leon.pl Tue May 24 09:21:27 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 24 May 2011 09:21:27 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110523125440.GZ45955@Space.Net> References: <4DDA3624.7050501@danysek.cz> <20110523125440.GZ45955@Space.Net> Message-ID: <4DDB5C77.9030207@leon.pl> > As soon as we're down to managing the scraps, *any* policy is likely to > cause major feelings of unfairness... right, however, if it touches returned all address space kind (PI/PA) and we don't really know what is going to happen - maybe it is reasonable to postopne the policy start point to let's say - 50 or 60% of last /8 usage ? Regards, Marcin From wolfgang.tremmel at de-cix.net Tue May 24 09:42:15 2011 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Tue, 24 May 2011 09:42:15 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDB5C77.9030207@leon.pl> References: <4DDA3624.7050501@danysek.cz> <20110523125440.GZ45955@Space.Net> <4DDB5C77.9030207@leon.pl> Message-ID: <4DDB6157.3010208@de-cix.net> On 24.05.11 09:21, Marcin Kuczera wrote: > however, if it touches returned all address space kind (PI/PA) and we don't > really know what is going to happen - maybe it is reasonable to postopne > the policy start point to let's say - 50 or 60% of last /8 usage ? > what "problem" should postponing solve? I support the proposal like it is. best regards, Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.tremmel at de-cix.net DE-CIX Management GmbH Phone: +49 69 1730 902-26 Lindleystr. 12, 60314 Frankfurt Mobile: +49 171 8600 816 Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln From marcin at leon.pl Tue May 24 09:57:34 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 24 May 2011 09:57:34 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDB6157.3010208@de-cix.net> References: <4DDA3624.7050501@danysek.cz> <20110523125440.GZ45955@Space.Net> <4DDB5C77.9030207@leon.pl> <4DDB6157.3010208@de-cix.net> Message-ID: <4DDB64EE.7060908@leon.pl> Wolfgang Tremmel wrote: > On 24.05.11 09:21, Marcin Kuczera wrote: > >> however, if it touches returned all address space kind (PI/PA) and we don't >> really know what is going to happen - maybe it is reasonable to postopne >> the policy start point to let's say - 50 or 60% of last /8 usage ? >> > > what "problem" should postponing solve? > I support the proposal like it is. i.e. if some company still need /24 PI for their purposes (non ISP company), after 2011-03 start, there will be no way to get PI any more (except from black market). Regards, Marcin From Remco.vanMook at eu.equinix.com Tue May 24 10:20:18 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Tue, 24 May 2011 09:20:18 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: Message-ID: Hi Martin, I'll try to answer the points you raised below: 1. This proposal does not impact transfer at all. Addresses that get transferred are at no point in that process 'returned to the RIPE NCC'. 2. It's not explicitly defined because it all depends on the address space returned. As I already indicated in another email, the long term effect of this is likely to be that all /8s managed by the RIPE NCC will have a minimum allocation size of a /22; and if we then run out of /22s or larger and need to hand out multiple smaller blocks (moving to clause 4) a few additional /8s might get *really* unlucky. But that will only happen when we're scraping the RIPE NCC barrel. Best regards, Remco On 24-05-11 01:44, "Martin Millnert" wrote: >Hi! > >On Fri, May 20, 2011 at 6:11 AM, Emilio Madaio wrote: >> http://www.ripe.net/ripe/policies/proposals/2011-03/ > >I support this proposal, provided I see satisfactory clarifications >according to the below. :) > >1) I note that the proposal specifically does not address transfers >between entities under contract with the RIPE NCC. >Am I correct in concluding the above and following? That this >proposal does not affect or impede the transfer of an IPv4 resource >from entity X to Y, while keeping the RIPE registry accurate, in any >way? This is a strong and vital function of RIPE NCC's registry >function as we go into the darkness IMO. I.e.., that this only >addresses resource holders who specifically chooses to return >resources to the RIPE NCC without any other party involved? While I >cannot support a policy proposal which would damage the RIPE NCC >registry in such a way, I don't think this is the intention, but I'd >like to make it dead certain! > >2) I'd also like a clarification regarding clause 3b: >"b. Minimum allocation sizes for the relevant /8 blocks will be >updated if necessary." > >Updated to what? It is not explicitly defined. Is this intentional or >not? > >I see two ways to read this: >a) The policy proposal intends to declare that address blocks returned >to RIPE that are to be handed out according to LIR's without such an >assignment according to clause 1 (in other words, assignments by way >of clause 3a), shall have the same fixed assignment size as those in >clause 1, i.e. that of a /22. >b) The policy proposal intends to declare that the fixed assignment >size, /22, in clause 1 can "be updated if necessary", i.e be changed >to something else, likely/presumably longer? > >Either is fine with me, but I think it's a bit too ambiguous right now. > >Thank you, >Regards, >Martin > 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 sander at steffann.nl Tue May 24 10:33:25 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 24 May 2011 10:33:25 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: Message-ID: <86FA1F23-3A93-479F-8259-90BDEF2F1C43@steffann.nl> Hi, > 2. It's not explicitly defined because it all depends on the address space > returned. As I already indicated in another email, the long term effect of > this is likely to be that all /8s managed by the RIPE NCC will have a > minimum allocation size of a /22; and if we then run out of /22s or larger > and need to hand out multiple smaller blocks (moving to clause 4) a few > additional /8s might get *really* unlucky. But that will only happen when > we're scraping the RIPE NCC barrel. If we reach that point people can be glad they get *any* addresses. It's either this or no IPv4 addresses at all. They might hit prefix-length filters, but still, at least they have a chance to try something. - Sander From gert at space.net Tue May 24 11:21:15 2011 From: gert at space.net (Gert Doering) Date: Tue, 24 May 2011 11:21:15 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDB5C77.9030207@leon.pl> References: <4DDA3624.7050501@danysek.cz> <20110523125440.GZ45955@Space.Net> <4DDB5C77.9030207@leon.pl> Message-ID: <20110524092115.GV45955@Space.Net> Hi, On Tue, May 24, 2011 at 09:21:27AM +0200, Marcin Kuczera wrote: > > As soon as we're down to managing the scraps, *any* policy is likely to > > cause major feelings of unfairness... > > right, > however, if it touches returned all address space kind (PI/PA) and we > don't really know what is going to happen - maybe it is reasonable to > postopne the policy start point to let's say - 50 or 60% of last /8 usage ? This would be possible, but would be a very different policy proposal than the one on the table (and someone would need to come forward and specifically propose it). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From dave.wilson at heanet.ie Tue May 24 13:08:57 2011 From: dave.wilson at heanet.ie (Dave Wilson) Date: Tue, 24 May 2011 12:08:57 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4DDB64EE.7060908@leon.pl> References: <4DDA3624.7050501@danysek.cz> <20110523125440.GZ45955@Space.Net> <4DDB5C77.9030207@leon.pl> <4DDB6157.3010208@de-cix.net> <4DDB64EE.7060908@leon.pl> Message-ID: <4DDB91C9.9050902@heanet.ie> >>> however, if it touches returned all address space kind (PI/PA) and we >>> don't really know what is going to happen - maybe it is reasonable to postopne >>> the policy start point to let's say - 50 or 60% of last /8 usage ? >> >> what "problem" should postponing solve? >> I support the proposal like it is. > > i.e. if some company still need /24 PI for their purposes (non ISP > company), after 2011-03 start, there will be no way to get PI any more > (except from black market). Noting first that this eventuality will also occur if 2011-03 is not adopted. I think that this idea is in effect a no-op, because even if implementation of 2011-03 is postponed, any returned address space will still not be reallocated using old policies. I guess the intent of the suggestion though is to expand the scope of 2011-03 from one of clarification to one of reopening old allocation policies. Quite apart from the author's stated reluctance to expand the scope in any way, this would lead to a state, of unknown duration, where old allocation policies are attempted to be fulfilled with a run rate that is vastly smaller than demand, in parallel with the rationing procedures that are already set. This is a situation that is explicitly avoided both by the current wording of RIPE-509 and by the proposed changes of 2011-03. It is not a small change. What we have with RIPE-509, and what 2011-03 does not damage imo, is a plan to deal with runout in as clear and fair a manner as we can muster at this point. There is a moment at which the rules change for everyone; there is no question of some subsequently getting served with policies that cannot possibly be applied to all. We all feel the temptation to try to squeeze a little more out of the old way, to try to redistribute what scraps we can find in some manner that will stave off the consequences of runout for a few more people for a little longer. But we've already optimised pretty much all the slack we can out of this; any further changes must undermine clarity and fairness. We should resist the temptation to try to optimise to an infinitesimal degree for the sake of a few scraps. And, frankly, we should take every opportunity remaining to expand the meagre pool of IPv4 addresses we leave to our children. I support 2011-03 with the wording proposed by its author. Best regards, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From millnert at gmail.com Thu May 26 03:47:11 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 25 May 2011 21:47:11 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> References: <20110509192809.GA87495@cilantro.c4inet.net> <02F0C80D-B3E4-4DDB-BE5B-2C2889E11564@steffann.nl> <1CE76C0B-5622-44BD-AE0C-69A3D142D0BB@steffann.nl> Message-ID: Sander, On Mon, May 9, 2011 at 4:01 PM, Sander Steffann wrote: > As soon as laws don't allow 'your network, your rules' anymore then anything can happen... A follow-up: http://www.govtrack.us/congress/bill.xpd?bill=s112-968 A response: http://www.redbarn.org/files_redbarn/PROTECT-IP-Technical-Whitepaper-Final.pdf Regards, Martin From slz at baycix.de Thu May 26 08:38:16 2011 From: slz at baycix.de (Sascha Lenz) Date: Thu, 26 May 2011 08:38:16 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <20110520101101.8CA456A005@postboy.ripe.net> References: <20110520101101.8CA456A005@postboy.ripe.net> Message-ID: <4B8409C7-A519-4D5F-A204-C24DC33C3E52@baycix.de> Hi, Am 20.05.2011 um 12:11 schrieb Emilio Madaio: > > Dear Colleagues, > > A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/ > > We encourage you to review this proposal and send your comments to > before 17 June 2011. > In short: I support the proposal, because it clarifies the obvious. I tried to follow the discussion up to now and i'm not convinced of any of the possible downsides mentioned. Although i like to raise a little concern about the vague point 4 - Insufficient address space : Do we really want to tell the hostmasters/IPRAs to allocate 2x /25, 4x /26 8x /27 ... and so on to LIRs in the end? I mean, "routing" is out of scope (and should be), but... This might be not so awkward with IPv4 PI assignments right now since there actually might be some end users who don't care for internet routability at all, but for allocations? I'm not sure putting something like ".. allocate multiple /24s" or similar in a policy would be a better choice though. (I hope this wasn't already discussed in a thread i didn't read properly) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From Remco.vanMook at eu.equinix.com Thu May 26 10:52:22 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 26 May 2011 09:52:22 +0100 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: <4B8409C7-A519-4D5F-A204-C24DC33C3E52@baycix.de> Message-ID: Hi Sascha, On 26-05-11 08:38, "Sascha Lenz" wrote: > >Although i like to raise a little concern about the vague point 4 - >Insufficient address space : >Do we really want to tell the hostmasters/IPRAs to allocate 2x /25, 4x >/26 8x /27 ... and so on to LIRs in >the end? Indeed that's what we tell them to, although it's not going to be quite so dramatic as you think. Point 4 is there to ensure that, even though the current final /8 policy explicitly states a single /22, RIPE NCC is not going to get stuck with a pile of /23s and smaller at the end of it all. > >I mean, "routing" is out of scope (and should be), but... >This might be not so awkward with IPv4 PI assignments right now since >there actually might >be some end users who don't care for internet routability at all, but for >allocations? >I'm not sure putting something like ".. allocate multiple /24s" or >similar in a policy would >be a better choice though. These smaller blocks only come into play when and if we've exhausted the entire final /8 pool (which will give us I reckon about 20-25,000 "final" allocations, three times the number of current LIRs) and there's more people who want an allocation but there's no more /22s to be handed out, just scraps. I don't want to end up in a situation where RIPE NCC has to say no to people based on policy when they still have blocks of addresses that people will likely be happy to take anyway. I don't know what the current RIPE NCC stockpile of /25s and smaller is, but I think it's unlikely that at the point where we have to start using these for allocations, it's going to have a dramatic impact on the routing table (as I think it'll be a shambles at that point anyway). The final dozen or so LIRs to ever get IPv4 space from the RIPE NCC are going to have to deal with a mixed blessing. Best, Remco 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 millnert at gmail.com Thu May 26 17:28:21 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 26 May 2011 11:28:21 -0400 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: Message-ID: Hi Remco, On Tue, May 24, 2011 at 4:20 AM, Remco Van Mook wrote: > Hi Martin, > > I'll try to answer the points you raised below: > > 1. This proposal does not impact transfer at all. Addresses that get > transferred are at no point in that process 'returned to the RIPE NCC'. > > 2. It's not explicitly defined because it all depends on the address space > returned. As I already indicated in another email, the long term effect of > this is likely to be that all /8s managed by the RIPE NCC will have a > minimum allocation size of a /22; and if we then run out of /22s or larger > and need to hand out multiple smaller blocks (moving to clause 4) a few > additional /8s might get *really* unlucky. But that will only happen when > we're scraping the RIPE NCC barrel. > > Best regards, > > Remco > Thank you for the clarification. I'm satisfied with the above, which is what I expected. Thanks! Best regards, Martin From slz at baycix.de Fri May 27 08:53:16 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 27 May 2011 08:53:16 +0200 Subject: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling) In-Reply-To: References: Message-ID: <0189217F-2F20-476C-87BA-430BA91C4E16@baycix.de> Hi, Am 26.05.2011 um 10:52 schrieb Remco Van Mook: > Hi Sascha, > > > On 26-05-11 08:38, "Sascha Lenz" wrote: >> >> Although i like to raise a little concern about the vague point 4 - >> Insufficient address space : >> Do we really want to tell the hostmasters/IPRAs to allocate 2x /25, 4x >> /26 8x /27 ... and so on to LIRs in >> the end? > > Indeed that's what we tell them to, although it's not going to be quite so > dramatic as you think. Point 4 is there to ensure that, even though the > current final /8 policy explicitly states a single /22, RIPE NCC is not > going to get stuck with a pile of /23s and smaller at the end of it all. > I don't think it will be dramatic at all, otherwise i wouldn't support the proposal ;-) I just wasn't 100% sure that this wording is "what we want". [...] > that people will likely be happy to take anyway. I don't know what the > current RIPE NCC stockpile of /25s and smaller is, but I think it's > unlikely that at the point where we have to start using these for > allocations, it's going to have a dramatic impact on the routing table (as > I think it'll be a shambles at that point anyway). > I'm actually satisfied with the point that we shouldn't see much of that just because there shouldn't be much of this sub-/24 fragmentation anyways. (But only the NCC can tell). I was a bit blinded by the PI situation where we seem to have this kind of fragmentation, but due to the allocation policy for PA space this shouldn't be the case in the "PA /8s" in the first place. So now i'd rather say this wording is a non-issue, nevermind. > The final dozen or so LIRs to ever get IPv4 space from the RIPE NCC are > going to have to deal with a mixed blessing. *sigh* Let's create a "Secret End-of-IPv4 WG" and announce "IPv4 rapture day" for 01.04.2012 or something :-> -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From randy at psg.com Sat May 28 10:52:49 2011 From: randy at psg.com (Randy Bush) Date: Sat, 28 May 2011 11:52:49 +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> Message-ID: > As soon as laws don't allow 'your network, your rules' anymore then > anything can happen... if you think that laws have allowed 'your network, your rules' any time in the last couple of decades, you should share what you are smoking. randy From sander at steffann.nl Sun May 29 23:42:16 2011 From: sander at steffann.nl (Sander Steffann) Date: Sun, 29 May 2011 23:42:16 +0200 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> Message-ID: <459BF2EB-062E-499F-B1BC-FBD8F20BDDD6@steffann.nl> > if you think that laws have allowed 'your network, your rules' any time > in the last couple of decades, you should share what you are smoking. Point taken :) Sander Co-chair of the RIPE APWG / ALPG From emadaio at ripe.net Mon May 30 15:04:40 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 30 May 2011 15:04:40 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review period on the new draft document for IPv6 Address Policy Message-ID: <4DE395E8.1040206@ripe.net> Dear colleagues, At RIPE 59 in Lisbon in October 2009, the RIPE NCC announced that it would undertake a project to make various RIPE policy documents easier to understand without changing the meaning of the text. As already announced, the latest draft document produced according to the project is available at: http://www.ripe.net/ripe/updated-documents/ This is the merger of the three policy documents: -ripe-512 "IPv6 Address Allocation and Assignment Policy" -ripe-451 "IPv6 Address Space Policy for Internet Exchange Points" -ripe-233 "IPv6 Addresses for Internet Root Servers in the RIPE Region" The announcement of the publication of this new draft is available at: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00243.html The Address Policy Working Group co-Chairs decided to extend the review period until 13 June 2011 to allow the community more time to give their feedback. We encourage you to read this merged version and send any comments to address-policy-wg at ripe.net by 13 June 2011. Best Regards Emilio Madaio Policy Development Officer RIPE NCC From millnert at gmail.com Mon May 30 21:26:40 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 30 May 2011 15:26:40 -0400 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> Message-ID: Randy, On Sat, May 28, 2011 at 4:52 AM, Randy Bush wrote: >> As soon as laws don't allow 'your network, your rules' anymore then >> anything can happen... > > if you think that laws have allowed 'your network, your rules' any time > in the last couple of decades, you should share what you are smoking. This is certainly true. The internet is part of our society much like a public square is (borrowed expression). It's important to point out that the recent eG8 debates[1] on strict Internet regulation and a "civilized Internet", championed by Nicolas Sarkozy, is a view not shared by all governments, and any take-away from that get-together *must not* assume so. (It's not clear exactly what was proposed anyway, and consensus was not really there.) Certainly, a lot of people, as evident in the debate, do not wish to see more of the Sarkozy regulation. It's noteworthy that at the same time Sarkozy and a few other speak of decreasing Internet freedoms, Iran is moving forward with its closed-off Halal Internet (where are the, morally just, trade embargoes on selling Internet censorship equipment to certain countries, I wonder?). The Swedish foreign minister, Carl Bildt, had this opening announcement to the session "Internet for Democracy, a tool, a trap, or what?" at the EuroDIG 2011 which opened today: http://www.youtube.com/patrikhson#p/a/u/0/GLLpW4s7WTo Additionally, the Special Rapporteur to the UN on Freedom of Expression, Frank la Rue has this to say recently [2]: D. Disconnecting users from Internet access, including on the basis of violations of intellectual property rights law 49. While blocking and filtering measures deny access to certain content on the Internet, States have also taken measures to cut off access to the Internet entirely. The Special Rapporteur is deeply concerned by discussions regarding a centralized ?on/off? control over Internet traffic. All is not lost. And right now is a *particularly* bad time to make any hasted moves in the wrong direction, I would say. Regards, Martin [1] http://stupid.domain.name/node/1348 [2] http://stupid.domain.name/node/1341 From randy at psg.com Tue May 31 07:50:58 2011 From: randy at psg.com (Randy Bush) Date: Tue, 31 May 2011 08:50:58 +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> Message-ID: >>> As soon as laws don't allow 'your network, your rules' anymore then >>> anything can happen... >> if you think that laws have allowed 'your network, your rules' any time >> in the last couple of decades, you should share what you are smoking. > > This is certainly true. The internet is part of our society much like > a public square is (borrowed expression). > > It's important to point out that the recent eG8 debates[1] warning: you are leaving the real internet and entering a large, possibly infinite, gas cloud of political bullshit. tinfoil hats, kevlar undies, and nose plugs must be worn at all times. please report any signs of reality to the flight crew in case there could be a small chance of finding our way back to earth. thank you, and thanks for flying layer ten space lines. randy From malcolm at linx.net Tue May 31 09:58:05 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Tue, 31 May 2011 08:58:05 +0100 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> Message-ID: <4DE49F8D.7010900@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 06:50, Randy Bush wrote: > warning: you are leaving the real internet and entering a large, > possibly infinite, gas cloud of political bullshit. Sarkozy has clearly described the political imperative. 2008-08 provides (some of) the tools to carry it out. You call Sarkozy's vision "political bullshit"? Tough. He's in charge, you're not. If you build the tools, political leaders like Sarkozy will ensure they get used. Do you really think you can hold off this outcome by calling politicians rude names? - -- 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/ iEYEARECAAYFAk3kn40ACgkQJiK3ugcyKhRONgCgs3MxpktJwqetiOcLBqdSjkoB uv0An188b+bg9WYcYyh0i4d8W/jWs7+7 =oSfv -----END PGP SIGNATURE----- From gert at space.net Tue May 31 10:06:40 2011 From: gert at space.net (Gert Doering) Date: Tue, 31 May 2011 10:06:40 +0200 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> 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: <20110531080640.GT45955@Space.Net> Hi, On Tue, May 31, 2011 at 08:58:05AM +0100, Malcolm Hutty wrote: > You call Sarkozy's vision "political bullshit"? Tough. He's in charge, > you're not. If you build the tools, political leaders like Sarkozy will > ensure they get used. Sarkozy is not in charge in Holland, and his visions are not *that* popular outside France. RIPE policy is not the ideal place to fix broken political approaches - they have their own processes for that, and it works (look at what we did in DE with the internet access denial law that *did* get removed after enough political work in the proper channels). Gert Doering -- APWG chairs -- 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 jim at rfc1035.com Tue May 31 10:41:23 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 31 May 2011 09:41:23 +0100 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> Message-ID: On 31 May 2011, at 06:50, Randy Bush wrote: > warning: you are leaving the real internet and entering a large, > possibly infinite, gas cloud of political bullshit. tinfoil > hats, kevlar undies, and nose plugs must be worn at all times. > please report any signs of reality to the flight crew in case > there could be a small chance of finding our way back to earth. > thank you, and thanks for flying layer ten space lines. Aw come on Randy! Stop pussyfooting around. Tell us what you *really* think. :-) From malcolm at linx.net Tue May 31 10:43:20 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Tue, 31 May 2011 09:43:20 +0100 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110531080640.GT45955@Space.Net> 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> Message-ID: <4DE4AA28.4000505@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 09:06, Gert Doering wrote: > RIPE policy is not the ideal place to fix broken political approaches If after all this discussion you still think those criticising 2008-08 are the ones trying to "fix broken political approaches" through RIPE policy I don't see how we're ever going to agree. - -- 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/ iEYEARECAAYFAk3kqigACgkQJiK3ugcyKhTDlwCfQOSSH6875UQ3w12dIuPfNs0/ vH8Anj/IKMp4iiwd83AQsu3SOSB/1D9W =+Cbx -----END PGP SIGNATURE----- From sander at steffann.nl Tue May 31 10:54:24 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 31 May 2011 10:54:24 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DE4AA28.4000505@linx.net> 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> Message-ID: Hi Malcolm, > If after all this discussion you still think those criticising 2008-08 > are the ones trying to "fix broken political approaches" through RIPE > policy I don't see how we're ever going to agree. It's not about agreeing at this point in time, it's about moving forward: at the last RIPE meeting you said that RPKI has risks what we shouldn't take without thinking about them and without looking for alternatives. In the hallway after the discussion you promised me to do research. As far as I can remember you would: 1) study the discussions in the IETF and other places to see why RPKI design decisions were made the way they are 2) see if there is a better way to secure routing that provides (90%-100%) the same benefits without the major risks as you see them 3) of course taking 1 into account while doing 2 Can you give us a status update on this? Thanks, Sander From Niall.oReilly at ucd.ie Tue May 31 10:55:12 2011 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 31 May 2011 09:55:12 +0100 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review period on the new draft document for IPv6 Address Policy In-Reply-To: <4DE395E8.1040206@ripe.net> References: <4DE395E8.1040206@ripe.net> Message-ID: <4DE4ACF0.8020708@ucd.ie> On 30/05/11 14:04, Emilio Madaio wrote: > At RIPE 59 in Lisbon in October 2009, the RIPE NCC announced that it > would undertake a project to make various RIPE policy documents easier > to understand without changing the meaning of the text. > > As already announced, the latest draft document produced according to > the project is available at: > http://www.ripe.net/ripe/updated-documents/ > > This is the merger of the three policy documents: > > -ripe-512 "IPv6 Address Allocation and Assignment Policy" > -ripe-451 "IPv6 Address Space Policy for Internet Exchange Points" > -ripe-233 "IPv6 Addresses for Internet Root Servers in the RIPE Region" > > The announcement of the publication of this new draft is available at: > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00243.html > > > The Address Policy Working Group co-Chairs decided to extend the review > period until 13 June 2011 to allow the community more time to give their > feedback. This is a significantly ambitious project. Simply merging existing documents is already a challenge. Transforming the output in the same operation "to make [it] easier to understand without changing the meaning of the text" augments that challenge. I believe that the routine work needed to support this review has not yet been performed by the RIPE NCC, and that the proposed deadline, even though already extended, is unrealistic. Specifically, the version of the change proposal which juxtaposes current and proposed text does not show from which of the three source documents the text presented as "current" is taken. Resolving the source references appears to have been left implicitly as an exercise for the reader. I expect that this will surely discourage engagement in the review process. Best regards Niall O'Reilly From gert at space.net Tue May 31 10:57:27 2011 From: gert at space.net (Gert Doering) Date: Tue, 31 May 2011 10:57:27 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DE4AA28.4000505@linx.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> Message-ID: <20110531085727.GW45955@Space.Net> Hi, On Tue, May 31, 2011 at 09:43:20AM +0100, Malcolm Hutty wrote: > On 31/05/2011 09:06, Gert Doering wrote: > > RIPE policy is not the ideal place to fix broken political approaches > > If after all this discussion you still think those criticising 2008-08 > are the ones trying to "fix broken political approaches" through RIPE > policy I don't see how we're ever going to agree. Well, *I* don't have to agree with anyone. I'm here to steer the process. 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?) 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 malcolm at linx.net Tue May 31 12:34:28 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Tue, 31 May 2011 11:34:28 +0100 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> Message-ID: <4DE4C434.4070806@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 09:54, Sander Steffann wrote: > It's not about agreeing at this point in time, it's about moving forward: at the last RIPE meeting you said that RPKI has risks what we shouldn't take without thinking about them and without looking for alternatives. In the hallway after the discussion you promised me to do research. As far as I can remember you would: > 1) study the discussions in the IETF and other places to see why RPKI design decisions were made the way they are > 2) see if there is a better way to secure routing that provides (90%-100%) the same benefits without the major risks as you see them > 3) of course taking 1 into account while doing 2 > > Can you give us a status update on this? You make it sound like I agreed to single-handedly solve the problem in all its various aspects. Not so. The only pointer anyone has given me to explain why 2008-08 incorporates the RPKI architecture that it does is "Go read the SIDR mailing list archive". So I had a look at that, but as far as I can understand they took the RPKI architecture as an input from previous work. So the reasons why this was picked seem to lie elsewhere, although I'm not sure where that is. Any better pointers to the actual discussion and decision-making would be welcome. What worries me about the questions you set me above is that it reads as though you expect me to single-handedly design an alternative solution that meets 2008-08's goals while also satisfying the criticisms. As I said in the hallway, the technical work on producing an alternative approach would have to be led by someone expert in that area, which I am not. If such work is done, I believe I can contribute usefully by helping to identify whether an alternative does indeed reduce the risk of the foreseeable consequences I've identified with 2008-08. For example, in the hallway we discussed a couple of ideas for variations on 2008-08 (distributed certification and decentralised CAs). These did seem to tackle the problems of centralisation with 2008-08, and so seem to me to be worthy of investigation, but developing the idea into an approvable policy proposal should be done by someone else. To reiterate: I am happy to contribute. However, if the design of this is in the hands of the IETF not RIPE, then I have to ask whether there any point in us designing an alternative? Or is the only decision for this WG a simple YES/NO on whether the community wants RIPE NCC to implement the IETF work? If the latter, what I have already said is probably sufficient. I must confess my ignorance on the scope available to us, and ask for your guidance. In any case, my own core relevant expertise lies in correcting some of the misinformation propagated here about "black helicopters" and so forth, by providing concrete information on public policy developments in progress, and filling in the information gap left by the RIPE NCC's legal advice, which disclaims advising upon the likelihood and likely consequences of future changes in the law (I'm not criticising the lawyer for leaving this gap: that area is essentially Public Affairs advice not legal advice). I suggest that this is important input to this WG's decision as to whether it believes 2008-08 (or any successor proposal) is in fact useful, i.e. whether it is likely to do more good than harm. 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/ iEYEARECAAYFAk3kxDQACgkQJiK3ugcyKhS9uwCgrl/fYP62Y/tMwCGfOy9h1Xh5 CVoAoMmztYz0XGVIyW6XXRK5RDa6dciR =Thdg -----END PGP SIGNATURE----- From thk at telenor.net Tue May 31 13:39:46 2011 From: thk at telenor.net (Thor-Henrik Kvandahl) Date: Tue, 31 May 2011 13:39:46 +0200 (MEST) Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review period on the new draft document for IPv6 Address Policy In-Reply-To: <4DE395E8.1040206@ripe.net> References: <4DE395E8.1040206@ripe.net> Message-ID: Hi. In RIPE-512 section 5.5 "Registration" is says: "When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'." I believe the correct wording here should be "End Site" instead of organisation. If you read the wording stictly, we cannot use the AGGREGATED-BY-LIR for "organisations" with more than one /48 End Site, and I dont think this was the intention. -- Thor-Henrik Kvandahl Network Architect Telenor Norway, Snaroyvn. 30, 1331 Fornebu, Norway. On Mon, 30 May 2011, Emilio Madaio wrote: > > Dear colleagues, > > At RIPE 59 in Lisbon in October 2009, the RIPE NCC announced that it would > undertake a project to make various RIPE policy documents easier to > understand without changing the meaning of the text. > > As already announced, the latest draft document produced according to the > project is available at: > http://www.ripe.net/ripe/updated-documents/ > > This is the merger of the three policy documents: > > -ripe-512 "IPv6 Address Allocation and Assignment Policy" > -ripe-451 "IPv6 Address Space Policy for Internet Exchange Points" > -ripe-233 "IPv6 Addresses for Internet Root Servers in the RIPE Region" > > The announcement of the publication of this new draft is available at: > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00243.html > > The Address Policy Working Group co-Chairs decided to extend the review > period until 13 June 2011 to allow the community more time to give their > feedback. > > We encourage you to read this merged version and send any comments to > address-policy-wg at ripe.net by 13 June 2011. > > > Best Regards > Emilio Madaio > Policy Development Officer > RIPE NCC > > From sander at steffann.nl Tue May 31 17:16:12 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 31 May 2011 17:16:12 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DE4C434.4070806@linx.net> 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> Message-ID: <603FB174-29EA-42EE-827C-984AA59863B0@steffann.nl> Hi Malcolm, > You make it sound like I agreed to single-handedly solve the problem in > all its various aspects. > > Not so. Certainly not single-handedly, but I though you would take the initiative and gather input from experts. > [...] > > However, if the design of this is in the hands of the IETF not RIPE, > then I have to ask whether there any point in us designing an > alternative? If the alternative fits in the framework that the IETF has designed: yes > Or is the only decision for this WG a simple YES/NO on > whether the community wants RIPE NCC to implement the IETF work? > > If the latter, what I have already said is probably sufficient. > > I must confess my ignorance on the scope available to us, and ask for > your guidance. I think the current scope should be: can we find a way that satisfies your concerns while staying within the RPKI framework that the IETF has designed. Once we have the answer to that question we can look at the next step. > In any case, my own core relevant expertise lies in correcting some of > the misinformation propagated here about "black helicopters" and so > forth, by providing concrete information on public policy developments > in progress, and filling in the information gap left by the RIPE NCC's > legal advice, which disclaims advising upon the likelihood and likely > consequences of future changes in the law (I'm not criticising the > lawyer for leaving this gap: that area is essentially Public Affairs > advice not legal advice). I don't think this is the place for discussions about possible future law changes. *anything* can be changed in the law, and the usual way to influence that is through voting. We deal with the current situation, and if the landscape changes we can always start a new policy proposal. > I suggest that this is important input to this WG's decision as to > whether it believes 2008-08 (or any successor proposal) is in fact > useful, i.e. whether it is likely to do more good than harm. I was just thinking: are these problems really about the RIPE NCC providing certification services for the resources they hand out, or is this about big router vendors implementing route-origin-code in their OS? I mean: that is the part that actually influences routing, and the data used there can come from RPKI but also from other sources. You seem to be concerned that governments can force ISPs to use RIPE NCC issued ROAs for this, and then force the RIPE NCC to revoke/reissue ROAs. Why would governments take this legally difficult path and not just force ISPs to use government-supplied data as input for their routers? The more I think about it the more I feel that governments have *many* easier ways to influence routing than the ways you are worried about... Sander From andrei.robachevsky at gmail.com Tue May 31 17:33:08 2011 From: andrei.robachevsky at gmail.com (Andrei Robachevsky) Date: Tue, 31 May 2011 17:33:08 +0200 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4DE4C434.4070806@linx.net> 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> Message-ID: <4DE50A34.3020906@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malcolm Hutty wrote on 5/31/11 12:34 PM: [...] > I suggest that this is important input to this WG's decision as to > whether it believes 2008-08 (or any successor proposal) is in fact > useful, i.e. whether it is likely to do more good than harm. > I'd like to note that RPKI is essentially an opt-in technology. Without issuing a ROA, which is an ISP decision, not much changes compared to how things are today. We are not switching on secure routing with adopting this policy, the ISPs will have plenty of time to decide for themselves what the fear more - route hijacking or some crazy law wiping their network out. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3lCjQACgkQljz5tZmtij8yFQCgpUZ36e+d8LhoyB0T7HixR6Lg +KcAoLtclX30uvfUCC+DCPRySFFTXnSj =o0N4 -----END PGP SIGNATURE----- From jim at rfc1035.com Tue May 31 17:44:38 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 31 May 2011 16:44:38 +0100 Subject: [address-policy-wg] Is RPKI opt-in? In-Reply-To: <4DE50A34.3020906@gmail.com> 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> <4DE50A34.3020906@gmail.com> Message-ID: <28D6AC52-C0FD-42B9-855D-9C6F61EC6BC3@rfc1035.com> On 31 May 2011, at 16:33, Andrei Robachevsky wrote: > I'd like to note that RPKI is essentially an opt-in technology. Depends on your definition Andrei. Once upstream ISPs insist on ROAs, the choice of opting in (or out) is made for you. From andrei.robachevsky at gmail.com Tue May 31 18:19:49 2011 From: andrei.robachevsky at gmail.com (Andrei Robachevsky) Date: Tue, 31 May 2011 18:19:49 +0200 Subject: [address-policy-wg] Re: Is RPKI opt-in? In-Reply-To: <28D6AC52-C0FD-42B9-855D-9C6F61EC6BC3@rfc1035.com> 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> <4DE50A34.3020906@gmail.com> <28D6AC52-C0FD-42B9-855D-9C6F61EC6BC3@rfc1035.com> Message-ID: <1723504E-AA56-4349-B112-7B702951D04B@gmail.com> On 31 mei 2011, at 17:44, Jim Reid wrote: > On 31 May 2011, at 16:33, Andrei Robachevsky wrote: > >> I'd like to note that RPKI is essentially an opt-in technology. > > Depends on your definition Andrei. Once upstream ISPs insist on ROAs, the choice of opting in (or out) is made for you. True, for those who borrow address space from their upstreams, but many other choices are made for them anyway. I meant more than 7000 holders of PA allocations, and many more PI holders in the future. Andrei From nick at inex.ie Tue May 31 18:38:52 2011 From: nick at inex.ie (Nick Hilliard) Date: Tue, 31 May 2011 18:38:52 +0200 Subject: [address-policy-wg] Re: Is RPKI opt-in? In-Reply-To: <1723504E-AA56-4349-B112-7B702951D04B@gmail.com> 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> <4DE50A34.3020906@gmail.com> <28D6AC52-C0FD-42B9-855D-9C6F61EC6BC3@rfc1035.com> <1723504E-AA56-4349-B112-7B702951D04B@gmail.com> Message-ID: <4DE5199C.30009@inex.ie> On 31/05/2011 18:19, Andrei Robachevsky wrote: > I meant more than 7000 holders of PA allocations, and many more PI holders in the future. I think these were the address holders that Jim was referring to. Nick From millnert at gmail.com Tue May 31 20:41:40 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 31 May 2011 14:41:40 -0400 Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <603FB174-29EA-42EE-827C-984AA59863B0@steffann.nl> 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: Hi Sander, On Tue, May 31, 2011 at 11:16 AM, Sander Steffann wrote: > I don't think this is the place for discussions about possible future law changes. *anything* can be changed in the law, and the usual way to influence that is through voting. We deal with the current situation, and if the landscape changes we can always start a new policy proposal. 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. We're kind of saying, let's not make the shell casing if it is likely that the gun will be used for more bad than good. >You seem to be concerned that governments can force ISPs to use RIPE NCC issued ROAs for this, and then force the RIPE NCC to revoke/reissue ROAs. Why would governments take this legally difficult path and not just force ISPs to use government-supplied data as input for their routers? Governments tend to be good at legal work and not so much routing infrastructure (though they're trying in Iran). If they have one interfacing point, the RIPE NCC, which they and LEAs are already familiar with, why not use it? If ISPs as a result of their use of RIPE NCC to protect citizens from harmful ideas and information decide to not use the RIPE NCC trust anchor, they tend to remedy that with laws. In my view, the risks are certainly not solely with the RIPE NCC certifying resources according to IETF and SIDR-compatible ways, but it's a key piece. > The more I think about it the more I feel that governments have *many* easier ways to influence routing than the ways you are worried about... Assuming there is a ripencc.LEAandGovAPI.makePrefixGoAway(prefix) API, do you still think there are easier ways for one EU member state to make a route go away in a vast area? That seems pretty easy to me. Best, Martin From danny at danysek.cz Tue May 31 23:07:20 2011 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 31 May 2011 23:07:20 +0200 Subject: [address-policy-wg] Is RPKI opt-in? In-Reply-To: <28D6AC52-C0FD-42B9-855D-9C6F61EC6BC3@rfc1035.com> 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> <4DE50A34.3020906@gmail.com> <28D6AC52-C0FD-42B9-855D-9C6F61EC6BC3@rfc1035.com> Message-ID: <4DE55888.9020607@danysek.cz> On 05/31/2011 05:44 PM, Jim Reid wrote: > On 31 May 2011, at 16:33, Andrei Robachevsky wrote: > >> I'd like to note that RPKI is essentially an opt-in technology. > > Depends on your definition Andrei. Once upstream ISPs insist on ROAs, > the choice of opting in (or out) is made for you. I don't think they'll adopt this quickly. It's a new technology, not widely supported by vendors yet (on all platforms used for routing, that means not only "flag ships"), some large operators are also conservative in terms of any changes, even in running software... It's also a bussines case - upstream ISPs will not force their customers to RPKI. They'll loose their money, if they will... Even I'm supporting this technology, I don't make illusions here. Lessons learned from "speed" of IPv6 adoption should be taken in account. So this technology should be handled as opt-in... - Daniel