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

2012-04 Draft Document and Impact Analysis in the making (PI Assignment from the Last /8)
by Emilio Madaio 23 Aug '12

23 Aug '12

Dear colleagues, As previously announced, the discussion period for the proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has ended. A Draft Policy text and the Impact Analysis were due to move the proposal to Review Phase. While performing the Impact Analysis, RIPE NCC staff have identified a number of additional points to review in light of past discussions relating to IP address management and overall RIPE NCC membership. Therefore, in agreement with the Address Policy Working Group Co-chairs and the author of the proposal, we have decided to invest some more time in the analysis. The RIPE NCC will publish all relevant documentation in the coming weeks, and the proposal will move to the Review Phase prior to the RIPE 65 Meeting. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-04 Apologies for any inconvenience Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

RIPE65 - Agenda, first draft
by Gert Doering 14 Aug '12

14 Aug '12

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following two time slots: Thursday, Sep 27, 09:00 - 10:30 Thursday, Sep 27, 11:00 - 12: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. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Thursday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Emilio Madaio - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE64 - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Alex le Heux F. Discussion of open policy proposals 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space 2012-03 Intra-RIR transfer policy proposal 2012-04 (IPv4) PI assignments from the last /8 2012-05 Transparency in Address Block Transfers <new> IPv6 PA/PI unification proposal ---------------------------------------------------------------------- Thursday, 11:00-12:30 ---------------------------------------------------------------------- G. Discussion of open policy proposals (continued) H. IPv4 maintenance policy - Rob Blokzijl (bring topic back into people's minds, agree on next steps) 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." Z. AOB

1 0

Policy/practice on holding back space before reallocation?
by Heather Schiller 13 Aug '12

13 Aug '12

I have not been able to find this info on RIPE's website. Does anyone know the amount of time RIPE holds back a 'deregistered number resource' before allocating it? I found this document that describes the deregistration process for a resource holder: https://www.ripe.net/ripe/docs/ripe-517 In general it gives the resource holder 4 weeks to object and 3 months to remediate. It does not describe how long RIPE will hold back deregistered IP's before allocating them out again. For example, ARIN used to hold back for one year.. they recently announced they were preparing to drop from 6 months hold to 3 months hold - here is the announcement: https://www.arin.net/announcements/2012/20120717.html It's way down 3rd paragraph from the end. "One last change relates to the amount of time that ARIN will hold recovered IPv4 resources prior to reissuance. The hold time for all returned, reclaimed and revoked IPv4 resources will be reduced from six to three months." Does RIPE have a similar practice. Thanks, --Heather

1 0

2011-04 Implementation: Extension of the Minimum Size for IPv6 Initial Allocation
by Ioanna Spyroulia 09 Aug '12

09 Aug '12

[Apologies for duplicate emails] Dear colleagues, We have now completed the implementation of the accepted policy proposal 2011-04, "Extension of the Minimum Size for an IPv6 Allocation". RIPE NCC members who would like to extend an IPv6 allocation can submit the IPv6 Additional Allocation Request Form via the LIR Portal, or email it to<hostmaster(a)ripe.net>. You can find the IPv6 Additional Allocation Request Form at: https://www.ripe.net/ripe/docs/ripe-560 You can find the Supporting Notes for the IPv6 Additional Allocation Request Form at: https://www.ripe.net/ripe/docs/ripe-561 More information about IPv6 allocations is available at: http://www.ripe.net/lir-services/resource-management/faq/faq-ipv6 -- Kind Regards Ioanna Spyroulia IP Resource Analyst RIPE Network Coordination Centre Phone:+31 20 535 4444 Fax:+31 20 535 4445

3 3

Re: [address-policy-wg] Transparency in Address Block Transfers
by sandrabrown＠ipv4marketgroup.com 06 Aug '12

06 Aug '12

I support Milton Mueller's proposal to publish a record of transfers within the RIPE NCC. This will show RIPE participants the success (or failure) of transfer markets so we will know whether adjustments to the transfers processes need to be made. It will also, once Inter-RIR transfers are in place (Looking for support for Proposal 2012-02), show whether RIPE based constituents are using and needing to transfer IP's from and to other Regions. Sandra Brown IPv4 Market Group ---------------------------------------------------------------------- Message: 1 Date: Fri, 03 Aug 2012 14:35:28 +0200 From: "Emilio Madaio" <emadaio(a)ripe.net> Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) To: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Message-ID: <mailman.2.1344074403.18903.address-policy-wg(a)ripe.net> Dear Colleagues, The draft document for the proposal described in 2012-05, "Transparency in Address Block Transfers", has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-05 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 31 August 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC End of address-policy-wg Digest, Vol 12, Issue 1 ************************************************

1 0

2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers)
by Emilio Madaio 03 Aug '12

03 Aug '12

Dear Colleagues, The draft document for the proposal described in 2012-05, "Transparency in Address Block Transfers", has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-05 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 31 August 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2012-04 Draft Document and Impact Analysis will be produced (PI Assignments from the last /8)
by Emilio Madaio 26 Jul '12

26 Jul '12

Dear Colleagues The discussion period for the proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-04 Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2012-05 Draft Document will be produced (Transparency in Address Block Transfers)
by Emilio Madaio 25 Jul '12

25 Jul '12

Dear Colleagues, The discussion period for the proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-05 Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Transfer of Internet Number Resource Records and Change of a Member’s Official Legal Name - Draft Document
by Axel Pawlik 16 Jul '12

16 Jul '12

Dear colleagues, The RIPE NCC has created a draft procedural document, “Transfer of Internet Number Resource Records and Change of a Member’s Official Legal Name”. A PDF of the document is available at: http://www.ripe.net/lir-services/ncc/legal/Transferofrecords_namechange.v20… The draft document refers to the current procedures the RIPE NCC follows in order to maintain an accurate registry in the case of changes regarding: - The Internet number resource records that are registered to a person; or - The official name of the person holding a registration of Internet number resources The procedures were originally discussed at the RIPE 62 Meeting in Amsterdam. The text of this document is intended to replace relevant sections of ripe-515, “Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR”. The original RIPE Document is available at: https://www.ripe.net/ripe/docs/ripe-515 The RIPE NCC would like to receive feedback on this draft document from its members and the RIPE community. Based on this feedback, the RIPE NCC Executive Board will decide on a final version of the document. If you would like to give feedback on the document, please email the RIPE NCC Services Working Group mailing list at <ncc-services-wg(a)ripe.net>. Kind regards, Axel Pawlik Managing Director RIPE NCC

1 0

Special Use IPv4 Addresses: Draft RFC Best Current Practice Document
by Axel Pawlik 16 Jul '12

16 Jul '12

Dear colleagues, The IETF has issued a last call for comments on the draft RFC "Special Use IPv4 Addresses", Best Current Practice document. The document is available at: http://datatracker.ietf.org/doc/draft-vegoda-cotton-rfc5735bis/ The Last Call period concludes on 9 August 2012. The IETF requests that substantive comments should be sent to <ietf(a)ietf.org> by this date. The abstract describing the proposed RFC is as follows: This document obsoletes RFC 5735 and updates RFC 6441. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. We ask that you read the document and send any comments you might have to the appropriate channel within the Last Call period. Best regards, Axel Pawlik Managing Director RIPE NCC

1 0

011-04 Implementation: Extension of the Minimum Size for IPv6 Initial Allocation
by Alex Le Heux 09 Jul '12

09 Jul '12

Dear colleagues, The RIPE NCC has received a significant amount of requests following the RIPE community's recent acceptance of 2011-04, "Extension of the Minimum Size for an IPv6 Allocation". In order to process these requests under this new policy, we must adapt our internal infrastructure and produce the necessary request forms and documentation. We will have these posted to our website shortly. In the meantime, as of Monday, 9 July 2012, we will process requests for extensions to IPv6 allocations under section 5.7 of the IPv6 Address Policy. RIPE NCC members that would like to apply under this policy should email <lir-help(a)ripe.net> for the time being. Kind regards, Alex Le Heux Policy Implementation and Coordination RIPE NCC

1 0

APWG RIPE 64 draft minutes - now online
by Gert Doering 28 Jun '12

28 Jun '12

Dear Working Group, the draft minutes from RIPE 64 are now online at: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-64 (a big thanks to the good people at the RIPE NCC for this) If there is anything that you miss, or remember differently, please let us know to get it corrected. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? 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 0

2012-04 Discussion Period extended until 19 July (PI Assignments from the last /8)
by Emilio Madaio 21 Jun '12

21 Jun '12

Dear Colleagues, The text of the policy proposal 2012-04, "PI Assignments from the last /8", has been revised. We have published the new version (version 2.0) today. As a result a new Discussion Phase is set for the proposal. Highlights of the changes in version 2.0 are: -added clause 4 to section 5.6.2 You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-04 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net> before 19 July. Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-04 Implementation: Extension of the Minimum Size for IPv6 Initial Allocation
by Ioanna Spyroulia 11 Jun '12

11 Jun '12

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC has started the implementation of the accepted RIPE Policy Proposal 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation". We expect that by the end of July we will be ready to: - Extend an IPv6 /32 allocation up to a /29 - Issue an initial IPv6 allocation up to a /29 We will inform you about further details of the implementation closer to the date. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-04 The updated RIPE Document is ripe-552 and is available at: http://ripe.net/ripe/docs/ripe-552.html If you have any comments or questions, please contact <lir-help(a)ripe.net>. -- Kind Regards Ioanna Spyroulia RIPE Network Coordination Centre Phone:+31 20 535 4444 Fax:+31 20 535 4445

1 0

Last 4 Days: GreeNets 2012: October 24-26, 2012 - Gandia, Spain
by Sandra Sendra 06 Jun '12

06 Jun '12

==================================================================================== 2nd International Conference on Green Communications and Networking - GreeNets 2012 24th and 26th October 2012 Gandia, Spain http://greenets.org/ ==================================================================================== HIGHLIGHTS - The event is endorsed by the European Alliance for Innovation (www.eai.eu), a leading community-based organisation devoted to the advancement of innovation in the field of ICT - All accepted papers will be published by Springer and made available through SpringerLink Digital Library, one of the world's largest scientific libraries - Proceedings will be submitted for indexing by Google Scholar, ISI, EI Compendex, Scopus and many more - Best papers will be selected to be included in one of the special issues that will be published in: Future Internet, Network Protocols and Algorithms, Recent Patent in Telecommunications CALL FOR PAPERS [Scope] Global warming and climate change have been a growing worldwide concern. Six sources, i.e., transportation, power, buildings, industry, agriculture and forestry, and land use, have been identified as major contributors to the rise of global carbon dioxide (CO2). The mobile industry is seen as a potential enabler to reduce greenhouse gases contributed by these six sources provided that appropriate measures are implemented. On the other hand, the mobile industry itself will also contribute to CO2 emission through network operations, mobile equipments, etc. To meet the requirement of low-carbon economy development, it is necessary to reduce the operation expenditure or energy consumption of mobile networks, while maintaining acceptable quality of service. This conference will explore and explain the scope and challenges of designing, building, and deploying GreeNets. In this regard, the conference aims to establish a forum to bring together research professionals from diverse fields including green mobile networks, system architectures, networking & communication protocols, applications, test-bed and prototype, traffic balance and energy-efficient cooperation transmission, system and application issues related to GreeNets. [Topics] The conference invites original technical papers that were not previously published and are not currently under review for publication elsewhere. Topics include, but are not limited to: - Communications and Networking: Communication techniques and protocols for GreeNets Energy-efficient transmission technologies based on the cooperation communication Scalable and flexible energy efficiency mobile network architectures, deployments, and applications - Energy-efficient network architecture & protocols: Scalability and mobility issues in energy efficiency cross-layer design MAC Protocols and QoS Designing for mobile networks - Systems and Technology: Transactions and workflows in green mobile networks Adaptability and stability of green mobile networks Mobile and multimedia supported green mobile networks Experimental and test bed studies for energy efficiency mobile networks, simulation tools - Energy-efficient management: Energy-efficient traffic balance, cooperation and management Distributed energy efficiency resource management techniques Protocols for cooperative management and control [Publications] Accepted papers will be published in Springer's LNICST series and will appear in the SpringerLink, one of the largest digital libraries online that covers a variety of scientific disciplines, as well as in the ICST's own EU Digital Library (EUDL). LNICST volumes are submitted for inclusion to leading indexing services, including DBLP, Google Scholar, ACM Digital Library, ISI Proceedings, EI Engineering Index, CrossRef, Scopus. [Special Issues] Best papers will be selected to be included in one of the special issues that will be published in: Future Internet (ISSN 1999-5903) Network Protocols and Algorithms (ISSN 1 943-3581) Recent Patent in Telecommunications (ISSN: 2211-7407 (Print) ISSN: 2211-7415 (Online)) [Paper submission] All the papers formatted according with the instructions have to be submitted through the conference online system at: http://greenets.org/submission.shtml [Important dates] Abstract Submission Deadline: June 10, 2012 Full Paper Deadline: June 10, 2012 Notification of Acceptance: July 6, 2012 Camera-ready: August 11, 2012 Conference dates: 24th - 26th October 2012 [Conference organizing committees] General Co-Chairs: Jaime Lloret, Universidad Politecnica de Valencia, Spain Joel Rodrigues, Institute of Telecommunications, University of Beira Interior, Portugal TPC Co-Chairs: Liang Zhou, Nanjing University of Posts and Telcommunications, China Eduardo Nakamura, Federal Univ. of Amazonas, Brazil Industry Track Chair: Jose Maria Alcaraz Calero, Hewlett Packard Laboratories, Bristol, UK Workshop Chair: Javier Aguiar, University of Valladolid, Spain Special Session Chair: Jose Soler, Danmarks Tekniske Universitet, Denmark Vivek S. Deshpande, MIT College of Engineering, Pune, India Panel Chair: A.v. Senthil Kumar, HINDUSTHAN College of Arts & Science, India Posters Chair: Kayhan Zrar Ghafoor, Universiti Teknologi Malaysia, Malaysia Local Co-Chairs: Diana Bri, Universidad Politecncia de Valencia, Spain Miguel Garcia, Universidad Politecncia de Valencia, Spain Publicity Chairs: Sandra Sendra, Univ. Politecnica de Valencia, Spain Min Chen, Seoul National University, Korea Web Chair: Alejandro Canovas, Universidad Politecncia de Valencia, Spain Steering Committee: Athanasios Vasilakos, National Technical University of Athens (NTUA), Greece Imrich Chlamtac, Creat-Net, Italy ABOUT EAI The European Alliance for Innovation is a dynamic eco-system for fostering ICT enabled innovation to improve European competitiveness and to benefit society. EAI uses open e-platforms to inspire grassroots collaboration among all relevant actors, from organizations to individuals, to stimulate community driven innovation to its institutional and individual members worldwide. Through EAI, organizations find ideas and talent, and individual innovators find organizations for their ingenuity and craft. Join the innovation community at www.eai.eu UNSUBSCRIBE If you believed you have received this email in error, or do not want to receive emails from us in the future, please send an email to unsubscribe(a)eai.eu.

1 0

Re: [address-policy-wg] [policy-announce] 2012-05 New Policy Proposal (Transparency in Address Block Transfers)
by Richard Hartmann 05 Jun '12

05 Jun '12

I agree with this proposal. Monthly or anything more rapid, I don't care; still vote +1. Richard

1 0

Re: [address-policy-wg] [policy-announce] 2012-05 New Policy
by Octavio Alfageme 05 Jun '12

05 Jun '12

Dear all, First of all, sorry if this question was already addressed in the past, but I find a gap between the policy proposal and IPv4 market dynamics. According to the proposal, transfer would be approved if the receiving LIR fulfills requirements of Section 5.3 Additional Allocations. I personally agree with this requirement, but my doubt is how coherent it is with a real market scenario. A LIR selling an allocation would look for the best offer, regardless of the IPv4 allocation status with respect to Section 5.3 requirements of the purchasing LIR. Which would be the situation of a LIR acquiring IPv4 address blocks but unable to fulfill transfer requirements? Which would be the way to solve this situation? Kind regards Octavio Alfageme

2 1

Re: [address-policy-wg] [policy-announce] 2012-05 New Policy Proposal (Transparency in Address Block Transfers)
by Dan Luedtke 04 Jun '12

04 Jun '12

> The list will be updated monthly In periods of heavy transfers, this might be a little to slow. Is weekly an option? Does it create more work for RIPE NCC or will the list be auto-generated anyway? Can someone in favor of monthly updates clarify why monthly was chosen? Regards Dan -- Dan Luedtke http://www.danrl.de

2 1

2012-05 New Policy Proposal (Transparency in Address Block Transfers)
by Emilio Madaio 04 Jun '12

04 Jun '12

Dear Colleagues, A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-05 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 2 July 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-05 Proposal Accepted (Safeguarding future IXPs with IPv4 space)
by Emilio Madaio 01 Jun '12

01 Jun '12

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-530, "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: https://www.ripe.net/ripe/policies/proposals/2011-05 The updated RIPE Document is ripe-553 and is available at: http://ripe.net/ripe/docs/ripe-553.html Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-04 Proposal Accepted (Extension of the Minimum Size for IPv6 Initial Allocation)
by Emilio Madaio 31 May '12

31 May '12

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-545 has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-04 The updated RIPE Document is ripe-552 and is available at: http://ripe.net/ripe/docs/ripe-552.html Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

New on RIPE Labs: IPv4 still business as usual
by Mirjam Kuehne 30 May '12

30 May '12

Dear colleagues, In anticipation of reaching the last /8 of IPv4 addresses in the RIPE NCC service region, we have been looking at the number of IPv4 addresses the RIPE NCC handed out over the last four years. The curves look surprisingly uniform. Please read more on RIPE Labs: https://labs.ripe.net/Members/dfk/ipv4-business-as-usual Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Any-cast or uni-cast solutions
by Lu Heng 29 May '12

29 May '12

Hi Sorry for disturbing. I have one question which I didn't find answer in the policy document. I was wondering how any-cast or uni-cast solution works with cross region possibilities. If we announcing 1.1.1.0/16 in EU, and announcing 1.1.1.0/18 in US, is it against policy? If we announcing 1.1.1.0/16 both in EU and US, is it against policy?(all IP from Ripe) Please if someone can help me clarify this. -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received.

17 46

Re: [address-policy-wg] address-policy-wg Digest, Vol 9, Issue 17
by Lu Heng 24 May '12

24 May '12

Dear Ingrid: Thanks for replying. So is that to speaking: As long as the need is inside the region, part of the infrastructure(CDN network for example) with the IP address can be announced outside of Ripe service region(as I see many are doing that). Am I correct? On Wed, May 23, 2012 at 5:17 PM, <address-policy-wg-request(a)ripe.net> wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Any-cast or uni-cast solutions (Tore Anderson) > 2. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) > 3. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) > 4. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) > 5. Re: Assignment transfer among LIR (Shane Kerr) > 6. Re: Assignment transfer among LIR (Pascal Gloor) > 7. Re: Assignment transfer among LIR (Jan Zorz @ go6.si) > 8. Re: Any-cast or uni-cast solutions (Randy Bush) > 9. Re: Any-cast or uni-cast solutions (Ingrid Wijte) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 May 2012 12:01:13 +0200 > From: Tore Anderson <tore.anderson(a)redpill-linpro.com> > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: Ingrid Wijte <ingrid(a)ripe.net> > Cc: address-policy-wg(a)ripe.net > Message-ID: <4FBCB569.5060204(a)redpill-linpro.com> > Content-Type: text/plain; charset=ISO-8859-1 > > * Ingrid Wijte > >> I would like to give some further clarification on this. >> >> The RIPE NCC allocates/assigns address space to organisations who have a >> need in the RIPE NCC service region. The address space must be >> originated from the RIPE NCC service region. Due to the diverse nature >> of businesses, in addition to this there can be announcements from other >> regions. > > Just to make 110% certain, you're saying here that it is the *need* that > must be in the RIPE region, not the *organisation*, correct? > > Example 1: China Unicom sets up a legal organisation in the Netherlands, > joins the NCC, and requests an allocation from which they intend to > assign addresses to broadband customers in China. They intend to > advertise the allocated prefix(es) to peers at AMS-IX (as well as from > other exchange points around the world). > > Example 2: I, representing an existing LIR in the RIPE region, build a > data center in Australia and set up a server hosting business there. I > want to make an assignment to a new customer in this data center from my > IPv4 allocation received from the RIPE NCC, and request that from the > NCC hostmater using a ripe-488 form. > > Assuming all the documentation is otherwise in order and the need is > real, will these requests be granted or denied? > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > > > > ------------------------------ > > Message: 2 > Date: Wed, 23 May 2012 12:03:28 +0200 > From: "Jan Zorz @ go6.si" <jan(a)go6.si> > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg(a)ripe.net > Message-ID: <4FBCB5F0.4050009(a)go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 10:28 AM, Randy Bush wrote: >>> You can announce them anywhere you like. But you cannot assign them to >>> end users outside outside of the region. >> >> really? so i have a /16 from ncc and i spread it over pops in ams, lon, >> and nyc, but i can not have bgp-speaking customers in that address space >> in nyc? if true, that is soooo broken. > > +1 > > (I just saw upfront that comment coming in :) :) :) ) > > Jan > > > > ------------------------------ > > Message: 3 > Date: Wed, 23 May 2012 12:11:36 +0200 > From: "Jan Zorz @ go6.si" <jan(a)go6.si> > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg(a)ripe.net > Message-ID: <4FBCB7D8.5090903(a)go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 12:01 PM, Tore Anderson wrote: >> Example 1: China Unicom sets up a legal organisation in the Netherlands, >> joins the NCC, and requests an allocation from which they intend to >> assign addresses to broadband customers in China. They intend to >> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >> other exchange points around the world). > > They could also say during the initial alloc process that they'll > allocate this resources to potential customers in RIPE-NCC region and > the use it elsewhere. Just saying... > >> >> Example 2: I, representing an existing LIR in the RIPE region, build a >> data center in Australia and set up a server hosting business there. I >> want to make an assignment to a new customer in this data center from my >> IPv4 allocation received from the RIPE NCC, and request that from the >> NCC hostmater using a ripe-488 form. >> >> Assuming all the documentation is otherwise in order and the need is >> real, will these requests be granted or denied? > > good questions, wonder what the answers will be :) > > Cheers, Jan > > > > ------------------------------ > > Message: 4 > Date: Wed, 23 May 2012 12:12:48 +0200 > From: "Jan Zorz @ go6.si" <jan(a)go6.si> > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg(a)ripe.net > Message-ID: <4FBCB820.2020704(a)go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 10:59 AM, Tore Anderson wrote: >> If on the other hand out-of-region assignments are valid and allowed, I >> cannot fathom why those fast growing ISPs in China, India, Vietnam and >> so on that were allocating IPv4 addresses from APNIC at an incredible >> rate right up until the day APNIC hit the /8 have not simply set up >> legal organisations in the RIPE region, joined the NCC, and continued >> allocating from here in more or less the same rate as before APNIC ran out. > > Maybe those IPv4-hungry operators are just not aware of this "option" ;) > > Jan > > > > ------------------------------ > > Message: 5 > Date: Wed, 23 May 2012 13:11:54 +0200 > From: Shane Kerr <shane(a)time-travellers.org> > Subject: Re: [address-policy-wg] Assignment transfer among LIR > To: Pascal Gloor <pascal.gloor(a)finecom.ch> > Cc: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> > Message-ID: > <20120523131154.55f5f50d(a)shane-eeepc.home.time-travellers.org> > Content-Type: text/plain; charset=US-ASCII > > Pascal, > > On Tuesday, 2012-05-22 16:26:50 +0000, > Pascal Gloor <pascal.gloor(a)finecom.ch> wrote: >> >IOW, I don't see any clear solutions to this problem for existing >> >contracts. >> >> To be honest, me neither, but I wanted some community feedback to see >> if there would be a solution I didn't think of. > > In my mind, this is the MAIN problem with IPv4 exhaustion. Anyone who > got IPv4 address before exhaustion can provide services, anyone else > cannot. > > Think back to the Internet in 1990 and where it would be today if the > phone companies held all of the IPv4 space and you had to go through > them for all connectivity. > > While James Blessing's "use IPv6" suggestion is perhaps not easy, it's > the best answer we have. :( > > -- > Shane > > > > ------------------------------ > > Message: 6 > Date: Wed, 23 May 2012 12:30:17 +0000 > From: Pascal Gloor <pascal.gloor(a)finecom.ch> > Subject: Re: [address-policy-wg] Assignment transfer among LIR > To: "Jan Zorz @ go6.si" <jan(a)go6.si>, "address-policy-wg(a)ripe.net" > <address-policy-wg(a)ripe.net> > Message-ID: <CBE2A372.25BDA%pascal.gloor(a)finecom.ch> > Content-Type: text/plain; charset="us-ascii" > >>Why moving elswhere then? > > It's the other way around. We are the wholesale cable provider and this > might be an issue to gain new customers if they don't have IPs and can't > have them from us. > > > Pascal > > > > > > > ------------------------------ > > Message: 7 > Date: Wed, 23 May 2012 14:57:02 +0200 > From: "Jan Zorz @ go6.si" <jan(a)go6.si> > Subject: Re: [address-policy-wg] Assignment transfer among LIR > To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> > Message-ID: <4FBCDE9E.9050604(a)go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 2:30 PM, Pascal Gloor wrote: >>> Why moving elswhere then? >> >> It's the other way around. We are the wholesale cable provider and this >> might be an issue to gain new customers if they don't have IPs and can't >> have them from us. > > I think you nailed it. > > So it's not the fairness and competitiveness issue but purely lack of > resources and IPv4 depletion that is beating your business up (and not > just yours). > > You have several ways out, as already pointed in this discussion: > > - Big evil CGN > - A bit less evil A+P derivates (MAP, 4RD, etc) - when they become available > - IPv6 with NAT64/DNS64 in the core > > Pick your poison :) > > Cheers, Jan > > > > ------------------------------ > > Message: 8 > Date: Wed, 23 May 2012 22:31:19 +0900 > From: Randy Bush <randy(a)psg.com> > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: Tore Anderson <tore.anderson(a)redpill-linpro.com> > Cc: Sander Steffann <sander(a)steffann.nl>, Lu Heng > <h.lu(a)anytimechinese.com>, address-policy-wg(a)ripe.net > Message-ID: <m2wr439g7s.wl%randy(a)psg.com> > Content-Type: text/plain; charset=ISO-8859-1 > >> That is my understanding, at least. I asked this question to the RIR >> panel at the mic in Rome, whether and APNIC region ISP could (post APNIC >> depletion) set up a LIR in the RIPE region (or any other region), and >> allocate addresses from there and assign them to end users in their home >> region. The answer (which came from Geoff Huston IIRC) was something >> along the lines of ?no, you have to assign the addresses in the service >> region from which they were allocated?. > > you mis-heard > > i am in the apnic region and chaired address policy sig in apnic for > some years. this is not the case. > > randy > > > > ------------------------------ > > Message: 9 > Date: Wed, 23 May 2012 17:17:09 +0200 > From: Ingrid Wijte <ingrid(a)ripe.net> > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg(a)ripe.net > Message-ID: <4FBCFF75.9050708(a)ripe.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Tore, > > On 5/23/12 12:01 PM, Tore Anderson wrote: >> * Ingrid Wijte >> >>> I would like to give some further clarification on this. >>> >>> The RIPE NCC allocates/assigns address space to organisations who have a >>> need in the RIPE NCC service region. The address space must be >>> originated from the RIPE NCC service region. Due to the diverse nature >>> of businesses, in addition to this there can be announcements from other >>> regions. >> Just to make 110% certain, you're saying here that it is the *need* that >> must be in the RIPE region, not the *organisation*, correct? > The need and the route origination must be in the RIPE NCC service region. >> >> Example 1: China Unicom sets up a legal organisation in the Netherlands, >> joins the NCC, and requests an allocation from which they intend to >> assign addresses to broadband customers in China. They intend to >> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >> other exchange points around the world). > This example would be ok for several reasons: > The requestor is a RIPE NCC member. They have infrastructure in the > region and the address space will originate from the RIPE NCC service > region. > Other similar examples would be VPN Providers but also Satellite > providers that are based in the region and have customers globally. >> >> Example 2: I, representing an existing LIR in the RIPE region, build a >> data center in Australia and set up a server hosting business there. I >> want to make an assignment to a new customer in this data center from my >> IPv4 allocation received from the RIPE NCC, and request that from the >> NCC hostmater using a ripe-488 form. > As long as the prefix is originated in the RIPE NCC service region, this > would be approved. The LIR has an allocation, is announcing it in the > RIPE NCC service region, and is making PA assignments to its customers. > > Regards, > > Ingrid Wijte > > Registration Services Assistant Manager > RIPE NCC > >> Assuming all the documentation is otherwise in order and the need is >> real, will these requests be granted or denied? >> >> Best regards, > > > > End of address-policy-wg Digest, Vol 9, Issue 17 > ************************************************ -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received.

2 1

Assignment transfer among LIR
by Pascal Gloor 23 May '12

23 May '12

Dear WG, As a service provider specialized in CATV, we will soon face a competition problem. CATV operators, often, do not operate their IP business, they take these services from a specialized service provider (like us) and therefore the end-users get IP(v4) addresses from that provider. In the future, CATV operators will not be able to change their provider because the new provider will be unable to assign IPv4 space to them. On the other side, there is no need for additional IPs, the CATV operator already has them (from another LIR). If we do not solve this issue, this market will simply and completely freeze, giving way too much power to the 'current' provider (like us) over the CATV operator. I've been thinking a lot about how to solve this issue, so I'll just throw a first pseudo-draft, give me your feedback and we'll make it better. Post-IPv4-Exhaustion customer transfer When a customer changes from LIR A to LIR B: - RIPE NCC will allocate the needed space (out of the 'reserved-for-new-LIR' space) to LIB B, but not larger than the original one. - RIPE NCC will inform LIR A about the transfer and will request the space to be returned. - If LIR A cannot return the space (deaggregation?), RIPE NCC will freeze (how?) it. NOTE: There should maybe be a minimal assignment size for this process, maybe /22. (Why? To avoid a flood of very small assignments transfer requests to RIPE NCC). Let me know what you think, how it can be improved or if you think its BS. Cheers, Pascal

8 18