Re: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses
On 3 October 2012 15:21, LeaderTelecom B.V. <info@leadertelecom.nl> wrote:
You can sub-allocate up to a /20 every twelve months to a single downstream Internet Service Provider (ISP). The minimum sub-allocation size is a /24. This is the smallest prefix length that can be reverse delegated and that allows for a reasonable number of small assignments to be made by a downstream network operator.
Okay So wouldn't the best change be to allow up to allocation window per annum plus an ability to go via the RIPE NCC for further sub-allocations? J -- James Blessing 07989 039 476
Dear James,
So wouldn't the best change be to allow up to allocation window per annum plus an ability to go via the RIPE NCC for further sub-allocations?
What you mean when tell about "allocation window"? Do you mean assignment window? -- Kind regards, Alexey Ivanov 03.10.2012 20:02 - James Blessing написал(а): On 3 October 2012 15:21, LeaderTelecom B.V. <info@leadertelecom.nl> wrote:
You can sub-allocate up to a /20 every twelve months to a single downstream Internet Service Provider (ISP). The minimum sub-allocation size is a /24. This is the smallest prefix length that can be reverse delegated and that allows for a reasonable number of small assignments to be made by a downstream network operator.
Okay So wouldn't the best change be to allow up to allocation window per annum plus an ability to go via the RIPE NCC for further sub-allocations? J -- James Blessing 07989 039 476
Hi, On Tue, Oct 09, 2012 at 02:33:48AM +0400, LeaderTelecom B.V. wrote:
So wouldn't the best change be to allow up to allocation window per annum plus an ability to go via the RIPE NCC for further sub-allocations?
What you mean when tell about "allocation window"? Do you mean assignment window?
Sub-Allocations actually have their own "window" - one /20 per receipient per annum. Not coupled to the "assignment window". James' proposal has its merits, but OTOH, just loosening up sub-allocations might be the approach more appropriate for "the time we're living through". When this policy was initially written, there was a) no experience with sub-allocations, so I was careful, and b) worries that this might lead to LIRs sub-allocating all their space out the window, and then ending up in lengthy discussions with the NCC hostmasters - so a barrier was built in that was reasonable for the time and the envisioned usage ("customers that run ISP-ish businesses and need larger chunks of addresses to handle their customer allocations themselves"). While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now... Gert Doering -- APWG chair and author of the IPv4 sub-allocation policy :-) -- 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 (89) 32356-444 USt-IdNr.: DE813185279
* Gert Doering
James' proposal has its merits, but OTOH, just loosening up sub-allocations might be the approach more appropriate for "the time we're living through".
[...]
While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now...
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here. It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays? If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Removing the needs-based requirement would break open the entire IPv4 market, letting big corporations to buy everything available and then decide who they are willing to sell it for the highest price. IP addresses will become a tool to obstruct competitors, wipe-out all smaller players and locking the market for newcomers. An authority validating each request with the current policies could somewhat prevent that from happening. At 09-10-2012 12:16, Tore Anderson wrote:
* Gert Doering
James' proposal has its merits, but OTOH, just loosening up sub-allocations might be the approach more appropriate for "the time we're living through".
[...]
While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now...
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here.
It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays?
If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy.
* Michiel Klaver
Removing the needs-based requirement would break open the entire IPv4 market, letting big corporations to buy everything available and then decide who they are willing to sell it for the highest price.
IP addresses will become a tool to obstruct competitors, wipe-out all smaller players and locking the market for newcomers. An authority validating each request with the current policies could somewhat prevent that from happening.
You could say the same thing about real estate or pretty much any other freely traded resource in the world, and yet the sky isn't falling. In a competitive market, supply and demand will regulate the prices. Otherwise, there's plenty of laws governing cartels, monopolies, price fixing, anti-competitive practises, and so forth. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Removing the needs-based requirement would break open the entire IPv4 market, letting big corporations to buy everything available and then decide who they are willing to sell it for the highest price. I think big companies can approve via RIPE any transfers while they have
IP addresses will become a tool to obstruct competitors, wipe-out all smaller players and locking the market for newcomers. Newcomers can get 1024 IPv4 as new LIR. I think any restrictions only increase
An authority validating each request with the current policies could somewhat prevent that from happening. Aha.. Just check big blocks (100k IPs and more) which were allocated before IPv4 were finished in RIPE. Of course I think all was made as it was written in
Dear Michiel, thousands work places, servers, and etc. If we discuss sub-allocations - then allocated PA block won't changed. And they can't sell too high. prices. All people usually busy (who not busy here?). If someone has IP and can very simple give it to someone - then more IPs will be available and prices for IP will be lower. I had this situation - in one company told me that they can sub-allocate IP, but don't have any time for bureaucracy. policy. It is just a black hole in policy. Conclusion: let’s make simple regulation. Less paperwork, more freedom. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team
I agree with Alexey about any restrictions only increase prices. Hamed -- I Hamed Shafaghi I I Managing Director I I Skydsl® Telecom I hamed@skydsl.ir I www.skydsl.ir I
On 10/11/12 1:39 PM, Hamed Shafaghi wrote:
I agree with Alexey about any restrictions only increase prices.
I'm not sure we are still inside the scope limits of Address Policy WG here :) Chairs will correct me if I'm wrong. Cheers, Jan
Hi Tore,
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here.
It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays?
If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy.
Call for feedback: I am very interested in how the working group feels about such an idea these days now that the normal RIPE NCC IPv4 pool has run out. Thank you, Sander Steffann APWG co-chair
On Tue, 9 Oct 2012, Sander Steffann wrote:
Hi Tore,
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here.
It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays?
If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy.
Call for feedback: I am very interested in how the working group feels about such an idea these days now that the normal RIPE NCC IPv4 pool has run out.
I think Tore has a point. The rules for IPv4 were useful as long as there were IPv4 addresses to hand out but now they just makes life harder for those who need addresses and if we have a lot of regulations to stop an open market we will just have higher prices on a black market. I would also like to see IPv6 policies much more simple. The situation today is that customers applying for IPv6 space are rejected completely or if they a number of prefixes (i.e. an international clouds based company wants one per site) they get some, but not fewer than they wanted. 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, On Fri, Oct 12, 2012 at 01:48:37PM +0200, Daniel Stolpe wrote:
I would also like to see IPv6 policies much more simple.
So do I, and I *am* working on that. But let's not intermix this into IPv4 discussions (otherwise we loose focus). 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 (89) 32356-444 USt-IdNr.: DE813185279
Hi, On Tue, Oct 09, 2012 at 12:16:24PM +0200, Tore Anderson wrote:
While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now...
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here.
Well, sub-allocation used to be special in the same way allocations are different than PI assignments - "the receipient is assumed to be an ISP-ish operation that provides (needs-based) assignment to lots of end-users".
It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays?
There are traces of needs-based still present in the system - like the transfer policy requiring the receipient to "document need" to the NCC to get the transfer approved (... and the ARIN folks flatly refusing cross-RIR transfers if the receipient RIR has no needs-based component). So if you permit LIRs to "just give away their stuff" and then go back to the NCC and claim "need!" (to get an incoming transfer approved), this is not without its own risks. (Not that we couldn't change the transfer policy towards "both parties tell the NCC, the NCC registers the transfer, done"... someone would have to propose that, though, and fight for it) 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 (89) 32356-444 USt-IdNr.: DE813185279
Gert Doering wrote: [...]
There are traces of needs-based still present in the system
AFAIK RFC2050 still is in effect. All more recent suggestions to get it modified or retired were not successful. I got to understand that messing around with it [c|w]ould have far-reaching unwanted consequences for the whole IP Address Distribution System. FWIW, Wilfried.
Hi, On Thu, Oct 11, 2012 at 03:27:48PM +0200, Wilfried Woeber wrote:
Gert Doering wrote:
[...]
There are traces of needs-based still present in the system
AFAIK RFC2050 still is in effect.
All more recent suggestions to get it modified or retired were not successful.
I got to understand that messing around with it [c|w]ould have far-reaching unwanted consequences for the whole IP Address Distribution System.
Like we have Addresses to Distribute :-) - the IPv4 run-out has fairly fundamental consequences for the environment in which we operate, and at least one of the pillars of RFC2050 ("conservation") is not exactly relevant anymore. I consider RFC2050 a very useful document to establish principles, but it can not be binding - and in doubt, the bottom-up community based process will win. 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 (89) 32356-444 USt-IdNr.: DE813185279
Dear Gert, Agree with your opinion regards RFC 2050. Main idea this RFC: This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Goals:
1. Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space.
This doesn't required anymore. While RIPE doesn't have free space for distributing. It was very useful before and respect for people who wrote it while principes in this RFC were very useful long time. But for now it looks as deprecated and not updated. Some words from RFC which looks like depriceated: ...Currently there are three regional IRs established; InterNIC serving North America, RIPE NCC serving Europe, and AP- NIC serving the Asian Pacific region... ...3.2 Network Engineering Plans.. 2. a description of the network topology 3. a description of the network routing plans, including the routing protocols to be used as well as any limitations.. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team URL: [1]http://www.LeaderTelecom.nl/ - IP- addresses URL: [2]http://www.GetWildcard.com/nl - WildCard SSL certificates 11.10.2012 17:46 - Gert Doering написал(а): Hi, On Thu, Oct 11, 2012 at 03:27:48PM +0200, Wilfried Woeber wrote:
Gert Doering wrote:
[...]
There are traces of needs-based still present in the system
AFAIK RFC2050 still is in effect.
All more recent suggestions to get it modified or retired were not successful.
I got to understand that messing around with it [c|w]ould have far-reaching unwanted consequences for the whole IP Address Distribution System.
Like we have Addresses to Distribute :-) - the IPv4 run-out has fairly fundamental consequences for the environment in which we operate, and at least one of the pillars of RFC2050 ("conservation") is not exactly relevant anymore. I consider RFC2050 a very useful document to establish principles, but it can not be binding - and in doubt, the bottom-up community based process will win. 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 (89) 32356-444 USt-IdNr.: DE813185279 [1] http://www.leadertelecom.nl/ [2] http://www.GetWildcard.com/nl
LeaderTelecom B.V. wrote:
Dear Gert,
Agree with your opinion regards RFC 2050.
Main idea this RFC: This document describes the registry system for the distribution of globally unique Internet address space and registry operations.
Goals:
1. Conservation: Fair distribution of globally unique Internet address space
according to the
operational needs of the end-users and Internet Service Providers operating
networks using this
address space. Prevention of stockpiling in order to maximize the lifetime
of the Internet address
space.
This doesn't required anymore. While RIPE doesn't have free space for distributing.
I am sorry, but this is simply wrong. The NCC still *does* have addresses (Ipv4) to distribute. that's the reason for having all the "Last /8" stuff (an the bickering :-) ) There's also the provision for the IANA to re-distribute address blockas to the RIRs, that get returned.
It was very useful before and respect for people who wrote it while principes in this RFC were very useful long time.
IMHO, they are still as appropriate now as they were from the beginning.
But for now it looks as deprecated and not updated.
I do agree with regard to the "not updated". Anyone is free to start the process of updating or replacing an RFC, though.
Some words from RFC which looks like depriceated:
...Currently there are three regional IRs established; InterNIC serving North America, RIPE NCC serving Europe, and AP- NIC serving the Asian Pacific region...
...3.2 Network Engineering Plans..
2. a description of the network topology
3. a description of the network routing plans, including the routing protocols to be used as well as any limitations..
-- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team
URL: [1]http://www.LeaderTelecom.nl/ - IP- addresses URL: [2]http://www.GetWildcard.com/nl - WildCard SSL certificates
11.10.2012 17:46 - Gert Doering написал(а): Hi,
On Thu, Oct 11, 2012 at 03:27:48PM +0200, Wilfried Woeber wrote:
Gert Doering wrote:
[...]
There are traces of needs-based still present in the system
AFAIK RFC2050 still is in effect.
All more recent suggestions to get it modified or retired were not
successful.
I got to understand that messing around with it [c|w]ould have far-reaching unwanted consequences for the whole IP Address Distribution System.
Like we have Addresses to Distribute :-) - the IPv4 run-out has fairly fundamental consequences for the environment in which we operate, and at least one of the pillars of RFC2050 ("conservation") is not exactly relevant anymore.
I disagrre. If your statement would be true, then we wouldn't need the L/8 stuff to begin with. The community seems to (still) think otherwise.
I consider RFC2050 a very useful document to establish principles, but it can not be binding - and in doubt, the bottom-up community based process will win.
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 (89) 32356-444 USt-IdNr.: DE813185279
Wilfried
Alexey, On Oct 15, 2012, at 5:59 AM, LeaderTelecom B.V. <info@leadertelecom.nl> wrote:
But for now it looks as deprecated and not updated.
RFC 2050 was intended to document the then-current (1996) number registry policies. As mentioned in the IESG-inserted prologue, the IESG was going to reevaluate the "best current practice" status via the Internet Registry Evolution (IRE) working group (which never got beyond the BOF stage). By the time 2050 was published, it was already overtaken by events and I believe there was a consensus (at least within the RIR and maybe network operation communities) that further policy definition should be done within the RIR structures, not the IETF. As such, I've always found folks treating 2050 as holy text somewhat amusing. I have suggested in a couple of places that 2050 should be moved to Historic, but there doesn't seem much appetite in the IETF to take that on. Regards, -drc
RFC 2050 was intended to document the then-current (1996) number registry policies. As mentioned in the IESG-inserted prologue, the IESG was going to reevaluate the "best current practice" status via the Internet Registry Evolution (IRE) working group (which never got beyond the BOF stage). By the time 2050 was published, it was already overtaken by events and I believe there was a consensus (at least within the RIR and maybe network operation communities) that further policy definition should be done within the RIR structures, not the IETF.
As such, I've always found folks treating 2050 as holy text somewhat amusing. I have suggested in a couple of places that 2050 should be moved to Historic, but there doesn't seem much appetite in the IETF to take that on.
amusingly, it is held up as sacred text when it suits, and described as ancient history when it does not suit. but the admin infrastructure seems to have majored in hypocrisy, so no shock there. we were both there in danvers, as were others. it was a meeting of the ops and the then-existent rirs to reach some agreements, especially on allocation size and satanic phyltres (the /19 compromise). in normal ops behavior, once the immediate deal was done, we all went back to work and forgot about it. the rirs used it to embed self-perpetuating monopolies. today's problem is that reaching a new agreement would mean slicing through massive rhetoric, bs, deeply embedded financial positions in rental of integers, vigilante culture, ... that it is essentially hopeless. otoh, i must compliment the ripe community for trying to address the issues of legacy, pi, ... space, and re-form the internet community. maybe there is hope. randy
Dear Tore,
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here.
Transfers are very useful for permanent transfer. Sub-allocations - for temporary use. This allows to control what happend's with IP-addresses while if they will be in black list (SpamHouse, etc..) - then impossible to use them in future. -- Kind regards, Alexey Ivanov 09.10.2012 14:16 - Tore Anderson написал(а): * Gert Doering
James' proposal has its merits, but OTOH, just loosening up sub-allocations might be the approach more appropriate for "the time we're living through".
[...]
While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now...
The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here. It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays? If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy. -- Tore Anderson Redpill Linpro AS - [1]http://www.redpill-linpro.com/ [1] http://www.redpill-linpro.com/
Dear Gert,
When this policy was initially written, there was a) no experience with sub-allocations, so I was careful, and b) worries that this might lead to LIRs sub-allocating all their space out the window, and then ending up in lengthy discussions with the NCC hostmasters - so a barrier was built in that was reasonable for the time and the envisioned usage ("customers that run ISP-ish businesses and need larger chunks of addresses to handle their customer allocations themselves").
While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now...
I think for now all LIRs know that IPs in RIPE finished and they understand what they do if they will sub-allocate all IPs. And may be it make sense. For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. -- Kind regards, Alexey Ivanov
participants (12)
-
Daniel Stolpe -
David Conrad -
Gert Doering -
Hamed Shafaghi -
James Blessing -
Jan Zorz ＠ go6.si -
LeaderTelecom B.V. -
Michiel Klaver -
Randy Bush -
Sander Steffann -
Tore Anderson -
Wilfried Woeber