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

2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 29 Sep '15

29 Sep '15

Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

9 19

Discussion phase .. 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by Erik Bais 16 Sep '15

16 Sep '15

Dear all, The initial discussion phase of the proposal has passed .. however I would like to extend it to allow some additional time for people to provide insight or feedback and questions to the end of next week ( Sept. 25 2015 ). Ill work with the NCC in the timing to see if we can get the Impact Analyses done before the Bucharest RIPE meeting. So if you have not read the proposal, please have a look at it.. If you have additional insight or questions about it, please let me know. Quick short link to the proposal : https://www.ripe.net/participate/policies/proposals/2015-04 Regards, Erik Bais

1 0

"last /8" allocation size - community feedback request before engaging PDP
by Radu-Adrian FEURDEAN 15 Sep '15

15 Sep '15

Hello everybody, Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Before submitting the proposal we would like to have some community feedback on several aspects : 1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool 2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail) 3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ??? We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month. The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :) Regards, -- Radu-Adrian FEURDEAN fr.ccs

13 23

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by George Michaelson 03 Sep '15

03 Sep '15

Right. I mussed up some details. The substance remains: if you are exposed to economics which depends on the use of communities for TE, and cannot influence external agents you do BGP with to support extended communities, then you may decide you need a 16bit ASN, and so they have inherent value to you, distinct from any other resources potentially in transfer. You aren't looking to acquire active IPv4, or IPv6, you are looking to acquire a 16 bit ASN as a thing in itself. -G On 3 September 2015 at 15:49, Nick Hilliard <nick(a)inex.ie> wrote: > This has come up several times before. There is support for asn32s in bgp > extended communities: you need the "Transitive Four-Octet AS-Specific > Extended Community" values from here: > > http://www.iana.org/assignments/bgp-extended-communities > > ... and you need to hope that this is supported on your router software. > And everyone else's that you plan to talk to. > > This can work in some situations where you have tight control over the > entire management plane of everywhere you plan to export these communities > to, but the internet at large is going to have a lot more difficulty with > it. > > As you point out, you can only support 16b:32b or 32b:16b style communities > with the current community mechanism, not 32b:32b communities. The latter > will require implementation of draft-ietf-idr-wide-bgp-communities. > > So if you have any requirement for 32b:32b communities, you're out of luck. > > Nick > > On 03/09/2015 18:59, George Michaelson wrote: > > Purely as a point of information, I think its worth remembering that 32 > bit > > ASN cannot be used in currently specified BGP4 in communities, because > its > > a 32 bit field defined as two 16 bit halves. I believe there is work > afoot > > in IETF to fix this. I don't have concrete details. > > > > Therefore there *is* a quality in 16 bit ASN which may be divorced from > its > > association with specific V4 or V6 resources and which makes it a > desirable > > thing, in itself, for some people: If you are in the business of doing TE > > in BGP with communities, you can't do it with 32 bit ASN. You have to use > > other mechanisms. > > > > On that basis, Should you permit transfers of ASN, you might wish to > permit > > transfers of ASN independently of any associated routable IP address > space: > > people who already have space but need a 16 bit ASN may wish to acquire > one. > > > > I'm not an asset holder in the RIPE region, and I am staff at another > RIR, > > so I stress this is purely informational. I'm not trying to directly > > advocate for or against ASN transfers. > > > > -George > > > > On 3 September 2015 at 14:38, Nick Hilliard <nick(a)inex.ie > > <mailto:nick@inex.ie>> wrote: > > > > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > > Mind, if yelling loudly is how you get policy made in the RIPE > > > community, rest assured I can yell VERY loudly. I can, in fact, > > > even automate the yelling if need be. > > > > please don't: rfc7282 works much better. > > > > Nick > > > >

2 1

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by George Michaelson 03 Sep '15

03 Sep '15

Purely as a point of information, I think its worth remembering that 32 bit ASN cannot be used in currently specified BGP4 in communities, because its a 32 bit field defined as two 16 bit halves. I believe there is work afoot in IETF to fix this. I don't have concrete details. Therefore there *is* a quality in 16 bit ASN which may be divorced from its association with specific V4 or V6 resources and which makes it a desirable thing, in itself, for some people: If you are in the business of doing TE in BGP with communities, you can't do it with 32 bit ASN. You have to use other mechanisms. On that basis, Should you permit transfers of ASN, you might wish to permit transfers of ASN independently of any associated routable IP address space: people who already have space but need a 16 bit ASN may wish to acquire one. I'm not an asset holder in the RIPE region, and I am staff at another RIR, so I stress this is purely informational. I'm not trying to directly advocate for or against ASN transfers. -George On 3 September 2015 at 14:38, Nick Hilliard <nick(a)inex.ie> wrote: > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > Mind, if yelling loudly is how you get policy made in the RIPE > > community, rest assured I can yell VERY loudly. I can, in fact, > > even automate the yelling if need be. > > please don't: rfc7282 works much better. > > Nick > >

2 1

Update on Inter-RIR Transfer Implementation
by Marco Schmidt 01 Sep '15

01 Sep '15

Dear colleagues, We wanted to update you on our implementation of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". We have made good progress so far on what has been one of the most substantial policy changes ever implemented by the RIPE NCC. Most of the updates to our internal processes and software have been finalised, as have the processes that require interaction with the other RIRs. During the implementation we encountered some additional complexity in the transfer process. To compensate for this, we are developing additional software automation to ensure the quality of registration data is maintained. We now therefore expect the implementation to be finished before the end of September. The policy implementation status has been updated accordingly, and you can find this here: https://www.ripe.net/manage-ips-and-asns/resource-management/policy-impleme… We will send another announcement once the implementation has been completed. Kind regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE IPv4 Allocation Policy
by SBS - Support 31 Aug '15

31 Aug '15

Dear RIPE Address Policy Group, The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified. Regards, Walter This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately.

10 15

2015-03 Last Call for Comments (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 31 Aug '15

31 Aug '15

Dear colleagues, The proposal described in 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 29 September 2015 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of the Working Group for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 29 September 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Help Re: address-policy-wg Digest, Vol 48, Issue 17
by 8lb. 7zin 19 Aug '15

19 Aug '15

‏في الثلاثاء، ١٨ أغسطس، ٢٠١٥, <address-policy-wg-request(a)ripe.net> كتب: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net <javascript:;> > > 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 <javascript:;> > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net <javascript:;> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2015-04 New Policy Proposal (RIPE Resource Transfer > Policies) (Jan Ingvoldstad) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Aug 2015 18:26:30 +0200 > From: Jan Ingvoldstad <frettled(a)gmail.com <javascript:;>> > To: Address Policy Working Group <address-policy-wg(a)ripe.net > <javascript:;>> > Subject: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE > Resource Transfer Policies) > Message-ID: > < > CAEffzkzzpKA1aqUtUzESDJpLggLbOUdfMhaETmStDcRddPmUjg(a)mail.gmail.com > <javascript:;>> > Content-Type: text/plain; charset="utf-8" > > On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < > james.blessing(a)despres.co.uk <javascript:;>> wrote: > > > On 14 August 2015 at 10:54, Marco Schmidt <mschmidt(a)ripe.net > <javascript:;>> wrote: > > > > > https://www.ripe.net/participate/policies/proposals/2015-04 > > > > Thanks for putting in the time and effort, Erik! > > Couple of questions/comments... > > > > From 1.0 > > > > Shouldn't the scope be explicit as to what is/isn't included > > > > I agree that this would help. > > >From 2.1 > > > > "Transfers can be on a permanent or non-permanent basis." > > > > How is this going to be recorded and managed within the context of > > reflecting it being a non-permanent transfer? > > > > Wouldn't that be up to the RIPE NCC? > > >From 2.2 > > > > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit > > ASNs)" > > > > Rather than "such as" this needs to be a definitive list of what is > > classed as a restricted resource > > > > I concur, but I don't think it should be listed in the same document. > > My first thought is that this list should be maintained by the RIPE NCC. > > Keeping that list in a separate document means changing fewer documents > when policy changes, or reality reaches a pre-set limit set in policy. > > That separate list should reference the policy documents enabling the > restrictions. > > >From 3.1 > > > > Again a list of conditions or references to policies that impose > > restrictions needed > > > > I'm a bit confused both by the point and by your response to it, maybe I'm > just tired, but I think both could be clearer. :) > > >From 4.0 > > > > M&A process is mentioned, should there be other references to this? > > Especially as M&A (as I understand it) allows 2.2 to be overridden > > > > "The document proposes to include the transfer restrictions to mergers and > acquisitions. This is done to make the policy more in line with the > intention of the transfer policy restrictions when proposed." > > General > > > > - As this is about transfers should this also cover returning > > resources to ripe NCC so all types of transfers be included > > > > I'm not sure that this would be useful, but 2015-04 could 1) include a > reference to the policy for that, and 2) make it even clearer that this is > a document for transfers between resource holders. > > I don't think it's useful to consider the RIR a resource holder in this > context. > > - broadly support the unification of transfer policy into a single > > document, just things bits are missing or muddy > > > > Agreed, but the document is largely clarifying more than muddying, IMHO. > -- > Jan >

1 0

Fwd: 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)
by ripe＠europeiptv.net 16 Aug '15

16 Aug '15

Hello, The allocations made before the date of this announcement, should be governed by the old politics. is not serious things apply retroactively. On exhaustion, RIPE Why is not like other RIRs? Because RIPE accepts LIRs outside the region? without having a registered company and physical address in the RIPE Region? Other ARIN RIR as it met. Regards. David

8 12