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

WG: Re: 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)
by alexander.brinkmann＠kaufland.com 26 May '15

26 May '15

Hi all, I support this proposal, too, Thanks John Mit freundlichen Grüßen / Best Regards Alexander Brinkmann Tel.: +49 7132 949665 Fax: +49 7132 9479665 EMail: alexander.brinkmann(a)kaufland.com KI 967850 IT International / IT Governance / Netzwerk Design und IT-Sicherheit Office: Haller Straße 60 74189 Weinsberg http://www.kaufland.de http://www.spannende-it.de Kaufland Informationssysteme GmbH & Co. KG Postfach 12 53 - 74149 Neckarsulm Kommanditgesellschaft Sitz: Neckarsulm Registergericht: Stuttgart HRA 104163 ----- Weitergeleitet von Alexander Brinkmann/IS/KI/KAUFLAND am 26.05.2015 11:36 ----- Von: Carlos Gómez Muñoz <carlosf.gomez(a)seap.minhap.es> An: John.Collins(a)BIT.admin.ch, address-policy-wg(a)ripe.net Kopie: mschmidt(a)ripe.net Datum: 26.05.2015 11:03 Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Gesendet von: "address-policy-wg" <address-policy-wg-bounces(a)ripe.net> I support the proposal with the addition suggested by John. Best regards, Carlos Gómez es.seap Spanish government LIR El 22/05/2015 a las 11:45, John.Collins(a)BIT.admin.ch escribió: > Dear Colleagues, > > On Tue Apr 28 Marco Schmidt wrote: > ------------------------------------------------- > >> A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. >> >> The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-03 >> > > I supported this proposal is a previous post and I still do. However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC. I want to make a suggestion for such "additional aspects". It might make sense that some inclusive evaluation criteria are listed in the policy. This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs. > > I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size) > > -------------------- begin ------------------------------------------ > "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. > > Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation." > -------------------- end -------------------------------------------- > > > Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text): > > number of users, the extent of the organisation's infrastructure > ---------------------------------------------------------------------------------- > This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans. It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses. The more users and the bigger the infrastructure, the more address are needed. > > hierarchical and geographic structuring > ---------------------------------------------------- > Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects. > > the segmentation of infrastructure for security > ------------------------------------------------------------ > Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery. > > planned longevity of allocation > ---------------------------------------- > Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation. I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation. As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc. > > > Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. > > And thank you very much for reading this far! > > Best Regards, > John > > >

1 0

New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region
by Mirjam Kuehne 21 May '15

21 May '15

Dear colleagues, Now that the RIPE NCC has reached its last /8, some Local Internet Registries (LIRs) are choosing to obtain additional address space from other organisations via the emerging transfer market. In this new article on RIPE Labs we examine statistics from the last two and a half years of transfers and visualise per country aggregates on a map: https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-servic… Kind regards, Mirjam Kuehne RIPE NCC

10 9

Re: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)
by David Huberman 20 May '15

20 May '15

Some data from the ARIN region, courtesy of Richard Jimmerson of ARIN: For the last several years ARIN has been registering AS numbers by issuing the lowest AS number we have in inventory to approved organizations. We ask those organizations if they would be willing to accept an AS number higher in the number range, and outside of the range that previously made up the 2-byte only AS number space. In 2014 we found that nearly 27% of the organizations approved for an AS number elected to receive a 4-byte AS number rather than take the lowest AS number in our inventory. Several organizations unwilling to receive a 4-byte AS number have indicated to ARIN that their transit providers strongly state a preference that their customers use AS numbers from the traditional 2-byte AS number range. More recently, because of a lack of 2-byte AS numbers in the ARIN inventory, the AS number assignments we make are 4-byte AS numbers and outside of the range that previously made up the 2-byte only AS number space. For those organizations who come back to ARIN specifically stating a preference for a 2-byte AS number, we may be able to continue satisfying their requests using AS numbers that have recently been added to the ARIN AS number inventory through returns or revocations. Very recently ARIN received a new assignment of AS numbers from the IANA. Roughly 90 of those were from the 2-byte range. In 2014 there were 12 organizations that elected to receive a 4-byte AS number and later came back to ARIN to exchange it for a 2-byte AS number. Each of these organizations stated issues with their transit providers either unwilling or unable to accept the use of a 4-byte AS number by a customer. 2014 total AS numbers issued: 1,579 2014 4-byte AS numbers issued: 416 2014 2-byte AS numbers issued: 1,163 David R Huberman Principal, Global IP Addressing Microsoft Corporation

4 4

2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 20 May '15

20 May '15

Dear colleagues, The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC

10 15

<off-topic> RE: 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)
by Erik Bais 17 May '15

17 May '15

Hi Randy, > i really missed being there > we can blame serge, who shifted the meeting left one week from it's > traditional time, and thus conflicted with our tenth wedding anniversary :) You can't blame Serge for your poor planning in a wedding date ... You knew 10 years ago that there is a RIPE meeting in may ;) Congratz btw ;-) Erik

2 1

2015-02 Impact Analysis will be produced (Keep IPv6 PI When Requesting IPv6 Allocation)
by Marco Schmidt 14 May '15

14 May '15

Dear colleagues, The discussion period for the proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation" has ended. The RIPE NCC Impact Analysis will now be prepared for review. We will publish the document shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 14 May '15

14 May '15

Dear colleagues, A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 27 May 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

15 30

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)
by Sander Steffann 13 May '15

13 May '15

Hi, > A good point and one that hadn't occurred to me. If this was to > be interpreted as "must make assignments", would this proposal > even be necessary? Everyone receiving resources and immediately > transferring them would be in violation of the policy and, > strictly speaking, all transfers of this kind that have already > happened would be invalid? My argument was mainly to point out that this behaviour is against the spirit of the policy, in response to: > So, yes, an assumption that one can join the NCC now and get a /22 with the intent to "sell" it is reasonable. But yes, if no assignments happened at all I agree that the allocation would not be according to policy. However, people trying to cheat the system could just make fake assignments for a short period of time and then they would strictly speaking comply with the policy. They would still be dishonest though, which is why I feel that we shouldn't take this practice into account when writing new policy. If you want to look up the history of this, here is the message from Tore when he introduced that line in the policy: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/00815… Cheers, Sander

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 45, Issue 8
by Callum Stuart 12 May '15

12 May '15

Someone has made the comments on this article from ripe labs. Any comments from the community? How can this kind of thing happen in the ripe? Prior to the ripe depletion, it is even hard for my org to apply for a /19. Now my org can only apply for a /22! So as to keep low profile to have Lu Heng’s IPs sold. He had created another shell named Wuhan Yunwaiheng Information Technology Co., Ltd registered in Wuhan, Hubei Province of China ( its Chinese name is:武汉云外恒信息技术有限公司). And then have his IPs sold under this new shell without attracting too much attentions from the RIPE community. He has earned more than 4millions USD for selling his IPs. By the way, cos of this business structure, he can avoid heaps of taxes which should be paid to Netherland Gov and Overseas Gov. Rijksuniversiteit Groningen ( this is where Lu heng graduated) 31.201.0.0/16 2011-04-28 PA SOLD AS35916 (US） 37.222.0.0/15 PA SOLD AS16276 （ovh, France） ;AS35916 46.136.0.0/16 PA SOLD AS8312（kpn Netherland）;AS35916 5.132.0.0/16 2012-07-12 PA ( Split for sales） /17 left for future sale AS35916 5.224.0.0/15 2012-09-06 SOLD AS35916 178.236.224.0/20 PA Still available for Sale AS16276 Lu Heng still has /17 +/20 left available for Sale in RIPE and one aggregated Afrinic 154.80.0.0/12 ( Currently in Rental business). The Business structure of OutsideHeaven: The main Body of OutsideHeaven was registered in Tax heaven place ( Netherland). Then come the lower Body OutsideHeaven Hangzhou ( registered in Zhejiang Province of China) and the other lower Body Wuhan Yunwaiheng Information Technology ( registered in Hubei Province of China). Under this kind of structure, the company of Lu Heng has avoided to pay the taxes he should pay to the Chinese Government. His main Body registration info: His shell company’s registration info written in holland language. However, you can use google translate to understand. Please note this company does not pay any tax in Holland and in China. Online inzage uittreksel KvK-nummer 01133738 Deze inschrijving valt onder beheer van Kamer van Koophandel Noord-Nederland Onderneming Handelsnamen OutsideHeaven AnytimeChinese Voor Altijd Rechtsvorm Eenmanszaak Startdatum onderneming 26-06-2008 Activiteiten SBI-code: 620102 - Ontwikkelen en produceren van maatwerksoftware SBI-code: 6203 - Beheer van computerfaciliteiten Werkzame personen 0 Vestiging Vestigingsnummer 000005125421 Handelsnamen OutsideHeaven AnytimeChinese Voor Altijd Bezoekadres Esdoornlaan 656, 9741MH Groningen Telefoonnummer 0641734323 Internetadressen www.anytimechinese.com (http://www.anytimechinese.com) www.anytimechinese.net (http://www.anytimechinese.net) E-mailadres info(a)anytimechinese.com (mailto:info@anytimechinese.com) Datum vestiging 26-06-2008 Activiteiten SBI-code: 620102 - Ontwikkelen en produceren van maatwerksoftware SBI-code: 6203 - Beheer van computerfaciliteiten Webdesign. Het exploiteren van een informatieve website. Het geven van informatie over China aan ondernemers. De export van online gamecards. Het beheren van computernetwerken. ICT dienstverlening. Beheren van ICT infrastructuur. Werkzame personen 0 Eigenaar Naam Lu, Heng Geboortedatum en -plaats 01-09-1988, Onbekend, China Adres Esdoornlaan 656, 9741MH Groningen Datum in functie 26-06-2008 One of His Chinese Dummy Corporation named 杭州云外恒网络技术有限公司 in Chinese／English name: outside heaven If you look at its websites, there is no update since 2013 http://www.outsideheaven.com/zh-cn/news You can search the company registration info via link http://122.224.75.235:7082/wsdjpt/ The other of his Chinese Dummy Corporation named Wuhan Yunwaiheng Information Technology Co., Ltd registered in Wuhan, Hubei Province of China ( its Chinese name is:武汉云外恒信息技术有限公司) You can search the company registration info via link http://gssoso.whhd.gov.cn/dhb/index.html Ironically, a Clever Chinese guy without “Euro blood” can be "smart Enough" to have as many RIPE IPs as he can. On Saturday, May 9, 2015 at 2:55 AM, address-policy-wg-request(a)ripe.net (mailto:address-policy-wg-request@ripe.net) wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net (mailto:address-policy-wg@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 (mailto:address-policy-wg-request@ripe.net) > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net (mailto:address-policy-wg-owner@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: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (Sebastian Wiesinger) > 2. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (remco van mook) > 3. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (Hannigan, Martin) > 4. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (Michele Neylon - Blacknight) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 May 2015 13:54:14 +0200 > From: Sebastian Wiesinger <sebastian(a)karotte.org (mailto:sebastian@karotte.org)> > To: address-policy-wg(a)ripe.net (mailto:address-policy-wg@ripe.net) > Subject: Re: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in > the RIPE NCC Service Region > Message-ID: <20150508115414.GA23553(a)danton.fire-world.de (mailto:20150508115414.GA23553@danton.fire-world.de)> > Content-Type: text/plain; charset="utf-8" > > * Dan L?dtke <mail(a)danrl.de (mailto:mail@danrl.de)> [2015-05-08 11:33]: > > See, we can not win this games. Let?s stop wasting energy and > > resources on dealing with legacy IP and how to make it work for a > > bit longer. New entrants are entering are market that is not fair, > > and we can not make a real difference. The only way forward is to > > push IPv6 and restore a healthy climate regarding the availability > > of IP addresses. > > > > > Dan, > > if you don't want to invest your time trying to make this market more > fair by all means go ahead and do something else. There are still > people here who would like to try so that new players can enter a > market that will be dominated by IPv4 for some time to come. > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > it will still be around for some time. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant >

4 3

Re: [address-policy-wg] mesh / community networks? 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)
by William Waites 11 May '15

11 May '15

Hi Vesna! Nice to hear from you. You say that this is about governmental networks but that is not actually mentioned in the proposal itself. If you are correct then the proposal should be changed to explicitly mention that. If you are not correct then this just leaves more discretion to RIPE, which is fine -- I've always found the NCC to be rational and reasonable. For an organisation like HUBS which has small but autonomous member networks and a /29, we basically do: 2a04:5d00::/32 -- pool for /64 networks with /44 allocated to each member. 2a04:5d01::/32 -- pool for /48 networks with /40 allocated to each member (currently unused!). 2a04:5d02::/32 -- reserved. 2a04:5d03::/32 -- reserved. 2a04:5d04::/32 -- experimental 2a04:5d05::/32 -- reserved. 2a04:5d06::/32 -- reserved. 2a04:5d07::/32 -- reserved. In a country with 5 million population -- even several times that -- this ought to be plenty. If we need more I would expect to have to justify it! This does not really bear on DFZ routing table size unless there is a global policy on the horizon that will forbid announcing /44 or /40 networks i.e. when one of our members becomes multi-homed. The current policy says, "If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure." Deleting this is ok. Also ok would be substituting "extent and structure" for "extent". Without knowing any better I would have interpreted this as giving equal weight to number of users and topology. If you have a lot of users you get a big allocation. If your topology justifies you get a big allocation. So it may actually be that we don't even need a new policy, just more clarity on the interpretation. Cheers, -w On Mon, 11 May 2015 09:18:15 +0200, Vesna Manojlovic <BECHA(a)ripe.net> said: > Hi, there is this policy proposal (below) that is going to > change criteria for allocations to _governmental_ / national > networks -- but!! Maybe it can be used for the community > networks too?? > Would you be interested in reading this proposal, and seeing if > it would be sufficient, or are there any modifications possible > to suit your needs? > Now is the time :) > If you have any questions about "policy development process", > please let me know! > In short: you (anyone) can write to the mailing list below, and > say what you think of this proposal - agree, disagree, or how it > could be modified, and why. Then there will be more discussion, > proposal might get changed and finally accepted -- or > refused. If it's accepted, it becomes a new "policy", that is: > rules for allocating IPv6 to LIrs -- or their customers! > Concretely, if "additional aspects" can be expressed in terms > that "participants in mesh network are not countable customers" > and there is no "infrastructure" in the mesh... then maybe this > will work out better for the future community networks. > Thanks, Vesna > -------- Forwarded Message -------- Subject: [staff] > [policy-announce] 2015-03 New Policy Proposal (Assessment > Criteria for IPv6 Initial Allocation Size) Date: Tue, 28 Apr > 2015 14:00:40 +0200 From: Marco Schmidt <mschmidt(a)ripe.net> > Reply-To: address-policy-wg(a)ripe.net To: > policy-announce(a)ripe.net CC: address-policy-wg(a)ripe.net > Dear colleagues, > A proposed change to the RIPE Document "IPv6 Address Allocation > and Assignment Policy" now is open for discussion. > The proposal aims to expand the criteria for evaluating initial > IPv6 allocations larger than a /29. The RIPE NCC would consider > additional aspects beyond only the number of existing users and > extent of the organisation's infrastructure. > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2015-03 > We encourage you to review this proposal and send your comments > to <address-policy-wg(a)ripe.net> before 27 May 2015. > Regards > Marco Schmidt Policy Development Officer RIPE NCC

2 1