- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by David Monosov 21 Apr '14

21 Apr '14

Dear address-policy-wg, With such a policy in place, IP address broker needs to offers potential IP space buyers only a marginally lower price than the cost of being a LIR for the expected duration of use of the IPv4 PI space in question (and requesting this IP space from the last /8 or realizing an inter-LIR PA transfer) in order to create a perverse incentive for IPv4 address buyers to line the pockets of IP address brokers instead of stepping up and becoming members of the RIPE NCC. This policy appears to fail the most basic economic incentive test, and will in practice create a secondary and desirable 'asset class' from which IP transfer brokers benefit considerably more than the community as a whole. To deconstruct the arguments which purportedly support this proposal: a) "Currently the policy for PA and PI space isn’t the same and people don’t understand the difference between the various types of IP Space." Ignoring that this is a superfluous argument which goes in the face of nearly two decades of policy, this appears to argue that letting PI space be sold would somehow eliminate this distinction. This, of course, is disingenuous. If this is indeed the goal, a policy should be introduced to allow PI space to be converted into PA space and assigned to a LIR - this will enable its "transferability" and eliminate many of the concerns raised above by ensuring that all holders of "transferred" IPv4 space are first rate LIRs who contribute financially toward the operation of the RIPE NCC and fall under all obligations imposed on such. b) "There is already some trade in PI space, however it is not documented or registered, which doesn’t help to keep the registry updated." This is also disingenuous, as every IPv4 PI space holder has a contract with the sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, regularly verify and update these details in cooperation with the registrant. c) "A lot of current PI space holders are more than happy to have their assignments re-assigned to other parties, but due to the current policy it is not possible. The same goes for the documentation provided to the RIPE NCC during mergers or acquisitions of infrastructure with PI space. Due to the current policy, some changes in company names are marked as mergers or acquisitions when they are actually a transfer of IP space with added documentation to make it look like an merger or acquisition of infrastructure." If a legitimate transfer has occurred as part of legitimate organizational restructuring, there is no disincentive to document it. The disincentive only exists if the registrant fears the transfer's legitimacy may be questioned, which is exactly the intention for non-transferable, end-user assigned PI space. Such transferred allocations could, and should, per current policy, be simply reclaimed. d) "We want to have an open and honest communication to the RIPE NCC from the community and we need to make sure that the registry is up to date, without having to fluff up the procedures, bend the rules and truth in communication to the RIPE NCC to be able to transfer the IP space." Alternatively, elements which "bend the rules and truth" could be identified, and, within reason, have their resources reclaimed. Certainly, such enforcement can never be perfect - but speed traps also do not catch 100% of speeding cars. With a few documented instances, this would create tremendous uncertainty and disincentive to engage in such practices from the buy side, as it will mean that any resources acquired in this manner may very suddenly get written off. e) "The goal of this policy change is to get PI space on-par with PA space in respect to the ability to transfer it." See (a). It seems very disingenuous to make PI and PA "equal for purposes of transferability" but maintain the distinction in all other aspects. To summarize, I strongly object to this policy in its current form. I concur that the mobility of IPv4 PI space toward those who value it most is desirable - on the condition that this mobility occurs as part of a wider reform to eliminate the distinction between PA and PI status of IPv4 resources. This should result in equitable burden for all resource holders toward the RIPE NCC instead of lining the pockets of IP address brokers by helping address space speculators which presently hoard IPv4 PI assignments against policy realize profits at the expense of the community. -- Respectfully yours, David Monosov

5 7

Policy Proposal Implemented: 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text"
by Marisol Estrada 17 Apr '14

17 Apr '14

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text". In accordance with the new policy, the RIPE NCC will no longer require LIRs to complete a forecast-based documentation of need when requesting /22 IPv4 allocations, when making assignments to End Users, or when requesting approval for IPv4 transfers. Accordingly, this also means that the "Assignment Window" is no longer applicable. As a result, we have updated the following request forms and supporting notes: - IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-608 - Supporting Notes For The IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-609 - IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-610 - Supporting Notes for the IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-611 Both the Provider Aggregatable (PA) Assignment Request Form and the Supporting Notes for Provider Aggregatable (PA) Assignment Request Form have also been removed due to this change. RIPE NCC members can still access the list of their past assignments approved by the RIPE NCC as well as their Assignment Window history, which is available in the "Archive" section of the LIR Portal. The IP Analyser functionality of the LIR Portal has been changed, as explained at: https://labs.ripe.net/Members/AlexBand/modifications-to-the-ip-analyser-to-… The archived policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2013-03 The updated RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: http://www.ripe.net/ripe/docs/ripe-606 Kind regards Marisol Estrada RIPE NCC Registration Services

1 0

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Richard Hartmann 15 Apr '14

15 Apr '14

I am afraid that I didn't have time to review the text in-depth yet, but I agree with the general direction this is going. Richard

1 0

APWG agenda for RIPE 68, first draft
by Gert Doering 14 Apr '14

14 Apr '14

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Warsaw in the following time slots: Wednesday, May 14, 09:00 - 10:30 Wednesday, May 14, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Marco Schmidt, NCC RS - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE67 2013-03 Post-Depletion Reality Adjustment and Cleanup (consensus, policy) 2013-05 No Restrictions on End User Assignments in Intra-RIR Transfers (consensus, policy) 2013-06 PA/PI Unification IPv6 Address Space (withdrawn) - brief overview over new proposals (if any) E. On Personal Identity - for internet resources registered to natural persons, what level of identity verification does the community require from the RIPE NCC? - with (hopefully) lots of input from the Anti-Abuse WG, on what they see necessary - results will be presented to NCC services WG, as this is important for the "due dilligence" considerations of the NCC D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) (+ discussion with the group) [might be moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back G. On SHOULDs and MUSTs - RFC 2119 language in RIPE documents followup to RIPE 67, findings by Marco Schmidt and Jan Zorz F. Discussion of open policy proposals 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space (which will hopefully be restarted until then) 2014-01 Abandoning the Minimum Allocation Size for IPv4 (Carsten Schiefner) 2014-02 Allow IPv4 PI transfer (Erik Bais) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB

1 0

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Rob Evans 09 Apr '14

09 Apr '14

> http://www.ripe.net/ripe/policies/proposals/2014-01 Overall I think this is a good thing, but I wonder if there is a reason for leaving 5.4 (minimum sub-allocation size) as-is? If we open the door to transfer prefixes smaller than a /24, should sub-allocation of them be prevented? The routing side of me, of course, might consider the alternative of clamping the transfers at /24 too, but perhaps that should just be left for consenting adults to negotiate between themselves. Cheers, Rob

11 26

report address policy violation
by Tom Norda 08 Apr '14

08 Apr '14

Hi: I know a RIPE member with an unused ipv4 /20 block not used in the last 2 years and i'm wondering if that's a RIPE community policy violation. I checked https://www.ripe.net/ripe/docs/current-ripe-documents/ripe-policiesbut i still have doubts if it is accepted or not. Best regards

2 1

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Tore Anderson 01 Apr '14

01 Apr '14

* Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-02 I think it makes sense to allow PI transfers, at least when taking into account that we already do so for PA. So I'm generally supportive of this proposal A few comments though: 1) The new policy says: «Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid». What exactly are the implications of this requirement? I am assuming that the «RIPE Registry» is not the RIPE DB; as the original criteria isn't documented in the RIPE DB to begin with. As I understand it, any criteria that somehow involves «operating a network» is a valid assignment criteria (cf. section 3.0.3), with no requirement for specifics. I'm thinking that it might be better to simply say something along the lines of an assignment being valid for as long as it is being used according to the policy, rather than worrying about the «original criteria» and how it possibly have changed. Most networks evolve and change over time; it wouldn't surprise me if a majority of assignments are now being used differently than originally documented in their associated assignment request form. That's not a bad thing though, is it? 2) Editorial: The new section 6.4 «Transfers of PI space» appears to me to be pretty much a carbon copy of section 5.5 «Transfers of Allocations» with a tiny bit changed here and there. Rather than duplicating all that text, would it not be better to move 5.5 out of section 5, and re-title and generalise it so that it applies equally to PI and PA? 3) The new section 6.4 speaks of «Non-approved transfers». Under which circumstances would a transfer not be approved, exactly? Do we really need this language anymore? (I'm regretting that 2013-03 didn't do away with it already. Oh well...) Tore

2 2

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Erik Bais 01 Apr '14

01 Apr '14

> You can find the full proposal at: > http://www.ripe.net/ripe/policies/proposals/2014-01 Support +1 Erik Bais

1 0

2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Marco Schmidt 31 Mar '14

31 Mar '14

Dear colleagues, A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 29 April 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Sascha Luck 29 Mar '14

29 Mar '14

All, On Mon, Mar 24, 2014 at 02:18:44PM +0100, Marco Schmidt wrote: >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-01 > >We encourage you to review this proposal and send your comments to I don't think this proposal takes into account operational reality. The fact of the matter is, that there is a lower limit to what allocation size is operationally useful to a LIR (unless the routing community is prepared to accept /32s in the DFZ). Add to that the extra complexity of reverse delegating </24 zones that is mentioned elsewhere in the thread and the likely outcome is a mess. I think the better way to do this would be to: - retain the /22 min-alloc size until the last /8 is gone - possibly change the *transfer* policies to allow transfers of /24< x </22 - implement something like 2014-01 but with a min-alloc size of /24 when that happens - review after a year(?) with a view to whether any smaller allocation size is actually *operationally useful* to LIRs I do not want to go back to the not-so-long-ago days of having to concoct fiction in order to get a useful amount of resources out of the NCC. rgds, Sascha Luck

3 6

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the MinimumAllocation Size for IPv4)
by sandrabrown＠ipv4marketgroup.com 28 Mar '14

28 Mar '14

Hello -- I am neither for nor against the policy. I do have some statistics from our business that may be relevant to the decision. Between May of 2012 when we saw the first small transaction, and today, we have received exactly 50 requests for transfers of LESS than a /22 within the RIPE region. One of these was for only 1 IP, but the most common request would be for a /24. My opinion is that this shows there is some demand for an allocation size smaller than a /22. The requests came from all over Europe, but the countries most represented would be Poland, the UK, the Netherlands, Italy, and the Ukraine, for whatever reason. Many countries are represented at least once. Best Regards, Sandra Brown IPv4 Market Group

1 0

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by poty＠iiat.ru 28 Mar '14

28 Mar '14

Hello, There would be always the difference between PI distribution and PA. As pointed by Janos - there is always contractual relationship between a PI user and a LIR or RIR, who covers some "side" mechanic. In case of PA it is more like selling - after an address block transfer the only responsible party is the new "owner". Regards, Vladislav >> Besides, one of the two stated reasons for having the minimum >> sub-allocation size (<[/24] is the smallest prefix length that can be >> reverse delegated>) is quite simply false, given RFC 2317 > > Well, technically speaking this is obviously feasible. However, as I > pointed it out on the DSN WG mailing list, in case of transfers, where > the "buyer" normally does not wish to have any further business > relationship with the "seller" once the transfer is completed, this > solution may be unattractive. The fact that the "seller" has to > provide appropriate DNS services (i.e. in accordance with > BCP20/RFC2317) to the "buyer" for an _indefinite_ period of time, is > probably one more deterrent to transferring such a small amount of > addresses. I think it would be reasonable to expect that if 2014-01 passes, the NCC will respond by allowing direct classless delegation of PA blocks, just like is already done for PI. If so, what you're describing here shouldn't be a problem. Tore

1 0

A question
by Nigel Titley 26 Mar '14

26 Mar '14

Anyone care to cast an opinion on the following question: The company I work for is about to split off one of its country operations into a separate company. There are various blocks in use from various allocations to the parent company. Is it permissible to split a PA block and transfer part of it to the new company in order to avoid having to renumber the customers? My reading of the transfer policy is that it is possible (if reprehensible), but I thought I'd just like to check with the great and the good to see what opinion is. Nigel

4 4

Re: [address-policy-wg] address-policy-wg Digest, Vol 31, Issue 15
by Lu Heng 26 Mar '14

26 Mar '14

Hi Nigel: My suggestion was keep block in one piece and lease the block to the local companies(if legal requires). because put it back in one piece later on might be a problem and if there is no real transaction involved, less specific block are always better than smaller block for routing reasons. my two cents. On Wed, Mar 26, 2014 at 2:52 AM, <address-policy-wg-request(a)ripe.net> wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. A question (Nigel Titley) > 2. Re: Input request for the PI Transfer policy (Elvis Velea) > 3. Re: A question (Elvis Daniel Velea) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Mar 2014 17:25:24 +0000 > From: Nigel Titley <nigel(a)titley.com> > Subject: [address-policy-wg] A question > To: address-policy-wg(a)ripe.net > Message-ID: <5331BC04.1020401(a)titley.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Anyone care to cast an opinion on the following question: > > The company I work for is about to split off one of its country > operations into a separate company. There are various blocks in use from > various allocations to the parent company. Is it permissible to split a > PA block and transfer part of it to the new company in order to avoid > having to renumber the customers? My reading of the transfer policy is > that it is possible (if reprehensible), but I thought I'd just like to > check with the great and the good to see what opinion is. > > Nigel > > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 Mar 2014 19:35:27 +0200 > From: Elvis Velea <elvis(a)velea.eu> > Subject: Re: [address-policy-wg] Input request for the PI Transfer > policy > To: Gert Doering <gert(a)space.net> > Cc: address-policy-wg(a)ripe.net > Message-ID: <5331BE5F.8020108(a)velea.eu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Gert, > > > On 25/03/14 15:26, Gert Doering wrote: > > [...] >> There might be other reasons as well.. It's just a feeling that limiting >> at /24 is the right thing to do. On the other hand, while writing this >> e-mail I've been having second thoughts on each of the paragraphs and >> reasons :-) >> It's good to have the arguments out, so we can think through them - thanks! > I tried to play the devil's advocate role this time. As said, even when > writing all my con's I realized these aren't too strong. > > As you already know, I'm in favor of not adding any limitations in > policy. I was just trying to voice all the possible con's. > >> >> Gert Doering >> -- no hats > cheers, > elvis > -- blue hat to protect against the sun :-) > > > > > ------------------------------ > > Message: 3 > Date: Tue, 25 Mar 2014 20:52:21 +0200 > From: Elvis Daniel Velea <elvis(a)v4escrow.net> > Subject: Re: [address-policy-wg] A question > To: address-policy-wg(a)ripe.net > Message-ID: <5331D065.5040402(a)v4escrow.net> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nigel, > > As far as I understand from the policy, you can transfer a block that > contains customer assignments. The size of the block that you would > transfer can not be (currently) smaller than a /22. > > So, I would say that you have two options: > - first - where you use the transfer policy and transfer parts of an > allocation to an other LIR (even if it's yours, in a different country). > In this case, the IPs transferred can not be again transferred for two > years to an other LIR. > - second - where you sell to a separate company (parts of) your > infrastructure (and maybe associated customers) and then you would use > the Mergers and Acquisitions procedure. In this case, the transfer > policy would not be used and the IPs transferred to the new company > could then be again transferred using the transfer policy. > > cheers, > elvis > > On 25/03/14 19:25, Nigel Titley wrote: >> Anyone care to cast an opinion on the following question: >> >> The company I work for is about to split off one of its country >> operations into a separate company. There are various blocks in use from >> various allocations to the parent company. Is it permissible to split a >> PA block and transfer part of it to the new company in order to avoid >> having to renumber the customers? My reading of the transfer policy is >> that it is possible (if reprehensible), but I thought I'd just like to >> check with the great and the good to see what opinion is. >> >> Nigel >> >> > > > -- > <http://v4escrow.net> > > > Elvis Daniel Velea > > > Chief Business Analyst > > Email: elvis(a)V4Escrow.net <mailto:elvis@v4escrow.net> > US Phone: +1 (702) 475 5914 > EU Phone: +3 (161) 458 1914 > > Recognised IPv4 Broker/Facilitator in: > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received this email in error, please notify the sender immediately and > delete the original.Any other use of this email is strictly prohibited. > >

1 0

Input request for the PI Transfer policy
by Erik Bais 25 Mar '14

25 Mar '14

Hi, As you might know, we are currently working on a policy proposal to allow the transfer of PI space. One of the topics that I would like some input (prior to sending out the proposal itself) it the following: In the current draft, Ive phrased one of the rules for the PI transfer as follows: - Assignments smaller than the minimal allocation size, cant be split into smaller assignments, but can be re-assigned as a complete assignment. My reasoning is that it would disallow cutting up small assignments into even smaller assignments. So in the current situation a /23 PI assignment is smaller than the minimal allocation size, however assigned in the past by the RIPE NCC. With the above stated rule in the proposal, it would not be allowed to split up a PI assignment into 2 PI assignments of a /24 .. or 4 PI assignments of a /25, but it would be allowed to do a complete re-assignments as a /23. With the current new proposal 2014-1 put forward today, the question that we discussed last week (myself, Marco and Andrea ) is that if we would put this forward, that this might need to be re-phrased. The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI. The goal of the PI transfer policy proposal is to have it similar as the current Transfer policy for PA space. Lets hear it. Regards Erik Bais

10 19

2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Marco Schmidt 24 Mar '14

24 Mar '14

Dear colleagues, A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-01 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 22 April 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Converting PI assignments to PA allocations for LIRs
by Andrea Cima 24 Mar '14

24 Mar '14

Dear colleagues, At RIPE 66, we informed the Address Policy Working Group that an increasing number of members were asking to change the status of their inetnum objects from “ASSIGNED PI” to “ALLOCATED PA”. After RIPE 66, the discussion continued on this mailing list. Here, a lot of support was expressed for allowing LIRs to change the status of their resources, provided they are correctly registered with the RIPE NCC to the same legal entity that is registered as an LIR. Based on this input, we have now published the procedure to allow assignments to be converted: https://www.ripe.net/lir-services/resource-management/converting-pi-to-pa Kind regards, Andrea Cima Registration Services Manager RIPE NCC

1 0

Changing the Status of PI Address Space
by Elvis Daniel Velea 20 Mar '14

20 Mar '14

Hi everyone, I'd like to restart the discussion that was taking place on the mailing list before the RIPE Meeting in Athens. The discussion happened on the mailing list and in Athens and moved to a discussion on whether we should permit PI transfers through policy -> I understand that Erik Bais is working on a policy proposal that would include PI transfers. However, the discussion on ASSIGNED PI to ALLOCATED PA status change for address space given and used by the LIR has been stopped and I would like to restart it. My opinion is that I don't think a policy is needed for these changes to be performed by the RIPE NCC at the request of the LIR. Changes from ALLOCATED PI to ALLOCATED PA have been done in the past; plus - Tore has also pointed out some precedent where ASSIGNED PIs have been changed to ALLOCATED PAs. By keeping the artificial limit of PI used by LIRs the registry is suffering as any assignments made within that PI block are not properly recorded in the registry/RIPE Database. By looking back at the feedback received from lots of people in the community (and I counted at least 20 people responding to Andrea's e-mail) I have the feeling that this should have been already implemented. Therefore, I'm curious: - should we restart the discussion? - was the minimum limit of the prefix size the only reason why it hasn't yet been implemented? (some were saying any prefix, some were saying min /22) - or was it already implemented and I missed the announcement? Kind regards, Elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis(a)V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

7 9

Post Ident / Post Brief
by Nick Hilliard 04 Mar '14

04 Mar '14

As there are legal prohibitions in place which prevent german nationals (and possibly other countries) from photocopying their passports, would it be possible for the RIPE NCC to give an opinion on whether Post Ident would be acceptable as an alternative to photocopying passports / driving licenses / etc for PI address applications? Post Ident is considered to be suitable identity certification from the point of view of the german money laundering act. Nick

24 43

IPv6 PA/PI - restarting discussion after failed 2013-06 proposal
by Elvis Daniel Velea 04 Mar '14

04 Mar '14

Hi everyone, 2013-06 has failed to become policy and we all understand that it presented such big changes that it became too complex. I would like to restart that discussion and see what are the problems/failures of the IPv6 policies (both PI and PA) and come up with a proposal to fix these problems. I'd like to start with the first 4 problems that I have noticed: #1. In IPv4 a PI user can connect a customer to it's network or allow a customer to use a dedicated server using one IP address. This limitation had been extended to up to a /29 (in case redundant connections were offered - ie:VRRP) but most of the cases I have encountered were using either a /32 or a /30. Currently, the IPv6 policy states that the minimum a customer should use is a /64. And because the minimum per customer is a /64, when someone would actually use IPv6 PI for a customer, it would make an assignment of a subnet and violate the policy. I've heard of people using /128s for the servers of their customers and sharing the same vlan amongst multiple customers in the same /64. Others are just requesting a/48 PI and expect never to come back for more (therefore, could not care less about policies). Others just know that the RIPE NCC has no way to see if they sub-assign parts of the /48 PI, so they just request a /48 PI, promise never to sub-assign and later on, forget about the promise. Therefore, I propose that the first change we make to the IPv6 PI policy is that where a /64 could be used per customer (regardless of the service offered to that customer) only if it is registered properly in the RIPE Database. The change would allow PI users to sub-assign in IPv6, but only small (?) amounts of space and only if they actually register the assignment. #2. Second problem I've noticed is the fact that LIRs can receive /32s (and up to /29s) only by asking. On the other hand, if you do not want to become a RIPE NCC member or just can not, you are forced to use IPv6 - a /48. Additionally, this IPv6 PI can only be used for your own infrastructure and not to provide any service (other than SaaS) to your customers without violating the policy (see problem statement #1). One could request more than a /48 but it would need to demonstrate that it has two or more sites that have different routing policies or demonstrate that it has a need for more than 65K subnets. I would like to introduce the IPv6 PI ALLOCATION. This time, the PI allocation could be made to the PI user and the user could actually make assignments from it. The PI allocation would be just as large as the PA Allocation and the price for it would be no less than 50% of the membership fee (Off course, the fees can only be voted upon at the GM and the example is just purely theoretical). This would introduce that 'additional registry' which we never knew how to name during the discussions of 2013-06 and would allow PI users to request/receive a /29 from which they could make assignments. Everyone will say that /32 or /29 will become the new /48. Well, that may be true, on the other hand, it may be the price that could keep the number of large PI Allocations low. Additionally, we could add an arbitrary limit. For example, say that you can request an IPv6 PI Allocation only if you already have x hundred customers that will receive an assignment from you immediately. #3. Minimum assignment size The policy says that the minimum assignment size is a /64. However, the RIPE Database does not enforce this rule and I have seen /128s registered. for example: inet6num: 2001:b70:f000::/112 inet6num: 2001:820:0:1:1::1000/116 inet6num: 2a01:2f0f:ffff:ffff:100:1000::1/128 There are over 700 inet6num objects registered which are below a /64. If we take the policy literally, all these assignments currently violate the policy. Therefore, I think we should either change/remove the minimum assignment size or have the RIPE Database block the creation of any IPv6 assignment smaller than a /64. #4. fix utilisation and hd-ratio vs assignment size While the HD-ratio is being calculated in terms of /56s, the policy says (at point 5.4.1.) that the minimum assignment that can be made is a /64. Furthermore, as you can see above, /128s can be registered in the RIPE Database as well. If we will continue allowing the registration of less than /56 assignments, it will be difficult to almost impossible to the IPRAs to actually calculate what is the HD-ratio of an IPv6 allocation. While now it is too early to see additional IPv6 allocation requests, if we keep doing things as we've been doing for the past years, we will end up in a few years with a huge mess in the registry and the impossibility to calculate the HD-ratio without applying random procedures. A very simple and quick fix would be to say that if any prefix is registered, the whole /56 that includes the prefix is in use. But then, we may see people registering/using /128s from different /56s just to reach the HD-ratio for an additional allocation. Would that still be considered an efficient usage? An other option would be to change the HD-ratio calculation to the actual number of IP addresses used and consider all the IP addresses from an assignment used if correctly registered in the RIPE Database. Once we have worked out whether these 4 issues are indeed flaws in the policy or not and whether we want them fixed or not, I would like to hear your opinion in what else should be modified in the IPv6 policies. I will then collect all the feedback, probably present it at the next RIPE Meeting, and start to discuss an other approach/policy proposal to achieve what 2013-06 failed to achieve. cheers, elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis(a)V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

1 0

New AS Number Blocks allocated to the RIPE NCC
by Andrea Cima 03 Mar '14

03 Mar '14

Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA in February 2014. 200192-201215 201216-202239 You may want to update your records accordingly. Best regards, Andrea Cima Registration Services Manager RIPE NCC

1 0

ABUSE IP 176.57.210.40 planetadeneg.com
by Илья Полушкин 24 Feb '14

24 Feb '14

Welcome to the IP 176.57.210.40 planetadeneg.com domain is the so-called HYIP project administrator who collects the money and cheating people. Please take steps to block IP 176.57.210.40 work or I will be forced to contact the police. С уважением, Полушкин Илья тел.: 7(916)5800672

2 1

Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
by Filiz Yilmaz 24 Feb '14

24 Feb '14

Dear Colleagues, NRO NC is asked by the IANA Staff for a clarification on the reading of this policy, Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA, in regards to "when" the first allocations from the Recovered IPv4 pool can be made. The Council decided to check further with the communities, hence this mail. The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the following: ---- 1.0 Recovered IPv4 Pool …. When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below. 2.0 Allocation of returned IPv4 address space by the IANA 1. Allocations from the IANA may begin once the pool is declared active. 2. In each "IPv4 allocation period", each RIR will receive a single “IPv4 allocation unit” from the IANA. 3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year ... ---- While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 and 3 together talk about "allocation periods" and that they are the “6-month period following 1 March or 1 September in each year.” In practice, if the pool is declared active on 1 January and IANA makes the first allocations immediately this would be outside of the allocation period, which begins at the start of March. So mainly the question is about the first allocations from the the Recovered IPv4 pool; a) Should they be made straight away or b) Should IANA wait and make them at the start of the next "IPv4 allocation period," the "6-month period following 1 March or 1 September. In my personal opinion I see no problems with starting straight away (option a above), and then continue the rest in the regularity of the allocation periods as stated in the policy. Would you agree or is your reading towards option b above? Please let us know of your opinions on this list until 23 February 2014. Kind regards Filiz Yilmaz as NRO NC Member from RIPE Region

7 8

RIPE Policy Proposal 2012-07 Accepted: Effect on ripe-604
by Marco Schmidt 07 Feb '14

07 Feb '14

Dear colleagues, As announced on the RIPE NCC Services Working Group Mailing List, the policy proposal 2012-07, “RIPE NCC Services to Legacy Internet Resource Holders” has reached consensus. This proposal contained a small amendment to ripe-604, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". 2012-07 replaces section 5.5 of ripe-604, currently: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." With "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System." This change was proposed to ensure that 2012-07 was in alignment with the policies described in ripe-604, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”. The new RIPE Document is ripe-606 and it is available at: https://www.ripe.net/ripe/docs/ripe-606 As an existing RIPE Document was impacted by this policy proposal, we felt it was worth notifying the Address Policy Working Group. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC

4 3

Re: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text)
by Robert.Guentensperger＠swisscom.com 06 Feb '14

06 Feb '14

Dear all, I'm unsure now. Is ripe-583 (Provider Aggregatable (PA) Assignment Request Form) still valid? Regarding the new policy-text and the discussion before it's now unclear. At least for me. ;-) Thank you in advance for a clarification. Best regards, Robert Robert Güntensperger Swisscom (Switzerland) Ltd. > -----Original Message----- > From: address-policy-wg-bounces(a)ripe.net [mailto:address-policy-wg- > bounces(a)ripe.net] On Behalf Of Marco Schmidt > Sent: Tuesday, February 04, 2014 4:36 PM > To: policy-announce(a)ripe.net > Cc: address-policy-wg(a)ripe.net > Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion > Adjustment of Procedures to Match Policy Objectives, and Clean-up of > Obsolete Policy Text) > > > Dear colleagues, > > > Consensus has been reached, and the proposal for a change to RIPE > Document ripe-599, "IPv4 Address Allocation and Assignment Policies for > the RIPE NCC Service Region", has been accepted by the RIPE community. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > The new RIPE Document is called ripe-604 and is available at: > > https://www.ripe.net/ripe/docs/ripe-604 > > > The RIPE NCC has already begun preparations to implement this policy > proposal, which will require updating many internal and external > procedures and related tools to ensure we continue to provide efficient > service. > We estimate it may take up to three months to make these changes and > fully implement the policy proposal. In the meantime, the current > procedures will remain in effect. The RIPE NCC will send another > announcement once the implementation is complete and the new procedures > are in place. > > > Thank you to everyone who provided input. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC

4 4