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 <address-policy-wg@ripe.net> before 12 February 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Filiz Yilmaz Sent: 15 January 2008 16:14 To: policy-announce@ripe.net Cc: Lutz Donnerhacke; address-policy-wg@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 <address-policy-wg@ripe.net> before 12 February 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
timothy.clarke@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 ]---
On 15 Jan 2008, at 22:18, Elmar K. Bins wrote:
timothy.clarke@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
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
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 <http://www.getipv6.info/> such as the one on First Steps for ISPs <http://www.getipv6.info/index.php/First_Steps_for_ISPs> or Transparent Internet Access <http://www.getipv6.info/index.php/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
On Jan 15, 2008, at 5:35 PM, <michael.dillon@bt.com> 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 <http://www.getipv6.info/> such as the one on First Steps for ISPs <http://www.getipv6.info/index.php/First_Steps_for_ISPs>
or Transparent Internet Access <http://www.getipv6.info/index.php/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
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
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 <address-policy-wg@ripe.net> before 12 February 2008.
Regards
Filiz Yilmaz RIPE NCC Policy Development Officer
* 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.
jarlah@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 ]---
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@inex.ie
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
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@e-utp.net http://www.e-utp.net
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@swm.pp.se
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
- 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
On Wed, Jan 16, 2008 at 09:00:59AM -0000, michael.dillon@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
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
michael.dillon@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
michael.dillon@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
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
michael.dillon@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
On Wed, Jan 16, 2008 at 12:50:29PM +0100, Jeroen Massar wrote:
michael.dillon@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
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@streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc@streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Shane Kerr" <shane@time-travellers.org> To: <address-policy-wg@ripe.net> 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@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
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
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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of michael.dillon@bt.com Sent: 16 January 2008 11:23 To: address-policy-wg@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
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
michael.dillon@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.
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
On Jan 16, 2008, at 12:23 PM, <michael.dillon@bt.com> <michael.dillon@bt.com
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
Marco, On Wed, Jan 16, 2008 at 02:09:59PM +0100, Marco Hogewoning wrote:
On Jan 16, 2008, at 12:23 PM, <michael.dillon@bt.com> <michael.dillon@bt.com > 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
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, <michael.dillon@bt.com> <michael.dillon@bt.com > 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
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
On Wed, 16 Jan 2008, michael.dillon@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
On Jan 16, 2008, at 3:24 PM, <michael.dillon@bt.com> <michael.dillon@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.
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
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
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
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
On Jan 16, 2008 2:09 PM, Marco Hogewoning <marcoh@marcoh.net> 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
On Jan 16, 2008, at 3:54 PM, Leo Vegoda wrote:
On Jan 16, 2008 2:09 PM, Marco Hogewoning <marcoh@marcoh.net> 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
* 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.
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
* 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.
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
* 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:
The org: field is optional, and it does not necessarily contain a pointer to the LIR.
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:
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
* 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.
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
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
- 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
Hi Garry, second all of this... garry@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 ]---
Isn't that the point of 2008-02, LIR's without customers can then get IPv6 -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Elmar K. Bins Sent: 16 January 2008 09:21 To: Garry Glendown Cc: address-policy-wg@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@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
timothy.clarke@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
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@e-utp.net http://www.e-utp.net
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@swm.pp.se
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
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
michael.dillon@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@e-utp.net http://www.e-utp.net
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@streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc@streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Marcin Gondek" <drixter@e-utp.net> To: <address-policy-wg@ripe.net> 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@e-utp.net http://www.e-utp.net
* 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.
On 15. jan.. 2008, at 17.14:25, Filiz Yilmaz wrote:
<snip>
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@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
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@FIDO)
participants (27)
-
Alex Le Heux -
Andy Davidson -
Bernhard Schmidt -
Denis Walker -
Elmar K. Bins -
Filiz Yilmaz -
Florian Weimer -
Garry Glendown -
Gert Doering -
Jarno Lähteenmäki -
Jeroen Massar -
Leo Vegoda -
Leo Vegoda -
Lutz Donnerhacke -
Marcin Gondek -
Marco Hogewoning -
Max Tulyev -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Mohacsi Janos -
Nick Hilliard -
Per Heldal -
Roger Jørgensen -
Shane Kerr -
Stream Service || Mark Scholten -
Tim Chown -
Timothy Clarke