RIPE IPv4 Allocation Policy
Dear RIPE Address Policy Group, The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified. Regards, Walter This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately.
* SBS - Support <support@sonabusiness.nl>
The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified.
If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations. None. Zip, zilch, zero. How would that have been any less detrimental? Tore
Hi Tore, That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources. Regards, Walter ---- On Fri, 28 Aug 2015 13:55:07 +0200 Tore Anderson <tore@fud.no> wrote ---- * SBS - Support <support@sonabusiness.nl> > The RIPE policy of allocating only a PA /22 to new LIR's and not > allocating any further IPv4 resources is highly detrimental to the > growth of new upcoming organisations and protects legacy Telco > operators, what are your thoughts on reviewing this and coming up > with a process to allocate further resources to new LIR's if the need > can be justified. If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations. None. Zip, zilch, zero. How would that have been any less detrimental? Tore This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately.
Hi Walter, On 28/08/15 13:17, SBS - Support wrote:
That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources.
Have you seen what's happened in North America recently? I don't think that is a good news situations for small/new ISPs, and yet the story for bigger ISPs doesn't seem to have changed as a result. Anyone trading IPs (illegitimate or legitimately) is likely to be rather happy about the situation, too. Now that we have an example of what happens when you run out of IPv4 without 'running down fairly', one would hope it's clearer now why the policy is in place. Best regards, -- Tom Hill Network Engineer Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 (0) 1904 890 890
* SBS - Support <support@sonabusiness.nl>
That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources.
Where do you propose we locate these mythical «additional IP[v4] resources» we should proceed to allocate based on justified need, exactly? Tore
Hi Walter, be assured that the large telcos also need IPv4 addresses. If we return to need based policy, they will use up all remaining IPv4 addresses in a few days. This does not help anybody. But if you think anything should be changed, then please write a new policy proposal and start the discussion. Regards, Wilhelm Am 28.08.2015 um 14:17 schrieb SBS - Support:
Hi Tore,
That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources.
Regards, Walter
---- On Fri, 28 Aug 2015 13:55:07 +0200 *Tore Anderson <tore@fud.no>* wrote ----
* SBS - Support <support@sonabusiness.nl <mailto:support@sonabusiness.nl>>
> The RIPE policy of allocating only a PA /22 to new LIR's and not > allocating any further IPv4 resources is highly detrimental to the > growth of new upcoming organisations and protects legacy Telco > operators, what are your thoughts on reviewing this and coming up > with a process to allocate further resources to new LIR's if the need > can be justified.
If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations.
None.
Zip, zilch, zero.
How would that have been any less detrimental?
Tore
This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately.
On Fri, Aug 28, 2015, at 14:50, Wilhelm Boeddinghaus wrote:
be assured that the large telcos also need IPv4 addresses. If we return to need based policy, they will use up all remaining IPv4 addresses in a few days. This does not help anybody.
There are 2 views of "needs-based": - allocate as much as needed (that clearly won't last long) - only allocate IF needed (what would be supposed to make things last longer - but it's gone)
Hi, On Fri, Aug 28, 2015 at 02:17:37PM +0200, SBS - Support wrote:
That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources.
Do you have a few /8s available that the RIPE NCC could use to do that? IPv4 has run out. Choices are "distribute the rest in small scraps, so new entrants in the market can at least get *some* space" or "first come, first served, bam, nothing left" - almost everybody in the business is able to document need now, and if the NCC fulfills that, the remaining space is gone by end of August. ARIN has decided to run against the wall, and we'll see how well that works out - the other RIRs (including RIPE) have decided to go for "small scraps", and it seems to distribute the pain somewhat evenly... Gert -- 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, Aug 28, 2015, at 13:55, Tore Anderson wrote:
If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations.
Between the old policy (pre last-/8) and the new one, there is a whole lot of middleground.
* Radu-Adrian FEURDEAN
On Fri, Aug 28, 2015, at 13:55, Tore Anderson wrote:
If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations.
Between the old policy (pre last-/8) and the new one, there is a whole lot of middleground.
Certainly, but what's being asked for in this thread *is* essentially the old policy: «If need is justified there has to be a process to allocate additional IP resources.» There's no middle ground (that I can think of, anyway) between the old and the new policy where we won't have to go against the above at some point, instead telling applicants something like «while your need is justified, we're sorry, we won't be allocating you what you ask for». In any case, Nick is right. If someone is unhappy about the current policy and thinks it could be better, that someone needs to submit an actual policy proposal. Until that happens it's not much point in rehashing this dicussion yet another time. Tore
On 28/08/2015 12:28, SBS - Support wrote:
The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified.
Anyone is free to suggest a better mechanism. If you have some ideas which are better that what's already there, please feel free to write a proposal. Nick
On 28.08.2015 15:13, Nick Hilliard wrote:
Anyone is free to suggest a better mechanism. If you have some ideas which are better that what's already there, please feel free to write a proposal.
Maybe something along the lines of "you can have a second /22" after a certain period of time if you only have a /22. The rationale behind this could be that RIPE NCC got more address space than anticipated when the last /8 was made. According to https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustio... RIPE NCC currently have 17.7 M IPv4 addresses left - which is slightly more than a /8 (https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustio...) NRO June figures: https://docs.google.com/viewer?url=https%3A%2F%2Fwww.nro.net%2Fwp-content%2F... Afrinic: 2.7 RIPE NCC: 1.08 APNIC: 0,69 Lacnic: 0.16 Arin: 0.1 now down to 0.0015 So if somebody want to pursue this I suggest looking a t https://www.ripe.net/publications/docs/ripe-642 and create a proposal using the Policy template in Appendix B But it is really time to get serious about IPv6. (Since you can do Google and Facebook on v6 - what more do you want:-) -- Hans Petter Holen Mobile +47 45 06 60 54 | hph@oslo.net<mailto:hph@oslo.net> | http://hph.oslo.net
Hi Hans, Do you know there is a "bug" in Android with IPv6? I had to disable IPv6 in all my customers due to this issue.(*) (*) https://code.google.com/p/android/issues/detail?id=79576 While IPv6 is not fully supported by the majority of the devices, it cant be deployed. Regards, El 30/08/2015 a las 18:02, Hans Petter Holen escribió:
On 28.08.2015 15:13, Nick Hilliard wrote:
Anyone is free to suggest a better mechanism. If you have some ideas which are better that what's already there, please feel free to write a proposal.
Maybe something along the lines of "you can have a second /22" after a certain period of time if you only have a /22.
The rationale behind this could be that RIPE NCC got more address space than anticipated when the last /8 was made. According to https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustio... RIPE NCC currently have 17.7 M IPv4 addresses left - which is slightly more than a /8 (https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustio...)
NRO June figures: https://docs.google.com/viewer?url=https%3A%2F%2Fwww.nro.net%2Fwp-content%2F...
Afrinic: 2.7 RIPE NCC: 1.08 APNIC: 0,69 Lacnic: 0.16 Arin: 0.1 now down to 0.0015
So if somebody want to pursue this I suggest looking a t https://www.ripe.net/publications/docs/ripe-642 and create a proposal using the Policy template in Appendix B
But it is really time to get serious about IPv6. (Since you can do Google and Facebook on v6 - what more do you want:-)
On 31.08.2015 12:19, Daniel Baeza (Red y Sistemas TVT) wrote:
Hi Hans,
Do you know there is a "bug" in Android with IPv6? I am quite sure there are as many bugs in various systems. Acting professionally we should report these to the vendors and push to get them fixed. Some of the vendors take part in RIPE meetings - so working trough informal channels is also known to work.
I had to disable IPv6 in all my customers due to this issue.(*)
(*) https://code.google.com/p/android/issues/detail?id=79576
While IPv6 is not fully supported by the majority of the devices, it cant be deployed.
I do know that 8% of the traffic seen by Google is IPv6 http://www.google.com/intl/en/ipv6/statistics.html and that Google sees more than 35% from Belgium - http://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption So I beg to differ - IPv6 can indeed be deployed. Further discussion on deployment IPv6 belong in the IPv6 wg. In Address Policy you are welcome to propose changes to the policy. Hans Petter
Regards,
El 30/08/2015 a las 18:02, Hans Petter Holen escribió:
On 28.08.2015 15:13, Nick Hilliard wrote:
Anyone is free to suggest a better mechanism. If you have some ideas which are better that what's already there, please feel free to write a proposal.
Maybe something along the lines of "you can have a second /22" after a certain period of time if you only have a /22.
The rationale behind this could be that RIPE NCC got more address space than anticipated when the last /8 was made. According to https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustio...
RIPE NCC currently have 17.7 M IPv4 addresses left - which is slightly more than a /8 (https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustio...)
NRO June figures: https://docs.google.com/viewer?url=https%3A%2F%2Fwww.nro.net%2Fwp-content%2F...
Afrinic: 2.7 RIPE NCC: 1.08 APNIC: 0,69 Lacnic: 0.16 Arin: 0.1 now down to 0.0015
So if somebody want to pursue this I suggest looking a t https://www.ripe.net/publications/docs/ripe-642 and create a proposal using the Policy template in Appendix B
But it is really time to get serious about IPv6. (Since you can do Google and Facebook on v6 - what more do you want:-)
-- Hans Petter Holen Mobile +47 45 06 60 54 | hph@oslo.net<mailto:hph@oslo.net> | http://hph.oslo.net
Hi, On Mon, Aug 31, 2015 at 12:19:18PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote:
Do you know there is a "bug" in Android with IPv6?
I had to disable IPv6 in all my customers due to this issue.(*)
(*) https://code.google.com/p/android/issues/detail?id=79576
I can't see why you would need to disable IPv6 completely just because one client OS does not support IPv6-*only* operation? Android works totally well in dual-stack networks - not using IPv6 if you mandate stateful DHCPv6, though.
While IPv6 is not fully supported by the majority of the devices, it cant be deployed.
"Some vendor's interpretation of Android" is hardly "the majority of devices"... Gert Doering -- deploying IPv6 in our office and wifi networks since 10+ years -- 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
The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified.
as those egacy telcos got all that address space because they could justify it, what makes you think they would not have the very same justification fo rmassive need now? the thought behind one /22 per newcomer is to prevent the biggies from gobbling it all up instantly and to see that it is there to allw for new entrants. of course the new entrants will not get all they need. no one will; ipv4 space is gone; get over it. but they can get enough to nat or nat64 or whaever to at least get in the door. randy
participants (10)
-
Daniel Baeza (Red y Sistemas TVT) -
Gert Doering -
Hans Petter Holen -
Nick Hilliard -
Radu-Adrian FEURDEAN -
Randy Bush -
SBS - Support -
Tom Hill -
Tore Anderson -
Wilhelm Boeddinghaus