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

2015-04 Discussion Period extended until 25 September 2015 (RIPE Resource Transfer Policies)
by Marco Schmidt 08 Oct '15

08 Oct '15

Dear colleagues, The Discussion Period for the proposal 2015-04, "RIPE Resource Transfer Policies" has been extended until 25 September 2015. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. The proposer asked to provide additional feedback or questions. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 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

3 3

New on RIPE Labs: IPv4 in the RIPE NCC Service Region - Three Years After Reaching the Last /8
by Mirjam Kuehne 08 Oct '15

08 Oct '15

Dear colleagues, In September 2012 the RIPE NCC reached its last /8 of available IPv4 addresses. This activated a new phase in the RIPE IPv4 policies, with each LIR now eligible to receive one final /22 allocation. In this new article on RIPE Labs we look at developments in IPv4 allocations and remaining addresses at the RIPE NCC in the three years since then: https://labs.ripe.net/Members/wilhelm/ipv4-in-the-ripe-ncc-service-region-t… Kind regards, Mirjam Kuehne RIPE NCC

1 0

2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by Marco Schmidt 02 Oct '15

02 Oct '15

Dear colleagues, A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 14 September. Regards Marco Schmidt Policy Development Officer RIPE NCC

12 24

Re: [address-policy-wg] 2015-03 Proposal Accepted (Assessment Criteria for IPv6 Initial Allocation Size)
by Mathew Newton 01 Oct '15

01 Oct '15

Hi Marco, > Consensus has been reached on the proposal to amend RIPE Document > ripe-650, "IPv6 Address Allocation and Assignment Policy". > The new RIPE Document is called ripe-655 and is available at: > > https://www.ripe.net/publications/docs/ripe-655 That's great news! > Thank you to everyone who provided input. Yes, and thanks also to you and your colleagues for your assistance throughout the process. Regards, Mathew

1 0

Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"
by Nikolas Pediaditis 01 Oct '15

01 Oct '15

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". In accordance with the new policy, Internet number resources can be transferred between resource holders in the RIPE NCC service region and resource holders in the service regions of other Regional Internet Registries (RIRs). Inter-RIR transfers are possible between RIRs with compatible policies. Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR transfers with the RIPE NCC: - IPv4 addresses can be transferred to/from the ARIN service region - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service region The main web page on inter-RIR transfers with the supporting documentation and all related information to get you started can be found at: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2014-05 The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is available at: https://www.ripe.net/publications/docs/ripe-644 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services

5 7

2015-03 Proposal Accepted (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 01 Oct '15

01 Oct '15

Dear colleagues, Consensus has been reached on the proposal to amend RIPE Document ripe-650, "IPv6 Address Allocation and Assignment Policy". This policy change introduces new criteria for the evaluation of large IPv6 allocation requests: * Hierarchical and geographical structure * Segmentation for security * Planned longevity The existing requirements in the policy that stipulate the number of users a nd extent of the infrastructure remain unchanged. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 The new RIPE Document is called ripe-655 and is available at: https://www.ripe.net/publications/docs/ripe-655 We estimate that this proposal will take about one week to fully implement. We 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

1 0

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