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

2010-05 Policy Proposal Withdrawn (Global Policy for IPv4 Allocation by the IANA post exhaustion)
by Emilio Madaio 18 Mar '11

18 Mar '11

Dear Colleagues, The global policy proposal 2010-05, "Global Policy for IPv4 Allocation by the IANA post exhaustion", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2010-05 The reason for withdrawal is: it was agreed with the proposer that the lack of community feedback and the impossibility of the proposal becoming globally accepted due to recent developments in the global PDP at the time were sufficient reasons to have it withdrawn. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Updated RIPE NCC Procedural Document Available
by Arne Kiessling 15 Mar '11

15 Mar '11

Dear Colleagues, The RIPE NCC has published an updated procedural document, ripe-518, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document replaces ripe-511, which was published recently. The updated document is available at: http://www.ripe.net/ripe/docs/ripe-518 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre

2 2

New RIPE NCC Procedural Document Available
by Arne Kiessling 10 Mar '11

10 Mar '11

Dear Colleagues, The RIPE NCC has published the new procedural document ripe-511, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document describes the RIPE NCC procedure when contacting End Users of independent Internet number resources who have not yet entered into a contractual relationship with sponsoring Local Internet Registry (LIR) or the RIPE NCC. It also describes the possible consequences if End Users of independent Internet number resources fail to respond when approached by the RIPE NCC or are not compliant with the policies of the RIPE community. The new document is available at: http://www.ripe.net/ripe/docs/ripe-511 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre

2 1

Re: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting
by Adrian Czapek 07 Mar '11

07 Mar '11

My similar request was rejected for the same reasons. Although I did not get a proposal to sub-allocate PA address space from my allocation and deaggreage it over BGP, as Mathieu got, but let's assume that I would get such proposal if I asked for it. What puzzles me, what is the meaning of that action? Let's check the options: 1. They become LIR, they got their allocation - result: +1 prefix i global routing table. 2. They gets PA suballocation from other LIR and deaggreate it - result +1 prefix in global routing table. 3. They gets PI address space - +1 prefix in global routing table. As can be clearly seen above, global routing table growth is not an issue here, since IPRA suggests to deaggregate PA sub-allocations. So, what is an issue here, beacuse I have a strange feeling that only issue are $$ lost by certain RIR due to certain companies refusing to become LIR?! Regards -- Adrian

2 2

Re: [address-policy-wg] IPv6 PI resource question!
by Igor Ybema 03 Mar '11

03 Mar '11

Hi, I'm new to the list but would like to comment on this subject. I'm also trying to receive IPv6 PI for a webhosting customer of us which seems to be a big problem. I do not understand why everyone claims that 'the routing table growth' is the reason not to allow too much IPv6 PI. Those currently having IPv4 PI would of course require IPv6 PI because they still want to be indepentent. If they need to be a LIR to get IPv6 PA the problem is not solved for the routing-table issue. A prefix is still entered into the same global routing-table. I would suggest changing the IPv6 PI policy to make it more clear for hosting/isp company's to get IPv6 PI by enforcing that the equipment on which the IPv6 addresses are installed in rooms accessible by that company. Multi-homing is a good reason also. I'm not sure if we should delete that reason. This makes the company more aware that they are really independend. This suggestion solves two things: - large broadband ISP's with CPE in office-building, homes etc do not fit into this policy. The equipment is behind other company's doors. This enforces these company's to assign block to their customers from PA space as it was meant to be. - small ISP's/hosting company's with a few racks installed at one ore more DC's (which we talk about in this postings) do fit into this policy and will be independend to their internet suppliers. Of course, they should request another PI (or get assigned-PA from a LIR) for their customers which buy dedicated racks from them and receiving their own key to the lock. This is exactly what we would like to see it. What do other people on the list think about this? regards, Igor Ybema

8 11

New IPv4 block allocated to RIPE NCC
by Andrea Cima 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC has received the IPv4 address range 185/8 from the IANA. This is the final allocation of IPv4 address space that the RIPE NCC will receive from the IANA as stated in ripe-436, "Global Policy for the Allocation of the Remaining IPv4 Address Space". The minimum allocation size for this /8 has been set at /22. You may wish to adjust any filters you have in place accordingly. More information on the IP address space administered by the RIPE NCC can be found on our website at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Additionally, please note that three "pilot" prefixes will be announced from this /8. The prefixes are: 185.0.0.0/16 185.1.0.0/21 185.1.24.0/24 They all originate in AS12654. The pingable addresses will be: 185.0.0.1 185.1.0.1 185.1.24.1 More information on this 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 Kind regards, Andrea Cima Registration Services Manager RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1Pu9kACgkQXOgsmPkFrjM9FgCgsaT8cFxK0YKTFUFzj41L0PQT N1AAoIgmL1zUY8JjkCSa05xt0t8oppgP =woX5 -----END PGP SIGNATURE-----

2 8

RE: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD
by Wyatt Mattias Gyllenvarg 01 Mar '11

01 Mar '11

Hi We would like to weigh in here. We feel that it should be RIPEs policy to allocate ONE /32 to any LIR who requests it for 6rd. 6rd is the only way for us to reach all our residential customers. Especially those in Municipal Networks that are very slow to invest in their networks and often do not have the competence and time to impelment IPv6. Also, Cisco has not yet implemented even a small part of the protective mechanisms we rely on in IPv4 to secure our residential networks. Many of these features are required to meet the demands contracted with the customers. We cannot use native IPv6 until Cisco implements these features and we have tested and rolled them out on hundreds of switches. 6rd bypasses all these issues. IF we can get a /32 for that purpuse. -- Med Vänliga Hälsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line ---------------------------

6 8

REMINDER; WAS Re: 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders)
by Emilio Madaio 25 Feb '11

25 Feb '11

[Apologies for duplicates. Courtesy copy sent to Routing Working Group and RIPE NCC Services Working Group. Please direct feedback to the Address Policy Working Group mailing list.] Dear Colleagues, The new version of RIPE Policy Proposal 2008-08, "Initial Certification Policy for Provider Aggregatable Address Space Holders", was published on 9 February 2011. The time period for community review ends on 23 February 2011. Some feedback was sent to the Address Policy Working Group mailing list. However, to maintain the discussion, we strongly recommend that you share your ideas and comments and clearly let the community know if you: - Support the implementation of the proposal - Support the general principle of the proposal but would prefer another wording - Support the general principle with some details changed but agree to postpone this discussion until another stage of the policy proposal review. (This is an initial proposal that covers only PA resources. If the community supports extending certification to all resources, then another version of the proposal will be necessary.) - Do not support the proposal (please explain your motivations) You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2008-08/draft Please send an email with your comments to address-policy-wg(a)ripe.net by 23 February 2011. Best regards, Emilio Madaio

2 2

2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders)
by Emilio Madaio 24 Feb '11

24 Feb '11

Dear Colleagues, The new version (3.0) of the proposal 2008-08 has been published. The draft document for the proposal and the impact analysis have also been published. The proposal will now undergo a two weeks Review Phase as explained in the previous message available at: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022… You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2008-08/draft We strongly encourage you to read the draft document text and send comments, ideas, feedback to address-policy-wg(a)ripe.net before 23 February 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

11 17

Query for the RIPE NCC: Size of PIv4 assignments used for access networks
by Martin Millnert 22 Feb '11

22 Feb '11

Hi, I would like to request from the RIPE NCC an answer to the following query: What is the size, in number of addresses, of all PIv4 assignments that are (mostly) used for access networks? Access networks in this context means traditional ISP:s who let humans access the internet. I believe the RIPE NCC keeps documentation over what justifies an assignment, so I imagine it will be possible to come up with some kind of answer to this question even if it is outright impossible to answer based on data in the database. If it is indeed possible to answer the above question with some form of accuracy (+/- 50% or so: order of magnitude most important to get right), I would like to run the question also for PAv4. This is required data to reach some form of informed policy decision/consensus on the PIv4 / PIv6 discrepancy issue which has resurfaced. Regards, Martin

1 0

2010-05 Discussion Period extended until 22 March 2011 (Global Policy for IPv4 Allocation by the IANA Post Exhaustion)
by Emilio Madaio 22 Feb '11

22 Feb '11

Dear Colleagues, The Discussion Period for the global policy proposal 2010-05 has been extended until 22 March 2011. The extension was decided due to the lack of feedback in the Initial Discussion Period. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-05 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

IPv6 PI resource question - Not for ISP but hosting
by Mathieu Paonessa 17 Feb '11

17 Feb '11

Hi All, I've been following the previous thread concerning IPv6 PI assignment but I'm running into a special case and need your input. As a LIR, I did send an IPv6 PI request for one of our customers few days ago and the hostmaster did point me to this previous thread saying that we are in the same case and that he may reject this request. The company requesting the IPv6 PI is a hosting company providing software as a service solution for its customers. All the infrastructure (servers, routers...) is owned by them. For security reasons, they chose to isolate each of their customers on a separate VLAN. Their customer don't have administrative access to the servers and just uses the software hosted on them for their CRM, extranet or other corporate applications. Would you consider this to be the exact same case as an ISP assigning an IP to a customer's CPE? I really don't see the point for such a company to become a LIR as they will only use those IPs for them. They also don't need more than a /48 as they are currently having about 50 customers. Regards, Mathieu Paonessa

8 15

IPv6 PI resource question!
by Yasen Simeonov(Neterra NMT) 17 Feb '11

17 Feb '11

Hi, please explain me the following case: There is a small company /ISP/ that wants PI IPs to be independent of upstream providers. The company would not make sub-allocation and will only provide its customers with addresses for Internet access, but these IPs will be the company's infrastructural addresses. The company will use DHCP pool to distribute the addresses to its customers, these will be its own infrastructure addresses and not to the customers /they may receive every time different addresses/. Can that company receive PI IPv6 considering the policy? Thanks, Yasen Simeonov -- Yasen Simeonov Network Management Team Neterra Ltd. Sofia, Bulgaria Phone: +359 2 974 33 11 Fax: +359 2 975 34 36 Mobile: +359 887 477 540 http://www.neterra.net

18 33

Re: [address-policy-wg] Re: IPv6 PI resource question - Not for ISP but hosting
by Sander Steffann 15 Feb '11

15 Feb '11

>> Correct. The idea is that one LIR PA block covers lots of customers. It's a matter of scalability... I would love to give every organization it's own block of addresses. If someone finds a way to make that scale please let us know. > > FWIW, LISP is attempting to do just that. I know. I *really* hope it will work and be accepted as a solution. I would love a situation where we don't have to worry about the future routing table size!!! Thanks, Sander

1 0

RIPE 61 Address Policy WG Meeting Draft Minutes
by Emilio Madaio 14 Feb '11

14 Feb '11

Dear Colleagues, The draft minutes of Address Policy Working Group sessions from RIPE 61 are now available at: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-61 Best Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2010-06 Proposal Accepted (Registration Requirements for IPv6 End User Assignments)
by emadaio＠ripe.net 10 Feb '11

10 Feb '11

Dear Colleagues, Consensus has been reached, and the proposal described in 2010-06 has been accepted by the RIPE community. The updated policy "IPv6 Address Allocation and Assignment Policy" is available at: http://www.ripe.net/ripe/docs/ripe-512 The new policy "Value of the "status:" and "assignment-size:" attributes in inet6num objects for sub-assigned PA space" is available at: http://www.ripe.net/ripe/docs/ripe-513 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-06 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

RIPE NCC Resource Certification service update
by Alex Band 03 Feb '11

03 Feb '11

Dear colleagues, It's been one month since I sent the announcement about the RIPE NCC Resource Certification service. I would like to give you an overview of the current status. The facts by numbers: ------------------------------ LIRs who have enabled the service: 219 Number of Route Origin Authorisations they created: 170 Number of prefixes covered by these ROAs: 469 Total IPv4 space covered by ROAs in the RIPE region: 40159 /24s Total IPv6 space covered by ROAs in the RIPE region: 7340035 /48s Unique visitors to ripe.net/certification: 1564 Downloads of the RIPE NCC Validator: 117 So while 219 LIRs have enabled the service, and very diligently created a large number of ROAs to specify their routing policy, unfortunately nobody gave any feedback on any of the mailing lists. It is very important that you let your voice be heard and provide input on policy proposal 2008-08: http://ripe.net/ripe/policies/proposals/2008-08.html Please note that version 3.0 of this proposal will be published very soon. As soon as it is available, I urge you to read it and provide feedback, because the fact that the current service not backed by a policy is not a sustainable state of affairs. Kind regards, Alex Band Product Manager, RIPE NCC http://ripe.net/certification P.S. Here are some links courtesy of LACNIC in case you would like to track the progress: http://www.labs.lacnic.net/~rpki/rpki-monitor/rpki-ta-status.xml http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ripe-roa-heatmap.png

2 1

Invitation to particpate in a RIPE Task-Force
by Wilfried Woeber, UniVie/ACOnet 03 Feb '11

03 Feb '11

Invitation to join and actively contribute to a RIPE Taskforce on "Abuse Contact Management in the RIPE Database" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: The RIPE Database serves as a data repository for Internet resource assignments and allocations in the RIPE NCC's service region. Among other purposes, it serves as a contact repository for administrative, technical and operational matters regarding IP address ranges and autonomous system numbers. Over time, some mechanisms became available, such as the Incident Response Team (IRT) object and an abuse-mailbox: attribute. Different communities seem to have developed varying expectations and understanding of how the data quality for such contact information can be maintained at a high level, and how and when a report sent to such a contact mechanism will be responded to or otherwise acted upon. Recently, some RIPE Policy Proposals were submitted for consideration and these proposals (2010-08, 2010-09 and 2010-10) were discussed in the Address Policy Working Group, the Anti-Abuse Working Group and briefly in the Database Working Group during the RIPE 61 Meeting in Rome. Deliberations among the responsible working group chairs and senior policy experts suggested that investigation be carried out to get a deeper understanding of the motivations behind the policy proposals, the expected outcomes, the operational and maintenance implications and the role the RIPE Database could perform to support the desired results. It was then suggested to the community and the policy proponents that the most efficient way to progress the issue would be the creation of a RIPE Task Force. There was no objection raised by the members of the community present at the meeting. Call for Participation ----------------------- We invite members of the RIPE community, from the security as well as from the anti-abuse areas, to volunteer and contribute to the proposed task force. Ideally, we would like to bring together the security and anti-abuse communities and the IP resource management and network operations communities to jointly analyse and refine the issue. *Draft* Mandate for the Task Force ---------------------------------- [This draft mandate is for consideration, modification and refinement by the task force] The task force is mandated to: - Agree on a useful name for the task force and, with the help of the RIPE NCC, arrange the logistics and report back to the community about the establishment of the task force - Collect all relevant input that is readily available, in particular policy proposals, information from presentations given recently by the RIPE NCC regarding ideas on the future structure, credibility and quality of data, and the maintenance mechanisms for entries in the RIPE Database - Collect and document comparable mechanisms and proposals in the other RIR Regions (APNIC, AfriNIC, ARIN and LACNIC) - Work with the interested community and the RIPE NCC to understand the problem at hand and the environment in which to develop a proposal. This analysis of the environment should include legal aspects, formal responsibilities for the use of resources on the Internet, well-established operating procedures and relevant operational aspects. - Develop one or more (policy) proposals and/or general recommendations on how collection and maintainace of relevant information in the Registry Database should be organised, including a description of potentially alternative implementations or approaches and the related impact on all parties involved *Draft* Timeline ----------------- The Taskforce should: - Try to collect the core group of participants before end of February 2010 - Start work on the dedicated mailing list as soon as possible, with a view to meet for a face-to-face meeting in advance of RIPE 62 (May 2011) - Report on the task force's progress during RIPE 62 (May 2011) and collect regular input from the RIPE community - Submit a first draft of a recommendation(s) and/or policy proposal(s) before RIPE 63 - Agree on the proposal(s) and agree on the expected implementation deadline Submitting statements of intent to actively participate -------------------------------------------------------- If you would like to participate in the task force, please email the RIPE NCC's Database Manager, Paul Palse, at <ppalse(a)ripe.net>. ________________________________________________________________________ Best regards, Wilfried, circulating this invitation on behalf of the group of the proponents, with kudos to the colleagues at the RIPE NCC for their help with wording!

1 0

FW: [policy-announce] 2006-05 New Draft Document Published (PI Assignment Size)
by Erik Bais 01 Feb '11

01 Feb '11

Hi, I was wondering what the status is of this policy. I haven't seen any updates or feedback on this and I think that it would make a lot of sense to proceed with this proposal. For those that didn't go to the RIPE 61 meeting (like myself) or missed Nick Hilliard his preso on the topic : http://ripe61.ripe.net/presentations/318-inex-ripe-rome-apwg-minassignments… You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html Regards, Erik Bais

1 0

2010-06 is going to Last Call
by Shane Kerr 28 Jan '11

28 Jan '11

Hello, [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, -- Shane

13 12

2010-07 Policy Proposal Withdrawn (Ambiguity cleanup on IPv6 Address Space Policy for IXP)
by Emilio Madaio 27 Jan '11

27 Jan '11

Dear Colleagues, The proposed change to RIPE Document ripe-451 has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2010-07.html The reason for withdrawal is: the editorial text change proposed will be discussed in the Cosmetic Surgery Project Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Proposed Implementation Plan for Policy Proposal 2010-06 in the RIPE Database
by Denis Walker 26 Jan '11

26 Jan '11

[Apologies for duplicate emails] Dear Colleagues, To prepare for the possible acceptance of RIPE Policy Proposal 2010-06, "Registration Requirements for IPv6 End User Assignments", the Database Group at the RIPE NCC proposes the following implementation plan. We will implement a new attribute ("assignment-size:") in INET6NUM objects, add some business logic for its use and add a new value (AGGREGATED-BY-LIR) for the "status:" attribute of an INET6NUM object. Schema and syntax changes in INET6NUM objects: - New attribute "assignment-size:" - Syntax is numeric value > 0 - INET6NUM object will include "assignment-size:" as an optional, single attribute - "assignment-size:" will not be an inverse searchable attribute - New value for the "status:" attribute of an INET6NUM object will be AGGREGATED-BY-LIR Business rules: - "assignment-size:" is optional in INET6NUM objects but required if "status:" is AGGREGATED-BY-LIR - The value of "assignment-size:" must be greater than the prefix size of the INET6NUM object containing the attribute - Parent status of INET6NUM object with status AGGREGATED-BY-LIR can be: ALLOCATED-BY-RIR ALLOCATED-BY-LIR AGGREGATED-BY-LIR - If parent status is AGGREGATED-BY-LIR, grandparent status cannot be AGGREGATED-BY-LIR - If an object has the status AGGREGATED-BY-LIR, a more specific object can only have the status AGGREGATED-BY-LIR (subject to the aforementioned constraints) We will prepare implementation of this plan during the week commencing 31 January 2011. It will be deployed during the week commencing 7 February 2011 should RIPE Policy Proposal 2010-06 be formally approved. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

2010-02 Proposal Accepted (Allocations from the last /8)
by Emilio Madaio 19 Jan '11

19 Jan '11

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-498, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-02.html The updated RIPE Document is ripe-509 and is available at: http://ripe.net/ripe/docs/ripe-509.html Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 06 Jan '11

06 Jan '11

Dear Colleagues, The RIPE NCC received the following AS Number Blocks from the IANA in January 2011. 56320-57343 57344-58367 197632-198655 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0

2010-10 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion)
by Emilio Madaio 17 Dec '10

17 Dec '10

Dear Colleagues, A new version for the Global Policy Proposal has been presented at the RIPE 61 meeting in Rome. The new text has been produced and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-05.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 12 January 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 1