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

Implementation details 2009-06 and 2009-08
by Ingrid Wijte 30 Sep '09

30 Sep '09

Dear Colleagues, In my previous emails regarding the two accepted policy proposals (2009-06 and 2009-08) I overlooked to add information regarding approximate implementation timelines. We expect to be able to implement 2009-06 (Removing Routing Requirements from the IPv6 Address Allocation Policy) within one month and 2009-08 (IPv6 Provider Independent (PI) Assignments for LIRs) within three months. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

2009-08 Proposal Accepted (IPv6 Provider Independent (PI) Assignments for LIRs)
by Ingrid Wijte 30 Sep '09

30 Sep '09

PDP Number: 2009-08 IPv6 Provider Independent (PI) Assignments for LIRs Dear Colleagues Consensus has been reached, and the proposal described in 2009-08 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-481.html Note: This document also incorporates the changes coming from the proposal described in 2009-06, Removing Routing Requirements from the IPv6 Address Allocation Policy, for which consensus was also reached. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-08.html Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

2009-06 Proposal Accepted (Removing Routing Requirements from the IPv6 Address Allocation Policy)
by Ingrid Wijte 30 Sep '09

30 Sep '09

PDP Number: 2009-06 Removing Routing Requirements from the IPv6 Address Allocation Policy Dear Colleagues Consensus has been reached, and the proposal described in 2009-06 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-481.html Note: This document also incorporates the changes coming from the proposal described in 2009-08, IPv6 Provider Independent (PI) Assignments for LIRs, for which consensus was also reached. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-06.html Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

agenda for upcoming APWG meeting
by Gert Doering 28 Sep '09

28 Sep '09

Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in two weeks in Lissabon. This time, we the following three time slots: Wednesday, Oct 7, 09:00 - 10:30 Wednesday, Oct 7, 11:00 - 12:30 Thursday, Oct 8, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. The agenda is fairly lightly loaded so far, especially for the Thursday time slot, all we have is "if you have something in mind that needs discussion, this is the place to go". So we certainly welcome your input. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-05 [multiple IPv6 /32 allocations] - withdrawn 2008-05 [Anycast for ENUM] - accepted 2009-02 [Resources to the RIPE NCC] - accepted - overview over proposals currently in Last Call 2009-06 [Routing Requirements] 2009-07 [global ASN block policy] 2009-08 [IPv6 PI for LIRs] - common policy topics in all regions (end of IPv4, transfers, ...) C. Rough Edges of the current policies Report from the RIPE NCC Registration Services department on issues and unintended side-effects showing up in the daily implementation of the RIPE policies. (+ brief discussion) D. "Routing Issues" update At RIPE 58, we decided to work together with the routing WG to remove "routing policy" from the address policy documents, and have the routing WG come up with an updated routing recommendation document. This is to briefly summarize what this is all about and point to the document. Discussion should take place in the routing WG. E. Document Cosmetic Surgeries Project - Filiz Yilmaz (separate item from "B.", because it's really a separate activity - and this gives us a bit scheduling flexibility) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- E. New Proposals since RIPE 58 overview about what's coming [5-10 min] F. Discussion of open policy proposals ---- various stuff, not directly related to IPv4 run-out --- 2006-05 PI Assignment Size [?? min] 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team) ---- directly related to IPv4 run-out --- 2008-06 Use of Final /8 (Philip Smith) 2009-03 Run Out Fairly (Daniel Karrenberg) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (Alain Bidron) ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- X. Ideas how to tackle any problems that have been experienced by the NCC Registration Services Department. (open discussion, based on the report and comments on Wednesday) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 1

2009-03 New Draft Document Published (Run Out Fairly)
by Filiz Yilmaz 28 Sep '09

28 Sep '09

PDP Number: 2009-03 Run Out Fairly Dear Colleagues, The draft document for the proposal described in 2009-03 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-471-draft2009-03.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 20 October 2009. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC

6 6

2009-07 Proposal Accepted (Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries)
by Filiz Yilmaz 28 Sep '09

28 Sep '09

PDP Number: 2009-07 Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Dear Colleagues, Consensus has been reached, and the proposal described in 2009-07 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: ripe-480, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries" http://www.ripe.net/ripe/docs/ripe-480.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2009-07.html Please note that this is a global policy and will therefore come into effect only after it has been accepted as a policy in all other RIR regions and then ratified by ICANN. Thank you for your input. Regards Filiz Yilmaz Policy Development Manager RIPE NCC

1 0

ripe471 - language query
by David Freedman 25 Sep '09

25 Sep '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick query w.r.t the ripe471 document relating to a conversation I had with another registry today who were confused by the use of the language: Section 5.3 (Additional Allocations) states: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." Whereas Section 5.4 (Sub Allocations) states: "LIRs are still required to demonstrate about 80% usage for all their allocations." The question is therefore, do we mean: - - That all the address space currently allocated to the registry should be summed and if the registry consumes more than 80% of this they qualify for an additional allocation or - - That all allocations the registry has must each consume more than 80% before the registry qualifies for an additional allocation. and if so, could the language in the document be cleaned up to avoid such ambiguity? Dave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8n74ACgkQtFWeqpgEZrL9tgCfUbDNmABC8AfnJ4YU/Rd1waU0 Ga8Anjd3WAb1cuyQ/xvd0LH9Z9ZAFilo =q7Pd -----END PGP SIGNATURE-----

1 0

Decision regarding 2009-08
by Gert Doering 25 Sep '09

25 Sep '09

Dear address policy WG, one of our policy proposals (2009-08, IPv6 PI assignments for LIRs) has reached the end of the "last call" phase, and is now being discussed among the chairs of all working groups to decide whether the RIPE policy process has been properly followed, and whether consensus has been reached. The APWG chairs have decided that consensus has been reached, but the amount of participation from the WG was small enough that this was a difficult decision. - at the RIPE meeting, there was support for moving in this direction - in the discussion and review phases, there were 3 e-mails stating explicit support. One e-mail stated non-support, but that was referring to another mail with questions about the proposal, so it was a bit unclear on what exactly the "non-support" referred to. - during last call phase, there was exactly 1 (one) e-mail on the list, and that e-mail was a question regarding the proposal. We, as the WG chairs, think that the change proposed is useful to have a more workable policy for "real world" networks. Thus we have decided to move forward, even if the amount of participation was a bit low. In general, we really need to see a few more voices in the various phases - otherwise it's really hard to claim consensus. (Which means that we, as the WG chairs, will have to be a bit more proactive in getting responses out of YOU...). regards, Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

3 2

Re: [address-policy-wg] 2009-08 Last Call for Comments (IPv6 Provider Independent (PI) Assignments for LIRs)
by IP-Office KPN 24 Sep '09

24 Sep '09

All, I support the general idea of the proposal, but I have some questions: The proposal states that (last paragraph): "If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both." First question: Only in this last paragraph of the proposal there is mention of "PI assignment" as opposed to "IPv6 assignment". Was this done intentionally? Second question: Is it (therefore) not possible to become a LIR and just keep the PI assignment instead of asking for a IPv6 PA allocation? I can imagine that if an organisation doesn't want to have Independent Assignment Request and Maintenance Agreements with LIRs, instead of entering into a End User Assignment Agreement with RIPE, the organisation wishes to become a LIR (same costs, more service) while wanting to keep the previously assigned PI space (and public AS number). Third question: Also, (just to be sure) as this Policy document exclusively deals with IPv6, does this policy proposal also have impact on the IPv4 PI space an organisation already has when it wants to become an LIR? With kind regards, Andries Hettema nl.kpn-bbt IP-Office KPN Internet 070 45 13398 ip-office(a)kpn.com

2 1

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