2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8)
Dear colleagues, The draft document for version 3.0 of the policy proposal 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8", has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 2.0 include: - Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC - Related wording adjustments in the title, summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-04 The draft document is available at: https://www.ripe.net/ripe/policies/proposals/2014-04/draft We encourage you to read the draft document and send any comments to address-policy-wg@ripe.net before 7 January 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC
On 09/12/2014 15:20, Marco Schmidt wrote:
- Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC - Related wording adjustments in the title, summary and rationale of the proposal
support. Nick
Hi, On 09.12.2014 16:20, Marco Schmidt wrote:
- Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC - Related wording adjustments in the title, summary and rationale of the proposal
I support these changes and the proposal as it now stands. Regards André
On Tue, Dec 09, 2014 at 04:20:30PM +0100, Marco Schmidt wrote:
The draft document for version 3.0 of the policy proposal 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8", has now been published, along with an impact analysis conducted by the RIPE NCC.
Supported. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
* Marco Schmidt
It's been shown that the current /22 IPv6 requirement causes difficulties in a particular corner case where the applicant has actually already obtained an IPv6 non-PA delegation and are most likely making use of it too (since returning/renumbering is problematic). This is exactly the opposite of the desired effect of fostering IPv6 deployment, indeed, it could be considered as penalising IPv6 deployment. I believe that at this point in time, the community's awareness and use of IPv6 isn't likely to increase further by keeping the /22 IPv6 requirement. In a nutshell: LIRs who have no interest in IPv6 won't start actual deployment even if the /22 IPv6 requirement forces them to obtain an IPv6 allocation, while LIRs who do have an interest in IPv6 will be perfectly able to obtain and deploy IPv6 without the /22 IPv6 requirement present. Given the above, I think it is time to remove it completely. That seems the simplest and cleanest solution. +1 Tore
On Wed, 10 Dec 2014, Tore Anderson wrote:
* Marco Schmidt
It's been shown that the current /22 IPv6 requirement causes difficulties in a particular corner case where the applicant has actually already obtained an IPv6 non-PA delegation and are most likely making use of it too (since returning/renumbering is problematic). This is exactly the opposite of the desired effect of fostering IPv6 deployment, indeed, it could be considered as penalising IPv6 deployment.
I believe that at this point in time, the community's awareness and use of IPv6 isn't likely to increase further by keeping the /22 IPv6 requirement. In a nutshell: LIRs who have no interest in IPv6 won't start actual deployment even if the /22 IPv6 requirement forces them to obtain an IPv6 allocation, while LIRs who do have an interest in IPv6 will be perfectly able to obtain and deploy IPv6 without the /22 IPv6 requirement present.
Given the above, I think it is time to remove it completely. That seems the simplest and cleanest solution.
+1
Tore
Very well put. +1 Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
Hi, Am 09.12.2014 um 16:20 schrieb Marco Schmidt:
- Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC - Related wording adjustments in the title, summary and rationale of the proposal
I do not agree with this proposal. Let me explain that with a simple case: Our company is a LIR for just a few month now; the main reason why we signed up on April this year was that we started to run out of IP addresses and wanted to get that /22 IPv4 allocation (we already had a /24). And for us the only reason to deploy IPv6 was that we had to request an allocation in the first place. In our case we are a software company and we provide hosting services only for our existing customers and for our own software; therefore, the additional /22 IPv4 allocation that we received is suitable to expand our business and still have enough IPv4 address space for a long time. So, actually, we don't need IPv6 yet; and the chances are quite high that if we did not had to request the IPv6 allocation we would still be living happily with IPv4 only. Everyone who decided to deploy IPv6 will automatically inform others. A lot of our customers didn't even know that IPv6 exists; so they need other companies to inform them why they need it and why they should be concerned about it. Additionally we noticed that selling IPv6 is not even for our upstream providers a common process. They are capable of providing IPv6 and generally it works quite fine; however, there is a slight difference between anyone who's keen to sell his company's services and anyone who's fine with selling services if the customer is willing to pay for it. And from my experience the first one applies to IPv4 and the second one to IPv6. There are about 1000 new LIRs per year; if only this new LIRs would have to request an IPv6 allocation I believe that a lot of them would want to have this IPv6 allocation set up an running even if it's only because they've received it (as it was the case for our company). And the same applies to any existing LIR requesting their last /22. From my point of view, the removal of the IPv6 requirement would slow down the process of deploying IPv6; the more everyone is talking about IPv6 to customers as well as to other providers (especially upstream providers) the more public awareness of IPv6 increases and the more selling and buying IPv6 services goes without saying - and that's what we need. Kind Regards, Stefan Schiele
Hi Stefan,
Let me explain that with a simple case: Our company is a LIR for just a few month now; the main reason why we signed up on April this year was that we started to run out of IP addresses and wanted to get that /22 IPv4 allocation (we already had a /24). And for us the only reason to deploy IPv6 was that we had to request an allocation in the first place.
[...]
From my point of view, the removal of the IPv6 requirement would slow down the process of deploying IPv6; the more everyone is talking about IPv6 to customers as well as to other providers (especially upstream providers) the more public awareness of IPv6 increases and the more selling and buying IPv6 services goes without saying - and that's what we need.
I fully agree that there is need for public awareness for IPv6 deployment. However, I think there are better ways for causing awareness and get people talking about IPv6 etc than doing this in address policy. I would suggest that we ask the RIPE NCC to increase their outreach to LIRs that don't have any IPv6 address space, explain the need for IPv6 deployment, promote the trainings provided by the RIPE NCC etc. Just because a RIPE policy doesn't require an LIR to request IPv6 space anymore doesn't mean that the RIPE NCC cannot promote IPv6, especially if we as a community ask them to. Cheers, Sander
Hi Sander, Am 10.12.2014 um 14:11 schrieb Sander Steffann:
I fully agree that there is need for public awareness for IPv6 deployment. However, I think there are better ways for causing awareness and get people talking about IPv6 etc than doing this in address policy.
I would suggest that we ask the RIPE NCC to increase their outreach to LIRs that don't have any IPv6 address space, explain the need for IPv6 deployment, promote the trainings provided by the RIPE NCC etc. Just because a RIPE policy doesn't require an LIR to request IPv6 space anymore doesn't mean that the RIPE NCC cannot promote IPv6, especially if we as a community ask them to.
I would love to see the RIPE NCC doing more to promote IPv6. I've visited training courses a few months ago; and I was told that it's our job as LIRs to promote IPv6 to our customers. In my opinion that sounds quite reasonable; the RIPE NCC can only reach the LIRs; the LIRs are the ones that can improve their customers awareness. Therefore I would say that the RIPE NCC needs the help of as much LIRs as possible to be able to increase general IPv6 deployment. Mike had a very good example with a cake and vegetables: It might be an annoyance if you have to eat more vegetables in order to get a piece of cake; but, if mothers in general wouldn't care about their children's nutrition a lot of us folks would end up eating fast food all the time and in the end suffering from several severe diseases. Regards, Stefan
Hi, On Wed, Dec 10, 2014 at 12:42:16PM +0100, Stefan Schiele wrote:
Let me explain that with a simple case: Our company is a LIR for just a few month now; the main reason why we signed up on April this year was that we started to run out of IP addresses and wanted to get that /22 IPv4 allocation (we already had a /24). And for us the only reason to deploy IPv6 was that we had to request an allocation in the first place.
So did you actually *deploy* IPv6, as in "every new service you run and install has IPv6 on it, every new product you build supports IPv6", or did you just *get* an IPv6 block, put it on a shelf, and leave it there? I'm impressed if our existing policy actually had such a big impact, and it wasn't just "the last nudge to get going" - which we could easily achieve by having the NCC IPRAs ensure that LIRs asking for a /22 are aware of IPv6 ("have you considered deploying IPv6?"). Gert Doering -- NetMaster -- 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
Hi Gert, Am 10.12.2014 um 20:02 schrieb Gert Doering:
So did you actually*deploy* IPv6, as in "every new service you run and install has IPv6 on it, every new product you build supports IPv6", or did you just*get* an IPv6 block, put it on a shelf, and leave it there?
I'm impressed if our existing policy actually had such a big impact, and it wasn't just "the last nudge to get going" - which we could easily achieve by having the NCC IPRAs ensure that LIRs asking for a /22 are aware of IPv6 ("have you considered deploying IPv6?").
We really deployed IPv6 ;-) All servers used for customer software solutions and except for one service all our other services are IPv6 enabled. For sure, we still have some servers in our internal network that are not IPv6 capable (e.g. some print servers); for IPv6 we currently focus on everything that is publicly accessible (and on core components, for sure). Servers that are only used internally get IPv6 enabled on the next OS update or at the time the server will be replaced. I get your point that there is no use in allocation IPv6 space to an LIR if that space is not used; do you know whether statistical data is available how much IPv6 address space that has been allocated to those LIRs which requested their final /22 is actually visible in the BGP routing tables? Regards, Stefan
Hi Stefan, On 11/12/14 10:19, Stefan Schiele wrote:
I get your point that there is no use in allocation IPv6 space to an LIR if that space is not used; do you know whether statistical data is available how much IPv6 address space that has been allocated to those LIRs which requested their final /22 is actually visible in the BGP routing tables?
The RIPE NCC has started allocating /22s from the last /8 on 14 September 2012. Since then 4190 IPv6 allocations have been made, out of which 1160 are currently visible in the BGP routing tables. If we take into consideration the total number of IPv6 allocations made by the RIPE NCC, 8398 IPv6 allocations have been made, out of which 4098 are currently visible in the BGP routing tables. I hope this helps. Best regards, Andrea Cima RIPE NCC
On Wed, Dec 10, 2014 at 08:02:10PM +0100, Gert Doering wrote:
So did you actually *deploy* IPv6, as in "every new service you run and install has IPv6 on it, every new product you build supports IPv6", or did you just *get* an IPv6 block, put it on a shelf, and leave it there?
it appears to me this is asking for more than what was aimed at. If memory serves the idea was to get the message through, even by pushing the issue through LIRs' internal escalation chains. Now, there are some odd conditions with PI holders that need attention and change, but the proposal declares defeat for a non-goal of the current policy. -Peter
Hi Stefan, On Wed, 10 Dec 2014 12:42:16 +0100 Stefan Schiele <st@sct.de> wrote:
There are about 1000 new LIRs per year; if only this new LIRs would have to request an IPv6 allocation I believe that a lot of them would want to have this IPv6 allocation set up an running even if it's only because they've received it (as it was the case for our company). And the same applies to any existing LIR requesting their last /22.
From my point of view, the removal of the IPv6 requirement would slow down the process of deploying IPv6; the more everyone is talking about IPv6 to customers as well as to other providers (especially upstream providers) the more public awareness of IPv6 increases and the more selling and buying IPv6 services goes without saying - and that's what we need.
The proposal does not preclude the RIPE NCC from mentioning to LIRs who request their last /22 that there is such a thing as IPv6 and that an LIR can get an IPv6 allocation with one click if they want it. This can be done as part of the increased outreach that the impact analysis talks about. Kind regards, Martin
Hi, I support, provided that the RIPE NCC will inform the applicants about IPv6. Regards, George On Thu, Dec 11, 2014 at 10:36 AM, Martin Pels <martin.pels@ams-ix.net> wrote:
Hi Stefan,
On Wed, 10 Dec 2014 12:42:16 +0100 Stefan Schiele <st@sct.de> wrote:
There are about 1000 new LIRs per year; if only this new LIRs would have to request an IPv6 allocation I believe that a lot of them would want to have this IPv6 allocation set up an running even if it's only because they've received it (as it was the case for our company). And the same applies to any existing LIR requesting their last /22.
From my point of view, the removal of the IPv6 requirement would slow down the process of deploying IPv6; the more everyone is talking about IPv6 to customers as well as to other providers (especially upstream providers) the more public awareness of IPv6 increases and the more selling and buying IPv6 services goes without saying - and that's what we need.
The proposal does not preclude the RIPE NCC from mentioning to LIRs who request their last /22 that there is such a thing as IPv6 and that an LIR can get an IPv6 allocation with one click if they want it. This can be done as part of the increased outreach that the impact analysis talks about.
Kind regards, Martin
Support +1
Support. The marginal public awareness utility of the IPv6 requirement is not worth the policy verbiage. Well-intentioned but inappropriate use of policy to burden members with unwanted IPv6 space. It's like I want a piece of cake and mother says okay, but you must also take some more vegetables. The vegetables remain on the plate, uneaten and destined for the garbage, because mother thinks I might try them and like them. I would change my mother's policy if I could! -----Original Message----- From: Erik Bais Sent: Wednesday, December 10, 2014 8:21 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2014-04 New Draft Document and ImpactAnalysis Published (Removing IPv6 Requirement for ReceivingSpace from the Final /8) Support +1
I dont agree. -- Daniel Baeza
Hi Daniel,
Op 12 dec. 2014, om 10:53 heeft Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> het volgende geschreven:
I dont agree.
With what exactly? We make policy based on arguments. Please provide us (=this list) with arguments why you don't agree so they can be discussed. Thanks! Sander
Hi Sander, Sorry, I thought all on the list knew my position about that. I will stole the arguments from Stefan Schiele. I hope he doesnt mind. In our case, we are not a software company providing hosting. We are a little Local ISP in an "small" town (arround 100k population) and same as Stefan Schiele, we runned out of IPv4 and our transit provider, in that moment, couldnt gave us more. Until that moment, I never cared out about IPv6. Only when we was "forced" to have an alloc of IPv6 I cared and thinked about it. Now, I consider myself an IPv6 warrior.
Andrea Cima wrote: The RIPE NCC has started allocating /22s from the last /8 on 14 September 2012. Since then 4190 IPv6 allocations have been made, out of which 1160 are currently visible in the BGP routing tables.
That means arround 27%. To be honest, I thought a really lower numbers before Andrea said the real ones. Taking into account the current IPv6 deployment rate, I'm more convinced we need the current requisite of having an IPv6 alloc to request the last /22. The only argument supporting the proposal:
In order to receive an allocation from the final /8, LIRs are currently required to have received an IPv6 allocation. This requirement was originally meant to foster IPv6 deployment. However, in some cases it does the reverse. If LIRs have an existing IPv6 PI assignment but no IPv6 PA allocation, they do not meet this criterion. In order to qualify, they need to request an IPv6 allocation and subsequently return their existing PI assignment (per ripe-589 section 7.1).
The problem is LIRs with PI space dont having the requirements to recieve the v4 /22 from the last /8. Why just dont allow PI assignment to be valid to recieve an alloc from the final /8?
Since there is a huge difference between having received an IPv6 allocation and actually deploying IPv6, there is doubt that the requirement has in fact lead to wider IPv6 adoption.
A 27% from a total of ~50% alloc/published ipv6 that will be lost in the current v6 deployment. TL;DR Requesting an IPv6 allocation dont takes time, its only a procedure. The 27% of LIRs who did the procedure have IPv6 published in BGP and I hope at least half of them have it working too. Just allowing v6PI space to be valid to recieve the /22 from last /8 is easier. And those are my arguments. PD: You asked for them, now you read it! :D El 13/12/2014 20:48, Sander Steffann escribió:
Hi Daniel,
Op 12 dec. 2014, om 10:53 heeft Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> het volgende geschreven:
I dont agree.
With what exactly? We make policy based on arguments. Please provide us (=this list) with arguments why you don't agree so they can be discussed.
Thanks! Sander
-- Daniel Baeza
* Marco Schmidt <mschmidt@ripe.net> [2014-12-09 16:30]:
Dear colleagues,
The draft document for version 3.0 of the policy proposal 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8", has now been published, along with an impact analysis conducted by the RIPE NCC.
Support Regards, Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Dear APWG, On Tue, Dec 09, 2014 at 04:20:30PM +0100, Marco Schmidt wrote:
The draft document for version 3.0 of the policy proposal 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8", has now been published, along with an impact analysis conducted by the RIPE NCC. [..] We encourage you to read the draft document and send any comments to address-policy-wg@ripe.net before 7 January 2015.
The review phase for 2014-04 has ended. Given the amount of support over the lifetime of this proposal, and the nature of the opposition, I have decided that we have reached rough consensus (Sander as co-chair has abstained, because he has officially taken an opionion). The main counterargument brought up was that this would lower the incentive for LIRs to adopt IPv6 and would create the impression that IPv6 is no longer important to the RIPE community. To counter that, the chairs will ask the RIPE NCC to continue their good work in raising IPv6 awareness and to continue to mention it on IPv4 /22 requests. So, I consider the counterarguments addressed, and see enough support to declare rough consensus and move the proposal forward. This is what I'll do now -> move 2014-04 to Last Call. Marco will send the formal announcement for that later today or tomorrow. For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what I have based my decision on. If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase for V3.0, starting Dec 09, 2014 Support: Nick Hilliard Andre Keller Daniel Roesen Hamed Shafaghi Tore Anderson Daniel Stolpe Erik Bais Mike Burns George Giannousopoulos (as long as the NCC informs applicants about IPv6) Sebastian Wiesinger Opposing: Daniel Baeza Stefan Schiele (both on the basis that stronger encouragement for IPv6 is needed, and that the IPv4 "last /22" policy would be the right approach to doing it) Comment, not stating clear pro/con Peter Koch -- 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
Dear Address Policy WG, On Tue, Jan 13, 2015 at 02:50:37PM +0100, Gert Doering wrote:
The review phase for 2014-04 has ended.
Given the amount of support over the lifetime of this proposal, and the nature of the opposition, I have decided that we have reached rough consensus (Sander as co-chair has abstained, because he has officially taken an opionion).
The main counterargument brought up was that this would lower the incentive for LIRs to adopt IPv6 and would create the impression that IPv6 is no longer important to the RIPE community. To counter that, the chairs will ask the RIPE NCC to continue their good work in raising IPv6 awareness and to continue to mention it on IPv4 /22 requests.
So, I consider the counterarguments addressed, and see enough support to declare rough consensus and move the proposal forward.
The "last call" phase has now ended. Unlike most proposals, there was quite a bit of discussion in Last Call. After reviewing the messages sent, the chairs have decided that no new arguments have been brought up - and repetition of arguments that have been discussed and addressed before does not stop consensus, if strong support exists otherwise. It might be a bit more rough than for other proposals, but "rough consensus" is good enough. Thus, the chairs hereby declare consensus on 2014-04. If you disagree with this decision please contact the working group chairs (preferably on this public mailing list and otherwise by sending mail to apwg-chairs@ripe.net). Should that not resolve the problem then you can appeal to the WG chairs collective (as per section 4 of ripe-614). Marco will send the formal announcement from the NCC soon. regards, Gert Doering and Sander Steffann -- APWG chairs -- 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 (17)
-
Andre Keller -
Andrea Cima -
Daniel Baeza (Red y Sistemas TVT) -
Daniel Roesen -
Daniel Stolpe -
Erik Bais -
George Giannousopoulos -
Gert Doering -
Marco Schmidt -
Martin Pels -
Mike Burns -
Nick Hilliard -
Peter Koch -
Sander Steffann -
Sebastian Wiesinger -
Stefan Schiele -
Tore Anderson