Re: [address-policy-wg] Reducing IXP IPv4 assignment default size to a /26
On Tue, Sep 5, 2023, at 15:43, Viacheslav Adamanov wrote:
> The problem with ipv4 network speculation for IXP is exaggerated. RIPE
> NCC forbids transferring this networks to another company.
>
> Have there been cases of transmission of such networks?
Late to the show, but yes, there are such cases ("transmission" of an IXP,
blocks included).
--
Radu-Adrian FEURDEAN
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
On Wed, Jan 11, 2023, at 15:18, Marco Schmidt wrote: > Other IP ranges that might be used for IXP services, such as parts of an > IPv4 allocation (ASSIGNED PA), do not fall under this condition. So when the time comes (and provided the other conditions are met) it would be possible to request a /23 in grow an IXP currently using a /24 "ASSIGNED PA", with nothing to return to the NCC (the rest of the allocation being in use). Is that correct ? -- Radu-Adrian FEURDEAN -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
Hello, Would somebody from NCC be able to clarify how would the wording "must return the existing assignment (or existing PI used as an IXP peering LAN)" (proposed text 6.1.4 and 6.1.5) be interpreted/implemented for the case of IXPs that use ASSIGNED PA space for the peering LAN. OK, it's the same wording that already exists in the current policy, but a clarification is welcome. Otherwise the proposal seems reasonable. On Mon, Jan 9, 2023, at 11:40, Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > default size to a /26" > is now available for discussion. > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > address pool and to motivate IXPs to implement the exchange of IPv4 > routing information over IPv6. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-01 > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg@ripe.net before 7 February 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/address-policy-wg -- Radu-Adrian FEURDEAN -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] IXP pool lower boundary of assignments
Hi, On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote: > Actually, I do have some real-life experience here as I/AS39029 was > part of the NIX renumbering process back in 2017. The whole operation > was rather straight-forward and went very smoothly. NIX staff simply > informed all members of their new IPs by e-mail and told to migrate > within a certain date (different dates for NIX1 and NIX2). Well, this seems to be the customer-side experience, not the IXP-side. Also, what I can see is that responsiveness of NOCs and peering teams of members is only getting worse with time. At France-IX, just changing a netmask (from /23 to /22) - because we have the biggest 3 out of 5 IXPs numbered from PA space - took just under 2 years to complete (23 months to be precise). More than 80% did the change in less than 3 months, but after 12 months we still had a few members that didn't change their config. OK, things end up in a slightly more violent manner with renumbering, but you sill end up with "zombie members", not all of them being small players. /29 is way too small. It's 6 members, and that supposes that you don't have route-servers or any other internal stuff on the peering LAN. Getting from /29 to /25 that's 4 renumberings, and that may well happen within 2 years. You end up being labelled as "unstable" (read "junk" or "toy" IXP). 3 renumberings to get to /26. > NIX is (and was) a mid-sized IX, currently around 60 participants. > Based on that experience I have honestly a very hard time believing > that renumbering a small IX is «much more difficult [than renumbering > a] data centre or an access provider». Convincing different distinct parties to do something within a specific timeframe is always difficult. Especially when you have to deal with big companies. Pushing things too hard will only get you losing members. I do agree that /26 is a decent minimum, and /27 is the strictest acceptable minimum (if there really isn't anything bigger left). ... or getting rid of v4 entirely, which seems to be on nobody's agenda ... -- Radu-Adrian FEURDEAN -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)
On Wed, Jan 8, 2020, at 13:34, Gert Doering wrote: > So, please have a look and express your opinion - continued support, or > disagreement. Support. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote: > As you're speaking in favour of the proposal, can you describe what > problem you want to see fixed here? Problem : adapt the default assignment to the needs of most, in order to prolong pool's life, while allowing those that need to grow to do so while minimising re-numbering at maximum. To put it other way, I'm in favour of the idea, but not in favour of the current wording. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
On Wed, Nov 13, 2019, at 15:04, Scott Leibrand wrote: > Isn’t that as simple as “use sparse allocation”? As long as less than > half of the remaining IXP pool has been used up, everyone can be given > an allocation within a larger block with the ability to grow at least > 2x. If "sparse allocation" is the magic word, it's OK for me. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
Hello, On Tue, Oct 15, 2019, at 14:43, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" > is now available for discussion. A little late, but here's my point of view: - /27 is borderline for a default. Hopefully the 50% use within 2 years should alleviate this (even if I find it not enough). - Anything smaller than a /27 is close to useless. - Renumbering is painful and should be avoided as much as possible. - IXP growth may be very variable in time. You may struggle for 1-2 years, then add several dozens members the next year. You may easy get in a situation when renumbering falls in a period of rapid growth, which only makes things worse. The peering landscape has changed quite a lot during the last years. You have to deal with NOCs that function purely "by the book", usually a book not well written. You have to deal with lack of coordination between operations and strategy. You have to deal more and more with "the peering coordinator changed, there is no more peering policy". You have to deal with "there might be a slight impact, we need a change request approved, it will take 3 months at least". This noes not touch only the small participants, this does touch *EVERYONE*. At the end, you end up with x% (where x>10, even x>20) of your user base does not respond in a timely manner (if at all). Because of this you will end up looking as "not serious" (sometimes by the same people that took 3 months to do the renumbering). My suggestion : - if the default assignment size is to be lowered, that should be a /25 or a /26, not smaller. - The "target use" (currently "50% within 2 years"), should be a little more relaxed (either 3 years, or something like 35%-40% use within 2 years). I wouldn't mind reserving space for future enlargement (with reservations being re-allocated or reduced when space is needed by other members), but I think wording for that would render the policy way too complex. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 62.222.0.0/15
On Wed, Oct 9, 2019, at 09:01, Ronald F. Guilmette wrote: > I thought that we were discussing something that had been -aggregated-, > not split. Mea culpa, Still, the logic remains the same. The "created" field indicated when the record has been created (split, aggragation or transfer being reasons to create a new record), not when the space has been allocated. Allocation date does not have a field in its own, but that date is contained in the main block's "netname". -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 62.222.0.0/15
On Wed, Oct 9, 2019, at 07:37, Ronald F. Guilmette wrote: > I guess that I will have to speak to my friends in the DB working group > about that, because there is *no* indication of this whatsoever in > either the current -or- the historical records for the 62.222.0.0/15 > block, specifically. Probably a less specific When a less specific is splitted for transfer, the transferred chunk (didn't check for the remaining ones, but I suppose it's the same), has the "created date" of the transfer, but the date in the netname retains the date of the initial allocation. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call
Strong support here too ! -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
On Sat, Aug 10, 2019, at 10:59, Nick Hilliard wrote: > I agree with Wolfgang - the current version is fine, and Gert - that it > is important to move on this because otherwise we'll lose the > opportunity forever, and that would be a shame because IXPs perform an > important function for the Internet as a whole. +1 We should go on with the current version. *IF* you consider that lowering the default to /25 is really necesarry, you can still submit a new proposal for thay, AFTER the current one is ik and the extra space secured. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
On Thu, Jul 18, 2019, at 08:25, Piotr Strzyzewski via address-policy-wg wrote: > > I fail to see much support for your well-formulated problem statement. > > So count me as one of the supporters. I see at least two extra Count me too. However, please note that we are AGAIN discussing about IPv4, since this issue does not exist with IPv6 addresses. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
On Wed, Jul 17, 2019, at 18:28, Sascha Luck [ml] wrote: > Correct, and the rationale for that is that it's better for the > Internet to have these resources documented somewhere. This is about documentation change, not about keeping the documentation in place. > Leaving the inherent silliness of "owning" or "administering" > integers aside: Leaving that aside pretty much means supporting it (the silliness). The legacy vs RIR-administered debate is pretty much about the silliness vs normality of "owning integers". > I own my car because "somebody, someday" told me (after money > changing hands, of course) "this is yours". The same applies to > the computer I'm writing this on. No. First, the car and the computer are not under the same regime. For the car, you own it when the registry has been updated with convincing documentation from the former owner. That usually implies some other things are up-to-date (technical control ok - to take some random thing). For the computer, it's pretty much the case, with a few exceptions like "enough" people disagreeing for certain reasons making it "no longer yours". > If you'd like to change this you're welcome to try and take them off me and > see how far you get ;) You do realize that some people do it, and for a computer it works much better than for a car. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
On Mon, Jul 15, 2019, at 14:02, Tore Anderson wrote: > In any case, and to be perfectly honest, this rationale reads to like > petty jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I > don't want others to be able to do X either». Hi, I see the situation a little differently: - if my understanding is correct, you can benefit from pretty much same (or most of) services with you legacy space as with your PI/PA space, however you don't really have the same obligations. Correct me if/where I'm wrong. - do you consider something normal that somebody "owns" numbers, just because somebody, someday told them "those are yours" ? I don't. For the moment I have to live with the fact that in many cases (not all) this is what is happening, but I would pretty much appreciate a change. However, pushing for a conversion from legacy to "RIR system" looks very delicate. Not sure that legally it can be forced (probably in some countries the regulator may be able to do something, but I wouldn't count on that). As for "do it for you own good", while this may not work today, some day everybody would better get into the RPKI bandwagon, at which point the RIRs would be in a strong position to "kindly" ask holders to convert the legacy resources to "RIR system". If the will id there, which is an entirely different issue. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
On Wed, May 29, 2019, at 17:48, Gert Doering wrote: > Does this matter? For the IXP - definitely no. For the rest of the pool - maybe. This is why I was asking. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
On Wed, May 29, 2019, at 15:11, Denis Fondras wrote: > Just because of "It no longer provides for IXPs that need more than a > /23 of IPv4 > space" I am against this proposal. Hi, The alternative is that in just a few years it will no longer provide IXPs with any space. Right now, according to peeringdb, in RIPE region there are 5 IXPs holding a /21 and 5 (or 4, depending on how you consider the 2 LINX LANs) that hold a /22, and 14 (12, depending on how you count multi-LAN IXPs) that hold a /23. Let's hear their point of view, since building an IXP so big takes a lot of time (took almost 9 years for FranceIX to get there). Those being said, I'm in favour of the proposal. Just one reserve on wording of the assignment of "dust" (less than /24): if a request (for smaller than /24) is being made before the reserved pool exhaustion, will it be taken from he reserved pool or from the "dust" ? -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] PA ??? life after death
On Tue, Mar 12, 2019, at 18:48, Maxim A Piskunov wrote: > Please explain anybody, "PI in IPv4 is not coming back" -- is any rules > what prohibit community to turn situation to allow PA to PI conversion > for use by end-user purposes? Yes: The rule that says that needs to be a proposal for the policy to change (in order to allow that), and the proposal is accepted by the community following the PDP (which is the point where things start getting VERY complicated - such a proposal will most likely be rejected). -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")
Support here too. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] PA – life after death
On Wed, Mar 6, 2019, at 18:23, Max Tulyev wrote: > I remember that old good times when RIPE NCC was turned face to the > community. > > That times in case of LIR closure assignments was converted to PI blocks > and given directly to it's holders to avoid renumbering... And how do you do that when assignments are smaller (prefix longer) than /24. What does a customer do with a /27 PI ? -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Fri, Feb 8, 2019, at 17:24, Nikolas Pediaditis wrote: > Dear Carlos, Radu-Adrian, all, > > Following your questions, I have some numbers and other information > that might be useful. Hello and thanks for the rapid response. > 1. Currently, there will be 977,408 IPv4 addresses remaining in our > free pool once we are no longer able to allocate contiguous /22s. This Wow ! that's HUGE ! Under current conditions (equivalent on a /22 allocated at once, between 80 and 100 allocations per week) that would last about 10 weeks/2 months. With the new policy, that would be transformed to 40 weeks/9 months, not counting the almost certain decrease in the LIR creation rate. These numbers are turning me against the proposal the way it is right now. I will find welcome any changes that may help reduce the delay. Maybe the impact analysis will bring a little light. > 2. Over the past three years, we have recovered the following amounts > of IPv4 addresses: > > 2016: 83,712 > 2017: 106,368 > 2018: 53,824 OK, not really important for this matter. 1 week of allocation for a "good year" (like 2017). > 3. We have assigned the following amounts of IPv4 addresses as > temporary assignments over the past three years: > > 2016: 205,568 > 2017: 188,928 > 2018: 162,048 > > (Note that these figures represent the sum of all temporary assignments > made in that year.) So for the last 3 years, a /14 would have been (more than) enough. Probably mixing pools or exchanging blocks between the pools would help avoid reduce the delay of "IPv4 availability". Is a polycy needed for that or is it just NCC internal housekeeping? > Temporary assignments are made from a /13 that has been reserved for > this purpose. When a temporary assignment is returned, it is added back > to this pool. > > Finally, I would like to clarify that IPv4 allocations and temporary > assignments come from two separate pools - neither influences the other. > > I hope this helps. It certainly did. -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Meanwhile, in ARIN-Land: https://www.mail-archive.com/nanog@nanog.org/msg98840.html Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy)
I strongly support this policy. Makes things clear and outcomes predictable (I even suspect implementation of the current policy to be occasionally/randomly "bent" towards something more in line with what this proposal aims) -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy)
On Mon, Mar 19, 2018, at 17:47, Gert Doering wrote: > Thus: feedback please. Hi, I do agree with the concept of the policy as presented in the summary. The text seems (at a first reading) to confirm the stated intent. However, among the supporting arguments, only the first is clearly valid. To make it short, I don't recall being asked to return IPv6 allocations when performing a merger (M process) of 2 LIRs each one having v6 allocations. Not even when merging "already merged" LIRs. If such behavior does really occur under current policy, the proposal will prevent it from happening again, which is a good thing. Ah, and please fix typos :) -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
On Thu, Sep 28, 2017, at 13:21, Carlos Friaças wrote: > > - forcing desegregation, as if the problem is not bad enough already, > > and possibility to make things even worse (by creating new pretext for > > "longer than /24 in GRT"). > > Any prefix can be split into /24s and still remain globally routable. > > Going beyond /24 is really not in this proposal. A new proposal would be > needed for that... The issue is not with what it's in the proposal, the issue is the consequences, direct or indirect. > > I would also add some other reasons: > > - community's duty/responsibility for future generations : apart what > > it has already been discussed (get v4 on the market, get it from > > upstream, or even "really need to get v4 ?"), we are representing here > > the RIP*E* community, with limited geographical scope. However, the > > policy is quite lax at the moment concerning the out-of-region use of > > resources, basically allowing an out-of-region entity to get resources > > with a sole promise to use *some* of them in-continent. > > If you disagree with the current "lax" status, why not build a new > proposal? We don't need to address everything with just one proposal... This a simplist (almost childish) answer to a more complex issue. Even if we start with only the "out-of-region" issue, we will quickly get into the needs-based check, which I have been explained several times by several people that it can no longer work in RIPE-land. There is also the issue of what should happen with those not respecting the policies. Right now we seem to be in a situation where we have laws but no police. Should we continue on that direction (more laws, still no police) or should we just remove the root cause for breaking the law (removing the law may also be an option - even if not really the best) ? > It's a valid viewpoint. I would also agree with "less lax", but that > would be a different proposal. I would support such a proposal, but I doubt that it will have the expected effect in the short-medium term. > I can also agree with that, but it's just a matter of sizing it. If v2.0, > v3.0, v4.0, ... is eventually approved/adopted, it may be that there > isn't a /12 to do this anymore... > So, we really didn't focus in the task of establishing > barriers/boundaries. But we might consider this for v2.0, if it helps. :-) So I'll wait a "better" v2.0 or v3.0, or v4.0 .. :) -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi All,
I oppose this proposal. My reasons, or at least most of them, have
explained by other people during the last week:
- maintaining a lack of incentive for IPv6 deployment ("still have some
IPv4")
- forcing desegregation, as if the problem is not bad enough already,
and possibility to make things even worse (by creating new pretext for
"longer than /24 in GRT").
I would also add some other reasons:
- community's duty/responsibility for future generations : apart what
it has already been discussed (get v4 on the market, get it from
upstream, or even "really need to get v4 ?"), we are representing here
the RIP*E* community, with limited geographical scope. However, the
policy is quite lax at the moment concerning the out-of-region use of
resources, basically allowing an out-of-region entity to get resources
with a sole promise to use *some* of them in-continent.
- this brings us to the next point : with RIPE region being for the
moment the second-richest RIR (v4-wise) and the lax rules regarding
out-of-region use, I would not like RIPE NCC to become the world's
"last resort" registry for v4 resources (or any other resources for
that matter).
And if I were to agree with the proposal (which is not the case right
now), I would say that some thresholds should be used. Like /10 or /11
available for /23 allocations and /12 available for /24. Under no
circumstance /24 now.
--
Radu-Adrian FEURDEAN
Re: [address-policy-wg] Cleaning up Unused AS Numbers
Hi, On Thu, Mar 23, 2017, at 17:35, Gert Doering wrote: > Well, if they keep being not publically visible, maybe they *should* > be asked regularily if they are *still* in use? > (I wouldn't ask "every couple of months", though, maybe "every few > years" - but that's for the community to decide, in the end) Several years would be OK, given that some set-ups use ASNs outside of the GRT on the long (even "very long") term (PPPoL2TP aggregation from incumbent, other ugly things that some people consider to be the norm). -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
On Sat, Oct 22, 2016, at 23:30, Sander Steffann wrote: > > (Actually, it would not be ok, as »/64 or shorter« still prohibts use of > > /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or > > »shorter than /64«, I think, or SLAAC is not an option anymore.) > > You are misunderstanding. We're not talking about what you configure on > your Wi-Fi, we're talking about what you delegate to third parties: the > users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user > it's within the proposed policy. ... and this is where technical implementation comes and messes things up If you are functioning in "subscriber management" mode, you equipment may impose you that each subscriber has its own subnet for interconnection (mine does) - obvious choice being a /64. But being in "subscriber management" mode may not be the case for somebody offering wifi on a non-commercial basis, but if it still is, you may always try to use "longer than /64" (??? /128 ???) subnet per device. I haven't tried to see if "longer than /64" works with my equipment, since for me it's a non problem (I do assignments from PAs). -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)
On Wed, Oct 19, 2016, at 10:33, Aleksey Bulgakov wrote: > Hi. > > It is obviously the 99℅ of members want to withdraw this proposal in any > versions, but the NCC strongly moves it forward. May be the NCC has own > reasons to do it, but why it doesn't notice evident things. Except that members (RIPE NCC members), unless they voice their concerns here, on this list, don't have a word to say on policy development. As for myself, I still strongly oppose for too many reasons (it would take half of a working day to write all them down again). As a very quick and incomplete reminder: - "two levels membership" / differentiated services - "RIPE NCC as an investment fund" (or "former Gold distributor") - uncertainty for feasibility of business processes (what exactly is M today ? , what will it be tomorrow ?) - stubbornness on arguments/issues that still do not yet apply everywhere or that still have enough space for a middlegroud - - https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-August/011700.html - https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-June/011565.html - https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-June/011548.html No, I don't think any of my concerns has been addressed. And last but not least, differentiated treatment of the proposals (ideas in general), depending on who is the proposer and how does it fit within the ideas of the "establishment".
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Tue, Jun 21, 2016, at 11:06, Sander Steffann wrote: > > PI can be converted in PA easily in RIPE > > ??? https://www.ripe.net/manage-ips-and-asns/resource-management/converting-pi-to-pa ASSIGNED PI -> ALLOCATED PA on request. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Fri, Jun 17, 2016, at 23:11, Sander Steffann wrote: > I'm sorry, but this policy proposal limits selling the last /22 LIRs get > from RIPE NCC. How is preventing to sell off your addresses in any way > considered "healing yourself"? It doesn't only limit "selling", it limits "transfer by policy". The M has become stricter (pending written confirmation) and pushes some legitimate cases in policy territory. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Fri, Jun 17, 2016, at 23:48, Sander Steffann wrote: > Two scenarios: > > One > - Someone opens up an LIR > - They get their /22 (free) > - They sell it off to another LIR for a profit > > Two > - That other LIR opens up a second LIR > - They get their /22 (free) > - They merge that new LIR with their old LIR using M Three: - That other LIR opens up a second LIR - They get their /22 (free) - They can no longer apply "M" because the definition of "M" changed, and they have to do a regular transfer. On a general basis, there may be reasons for which you have to proceed with a regular transfer, other than "get IPs from NCC in order to sell them". It is my understanding, and please someone from RIPE NCC confirm or infirm that in public, that M has "slightly" changed recently, and the following operations are no longer M: - merging several existing LIRs having the same owner. - re-organisation of address space between the LIRs of a group. - purchasing a company but keeping the purchased company's legal entity (you accountant will give you good reasons for this; if you live in counties like France, your HR will give a few more reasons). - putting together resources of several entities within a group without proceeding with heavy legal and administrative paperwork. > So what is this proposal blocking for new LIRs? Not buying space, not > opening up a second LIR and getting that /22 from RIPE NCC. It only > limits those LIRs from *selling* their /22 for profit. For allocations prior to the unlikely application of the policy, it only gives one shot for some business processes. For those made after that hypothetic date, zero. Unless someone from RIPE NCC (registration services or board preferred) can infirm my understanding of recent M changes. > currently violating the policy by requesting my /22 for the wrong reasons Policy-wise, there are no "wrong reasons". If we decide to create them however, there are two possibilities : - all allocations done *AFTER* the application of "wrong reasons policy" would be concerned. Not those done before. - in addition to the above, if we want to apply this to transferred space, *ALL* space transferred (regardless of the initial allocation date) should be concerned. > examples of issues, not some hand-waving like "this is disadvantaging new > LIRs" without any explanation of how that exactly would work. Then we See my comment above, under reserve of validation from NCC staff: - "old LIR" got a /20 on Aug 2012. They never needed to pay more than one membership fee - "new company #1" /22 on July 2015, another one on Dec 2015 (on a sister company) and anther one on June 2016 (another sister company, since "additional" LIRs is still not officially reinstated). Due to the new M rules, the ressources have to be transferred (regular transfer) in order for the LIRs to be consolidated. If 2016-03 goes "live" before July 2017, "new company #1" is stuck with 3 memberships forever for less space the "old LIR". - "new company #2" did similar things to "new company #1", just at different dates (2014/10 and 2015/09) and on the same legal entity. Not having had enough time to sort out the merger due to "have to run a business" they can no longer do the merge today and have to wait until 2016/10, provided that 2015-03 does not go live by then. If for the same reasons the merger is left over until after 2016-03 goes live, they will also have to stay with 2 memberships forever. - "new company #3" which just got their /22 will face the risk of having to pay one membership per /22 forever. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Fri, Jun 17, 2016, at 22:37, Sebastian Wiesinger wrote: > that. You must know that? Why does the date bother you? Because it is in the past. > That would revert us to back to pre-market policy. Who would want that and > why? Those that would like all allocations to be treated the same. > We can only heal everyone by moving to IPv6. There is no cure in IPv4 land. Just stop telling me how to heal. I like your new diet, I practice it myself, but for the moment it is far from allowing me to live. In order to survive I need extras that can only be found in limited quantities. And you want to explain me how you're doing me a favor by increasing the price, while people having stocks (and putting on me pressure that makes the new diet irrelevant) can happily live ever after ... ? With 2015-05 I tried to fix the issue, but number of people in the community were against, the reason being mainly "make v4 last as long as possible". For me that reason makes it clear that IPv4 address space is meant to be the new equivalent of gold. Today, IPv6 is only a distraction, in the next years a "possible but unlikely option" and *AN* alternative in the future. But it will not become *THE* solution before IPv4 availability goes to ZERO (0.00, not 0.1 or 0.01 or even 0.001). Trying to explain me that on 14 Sept 2022 a new start-up (especially a content-related one) will legitimately need a /22 worth of provider-agnostic IPv4 space *ALONE* (i.e. IPv6 still as optional as today), for me it seems exaggerate. Same thing on 14 Sept 2027 (regardless of the allocation size) is totally unacceptable. Even today I find it hard to hear "save v4 for future entrants" with no incentive (or even obligation) to deploy v6. As for the market, today, mid-2016, the market doesn't have any explicit need for IPv6. On the contrary, the market *DOES* require IPv4 explicitly : no v4 = no business (mostly because "static public IPv4 address required"). Best case, very optimistic scenario, "not enough business". At least in my area and most of my market. I would be interested to hear the situation in other areas/markets : do a customer that is only give IPv6 stay with you for more than 1 year by using the service and never calling the support ? I have examples with IPv4-only (they ignore v6, some voluntarily, some not) customers. I also have customers that explicitly request IPv6 to be disabled (most likely because they don't know how to dot it themselves). IPv6 is only acceptable as long as it comes together with IPv4. But that doesn't meant that it will be used. So yes, I oppose this policy as I oppose by principle anything that: - changes the rules selectively, especially based on age (my most important no-go for 2016-03) - does it retroactively - tries to unbalance even more an already unbalanced market -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Fri, Jun 17, 2016, at 21:09, Remco van Mook wrote: > Let me get this straight - you oppose a proposed change in policy because > the change itself is not part of current policy? No, more people than you expected oppose it because you make an explicit reference to allocation made after a certain date in the past: All allocations made by the RIPE NCC to LIRs after 14 September 2012 will be marked in the RIPE Database as “ALLOCATED FINAL”. Just remove "after 14 September 2012" and you ban all transfers. Not necessarily a bad idea. > Also, those "heavily disadvantaged members" as you describe them, only > have received address space thanks to a particularly selfless decision by > the community at the time to dedicate the last remaining address space to > that purpose, rather than just blowing through it by early 2013. Like in "we won't kill you with a bullet in the head, we will kill you by letting you slowly bleed to death". Thanks. Now you try to regulate how you are allowed (or not) to heal yourself. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Thu, Jun 16, 2016, at 16:14, Remco van Mook wrote:Dear all, > > I would encourage everyone to carefully read this second version (and not Done. > just respond "no, still hate it, kill it with fire") as it is quite > different from the first version. Yes, it is "quite" different (depending on the definition of "quite"). But still hate it, kill it with fire. Use napalm if necessary. > Basically the only restriction left is to disallow transfers on all "last > /8 space"* going forward, and there is some language added to the policy > that tries to raise awareness that if you just go and parcel out that > entire allocation to endusers, you might end up feeling a little bit > silly a couple of years from now. And makes clear the retroactive intent. In fact, only use fire to kill it if you don't have anything more effective (to kill it). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Thu, Jun 16, 2016, at 17:28, Nick Hilliard wrote: > rather than speculating, maybe someone from the RIPE NCC could provide > information on how much address space has been returned to the registry > over the last couple of years? Hi, https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph Says 8.21 million returned ot recovered. http://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml Says (32+16+8+2+1+1+0.25+1+0.25+0.5)*65536 = 4063232 recovered. That gives a total of 4146768 IPs, slightly less than a /10. Or slightly more then the amount recovered from IANA. Marco, can you confirm this ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
On Thu, Jun 16, 2016, at 20:30, Sander Steffann wrote: > they were a member. Stop being a member = stop holding resources. > Allocations are for running networks with, not making money... I find this inconsistent. Either we do it for *ALL* allocations (including the ones allocated prior to the 2012/09 ipocalipse), effectively banning or heavily restricting transfers, or we keep it the way it is today, i.e. for *NO* allocations. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] IPv6 deployment
On Mon, Jun 13, 2016, at 02:40, JORDI PALET MARTINEZ wrote: > I don’t think the regulator is forbidding using a 6in4 tunnel because LI > regulation, otherwise, they will not allow any kind of VPN, etc? I don't think they do. But chasing 100 000 users running VPNs is not the same thing as chasing 10 ISPs providing VPN-like services (by default) to users.
Re: [address-policy-wg] IPv6 deployment
On Mon, Jun 13, 2016, at 02:31, Sergey wrote: > What's the problem with using it and deploying IPv6 on your own network? My understanding is that his problem is "going to jail" if he does so.
Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space
On Sun, Jun 12, 2016, at 23:22, David Conrad wrote: > Radu-Adrian, > > On Jun 12, 2016, at 1:26 PM, Radu-Adrian FEURDEAN > <ripe-...@radu-adrian.feurdean.net> wrote: > > Unless you manage to bring in money by using IPv6 and *NOT* IPv4, it > > remains either a "submarine project" or an explicit NO-GO. > > In most businesses, there are two (non-exclusive) ways to get traction on > doing pretty much anything: > > 1) it generates more revenue. > 2) it reduces costs. David, For the moment neither of those applies to IPv6 deployments. Cost reductions only applies to a limited number of players (those for which a 25% reduction in v4 traffic does end up in cost reduction, which implies a certain size). > more revenue -- the vast majority of customers do not and should not care > about something as esoteric as the particular bit layouts at an At some point, some categories of customers will have to start caring about this if we want to move forward. Especially those that need "port redirections to access the 2-3 devices in their office". > one nice thing about markets is that they can provide explicit signals > that help businesses decide. While there were free pools, the RIR system > masked those signals, ironically making it harder for businesses to see For the moment it's old big players that mask those signals : "$incumbent does provide us a /28 (or a /27). If you can't do the same, we will not buy the service from you". As long as this is only one random customer/prospect, you may be able to deal with it (let it stay with the incumbent or provide it the block needed). When you have lots of them, you have a problem. It's THEM that have to start caring about IPv6. > CGN are now a direct and obvious cost network service providers will need > to account for and (likely) pass on to their customers. When you go from ZERO to something (CGN-wise) you don't do any cost reduction. > migrating their internal infrastructure to IPv6 and selling a native > IPv6/CGN'd IPv4 solution by default, having non-CGN'd IPv4 as an extra > cost option (at least for new customers and increasingly, As explained above, as of today no IPv4 = no business. I am willing to wait for the things to change, but in the meantime it's IPv6 that is under life support (that I have to provide alone). > old customers when their contracts renew). Today, this is more painful for them than switching to another provider that does provide them with the needed IPv4 space. Those providers DO exist. > Now that most ISP network gear supports IPv6, the first part of that would > make sense regardless of the regulatory environment. This pretty much looks like "lab in production". usually it's not very well seen. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space
On Sun, Jun 12, 2016, at 19:42, Gert Doering wrote: > Work with your regulator to *make* it possible - like the rest of the world > has. I don't think that we (most people on this list) have IPv6 because the local regulator allowed us to. On the contrary, I think *our* regulator doesn't care very much (if at all) about this - it just doesn't force us to use IPv4 (like some others do). There are more than 50 regulators in the RIPE area, and not all of them do a job the we could consider "good". -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
On Sat, Jun 11, 2016, at 22:50, Aled Morris wrote: > I am just surprised that we encourage organisations who don't participate > (or have any interest in participating) in the RIPE policy process, or any > of the mechanics of Internet governance, to join the RIPE NCC and > therefore get a vote on budget and board member decisions. Well, hopefully (depends for who), they don't (https://www.ripe.net/participate/meetings/gm/meetings/may-2016/voting-report). At least not yet. But you do have a valid point. Just hope they don't come with the idea that the NCC should stop following community's policies (and hand things over to national governments, or decice policies to be followed at the GM). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
On Sun, May 22, 2016, at 13:02, Jan Ingvoldstad wrote: > You seem to be confused about what constitutes non-profit and what > constitutes for-profit or "commercial". Making _a_ profit does not > automatically make you a for-profit/commercial enterprise. Investment fund would probably be more appropriate. So is it possible to have a non-profit investment fund ? For me "non-profit" means not actively seeking profit; target being a zero end-of year result.
Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
Remco, As you may know, the "multiple LIRs" is for the moment least expensive way of getting around the "one /22" restriction. Combined withe the removal of "need checking", this very much looks like selling /22 to anybody willing to pay a sign-up and at least one year of membership. This may not have been intentional, but it looks to me as a first step to "turning commercial". With your proposal, while the idea was to discourage the "multiple LIR" practice, I have very serious doubts that it will happen this way. Given the current market price (which is only the most important show-stopper, but not the only one), with your proposal it would take about 5 years of membership to get at a similar level. With all that money going to the NCC. IF the NCC really whishes to keep its not-for-profit status, this will result in reduced membership, one reduced membership for older LIRs, but several memberships for the LIRs in "desperate need" (mostly small new ones). And of course, it would look more like a business of "leasing IPv4 blocks". ... and you DO have a NCC hat. I hope it does clarify my previous e-mail. On Wed, May 18, 2016, at 00:24, Remco van Mook wrote: > > Radu-Adrian, can you please clarify and substantiate this part of your > response? > > > This is basically a first (err, or is it a second) step to > > transforming RIPE NCC to a profitable "for profit" company. And if > > it will not be RIPE NCC getting the profits, it will be the "old > > LIRs" getting all the benefits (one single membership fee instead of > > several). I can see a hat there -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
On Tue, May 17, 2016, at 14:46, Remco van Mook wrote: > > So this includes LIR's who already have (through acquisition of other > > companies) multiple /22 from the last /8 > > It doesn't apply retroactively - so if you have already merged LIRs and > are currently holding multiple /22s form the final /8 you're fine. It > does stop future cases though. This is not exactly my reading of the new 5.1.5. If a LIR already holds several /22 and stays the way it is, OK, it stays the same. However, if a LIR, holding several "last /22" *today* acquires another LIR having a "last /22" and proceeds to a merger, in my reading it is supposed to loose the equivalent of "last /8 space" it already has. And I this cannot stop me thinking about the incitation of keeping as many LIRs as possible alive. You can always buy another company and keep the LIR, and this will be exactly what will happen if this policy gets implemented. This is basically a first (err, or is it a second) step to transforming RIPE NCC to a profitable "for profit" company. And if it will not be RIPE NCC getting the profits, it will be the "old LIRs" getting all the benefits (one single membership fee instead of several). I can see a hat there Otherwise: - still no incitation to deploy IPv6. Zero. Nada. a.k.a. "IPv4 is good, please go to the market; IPv6 really is irrelevant". - I don't get the point for the "reverse delegation restriction". BTW, how do you define "another party" ? - see the arguments for 2015-05 (I suppose this proposal is just the counter-reaction to that one), what you say is just dust in new entrants' eyes : "you have a /22 to start, but nothing more to live". It also misses the point of what is a "new entrant" today : i.e. not always someone prepared to do the "registry" job - "registry" like the "R" in LIR. Circumvention : keep up with multiple LIRs, for NCC's profit. But after all, I can also understand the very high possibility that this proposal is only a bad joke (even it we're May 15th, not April 1st). Just in case it's not clear, I'm completely against. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] Splitting 2015-05 in two
On Sat, May 14, 2016, at 10:16, Jan Ingvoldstad wrote: > This seems like putting the cart before the horse. > > Allocation conditions should be introduced _first_, as a "part A". Ok, got it, I messed the order. Sill, the question remains on what is the scope of "Part A" (condition for allocation) ? For old LIRs (that got an allocation before 14/09/2012), that shouldn't be a problem unless community decides otherwise The question is for new LIRs : how can you ask them to fulfill the conditions when they never had anything (nada, zero, LIR just opened) in the first place ? - ask them to start deployment using somebody else's space (ASSIGNED PA from transit, leased space) ? - lease them the block for X months/years (trial period) than take it back if at the end of trial period the condition is not met ? - keep the current status for them, which pretty much voids the purpose of the condition ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] Splitting 2015-05 in two
On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote: > If it were my proposal, here's how I would go about it. > > Withdraw the current proposal. > The proposer can always do this during the process. > > Introduce two new proposals (2016-somenumber and 2016-someothernumber) > respectively containing the "Part A" and "Part B" material from the > current proposal. Hello, As the proposal was written, the "part B" (allocation condition including v6 deployment) would have no sense on its own, since it only applies to the results of "part A" (further allocations). In order to have a "part B" that makes any sens, it would mean that current rules for allocation of the "first /22 from last /8" would have to change: - for a "real" first allocation (LIR that never received a v4 allocation before) either conditions would not apply, or a new system would have to be created where the allocation is time-limited, and at the end of time limit the allocated block is either returned (condition not met) or made "regular allocation" (condition met). - for LIRs that had previously allocated IPv4 space, condition applied directly.
Re: [address-policy-wg] agreement
On Wed, May 11, 2016, at 14:52, Peter Hessler wrote: > The 23.128/10 block is ONLY for /24-/28 allocations. These are not A /24 every 6 months (provided that conditions keep being fulfilled). Because less than /24 is pretty much useless. > intended as general purpose IP blocks, and are ONLY allowed to be used > for the IPv6 trasition (DNS servers, NAT64 gateways, etc). Some people tell me that "last /8" in RIPE-land is supposed to serve the same purpose, even if it's not written. Plus, you *CAN* get more than 4 x /24 in ARIN-land (to date 2 x /24, but the allocation rate is really low). > People violating the ARIN rules shouldn't be used as an excuse for us to > change > the rules in RIPE. > > https://www.arin.net/announcements/2014/20140130.html > > ARIN does not count them as part of the available ranges for > allocation, so we should not assume they are part of the normal pool. It's not the violation of ARIN rules, it's the fact that ARIN is *NOT* v4-exhausted. They still have available space, even if they call it otherwise. And it's used (or at least supposed) to reward people with real IPv6 deployment.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Wed, May 11, 2016, at 21:53, Remco van Mook wrote: > OK, have it your way. Let's look at some numbers: > > Available in 185/8 right now: ~ 6,950 /22s (1) > Available outside 185/8 right now: ~ 8,180 /22s (1) I'm OK with that. > New LIRs since January 2013: ~4,600 (2,3) > Budgeted membership growth for the rest of 2016: ~ 1,500 (2) > > Before 2016 is out, around 4,000 existing LIRs will have qualified under > the proposed policy to get another allocation. > Half the 'outside 185' pool will be gone by the end of this year. At the same time, 4472 LIRs do not have any IPv4 space. Is it possible to know how many of them never requested it, 3.5 years after (or more likely 2 years after all the restrictions have been lifted) ? Do you really think all eligible LIRs will make the request within 6 months ? > Based on an extrapolated growth rate of new members, the '185' pool > should last until early 2019. I see an average 12 months allocation rate of over 270 allocations/month (and rising). That leaves us (185/8 and recovered) 4 years 8 months (if allocation rate remains steady - but it is increasing). For 185/8 only, that is (less than) 25.75 months, which is more like mid-2018. Continuing outside of 185/8, at the same rate, we get around dec-2020/maybe jan-2021. But that's missing the following: - allocations/month are on the rise, new members are on the rise - not much effect from 2015-01 - no visible effect from suspending "multiple LIRs per member" (lower maximum, but steady high level). - things can change either way, rendering any estimation . very estimative > At that point, another 4,000 existing LIRs will have qualified under the > proposed policy for another /22 from the 'outside' pool. This pool is now > empty as well. Not over-night. > So, under the new policy, it will be game over for all involved somewhere > in early 2019. > The space you argue would be available for new entrants outside the '185 > pool' was gone by the time it was needed. It will not be completely depleted, just reduced (and I can accept "reduced by 50%"). > or we keep the existing policy that shares the pain for > existing and future LIRs well into the next decade. This is the problem that is supposed to be fixed : the pain. And if at the same time we can also do something effective for boosting IPv6 deployment, the pain level may be even less when the v4 pool will be really empty. > At which point, IPv6 will have saved the world from global heating, or so > they tell me. So they told me too, I discovered that it's much more complicated. > (if any of the NCC staff wants to verify my numbers, feel free to do so) Please ! Since it's not easy to find the following information: - if a LIR received or not it's "last /22" (cannot distinguish from one that get it and sold it) - if a LIR has performed an "outbound" transfer or not Thanks.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Wed, May 11, 2016, at 09:47, Remco van Mook wrote: > Again, you can't have it both ways. Current policy is not limited to > 185/8, so your proposal does have an impact. Actually 185/8 is more than > half gone by now (9571 allocations that I can see as of this morning) - > effectively this means the proposal wants over half of what remains in > the pool to get released to existing LIRs who've already received their > last /22. This cuts the lifespan of the pool for new entrants by more > than half, no? No, because: - it will not be dedicated to "further allocations" - there are some extra conditions that makes a lot of people not to qualify - with the time passing, when 185/8 is over, the "first /22 from last /8" will start being allocated from the same space as "further allocations". -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] agreement
On Wed, May 11, 2016, at 08:53, Gert Doering wrote: > Would you have preferred the ARIN way? "Oops, we have reached > exhaustion, nothing left, good buy to new entrants"? My understanding is that ARIN is not yet "dry". There still is some space available within 23.128.0.0/10 under NRPM 4.10 (which is supposed to be pretty restrictive, but I saw networks that prove me otherwise). And they still allow "further allocations" from that block (provided the "restrictive" conditions are met for all blocks). And it's evey 6 months not every 18 months. So it seems that issuing IPv4 space is still possible even after you cry out loud everywhere that you have none left. Don't tell me we (small LIRs) have to do the same with only a /22 in stock :) -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] Comment on IPv4 depletion rate for proposal 2015-05
On Tue, May 10, 2016, at 17:17, Jérôme Nicolle wrote: > Hi Radu, > > Le 10/05/2016 16:40, Radu-Adrian FEURDEAN a écrit : > > For now, I have the impression that the administrative overhead is just > > a pretext to be able to say "nonono, we DO NOT sell IPv4 addresses". > > IP adresses cannot be sold, it's public domain. > > What's beeing sold is a service to ensure uniqueness and a well > maintained registry. One-time fees won't cover that. Jerome, The problem is the "multiple LIR accounts per member". Of course, it does arrange some members' business, but it still sounds like "purchase parts in an investment fund". OK, that situation is suspended since november, but follow-up on 27/05 (voting results). One of the ideas behind 2015-05 was to calm down the need for such practice. Some people do not agree, and some may start considering the "extra LIR" option as normal. Not to mention that some people simply do not agree with that and make a more than decent living out of it. > Whenever we decide to put a facial value onto adress blocks, we'd get in > a slipery slope leading to the demise of innovation and competitive > telecom market (re-read the taxi licence analogy). And it sure won't Unfortunately we're already on the slippery slope. How far, check here : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/ipv4/ipv4-transfer-statistics . -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] Comment on IPv4 depletion rate for proposal 2015-05
On Tue, May 10, 2016, at 14:16, Peter Hessler wrote: > This was called "Provider Independent" and for IPv4, it was killed off > some years ago. Yes, except that the need for "provider independent" IP blocks did not disappear. Only the "ASSIGNED PI" status for new blocks did. The "ALLOCATED PA" is a good enough substitute for those needing it. Then there's still the "multihome with ASSIGNED PA phenomenon" and the "don't need multihoming, just a /24" (actually anything from /23 to /26 may qualify). For the second one, if done by the LIR it may actually decrease the depletion rate (saving months lost with extra allocations). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] agreement
On Tue, May 10, 2016, at 08:15, Denis Fondras wrote: > Why wouldn't a LIR get some space on the secondary market to provide to > its customers ? Because: - for a small LIR it's still too expensive (usual quote is 11-13 USD/IP for /22 to /24) - there is some risk of "bad quality IPs" (blacklists, bad reputation, bad and slow-to-update geoloc data) - missing business procedures/confidence (issue of using escrow account does not help) > Some are taking advantages of this situation (open multiple LIR) to get IPv4 > space. I don't see how 2015-05 would stop that even if you allow new LIR to > get > more than a /22. All I can see it more faster depletion (honest LIR getting > more + dishonest LIR getting more) It will not stop dishonest ones. May checking the actual need may slow them down a little bit, but that is not sure either. However, the honest ones will not have to use the same practices that they already consider "cheating". > I hear your arguments but I don't think 2015-05 is the right answer for the > community. If you have any ideas, you're welcome to share. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] agreement
Hi, On Mon, May 9, 2016, at 14:50, Sander Steffann wrote: > Indeed. It all comes down to "the needs of those in the next few years > with no IPv4 addresses" vs "those today who have only one /22". I find the situation a little more complex than that: - First, the "in a few years with no IPv4" is not so far away. Even with current policy, it is for 2020, with a lot of chance 2021. With the proposal, worst case scenario is that we MAY loose up to 18 months (more likely something in the 6-12 months range ). Which is not completely sure (as Martin Huněk noted a few messages ago). - Second, right now the NCC is just handing out /22 to whoever can pay for them (with only a small extra administrative restriction during the last 6 months). For me this is plain "selling IP addresses" (concept that the NCC avoided like hell int the past), and it is also defeating the "keep space for later entrants" purpose. No need check (as in "do you really need that space" *), no requirement to deploy IPv6 of any kind, just a simple "pay to have it". > Well, to make a useful discussion possible I think it's important to look > at the timescales. A policy that changes expected depletion from e.g. 100 > years to 90 years might not be a problem, but other timescales will > definitely be a problem. Given the time we have left (very unlikely to have 60 moths left) anything starts being problematic. > I think the timescale I have heard that people would find acceptable is > *at least* 5 to 10 years. If you look at the minutes of RIPE 70 > (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see > a statement from RIPE NCC when discussing this policy proposal that "the > RIPE NCC’s IPv4 pool was expected to last for around five years.". It all depends on when we start counting. If we start counting from 09/2012, we will meet the 5 years lifetime even with the current proposal. If we start now (10/05/2016), we will most probably NOT reach 5 years. We will NOT get 10 years of "last /8". And we should probably stop thinking "X years starting from now on". Time passes. In the meantime, people do "whatever seems appropriate" to get more v4 space. And unfortunately more and more people find there is no other solution than cheating in some way or another. The policy was supposed to calm down this. > Someone would need to come up with a radical new idea to get out of the > current deadlock. Which is why I urge all new participants in this Does anybody feel that a more complex policy is acceptable ? Does making the policy more complex in order to get longer timespan for the free pool (which does not exclude extra allocations if conditions are met) is somthing that may get consensus ? (*) Some time ago, a lot of "new players" would have started by being single-homed and having one (or more) "ASSIGNED PA" block(s) from their upstream. Then they were taking an ASN, and then became LIRs. Those going LIR from day one were not exactly commonplace. Today, even for those that are ok with being single-homed with an "ASSIGNED PA" from their upstream, if the size of the requested block goes beyond a certain size (commonly /24, occasionally down to /26), they are recommended (or even pushed) to become a LIR and get their /22. There are others that just "can afford" to spend some money to become LIR and get some space, even if it's not really used, just in case things go wrong in the future. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] agreement
> (note: my stance is based on forming a LIR simply to get any amount of > announcable addresses.) Hi, With a few drawbacks - more de-aggregation, (much) more complex policy - that could be achieved (without speeding up depletion). However, a lot of people let me understand that complexity is a no-go. That could even have been achieved with 2012-04 (rejected back in 2013). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 22, 2016, at 18:00, Nick Hilliard wrote:
> Radu-Adrian FEURDEAN wrote:
> > I do understand that. I just do not agree with the "as long as possible,
> > no matter what" approach.
> > For me, the issue is that right now we are in a "please suffer, the
> > solution is not working yet" situation.
>
> and your solution is that you want future market entrants to suffer more
> than you're suffering now because there will be no address space
> whatsoever left for them?
They will eventually do it anyway. And I really don't belive that with
the new proposal it will be in 18 months whereas with the current one it
will be in more than 5 years.
Those being said, historically, many new (small) entrants were not
becoming LIRs from day 1. They were usually starting with some space
from an existing LIR, some of them going multihomed with that space, and
only then becoming LIR and having "their own space".
The transfer market is discouraging this, and the limited space is also
pushing many of them to become LIR not because they really want to, but
because some upstream providers encourage them to do so in order to save
their own space ("wanna /24 - become LIR").
--
Radu-Adrian FEURDEAN
fr.ccs
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 22, 2016, at 17:37, Nick Hilliard wrote: > As a separate issue, the RIPE NCC is not in the business of telling its > members how to run their networks. Still a somehow separate issue, it shouldn't be in the "sell IPs" business neither, but it looks like it's exactly what it's doing with the multiple-LIR stuff. Follow-up 27/05.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 22, 2016, at 15:05, Nick Hilliard wrote: > Regarding the current allocation policies, you still have not addressed > the query that several people have raised about why it is better to shut > off opportunities for future internet service market entrants than it is > to make things marginally easier for a small segment of the existing > market for a short period of time, other than "but it hurts". Hi, I do understand that. I just do not agree with the "as long as possible, no matter what" approach. For me, the issue is that right now we are in a "please suffer, the solution is not working yet" situation. Pain management. The only solution right now is pain suppressors. Some have stocks, some just get enough to see it's possible but not enough to get to a point where they can get on by themselves. Only a few are not affected at all.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 22, 2016, at 10:46, Stepan Kucherenko wrote: > Last /8 policy came with some strings attached (IPv6 allocation) but > there is no way a new LIR will show some IPv6 progress before initial > IPv4 allocation was made. But with additional allocation it IS possible > to check if they even done anything in that time. Right now, there's no string attached. As long as the issue of "new player, get IPv6 ASAP" one of the 2 ways to achieve this is to stop handing out allocations directly, but "lease" them for X months/years, and recover it if no IPv6 has been deployed in the meanwhile. The complexity of such a thing is much higher, but if anybody would find the good wording for this, I would support. The second one would be "no more IPv4 at all". We're not there yet. > 5-stars RIPEness with even higher thresholds + on main site + IPv6 > as part of usual services to customers ? It will be hard to achieve > without actual rollout, and additional allocations to LIRs will be > either small in number or useful. I agree, with the reserve of clearly defining "main site".
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Thu, Apr 21, 2016, at 12:38, Stepan Kucherenko wrote: > > They have to deal with that anyway sooner or later. Also it might become > an additional pressure, "our rivals have this strange thing called IPv6 > on their site, can we do it too?". At which point I prefer being in the situation of telling them "doing this for years already. next." > There is also a problem with IPv6 roll-outs that it's usually (almost > always?) bigger guys, but smaller companies will lag behind for years if > not decades. Small incentive for small companies to keep up ? Small guys are either among the first or among the last to do it. You can find incetives from them (??? extra /22 ???) Big guys are almost never the first (but can start really early) and rarely among the last (even if they can wait a really long time). > >> Although ideas of only giving /24 to those who don't need more, and > >> probably just /24 after some arbitrary depletion state (/10?) would be > >> great as well. Anyone writing a policy for that yet ? > > > > That was part of the initial idea (see > > https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) > > Then I think it needs to be considered again, with or without additional > allocation. At some point yes, that's something that should be done somehow.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
Hi, On Tue, Apr 19, 2016, at 16:55, Stepan Kucherenko wrote: > Why not just check for record for their main site and mention of > IPv6 somewhere, like "/X for every customer on every tariff" or > something similar depending on the market ? > > It may put enough pressure for them to actually roll it out. Let's not put our marketing departments in the loop. Some of them get scared (for nothing). > I don't support this proposal in it's current state though. It won't > help IPv6 rollout as it is, it can actually make it worse because some > LIRs will be able to postpone it even more. But if combined with > additional incentives...it might just work. Some tiny bit of (free) IPv4 is the incentive. I can't find better. Just need to make sure the condition is well-written. > Although ideas of only giving /24 to those who don't need more, and > probably just /24 after some arbitrary depletion state (/10?) would be > great as well. Anyone writing a policy for that yet ? That was part of the initial idea (see https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf )
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote: >IIRC, the triggering of the "last /8" policy (as it has usually been > known) >did not coincide with receipt of 185/8 from (NB: not "by") IANA by > RIPE NCC, >but rather with the first allocation by RIPE NCC from 185/8. 185/8 received from IANA on feb. 2011 185/8 went "in use" (and the policy started) on sept 2012 >As Roger Jørgensen has explained, once the policy was triggered, it > was to apply to all subsequent allocations. However, in the meantime some events happened: - recovered space issue - space returned to IANA 2012-05 to 2014-04 and gradually returned starting 2014-05 - 2013-03 - no need checking - 2014-04 - no ipv6 requirement - still keeping a high (~= /8) level of "somehow available space" - policy abuse, pushing to limits and general change in "who is a LIR" (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and more of them, corporate LIRs or simply "just want my damn ASN and /24" LIRs) I hope everybody does realize how this proposal came to life.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Sun, Apr 17, 2016, at 10:42, Lu Heng wrote: > As I understand, more and more end user are becoming LIR as their ISP > refuse to give them IP, therefore it fundamentally changed the > very definition of LIR. > > The outbreak in the member mailing list last time reminds us how big that > group could be. > > What current ISP doing nowadays, instead of charging customer and apply to > RIPE for their customer's IP, they ask their customer come to RIPE to > become their own LIR and get their own IP then manage it for the customer. > In which, results what we see today, shipping companies, banks, even > airlines become LIR. Hi, This is exactly the point where the community failed. We keep saying that there is no more IPv4, and in the meanwhile more and more companies (non-ISP) discover that they can still get their needed IPv4 space, with the bonus of becoming provider independent. In the process of doing this, they "eat up" a /22 even if they only need a /23 or a /24 (or less, but that can't be routed). At the same time they still hear (for more than 10 years already) that IPv6 is coming, but still don't see it "coming close enough" (no, they don't really care about Google, FB, and Netflix - and if they do, it's more about how to block them).
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Sat, Apr 16, 2016, at 13:36, Jim Reid wrote: > > > On 16 Apr 2016, at 11:49, Radu-Adrian FEURDEAN > > <ripe-...@radu-adrian.feurdean.net> wrote: > > > > ... and there are other markets where "no dedicated IPv4 per customer" > > equals no business. > > And these other markets are either dead or dying because there is no more > IPv4. Some might survive if they can adapt to reality in time. > > Any current business model which depends on issuing a dedicated (public?) > IPv4 addresses to new customers is doomed. That model is simply not > sustainable any more. Either change the model or go bust. Pick one. For the moment it's "change model *AND* go bust". Or "refuse and try to survive" (but ultimately fail 95% of the time, with the current rules). Customers don't care very much about IPv6, CGN doesn't always work, transfer market is at a point difficult ot reach. Or you can just let "incumbets" develop a monopoly.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 15, 2016, at 16:09, Tim Chown wrote: > As others have said, everyone wants to grow. If you’re starting a new > venture v6 should be at the heart of what you’re doing. Tim, This is a good way not to start a business, and if you still do it, not to have many customers. No matter how much you have IPv6 at heart, as of 16/04/2016 on most markets "no IPv4" = "no business". For some customers, they won't use IPv6 even if you bring it at their doorstep. Been there, done that, still doing that.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 15, 2016, at 10:41, Gert Doering wrote: > If we didn't have this policy, but just ran out like ARIN did, small Gert, ARIN didn't run out dry (contrary to the popular behaviour). They barely entered some sort of "last /10" (23.128.0.0/10) , which is very restrictive. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 15, 2016, at 10:33, Tim Chown wrote: > > there are really no incentives to IPv6 adoption. > > Really? What incentive ? A black T-Shirt ? (for the record, I preferred the blue one handed out ~2010-2012).
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Fri, Apr 15, 2016, at 10:16, Peter Hessler wrote: > Growth into a market that should be killed, should not be encouraged by RIPE. What you are actually saying is the "Internet Access for Small Business" market should be killed. A "softer" interpretation would be that it should be left to "big enough players". ... and there are other markets where "no dedicated IPv4 per customer" equals no business.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
Hi, On Fri, Apr 15, 2016, at 07:48, Riccardo Gori wrote: > We are dealing with the same amount of space as September 2012 that in > the meanwhile has been abused in several ways and there are really no > incentives to IPv6 adoption. > > There was only one requirement to obtain one IPv4 /22: request and > obtain at least from /32 IPv6 to a maximum of /29 IPv6. > Am I wrong or this requirement has been removed?!?! Please explain that > to a new entrant... Not only that, but since 2014 IPv4 blocks are to be handed without any justification. Basically RIPE NCC sells IPv4 adresses. I would definitely NOT call that a success. > I think this policy is not for faster exhaustion but for "farier > exhaustion" and is offering a path to go over IPv4 while still needing > it to grow. What we are trying to compensante is the "fair" part which is diminishing with time. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
Hi Erik, On Thu, Apr 14, 2016, at 22:07, Erik Bais wrote: > If we currently have about 12.000 members .. and hand out additional > /22’s to each of them, it will cost 12 milj addresses ( more or less..) > ( as it would be more fair than discriminating on current size and age of > an LIR … ) We won't "hand them out". We live them the choice to ask. Please note that some of them didn't request their /22 as per current policy. > The pool won’t grow much more than it is currently … We are aware. > So handing out 12 milj. addresses in a single gift.. without the hard Again, we are not doing this in a "single gift". Or at least it is not what we wanted to say. > requirement to not allow final /8 policy received IP space to be > transferred, will most likely only increase the run-out of the IP space > and not fix anything.. This is something worth discussing. I think enough people were complaining about this in order to start discussing this more seriously. > If we hand out 12 milj. Addresses of the 16.4 milj. We have 4.4 milj. > addresses left.. meaning that we will have a full run-out within 18 > months. Then again, we are not talking about handing out in one shot ! Otherwise, I can understand your point of view. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Thu, Apr 14, 2016, at 19:24, Randy Bush wrote: > the purpose of the single last /8 allocation was to allow NEW ENTRY. The *single* "last /8" (185.0.0.0/8) is still reserved to what most people consider new entry. Further allocations would be from recovered space, which can also serve "new entry". Did you actually read the new text ? > pigs coming back to the trough every 18 months is not new anything. No, it's not. It'a actually commonplace in the other RIRs. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
Hi, On Thu, Apr 14, 2016, at 18:17, Dickinson, Ian wrote: > I’m arguing against it because it is the wrong thing to do, full stop. We > have a working policy, and we should stick with it. I'm not sure everyone has the same view of "working". > Anyway, I’ve registered my objection – I’m done with this unless the text > changes. Noted.
Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
On Thu, Apr 14, 2016, at 18:01, Jim Reid wrote: > > I strongly disagree with the proposal because it will encourage LIRs to > fritter away scarce IPv4 resources which need to be conserved so there > will be at least some IPv4 space available for new entrants 10? 20? 30? > years from now. Unless massive amount of space is returned or we change the rules again, the free pool will not survive 10 years. And if the purpose is to last as long as possible, other changes are required (strict needs assesment, more restrictions, penalties for not respecting the conditions) > LIRs who take advantage of this proposal would continue to fail to deal > with the v4 run-out. Because they can't. You can deploy as much IPv6 as you want, there still are things that require IPv4 without CGN. If you can't provide it, you don't sell. > New entrants presumably know what the current v4 allocation policy is and > should plan accordingly. No, most of them don't. They barely understand what RIPE and RIPE NCC are. Then at some point they find out (few of them know already) that years ago some people could get more space than they ever needed, while right now you can't get more than half of the previous minimum even if you need. I can understand that everybody should switch to transfers market at some point, but with only a /22 you will have lots of troubles reaching that point. Cases where you can go directly from a /22 to transfers are more the exception than the rule. > It's the only sane option. But there are others. Choose wisely. In certains situations (read market segements) there are no other options. At least not today. > This proposal, if adopted, would be also unfair on the LIRs who *already > have* taken action to deal with the v4 run-out. That can’t possibly be right. Actually no. On the contrary, they may have some fresh air. The only case where they may be impacted is going to the market and purchasing a "large enough block" (usually more than a /22). > BTW what’s to stop an unscrupulous LIR from repeatedly requesting extra > /22s (or whatever) through this proposal and then selling/transferring > the space without updating the database? If they tried to do this today, Time ? On the other hand, I would say that someone accepting the purchase of a block not declared in the database has a real problem to solve. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)
On Wed, Mar 2, 2016, at 17:30, Erik Bais wrote: > As we are almost at the end of the current phase (after today. ) [x] yes, this makes sense, go there If anything minor needs adjustment, it can be done afterwards. The way it is today, the policy is clearly better than the existing status quo.
Re: [address-policy-wg] Working group chair rotation 2
On Mon, Feb 8, 2016, at 21:24, Sander Steffann wrote: > So, let me start by volunteering again :) I would love to serve this > working group for another term as one of its chairs. A short introduction > for those who don't know me: +1 -- Radu-Adrian FEURDEAN fr.ccs / fr.coriolis
Re: [address-policy-wg] 2015-05
On Mon, Nov 2, 2015, at 16:04, Riccardo Gori wrote: > It does not contain any /something limit (as example /20) already > administered by the requesting LIR. > I would add some text as follows: > [...] > 3. The LIR has not reached an address space equivalent to /20 in its > registry > [...] IF that is to be done, I'd say that the acceptable limit (from several points of view) may be more /21 rather than /22, i.e. only real new entrants (after 09/2012). That could also be spelled this way. /20 was the initial idea too, but left aside for the first version. Any other optinion on this (other than "global no" or "no, no, no") ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05
On Mon, Nov 2, 2015, at 17:23, Radu-Adrian FEURDEAN wrote: > points of view) may be more /21 rather than /22, i.e. only real new That should have been "/21 rather than /20", concerning the limit of already-held space. Sorry for the error.
Re: [address-policy-wg] address-policy-wg / Revision of Last /8 Allocation Criteria
On Thu, Oct 29, 2015, at 14:44, Christopher Kunz wrote: > It cannot be reiterated enough: The final /22 is a migration tool for > IPv6. There is a large number of viable solutions to use IPv6 as your > main addressing scheme for a eyeball ISP, especially if you have started > from scratch only a few years ago. While this has beed understood and accepted by some small players, deploying IPv6 doesn't spare you of situations like: - residential users that will cancel and make you bad press because their PS4 doesn't work. Not with CGN, and for the moment not over v6(*) - business users that will just not sign with you if you cannot provide them their block of X public v4 addresses. Be happy if they don't explicitely ask you to disable IPv6. > I think that focusing on IPv6 adoption should be the first order of business. And once you have IPv6 as standard for everyone, but public dedicated v4 either unavailable of extremely expensive, you do what ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05
On Thu, Oct 29, 2015, at 15:20, Sylvain Vallerot wrote: > Unfortunately I suspect we lost the power to do so when we adopted the > catastrophic > "no need" policy, since big LIRs would easily declare fake assignments now to > fill > and reserve their already routed but yet unsed allocations. We would have to > restore > needs-based policy first. Things are a little bit more complex than that, but globally you are right, and we should have been more vocal years ago, when nonsense started to develop (no need, no new PI, PI trasnfer, ...). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 15:40, Jan Ingvoldstad wrote: > Here's a thought experiment: > > Set aside a /12 pool for this particular purpose. I would call this an "almost good" idea. "Almost", because /12 is too small. I would upgrade it to a "good idea" if it were a /11 or even a /10. Or at least "all recovered space since 2014-07-01", which is 1x /12 + 1x /13 + 1x /14 + whatever will follow (current estimate : 1 x /15). However, this will also de facto create an APNIC-style policy with 2 pools, which doesn't seem very popular around. But at the point where we are -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Wed, Oct 21, 2015, at 14:57, Daniel Stolpe wrote: > Yes. That was my idea as well, when we were discussing the last /8 policy: > that I would have liked to have a "last /8 policy" to be about the "last > /8", i.e. 185/8 and then the possible other free pool could have been > treated differently. Not sure that separating pools would have made things easier to accept. Some people gave me their opinions about this issue, and at that time (~6 weeks ago) there was only 1 (one) voice in favour of having separate pools. But again, if this makes it easier to pass, having distinct pools (newcomers & further allocations, 185/8 and recovered, ...) is an option for me as a proposer. Personally, I'm even in favour. > The major result of this proposal is likely to be an empty free pool and > the broker market as the only market. We will get there anyway. Worst things is that we (RIPE community) kickstarted this market too early. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05
On Wed, Oct 21, 2015, at 13:20, Tom Smyth wrote: > Perhaps people would support the Proposal, if the there was a stricter > condition on the transfers, ie > > that the Lir has not had any transfered IPs added to its registry, (in > addtition to the rule that the Lir has not transferred IPs out of its > registry) You have a point but: - not sure people will support it better with this condition added - there may be legitimate cases where you managed to have a inbound transfer and you still need adresses. Those being said, stricter criteria is under investigation. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05
On Wed, Oct 21, 2015, at 13:34, Randy Bush wrote: > > Transfer/ selling of ipv4 space should simply be forbidden. > > https://en.wikipedia.org/wiki/King_Canute_and_the_waves Encouraging and stimulating it OTOH, could have been skipped/avoided. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05
On Wed, Oct 21, 2015, at 13:33, Tom Smyth wrote: > My point was that if people have used mechanisims such as new lir +transfer > /merge then they would not qualify for an additional alocation ... which in > my opinion is fair enough...and would still conserve ip address space for > new lirs in future ... > Do you love it now ;) ? The issue of "multiple LIRs abuse" is much more complicated. If it isn't solved it's because it's too complex. If we take into account mergers and acquisitions (which is a policy in its own) things get even more complex. That part is more related to business processes than anything else. But I do agree that it's something that should be fixed at some point. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 15:16, h...@anytimechinese.com wrote: > Sounds not bad idea, if current pool last us more than 5 years...but on > the other hand, If it will shorten the lasting period below 5, I would > not support it. 5 years seems borderline even with existing policy. Then, in about 3 years APNIC and LACNIC would have probbaly run out dry (ARIN already did) and spill-over to RIPE area could be expected. Just look at the existing us.* LIRs having only 185 v4 address-space. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 15:25, Riccardo Gori wrote: > I would support it but I would add some text as follows > > 3. The LIR has not reached an address space equivalent to /20 in its > registry > [...] Hi, This is something that could be done provided there are enough people "for" and not many people "against". Any other opinions on this ? Including the size (proposed /20) ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 16:18, Aleksey Bulgakov wrote: > But there is conflict with 2015-01, was accepted to prevent depletion > of the free IPv4 pool, wasn't it? > 2015-01 was published and adopted in order to prevent abuse... as is the "no outbound transfers" criteria for further allocations. > This case we have to create 2015-10 to cancel 2015-01, or change the > text of this one. Where do you see an incompatibility between the two ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 23:02, Randy Bush wrote: > please put your money where your mouth is and run ipv6 only, including > smtp, ..., all external and internal connectivity. And If I do it, do I get some extra space ? No. In the meanwhile remaining v4 space goes where most people can't even imagine.... -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 21:29, remco van mook wrote: > The policy text was and is unambiguous, you knew you were only getting the > one allocation, there should be no surprises there. Stop smoking already. Which seemed right as long as there was a "needs requirement" and I belived (many people still do) that it was taken seriously. It also seemed right until you woke up 30 months later with more than one /8 in the free pool. For many people also seemed right as long as they were not aware that piles of unused v4 blocks will go "on the market", including those allocated via "last /8 policy". That looks like too much. > It's anti-competitive to the people who are looking to sign up in 2018 or It's also anti-competitive to keep out people who are looking to sign up in 2021. All that time you just kept in the dark corner other people that already signed up (after 09/2012, but not only). > Well, sure, why not. I think it's a very bad idea for a whole pile of other > reasons, but if you were to draft a policy that would allow additional > NEEDS BASED allocations to existing LIRs from address space that gets > RETURNED to the RIPE NCC that is outside the final /8 pool (so basically, > allocated pre-2012), that would sound very reasonable, fair and good for > competition. Returned ? After everything has been done to promote the address-space market ? -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 20:00, Randy Bush wrote: > what is it that people do not understand about "gone, no more, we're > out, ...?" Because it's NOT. Not yet. Not in RIPE-land, not in APNIC-land, not even in LACNIC-land. Not to mention AfriNIC-land. It IS over in ARIN-land (unless 23.128/10 ...). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
On Tue, Oct 20, 2015, at 15:06, Peter Hessler wrote: > On 2015 Oct 20 (Tue) at 14:46:54 +0200 (+0200), Marco Schmidt wrote: > :https://www.ripe.net/participate/policies/proposals/2015-05 > > From the proposed text: > 5.1.3.2. There is enough space in the free pool to perform the > allocation > > Is there a definition of "enough space in the free pool"? Is it a > single /22? A /22 or equivalent. Given de structure of the remaining space, the "or equivalent" shouldn't may times (if ever). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
On Mon, Sep 14, 2015, at 10:51, Peter Hessler wrote: > At my previous company, we joined RIPE as a LIR specifically because > there was no other way to get our own IPv4 address space. As a smaller > orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ > to provide serivces to our users. This is pretty much the situation at my present company. > I support the existing policy, and are very concerned with any proposal > that would encourage faster exhaustion of the IPv4 space. > > I respectfully disagree with the assertion that the existing last /8 > policy is painful for everyone.e It depends : if you need more than a /22 it is (very) painful, if you don't - it's not. And don't forget that some people are still arguing that the last /8 policy is to be used as a workaround until IPv6 becomes a useful option. Unfortunately, with the current stocks of available addresses, for a lot of people it doesn't work this way. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote: > 1) anything that increases the bureaucracy required to deal with > the NCC for a first allocation is a non-goer. > > 2) I could live with giving a LIR which has only received an > "austerity /22" another shot after a certain time, but I'd couple > it with some proof of ipv6 deployment (beyond just advertising a > /32) If you have some ideas of how to reliably determine "real ipv6 deployment" *AND* write down that criteria in a policy-friendly way, you're welcome (want to be part of the proposal ? - ok). -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote: > > b. treat all addressing space available for allocation as a single pool > B. KISS. > > > 2. Conditions for allocation the first /22. > Maintain the status quo. Point taken. > > 3. Further allocation(s) (after the first /22) > None of the above. My preference is to maintain the status quo - no > additional allocations. I do not quite see why we should change the > «last /8» policy which in my view has been quite successful (except for > the abuse that 2015-01 hopefully helps shut down). > > If it ain't broke, don't fix it? > > Unless we interpret «broke» to mean «exhausted». If so, c'est la vie. I take "broken" as "painful and far enough from exhaustion", so in need of a fix. Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99).
Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote: > * "Radu-Adrian FEURDEAN" <ripe-...@radu-adrian.feurdean.net> > > I take "broken" as "painful and far enough from exhaustion", so in need > > of a fix. > > Is there any urgency in getting closer to full exhaustion (i.e., no > remaining austerity pool)? Is full exhaustion somehow less painful than > the current status quo? > > I guess we can look at the ARIN region, as they'll reach that point in > the coming weeks. If that situation turns out to benefit their > community somehow (like increasing the IPv6 deployment rate), I'm > willing to be persuaded that we should open the floodgates and get rid > of our austerity pool ASAP. I'm sceptical this will be the case, though. I do think that it will push towards more serious IPv6 deployment (beyond "get the /29 or /32, announce it into the GRT, deployment successful"). > > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and > > RIPE still has more than 0.98 of a /8 available (more likely 0.99). > > And those three years we've delegated just shy of a /9: Which makes the "austerity pool" (I would rather call it "waste pool") available for about 5-6 more years. > implemented, has pretty much dried up. There are currently only 163,481 > addresses remaining in that pool earmarked to be delegated to the NCC. I am fully aware of that. > In summary I don't think that we can open the faucet any more than it > currently is if we want to be able to give IPv4 for new entrants in > 2020. If needed, we can revise things in another 3 years. -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
On Mon, Sep 14, 2015, at 09:36, Aleksey Bulgakov wrote: > Hi to all. > > 2015-01 has been approved to prevent IPv4 exhaustion (Elvis was an Hello, More to prevent abuse. Today we "celebrate" 3 years into exhaustion and the only thing that can be done is make sure things are less painful until we get rid of the "need for IPv4" by having a fully workable IPv6 Internet (for the moment we don't). > author). And you suggest to allocate additional blocks now. As told some > stuffs from the IPRA, here is the conflict, isn't it? I'm not a broker and not in the transfer business (not at all for now, and if I ever will, it's highly unlikely for me to be on anything other than the receiving side). So I don't see any conflict. Regards, -- Radu-Adrian FEURDEAN fr.ccs
Re: [address-policy-wg] 2014-03 Remove Multihoming Requirement for AS Numbers Assignments take #4
On Tue, Aug 11, 2015, at 12:24, Job Snijders wrote: It might be interesting if we could shift the discussion away from How to justify to RIPE NCC how you run your network to a slightly different angle: Helping the community prevent hoarding. Nothing more, nothing less. Because AS numbers are still limited ressources. We are just making (since at least 5 years) the switch from 16-bit to 32-bit (which we found some time ago that it does not represent infinite). So for 16-bit ASNs, I find that yes, people should justify to RIPE NCC how do they run the network in order to get an unique number. For 32-bit ASNs, there is no problem YET, but let's not make a habit (quickly transformed into rule) about how to get exclusivity on unique numbers.
Re: [address-policy-wg] 2014-03 Remove Multihoming Requirement for AS Numbers Assignments take #4
On Tue, Aug 11, 2015, at 12:44, Job Snijders wrote: ASNs have no associated cost. To my understanding they do, but the cost is set to zero until further notice or vote. Someone please confirm or correct please ?
Re: [address-policy-wg] 2014-03 Remove Multihoming Requirement for AS Numbers Assignments take #4
On Tue, Aug 11, 2015, at 12:13, Gert Doering wrote: I like this :-) - of course I'd like to hear what RS would have to say about it (we can do this vs. there are too many different cases to make sense out of this, etc.) - but the general idea is nicely lightweight and flexible... The idea is good, but I would really really want to see what does it give implementation-wise. Generally speaking a text like interconnection with several (= how many ???) external (how do you really define external) entities should cover the need for one AS. A second ASN (*autonomous* system) , well it should require a second autonomous system/entity respecting the same conditions. Now we should probably ask about NCC's capacity to evaluate what is external and autonomous. For LIR creation it doesn't seem to be very effective at this task. It didn't seem very effective in the past for IP address allocation neither (criteria slightly different, but not so much).
