From president at ukraine.su Mon Jan 7 15:28:30 2008 From: president at ukraine.su (Max Tulyev) Date: Mon, 07 Jan 2008 16:28:30 +0200 Subject: [address-policy-wg] PA vs PI routing pollution question Message-ID: <4782370E.7020703@ukraine.su> Hello! As I send a lot of PI address space requests for my customers, RIPE hostmasters often says LIR is better than PI because of "That way they can receive as much contiguous (!) PA address space as they need." When I establish a new LIR, I write almost same request for PA, and it contains same address space usage plan for two years. PI networks requested after two years are not contiguous, and I understand why. Is it means RIPE reserve some contiguous network for future grow for LIRs? If yes, how big is this reservation? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From filiz at ripe.net Tue Jan 15 17:14:25 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 15 Jan 2008 17:14:25 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) Message-ID: <20080115161425.84C082F583@herring.ripe.net> PDP Number: 2008-01 Assigning IPv6 PI to Every Inetnum Holder Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. With the acceptance of this proposal, the RIPE NCC will conduct a one-time operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered in the RIPE Database. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-01.html We encourage you to review this proposal and send your comments to before 12 February 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Tue Jan 15 17:19:01 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 15 Jan 2008 17:19:01 +0100 Subject: [address-policy-wg] 2008-02 New Policy Proposal (Assigning IPv6 PA to Every LIR) Message-ID: <20080115161901.EAC342F583@herring.ripe.net> PDP Number: 2008-02 Assigning IPv6 PA to Every LIR Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. With the acceptance of this proposal RIPE NCC will run a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 holdings. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-02.html We encourage you to review this proposal and send your comments to before 12 February 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From jeroen at unfix.org Tue Jan 15 17:27:38 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 15 Jan 2008 17:27:38 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <478CDEFA.1010200@spaghetti.zurich.ibm.com> Filiz Yilmaz wrote: > PDP Number: 2008-01 > Assigning IPv6 PI to Every Inetnum Holder Filiz Yilmaz wrote: > PDP Number: 2008-02 > Assigning IPv6 PA to Every LIR Both these proposals should directly be binned. Especially the /56 proposal is insane and will only result in those routes to also become into the BGP increasing the junk there even more. What happened to the idea of "Aggregation". Organizations who are not requesting address space with the currently available process are not going to deploy IPv6, going to force it down them is not going to help either. Please *BIN* these proposals. Both of them. Directly. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From michael.dillon at bt.com Tue Jan 15 17:35:18 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 15 Jan 2008 16:35:18 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: > Under this proposal all End Users in the RIPE NCC service region > will receive an IPv6 PI assignment. All holders of IPv4 address > space in the RIPE region will also be proactively informed that > they have been assigned a block of IPv6 address space and that > it is ready for deployment. If a policy like this was ever to be accepted, it should only give every existing IPv4 *PI* holder, an IPv6 /48 block. There is no good reason to give non-PI holders in the RIPE database any IPv6 blocks. There is also no good reason to give any PI holder less than a /48 block as ARIN currently does. Longer prefixes in the routing table only make a confusing situation more confusing. > An assignment size of /56 is specified in the proposal in an effort > to keep the routing table free from /64 address blocks. > The /56 assignment is seen as a balance between individual > routing requirements and routing aggregation needs. I know of no research that shows any negative impacts of placing /64 blocks in a routing table. This is a silly argument since the proposal suggests *ADDING* a large number of routes to the routing table and there is a lot of published research about the problems caused by having too many routes in the routing table. In addition, this policy proposal is suggesting that RIPE should lie to all the End Users in the database and tell them that IPv6 is ready for deployment just because they now have some shiny new numbers in their RIPE database entry. Nothing could be further from the truth. Even though my company already has commercial IPv6 customers on our network, we would not know what to do with a flood of requests from people who think that IPv6 Internet access is easy if you have a number. IPv6 Internet access in Europe in early 2008 is hard. Lack of address assignments is not a barrier to making IPv6 Internet access work. The real barriers can be found by reading through some of the pages at such as the one on First Steps for ISPs or Transparent Internet Access Accepting a proposal like this would send entirely the wrong message and could only delay the deployment of IPv6 while we try to do damage control. --Michael Dillon From timothy.clarke at thecloud.net Tue Jan 15 17:25:35 2008 From: timothy.clarke at thecloud.net (Timothy Clarke) Date: Tue, 15 Jan 2008 16:25:35 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <71CBBB1D828DB747BAF4B5362878A037039246DC@ebe1.corp.thecloud.net> >From the little I've seen / read regarding IPv6 I get the impression that people are starting to think of a IPv6 /48 in the same light as a IPv4 /24. As such a /56 will fall into the same hole as longer IPv4 prefix's in that no one wants to carry them. Please tell me this isn't the impression other people are starting to get Timothy -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Filiz Yilmaz Sent: 15 January 2008 16:14 To: policy-announce at ripe.net Cc: Lutz Donnerhacke; address-policy-wg at ripe.net Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) PDP Number: 2008-01 Assigning IPv6 PI to Every Inetnum Holder Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. With the acceptance of this proposal, the RIPE NCC will conduct a one-time operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered in the RIPE Database. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-01.html We encourage you to review this proposal and send your comments to before 12 February 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From marcoh at marcoh.net Tue Jan 15 17:38:29 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 15 Jan 2008 17:38:29 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: On Jan 15, 2008, at 5:35 PM, wrote: >> In addition, this policy proposal is suggesting that RIPE should >> lie to > all the End Users in the database and tell them that IPv6 is ready for > deployment just because they now have some shiny new numbers in their > RIPE database entry. Nothing could be further from the truth. Even > though > my company already has commercial IPv6 customers on our network, we > would > not know what to do with a flood of requests from people who think > that > IPv6 Internet access is easy if you have a number. > > IPv6 Internet access in Europe in early 2008 is hard. Lack of address > assignments is not a barrier to making IPv6 Internet access work. The > real barriers can be found by reading through some of the pages at > such as the one on First Steps for ISPs > > > or Transparent Internet Access > > > Accepting a proposal like this would send entirely the wrong message > and > could only delay the deployment of IPv6 while we try to do damage > control. I totally agree on this one, it's not that we haven't got the space to supply our customers with v6 addresses, we simply can't provision at the moment, at least not for a large chunk of our customer base. Before I start any work myself, does anybody have the statistics on hand on how many end-users (routes) we are talking about ? -- MarcoH From jarlah at imate.fi Tue Jan 15 17:36:57 2008 From: jarlah at imate.fi (=?ISO-8859-1?Q?Jarno_L=E4hteenm=E4ki?=) Date: Tue, 15 Jan 2008 18:36:57 +0200 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <478CE129.4060608@imate.fi> Does this proposal really mean that every inetnum object holder will get IPv6 PI block? Or should it mean that every PI assignment holder gets also IPv6 PI assignment? Second thing. We should try to aggregate more in IPv6 world than in IPv4 world. So if some entity has 4 IPv4 PI blocks it should get only one IPv6 block if it doesn't necessarily want more. It creates some bureaucracy but I think we can cope with that. Regards, Jarno Filiz Yilmaz wrote: > PDP Number: 2008-01 > Assigning IPv6 PI to Every Inetnum Holder > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > With the acceptance of this proposal, the RIPE NCC will conduct a one-time operation > to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered > in the RIPE Database. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-01.html > > We encourage you to review this proposal and send your comments to > before 12 February 2008. > > > Regards > > Filiz Yilmaz > RIPE NCC Policy Development Officer From alexlh at ripe.net Tue Jan 15 18:18:49 2008 From: alexlh at ripe.net (Alex Le Heux) Date: Tue, 15 Jan 2008 18:18:49 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <02C490C8-178F-48F3-8810-8206CBA45BE9@ripe.net> Dear Marco, > Before I start any work myself, does anybody have the statistics on > hand on how many end-users (routes) we are talking about ? There are around 2.2 million inetnum objects in the RIPE Database. It is not immediately obvious into how many routes this would translate. When talking about ASSIGNED PI objects only, the number is around 20.000. Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator From nick at inex.ie Tue Jan 15 19:25:27 2008 From: nick at inex.ie (Nick Hilliard) Date: Tue, 15 Jan 2008 18:25:27 +0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <478CFA97.5050408@inex.ie> > With the acceptance of this proposal, the RIPE NCC will conduct a one-time operation > to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered > in the RIPE Database. What exactly is the problem we're trying to solve here? Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From berni at birkenwald.de Tue Jan 15 22:28:38 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 15 Jan 2008 22:28:38 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <478D2586.50604@birkenwald.de> Filiz Yilmaz wrote: > With the acceptance of this proposal, the RIPE NCC will conduct a one-time operation > to assign a /56 IPv6 PI prefix to all End Users with an IPv4 assignment registered > in the RIPE Database. I agree with Jeroen here that both proposals should be binned immediately or reposted in two and a half months. I think (hope) the intention of 2008-01 was to get some discussion/movement into the whole PIv6 area again, which is desperately needed. First of all, I don't think the majority is afraid of the idea of PI itself (the old "carriers want to constrain their customers" myth), the majority is afraid of running it like it is currently done for IPv4 in the RIPE region. I'm talking about PI space that is visible in the DFZ here of course, unannounced PI space should mostly be covered by ULA. My main concern with IPv4 PI is that there is _no_ reasonable financial incentive to help weighting the pros (you got yourself independent addresses, yay) against the cons (_everyone_ _else_ needs an additional slot in the routing table). The main argument I heard about this is that getting PI space is not free either, because you need to pay the sponsoring LIR to do the work. Unfortunately, in most cases I have seen this work was never billed, because there was no need to do so. Due to the way billing PI space works in the RIPE region (scoring points, only once) LIRs, especially big ones, often don't pay a single cent for the space they have allocated, so everything they need to account for is work. PI requests which are reasonably well justified don't make that much work, and even if not, there are plenty of network engineers/hostmasters sitting around all day idling in IRC. :-) This is at assigning time. Once the address space is assigned, it is basically free. Again there is _no_ incentive to reevaluate the need for this PI space, because renumbering is certainly causing some amount of work which is definitely not offset by the amount of money you will save by giving back this PI space (zero!). Again, there has been the argument that announcing a prefix is not free either, but there are plenty of operators that would gladly announce your PI prefix without additional costs if you buy their 50? DSL/housing service. This is a very competitive market, at least here in Germany. After all, its just a few lines of routerconfig and if your are pedantic, the registration of the route object in the RIPE database. Announcing additional prefixes is not increasing your transit costs, so after it has been setup, it is free (again) for all parties involved (apart from the DFZ slot again). After the prefix has been assigned, there is no real way for RIPE to track it. The PI space is not linked to a member, they don't exchange any information with the original requestor. Now we are at the end of the requestor's lifecycle (let's just assume it is a company, not personal PI space) and all its assets get dismantled. Normally, the PI space should be returned to the RIR, but at this stage of business only a minority cares about that. Hopefully the remainders have their announcements pulled at least, but is a rule with the well-known exception. Now there is address space that can either be hijacked by anyone else or just "donated" to a former employee/fried of the owner/whatever (compensation?). This most certainly does not match the original PI request anymore, but unless RIPE is given enough clues about it they just can't know. A solution to all this problems is already a RIPE policy proposal (2007-01, http://www.ripe.net/ripe/policies/proposals/2007-01.html). It does not discuss assigning a cost to this membership, but I think this is a generally understood that this membership is not going to be free. By assigning a _direct_ and _recurring_ fee to address space you don't fix every instance of a case mentioned above, but the majority. People will think about requesting PI space because there IS a cost figure directly assigned to it (and not to some weird scoring point for a third party), they should think about the necessity of the assignment every year when they get the bill and if the company gets shut down it either gets cancelled properly (there is a contract) or gets cancelled when the next bill is not paid up. Of course, someone who has been given that address space can just continue paying on his own, but he will think about the necessity as well. Of course, you can't revoke an announcement as easy as a domain, but by removing the inetnum, route(6) and domain objects from the RIPE database this fact is at least documented. So, imho bin 2008-01, 2008-02 and 2006-01 now, get 2007-01 out with proper costs assigned (ARIN membership costs $500 a year, I don't want to discuss in this mail whether it should be higher or lower in the RIPE region and whether there should be a limit of resources assigned to one member) and _then_ (only then) discuss a proper PIv6 proposal that is similar to the other RIRs (e.g. minimum /48 from a certain prefix, requires membership). This can/should be done with PIv4 and ASN as well, but I don't think there is any legal loophole where you could apply it to the already assigned space. Bernhard From elmi at 4ever.de Tue Jan 15 23:18:14 2008 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 15 Jan 2008 23:18:14 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <71CBBB1D828DB747BAF4B5362878A037039246DC@ebe1.corp.thecloud.net> References: <20080115161425.84C082F583@herring.ripe.net> <71CBBB1D828DB747BAF4B5362878A037039246DC@ebe1.corp.thecloud.net> Message-ID: <20080115221813.GJ23974@ronin.4ever.de> timothy.clarke at thecloud.net (Timothy Clarke) wrote: > From the little I've seen / read regarding IPv6 I get the impression > that people are starting to think of a IPv6 /48 in the same light as a > IPv4 /24. > > As such a /56 will fall into the same hole as longer IPv4 prefix's in > that no one wants to carry them. Same here. I'd not bother with a /56. I recommend using a /48 and nothing else. Same as for "special use v6 PI" - and the size has been chosen for a reason there. Yours, Elmar. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fr?nzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]--- From elmi at 4ever.de Tue Jan 15 23:20:58 2008 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 15 Jan 2008 23:20:58 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478CE129.4060608@imate.fi> References: <20080115161425.84C082F583@herring.ripe.net> <478CE129.4060608@imate.fi> Message-ID: <20080115222057.GK23974@ronin.4ever.de> jarlah at imate.fi (Jarno L?hteenm?ki) wrote: > Does this proposal really mean that every inetnum object holder will get > IPv6 PI block? Or should it mean that every PI assignment holder gets > also IPv6 PI assignment? I must admit I didn't read it yet, but the _sane_ way of going about it would be - Assign a v6 block to any current PI assignment or PA allocation (!) holder _if_ they apply for it - Assign a /48, _NO /56_ (crap idea). Assign longer if justified. Yours, Elmi. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fr?nzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]--- From drixter at e-utp.net Tue Jan 15 23:29:19 2008 From: drixter at e-utp.net (Marcin Gondek) Date: Tue, 15 Jan 2008 23:29:19 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478D2586.50604@birkenwald.de> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> Message-ID: <185c01c857c6$121bc4d0$36534e70$@net> Hello, So maybe we can make this way: There is some membership free for PI user and then some yearly payment to keep it working. Please understand, not anyone have to be LIR > First of all, I don't think the majority is afraid of the idea of PI > itself (the old "carriers want to constrain their customers" myth), the > majority is afraid of running it like it is currently done for IPv4 in > the RIPE region. I'm talking about PI space that is visible in the DFZ > here of course, unannounced PI space should mostly be covered by ULA. [...] > but I don't think there is any legal loophole where you could apply it > to the already assigned space. > > Bernhard So maybe we can make this way: Make some membership fee for PI user and then some yearly payment to keep it working. For example: - 500E setup fee - 100E for ASN request for this PI Plus some kind monitoring, if PI addresses in request are requested for public use, not internal then: - have to be visible by RIPE router more than 75% time in year from date of assignment + 1 month. - 100E yearly maintenance If there availability time is smaller than 75%, again there is a setup fee or addresses backing to RIPE. Also ASN can be taken back to the RIPE. If PI addresses are requested for internal usage: - 200E yearly maintenance Every PI-member can have only one /48 prefix if we need more, then have to be a LIR, have to have a legal business in RIPE region and etc. Then, RIPE make a special /32 where those /48 are stored (for easy filtering). Please understand, not everyone have to be LIR because they don't need it to be, but they need PI address because they have >1 upstreams. It's very popular here in Poland. Now I hearing for people: "We don't implement IPv6 because there is no PI procedure. We don't want to be a LIR." I'm not a LIR, I just wondering, maybe someone will agree with me for this PI idea. Regards, -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 office at e-utp.net http://www.e-utp.net From swmike at swm.pp.se Tue Jan 15 23:46:16 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 15 Jan 2008 23:46:16 +0100 (CET) Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <185c01c857c6$121bc4d0$36534e70$@net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> Message-ID: On Tue, 15 Jan 2008, Marcin Gondek wrote: > - 100E yearly maintenance If not higher. Hidden cost to the community is much much higher as each PI announcement translates (in the long run) to more expensive routing platforms. We made a boo-boo with IPv4 in the PI area, let's not do it again with IPv6. Assign real cost to having a slot in the global DFZ. That way people that really really need PI will pay it (at 1000E a year it's still a win situation at a few tens of work hours) and the ones who do not, will not clutter the DFZ. -- Mikael Abrahamsson email: swmike at swm.pp.se From info at streamservice.nl Wed Jan 16 00:20:42 2008 From: info at streamservice.nl (Stream Service || Mark Scholten) Date: Wed, 16 Jan 2008 00:20:42 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <185c01c857c6$121bc4d0$36534e70$@net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> Message-ID: Hello, Maybe it is an option to use the same system as used by PI space on IPv4. Also more than a /48 should be possible with PI space on IPv6 (for example a /44). I'm not a LIR, but I will require to have PI space on IPv6 before I start using it (I need the option to move IPs from network 1 to network 2 and the option to have multiple uplink providers). Please remember: the easier it is to use and the easier it is to get IPv6 space the faster it will be used. With kind regards, Met vriendelijke groet, Mark Scholten Stream Service Web: http://www.streamservice.nl/ E-mail: mark at streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc at streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Marcin Gondek" To: Sent: Tuesday, January 15, 2008 11:29 PM Subject: RE: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) Hello, So maybe we can make this way: There is some membership free for PI user and then some yearly payment to keep it working. Please understand, not anyone have to be LIR > First of all, I don't think the majority is afraid of the idea of PI > itself (the old "carriers want to constrain their customers" myth), the > majority is afraid of running it like it is currently done for IPv4 in > the RIPE region. I'm talking about PI space that is visible in the DFZ > here of course, unannounced PI space should mostly be covered by ULA. [...] > but I don't think there is any legal loophole where you could apply it > to the already assigned space. > > Bernhard So maybe we can make this way: Make some membership fee for PI user and then some yearly payment to keep it working. For example: - 500E setup fee - 100E for ASN request for this PI Plus some kind monitoring, if PI addresses in request are requested for public use, not internal then: - have to be visible by RIPE router more than 75% time in year from date of assignment + 1 month. - 100E yearly maintenance If there availability time is smaller than 75%, again there is a setup fee or addresses backing to RIPE. Also ASN can be taken back to the RIPE. If PI addresses are requested for internal usage: - 200E yearly maintenance Every PI-member can have only one /48 prefix if we need more, then have to be a LIR, have to have a legal business in RIPE region and etc. Then, RIPE make a special /32 where those /48 are stored (for easy filtering). Please understand, not everyone have to be LIR because they don't need it to be, but they need PI address because they have >1 upstreams. It's very popular here in Poland. Now I hearing for people: "We don't implement IPv6 because there is no PI procedure. We don't want to be a LIR." I'm not a LIR, I just wondering, maybe someone will agree with me for this PI idea. Regards, -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 office at e-utp.net http://www.e-utp.net From garry at nethinks.com Wed Jan 16 06:43:18 2008 From: garry at nethinks.com (Garry Glendown) Date: Wed, 16 Jan 2008 06:43:18 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> Message-ID: <478D9976.4020600@nethinks.com> Mikael Abrahamsson wrote: > On Tue, 15 Jan 2008, Marcin Gondek wrote: > >> - 100E yearly maintenance > > If not higher. Hidden cost to the community is much much higher as each > PI announcement translates (in the long run) to more expensive routing > platforms. > > We made a boo-boo with IPv4 in the PI area, let's not do it again with > IPv6. Assign real cost to having a slot in the global DFZ. That way > people that really really need PI will pay it (at 1000E a year it's > still a win situation at a few tens of work hours) and the ones who do > not, will not clutter the DFZ. I second this (and the /48) suggestion ... from our experience, some customers who will most likely NEVER get a second uplink (don't really need it), and have very few boxes to change (in case of PA and provider change) have insisted to us to get PI instead of PA. No way of talking them out of it. Maybe with even a small _reasonable_ price tag for yearly renewal would have made it easier to reason with them ;) result is less unnecessary routing table growth for BS applications, and (also important) return of unused (read: unpaid) PI to RIR. In essence, here's my "wish list" for this topic: - /48, not /56 - small yearly fee (100-200??) for routable PI - small one-time fee (100-200??) for non-routable PI (take them out of a defined /32 or so which is/can/should be filtered by ISPs) - don't automatically distribute IPv6 space (both PI and LIRs) - e.g., our customers with PI I don't see using IPv6 within at least the next 5 years (we've had v6 available for several years ...). Instead, make initial v6 applications and allocations "painless", allowing for any PI owners to just "lift their hand" and they receive their v6-PI (/48) for just paying ;) -garry From andy at nosignal.org Wed Jan 16 09:15:59 2008 From: andy at nosignal.org (Andy Davidson) Date: Wed, 16 Jan 2008 08:15:59 +0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115221813.GJ23974@ronin.4ever.de> References: <20080115161425.84C082F583@herring.ripe.net> <71CBBB1D828DB747BAF4B5362878A037039246DC@ebe1.corp.thecloud.net> <20080115221813.GJ23974@ronin.4ever.de> Message-ID: On 15 Jan 2008, at 22:18, Elmar K. Bins wrote: > timothy.clarke at thecloud.net (Timothy Clarke) wrote: >> From the little I've seen / read regarding IPv6 I get the impression >> that people are starting to think of a IPv6 /48 in the same light >> as a >> IPv4 /24. >> As such a /56 will fall into the same hole as longer IPv4 prefix's in >> that no one wants to carry them. > Same here. I'd not bother with a /56. I recommend using a /48 and > nothing > else. Same as for "special use v6 PI" - and the size has been > chosen for > a reason there. There would need to be no mnt-lower or similar, to prevent people using /48 PI when they should really be becoming members of RIPE and getting a /48 PA. I'm still thinking about whether I feel this is a good idea. If v4- >v6 migration is going to work, then everyone who has some v4 PI is *probably* going to need some v6 PI. Perhaps sorting out the "does need" from the "should just get a slice of an upstream's PA" is going to be arduous, time-consuming, and possibly soul crushing, so I'm erring towards thinking that perhaps this is a good idea, it just needs some community refinement. Andy From michael.dillon at bt.com Wed Jan 16 10:00:59 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 09:00:59 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478D9976.4020600@nethinks.com> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> Message-ID: > - small one-time fee (100-200EUR?) for non-routable PI (take > them out of a defined /32 or so which is/can/should be > filtered by ISPs) What is non-routable PI? What can you do with it that you cannot do with a ULA prefix? --Michael Dillon From elmi at 4ever.de Wed Jan 16 10:21:06 2008 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 16 Jan 2008 10:21:06 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478D9976.4020600@nethinks.com> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> Message-ID: <20080116092106.GM23974@ronin.4ever.de> Hi Garry, second all of this... garry at nethinks.com (Garry Glendown) wrote: > - /48, not /56 > - small yearly fee (100-200??) for routable PI > - small one-time fee (100-200??) for non-routable PI (take them out of a > defined /32 or so which is/can/should be filtered by ISPs) > - don't automatically distribute IPv6 space (both PI and LIRs) - e.g., > our customers with PI I don't see using IPv6 within at least the next 5 > years (we've had v6 available for several years ...). Instead, make > initial v6 applications and allocations "painless", allowing for any PI > owners to just "lift their hand" and they receive their v6-PI (/48) for > just paying ;) ...but: Don't forget the LIRs-that-have-no-customers, please. We're in this peculiar situation: We are heavily multihomed in v4 but cannot get any v6; we have to make do with an assignment from one of our transits and agreements with the others to carry that assignment separately (and not filter it). Yours, Elmi. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fr?nzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]--- From timothy.clarke at thecloud.net Wed Jan 16 10:33:19 2008 From: timothy.clarke at thecloud.net (Timothy Clarke) Date: Wed, 16 Jan 2008 09:33:19 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080116092106.GM23974@ronin.4ever.de> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <20080116092106.GM23974@ronin.4ever.de> Message-ID: <71CBBB1D828DB747BAF4B5362878A03703992551@ebe1.corp.thecloud.net> Isn't that the point of 2008-02, LIR's without customers can then get IPv6 -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Elmar K. Bins Sent: 16 January 2008 09:21 To: Garry Glendown Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) Hi Garry, second all of this... garry at nethinks.com (Garry Glendown) wrote: > - /48, not /56 > - small yearly fee (100-200??) for routable PI > - small one-time fee (100-200??) for non-routable PI (take them out of a > defined /32 or so which is/can/should be filtered by ISPs) > - don't automatically distribute IPv6 space (both PI and LIRs) - e.g., > our customers with PI I don't see using IPv6 within at least the next 5 > years (we've had v6 available for several years ...). Instead, make > initial v6 applications and allocations "painless", allowing for any PI > owners to just "lift their hand" and they receive their v6-PI (/48) for > just paying ;) ...but: Don't forget the LIRs-that-have-no-customers, please. We're in this peculiar situation: We are heavily multihomed in v4 but cannot get any v6; we have to make do with an assignment from one of our transits and agreements with the others to carry that assignment separately (and not filter it). Yours, Elmi. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fr?nzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]--- - - - - - - - - - - - - - - - - - - - - The Cloud Networks Limited is registered in England and Wales with registered number 5141256 and registered office at 54 - 58 Bartholomew Close London EC1A 7HP, United Kingdom. The registered VAT number is GB/839621406. This e-mail and any attachments contain information that may be privileged or confidential and is the property of The Cloud Networks Limited. If you are not the intended recipient, please notify the sender immediately by replying to this e-mail, and then delete it. Any unauthorised dissemination, distribution, copying or use of this communication is strictly prohibited. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. Although this e-mail and any files attached to it may have been checked with virus detection software before transmission you should carry out your own virus checks before opening the attachment. No liability can be accepted for any damage which you may sustain as a result of software viruses. - - - - - - - - - - - - - - - - - - - - Please consider the environment before printing this email From elmi at 4ever.de Wed Jan 16 10:36:50 2008 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 16 Jan 2008 10:36:50 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <71CBBB1D828DB747BAF4B5362878A03703992551@ebe1.corp.thecloud.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <20080116092106.GM23974@ronin.4ever.de> <71CBBB1D828DB747BAF4B5362878A03703992551@ebe1.corp.thecloud.net> Message-ID: <20080116093650.GR23974@ronin.4ever.de> timothy.clarke at thecloud.net (Timothy Clarke) wrote: > Isn't that the point of 2008-02, LIR's without customers can then get IPv6 I vaguely remember, so yep, let's nullify my point in the discussion about 2008-01 ;-) So I simply second Garry's points *g* Yours, Elmar From garry at nethinks.com Wed Jan 16 10:56:42 2008 From: garry at nethinks.com (Garry Glendown) Date: Wed, 16 Jan 2008 10:56:42 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> Message-ID: <478DD4DA.5030804@nethinks.com> michael.dillon at bt.com wrote: >> - small one-time fee (100-200EUR?) for non-routable PI (take >> them out of a defined /32 or so which is/can/should be >> filtered by ISPs) >> > What is non-routable PI? > What can you do with it that you cannot do with a ULA prefix? > Not routed for things like VPN-Connections and the likes ... users sometimes need unique IP addresses, as the chance of running into a customer/partner that happens to use the same RFC networks is growing ... IPv6 will make the chances smaller, but getting a PI assigned for such purposes would eliminate that problem. -garry From garry at nethinks.com Wed Jan 16 10:55:25 2008 From: garry at nethinks.com (Garry Glendown) Date: Wed, 16 Jan 2008 10:55:25 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> Message-ID: <478DD48D.3040505@nethinks.com> michael.dillon at bt.com wrote: >> - small one-time fee (100-200EUR?) for non-routable PI (take >> them out of a defined /32 or so which is/can/should be >> filtered by ISPs) >> > What is non-routable PI? > What can you do with it that you cannot do with a ULA prefix? > Not routed for things like VPN-Connections and the likes ... users sometimes need unique IP addresses, as the chance of running into a customer/partner that happens to use the same RFC networks is growing ... IPv6 will make the chances smaller, but getting a PI assigned for such purposes would eliminate that problem. -garry From tjc at ecs.soton.ac.uk Wed Jan 16 10:05:07 2008 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 16 Jan 2008 09:05:07 +0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> Message-ID: <20080116090507.GB15401@login.ecs.soton.ac.uk> On Wed, Jan 16, 2008 at 09:00:59AM -0000, michael.dillon at bt.com wrote: > > - small one-time fee (100-200EUR?) for non-routable PI (take > > them out of a defined /32 or so which is/can/should be > > filtered by ISPs) > > What is non-routable PI? > What can you do with it that you cannot do with a ULA prefix? I assume this is C-ULA, i.e. supposedly guaranteed unique ULA. -- Tim From drixter at e-utp.net Wed Jan 16 11:13:40 2008 From: drixter at e-utp.net (Marcin Gondek) Date: Wed, 16 Jan 2008 11:13:40 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> Message-ID: <478DD8D4.9040108@e-utp.net> Mikael Abrahamsson pisze: > >> - 100E yearly maintenance > > If not higher. Hidden cost to the community is much much higher as > each PI announcement translates (in the long run) to more expensive > routing platforms. > > We made a boo-boo with IPv4 in the PI area, let's not do it again with > IPv6. Assign real cost to having a slot in the global DFZ. That way > people that really really need PI will pay it (at 1000E a year it's > still a win situation at a few tens of work hours) and the ones who do > not, will not clutter the DFZ. > If the price will be higher, then everybody join to RIPE as LIR. And then we will have +1000% of LIRs. Do "we" need this? Now everybody is waiting for some kind of statesment or procedure from RIPE side. -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 office at e-utp.net http://www.e-utp.net From drixter at e-utp.net Wed Jan 16 12:04:20 2008 From: drixter at e-utp.net (Marcin Gondek) Date: Wed, 16 Jan 2008 12:04:20 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478DDD03.8050101@nethinks.com> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478DD8D4.9040108@e-utp.net> <478DDD03.8050101@nethinks.com> Message-ID: <478DE4B4.4010709@e-utp.net> Garry Glendown pisze: > Marcin Gondek wrote: >> If the price will be higher, then everybody join to RIPE as LIR. And >> then we will have +1000% of LIRs. Do "we" need this? >> Now everybody is waiting for some kind of statesment or procedure >> from RIPE side. >> > Price should be low enough to keep people from becoming an LIR > unnecessarily, but high enough to make them think twice about getting > space that they don't need ;) > Indeed -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 office at e-utp.net http://www.e-utp.net From swmike at swm.pp.se Wed Jan 16 12:06:54 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 16 Jan 2008 12:06:54 +0100 (CET) Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478DD8D4.9040108@e-utp.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478DD8D4.9040108@e-utp.net> Message-ID: On Wed, 16 Jan 2008, Marcin Gondek wrote: > If the price will be higher, then everybody join to RIPE as LIR. And > then we will have +1000% of LIRs. Do "we" need this? Now everybody is > waiting for some kind of statesment or procedure from RIPE side. I don't really care, I want that there should be a recurring cost involved with having a route in DFZ. If that money goes to RIPE, so be it. I know people today that could renumber to another /24 from their existing /24 in a matter of a few hours, yet they still have a /24 PI for convenience. If the cost was 1000EUR per year (doesn't matter if it's LIR membership cost or something else) only people that actually value this highly will have it. It might be coupled to having a route object attached to the IP space in question that actually triggers the cost, so people who need PI but who are not going to announce them can have them for free. I would happily advocate this for IPv4 as well but I think that train left the station long ago. -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Wed Jan 16 12:23:16 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 11:23:16 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478DD4DA.5030804@nethinks.com> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> Message-ID: > > What is non-routable PI? > > What can you do with it that you cannot do with a ULA prefix? > > > Not routed for things like VPN-Connections and the likes ... > users sometimes need unique IP addresses, as the chance of > running into a customer/partner that happens to use the same > RFC networks is growing ... IPv6 will make the chances > smaller, but getting a PI assigned for such purposes would > eliminate that problem. If you look at current RIPE policies, they imply that all PI address blocks may not be routable on the Internet. LIRs are supposed to warn applicants about this when they issue the PI block. Of course, in most cases, the PI blocks are routable because in most cases, if you announce the block, providers will accept the announcement. The need for such extranet addresses is a good reason for RIPE to allow PI allocations/assignments of IPv6 addresses but 2008-01 is the wrong way to go about it. Here is my wish list for IPv6 PI: - No PI assignments via LIRs. LIRs only manage PA IPv6. - special membership in RIPE with an annual fee for PI holders - contract signed between RIPE and PI holders that covers fee payments, and revocation/return of address blocks - special known superblock from which all PI allocations are made so that people can manage their filters - /48 minimum PI allocation but larger aggregate is also possible - contact every IPv4 PI holder by email and inform them of the new rules for IPv6 PI allocations In my opinion that should be followed by another policy change which requires RIPE membership, annual fee payment and a signed contract for any future ASN assignments or IPv4 PI address blocks. --Michael Dillon From michael.dillon at bt.com Wed Jan 16 12:25:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 11:25:42 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080116090507.GB15401@login.ecs.soton.ac.uk> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <20080116090507.GB15401@login.ecs.soton.ac.uk> Message-ID: > > What is non-routable PI? > > What can you do with it that you cannot do with a ULA prefix? > > I assume this is C-ULA, i.e. supposedly guaranteed unique ULA. No. The only kind of ULA addresses which exist today are the randomly generated prefixes. If RIPE allows IPv6 PI allocations then there will be no need for any kind of C-ULA. --Michael Dillon From michael.dillon at bt.com Wed Jan 16 12:27:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 11:27:51 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478DD8D4.9040108@e-utp.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478DD8D4.9040108@e-utp.net> Message-ID: > If the price will be higher, then everybody join to RIPE as > LIR. And then we will have +1000% of LIRs. Do "we" need this? > Now everybody is waiting for some kind of statesment or > procedure from RIPE side. If the organizations which receive IPv6 PI allocations, join RIPE and sign a contract and pay an annual fee, they would not be LIRs (Local Internet Registries) because they will not have the right to reassign parts of their address allocation. RIPE needs to have another class of member that is not an LIR. --Michael Dillon From drixter at e-utp.net Wed Jan 16 12:26:41 2008 From: drixter at e-utp.net (Marcin Gondek) Date: Wed, 16 Jan 2008 12:26:41 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478DD8D4.9040108@e-utp.net> Message-ID: <478DE9F1.3030608@e-utp.net> michael.dillon at bt.com pisze: >> If the price will be higher, then everybody join to RIPE as >> LIR. And then we will have +1000% of LIRs. Do "we" need this? >> Now everybody is waiting for some kind of statesment or >> procedure from RIPE side. >> > > If the organizations which receive IPv6 PI allocations, join RIPE > and sign a contract and pay an annual fee, they would not be > LIRs (Local Internet Registries) because they will not have the > right to reassign parts of their address allocation. > > RIPE needs to have another class of member that is not an LIR. > > Ok, who will make it? RIPE itself or "we" need another proposal? -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 office at e-utp.net http://www.e-utp.net From jeroen at unfix.org Wed Jan 16 12:50:29 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 16 Jan 2008 12:50:29 +0100 Subject: [address-policy-wg] New correct proposal (Was: 2008-01/2008-02) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> Message-ID: <478DEF85.5000201@spaghetti.zurich.ibm.com> michael.dillon at bt.com wrote: [..] > Here is my wish list for IPv6 PI: > > - No PI assignments via LIRs. LIRs only manage PA IPv6. > - special membership in RIPE with an annual fee for PI holders > - contract signed between RIPE and PI holders that covers fee > payments, and revocation/return of address blocks > - special known superblock from which all PI allocations are made > so that people can manage their filters > - /48 minimum PI allocation but larger aggregate is also possible > - contact every IPv4 PI holder by email and inform them of the > new rules for IPv6 PI allocations > > In my opinion that should be followed by another policy change > which requires RIPE membership, annual fee payment and a signed > contract for any future ASN assignments or IPv4 PI address blocks. Now *THAT* is a solid policy proposal that I would be willing to support. The 2008-01/2008-02 though should be binned directly and should have never seen daylight in the first place. (though it is good to again start discussions of course :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From timothy.clarke at thecloud.net Wed Jan 16 13:05:07 2008 From: timothy.clarke at thecloud.net (Timothy Clarke) Date: Wed, 16 Jan 2008 12:05:07 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> Message-ID: <71CBBB1D828DB747BAF4B5362878A03703992685@ebe1.corp.thecloud.net> 2008-01 The only questions that then are raised are what happens when some one with PI refuses to pay, misses payment etc and the space gets revoked? When a customer comes to an ISP saying I have a PI and here is my prefix. I'm assuming most ISP's do a DB lookup to confirm those details are correct, before advertising, are we saying RIPE now need to notify ISP's that a prefix should be withdrawn because it hasn't been paid for ? Depending on the cost / importance of the contract with the ISP are they going to pay these fees? Will the fees be part of the ISP's contract so avoid the situation above? As for the whole non-routable question. Would the block then be charged at a different rate because there won't be additional cost of a route entry in the global table? Should there then be an extra field in the object saying this is a non routable range (Yes the space comes from what SHOULD be routable) ? The give an ASN with a PI question should be rejected, a bunch of places want PI for multi-homing reasons but want nothing to do with BGP, that's why they buy a managed service. If someone wants an ASN, what's wrong with the current rules ? As for the renumbering question, don't assume it's always easy. For a web server or mail server or similar, fine. DNS servers slightly harder, but doable. We do WiFi with RFC1918 space and NAT (on IPv4), most European WISP's do. We have a few thousand VPN's for this, trying to move them is simply too costly without significant reason. It would be easier and cheaper for us to setup a new legal entity on each country we operate then to migrate these connections. 2008-02 The point some are trying to make is there are few LIR's that can fully justify IPv6 PA space right now because they don't have the customers. Perhaps the policy needs to change for the initial IPv6 PA so new & existing LIR's can get IPv6 even if they have no customers. Tim -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of michael.dillon at bt.com Sent: 16 January 2008 11:23 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) > > What is non-routable PI? > > What can you do with it that you cannot do with a ULA prefix? > > > Not routed for things like VPN-Connections and the likes ... > users sometimes need unique IP addresses, as the chance of > running into a customer/partner that happens to use the same > RFC networks is growing ... IPv6 will make the chances > smaller, but getting a PI assigned for such purposes would > eliminate that problem. If you look at current RIPE policies, they imply that all PI address blocks may not be routable on the Internet. LIRs are supposed to warn applicants about this when they issue the PI block. Of course, in most cases, the PI blocks are routable because in most cases, if you announce the block, providers will accept the announcement. The need for such extranet addresses is a good reason for RIPE to allow PI allocations/assignments of IPv6 addresses but 2008-01 is the wrong way to go about it. Here is my wish list for IPv6 PI: - No PI assignments via LIRs. LIRs only manage PA IPv6. - special membership in RIPE with an annual fee for PI holders - contract signed between RIPE and PI holders that covers fee payments, and revocation/return of address blocks - special known superblock from which all PI allocations are made so that people can manage their filters - /48 minimum PI allocation but larger aggregate is also possible - contact every IPv4 PI holder by email and inform them of the new rules for IPv6 PI allocations In my opinion that should be followed by another policy change which requires RIPE membership, annual fee payment and a signed contract for any future ASN assignments or IPv4 PI address blocks. --Michael Dillon - - - - - - - - - - - - - - - - - - - - The Cloud Networks Limited is registered in England and Wales with registered number 5141256 and registered office at 54 - 58 Bartholomew Close London EC1A 7HP, United Kingdom. The registered VAT number is GB/839621406. This e-mail and any attachments contain information that may be privileged or confidential and is the property of The Cloud Networks Limited. If you are not the intended recipient, please notify the sender immediately by replying to this e-mail, and then delete it. Any unauthorised dissemination, distribution, copying or use of this communication is strictly prohibited. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. Although this e-mail and any files attached to it may have been checked with virus detection software before transmission you should carry out your own virus checks before opening the attachment. No liability can be accepted for any damage which you may sustain as a result of software viruses. - - - - - - - - - - - - - - - - - - - - Please consider the environment before printing this email -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2259 bytes Desc: not available URL: From michael.dillon at bt.com Wed Jan 16 13:34:29 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 12:34:29 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <71CBBB1D828DB747BAF4B5362878A03703992685@ebe1.corp.thecloud.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <71CBBB1D828DB747BAF4B5362878A03703992685@ebe1.corp.thecloud.net> Message-ID: > When a customer comes to an ISP saying I have a PI and here > is my prefix. > I'm assuming most ISP's do a DB lookup to confirm those > details are correct, before advertising, are we saying RIPE > now need to notify ISP's that a prefix should be withdrawn > because it hasn't been paid for ? Why should RIPE notify anyone when the PI block has already been removed from the RIPE DB? > Depending on the cost / importance of the contract with the > ISP are they going to pay these fees? Will the fees be part > of the ISP's contract so avoid the situation above? The contract between RIPE and the holder of the PI block does not involve the ISP at all. I know that IPv4 PIs are currently acquired through an ISP but I am suggesting that we stop this practice, and for IPv6 PI allocations, we only do them with a direct two-party contractual and commercial relationship between the PI holder and RIPE. > As for the whole non-routable question. Would the block then > be charged at a different rate because there won't be > additional cost of a route entry in the global table? Not at all. Routability is a choice that the PI holder makes. Nothing that RIPE does has any effect on routability. > The point some are trying to make is there are few LIR's that > can fully justify IPv6 PA space right now because they don't > have the customers. There is no customer requirement to get IPv6 PA space. > Perhaps the policy needs to change for the initial IPv6 PA so > new & existing LIR's can get IPv6 even if they have no customers. They already can do this. --Michael Dillon From marcoh at marcoh.net Wed Jan 16 14:09:59 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Jan 2008 14:09:59 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> Message-ID: <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> On Jan 16, 2008, at 12:23 PM, wrote: > The need for such extranet addresses is a good reason for > RIPE to allow PI allocations/assignments of IPv6 addresses > but 2008-01 is the wrong way to go about it. > > Here is my wish list for IPv6 PI: > > - No PI assignments via LIRs. LIRs only manage PA IPv6. > - special membership in RIPE with an annual fee for PI holders > - contract signed between RIPE and PI holders that covers fee > payments, and revocation/return of address blocks > - special known superblock from which all PI allocations are made > so that people can manage their filters > - /48 minimum PI allocation but larger aggregate is also possible > - contact every IPv4 PI holder by email and inform them of the > new rules for IPv6 PI allocations > > In my opinion that should be followed by another policy change > which requires RIPE membership, annual fee payment and a signed > contract for any future ASN assignments or IPv4 PI address blocks. Not a bad proposal, but where does this actually differ from becoming a LIR, except for a change in minimum allocation sizes ? Next to that I see a huge increase in administrative load for the NCC which could result in bigger financial risks which in turn ends up at the LIR's. -- MarcoH From shane at time-travellers.org Wed Jan 16 13:52:42 2008 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 16 Jan 2008 13:52:42 +0100 Subject: [address-policy-wg] New correct proposal (Was: 2008-01/2008-02) In-Reply-To: <478DEF85.5000201@spaghetti.zurich.ibm.com> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <478DEF85.5000201@spaghetti.zurich.ibm.com> Message-ID: <20080116125242.GB32084@borg.c-l-i.net> On Wed, Jan 16, 2008 at 12:50:29PM +0100, Jeroen Massar wrote: > michael.dillon at bt.com wrote: > [..] > >Here is my wish list for IPv6 PI: > > > >- No PI assignments via LIRs. LIRs only manage PA IPv6. > >- special membership in RIPE with an annual fee for PI holders > >- contract signed between RIPE and PI holders that covers fee > > payments, and revocation/return of address blocks > >- special known superblock from which all PI allocations are made > > so that people can manage their filters > >- /48 minimum PI allocation but larger aggregate is also possible > >- contact every IPv4 PI holder by email and inform them of the > > new rules for IPv6 PI allocations > > > >In my opinion that should be followed by another policy change > >which requires RIPE membership, annual fee payment and a signed > >contract for any future ASN assignments or IPv4 PI address blocks. > > Now *THAT* is a solid policy proposal that I would be willing to support. I agree completely. -- Shane From shane at time-travellers.org Wed Jan 16 14:37:29 2008 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 16 Jan 2008 14:37:29 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> Message-ID: <20080116133729.GA32671@borg.c-l-i.net> Marco, On Wed, Jan 16, 2008 at 02:09:59PM +0100, Marco Hogewoning wrote: > > On Jan 16, 2008, at 12:23 PM, > wrote: > > >The need for such extranet addresses is a good reason for > >RIPE to allow PI allocations/assignments of IPv6 addresses > >but 2008-01 is the wrong way to go about it. > > > >Here is my wish list for IPv6 PI: > > > >- No PI assignments via LIRs. LIRs only manage PA IPv6. > >- special membership in RIPE with an annual fee for PI holders > >- contract signed between RIPE and PI holders that covers fee > > payments, and revocation/return of address blocks > >- special known superblock from which all PI allocations are made > > so that people can manage their filters > >- /48 minimum PI allocation but larger aggregate is also possible > >- contact every IPv4 PI holder by email and inform them of the > > new rules for IPv6 PI allocations > > > >In my opinion that should be followed by another policy change > >which requires RIPE membership, annual fee payment and a signed > >contract for any future ASN assignments or IPv4 PI address blocks. > > Not a bad proposal, but where does this actually differ from > becoming a LIR, except for a change in minimum allocation sizes ? The difference is that right now there is a number of assignments that are "orphaned". There was a relationship: RIPE NCC -> LIR -> end user But either the relationship between the RIPE NCC and the LIR ended, or the relationship between the LIR and the end user ended. In either case, now there is no way to manage the use of the number resource. By simplifying the relationship: RIPE NCC -> end user We know the status of the space at all times. > Next to that I see a huge increase in administrative load for the > NCC which could result in bigger financial risks which in turn ends > up at the LIR's. Depends on how it is done. There are millions of domain names, and these only cost 10 euros a year. :) -- Shane From marcoh at marcoh.net Wed Jan 16 14:47:31 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Jan 2008 14:47:31 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080116133729.GA32671@borg.c-l-i.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> Message-ID: <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> On Jan 16, 2008, at 2:37 PM, Shane Kerr wrote: Hi Shane, > Marco, > > On Wed, Jan 16, 2008 at 02:09:59PM +0100, Marco Hogewoning wrote: >> >> On Jan 16, 2008, at 12:23 PM, >> wrote: >> >>> The need for such extranet addresses is a good reason for >>> RIPE to allow PI allocations/assignments of IPv6 addresses >>> but 2008-01 is the wrong way to go about it. >>> >>> Here is my wish list for IPv6 PI: >>> >>> - No PI assignments via LIRs. LIRs only manage PA IPv6. >>> - special membership in RIPE with an annual fee for PI holders >>> - contract signed between RIPE and PI holders that covers fee >>> payments, and revocation/return of address blocks >>> - special known superblock from which all PI allocations are made >>> so that people can manage their filters >>> - /48 minimum PI allocation but larger aggregate is also possible >>> - contact every IPv4 PI holder by email and inform them of the >>> new rules for IPv6 PI allocations >>> >>> In my opinion that should be followed by another policy change >>> which requires RIPE membership, annual fee payment and a signed >>> contract for any future ASN assignments or IPv4 PI address blocks. >> >> Not a bad proposal, but where does this actually differ from >> becoming a LIR, except for a change in minimum allocation sizes ? > > The difference is that right now there is a number of assignments that > are "orphaned". > > There was a relationship: > > RIPE NCC -> LIR -> end user > > But either the relationship between the RIPE NCC and the LIR ended, or > the relationship between the LIR and the end user ended. In either > case, now there is no way to manage the use of the number resource. > > By simplifying the relationship: > > RIPE NCC -> end user > > We know the status of the space at all times. That was already clear, but if, as an end-user, I have to get a contract with the NCC to obtain PI space, there ain't much difference to becoming an LIR. There could be some difference in cost, but that would only mean that as a small ISP it might be cheaper to get PI space. >> Next to that I see a huge increase in administrative load for the >> NCC which could result in bigger financial risks which in turn ends >> up at the LIR's. > > Depends on how it is done. There are millions of domain names, and > these only cost 10 euros a year. :) And how many get cancelled each year because they are not being paid for, and if they do it's much easier to remove a domain name from the internet. Unless there would be an active system with signatures it's very hard to make sure cancelled PI/PA blocks will disappear from the DFZ. Second to that, most TLD's also use a tiered solution where as an end- user you need to get in contact with a member/reseller to get a name registered. Grt, -- MarcoH From timothy.clarke at thecloud.net Wed Jan 16 14:09:29 2008 From: timothy.clarke at thecloud.net (Timothy Clarke) Date: Wed, 16 Jan 2008 13:09:29 +0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <71CBBB1D828DB747BAF4B5362878A03703992685@ebe1.corp.thecloud.net> Message-ID: <478E0209.8070406@thecloud.net> michael.dillon at bt.com wrote: >> When a customer comes to an ISP saying I have a PI and here >> is my prefix. >> I'm assuming most ISP's do a DB lookup to confirm those >> details are correct, before advertising, are we saying RIPE >> now need to notify ISP's that a prefix should be withdrawn >> because it hasn't been paid for ? > > Why should RIPE notify anyone when the PI block has already > been removed from the RIPE DB? > >> Depending on the cost / importance of the contract with the >> ISP are they going to pay these fees? Will the fees be part >> of the ISP's contract so avoid the situation above? > > The contract between RIPE and the holder of the PI block does > not involve the ISP at all. I know that IPv4 PIs are currently > acquired through an ISP but I am suggesting that we stop this > practice, and for IPv6 PI allocations, we only do them with > a direct two-party contractual and commercial relationship > between the PI holder and RIPE. > >> As for the whole non-routable question. Would the block then >> be charged at a different rate because there won't be >> additional cost of a route entry in the global table? > > Not at all. Routability is a choice that the PI holder makes. > Nothing that RIPE does has any effect on routability. My whole point (as flawed as it may be) is, If RIPE is going to charge Annual fees for PI is it a) Cheaper if you're never going to have it in the global routing table (that seems to be the idea behind charging for PI)? b) What happens when someone stops paying RIPE but keeps using their PI? > >> The point some are trying to make is there are few LIR's that >> can fully justify IPv6 PA space right now because they don't >> have the customers. > > There is no customer requirement to get IPv6 PA space. > >> Perhaps the policy needs to change for the initial IPv6 PA so >> new & existing LIR's can get IPv6 even if they have no customers. > > They already can do this. I guess I was looking at an out of date document. I've just found. From http://www.ripe.net/ripe/docs/ripe-421.html 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: * a) be an LIR; * b) advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet; * c) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. From michael.dillon at bt.com Wed Jan 16 15:24:26 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 14:24:26 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> Message-ID: > And how many get cancelled each year because they are not > being paid for, and if they do it's much easier to remove a > domain name from the internet. Unless there would be an > active system with signatures it's very hard to make sure > cancelled PI/PA blocks will disappear from the DFZ. First of all, if a PI block is not paid for it will disappear from RIPE's DB. I would expect many ISPs to have an internal process for IPv6 Peering customers to regularly check the DB. Also, there are a number of groups which regularly analyze BGP announcements looking for things like bogons and ghost-routes. I would expect one or more of those groups to include unregistered PI blocks in their reporting. A greater number of ISPs will probably track these reports to make sure that they are following best practices. --Michael Dillon From michael.dillon at bt.com Wed Jan 16 15:27:41 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 14:27:41 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <478E0209.8070406@thecloud.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <71CBBB1D828DB747BAF4B5362878A03703992685@ebe1.corp.thecloud.net> <478E0209.8070406@thecloud.net> Message-ID: > b) What happens when someone stops paying RIPE but keeps > using their PI? They lose the PI. RIPE deletes it from the DB. If they want to use it on the Internet, it becomes very difficult because many ISPs will not accept the route announcements. If they want to use it on a VPN extranet, they lose the global uniqueness property and if this PI is allocated to one of their trading partners, that trading partner will win the argument. This type of collision can cause a multi-million euro contract to be lost. --Michael Dillon From mohacsi at niif.hu Wed Jan 16 15:24:37 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 16 Jan 2008 15:24:37 +0100 (CET) Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> Message-ID: <20080116152257.T50988@mignon.ki.iif.hu> On Wed, 16 Jan 2008, michael.dillon at bt.com wrote: >> And how many get cancelled each year because they are not >> being paid for, and if they do it's much easier to remove a >> domain name from the internet. Unless there would be an >> active system with signatures it's very hard to make sure >> cancelled PI/PA blocks will disappear from the DFZ. > > First of all, if a PI block is not paid for it will disappear > from RIPE's DB. I would expect many ISPs to have an internal > process for IPv6 Peering customers to regularly check the DB. > > Also, there are a number of groups which regularly analyze BGP > announcements looking for things like bogons and ghost-routes. > I would expect one or more of those groups to include unregistered > PI blocks in their reporting. A greater number of ISPs will > probably track these reports to make sure that they are > following best practices. Alternatively, PI holders should pay few (> 5) years IPv6 PI registration fee in advance... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From info at streamservice.nl Wed Jan 16 15:23:30 2008 From: info at streamservice.nl (Stream Service || Mark Scholten) Date: Wed, 16 Jan 2008 15:23:30 +0100 Subject: [address-policy-wg] New correct proposal (Was: 2008-01/2008-02) In-Reply-To: <20080116125242.GB32084@borg.c-l-i.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <478DEF85.5000201@spaghetti.zurich.ibm.com> <20080116125242.GB32084@borg.c-l-i.net> Message-ID: <5EB5A1E954B446FCA876DDD7C1D53264@laptopmark> A PI assignments via LIR's should be possible (make both options possible?) if you ask me and also the costs will go via the LIR in that case. A holder off PI space should be allowed to offer PA space to clients (but no special routing for the clients!). So it is only different in the RIPE NCC whois database and not in the routing table. With kind regards, Met vriendelijke groet, Mark Scholten Stream Service Web: http://www.streamservice.nl/ E-mail: mark at streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc at streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Shane Kerr" To: Sent: Wednesday, January 16, 2008 1:52 PM Subject: Re: [address-policy-wg] New correct proposal (Was: 2008-01/2008-02) On Wed, Jan 16, 2008 at 12:50:29PM +0100, Jeroen Massar wrote: > michael.dillon at bt.com wrote: > [..] > >Here is my wish list for IPv6 PI: > > > >- No PI assignments via LIRs. LIRs only manage PA IPv6. > >- special membership in RIPE with an annual fee for PI holders > >- contract signed between RIPE and PI holders that covers fee > > payments, and revocation/return of address blocks > >- special known superblock from which all PI allocations are made > > so that people can manage their filters > >- /48 minimum PI allocation but larger aggregate is also possible > >- contact every IPv4 PI holder by email and inform them of the > > new rules for IPv6 PI allocations > > > >In my opinion that should be followed by another policy change > >which requires RIPE membership, annual fee payment and a signed > >contract for any future ASN assignments or IPv4 PI address blocks. > > Now *THAT* is a solid policy proposal that I would be willing to support. I agree completely. -- Shane From jeroen at unfix.org Wed Jan 16 15:33:12 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 16 Jan 2008 15:33:12 +0100 Subject: [address-policy-wg] New correct proposal (Was: 2008-01/2008-02) In-Reply-To: <5EB5A1E954B446FCA876DDD7C1D53264@laptopmark> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <478DEF85.5000201@spaghetti.zurich.ibm.com> <20080116125242.GB32084@borg.c-l-i.net> <5EB5A1E954B446FCA876DDD7C1D53264@laptopmark> Message-ID: <478E15A8.7030808@spaghetti.zurich.ibm.com> Stream Service || Mark Scholten wrote: > A PI assignments via LIR's should be possible (make both options possible?) > if you ask me and also the costs will go via the LIR in that case. That is called PA. The "I" in PI is for "Independent", it is for people who don't want to/can't rely on external organizations. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From garry at nethinks.com Wed Jan 16 15:33:59 2008 From: garry at nethinks.com (Garry Glendown) Date: Wed, 16 Jan 2008 15:33:59 +0100 Subject: [address-policy-wg] New correct proposal (Was: 2008-01/2008-02) In-Reply-To: <5EB5A1E954B446FCA876DDD7C1D53264@laptopmark> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <478DEF85.5000201@spaghetti.zurich.ibm.com> <20080116125242.GB32084@borg.c-l-i.net> <5EB5A1E954B446FCA876DDD7C1D53264@laptopmark> Message-ID: <478E15D7.5010303@nethinks.com> Stream Service || Mark Scholten wrote: > A PI assignments via LIR's should be possible (make both options possible?) > if you ask me and also the costs will go via the LIR in that case. > ... for which you'd have to have some kind of provision to transfer the billing partner in case the user switches LIRs ... or gets a new provider that isn't a RIPE LIR ... > A holder off PI space should be allowed to offer PA space to clients (but no > special routing for the clients!). So it is only different in the RIPE NCC > whois database and not in the routing table. > What do you mean here? Assign subnets out of a PI to customers? Why should RIPE even bother getting involved? -garry From marcoh at marcoh.net Wed Jan 16 15:53:20 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Jan 2008 15:53:20 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> Message-ID: <4C6177DC-49FB-4C74-8B41-6142C9256518@marcoh.net> On Jan 16, 2008, at 3:24 PM, wrote: >> And how many get cancelled each year because they are not >> being paid for, and if they do it's much easier to remove a >> domain name from the internet. Unless there would be an >> active system with signatures it's very hard to make sure >> cancelled PI/PA blocks will disappear from the DFZ. > > First of all, if a PI block is not paid for it will disappear > from RIPE's DB. I would expect many ISPs to have an internal > process for IPv6 Peering customers to regularly check the DB. > > Also, there are a number of groups which regularly analyze BGP > announcements looking for things like bogons and ghost-routes. > I would expect one or more of those groups to include unregistered > PI blocks in their reporting. A greater number of ISPs will > probably track these reports to make sure that they are > following best practices. Next to the fact there is a limit on how many routes a forwardingtable will hold, there is an equal set of limitations on how big a route-map can grow. There is a big contrast as most of the current IPv4 bogon filters simply filter /8's which are either flagged for special use or not allocated yet. You are talking about a set of filters with a resolution of /48 and maybe even /56 in a large chunk of what in the end will become swamp6, the only way to maintain would be if you can trust everybody to check all annoucements from all networks who you are providing transit for. In a perfect world this could happen, but being a bit pessimistic I expect somewhere somebody will bend over, accept the money and forget about standards,policies and the rest of the world. For a working real world example of this mechanism, please check your spamfilter statistics. So, unless I can have my box auto check some signature on prefixes and act accoordingly, I don't see myself configuring a route-map with possibly over 65000 entries to check on a /48 boundry if that prefix is still being paid for. Grt, -- MarcoH From marcoh at marcoh.net Wed Jan 16 16:00:48 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Jan 2008 16:00:48 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> Message-ID: On Jan 16, 2008, at 3:54 PM, Leo Vegoda wrote: > On Jan 16, 2008 2:09 PM, Marco Hogewoning wrote: > > [...] > >> Not a bad proposal, but where does this actually differ from becoming >> a LIR, except for a change in minimum allocation sizes ? > > This was the point I was trying to raise at the last RIPE meeting. I > think it may make sense to make a scalable policy that doesn't have a > distinction between LIRs and enterprises. The border between the two > is porous and a policy that doesn't assume LIRs being significantly > larger than enterprises may be called for. > > I would suggest that instead of two policies we should have one. > > http://www.ripe.net/ripe/meetings/ripe-55/presentations/vegoda-v6-policy.pdf > > Thoughts? You have my vote :) Not that I think it's a strict requirement but the question could be raised if we need to introduce something like a 'NCC customer' next to the current membership to differentiate between those who are actually running an LIR, assigning end-user blocks from a larger aggregate and people simply having one or two single PI blocks which can't hold any suballocations/assignments. -- MarcoH From leo at bind.org Wed Jan 16 15:54:44 2008 From: leo at bind.org (Leo Vegoda) Date: Wed, 16 Jan 2008 15:54:44 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> Message-ID: On Jan 16, 2008 2:09 PM, Marco Hogewoning wrote: [...] > Not a bad proposal, but where does this actually differ from becoming > a LIR, except for a change in minimum allocation sizes ? This was the point I was trying to raise at the last RIPE meeting. I think it may make sense to make a scalable policy that doesn't have a distinction between LIRs and enterprises. The border between the two is porous and a policy that doesn't assume LIRs being significantly larger than enterprises may be called for. I would suggest that instead of two policies we should have one. http://www.ripe.net/ripe/meetings/ripe-55/presentations/vegoda-v6-policy.pdf Thoughts? Leo Vegoda From lutz at iks-jena.de Tue Jan 15 20:45:58 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 15 Jan 2008 19:45:58 +0000 (UTC) Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) References: <478CE129.4060608@imate.fi> Message-ID: * Jarno L?hteenm?ki wrote: > Does this proposal really mean that every inetnum object holder will get > IPv6 PI block? Yes. > Or should it mean that every PI assignment holder gets also IPv6 PI > assignment? No. IPv4 PI is not special in this case. Please allow me to not participate in the discussion for the first few days. Some arguments are better discussed without me. If necessary I'll clarify the proposal as above. From gert at space.net Wed Jan 16 18:15:14 2008 From: gert at space.net (Gert Doering) Date: Wed, 16 Jan 2008 18:15:14 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478DD8D4.9040108@e-utp.net> Message-ID: <20080116171514.GY69215@Space.Net> Hi, On Wed, Jan 16, 2008 at 12:06:54PM +0100, Mikael Abrahamsson wrote: > I would happily advocate this for IPv4 as well but I think that train left > the station long ago. Actually, 2007-01 aims for both IPv4 and IPv6, and I really hope we can make some progress there. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 110584 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 president at ukraine.su Wed Jan 16 18:28:02 2008 From: president at ukraine.su (Max Tulyev) Date: Wed, 16 Jan 2008 19:28:02 +0200 Subject: [address-policy-wg] "Dirty" recycled network assigned Message-ID: <478E3EA2.6000902@ukraine.su> Hello All, I just got an assignment for my client (large PI block). But this block is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as dynamic DHCP pool of other big ISP. So my client says they can't use this network, because mail service is blocked. RIPE rejected my request to change this network to another one: "As we do understand how unfortunate this is for **********, there is nothing we can do about prefixes that appear on so called black lists." How can I solve this? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From fw at deneb.enyo.de Wed Jan 16 18:56:44 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Jan 2008 18:56:44 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: (michael dillon's message of "Wed, 16 Jan 2008 11:23:16 -0000") References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> Message-ID: <87sl0xvelf.fsf@mid.deneb.enyo.de> * michael dillon: > - No PI assignments via LIRs. LIRs only manage PA IPv6. > - special membership in RIPE with an annual fee for PI holders How do you handle lack of payment? Reuse the prefix? That seems like a bad idea to me. I would also see a mandate to keep current address information, including legal details (register of companies number etc.) in the WHOIS database. RIPE NCC will investigate cases if proof is presented that something is wrong in the database (bouncing email, non-working phone number, bouncing snail mail, lack of matching entry in the register of companies). > - contact every IPv4 PI holder by email and inform them of the > new rules for IPv6 PI allocations Email addresses are currently optional, AFAICT. It's probably spamming, too. From david.conrad at icann.org Wed Jan 16 18:57:40 2008 From: david.conrad at icann.org (David Conrad) Date: Wed, 16 Jan 2008 09:57:40 -0800 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478E3EA2.6000902@ukraine.su> Message-ID: An "interesting" (in sort of the way the Ebola virus is "interesting") problem that is going to become much more common as we start reallocating previously allocated or otherwise flagged blocks. Leo Vegoda has done a couple of presentations on this. Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8 are going to have. Options I can think of: 1) Get everybody to transition to IPv6 (um, yeah). 2) Get all the folks who are running RBLs/DUNs to update their lists when address status changes (slightly more realistic than (1)). 3) Get everybody to use reputation services like http://www.karmasphere.com/, et al. (no, I'm not affiliated with them) 4) Get RPKI deployed to reduce the need for black list services (um, yeah.) 5) Get the folks who win the draw on prefixes to go around to every black list service themselves (as they discover them) and convince the operator of that list (somehow) to remove them (the default). No good answers I'm aware of... Regards, -drc On 1/16/08 9:28 AM, "Max Tulyev" wrote: > Hello All, > > I just got an assignment for my client (large PI block). But this block > is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as > dynamic DHCP pool of other big ISP. > > So my client says they can't use this network, because mail service is > blocked. > > RIPE rejected my request to change this network to another one: "As we > do understand how unfortunate this is for **********, there is nothing > we can do about prefixes that appear on so called black lists." > > How can I solve this? From leo.vegoda at icann.org Wed Jan 16 19:16:18 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 16 Jan 2008 19:16:18 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <87sl0xvelf.fsf@mid.deneb.enyo.de> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> Message-ID: On 16 Jan 2008, at 18:56, Florian Weimer wrote: > * michael dillon: > >> - No PI assignments via LIRs. LIRs only manage PA IPv6. >> - special membership in RIPE with an annual fee for PI holders > > How do you handle lack of payment? Reuse the prefix? That seems > like a > bad idea to me. If this is a bad idea... > I would also see a mandate to keep current address information, > including legal details (register of companies number etc.) in the > WHOIS > database. RIPE NCC will investigate cases if proof is presented that > something is wrong in the database (bouncing email, non-working phone > number, bouncing snail mail, lack of matching entry in the register of > companies). ... then what is the enforcement mechanism here? You've just defined a system where the RIPE NCC will guarantee the uniqueness of address space for a one-time fee *and* allow registrants to remain anonymous after the first 12 months. I can see a definite market for something like this. Regards, Leo From heather.skanks at gmail.com Wed Jan 16 19:33:36 2008 From: heather.skanks at gmail.com (heather skanks) Date: Wed, 16 Jan 2008 13:33:36 -0500 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: References: <478E3EA2.6000902@ukraine.su> Message-ID: <616812070801161033t72cdbf5ek6e7cdbd229e85baf@mail.gmail.com> In most cases, a note from the new holder of the address space, to the Blacklist - pointing out that the SWIP record has been updated and requesting the entry to be removed is sufficient. Where it isn't sufficient, the holder of the space should contact the organization that they are trying to send mail to and ask to be whitelisted. This is not an RIR problem. The RIR's make no guarantee that the address space will be globally routable. They can't force ISP's to accept routes, and they can't force ISP's or their customers to accept traffic from those addresses. It's not an ISP problem, because it is not a problem of the route being rejected by ISP's. It's a problem of people substituting their own judgment about who to accept mail from, for someone else's opinion. >From the POV of providers, it is our job to deliver the packets from point a to point b. When we give you IP space (or you provide your own) we allow you to source traffic from those IP's, and we deliver packets back to you destined for those IP's. If the folks you want to reach, have decided to implement a 3rd parties blacklist (or even make their own) and deny traffic, that's their own business. It's not up to the RIR's or ISP's to tell other organizations what routes or traffic to accept. --Heather On Jan 16, 2008 12:57 PM, David Conrad wrote: > An "interesting" (in sort of the way the Ebola virus is "interesting") > problem that is going to become much more common as we start reallocating > previously allocated or otherwise flagged blocks. Leo Vegoda has done a > couple of presentations on this. > > Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8 > are going to have. > > Options I can think of: > > 1) Get everybody to transition to IPv6 (um, yeah). > 2) Get all the folks who are running RBLs/DUNs to update their lists when > address status changes (slightly more realistic than (1)). > 3) Get everybody to use reputation services like > http://www.karmasphere.com/, et al. (no, I'm not affiliated with them) > 4) Get RPKI deployed to reduce the need for black list services (um, > yeah.) > 5) Get the folks who win the draw on prefixes to go around to every black > list service themselves (as they discover them) and convince the operator > of > that list (somehow) to remove them (the default). > > No good answers I'm aware of... > > Regards, > -drc > > On 1/16/08 9:28 AM, "Max Tulyev" wrote: > > > Hello All, > > > > I just got an assignment for my client (large PI block). But this block > > is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as > > dynamic DHCP pool of other big ISP. > > > > So my client says they can't use this network, because mail service is > > blocked. > > > > RIPE rejected my request to change this network to another one: "As we > > do understand how unfortunate this is for **********, there is nothing > > we can do about prefixes that appear on so called black lists." > > > > How can I solve this? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From packetgrrl at gmail.com Wed Jan 16 19:40:24 2008 From: packetgrrl at gmail.com (cja@daydream.com) Date: Wed, 16 Jan 2008 11:40:24 -0700 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <616812070801161033t72cdbf5ek6e7cdbd229e85baf@mail.gmail.com> References: <478E3EA2.6000902@ukraine.su> <616812070801161033t72cdbf5ek6e7cdbd229e85baf@mail.gmail.com> Message-ID: My point is that if ARIN has a listing service and ARIN "certifies" that a block can be listed either we have to have a big disclaimer that the block may be blacklisted and it's their problem or maybe we want to mention that it is black listed. If we do nothing and don't at least tell them that we're not certifying that the block is not blacklisted then they could come back and sue us. This is like we currently tell them that we don't guarantee routability. On Jan 16, 2008 11:33 AM, heather skanks wrote: > > In most cases, a note from the new holder of the address space, to the > Blacklist - pointing out that the SWIP record has been updated and > requesting the entry to be removed is sufficient. Where it isn't > sufficient, the holder of the space should contact the organization that > they are trying to send mail to and ask to be whitelisted. > > This is not an RIR problem. The RIR's make no guarantee that the address > space will be globally routable. They can't force ISP's to accept routes, > and they can't force ISP's or their customers to accept traffic from those > addresses. > > It's not an ISP problem, because it is not a problem of the route being > rejected by ISP's. It's a problem of people substituting their own judgment > about who to accept mail from, for someone else's opinion. > > From the POV of providers, it is our job to deliver the packets from point > a to point b. When we give you IP space (or you provide your own) we allow > you to source traffic from those IP's, and we deliver packets back to you > destined for those IP's. If the folks you want to reach, have decided to > implement a 3rd parties blacklist (or even make their own) and deny traffic, > that's their own business. It's not up to the RIR's or ISP's to tell other > organizations what routes or traffic to accept. > > --Heather > > > > On Jan 16, 2008 12:57 PM, David Conrad wrote: > > > An "interesting" (in sort of the way the Ebola virus is "interesting") > > problem that is going to become much more common as we start > > reallocating > > previously allocated or otherwise flagged blocks. Leo Vegoda has done a > > > > couple of presentations on this. > > > > Just imagine the fun folks who are going to get prefixes out of > > 1.0.0.0/8 > > are going to have. > > > > Options I can think of: > > > > 1) Get everybody to transition to IPv6 (um, yeah). > > 2) Get all the folks who are running RBLs/DUNs to update their lists > > when > > address status changes (slightly more realistic than (1)). > > 3) Get everybody to use reputation services like > > http://www.karmasphere.com/, et al. (no, I'm not affiliated with them) > > 4) Get RPKI deployed to reduce the need for black list services (um, > > yeah.) > > 5) Get the folks who win the draw on prefixes to go around to every > > black > > list service themselves (as they discover them) and convince the > > operator of > > that list (somehow) to remove them (the default). > > > > No good answers I'm aware of... > > > > Regards, > > -drc > > > > On 1/16/08 9:28 AM, "Max Tulyev" wrote: > > > > > Hello All, > > > > > > I just got an assignment for my client (large PI block). But this > > block > > > is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 > > as > > > dynamic DHCP pool of other big ISP. > > > > > > So my client says they can't use this network, because mail service is > > > blocked. > > > > > > RIPE rejected my request to change this network to another one: "As we > > > do understand how unfortunate this is for **********, there is nothing > > > we can do about prefixes that appear on so called black lists." > > > > > > How can I solve this? > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Wed Jan 16 19:57:41 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 Jan 2008 18:57:41 -0000 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <87sl0xvelf.fsf@mid.deneb.enyo.de> References: <20080115161425.84C082F583@herring.ripe.net><478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net><478D9976.4020600@nethinks.com><478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> Message-ID: > - contact every IPv4 PI holder by email and inform them of the > > new rules for IPv6 PI allocations > > Email addresses are currently optional, AFAICT. It's > probably spamming, too. That is stretching... There is certainly a prior business relationship with all PI holders even if there is not a signed contract under the current rules. --Michael Dillon From fw at deneb.enyo.de Wed Jan 16 20:01:45 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Jan 2008 20:01:45 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: (Leo Vegoda's message of "Wed, 16 Jan 2008 19:16:18 +0100") References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> Message-ID: <87prw1sig6.fsf@mid.deneb.enyo.de> * Leo Vegoda: > On 16 Jan 2008, at 18:56, Florian Weimer wrote: > >> * michael dillon: >> >>> - No PI assignments via LIRs. LIRs only manage PA IPv6. >>> - special membership in RIPE with an annual fee for PI holders >> >> How do you handle lack of payment? Reuse the prefix? That seems >> like a >> bad idea to me. > > If this is a bad idea... > >> I would also see a mandate to keep current address information, >> including legal details (register of companies number etc.) in the >> WHOIS database. RIPE NCC will investigate cases if proof is >> presented that something is wrong in the database (bouncing email, >> non-working phone number, bouncing snail mail, lack of matching entry >> in the register of companies). > > ... then what is the enforcement mechanism here? The same as above. This would be an additional process, on top of the yearly fee, not a replacement. > You've just defined a system where the RIPE NCC will guarantee the > uniqueness of address space for a one-time fee *and* allow registrants > to remain anonymous after the first 12 months. I can see a definite > market for something like this. We already face the problem that LIRs are somewhat pseudonymous. There's no easy way to determine which LIR controls which address blocks. From fw at deneb.enyo.de Wed Jan 16 20:04:37 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Jan 2008 20:04:37 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> (Filiz Yilmaz's message of "Tue, 15 Jan 2008 17:14:25 +0100") References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <87lk6psibe.fsf@mid.deneb.enyo.de> * Filiz Yilmaz: > With the acceptance of this proposal, the RIPE NCC will conduct a > one-time operation to assign a /56 IPv6 PI prefix to all End Users > with an IPv4 assignment registered in the RIPE Database. What about inetnum holders whose contact details are wrong? How do you handle delegation for the reverse zone? Such a mass assignment is only practical if name servers on magic addresses are used for delegating the reverse zone, IMHO. And if you tie it to AS numbers, you don't need any additional documentation whatsoever. But this is something for the IETF to consider, I guess. From mcfadden at 21st-century-texts.com Wed Jan 16 20:23:29 2008 From: mcfadden at 21st-century-texts.com (Mark McFadden) Date: Wed, 16 Jan 2008 13:23:29 -0600 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: References: <478E3EA2.6000902@ukraine.su> Message-ID: <00b101c85875$479e8c50$d6dba4f0$@com> >>An "interesting" (in sort of the way the Ebola virus is "interesting") >>problem that is going to become much more common as we start reallocating >>previously allocated or otherwise flagged blocks. Leo Vegoda has done a >>couple of presentations on this. A link or two to those would be useful. TIA. >>Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8 >>are going to have. It's not just those /8's that will be fun. As people try to scavenge from legacy, pre-RIR space there will be all sorts of pressure to recycle from blocks that aren't currently routable. For those people who believe that there is an enormous amount of reclaimable (is that a word?) space in the pre-RIR assignments, just imagine how much of that space has been used twice, thrice or more? Who, for instance, is the legitimate holder in those cases? Who convinces transit providers to change filters? I know that the RIRs are in no position to guarantee routability or "cleanliness" of a prefix. My point is simply that the pressure to reclaim "elderly" prefixes is going to be balanced against the practical problems of multiple uses, RBLs/DUNs, and routability. That problem is just as "interesting" as the 1.0.0.0/8 problems. p.s. I'm thinking that the solution to the Ebola virus will come first. Mark McFadden From randy at psg.com Wed Jan 16 21:17:23 2008 From: randy at psg.com (Randy Bush) Date: Thu, 17 Jan 2008 05:17:23 +0900 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: References: Message-ID: <478E6653.6090304@psg.com> > 2) Get all the folks who are running RBLs/DUNs to update their lists when > address status changes (slightly more realistic than (1)). could arin help automate this? randy From david.conrad at icann.org Wed Jan 16 22:07:26 2008 From: david.conrad at icann.org (David Conrad) Date: Wed, 16 Jan 2008 13:07:26 -0800 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478E6653.6090304@psg.com> Message-ID: On 1/16/08 12:17 PM, "Randy Bush" wrote: >> 2) Get all the folks who are running RBLs/DUNs to update their lists when >> address status changes (slightly more realistic than (1)). > could arin help automate this? Personally, I would imagine a set of services could be offered: A) IANA announces unallocated blocks B) the RIRs announce the blocks they've been allocated by IANA but which are unassigned (either new or returned) RBL/DUN maintainers could then listen for those announcements (note I'm not specifying the form of announcement here, there are a lot of possible mechanisms and some would argue it is already done via the registry databases, but that's pull versus push). The RPKI effort could address part or all of this (maybe). (of course, the last time I suggested IANA could offer a service like this, some people in the ops community yelled at me, so I'm not actually suggesting this). Problem is, we run again into the decentralized nature of the Internet. At least in the past, the folks who maintain RBL/DUN lists were an ornery, individualistic bunch and trying to get them to do something required one-on-one negotiations that sometimes failed for, shall we say, non-technical reasons. I haven't really been following the RBL/DUN world for a while -- maybe things have gotten more professional so getting (at least) the major players to buy into this sort of thing could be possible. However, none of this addresses Max's immediate concerns. In the near term, I figure the choices here are: 1) the RIRs accept "the prefix is on black lists" as a justification to accept a prefix in exchange for another. This will work for a little while longer yet. 2) the RIRs tell folks you get what you get and force the end users who ultimately get the addresses to deal with the situation. I suspect this will tend to result in the ISPs having to deal since they'll probably get tired of their customers whining at them. An icky situation. Regards, -drc From jwkckid1 at ix.netcom.com Thu Jan 17 00:16:48 2008 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 16 Jan 2008 15:16:48 -0800 Subject: [address-policy-wg] "Dirty" recycled network assigned References: Message-ID: <478E9060.C3D7AD04@ix.netcom.com> David and all, I find myself strangly agreeing with you here by in large Dave! >:) But only in the status quo situation overall... Seems to me that either ICANN itself is going to have to address this problem, or the RIR's will have to take the lead in cleaning up recycled IP's that have been black listed by any service whom for whatever reason has blacklisted those IP's. Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com My Phone: 214-244-4827 David Conrad wrote: > An "interesting" (in sort of the way the Ebola virus is "interesting") > problem that is going to become much more common as we start reallocating > previously allocated or otherwise flagged blocks. Leo Vegoda has done a > couple of presentations on this. > > Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8 > are going to have. > > Options I can think of: > > 1) Get everybody to transition to IPv6 (um, yeah). > 2) Get all the folks who are running RBLs/DUNs to update their lists when > address status changes (slightly more realistic than (1)). > 3) Get everybody to use reputation services like > http://www.karmasphere.com/, et al. (no, I'm not affiliated with them) > 4) Get RPKI deployed to reduce the need for black list services (um, yeah.) > 5) Get the folks who win the draw on prefixes to go around to every black > list service themselves (as they discover them) and convince the operator of > that list (somehow) to remove them (the default). > > No good answers I'm aware of... > > Regards, > -drc > > On 1/16/08 9:28 AM, "Max Tulyev" wrote: > > > Hello All, > > > > I just got an assignment for my client (large PI block). But this block > > is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as > > dynamic DHCP pool of other big ISP. > > > > So my client says they can't use this network, because mail service is > > blocked. > > > > RIPE rejected my request to change this network to another one: "As we > > do understand how unfortunate this is for **********, there is nothing > > we can do about prefixes that appear on so called black lists." > > > > How can I solve this? From jwkckid1 at ix.netcom.com Thu Jan 17 00:24:03 2008 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 16 Jan 2008 15:24:03 -0800 Subject: [address-policy-wg] "Dirty" recycled network assigned References: Message-ID: <478E9212.4D8F47AC@ix.netcom.com> Dave and all, If customers of ISP's don't whine, as you put it to them, how do they have an expectation of getting these situations addressed? As you rightly say, the IANA doesn't want to address it, the RIR's really don't either. So whom? Frankly again IMHO, either ICANN/IANA has to address this directly, or the RIR's do. Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com My Phone: 214-244-4827 David Conrad wrote: > On 1/16/08 12:17 PM, "Randy Bush" wrote: > >> 2) Get all the folks who are running RBLs/DUNs to update their lists when > >> address status changes (slightly more realistic than (1)). > > could arin help automate this? > > Personally, I would imagine a set of services could be offered: > > A) IANA announces unallocated blocks > B) the RIRs announce the blocks they've been allocated by IANA but which are > unassigned (either new or returned) > > RBL/DUN maintainers could then listen for those announcements (note I'm not > specifying the form of announcement here, there are a lot of possible > mechanisms and some would argue it is already done via the registry > databases, but that's pull versus push). The RPKI effort could address part > or all of this (maybe). > > (of course, the last time I suggested IANA could offer a service like this, > some people in the ops community yelled at me, so I'm not actually > suggesting this). > > Problem is, we run again into the decentralized nature of the Internet. At > least in the past, the folks who maintain RBL/DUN lists were an ornery, > individualistic bunch and trying to get them to do something required > one-on-one negotiations that sometimes failed for, shall we say, > non-technical reasons. I haven't really been following the RBL/DUN world > for a while -- maybe things have gotten more professional so getting (at > least) the major players to buy into this sort of thing could be possible. > > However, none of this addresses Max's immediate concerns. In the near term, > I figure the choices here are: > > 1) the RIRs accept "the prefix is on black lists" as a justification to > accept a prefix in exchange for another. This will work for a little while > longer yet. > > 2) the RIRs tell folks you get what you get and force the end users who > ultimately get the addresses to deal with the situation. I suspect this > will tend to result in the ISPs having to deal since they'll probably get > tired of their customers whining at them. > > An icky situation. > > Regards, > -drc From president at ukraine.su Thu Jan 17 02:00:34 2008 From: president at ukraine.su (Max Tulyev) Date: Thu, 17 Jan 2008 03:00:34 +0200 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: References: Message-ID: <478EA8B2.7090902@ukraine.su> David, is there real things I can do? Semi-real is 5. But the problem is much more deep. Some people make blacklisting by firewall rules based on data years old. Some blacklists (my client said about yahoo and aol) just have no policy to delist a network, and ignore requests. David Conrad wrote: > An "interesting" (in sort of the way the Ebola virus is "interesting") > problem that is going to become much more common as we start reallocating > previously allocated or otherwise flagged blocks. Leo Vegoda has done a > couple of presentations on this. > > Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8 > are going to have. > > Options I can think of: > > 1) Get everybody to transition to IPv6 (um, yeah). > 2) Get all the folks who are running RBLs/DUNs to update their lists when > address status changes (slightly more realistic than (1)). > 3) Get everybody to use reputation services like > http://www.karmasphere.com/, et al. (no, I'm not affiliated with them) > 4) Get RPKI deployed to reduce the need for black list services (um, yeah.) > 5) Get the folks who win the draw on prefixes to go around to every black > list service themselves (as they discover them) and convince the operator of > that list (somehow) to remove them (the default). > > No good answers I'm aware of... > > Regards, > -drc > > On 1/16/08 9:28 AM, "Max Tulyev" wrote: > >> Hello All, >> >> I just got an assignment for my client (large PI block). But this block >> is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as >> dynamic DHCP pool of other big ISP. >> >> So my client says they can't use this network, because mail service is >> blocked. >> >> RIPE rejected my request to change this network to another one: "As we >> do understand how unfortunate this is for **********, there is nothing >> we can do about prefixes that appear on so called black lists." >> >> How can I solve this? > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jwkckid1 at ix.netcom.com Thu Jan 17 04:19:13 2008 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 16 Jan 2008 19:19:13 -0800 Subject: [address-policy-wg] "Dirty" recycled network assigned References: <478EA8B2.7090902@ukraine.su> Message-ID: <478EC931.EB2C82A1@ix.netcom.com> Max and all, Maybe sue AOL and Yahoo? Why not, everyone else is? Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com My Phone: 214-244-4827 Max Tulyev wrote: > David, > > is there real things I can do? > > Semi-real is 5. But the problem is much more deep. Some people make > blacklisting by firewall rules based on data years old. Some blacklists > (my client said about yahoo and aol) just have no policy to delist a > network, and ignore requests. > > David Conrad wrote: > > An "interesting" (in sort of the way the Ebola virus is "interesting") > > problem that is going to become much more common as we start reallocating > > previously allocated or otherwise flagged blocks. Leo Vegoda has done a > > couple of presentations on this. > > > > Just imagine the fun folks who are going to get prefixes out of 1.0.0.0/8 > > are going to have. > > > > Options I can think of: > > > > 1) Get everybody to transition to IPv6 (um, yeah). > > 2) Get all the folks who are running RBLs/DUNs to update their lists when > > address status changes (slightly more realistic than (1)). > > 3) Get everybody to use reputation services like > > http://www.karmasphere.com/, et al. (no, I'm not affiliated with them) > > 4) Get RPKI deployed to reduce the need for black list services (um, yeah.) > > 5) Get the folks who win the draw on prefixes to go around to every black > > list service themselves (as they discover them) and convince the operator of > > that list (somehow) to remove them (the default). > > > > No good answers I'm aware of... > > > > Regards, > > -drc > > > > On 1/16/08 9:28 AM, "Max Tulyev" wrote: > > > >> Hello All, > >> > >> I just got an assignment for my client (large PI block). But this block > >> is listed in all DNS RBLs and DUN lists, as it was in use till Oct'07 as > >> dynamic DHCP pool of other big ISP. > >> > >> So my client says they can't use this network, because mail service is > >> blocked. > >> > >> RIPE rejected my request to change this network to another one: "As we > >> do understand how unfortunate this is for **********, there is nothing > >> we can do about prefixes that appear on so called black lists." > >> > >> How can I solve this? > > > > > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From leo.vegoda at icann.org Thu Jan 17 10:24:50 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 17 Jan 2008 10:24:50 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <87prw1sig6.fsf@mid.deneb.enyo.de> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> <87prw1sig6.fsf@mid.deneb.enyo.de> Message-ID: <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> On 16 Jan 2008, at 20:01, Florian Weimer wrote: [...] >>>> - No PI assignments via LIRs. LIRs only manage PA IPv6. >>>> - special membership in RIPE with an annual fee for PI holders >>> >>> How do you handle lack of payment? Reuse the prefix? That seems >>> like a >>> bad idea to me. >> >> If this is a bad idea... >> >>> I would also see a mandate to keep current address information, >>> including legal details (register of companies number etc.) in the >>> WHOIS database. RIPE NCC will investigate cases if proof is >>> presented that something is wrong in the database (bouncing email, >>> non-working phone number, bouncing snail mail, lack of matching >>> entry >>> in the register of companies). >> >> ... then what is the enforcement mechanism here? > > The same as above. This would be an additional process, on top of the > yearly fee, not a replacement. I'm not sure I understand what you mean. Could you elaborate, please? >> You've just defined a system where the RIPE NCC will guarantee the >> uniqueness of address space for a one-time fee *and* allow >> registrants >> to remain anonymous after the first 12 months. I can see a definite >> market for something like this. > > We already face the problem that LIRs are somewhat pseudonymous. > There's no easy way to determine which LIR controls which address > blocks. It's not all that hard. You can easily find all resources linked to an LIR's Organisation ID in the whois database. You can do it easily on the RIPE NCC's web site: http://www.ripe.net/whois?-r+-K+-i+org+ORG-NCC1-RIPE I've used the RIPE NCC's Organisation ID in this example but it's easily changed to the ID for whatever LIR you're interested in. You can find the Organisation ID of the LIR you're looking for by using a - L query from any IP address you know is allocated to them and looking for an organisation object that isn't the RIPE NCC's or IANA's. Regards, Leo Vegoda From heldal at eml.cc Thu Jan 17 10:42:05 2008 From: heldal at eml.cc (Per Heldal) Date: Thu, 17 Jan 2008 10:42:05 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> Message-ID: <1200562925.14012.3.camel@obelix.sandbu> On Wed, 2008-01-16 at 14:47 +0100, Marco Hogewoning wrote: > That was already clear, but if, as an end-user, I have to get a > contract with the NCC to obtain PI space, there ain't much difference > to becoming an LIR. There could be some difference in cost, but that > would only mean that as a small ISP it might be cheaper to get PI space. > Should we allow PI to be used to provide transit? If not, would you as an ISP build your network using PI? //per From marcoh at marcoh.net Thu Jan 17 11:39:49 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 17 Jan 2008 11:39:49 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <1200562925.14012.3.camel@obelix.sandbu> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> <1200562925.14012.3.camel@obelix.sandbu> Message-ID: <14AFD20B-725D-4060-A2FF-3D6C171856B8@marcoh.net> On Jan 17, 2008, at 10:42 AM, Per Heldal wrote: > On Wed, 2008-01-16 at 14:47 +0100, Marco Hogewoning wrote: >> That was already clear, but if, as an end-user, I have to get a >> contract with the NCC to obtain PI space, there ain't much difference >> to becoming an LIR. There could be some difference in cost, but that >> would only mean that as a small ISP it might be cheaper to get PI >> space. >> > > Should we allow PI to be used to provide transit? > If not, would you as an ISP build your network using PI? Is there an easy way to enforce people not doing it ? -- MarcoH From michael.dillon at bt.com Thu Jan 17 11:44:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Jan 2008 10:44:27 -0000 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478E6653.6090304@psg.com> References: <478E6653.6090304@psg.com> Message-ID: > > 2) Get all the folks who are running RBLs/DUNs to update > their lists when > > address status changes (slightly more realistic than (1)). > > could arin help automate this? What about RIPE, on whose list we are posting? In any case, I went to ARIN's suggestion page here: https://app.arin.net/suggestion/ and made that very suggestion. --Michael Dillon From michael.dillon at bt.com Thu Jan 17 11:59:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Jan 2008 10:59:42 -0000 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478EA8B2.7090902@ukraine.su> References: <478EA8B2.7090902@ukraine.su> Message-ID: > is there real things I can do? Assign the customer a /32 from one of your address blocks so that they can use it on their mail server. This means the mail server will not be multihomed but at least it will work. Maybe they can also get another /32 from their other upstream provider. In fact, you could also offer to host their mail server in your network which would accomplish the same thing. --Michael Dillon From president at ukraine.su Thu Jan 17 12:17:40 2008 From: president at ukraine.su (Max Tulyev) Date: Thu, 17 Jan 2008 13:17:40 +0200 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: References: <478EA8B2.7090902@ukraine.su> Message-ID: <478F3954.1040605@ukraine.su> 1. It is not multihomed. 2. There is MORE than 1 IP address using for mail service. michael.dillon at bt.com wrote: >> is there real things I can do? > > Assign the customer a /32 from one of your address > blocks so that they can use it on their mail server. > This means the mail server will not be multihomed > but at least it will work. Maybe they can also get > another /32 from their other upstream provider. > > In fact, you could also offer to host their mail > server in your network which would accomplish > the same thing. > > --Michael Dillon > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jeroen at unfix.org Thu Jan 17 12:18:41 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Jan 2008 12:18:41 +0100 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: References: <478E6653.6090304@psg.com> Message-ID: <478F3991.9060804@spaghetti.zurich.ibm.com> michael.dillon at bt.com wrote: >>> 2) Get all the folks who are running RBLs/DUNs to update >> their lists when >>> address status changes (slightly more realistic than (1)). >> could arin help automate this? > > What about RIPE, on whose list we are posting? > In any case, I went to ARIN's suggestion page here: > https://app.arin.net/suggestion/ > and made that very suggestion. For ARIN region it would really help already a lot if they had a populated and used routing registry which was correctly cross referenced to their main whois database. Then, if ISPs are really serious in their work, they could just start using the inetnum/inet6nums to see which prefixes should be in their routing tables, as the ones which are not registered there should clearly not be. This can be done for the RIPE, AFRINIC & APNIC region, but not for ARIN. Not sure about LACNIC there though. The next ultimate step of course is routing PKI, but that definitely will never happen unfortunately. Oh and people afraid of 'loosing their routes to important people', should of course do two things when generating filters from RIR data: - Also have a local repository with important stuff (eg your own and your friends stuff) - Always manually confirm/checkup the changes ;) (Though at some point it should be trustable) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From michael.dillon at bt.com Thu Jan 17 13:03:54 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Jan 2008 12:03:54 -0000 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478F3954.1040605@ukraine.su> References: <478EA8B2.7090902@ukraine.su> <478F3954.1040605@ukraine.su> Message-ID: > 1. It is not multihomed. This makes your problem easier to solve. > 2. There is MORE than 1 IP address using for mail service. Then give the customer more than one /32 or offer them mail hosting service in your address space. --Michael Dillon From heldal at eml.cc Thu Jan 17 18:08:21 2008 From: heldal at eml.cc (Per Heldal) Date: Thu, 17 Jan 2008 18:08:21 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <14AFD20B-725D-4060-A2FF-3D6C171856B8@marcoh.net> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <3B2346C8-B5DD-44BC-89EF-A1393EB791AA@marcoh.net> <20080116133729.GA32671@borg.c-l-i.net> <5B700BAE-8850-47D9-B46A-3B2D8FE2058C@marcoh.net> <1200562925.14012.3.camel@obelix.sandbu> <14AFD20B-725D-4060-A2FF-3D6C171856B8@marcoh.net> Message-ID: <1200589701.14012.18.camel@obelix.sandbu> On Thu, 2008-01-17 at 11:39 +0100, Marco Hogewoning wrote: > On Jan 17, 2008, at 10:42 AM, Per Heldal wrote: > > Should we allow PI to be used to provide transit? > > If not, would you as an ISP build your network using PI? > > > Is there an easy way to enforce people not doing it ? Maybe not today, but those who violate such terms have none other than themselves to blame if they later find themselves up sh*t creek without a paddle (ip-block) once the community has a decent mechanism to revoke allocations. //per From fw at deneb.enyo.de Thu Jan 17 19:42:43 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 17 Jan 2008 19:42:43 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> (Leo Vegoda's message of "Thu, 17 Jan 2008 10:24:50 +0100") References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> <87prw1sig6.fsf@mid.deneb.enyo.de> <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> Message-ID: <87hchci998.fsf@mid.deneb.enyo.de> * Leo Vegoda: >> The same as above. This would be an additional process, on top of the >> yearly fee, not a replacement. > > I'm not sure I understand what you mean. Could you elaborate, please? Yearly fee plus action from the RIPE NCC if someone presents proof that the contact details may be invalid. If the resource holder does not rectify the situation, sanctions comparable to those for lack of payment apply. > It's not all that hard. You can easily find all resources linked to an > LIR's Organisation ID in the whois database. You can do it easily on > the RIPE NCC's web site: > > http://www.ripe.net/whois?-r+-K+-i+org+ORG-NCC1-RIPE The org: field is optional, and it does not necessarily contain a pointer to the LIR. From leo.vegoda at icann.org Thu Jan 17 20:55:37 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 17 Jan 2008 20:55:37 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <87hchci998.fsf@mid.deneb.enyo.de> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> <87prw1sig6.fsf@mid.deneb.enyo.de> <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> <87hchci998.fsf@mid.deneb.enyo.de> Message-ID: <98F08CE8-533F-4957-A2E3-B5D0109CD563@icann.org> On 17 Jan 2008, at 19:42, Florian Weimer wrote: > * Leo Vegoda: > >>> The same as above. This would be an additional process, on top of >>> the >>> yearly fee, not a replacement. >> >> I'm not sure I understand what you mean. Could you elaborate, please? > > Yearly fee plus action from the RIPE NCC if someone presents proof > that > the contact details may be invalid. If the resource holder does not > rectify the situation, sanctions comparable to those for lack of > payment > apply. If the sanctions mean removal from the RIPE database with a guarantee that the prefix will never be re-issued by the RIPE NCC then you have a guaranteed unique network for a one-time fee. Is this actually 'sanctions' or a desirable feature? >> It's not all that hard. You can easily find all resources linked to >> an >> LIR's Organisation ID in the whois database. You can do it easily on >> the RIPE NCC's web site: >> >> http://www.ripe.net/whois?-r+-K+-i+org+ORG-NCC1-RIPE > > The org: field is optional, and it does not necessarily contain a > pointer to the LIR. My understanding was that all address space allocated or assigned directly by the RIPE NCC has the registrant's organisation object referenced in the inetnum object. If this is the case, all an LIR's allocations are linked directly to it. I could be wrong, but I thought the reference was a requirement enforced by the RIPE NCC. Regards, Leo From fw at deneb.enyo.de Thu Jan 17 21:05:52 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 17 Jan 2008 21:05:52 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <98F08CE8-533F-4957-A2E3-B5D0109CD563@icann.org> (Leo Vegoda's message of "Thu, 17 Jan 2008 20:55:37 +0100") References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> <87prw1sig6.fsf@mid.deneb.enyo.de> <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> <87hchci998.fsf@mid.deneb.enyo.de> <98F08CE8-533F-4957-A2E3-B5D0109CD563@icann.org> Message-ID: <87ejcgfc9r.fsf@mid.deneb.enyo.de> * Leo Vegoda: > If the sanctions mean removal from the RIPE database with a guarantee > that the prefix will never be re-issued by the RIPE NCC then you have > a guaranteed unique network for a one-time fee. Is this actually > sanctions' or a desirable feature? I don't know what the sanctions would look like, either. >> The org: field is optional, and it does not necessarily contain a >> pointer to the LIR. > > My understanding was that all address space allocated or assigned > directly by the RIPE NCC has the registrant's organisation object > referenced in the inetnum object. If this is the case, all an LIR's > allocations are linked directly to it. I could be wrong, but I thought > the reference was a requirement enforced by the RIPE NCC. As far as I can tell based on a few examples, it isn't. From marcoh at marcoh.net Fri Jan 18 11:13:00 2008 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 18 Jan 2008 11:13:00 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <98F08CE8-533F-4957-A2E3-B5D0109CD563@icann.org> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> <87prw1sig6.fsf@mid.deneb.enyo.de> <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> <87hchci998.fsf@mid.deneb.enyo.de> <98F08CE8-533F-4957-A2E3-B5D0109CD563@icann.org> Message-ID: <88738C73-ED80-4361-ACF8-4B04459986D0@marcoh.net> On Jan 17, 2008, at 8:55 PM, Leo Vegoda wrote: > If the sanctions mean removal from the RIPE database with a > guarantee that the prefix will never be re-issued by the RIPE NCC > then you have a guaranteed unique network for a one-time fee. Is > this actually 'sanctions' or a desirable feature? Sounds like the current PI system :) Issueing a new policy which, any new policy, which actually states addresses will not ever be recylced, seems rather stupid to me. -- MarcoH From denis at ripe.net Fri Jan 18 11:53:54 2008 From: denis at ripe.net (Denis Walker) Date: Fri, 18 Jan 2008 11:53:54 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <87ejcgfc9r.fsf@mid.deneb.enyo.de> References: <20080115161425.84C082F583@herring.ripe.net> <478D2586.50604@birkenwald.de> <185c01c857c6$121bc4d0$36534e70$@net> <478D9976.4020600@nethinks.com> <478DD4DA.5030804@nethinks.com> <87sl0xvelf.fsf@mid.deneb.enyo.de> <87prw1sig6.fsf@mid.deneb.enyo.de> <910C33F5-275B-4642-A968-FFBDDCC88082@icann.org> <87hchci998.fsf@mid.deneb.enyo.de> <98F08CE8-533F-4957-A2E3-B5D0109CD563@icann.org> <87ejcgfc9r.fsf@mid.deneb.enyo.de> Message-ID: <47908542.4020007@ripe.net> Florian Weimer wrote: > * Leo Vegoda: > > >> If the sanctions mean removal from the RIPE database with a guarantee >> that the prefix will never be re-issued by the RIPE NCC then you have >> a guaranteed unique network for a one-time fee. Is this actually >> sanctions' or a desirable feature? >> > > I don't know what the sanctions would look like, either. > > >>> The org: field is optional, and it does not necessarily contain a >>> pointer to the LIR. >>> >> My understanding was that all address space allocated or assigned >> directly by the RIPE NCC has the registrant's organisation object >> referenced in the inetnum object. If this is the case, all an LIR's >> allocations are linked directly to it. I could be wrong, but I thought >> the reference was a requirement enforced by the RIPE NCC. >> > > As far as I can tell based on a few examples, it isn't. > The "org:" attribute is optional as far as syntax is concerned. But business logic applied after the syntax checks makes it mandatory on an allocation inet(6)num object. regards Denis Walker Business Analyst RIPE NCC From Jerzy.Pawlus at cyf-kr.edu.pl Fri Jan 18 14:26:28 2008 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Fri, 18 Jan 2008 14:26:28 +0100 (MET) Subject: [address-policy-wg] 2008-02 New Policy Proposal (Assigning IPv6 PA to Every LIR) In-Reply-To: <20080115161901.EAC342F583@herring.ripe.net> (message from Filiz Yilmaz on Tue, 15 Jan 2008 17:19:01 +0100) References: <20080115161901.EAC342F583@herring.ripe.net> Message-ID: <200801181326.m0IDQSOs016198@nc.cyf-kr.edu.pl> Hi, > With the acceptance of this proposal RIPE NCC will run a one-time operation > to allocate an IPv6 block to every LIR that does not have any existing > IPv6 holdings. > It seems that with this and a new PI policy, RIPE community intends to copy an existing IPv4 world to the IPv6 world. The intention is to speed up IPv6 deployment and it is a step in the right direction. However, this process will not be complete unless there is a possibilty to obtain an IPv6 initial allocation per LIR routing policy (AS number). So I would like to change the Policy Proposal to: "With the acceptance of this proposal RIPE NCC will run a one-time operation to allocate an IPv6 block per LIR ASN to every LIR that does not have any existing IPv6 holdings fulfilling this statement." The alternative, although less preferable, would be a simultaneous removal of point b) (advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet) in 5.1.1 Initial allocation criteria of http://www.ripe.net/ripe/docs/ripe-421.html Jurek From rogerj at gmail.com Thu Jan 17 11:52:26 2008 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 17 Jan 2008 11:52:26 +0100 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <038D631C-C0D7-4567-810D-04B26EA6B6E6@jorgensen.no> On 15. jan.. 2008, at 17.14:25, Filiz Yilmaz wrote: > > > With the acceptance of this proposal, the RIPE NCC will conduct a > one-time operation > to assign a /56 IPv6 PI prefix to all End Users with an IPv4 > assignment registered > in the RIPE Database. It is a really bad choice of address lenght, /48 would make much much more sense. ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From zsako at 3c-hungary.hu Thu Jan 17 14:17:08 2008 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 17 Jan 2008 14:17:08 +0100 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478F3954.1040605@ukraine.su> References: <478EA8B2.7090902@ukraine.su> <478F3954.1040605@ukraine.su> Message-ID: <478F5554.6050301@3c-hungary.hu> Dear Max, > 2. There is MORE than 1 IP address using for mail service. You can offer mail relay service through your mail server(s). The customer(s) should then configure their mail servers to forward mail to the "smart" host (your relay), rather than deliver it directly. I hope this helps. Best regards, Janos Zsako > michael.dillon at bt.com wrote: >>> is there real things I can do? >> Assign the customer a /32 from one of your address >> blocks so that they can use it on their mail server. >> This means the mail server will not be multihomed >> but at least it will work. Maybe they can also get >> another /32 from their other upstream provider. >> >> In fact, you could also offer to host their mail >> server in your network which would accomplish >> the same thing. >> >> --Michael Dillon >> > > From president at ukraine.su Sat Jan 19 15:29:06 2008 From: president at ukraine.su (Max Tulyev) Date: Sat, 19 Jan 2008 16:29:06 +0200 Subject: [address-policy-wg] 2008-01 New Policy Proposal (Assigning IPv6 PI to Every Inetnum Holder) In-Reply-To: <20080115161425.84C082F583@herring.ripe.net> References: <20080115161425.84C082F583@herring.ripe.net> Message-ID: <47920932.5060908@ukraine.su> Hello All, sorry for a bit late join for this very interesting discussion. Here is my 5c: 1. 2008-01 is BAD. I don't support it. Two things why is said here: routing pollution and wasting of address space. 2. My opinion is still same: we should push RESOURCES, not ISPs, to move to IPv6 first. Why is need the fine working, but completely useless network? And, if 51% (majority) of RESOURCES will not be reachable via IPv6 when the last IPv4 network will be assigned - you can drop out IPv6 as it FAILS to be implemented, even if every user will have IPv6 /64 on their every mobile refrigerator. 3. Yes, we need IPv6 PI with same policies as IPv4. At first, we need it to push resources (hosting providers, etc) to move to IPv6. It will be a great if hosting providers will be multihomed (so better connected) and independent in v6, but not in v4 :) 4. We HAVE TO implement annual payments for PI. Both v4 and v6. It should be a small (100EUR?) "ping" payments "are you still alive?" Because of there is a lot of dead companies having locked PI space they will never use. May be we can't recycle it all now (guarantee stop routing), but at least we can count them. And I think majority of this space found out by non-payments can be recycled without any problems. And some about "new correct" PI proposal: > - No PI assignments via LIRs. LIRs only manage PA IPv6. > - special membership in RIPE with an annual fee for PI holders > - contract signed between RIPE and PI holders that covers fee > payments, and revocation/return of address blocks Please keep in mind RIPE NCC is still serving not only EU countries. And in eastern side of this continent there is slightly different rules of doing business. So it is very difficult (and even not possible at all) to have abroad contracts and do payments directly to RIPE. So we SHOULD keep possibility to receive payments for PI through a LIR (which is doing local business and can sign local domestic contract and receive payments in local money with providing local account law papers). Also I think for PI there should be separate payments, not just enlarging a scoring. Because of else LIRs with big scoring and a lot of clients (i.e. our company - Extralarge LIR) will not be interesting in catching and shooting dead PI holders - it will not change our invoice immediately :) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From fw at deneb.enyo.de Sun Jan 27 22:09:38 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 27 Jan 2008 22:09:38 +0100 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478E6653.6090304@psg.com> (Randy Bush's message of "Thu, 17 Jan 2008 05:17:23 +0900") References: <478E6653.6090304@psg.com> Message-ID: <878x2bq8kt.fsf@mid.deneb.enyo.de> * Randy Bush: >> 2) Get all the folks who are running RBLs/DUNs to update their lists when >> address status changes (slightly more realistic than (1)). > > could arin help automate this? I think you can't really automate this, otherwise people will try to use the automated process to purge bad reputation from the record. I also think that RIPE (and probably ARIN, too) publish enough data so that the blacklist operators could detect significant changes in address space ownership automatically. From fw at deneb.enyo.de Sun Jan 27 22:12:45 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 27 Jan 2008 22:12:45 +0100 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <478F5554.6050301@3c-hungary.hu> (Janos Zsako's message of "Thu, 17 Jan 2008 14:17:08 +0100") References: <478EA8B2.7090902@ukraine.su> <478F3954.1040605@ukraine.su> <478F5554.6050301@3c-hungary.hu> Message-ID: <87y7abotv6.fsf@mid.deneb.enyo.de> * Janos Zsako: >> 2. There is MORE than 1 IP address using for mail service. > > You can offer mail relay service through your mail server(s). > > The customer(s) should then configure their mail servers to forward > mail to the "smart" host (your relay), rather than deliver it > directly. You also need to rewrite Received: lines, to remove records of the supposedly infected address space. And you should do this on a separate server on a dedicated prefix, so that misguided blacklist operators do not retaliate against your main mail service for doing that. 8-( From Woeber at CC.UniVie.ac.at Mon Jan 28 10:58:36 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 28 Jan 2008 09:58:36 +0000 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <87y7abotv6.fsf@mid.deneb.enyo.de> References: <478EA8B2.7090902@ukraine.su> <478F3954.1040605@ukraine.su> <478F5554.6050301@3c-hungary.hu> <87y7abotv6.fsf@mid.deneb.enyo.de> Message-ID: <479DA74C.9010208@CC.UniVie.ac.at> Florian Weimer wrote: > * Janos Zsako: > > >>>2. There is MORE than 1 IP address using for mail service. >> >>You can offer mail relay service through your mail server(s). >> >>The customer(s) should then configure their mail servers to forward >>mail to the "smart" host (your relay), rather than deliver it >>directly. > > > You also need to rewrite Received: lines, to remove records of the > supposedly infected address space. And you should do this on a separate > server on a dedicated prefix, so that misguided blacklist operators do > not retaliate against your main mail service for doing that. 8-( I really don't get that one :-) I suppose the NCC manufactures a completely fresh and shiny address space object when giving out "previously used" address space? Otherwise, messing around with changed lines *after* an allocation or assignment transaction is a BAD IDEA [TM] (as I found out ;-) ) Wilfried. From fw at deneb.enyo.de Mon Jan 28 11:04:27 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 28 Jan 2008 11:04:27 +0100 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <479DA74C.9010208@CC.UniVie.ac.at> (Wilfried Woeber's message of "Mon, 28 Jan 2008 09:58:36 +0000") References: <478EA8B2.7090902@ukraine.su> <478F3954.1040605@ukraine.su> <478F5554.6050301@3c-hungary.hu> <87y7abotv6.fsf@mid.deneb.enyo.de> <479DA74C.9010208@CC.UniVie.ac.at> Message-ID: <87myqqe05w.fsf@mid.deneb.enyo.de> * Wilfried Woeber: >> You also need to rewrite Received: lines, to remove records of the >> supposedly infected address space. And you should do this on a separate >> server on a dedicated prefix, so that misguided blacklist operators do >> not retaliate against your main mail service for doing that. 8-( > > I really don't get that one :-) Which part? For certain mail relays, filter rules are applied to hosts behind it, not to the relay itself. > I suppose the NCC manufactures a completely fresh and shiny > address space object when giving out "previously used" address > space? They do. But blacklist operators do not seem to care. (Same for some routing database operators, BTW.) Apparently, it's also possible to wipe clean the record on your inetnum: objects, so it's understandable that the blacklist operators do not automatically wipe all the records from their databases just because the object appears to be new. From Woeber at CC.UniVie.ac.at Mon Jan 28 11:10:26 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 28 Jan 2008 10:10:26 +0000 Subject: [address-policy-wg] "Dirty" recycled network assigned In-Reply-To: <87myqqe05w.fsf@mid.deneb.enyo.de> References: <478EA8B2.7090902@ukraine.su> <478F3954.1040605@ukraine.su> <478F5554.6050301@3c-hungary.hu> <87y7abotv6.fsf@mid.deneb.enyo.de> <479DA74C.9010208@CC.UniVie.ac.at> <87myqqe05w.fsf@mid.deneb.enyo.de> Message-ID: <479DAA12.2050008@CC.UniVie.ac.at> Florian Weimer wrote: > * Wilfried Woeber: > > >>>You also need to rewrite Received: lines, to remove records of the >>>supposedly infected address space. And you should do this on a separate >>>server on a dedicated prefix, so that misguided blacklist operators do >>>not retaliate against your main mail service for doing that. 8-( >> >>I really don't get that one :-) > > > Which part? Sorry Florian, I got somewhat mixed up between "received:" and "changed:" :-/ My apologies... -W > For certain mail relays, filter rules are applied to hosts behind it, > not to the relay itself. > > >>I suppose the NCC manufactures a completely fresh and shiny >>address space object when giving out "previously used" address >>space? > > > They do. But blacklist operators do not seem to care. (Same for some > routing database operators, BTW.) > > Apparently, it's also possible to wipe clean the record on your inetnum: > objects, so it's understandable that the blacklist operators do not > automatically wipe all the records from their databases just because the > object appears to be new. > From s.steffann at computel.nl Mon Jan 28 17:17:33 2008 From: s.steffann at computel.nl (Sander Steffann) Date: Mon, 28 Jan 2008 17:17:33 +0100 Subject: [address-policy-wg] Legal status of IP addresses Message-ID: <00b201c861c9$4a3a3ab0$deaeb010$@steffann@computel.nl> Hello, For your information: Last week there has been discussion about the EU legal status of an IP address [1]. This is about whether an IP address can be used to identify an individual and the privacy and data protection implications. Sincerely, Sander Steffann Address Policy co-chair [1] http://www.networkworld.com/news/2008/012408-eu-aims-to-clarify-legal.html?f src=rss-security From berni at birkenwald.de Tue Jan 29 18:32:12 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 29 Jan 2008 18:32:12 +0100 Subject: [address-policy-wg] Pushing 2007-01 forward Message-ID: <479F631C.3020401@birkenwald.de> Hi, is there anything we (the community) can do to push 2007-01? http://www.ripe.net/ripe/policies/proposals/2007-01.html Regards, Bernhard From nick at inex.ie Wed Jan 30 00:14:06 2008 From: nick at inex.ie (Nick Hilliard) Date: Tue, 29 Jan 2008 23:14:06 +0000 Subject: [address-policy-wg] Pushing 2007-01 forward In-Reply-To: <479F631C.3020401@birkenwald.de> References: <479F631C.3020401@birkenwald.de> Message-ID: <479FB33E.6010803@inex.ie> Bernhard Schmidt wrote: > is there anything we (the community) can do to push 2007-01? > http://www.ripe.net/ripe/policies/proposals/2007-01.html Hi Bernhard, we are actively working on this proposal right now and hope to have a reworking of it shortly. Nick Hilliard