September 2009 - address-policy-wg

late comments on 2009-06
by Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 24 Sep '09

24 Sep '09

Dear colleagues, the last call for 2009-06 is very close to expiring... I'm sorry I'm coming this late with a few comments. I certainly support the the motion to remove from the contraints for routing announcements from the address allocation policy; I voiced my support already at the last RIPE meeting with strong words. I hope that Rob Evans' initiative to draft a document on recommended annoucement practices in IPv6 in routing WG will result in document providing guidance on usage of aggregates, more specifics etc. without unduely stressing the global routing system. Admittedly this will be much harder than the removal of a few words from existing policy text (as 2009-06 does). Recently a potential downside of the removal of routing constraints from allocation policy came to my attention: NCC resource analysts might begin to encourage or even force LIRs to plan to deaggragate announcements when discussing requests for address space. For the record: I'd strongly request that NCC should refrain from doing so until documents giving guidance on appropriate use of deaggregation, or announcements of more specifics have been written and agreed upon. Applying such restraint seems not to require explicit text in the allocation policy - though I can see that NCC using or not using such restraint can in some cases lead to different results in evaluating requests for address space; i.e. some times allocating an additional separate address block when using a more specific out of another allocation might be another way for solving a particular routing requirement. Before closing let me make another nit: I feel quite uncomfortable to see the the second paragraph the impact analysis for fragmentaion/aggregation: it would be better to ONLY have the "we cannot seriously estimate" of the first paragraph than juggle meaningless short sighted numbers. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv(a)NIC.DTAG.DE Phone: +49 251 7985 200 fax: +49 251 7985 109

3 2

The final /8 policy proposals, part 3.2
by Sander Steffann 22 Sep '09

22 Sep '09

Hello again, After my last questions I have only received concrete answers from Michael. He suggested the following: - Use a minimum allocation size of /24 - Determine the maximum allocation size for every LIR based on their run rate - Make no exceptions for cases where it is hard or impossible to downscale Jim asked why we should change the policy at all for the final /8. I hope I have given at least one good reason: new entrants. Michael proposed to leave (further) decisions about the final /8 until IANA runs out of IPv4 addresses. Does this represent the view of the community? I am not sure if people keep quiet because they agree with what has already been said, or because they are still on vacation... Please let us know :) Thank you, Sander Steffann APWG co-chair

17 39

The final /8 policy proposals, part 3
by Sander Steffann 22 Sep '09

22 Sep '09

Hello everyone, It has been quiet for some time now, so I think we should start to discuss the final /8 proposals again. In part 2 of the discussion, we discussed how many addresses an LIR should be able to get from the final /8. I'll try to summarize that part of the discussion. Please correct me if I am wrong or if I missed something: Most people preferred option b: All requests are downscaled by a certain factor Some people preferred option a: Everyone gets one (and only one) fixed size block There were comments that IPv4 would never run out, but let's assume that it will run out. In the worst (best?) case we won't need this final /8 policy, so it doesn't hurt to be prepared when we do need it. Because most people preferred option b, let's discuss some of the details to see if we can make that work. If we are going to downscale address space requests, how should we do that? Some issues: - If a company demonstrates the need for a /20, we could give them (for example) a /26. Smaller organisations would end up with even smaller amounts of address space. Currently prefixes longer than a /24 can not really be routed on 'the Internet' (for some definition of 'Internet'). Do we expect this to change, or do we have to make the minimum allocation size a /24 so that LIRs receiving address space can use it? - Do we want a maximum allocation size? This might be useful to prevent a few large companies to grab most of the address space, but it might also be unnecessary. - Do we want to make exceptions for certain situations where downscaling is not possible? For example a server farm with many HTTPS sites can't use less IP addresses than the number of websites (with the current protocols). I would like to leave PI assignments out od the discussion for now. I think we have enough PA related questions to discuss, but don't worry: we will get to the PI discussion later. As before: please stay on topic. This discussion is hard enough as it is :) Thanks, Sander Steffann APWG co-chair

6 18

New IPv4 blocks allocated to RIPE NCC
by Flor Paredes 21 Sep '09

21 Sep '09

Dear Colleagues, The RIPE NCC received the IPv4 address ranges 2/8 and 46/8 from the IANA in September 2009. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that several "pilot" prefixes are being announced from each /8. These prefixes are: 2.0.0.0/16, pingable 2.0.0.1 2.1.0.0/21, pingable 2.1.0.1 2.1.24.0/24, pingable 2.1.24.1 46.0.0.0/16, pingable 46.0.0.1 46.1.0.0/21, pingable 46.1.0.1 46.1.24.0/24, pingable 46.1.24.1 They all originate in AS12654. More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Regards, Flor Paredes Registration Services Manager RIPE NCC

1 0

Re: [address-policy-wg] The final /8 policy proposals, part 3.2
by Remco van Mook 17 Sep '09

17 Sep '09

Not everybody is going to run out at the same time because there are likely already LIRs whose assignment rate is so low they'll still have space from their current allocation in 2015 or so - intentional or not. Remco ----- Original Message ----- From: address-policy-wg-admin(a)ripe.net <address-policy-wg-admin(a)ripe.net> To: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Sent: Thu Sep 17 16:11:53 2009 Subject: RE: [address-policy-wg] The final /8 policy proposals, part 3.2 > Agree for as long as there are addresses enough to meet the applicants > needs. Yet it is IMHO pointless to hand out micro-blocks as a sorry > response to a PA-request for a substantially larger block. In particular, what if the applicant's competitor just received a much larger allocation two weeks earlier? That's why I think that any policy change related to the last IPv4 allocations should focus on some way to make sure that all LIRs run out of IPv4 at roughly the same time. Maybe the policy change needs to take effect before we reach the last /8 from IANA. Maybe we need some kind of cap on maximum allocation that shrinks month by month. Maybe we should link the allocation size to the number of weeks it would take to use it up given the applicant's historical run-rate, and then shrink that number of weeks every month. > This isn't > about forcing anyone in any particular direction, but about whether it > is of greater benefit to the community at large to allocate > such blocks > to organizations with a potential to enable connectivity between large > numbers of new users and the existing v4 network. Has anyone clearly explained how any organization would enable such connectivity in a way that existing LIRs could not? It sounds like people are assuming that there may be some magic bullet while in reality there are just network providers providing services. The technical details of those services change over time for all LIRs. Innovation is not restricted to new entrants. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.

1 0

(no subject)
by Kamil Semavi 11 Sep '09

11 Sep '09

How can I transfer a subnet from one AS to another AS number? Thanks Kamil

1 0

RIPE NCC NRO Number Council Candidates Confirmed
by Axel Pawlik 10 Sep '09

10 Sep '09

[Apologies for duplicate emails] Dear Colleagues, The nomination period for appointment to the Number Resource Organization (NRO) Number Council (NC) has now closed. This year, in accordance with the Number Resource Organization's Memorandum of Understanding (NRO MoU), the RIPE community will elect one individual to fill the seat that is being vacated by Dave Wilson, who was elected to a three-year term on the NRO NC that began on 1 January 2007. The following candidates have accepted their nomination for the vacant seat on the NRO NC from the RIPE NCC service region: - Dave Wilson The representative elected to the NRO NC seat will serve a three-year term, beginning 1 January 2010. Candidate profiles and information on how to submit an Expression of Support can be found at: http://www.ripe.net/info/resource-admin/nro2009/confirmed-nominations.html The election to fill this seat will be held at the RIPE 59 Meeting that takes place in Lisbon, Portugal from 5-9 October 2009. For more information about the NRO NC and the selection process, see: http://www.ripe.net/info/resource-admin/nro2008/about-nc.html Regards, Axel Pawlik Managing Director, RIPE NCC

1 0