Re: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Dear Address Policy WG, On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote:
A proposed change to RIPE Documents ripe-589, "IPv6 Address Allocation and Assignment Policy", ripe-451, "IPv6 Address Space Policy For Internet Exchange Points" and ripe-233, "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion. [..] We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 25 October 2013.
The discussion phase for this proposal is now over, but after the feedback received at the RIPE meeting in Athens (and here on the list, even if in the wrong thread :) ) the chairs have deviced to take a step back, and re-state the fundamental "do we want to go there?" question (and extend the discussion phase by +4 weeks). The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of address space, "IPv6 addresses". This is the goal. The idea to go there came from various people in the community, mostly for one reason - having two differently "coloured" addresses that do the same thing, routingwise, but follow different policies and have different strings attached, creates quite some confusion for the folks out there that can no longer be nicely separated into "ISPs" (->become RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming and/or upstream independence is required). Most notably, "garage style hosting providers" seem to have issues with the requirement of the IPv6 PI policy that PI space MUST NOT be sub-assigned, which the NCC interprets most strictly (because the vast amount of "grey" between "ok" and "not ok" is hard to codify into hostmaster guidelines). OTOH, I have not heard that complaint from actual hosting providers for a while, so maybe the issue is not that big anymore. *If* we go to "there is only one type of addresses" anymore, we have two options - abandon IPv6 PI (as in "not so expensive, but independent space") completely, problem solved -> I do not think we can reasonably do that - find a way to solve the needs for both RIPE members and non-members, with maximum flexibility, with only one type of addresses, taking "real world" address distribution chains (LIR->network operator-> hosting provider->customer->hosted virtual machines, for example) and "real world" financial constraints into account. 2013-06 aims to achieve the latter, while proposing / finding specific solutions for all the small details that come up if such a radical change is implemented. I think the presentation at RIPE67 was a bit too fast for the WG - it could have spent a bit more time on the background and "do we want to go there" before overwhelming you with questions about details to be solved. For that, I apologize - I did review the presentation beforehand with the proposers, and assumed "yes, this should work out nicely"... Anyway. I think what we need to hear now from the community (*you*) is where we want to go: - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine - keep the distinction, work on the IPv6 PI policy (if the pain is large enough that someone actually volunteers to come with a proposal) - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail problems that need to be addressed if we go there. Going for one of the first options would mean abandoning 2013-06 - but if that's what the community wants, it's much better to do it *now* than to invest more time in text, impact analysis, a few rounds of review phase, and *then* give up the project. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering <gert@space.net> wrote:
Dear Address Policy WG,
On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote:
A proposed change to RIPE Documents ripe-589, "IPv6 Address Allocation and Assignment Policy", ripe-451, "IPv6 Address Space Policy For Internet Exchange Points" and ripe-233, "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion. [..] We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 25 October 2013.
The discussion phase for this proposal is now over, but after the feedback received at the RIPE meeting in Athens (and here on the list, even if in the wrong thread :) ) the chairs have deviced to take a step back, and re-state the fundamental "do we want to go there?" question (and extend the discussion phase by +4 weeks).
The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of address space, "IPv6 addresses". This is the goal.
The idea to go there came from various people in the community, mostly for one reason - having two differently "coloured" addresses that do the same thing, routingwise, but follow different policies and have different strings attached, creates quite some confusion for the folks out there that can no longer be nicely separated into "ISPs" (->become RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming and/or upstream independence is required).
In my opinion, this distinction is not particularly useful in itself, and could very well be a floating definition. Coming from the DNS registrar side, I cannot help thinking that looking at the registry/registrar model might be beneficial for making things clearer for people out there. One way of seeing this, is that the LIRs are "registrars" for IP address space, and that their role could simply be about registering and brokering assignments and allocations for the RIR. An ISP or an "end user" then becomes an unnecessary distinction, as they would both have to go to a LIR to get their address space, and it's just a matter of placing a request for the correct size, at the discretion of the applicant and the LIR. Mind you, I think this is mostly about perspective, but if we could use the similarities with DNS registrations, then end customers (ISPs or whatever) might have less confusion. I could very well be wrong.
Most notably, "garage style hosting providers" seem to have issues with the requirement of the IPv6 PI policy that PI space MUST NOT be sub-assigned, which the NCC interprets most strictly (because the vast amount of "grey" between "ok" and "not ok" is hard to codify into hostmaster guidelines). OTOH, I have not heard that complaint from actual hosting providers for a while, so maybe the issue is not that big anymore.
From what I've seen – and this is anecdata – this is "solved" by subletting
the address space without leaving other traces of it than a PTR record, if that. *If* we go to "there is only one type of addresses" anymore, we have two
options
- abandon IPv6 PI (as in "not so expensive, but independent space") completely, problem solved -> I do not think we can reasonably do that
- find a way to solve the needs for both RIPE members and non-members, with maximum flexibility, with only one type of addresses, taking "real world" address distribution chains (LIR->network operator-> hosting provider->customer->hosted virtual machines, for example) and "real world" financial constraints into account.
2013-06 aims to achieve the latter, while proposing / finding specific solutions for all the small details that come up if such a radical change is implemented.
I think the latter is how it should be done, and I think it would be easier to explain.
I think the presentation at RIPE67 was a bit too fast for the WG - it could have spent a bit more time on the background and "do we want to go there" before overwhelming you with questions about details to be solved. For that, I apologize - I did review the presentation beforehand with the proposers, and assumed "yes, this should work out nicely"...
Anyway. I think what we need to hear now from the community (*you*) is where we want to go:
- do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine
- keep the distinction, work on the IPv6 PI policy (if the pain is large enough that someone actually volunteers to come with a proposal)
- go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail problems that need to be addressed if we go there.
Going for one of the first options would mean abandoning 2013-06 - but if that's what the community wants, it's much better to do it *now* than to invest more time in text, impact analysis, a few rounds of review phase, and *then* give up the project.
I think going the big step is where we need to go. But it's a nice extra workload. Keeping the current policy is less work, and I don't think it will hurt much of anything. But right now, I think the ideal should be the third option, especially considering that this will seem to be much harder to change at a later point in time.
Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?
(Yes!) -- Jan
As one of the authors of this proposal, maybe I should just shut up now, but I would just like to say that the current version of the proposal is a first attempt trying to solve an identified problem. Apparently it became a bit too complex. Another comment below. On Fri, 25 Oct 2013, Jan Ingvoldstad wrote:
On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering <gert@space.net> wrote: Dear Address Policy WG,
On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote:
A proposed change to RIPE Documents ripe-589, "IPv6 Address Allocation and Assignment Policy", ripe-451, "IPv6 Address Space Policy For Internet Exchange Points" and ripe-233, "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion. [..] We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 25 October 2013.
The discussion phase for this proposal is now over, but after the feedback received at the RIPE meeting in Athens (and here on the list, even if in the wrong thread :) ) the chairs have deviced to take a step back, and re-state the fundamental "do we want to go there?" question (and extend the discussion phase by +4 weeks).
The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of address space, "IPv6 addresses". This is the goal.
The idea to go there came from various people in the community, mostly for one reason - having two differently "coloured" addresses that do the same thing, routingwise, but follow different policies and have different strings attached, creates quite some confusion for the folks out there that can no longer be nicely separated into "ISPs" (->become RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming and/or upstream independence is required).
In my opinion, this distinction is not particularly useful in itself, and could very well be a floating definition.
Coming from the DNS registrar side, I cannot help thinking that looking at the registry/registrar model might be beneficial for making things clearer for people out there.
One way of seeing this, is that the LIRs are "registrars" for IP address space, and that their role could simply be about registering and brokering assignments and allocations for the RIR.
An ISP or an "end user" then becomes an unnecessary distinction, as they would both have to go to a LIR to get their address space, and it's just a matter of placing a request for the correct size, at the discretion of the applicant and the LIR.
Mind you, I think this is mostly about perspective, but if we could use the similarities with DNS registrations, then end customers (ISPs or whatever) might have less confusion.
I could very well be wrong.
I (personally) think you are right. You don't have so set up a domain name registrar if you just want to use a couple of domain names. We regularly see entities out there who just want some address space. Sometimes just a small space and sometimes a very space. I think if would be beneficial if they had an option to ask a registrar (LIR) to do the book keeping for them. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
Hi Gert, Thanks for the email and the discussion in Athens and let me start by saying thanks to the authors of the amount of effort and work they have put into this.
Anyway. I think what we need to hear now from the community (*you*) is where we want to go:
Having heard the discussion in Athens and seen the presentation, I personally think that we should abandon 2013-06. Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member.
- do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine
Having said that, maybe the currently policy isn't perfect, but it is better than the alternative imho. Not every End-User can legally become an LIR and they would still require the ability to be independent from their upstream provider.
- keep the distinction, work on the IPv6 PI policy (if the pain is large enough that someone actually volunteers to come with a proposal)
- go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail
Been there, done that... Let's implement v6 first. The current policy provides options for people on what to do and how to get what you require. If the policy is limiting v6 deployments, we can always revisit a specific option again imho. The current policy allows a End-User to receive their own /48 (minimal assignment) or larger with demonstrated documentation and need. The limitation is that they are not allowed to sub-assign to other organizations. problems that need to be addressed if we go there. I would strongly not go there to remove the PI limitation of sub-assignments to others and increasing the assigned (or newly proposed allocate) size to a /32 or /29 similar as one would get by signing up for a LIR membership. Regards, Erik Bais
I fully agree with Erik, please do not continue with 2013-06. -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Erik Bais Sent: 26. lokakuuta 2013 19:34 To: 'Gert Doering'; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) Hi Gert, Thanks for the email and the discussion in Athens and let me start by saying thanks to the authors of the amount of effort and work they have put into this.
Anyway. I think what we need to hear now from the community (*you*) is where we want to go:
Having heard the discussion in Athens and seen the presentation, I personally think that we should abandon 2013-06. Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member.
- do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine
Having said that, maybe the currently policy isn't perfect, but it is better than the alternative imho. Not every End-User can legally become an LIR and they would still require the ability to be independent from their upstream provider.
- keep the distinction, work on the IPv6 PI policy (if the pain is large enough that someone actually volunteers to come with a proposal)
- go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail
Been there, done that... Let's implement v6 first. The current policy provides options for people on what to do and how to get what you require. If the policy is limiting v6 deployments, we can always revisit a specific option again imho. The current policy allows a End-User to receive their own /48 (minimal assignment) or larger with demonstrated documentation and need. The limitation is that they are not allowed to sub-assign to other organizations. problems that need to be addressed if we go there. I would strongly not go there to remove the PI limitation of sub-assignments to others and increasing the assigned (or newly proposed allocate) size to a /32 or /29 similar as one would get by signing up for a LIR membership. Regards, Erik Bais
On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering <gert@space.net> wrote:
Dear Address Policy WG,
On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote:
A proposed change to RIPE Documents ripe-589, "IPv6 Address Allocation and Assignment Policy", ripe-451, "IPv6 Address Space Policy For Internet Exchange Points" and ripe-233, "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion. [..] We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 25 October 2013.
The discussion phase for this proposal is now over, but after the feedback received at the RIPE meeting in Athens (and here on the list, even if in the wrong thread :) ) the chairs have deviced to take a step back, and re-state the fundamental "do we want to go there?" question (and extend the discussion phase by +4 weeks).
sorry for helping out with that ;) <snip>
The idea to go there came from various people in the community, mostly for one reason - having two differently "coloured" addresses that do the same thing, routingwise, but follow different policies and have different strings attached, creates quite some confusion for the folks out there that can no longer be nicely separated into "ISPs" (->become RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming and/or upstream independence is required).
Most notably, "garage style hosting providers" seem to have issues with the requirement of the IPv6 PI policy that PI space MUST NOT be sub-assigned, which the NCC interprets most strictly (because the vast amount of "grey" between "ok" and "not ok" is hard to codify into hostmaster guidelines). OTOH, I have not heard that complaint from actual hosting providers for a while, so maybe the issue is not that big anymore.
Erik Bais's mail touch what is probably the only real difference between PI and PA, and our core problem:
From Erik Bais's post on this thread: "Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member."
Isn't this really about what is the difference between being a member and not? It would be nice to get ride of the PI and PA, and at the same time keeping the difference between member (LIR) and none member (no-LIR).
*If* we go to "there is only one type of addresses" anymore, we have two options
- abandon IPv6 PI (as in "not so expensive, but independent space") completely, problem solved -> I do not think we can reasonably do that
See above, wish we could, but it has this member/not-member side...
- find a way to solve the needs for both RIPE members and non-members, with maximum flexibility, with only one type of addresses, taking "real world" address distribution chains (LIR->network operator-> hosting provider->customer->hosted virtual machines, for example) and "real world" financial constraints into account.
This is the way I think we should pursue and see if we can figure out. It is all just bits/numbers anyhow. Right now I don't see a way to get there, we probably have some other work to get done first.
2013-06 aims to achieve the latter, while proposing / finding specific solutions for all the small details that come up if such a radical change is implemented.
2013-06 is dead in the water right now, it's too complex to get it done the way it was attempted.
I think the presentation at RIPE67 was a bit too fast for the WG - it could have spent a bit more time on the background and "do we want to go there" before overwhelming you with questions about details to be solved. For that, I apologize - I did review the presentation beforehand with the proposers, and assumed "yes, this should work out nicely"...
I think the presentation were good in the way that it showed the complexity we are trying to address. It made it very clear to me that it is not a easy thing to change. The other good thing, it trigged a discussion which is almost always a good thing. It make people think.
Anyway. I think what we need to hear now from the community (*you*) is where we want to go:
- do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine
Not an option as I see it.
- keep the distinction, work on the IPv6 PI policy (if the pain is large enough that someone actually volunteers to come with a proposal)
- go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail problems that need to be addressed if we go there.
I think we should remove the difference between PI and PA. However I don't see how to get there, but we can start with something else. What if we start with doing some housekeeping, make the different policies affecting the "PI-domain" clean and neat? Preferable in just one document. Later when that's concluded we might be able to move it one step further? Another side of this PI/PA space, should there be any way to transfer/change a PI allocation into PA? PI holders (not members) should have the options to become members and at that point they should have their addresses also made into PA... I think it's possible to have PI space while being member today? That should not exist, it should just be PA if you are a member... Then we have this concept of "independed resources"... is that PI or PI+ other things? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
On Sun, 27 Oct 2013, Roger Jørgensen wrote:
Erik Bais's mail touch what is probably the only real difference between PI and PA, and our core problem:
From Erik Bais's post on this thread: "Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member."
Isn't this really about what is the difference between being a member and not? It would be nice to get ride of the PI and PA, and at the same time keeping the difference between member (LIR) and none member (no-LIR).
Well, there has to be some benefits for the members, hasn't it? At the same time, what says RIPE has to have 10.000 members? Or 130 employees? And the current policy looks very much like a membership boosting construction: just sign up, pay the bill and get a /29 (compaired to ask a member to apply for a /48 with very restricted use and make life really hard if you ever want anything more). What makes us think that PA holders/members are always responsible while PI holders/non-members are completely not trustworthy? I would prefer policies to apply for addresses (let's say, thou shalt not assign less than a /xx to an yy) rather than the role play of today. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
Tore Anderson wrote:
Being a data centre operator and LIR, I believe I cannot currently make an IPv6 PA assignment to a customer of mine who wants to run a cloud service where their customers can rent virtual servers in turn. (A customer of theirs may in turn run some sort of web hotel for another set of customers on those VMs, and so on and so on.)
This is a typical situation the policies do not address well. Optional example: I have one IPv6 PI and I would love to become a RIPE member which I can not afford since I run a non-profit network targeted at network beginners. The policies gave me more than one headache and are the reason why I joined this wg in the first place. AFAIK the only way to go is by deciding which policy violation is less harmful. And that is bad. If an e.g. /56 would be treated like a single IPv4 address is today the solution would be "the loophole" (see quote above). As soon as I give /64 to a single VM to isolate it from other VMs and I am not the "owner" of the VM I will get into policy trouble because I just sub-allocated a portion of my PI space. Since I regularly deal with networking beginners and their VMs it would be fine to isolate them a bit more. Instead it looks like this: Multiple VMs share a link and a VM's interface gets as many addresses from that subnet as required, not more and not less, still seeing other VMs in the neighbor cache. On Tue, Oct 29, 2013 at 4:23 PM, Daniel Stolpe <stolpe@resilans.se> wrote:
On Sun, 27 Oct 2013, Roger Jørgensen wrote:
Erik Bais's mail touch what is probably the only real difference between PI and PA, and our core problem:
From Erik Bais's post on this thread:
"Having garage-style 'hosters' do assignments, just because they can while using PI IPv6 space, is against the policy, however removing that distinction between PI and PA for v6 and allowing sub-assignments from PI space will basically open the door in the near future for cheap resources, without being an LIR. That will have an impact on the number of members the NCC will have once we are beyond the v4 era ... And less members will result in a high fee per member."
Isn't this really about what is the difference between being a member and not? It would be nice to get ride of the PI and PA, and at the same time keeping the difference between member (LIR) and none member (no-LIR).
Well, there has to be some benefits for the members, hasn't it? At the same time, what says RIPE has to have 10.000 members? Or 130 employees? And the current policy looks very much like a membership boosting construction: just sign up, pay the bill and get a /29 (compaired to ask a member to apply for a /48 with very restricted use and make life really hard if you ever want anything more).
What makes us think that PA holders/members are always responsible while PI holders/non-members are completely not trustworthy?
I would prefer policies to apply for addresses (let's say, thou shalt not assign less than a /xx to an yy) rather than the role play of today.
Best Regards,
Daniel Stolpe
_________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
-- Dan Luedtke http://www.danrl.de
* Gert Doering
The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of address space, "IPv6 addresses". This is the goal.
A goal which I support. However, the proposal does go a bit further than just this. For example, it: - unifies [PA] allocations and [PA] assignments - unifies the LIR and End User roles - allows an infinitely deep hierarchy of LIR+EU organisations - in doing so, significantly changes the structure of the Internet Registry System - dramatically increases the maximum undocumented delegation size from 1 /29 per LIR to $NUMSITES * /29. - codifies particular mercantile/contractual arrangements into internet number policy I think it would benefit the proposal's journey through the PDP if it tried to do fewer things at once, perhaps by splitting it into multiple proposals.
The idea to go there came from various people in the community, mostly for one reason - having two differently "coloured" addresses that do the same thing, routingwise, but follow different policies and have different strings attached, creates quite some confusion for the folks out there that can no longer be nicely separated into "ISPs" (->become RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming and/or upstream independence is required).
Most notably, "garage style hosting providers" seem to have issues with the requirement of the IPv6 PI policy that PI space MUST NOT be sub-assigned, which the NCC interprets most strictly (because the vast amount of "grey" between "ok" and "not ok" is hard to codify into hostmaster guidelines). OTOH, I have not heard that complaint from actual hosting providers for a while, so maybe the issue is not that big anymore.
Is this concern really specific to PI? I'd say this is more a problematic property of IPv6 *assignments* - regardless of them being PI or PA. Being a data centre operator and LIR, I believe I cannot currently make an IPv6 PA assignment to a customer of mine who wants to run a cloud service where their customers can rent virtual servers in turn. (A customer of theirs may in turn run some sort of web hotel for another set of customers on those VMs, and so on and so on.) I do have such customers today. "Luckily" they've not yet taken an interest in IPv6. In IPv4, on the other hand, I may (ab)use the "single address loophole" to assign them the addresses they need. In any case, this particular concern could be resolved by relaxing the requirements on assignments somewhat. For example by allowing End Users to use the addresses for providing services to other entities (who may in turn do the same and so on), as long as the End User the assignment is registered to retains operational responsibility for the network in question. Of course, this wouldn't by itself yield PI/PA unification. However I think that too may be accomplished in a less intrusive way than 2013-06 currently proposes: Delete section 7, and add a new section to the appendix or even just the supporting notes saying that it should be possible to obtain become an LIR and hold PA space without being a direct member of the RIPE NCC, and that this should cost about the same as holding PI does today, and that all pre-existing PI holders and their blocks/inet6nums should be automatically converted to this new arrangement. Just my €.02 Tore
On 29/10/2013 15:33, Tore Anderson wrote:
I think it would benefit the proposal's journey through the PDP if it tried to do fewer things at once, perhaps by splitting it into multiple proposals.
Agreed. Despite i'm globally ok with the spirit the proposal but I think having a proposal that meets the "main goal" is not yet granted. A few things seem problematic to me Removing the color looks interesting, but to me question is, what does it bring apart from cosmetics ? From what I read in the proposal there sitll would be a difference between End User block and End Site bloc. Call it (sub)allocated or assign, it is the same difference. The majors points seems to be that nowadays PI blocks would (a) be bigger tomorrow and (b) able to be further sub-allocated / assigned to End Users / Sites. Yes this is the major point since it will give independance for a lot of companies. But this, only is costs from the sponsoring LIRs are not a barrier. However this should lead to an automatic shift to what used to be PI, since any End User could request a /32 that would be independant from the LIR there seems to be a risk regarding the aggregation goal (I refer to old-style routing aggregation). Next, growing automatic End-User minimum allocation to /32 is going to be a problem for routing LIRs structure and/or ressource management since they are supposed to have a IPv6 plan. This /32 frontier standard might become a problem for the smaller networks routability, leading everybody to rush to a /32 without having a need for it because of some operators taking /32 as a new filtering limit. I did not see any financial consideration here, so LIRs might will to apply financial pressure of their customers (and as Sponsoring LIRs) slow the implieds changes. So I think we lack an impact analysis here, and I wonder about the impact for LIRs, and impact for Ripe in terms if membership and workload evolutions. Sorry if some of these we already discussed, this is just for the requested feedback, I did'nt have the time to read all the 99 posts yet. Best regards, Sylvain
Hi, the discussion phase for this is coming to an end, and what I've heard so far is mostly "great idea, way too complex approach to solving it". Anyway, to answer some of these... On Tue, Oct 29, 2013 at 03:33:18PM +0100, Tore Anderson wrote:
The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of address space, "IPv6 addresses". This is the goal.
A goal which I support. However, the proposal does go a bit further than just this. For example, it:
I think these are really unavoidable consequences if you - unify PA and PI - keep the "there is LIR" and "there is users of sponsored LIRs" model
- unifies [PA] allocations and [PA] assignments - unifies the LIR and End User roles - allows an infinitely deep hierarchy of LIR+EU organisations - in doing so, significantly changes the structure of the Internet Registry System
This is basically a consequence of the policy we currently *have* - PA space can be sub-allocated, even though this is slightly hidden in the policy... http://www.ripe.net/ripe/docs/ripe-589#lir-to-isp ("status: ALLOCATED-BY-LIR"). While the database does not have a status: value for "ALLLOCATED-BY-CUSTOMER-OF-LIR", there is nothing in the policy text that wouldn't allow multiple layers of "subordinate ISPs" for PA space - as long as "all /48 assignments" are properly documented... So - if you unify PI and PA, and continue to permit sub-allocations, this is where you end... (and it seems to match "reality" somewhat better than "there are LIRs and there are end-users, and no other categories in between").
- dramatically increases the maximum undocumented delegation size from 1 /29 per LIR to $NUMSITES * /29.
There's that, yes. If we accept the prerequisites above, this is a certain risk, which is why we tried countering this with "large blocks are somewhat more expensive".
[.. reasons why this proposal exists ..]
Is this concern really specific to PI? I'd say this is more a problematic property of IPv6 *assignments* - regardless of them being PI or PA. Being a data centre operator and LIR, I believe I cannot currently make an IPv6 PA assignment to a customer of mine who wants to run a cloud service where their customers can rent virtual servers in turn. (A customer of theirs may in turn run some sort of web hotel for another set of customers on those VMs, and so on and so on.)
You can :-) - ripe-589, 5.3. Well, you wouldn't "assign" the addresses to your customers, but "sub-allocate", and he would then assign individual /56s or whatever to the final end customers. But the addressing hierarchy is possible. [..]
Of course, this wouldn't by itself yield PI/PA unification. However I think that too may be accomplished in a less intrusive way than 2013-06 currently proposes: Delete section 7, and add a new section to the appendix or even just the supporting notes saying that it should be possible to obtain become an LIR and hold PA space without being a direct member of the RIPE NCC, and that this should cost about the same as holding PI does today, and that all pre-existing PI holders and their blocks/inet6nums should be automatically converted to this new arrangement.
Sounds easy, but I'm not sure this would actually solve all the questions that arise, like - why should anyone become a RIPE member if they can have their address space for 50 EUR/year insteaad? - under which conditions can an entity get two "LIR blocks", then? - which size of address block would a "non RIPE member" LIR receive? ... so in the end, the answers would likely be similarily lengthy than what was provided here. But anyway, just trying to shine some light on why I think the complexity is not exactly avoidable - but I get the message "this is too much too digest, and the problem it is solving does not seem to be that big after all". Gert Doering -- ripe policy victim -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (9)
-
Dan Luedtke -
Daniel Stolpe -
Erik Bais -
Gert Doering -
Jan Ingvoldstad -
Jetten Raymond -
Roger Jørgensen -
Sylvain Vallerot -
Tore Anderson