September 2015 - address-policy-wg

2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 07 Nov '15

07 Nov '15

Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number - The RIPE NCC's need evaluation has been removed - A limit of 1,000 AS Numbers per organisation has been added - There is now a requirement that 16-bit AS Numbers be multihomed after nine months - The requirement that the routing policy must be new and unique has been removed - 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/ripe/policies/proposals/2014-03 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-03/draft We encourage you to read the draft document text and send any comments to <address-policy-wg(a)ripe.net> before 22 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

16 41

2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4
by Job Snijders 15 Oct '15

15 Oct '15

Dear APWG, Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review: """ A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """ diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Kind regards, Job

8 15

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

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

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 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 04 Sep '15

04 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