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

Update on ALLOCATED PI/UNSPECIFIED
by Ingrid Wijte 22 Aug '16

22 Aug '16

Dear colleagues, During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input. BACKGROUND Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation. In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be. ACTION TAKEN At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs. The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below. The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC. It was also stated that LIRs should not register any new assignments with the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments (with the exception of IXP PI assignments from our reserved address pool). APPROACH The RIPE NCC will contact the 38 LIRs holding allocations that contain address blocks with the status ASSIGNED PI (3,600 inetnum objects in total). In the following months, these LIRs will check if their RIPE Database entries are still correct. Each LIR will check their records and with their customers to see under what conditions the assignments were originally provided. After the LIRs have finished their research, the RIPE NCC will: - Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA. We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations. In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution. We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016. Kind regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC

19 40

2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by Marco Schmidt 16 Aug '16

16 Aug '16

Dear colleagues, The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. The goal of this proposal is to ban transfers of allocations made under the final /8 policy. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Several restrictions have been removed - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

39 154

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 01 Aug '16

01 Aug '16

Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 29 July 2016. 64396-64495 204288-205211 205212-206235 206236-207259 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by remco.vanmook＠gmail.com 22 Jul '16

22 Jul '16

He thought it needed to be withdrawn because he concluded that there was no consensus - and that conclusion is not his to make. So that's what Gert responded to. Remco Sent from my HTC ----- Reply message ----- From: "Riccardo Gori" <rgori(a)wirem.net> To: <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Date: Thu, Jul 21, 2016 20:29 I see he said "I think". I think list exists because everyone should be left free to express his own opinion, that's not taking decision. regards Riccardo Il 21/07/2016 20:07, Gert Doering ha scritto: Hi, On Thu, Jul 21, 2016 at 08:40:38PM +0300, Aleksey Bulgakov wrote: I think, it is time to withdraw this proposal due to we haven't reached the consensus. This is not your call to make. Gert Doering -- APWG chair -- Ing. Riccardo Gori e-mail: rgori(a)wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info(a)wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------

6 9

ipv6 assignments
by Nick Hilliard 23 Jun '16

23 Jun '16

Apropos of one of those endless arguments on the Internet (where everything is true, because it says it on the Internet), I had a discussion with Kurtis about the definition of an ipv6 "End Site", which is specified in section 2.9 of RIPE-655. This says: > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > - that service provider assigning address space to the End User > - that service provider providing transit service for the End User to other sites > - that service provider carrying the End User's traffic > - that service provider advertising an aggregate prefix route that contains the End User's assignment Our reading of this is that each of these conditions is mandatory, i.e. logical AND, because logical OR does not make sense. Term 2.9.2 states that an ipv6 End Site is only an End Site if the service provider is providing transit service for the End User to other sites. Section 5.4 and 5.4.1 then state: > LIRs must make IPv6 assignments in accordance with the following provisions. > > End Users are assigned an End Site assignment from their LIR or ISP. So the policy appears to state that an IPv6 assignment can only be issued to an end user if the end user has a transit service to more than one site, presumably ipv4 because demanding ipv6 connectivity would create a circular requirement. In other words, ipv4 connectivity to multiple different sites appears to be a mandatory prerequisite in order to get an IPv6 assignment. Could someone in the RIPE NCC please confirm that this policy is being policed as stated? And if not, when can we expect all non-compliant assignments in the RIPE NCC service region to be revoked? Nick

5 10

another way to achieve the original motives of post-exhaustion policy
by Mikael Abrahamsson 21 Jun '16

21 Jun '16

I just had a thought. What we're trying to do is to make sure there are IPv4 addresses available to new entrants. We're trying to do this by making a LIR get one post-exhaustion /22 each. The LIR fee is the limiting factor in trying to stop people from getting many /22:s. People have been trying to game this, by getting /22 and closing the LIR, thus avoiding the LIR fee. Changes in the policy has been all about trying to limit transfers etc, setting policy from what should happen with /22s, stopping transfers (so people still have to pay LIR fees, one per /22 etc). Since it's actually the post-exhaustion /22 we're after why not do this: The post-exhaustion /22 comes with a fee that is equivalent to the LIR fee. If a LIR contains one post-exhaustion /22, then this fee is waived. Doesn't this just solve the problem everybody is arguing about? Now all of a sudden it's not cheap to get multiple /22s, and we don't care any more if people keep their LIRs open or not, it still costs the same. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

4 4

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by Arash Naderpour 18 Jun '16

18 Jun '16

Hi, This policy can affect the members that already received some /22 or smaller blocks (from 185/8 range) from the market. They already paid to sellers to obtain those blocks and this policy make it impossible for them to transfer it out later if they don't need it. I'm opposing the policy, it make unnecessary limitation and put a part of community in an unfair situation. If returning an allocation is something visible it can be done to any allocation, not just the smallest ones. Regards, Arash Naderpour

3 2

Create FAQ? (was: Re: IPv4 reserved space)
by Nick Hilliard 14 Jun '16

14 Jun '16

Tore Anderson wrote: > If by some miracle you would be able to pull it all off, keep in mind > that the ~107M addresses gained by the RIPE NCC would all be used up > within two years if we return to the pre-depletion allocation policy > and consumption rate. Ask yourself: «then what?» > > Maybe you can now see why folks are telling you that this would be a > colossal waste of time APWG Chairs, Is there any possibility of creating a FAQ? There are a bunch of issues which are coming up repeatedly, of which this is one. Nick

4 4

IPv4 reserved space
by NTX NOC 14 Jun '16

14 Jun '16

Dear all, As we see ISPs and community would like to have more IPv4 space in use. I would like to ask a question what do people think about other side of IPv4 numeration space. Because we have in IPv4 a lot of addresses not in use at all but that space could be easy used. 240.0.0.0/4 Reserved (former Class E network) RFC 1700 it's 16 */8 networks. More then 256 Millions of routable and never used IPv4. 185/8 network has about 6.4M free and total RIPE has about 15M free IPv4 and we all say 185/8 will be enough for 2-3 years and rest - for some more time. But 256 M Ipv4 space could be enough for years! Space reserved for future Use. But will the future come to us or not? https://en.wikipedia.org/wiki/IPv4 https://tools.ietf.org/html/rfc1700 Is far as I see routers could easy start to use that IP space. People spend a lot of time and money to get some IPs but not to ask IANA to allow use this space. Technically it's very easy to start use IPs from such ranges. What does community thinks about it? Yuri

12 23

Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space
by Alexander Koeppe 13 Jun '16

13 Jun '16

I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex > Am 11.06.2016 um 22:35 schrieb Gert Doering <gert(a)space.net>: > > Hi, > >> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >> About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 >> by default to customers. Nobody wants it, nobody needs it. > > The "nobody needs it" is a misconception. Direct your energy there to > make people understand that IPv4 is game over. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > <totemomail_info.html> This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

14 26