From dominik at clouvider.co.uk Mon Nov 2 13:16:19 2015 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Mon, 2 Nov 2015 12:16:19 +0000 Subject: [address-policy-wg] 2015-05 Message-ID: Hello, I think that if we are changing the policy in regards to allocations from the Last /8 we should make sure this is not abused. There are many LIRs setup solely for the purpose of getting an allocation from the last /8 to rent this space out. As this space is offered for a very low fee it is often abused and hence artificially increasing the IPv4 depletion. This should not be the case. I think the policy should allow for the subsequent allocations from the last /8, but only if the space is not only not transferred out of the LIR account in the period of 18 months AND the LIR was not renting the space from the last /8 to another entities within the last 18 months period (solely, not as part of another service). What do you think ? Kind Regards, Dominik Clouvider Limited -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Mon Nov 2 14:01:39 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 2 Nov 2015 14:01:39 +0100 Subject: [address-policy-wg] 2015-05 In-Reply-To: References: Message-ID: On Mon, Nov 2, 2015 at 1:16 PM, Dominik Nowacki wrote: > > I think the policy should allow for the subsequent allocations from the > last /8, but only if the space is not only not transferred out of the LIR > account in the period of 18 months AND the LIR was not renting the space > from the last /8 to another entities within the last 18 months period > (solely, not as part of another service). > > > > What do you think ? > How do you propose that RIPE NCC go about acquiring that information and enforcing that regulation? Is there a bit of confusion regarding what a LIR is? https://www.ripe.net/manage-ips-and-asns/resource-management/faq/independent-resources/phase-three/what-is-a-local-internet-registry-lir -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Mon Nov 2 16:04:24 2015 From: rgori at wirem.net (Riccardo Gori) Date: Mon, 2 Nov 2015 16:04:24 +0100 Subject: [address-policy-wg] 2015-05 In-Reply-To: References: Message-ID: <56377B78.7060305@wirem.net> Dear colleagues, I am not supporting this policy. I write this email since I wrote on 20/10 that I like the policy text but I want that my thought about this policy is clear. It does not contain any /something limit (as example /20) already administered by the requesting LIR. I would add some text as follows: [...] 3. The LIR has not reached an address space equivalent to /20 in its registry [...] For the ones asking theirself if I think there is any difference between LIR and LIR someone already asked me this. Yes I think there is. I tought that the /8 policy was designed for new entrants and I can't see any new entrant owning a /21 or /20 or /19 or /16 To me looks slightly differente one old LIR to a new entrant LIR. So that's why different policies, different evaluation criterias and available recources. regards Riccardo -- Riccardo Gori e-mail: rgori at wirem.net WIREM Fiber Revolution - Net-IT s.r.l. Via Emilia Ponente, 1667 47522 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 e-mail: info at wirem.net -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l. via Emilia Ponente, 1667 - 47522 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Mon Nov 2 17:23:21 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 02 Nov 2015 17:23:21 +0100 Subject: [address-policy-wg] 2015-05 In-Reply-To: <56377B78.7060305@wirem.net> References: <56377B78.7060305@wirem.net> Message-ID: <1446481401.1597760.426859097.6F958D83@webmail.messagingengine.com> On Mon, Nov 2, 2015, at 16:04, Riccardo Gori wrote: > It does not contain any /something limit (as example /20) already > administered by the requesting LIR. > I would add some text as follows: > [...] > 3. The LIR has not reached an address space equivalent to /20 in its > registry > [...] IF that is to be done, I'd say that the acceptable limit (from several points of view) may be more /21 rather than /22, i.e. only real new entrants (after 09/2012). That could also be spelled this way. /20 was the initial idea too, but left aside for the first version. Any other optinion on this (other than "global no" or "no, no, no") ? -- Radu-Adrian FEURDEAN fr.ccs From dominik at clouvider.co.uk Mon Nov 2 19:50:57 2015 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Mon, 2 Nov 2015 18:50:57 +0000 Subject: [address-policy-wg] 2015-05 In-Reply-To: <1446481401.1597760.426859097.6F958D83@webmail.messagingengine.com> References: <56377B78.7060305@wirem.net> <1446481401.1597760.426859097.6F958D83@webmail.messagingengine.com> Message-ID: Colleagues, I'd say /21 with review of the policy scheduled within two years. Regards, Dominik -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Radu-Adrian FEURDEAN Sent: 02 November 2015 16:23 To: Riccardo Gori ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2015-05 On Mon, Nov 2, 2015, at 16:04, Riccardo Gori wrote: > It does not contain any /something limit (as example /20) already > administered by the requesting LIR. > I would add some text as follows: > [...] > 3. The LIR has not reached an address space equivalent to /20 in its > registry [...] IF that is to be done, I'd say that the acceptable limit (from several points of view) may be more /21 rather than /22, i.e. only real new entrants (after 09/2012). That could also be spelled this way. /20 was the initial idea too, but left aside for the first version. Any other optinion on this (other than "global no" or "no, no, no") ? -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Mon Nov 2 22:29:52 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 02 Nov 2015 22:29:52 +0100 Subject: [address-policy-wg] 2015-05 In-Reply-To: <1446481401.1597760.426859097.6F958D83@webmail.messagingengine.com> References: <56377B78.7060305@wirem.net> <1446481401.1597760.426859097.6F958D83@webmail.messagingengine.com> Message-ID: <1446499792.3801060.427165057.00232369@webmail.messagingengine.com> On Mon, Nov 2, 2015, at 17:23, Radu-Adrian FEURDEAN wrote: > points of view) may be more /21 rather than /22, i.e. only real new That should have been "/21 rather than /20", concerning the limit of already-held space. Sorry for the error. From gert at space.net Fri Nov 6 10:35:26 2015 From: gert at space.net (Gert Doering) Date: Fri, 6 Nov 2015 10:35:26 +0100 Subject: [address-policy-wg] RIPE 71 AP-WG Agenda v1 Message-ID: <20151106093526.GC70452@Space.Net> 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 Bucharest in the following time slots: Wednesday, Nov 18, 09:00 - 10:30 Wednesday, Nov 18, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. So far, the agenda is fairly light - if you have something you want to address, or that bothers you, let us know and we make room for you :-) The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) C. Current Policy Topics - Marco Schmidt, NCC PDO - 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 RIPE70 2015-01 Alignment of Transfer Requirements for IPv4 Allocations 2015-02 Keep IPv6 PI When Requesting IPv6 Allocation 2015-03 Assessment Criteria for IPv6 Initial Allocation Size - brief overview over new proposals (if any) F. Discussion of open policy proposals 2014-03 Remove Multihoming Requirement for AS Number .. (Job Snijders - ...?) 2015-04 RIPE Resource Transfer Policies (Erik Bais) 2015-05 Revision of Last /8 Allocation Criteria (Radu-Adrian Feurdean, Elvis Velea) [some bits might get moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back H. Romania's jump to 1st place as exporter of IPs (Ciprian Nica) [30 min] presentation and discussion D. Feedback From NCC Registration Service - Ingrid Wijte (NCC RS) (+ discussion with the group) 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 -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From saku at ytti.fi Sat Nov 7 18:19:18 2015 From: saku at ytti.fi (Saku Ytti) Date: Sat, 7 Nov 2015 19:19:18 +0200 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: Dear AP-WG, We are abandoning proposal 2014-03 due to our inability to find an acceptable solution which satisfies all parties. Thanks, Saku Ytti Job Snijders Authors of proposal 2014-03 "Remove Multihoming Requirement for AS Number" From mschmidt at ripe.net Mon Nov 9 16:20:02 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 09 Nov 2015 16:20:02 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) Message-ID: Dear colleagues, The proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposers decided to withdraw the proposal due to the inability to find an acceptable solution which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC From David.Huberman at microsoft.com Mon Nov 9 17:57:53 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Mon, 9 Nov 2015 16:57:53 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: As a community, I think it is important we resurrect this proposal as soon as possible. Requiring classic multi homing in order to obtain an AS Number is out of step with current engineering and operational practices. Can the authors, the chairs, the staff, or any knowledgeable observer please outline where the impasse is? I'd like to help get this back on the docket, but need to understand the bottom line. Thank you David David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________________ From: address-policy-wg on behalf of Marco Schmidt Sent: Monday, November 9, 2015 7:20:02 AM To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) Dear colleagues, The proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been withdrawn. It is now archived and can be found at: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ripe.net%2fparticipate%2fpolicies%2farchived-policy-proposals%2farchive-policy-proposals%2f&data=01%7c01%7cDAVID.HUBERMAN%40microsoft.com%7c06032ab2d4b940bc9e9108d2e919567e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=viQADY8DeLG%2fIyaMw6R62%2bJ5%2fVarFDLm4DFipQQcCT8%3d Reason for withdrawal: The proposers decided to withdraw the proposal due to the inability to find an acceptable solution which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC From marty at akamai.com Mon Nov 9 19:47:38 2015 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 9 Nov 2015 18:47:38 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: , Message-ID: <1447094859142.6669@akamai.com> I agree. Perhaps the use cases were too narrow? I see (and practice) single homing on a wide scale and the efficiencies of doing it responsibly are valuable to big and small alike IMHO. I don't recall the proposal and didn't pay attention to it. Mea culpa. Best, -M< ________________________________________ From: David Huberman Sent: Monday, November 9, 2015 11:57 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) As a community, I think it is important we resurrect this proposal as soon as possible. Requiring classic multi homing in order to obtain an AS Number is out of step with current engineering and operational practices. Can the authors, the chairs, the staff, or any knowledgeable observer please outline where the impasse is? I'd like to help get this back on the docket, but need to understand the bottom line. Thank you David David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________________ From: address-policy-wg on behalf of Marco Schmidt Sent: Monday, November 9, 2015 7:20:02 AM To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) Dear colleagues, The proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been withdrawn. It is now archived and can be found at: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ripe.net%2fparticipate%2fpolicies%2farchived-policy-proposals%2farchive-policy-proposals%2f&data=01%7c01%7cDAVID.HUBERMAN%40microsoft.com%7c06032ab2d4b940bc9e9108d2e919567e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=viQADY8DeLG%2fIyaMw6R62%2bJ5%2fVarFDLm4DFipQQcCT8%3d Reason for withdrawal: The proposers decided to withdraw the proposal due to the inability to find an acceptable solution which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC From saku at ytti.fi Mon Nov 9 21:41:34 2015 From: saku at ytti.fi (Saku Ytti) Date: Mon, 9 Nov 2015 22:41:34 +0200 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: On 9 November 2015 at 18:57, David Huberman wrote: Hey David, > Can the authors, the chairs, the staff, or any knowledgeable observer please outline where the impasse is? The impasse is that some people were afraid that too relaxed rules may encourage abuse, such as someone requesting 2**32 ASNs. To facilitate this, original proposal limited how many ASN single LIR (organisation) may register, essentially creating YRC to ASN, if you need more, register new LIR. The number was higher than any current organisation has ASNs for. People complained about that solution, because number was arbitrary. I suppose we need to get collection of non-arbitrary numbers from IEEE for this use. Another solution was attempted to add YRC to ASN itself, that was voted against. Personally I'd go with the original proposal and limit ASN per organisation. I'd also like to solve 16b ASN shortage by limiting single 16b ASN to organisation who has downstream public ASNs (because communities are important for downstream to signal information to upstream). For 32b ASN, I'd want reason for request to be submitted, but not evaluated. So that over time RIPE can present aggregated findings on how and why AS numbers are being used. Some suggested to iterate reasons for AS assignment, but I think that is counter-productive to innovation. Notion that we know of all use-cases there can be, is bit arrogant. -- ++ytti From David.Huberman at microsoft.com Tue Nov 10 04:29:56 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 10 Nov 2015 03:29:56 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: Thank you, ytti. So let's start with the basics. Does the following text allow the NCC to meet the needs of network operators today? "A new AS number is only assigned when the network architecture has a need that cannot be satisfied with an existing AS number." There will be more policy text. But again, let's start with -- and agree on -- the basics. Thanks! David David R Huberman Principal, Global IP Addressing Microsoft Corporation From aftab.siddiqui at gmail.com Tue Nov 10 05:30:22 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 10 Nov 2015 04:30:22 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: Hi Saku, > Personally I'd go with the original proposal and limit ASN per > organisation. I'd also like to solve 16b ASN shortage by limiting > single 16b ASN to organisation who has downstream public ASNs (because > communities are important for downstream to signal information to > upstream). > Just for my understanding, is there any demand for 16b ASN from the community? By default you get 32b ASN unless there is compelling reason for 16b. IANA gave the last block last year to all RIRs so if the requirement is there then it should be single 16b ASN to new LIR and nothing to existing ones. I believe only handful 16b ASNs are left in each RIR (though NCC may clarify) -- Best Wishes, Aftab A. Siddiqui -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Tue Nov 10 08:59:41 2015 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 10 Nov 2015 08:59:41 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <5641A3ED.3010405@CC.UniVie.ac.at> David Huberman wrote: > Thank you, ytti. > > So let's start with the basics. Does the following text allow the NCC to meet the needs of network operators today? > > "A new AS number is only assigned when the network architecture I would be more edxplicit and more flexible here, by adding e.g. or project > has a need that cannot be satisfied with an existing AS number." Looking at SDN stuff and pilot projects or testbeds, or even trainings or workshops, I can see the need to interconnect such projects with the 'real' net and to use globally unique AS numbers. I do understanf that "network architecture" can be interpreted as a rather wide and flexible term, but we should try to provide as good guidance as we can to support the evaluation of requests by the IPRAs. Wilfried > There will be more policy text. But again, let's start with -- and agree on -- the basics. > > Thanks! > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation From uros at ub330.net Tue Nov 10 09:16:51 2015 From: uros at ub330.net (Uros Gaber) Date: Tue, 10 Nov 2015 09:16:51 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <5641A3ED.3010405@CC.UniVie.ac.at> References: <5641A3ED.3010405@CC.UniVie.ac.at> Message-ID: I think that the pilot projects, testbeds or trainings are/could be already covered by the temporary assignments for which I think this proposal was not intended to change anything. I think that one 16bit ASN per LIR limit is not prudent as LIR != route end point, this notion that LIR is also "end customer" or the sole user of the network has been established in the last few years with the last /8 policy where I guess most of the new LIRs are actually also the route end point for their allocation, but if you look back LIRs were/are the middle-man between RIR and end customer which actually (could) need their own ASN so the need for the 16bit ASN exists at a third party and not directly with the LIR. I guess the need for 16bit ASN and with that requirements to get a 16bit ASN should stay unchanged but on the other hand the limitations for 32bit ASNs could be more relaxed. Uros On Tue, Nov 10, 2015 at 8:59 AM, Wilfried Woeber wrote: > David Huberman wrote: > > > Thank you, ytti. > > > > So let's start with the basics. Does the following text allow the NCC > to meet the needs of network operators today? > > > > "A new AS number is only assigned when the network architecture > > I would be more edxplicit and more flexible here, by adding e.g. > > or project > > > has a need that cannot be satisfied with an existing AS number." > > Looking at SDN stuff and pilot projects or testbeds, or even trainings > or workshops, I can see the need to interconnect such projects with > the 'real' net and to use globally unique AS numbers. > > I do understanf that "network architecture" can be interpreted as a > rather wide and flexible term, but we should try to provide as good > guidance as we can to support the evaluation of requests by the IPRAs. > > Wilfried > > > There will be more policy text. But again, let's start with -- and agree > on -- the basics. > > > > Thanks! > > David > > > > David R Huberman > > Principal, Global IP Addressing > > Microsoft Corporation > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.blessing at despres.co.uk Tue Nov 10 10:34:06 2015 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 10 Nov 2015 09:34:06 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: On 10 November 2015 at 04:30, Aftab Siddiqui wrote: > Just for my understanding, is there any demand for 16b ASN from the > community? Yes, if you want to peer widely and publically, then a 32b ASN leads to "issues" with IXP route servers not being able to "cope". In addition it appears that filtering AS-Paths with 23456 in them has been suggested in various places as being a "good thing tm" So if I was getting a new AS I'd be requesting one to be 16b in order to avoid as much of this as possible J -- James Blessing 07989 039 476 From phessler at theapt.org Tue Nov 10 10:49:21 2015 From: phessler at theapt.org (Peter Hessler) Date: Tue, 10 Nov 2015 10:49:21 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <20151110094921.GO23525@gir.theapt.org> On 2015 Nov 10 (Tue) at 04:30:22 +0000 (+0000), Aftab Siddiqui wrote: :Just for my understanding, is there any demand for 16b ASN from the :community? There is a technical case when attempting to use communities in the : format. There is not yet a 32:32b community available, even in extended communities. 16b:32b and 32b:16b do exist, so I'm not sure how critical that is. -- The bigger the theory the better. From d.baeza at tvt-datos.es Tue Nov 10 11:41:25 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Tue, 10 Nov 2015 11:41:25 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20151110094921.GO23525@gir.theapt.org> References: <20151110094921.GO23525@gir.theapt.org> Message-ID: <5641C9D5.3090503@tvt-datos.es> El 10/11/2015 a las 10:49, Peter Hessler escribi?: > On 2015 Nov 10 (Tue) at 04:30:22 +0000 (+0000), Aftab Siddiqui wrote: > :Just for my understanding, is there any demand for 16b ASN from the > :community? > > There is a technical case when attempting to use communities in the > : format. There is not yet a 32:32b community available, > even in extended communities. 16b:32b and 32b:16b do exist, so I'm not > sure how critical that is. And that is critical. I only have a 32b ASN and is impossible to work with communities while 32b:32b comm doesnt exists. From saku at ytti.fi Tue Nov 10 11:50:42 2015 From: saku at ytti.fi (Saku Ytti) Date: Tue, 10 Nov 2015 12:50:42 +0200 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20151110094921.GO23525@gir.theapt.org> References: <20151110094921.GO23525@gir.theapt.org> Message-ID: Dear Peter and Aftab, Extended communities are not transported in the Internet. So if I start new company and I want to sell IP transit, I'm competitively in disadvantageous position if I cannot market : traffic engineering policies to my customers. Sure I can use privateASN (and I must), but they are clearly less preferable on INET, and almost certainly won't cross many links. I.e. 16b ASN is special and should be under more strict assignment policy, when living without BGP communities is hard. On 10 November 2015 at 11:49, Peter Hessler wrote: > On 2015 Nov 10 (Tue) at 04:30:22 +0000 (+0000), Aftab Siddiqui wrote: > :Just for my understanding, is there any demand for 16b ASN from the > :community? > > There is a technical case when attempting to use communities in the > : format. There is not yet a 32:32b community available, > even in extended communities. 16b:32b and 32b:16b do exist, so I'm not > sure how critical that is. > > -- > The bigger the theory the better. > -- ++ytti From aftab.siddiqui at gmail.com Tue Nov 10 13:37:46 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 10 Nov 2015 12:37:46 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20151110094921.GO23525@gir.theapt.org> Message-ID: Hi Saku, > Extended communities are not transported in the Internet. So if I > start new company and I want to sell IP transit, I'm competitively in > disadvantageous position if I cannot market : traffic > engineering policies to my customers. > Sure I can use privateASN (and I must), but they are clearly less > preferable on INET, and almost certainly won't cross many links. > Yes I totally agree here. > I.e. 16b ASN is special and should be under more strict assignment > policy, when living without BGP communities is hard. Problem is the extremely low number of 16b ASN in the pool of every RIR. Although RIPE NCC has a quarantine policy (if am not mistaken) with 000+ ASN in it (NCC can confirm). Strict assignment policy would be great but BGP Communities can be simple justification to get 16b ASN and bypass any hurdles isn't it? -- Best Wishes, Aftab A. Siddiqui -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Nov 10 15:00:30 2015 From: saku at ytti.fi (Saku Ytti) Date: Tue, 10 Nov 2015 16:00:30 +0200 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20151110094921.GO23525@gir.theapt.org> Message-ID: On 10 November 2015 at 14:37, Aftab Siddiqui wrote: > Problem is the extremely low number of 16b ASN in the pool of every RIR. > Although RIPE NCC has a quarantine policy (if am not mistaken) with 000+ ASN > in it (NCC can confirm). Strict assignment policy would be great but BGP > Communities can be simple justification to get 16b ASN and bypass any > hurdles isn't it? I would expect that anyone who gets 16b ASN transits some downstream. Otherwise it's hard to argue you need globally visible BGP communities. -- ++ytti From aleksbulgakov at gmail.com Wed Nov 11 19:55:21 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 11 Nov 2015 21:55:21 +0300 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20151110094921.GO23525@gir.theapt.org> Message-ID: Hello. Who can send the docs for new proposal creation? 10 ????. 2015 ?. 17:00 ???????????? "Saku Ytti" ???????: > On 10 November 2015 at 14:37, Aftab Siddiqui > wrote: > > Problem is the extremely low number of 16b ASN in the pool of every RIR. > > Although RIPE NCC has a quarantine policy (if am not mistaken) with 000+ > ASN > > in it (NCC can confirm). Strict assignment policy would be great but BGP > > Communities can be simple justification to get 16b ASN and bypass any > > hurdles isn't it? > > I would expect that anyone who gets 16b ASN transits some downstream. > Otherwise it's hard to argue you need globally visible BGP > communities. > > -- > ++ytti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey at devnull.ru Wed Nov 11 19:57:51 2015 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 11 Nov 2015 19:57:51 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20151110094921.GO23525@gir.theapt.org> Message-ID: Why don?t you wish to talk to the Policy Development Officer? -- Kind regards, Sergey Myasoedov > On 11 Nov 2015, at 19:55, Aleksey Bulgakov wrote: > > Hello. > > Who can send the docs for new proposal creation? > > 10 ????. 2015 ?. 17:00 ???????????? "Saku Ytti" ???????: > On 10 November 2015 at 14:37, Aftab Siddiqui wrote: > > Problem is the extremely low number of 16b ASN in the pool of every RIR. > > Although RIPE NCC has a quarantine policy (if am not mistaken) with 000+ ASN > > in it (NCC can confirm). Strict assignment policy would be great but BGP > > Communities can be simple justification to get 16b ASN and bypass any > > hurdles isn't it? > > I would expect that anyone who gets 16b ASN transits some downstream. > Otherwise it's hard to argue you need globally visible BGP > communities. > > -- > ++ytti > From gert at space.net Wed Nov 11 20:08:03 2015 From: gert at space.net (Gert Doering) Date: Wed, 11 Nov 2015 20:08:03 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20151110094921.GO23525@gir.theapt.org> Message-ID: <20151111190803.GK89490@Space.Net> Hi, On Wed, Nov 11, 2015 at 09:55:21PM +0300, Aleksey Bulgakov wrote: > Who can send the docs for new proposal creation? The documents are online on the RIPE website - search for "policy development" - and of course the RIPE NCC policy development officer is happy to help (pdo at ripe.net). But before you all rush to send in new proposals - please wait for the RIPE meeting next week. We'll discuss this in the meeting, and then we have a better idea which direction the "new proposal" should take (just sending another one that doesn't get consensus either is wasting everyone's time) and see who will take it. 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From David.Huberman at microsoft.com Wed Nov 11 22:55:26 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 11 Nov 2015 21:55:26 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <5641A3ED.3010405@CC.UniVie.ac.at> References: <5641A3ED.3010405@CC.UniVie.ac.at> Message-ID: Very good input, thank you Wilfried! Does anyone else have any suggestions or objections to: "A new AS number is only assigned when the network architecture and/or project has a need that cannot be satisfied by an existing AS number." If there are no objections to this part of the text, that gives the WG a good foundation to build on in Bucharest, in my opinion. David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Wilfried Woeber [mailto:Woeber at CC.UniVie.ac.at] > Sent: Tuesday, November 10, 2015 12:00 AM > To: David Huberman > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2014-03 Policy Proposal Withdrawn > (Remove Multihoming Requirement for AS Number Assignments) > > David Huberman wrote: > > > Thank you, ytti. > > > > So let's start with the basics. Does the following text allow the NCC to meet > the needs of network operators today? > > > > "A new AS number is only assigned when the network architecture > > I would be more edxplicit and more flexible here, by adding e.g. > > or project > > > has a need that cannot be satisfied with an existing AS number." > > Looking at SDN stuff and pilot projects or testbeds, or even trainings or > workshops, I can see the need to interconnect such projects with the 'real' > net and to use globally unique AS numbers. > > I do understanf that "network architecture" can be interpreted as a rather > wide and flexible term, but we should try to provide as good guidance as we > can to support the evaluation of requests by the IPRAs. > > Wilfried > > > There will be more policy text. But again, let's start with -- and agree on -- > the basics. > > > > Thanks! > > David > > > > David R Huberman > > Principal, Global IP Addressing > > Microsoft Corporation From gert at space.net Thu Nov 12 08:53:25 2015 From: gert at space.net (Gert Doering) Date: Thu, 12 Nov 2015 08:53:25 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <5641A3ED.3010405@CC.UniVie.ac.at> Message-ID: <20151112075325.GO89490@Space.Net> Hi, On Wed, Nov 11, 2015 at 09:55:26PM +0000, David Huberman wrote: > Very good input, thank you Wilfried! > > Does anyone else have any suggestions or objections to: > > "A new AS number is only assigned when the network architecture and/or project has a need that cannot be satisfied by an existing AS number." > > If there are no objections to this part of the text, that gives the WG a good foundation to build on in Bucharest, in my opinion. Just to play the devil's advocate, who is to evaluate and understand these "cannot be satisfied" reasons? RIPE IPRAs are typically not BGP experts. Not saying that this is not a good starting point, but we always need to keep in mind that there are good people at the NCC who need to evaluate these requests, and they might not all have the in-depth understanding of technology... 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From saku at ytti.fi Thu Nov 12 17:13:56 2015 From: saku at ytti.fi (Saku Ytti) Date: Thu, 12 Nov 2015 18:13:56 +0200 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20151112075325.GO89490@Space.Net> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> Message-ID: On 12 November 2015 at 09:53, Gert Doering wrote: > Just to play the devil's advocate, who is to evaluate and understand these > "cannot be satisfied" reasons? RIPE IPRAs are typically not BGP experts. > > Not saying that this is not a good starting point, but we always need to > keep in mind that there are good people at the NCC who need to evaluate > these requests, and they might not all have the in-depth understanding > of technology... You should be saying this. This is what we got from RIPE NCC trying to pull it off. And I agree with them. If hostmasters need to decide, we need to tell them what are the rules. i.e. w need to iterate acceptable uses, which I don't want. I don't expect to know all use cases. I say this, clearly arrogantly, I think correct approach is: a) 32b ASN, question asked in form, but not evaluated (just to educate ourselves, why do people think they need ASNs) large limit per organisation, like 1000 ASN per organisation (LIR fees are low enough to justify buying another LIR if you need more ASN). b) 16b ASN, must not be stub network, must transit someone (if we can verify multihoming today, we can verify transiting tomorrow) -- ++ytti From phessler at theapt.org Fri Nov 13 09:40:43 2015 From: phessler at theapt.org (Peter Hessler) Date: Fri, 13 Nov 2015 09:40:43 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> Message-ID: <20151113084043.GV23525@gir.theapt.org> On 2015 Nov 12 (Thu) at 18:13:56 +0200 (+0200), Saku Ytti wrote: :On 12 November 2015 at 09:53, Gert Doering wrote: :> Just to play the devil's advocate, who is to evaluate and understand these :> "cannot be satisfied" reasons? RIPE IPRAs are typically not BGP experts. :> :> Not saying that this is not a good starting point, but we always need to :> keep in mind that there are good people at the NCC who need to evaluate :> these requests, and they might not all have the in-depth understanding :> of technology... : :You should be saying this. This is what we got from RIPE NCC trying to :pull it off. And I agree with them. If hostmasters need to decide, we :need to tell them what are the rules. i.e. w need to iterate :acceptable uses, which I don't want. I don't expect to know all use :cases. : :I say this, clearly arrogantly, I think correct approach is: : :a) 32b ASN, question asked in form, but not evaluated (just to educate :ourselves, why do people think they need ASNs) large limit per :organisation, like 1000 ASN per organisation (LIR fees are low enough :to justify buying another LIR if you need more ASN). :b) 16b ASN, must not be stub network, must transit someone (if we can :verify multihoming today, we can verify transiting tomorrow) : Thinking out loud: We could also apply the "last /8 policy" to this. After it goes into effect, each LIR can request one and only one 16b ASN. 32b ASNs are allocated as normal (with the question asked, but not evalutated). -- Maintainer's Motto: If we can't fix it, it ain't broke. From erik at bais.name Fri Nov 13 09:46:28 2015 From: erik at bais.name (Erik Bais) Date: Fri, 13 Nov 2015 08:46:28 +0000 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20151113084043.GV23525@gir.theapt.org> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> Hi Peter, > Thinking out loud: We could also apply the "last /8 policy" to this. > After it goes into effect, each LIR can request one and only one 16b ASN. > 32b ASNs are allocated as normal (with the question asked, but not > evalutated). I think that we are already beyond the point of handing out 1* 16b ASn to each LIR and there isn't that much left in the free pool I'm guessing .. ( that is my gut feeling .. ) But the NCC should be able to answer the total number in the RIPE pool ... Erik Bais From elvis at v4escrow.net Fri Nov 13 10:07:18 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Fri, 13 Nov 2015 01:07:18 -0800 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> Message-ID: <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> Hi, how would you explain it when a company (non-member) would ask why can a new LIR still receive a 16bit ASN and they can't? my 2 cents, elvis Excuse the briefness of this mail, it was sent from a mobile device. PS: apologies for the top-post > On Nov 13, 2015, at 00:46, Erik Bais wrote: > > Hi Peter, > >> Thinking out loud: We could also apply the "last /8 policy" to this. >> After it goes into effect, each LIR can request one and only one 16b ASN. >> 32b ASNs are allocated as normal (with the question asked, but not >> evalutated). > > I think that we are already beyond the point of handing out 1* 16b ASn to each LIR and there isn't that much left in the free pool I'm guessing .. ( that is my gut feeling .. ) > > But the NCC should be able to answer the total number in the RIPE pool ... > > Erik Bais > > From ingrid at ripe.net Fri Nov 13 10:27:06 2015 From: ingrid at ripe.net (Ingrid Wijte) Date: Fri, 13 Nov 2015 10:27:06 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> Message-ID: <5645ACEA.6090800@ripe.net> Dear colleagues, There are approximately 2,950 16-bit ASNs left in our pool, including the returned ASNs that are still referenced in other database objects. At the current rate of assignment, thepool of 16-bit ASNs will last 36 months. Within a few weeks, the RIPE NCC will start reassigning the referenced ASNs: https://www.ripe.net/manage-ips-and-asns/as-numbers/reassigning-as-numbers Best regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC On 13/11/2015 09:46, Erik Bais wrote: > Hi Peter, > >> Thinking out loud: We could also apply the "last /8 policy" to this. >> After it goes into effect, each LIR can request one and only one 16b ASN. >> 32b ASNs are allocated as normal (with the question asked, but not >> evalutated). > I think that we are already beyond the point of handing out 1* 16b ASn to each LIR and there isn't that much left in the free pool I'm guessing .. ( that is my gut feeling .. ) > > But the NCC should be able to answer the total number in the RIPE pool ... > > Erik Bais > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ck-lists at cksoft.de Fri Nov 13 11:02:07 2015 From: ck-lists at cksoft.de (Christian Kratzer) Date: Fri, 13 Nov 2015 11:02:07 +0100 (CET) Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> Message-ID: Hi, On Fri, 13 Nov 2015, Elvis Daniel Velea wrote: > Hi, > > how would you explain it when a company (non-member) would ask why can a new LIR still receive a 16bit ASN and they can't? exactly the same way as you explain to them that they cannot get IPv4 PI anymore. The situaion is very similar to the last /8 situation and I would support extending the last /8 policy to 16 bit AS numbers as well. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From gert at space.net Fri Nov 13 11:10:33 2015 From: gert at space.net (Gert Doering) Date: Fri, 13 Nov 2015 11:10:33 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> Message-ID: <20151113101033.GK89490@Space.Net> Hi, On Fri, Nov 13, 2015 at 11:02:07AM +0100, Christian Kratzer wrote: > The situaion is very similar to the last /8 situation and I would support extending the last /8 policy to 16 bit AS numbers as well. Actually, it is totally different. LIRs are entities that handle address distribution, but not necessarily run a network (many do, some do not), so tieing "last /8 address space" to "one LIR one block" is a compromise that sort of follows what the LIR does: hand out address space. Now, AS numbers are much more tied to the structure of the network - who is running BGP, who is transitting other ASes or just a leaf node - and the model "one LIR = one transit autonomous system" totally doesn't hold - not even "one LIR = one autonomous system in BGP". For a leaf node, 32bit ASes work mostly well. For a transit network, not so much, for the reasons listed - but not every LIR is a transit network (or has plans to eventually become one). Gert Doering -- NetMaster -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe-wgs at radu-adrian.feurdean.net Fri Nov 13 11:48:37 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 13 Nov 2015 11:48:37 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20151113101033.GK89490@Space.Net> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> <20151113101033.GK89490@Space.Net> Message-ID: <1447411717.2603402.438735665.2B13DC5F@webmail.messagingengine.com> On Fri, Nov 13, 2015, at 11:10, Gert Doering wrote: > On Fri, Nov 13, 2015 at 11:02:07AM +0100, Christian Kratzer wrote: > > The situaion is very similar to the last /8 situation and I would support extending the last /8 policy to 16 bit AS numbers as well. > > Actually, it is totally different. LIRs are entities that handle address > distribution, but not necessarily run a network (many do, some do not), > so tieing "last /8 address space" to "one LIR one block" is a compromise > that sort of follows what the LIR does: hand out address space. Not so much lately. At least not for new players and for the cases where a opening a LIR replaces a PI block. However, I do agree that some LIRs may not need an ASN at all, and most others may be fine with 32bit ASNs. Even for transit networks, 16-bit ASN is not a must in all cases. I think needs evaluation, as ugly as it is, it's still the best way of not wasting limited ressoucres. And a good recovery policy (maybe including "forced recovery/deregistration for non-complicance") is even better. Concerning the criteria for allocating a 16bit ASN, for a transit network I would add "accept 32bit ASN from customers", just to make sure. There are really ugly thing out there in the wild. -- Radu-Adrian FEURDEAN fr.ccs From h.lu at anytimechinese.com Fri Nov 13 17:34:26 2015 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 13 Nov 2015 17:34:26 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <1447411717.2603402.438735665.2B13DC5F@webmail.messagingengine.com> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> <20151113101033.GK89490@Space.Net> <1447411717.2603402.438735665.2B13DC5F@webmail.messagingengine.com> Message-ID: More flexible policy for better operation practice is really preferred in all cases. -Lu On Fri, Nov 13, 2015 at 11:48 AM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > On Fri, Nov 13, 2015, at 11:10, Gert Doering wrote: > > On Fri, Nov 13, 2015 at 11:02:07AM +0100, Christian Kratzer wrote: > > > The situaion is very similar to the last /8 situation and I would > support extending the last /8 policy to 16 bit AS numbers as well. > > > > Actually, it is totally different. LIRs are entities that handle address > > distribution, but not necessarily run a network (many do, some do not), > > so tieing "last /8 address space" to "one LIR one block" is a compromise > > that sort of follows what the LIR does: hand out address space. > > Not so much lately. At least not for new players and for the cases where > a opening a LIR replaces a PI block. > However, I do agree that some LIRs may not need an ASN at all, and most > others may be fine with 32bit ASNs. Even for transit networks, 16-bit > ASN is not a must in all cases. > > I think needs evaluation, as ugly as it is, it's still the best way of > not wasting limited ressoucres. And a good recovery policy (maybe > including "forced recovery/deregistration for non-complicance") is even > better. > > Concerning the criteria for allocating a 16bit ASN, for a transit > network I would add "accept 32bit ASN from customers", just to make > sure. There are really ugly thing out there in the wild. > > -- > Radu-Adrian FEURDEAN > fr.ccs > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Fri Nov 13 22:00:30 2015 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Fri, 13 Nov 2015 22:00:30 +0100 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> Message-ID: <56464F6E.10309@opdop.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, On 12/11/2015 17:13, Saku Ytti wrote: > You should be saying this. This is what we got from RIPE NCC trying to > pull it off. And I agree with them. If hostmasters need to decide, we > need to tell them what are the rules. i.e. w need to iterate > acceptable uses, which I don't want. I don't expect to know all use > cases. Well, if the only limitation making 16bit ASN required is to be able to export BGP communities to clients, why not just use this as the condition to request a 16bit ASN instead of a 32bit : - demander must have plans for BGP transit (re)selling - demander must explain the communities he plans to export. These are criteria that do not require Ripe NCC staff to have much knowledge about BGP operation nor about all possible use cases. Moreover these should apply to the EndUser (signer of a LIR sponsor agreement), not to the LIR. I believe next to come policies should always include respect of the policiy as mandatory to avoid the granted ressource to be withdrawn. Best regards, Sylvain Vallerot - -- http://www.opdop.fr - mutualiser et interconnecter en coop?rative Opdop - Soci?t? Coop?rative d'Inter?t Collectif sous forme de SARL sur IRC r?seau geeknode #opdop - t?l: 0950 31 54 74, 06 86 38 38 68 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlZGT2gACgkQJBGsD8mtnRH3qQD/e4GBIumaAY9SZVhoomfy7Qkr e0gntlUwU4r0qJ/wi40A/R6gqT8Yiemi8m9ysXC4et0CA2y8y0NxO/pr9EnwPneD =4uVo -----END PGP SIGNATURE----- From saku at ytti.fi Sun Nov 15 12:28:30 2015 From: saku at ytti.fi (Saku Ytti) Date: Sun, 15 Nov 2015 13:28:30 +0200 Subject: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> References: <5641A3ED.3010405@CC.UniVie.ac.at> <20151112075325.GO89490@Space.Net> <20151113084043.GV23525@gir.theapt.org> <862A73D42343AE49B2FC3C32FDDFE91C01612BCE3D@E2010-MBX04.exchange2010.nl> <9E2FB015-C526-470F-BE05-4E32A28E67CE@v4escrow.net> Message-ID: On 13 November 2015 at 11:07, Elvis Daniel Velea wrote: > how would you explain it when a company (non-member) would ask why can a new LIR still receive a 16bit ASN and they can't? Today we explain, yes - if you multihome. Tomorrow we explain, yes - if you transit someone. -- ++ytti From noc at atomohost.com Mon Nov 16 09:03:40 2015 From: noc at atomohost.com (NOC ATOMOHOST) Date: Mon, 16 Nov 2015 10:03:40 +0200 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria Message-ID: <56498DDC.3060506@atomohost.com> Hello, Me and my colleagues think that community should accept this proposal with an adjustment: ** 3. An equivalent of a /22 allocation can be requested every 18 months from the moment of the last allocation if the following conditions are met: 1. The LIR has not transferred any IPv4 address space out of its registry. 2. There is enough space in the free pool to perform the allocation Adjustment: 3. The LIR is not allocated more than equivalent of a /19 ** Adjustment reasoning: The last changes in IP Transfer policy (18 month transfer delay) positively influenced the fight against membership abuse. But we want to draw your attention to the fact that for now new members have virtually no space for further growth and development and are unable to compete with the old ones who were allocated much larger address space a long ago. The barrier and the prospect of a /19 prevents the old large members to abuse the changes and gives the new ones an opportunity to plan their growth for 12 years (on condition of 18 moth allocation delay), excluding transfers (in case if it is difficult to implement the transfer in a members service region). We belive that this policy changes with our adjustment will attract a new real and competitive members to community. -- Best regards, Igor Strelyaniy Network Operation Manager ATOMOHOST LLC email: noc at atomohost.com website: atomohost.com From david at profesionalhosting.es Mon Nov 16 10:02:24 2015 From: david at profesionalhosting.es (David - ProfesionalHosting) Date: Mon, 16 Nov 2015 10:02:24 +0100 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria Message-ID: <56499BA0.4080502@profesionalhosting.es> OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. This would only be possible if the LIR has not transferred any IPv4 address space before. I support this measure. For us it is a big problem not to request more / 22, we are an ISP, and it does not seem fair to have to buy to get / 22 when others have to spare. From jim at rfc1035.com Mon Nov 16 11:37:40 2015 From: jim at rfc1035.com (Jim Reid) Date: Mon, 16 Nov 2015 10:37:40 +0000 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <56499BA0.4080502@profesionalhosting.es> References: <56499BA0.4080502@profesionalhosting.es> Message-ID: <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> > On 16 Nov 2015, at 09:02, David - ProfesionalHosting wrote: > > OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. This would only be possible if the LIR has not transferred any IPv4 address space before. > > I support this measure. For us it is a big problem not to request more / 22, we are an ISP, and it does not seem fair to have to buy to get / 22 when others have to spare. I strongly oppose this measure. The NCC?s remaining v4 address space must be carefully conserved to ensure new LIRs in 5, 10, 20 year?s time can get a minimum allocation of IPv4. They will need some v4 space sp can reach IPv4-only equipment on what should be a mostly IPv6 Internet. If we burn through those remaining IPv4 addresses now, that will not be possible. This would be wrong. Very wrong. Any address policy for the last /8 which says ?LIRs can get even more than their one off final /22 of IPv4? undermines that principle. Every LIR really has to accept that they have to wean themselves off IPv4 and have a serious approach to using IPv6. You?re going to have to do this at some point. You might as well do it now. IPv4 allocations from the RIRs are not going to last forever. Changing the address policy for everyone just so you can continue with an IPv4-only networking approach for a few more months is both unfair and unwise. From tom.hill at bytemark.co.uk Mon Nov 16 11:45:17 2015 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Mon, 16 Nov 2015 10:45:17 +0000 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> Message-ID: <5649B3BD.9000705@bytemark.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16/11/15 10:37, Jim Reid wrote: > I strongly oppose this measure. > > The NCC?s remaining v4 address space must be carefully conserved > to ensure new LIRs in 5, 10, 20 year?s time can get a minimum > allocation of IPv4. They will need some v4 space sp can reach > IPv4-only equipment on what should be a mostly IPv6 Internet. If we > burn through those remaining IPv4 addresses now, that will not be > possible. This would be wrong. Very wrong. > > Any address policy for the last /8 which says ?LIRs can get even > more than their one off final /22 of IPv4? undermines that > principle. > > Every LIR really has to accept that they have to wean themselves > off IPv4 and have a serious approach to using IPv6. You?re going to > have to do this at some point. You might as well do it now. IPv4 > allocations from the RIRs are not going to last forever. Changing > the address policy for everyone just so you can continue with an > IPv4-only networking approach for a few more months is both unfair > and unwise. +1 to all of the above. I am also against this proposal. - -- Tom Hill Network Engineer Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 1904 890 890 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWSbO9AAoJEH2fKbrp2sQ68MQH/RX5tEccjob1Qata1keZuxGI PM1wTRxauEWH45t1a5/HLgULAm+bl9tBJPwnilky1Dxo8MmEY9JbsTqrpeZ0HLf4 bzijlwt1FYBfY/K9nS8WoaNmsMGS+zHuUT6e5ea9+83y3FuFkPqbP/keQsw2tsN9 uGlAKWti4dysfo7fW2+mJUe0z1uPfA8EPe0Ff1vA2+/38UxHz2JPNOuN9FE1ySPG Ax8sa7S6u4FkBUNUlxyuM6SSH4IBJMkHg0mHfQWqgrJiTlC+lnNfBStPTRCKb36D 1vSc0Q1HG/JtlsfEAq3oYXvxghSSkobPNmsqNlCe2Be9cgB/4exe6a7GwkyqvcA= =15uR -----END PGP SIGNATURE----- From bogdan at rotariu.ro Mon Nov 16 12:39:04 2015 From: bogdan at rotariu.ro (Bogdan-Stefan Rotariu) Date: Mon, 16 Nov 2015 13:39:04 +0200 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <56499BA0.4080502@profesionalhosting.es> References: <56499BA0.4080502@profesionalhosting.es> Message-ID: <5FF76FEB-68CB-4944-B300-16DDADDF3794@rotariu.ro> > On Nov 16, 2015, at 11:02, David - ProfesionalHosting wrote: > > OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. This would only be possible if the LIR has not transferred any IPv4 address space before. > > I support this measure. For us it is a big problem not to request more / 22, we are an ISP, and it does not seem fair to have to buy to get / 22 when others have to spare. I agree with this proposal, it will give a fresh air to some of us. From noc at atomohost.com Mon Nov 16 14:12:05 2015 From: noc at atomohost.com (NOC ATOMOHOST) Date: Mon, 16 Nov 2015 15:12:05 +0200 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria (Jim Reid) Message-ID: <5649D625.3030005@atomohost.com> > Every LIR really has to accept that they have to wean themselves off IPv4 and have a serious approach to using IPv6. You?re going to have to do this at some point. You might as well do it now. IPv4 allocations from the RIRs are not going to last forever. Changing the address policy for everyone just so you can continue with an IPv4-only networking approach for a few more months is both unfair and unwise. Dear Jim, A lot of LIR's in the number of regions cannot allow themselves "serious approach to using IPv6" because of outdated infrustructure and lack of resources . We offer (see my previous mail) to let them grow and expand and let them opportunity to accumulate resources for update and renew their infrustructures. We expect that subsequently this can help such LIRs to deploy IPv6. Also worth mentioning that our adjustment restricts the possibilities to abuse policy changes by major LIRs who are already have the opportunity to deploy IPv6. -- Best regards, Igor Strelyaniy Network Operation Manager ATOMOHOST LLC email: noc at atomohost.com website: atomohost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Mon Nov 16 14:12:48 2015 From: jim at rfc1035.com (Jim Reid) Date: Mon, 16 Nov 2015 13:12:48 +0000 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <5649C11B.1040504@profesionalhosting.es> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <5649C11B.1040504@profesionalhosting.es> Message-ID: <0E2CB4D8-7DFB-4446-9E83-FFF60942227E@rfc1035.com> > On 16 Nov 2015, at 11:42, David - ProfesionalHosting wrote: > > While 100% implemented IPv6 on all ISPs will be many many years, as we are both ipv4 blocked and need more, we can not wait for this to happen. We can only buy at speculative prices. Tough. If you choose that approach to kludging around your IPv4 problems, the consequences of that decision are yours alone. There are other ways of making ?better? use of your remaining IPv4 address space. Though they are also ugly. Get over it. Sorry. Your argument seems to be ?I want to plunder the remaining IPv4 at the NCC because I don?t want to buy addreses on the secondary market?. Well, that?s simply not a good enough reason to change the current policy. That approach may well be good for you and your business but it?s not good for the community as a whole. Tragedy of the commons and all that? From jim at rfc1035.com Mon Nov 16 14:22:53 2015 From: jim at rfc1035.com (Jim Reid) Date: Mon, 16 Nov 2015 13:22:53 +0000 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria (Jim Reid) In-Reply-To: <5649D625.3030005@atomohost.com> References: <5649D625.3030005@atomohost.com> Message-ID: <7EF00CDB-7EB7-42B0-82C8-A18443BC7892@rfc1035.com> On 16 Nov 2015, at 13:12, NOC ATOMOHOST wrote: > > A lot of LIR's in the number of regions cannot allow themselves "serious approach to using IPv6" because of outdated infrustructure and lack of resources . I?m sympathetic to those problems Igor. Everyone is. But the root cause of these problems has to be tackled. Burning through the last reserves of IPv4 as a short-term workaround does not seem wise. It would be as pointless as putting a band-aid over an arterial bleed. The problems of outdated infrastructure and lack of resources would still be there after a more liberal allocation policy for the last /8 meant ALL of the remaining IPv4 was gone. From he at uninett.no Mon Nov 16 14:32:08 2015 From: he at uninett.no (Havard Eidnes) Date: Mon, 16 Nov 2015 14:32:08 +0100 (CET) Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> Message-ID: <20151116.143208.1142929817368031559.he@uninett.no> >> On 16 Nov 2015, at 09:02, David - ProfesionalHosting wrote: >> >> OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 >> allocation from the RIPE NCC every 18 months. This would only >> be possible if the LIR has not transferred any IPv4 address >> space before. >> >> I support this measure. For us it is a big problem not to >> request more / 22, we are an ISP, and it does not seem fair to >> have to buy to get / 22 when others have to spare. > > I strongly oppose this measure. > > The NCC?s remaining v4 address space must be carefully conserved to > ensure new LIRs in 5, 10, 20 year?s time can get a minimum > allocation of IPv4. They will need some v4 space sp can reach > IPv4-only equipment on what should be a mostly IPv6 Internet. If we > burn through those remaining IPv4 addresses now, that will not be > possible. This would be wrong. Very wrong. > > Any address policy for the last /8 which says ?LIRs can get even > more than their one off final /22 of IPv4? undermines that > principle. > > Every LIR really has to accept that they have to wean themselves off > IPv4 and have a serious approach to using IPv6. You?re going to have > to do this at some point. You might as well do it now. IPv4 > allocations from the RIRs are not going to last forever. Changing > the address policy for everyone just so you can continue with an > IPv4-only networking approach for a few more months is both unfair > and unwise. Well said, Jim. FWIW, I'm agreeing fully with what you say here. The current "last /8" policy is working the way it should. Regards, - H?vard From noc at atomohost.com Mon Nov 16 14:59:16 2015 From: noc at atomohost.com (NOC ATOMOHOST) Date: Mon, 16 Nov 2015 15:59:16 +0200 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria (Jim Reid) In-Reply-To: <7EF00CDB-7EB7-42B0-82C8-A18443BC7892@rfc1035.com> References: <5649D625.3030005@atomohost.com> <7EF00CDB-7EB7-42B0-82C8-A18443BC7892@rfc1035.com> Message-ID: <5649E134.8070505@atomohost.com> 16.11.2015 15:22, Jim Reid ?????: > I?m sympathetic to those problems Igor. Everyone is. But the root cause of these problems has to be tackled. Burning through the last reserves of IPv4 as a short-term workaround does not seem wise. It would be as pointless as putting a band-aid over an arterial bleed. The problems of outdated infrastructure and lack of resources would still be there after a more liberal allocation policy for the last /8 meant ALL of the remaining IPv4 was gone. For now just a half of the last /8 (8mln) can help 7.812 LIRs to grow twice. I have no information about how many LIRs fall under our adjustment criteria. Maybe someone (RIPE staff e.g.) can announce the number of LIRs and their average pools so we can calculate the benefits and the consequences. I agree with your concerns but think that if we want to deploy IPv6 we should seek the ways to LIRs developement because valves twisting spawns abusers but not reformers. -- Best regards, Igor Strelyaniy Network Operation Manager ATOMOHOST LLC email: noc at atomohost.com website: atomohost.com From garry at nethinks.com Mon Nov 16 15:41:48 2015 From: garry at nethinks.com (Garry Glendown) Date: Mon, 16 Nov 2015 15:41:48 +0100 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <20151116.143208.1142929817368031559.he@uninett.no> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <20151116.143208.1142929817368031559.he@uninett.no> Message-ID: <5649EB2C.7000007@nethinks.com> Guten Tag, >>> On 16 Nov 2015, at 09:02, David - ProfesionalHosting wrote: >>> >>> OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 >>> allocation from the RIPE NCC every 18 months. This would only >>> be possible if the LIR has not transferred any IPv4 address >>> space before. >>> >>> I support this measure. For us it is a big problem not to >>> request more / 22, we are an ISP, and it does not seem fair to >>> have to buy to get / 22 when others have to spare. >> I strongly oppose this measure. >> > Well said, Jim. FWIW, I'm agreeing fully with what you say here. The > current "last /8" policy is working the way it should. As much as I sympathize with the LIRs that are suffering under the restrictions of the last/8 policy (one of our customers just opened an LIR in order to get their own /22 ... which is NOT enough to supply all of their business customers, let alone the home users, with unique IPv4 addresses), I do also have to oppose the proposition. What I could maybe live with would be if the additional addresses would be available from a pool of returned IPv4 addresses only, and only to those with available space smaller than /X (like, e.g. /20 or /19) Mit freundlichen Gr??en, Garry Glendown -- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstra?e 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown at nethinks.com Gesch?ftsf?hrer: Uwe Bergmann Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32 From david at profesionalhosting.es Mon Nov 16 12:42:19 2015 From: david at profesionalhosting.es (David - ProfesionalHosting) Date: Mon, 16 Nov 2015 12:42:19 +0100 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> Message-ID: <5649C11B.1040504@profesionalhosting.es> Dear Colleague, It is clear that the future is in the ipv6 but the current reality is that large ISPs do not use IPv6 customer connections. When exhausted my / 22 ipv4 first thing I did is to implement IPv6 , if only we set up a server with IPv6, end users connecting to only support IPv4 can not access the pages on that server. While 100% implemented IPv6 on all ISPs will be many many years, as we are both ipv4 blocked and need more, we can not wait for this to happen. We can only buy at speculative prices. In my humble opinion Limit /22 IPv4 will not solve the problem of using the ipv6. This measure limit /22 pressed only to new members who entered with this limitation, although all new members implement IPv6 does not solve the problem that depends on large ISP. El 16/11/15 a las 11:37, Jim Reid escribi?: >> On 16 Nov 2015, at 09:02, David - ProfesionalHosting wrote: >> >> OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. This would only be possible if the LIR has not transferred any IPv4 address space before. >> >> I support this measure. For us it is a big problem not to request more / 22, we are an ISP, and it does not seem fair to have to buy to get / 22 when others have to spare. > I strongly oppose this measure. > > The NCC?s remaining v4 address space must be carefully conserved to ensure new LIRs in 5, 10, 20 year?s time can get a minimum allocation of IPv4. They will need some v4 space sp can reach IPv4-only equipment on what should be a mostly IPv6 Internet. If we burn through those remaining IPv4 addresses now, that will not be possible. This would be wrong. Very wrong. > > Any address policy for the last /8 which says ?LIRs can get even more than their one off final /22 of IPv4? undermines that principle. > > Every LIR really has to accept that they have to wean themselves off IPv4 and have a serious approach to using IPv6. You?re going to have to do this at some point. You might as well do it now. IPv4 allocations from the RIRs are not going to last forever. Changing the address policy for everyone just so you can continue with an IPv4-only networking approach for a few more months is both unfair and unwise. > > From david at profesionalhosting.es Mon Nov 16 14:28:25 2015 From: david at profesionalhosting.es (David - ProfesionalHosting) Date: Mon, 16 Nov 2015 14:28:25 +0100 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <0E2CB4D8-7DFB-4446-9E83-FFF60942227E@rfc1035.com> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <5649C11B.1040504@profesionalhosting.es> <0E2CB4D8-7DFB-4446-9E83-FFF60942227E@rfc1035.com> Message-ID: <5649D9F9.60605@profesionalhosting.es> I have not suggested this proposal(although support), not only for me, I'm sure there are many new members in this situation. El 16/11/15 a las 14:12, Jim Reid escribi?: >> On 16 Nov 2015, at 11:42, David - ProfesionalHosting wrote: >> >> While 100% implemented IPv6 on all ISPs will be many many years, as we are both ipv4 blocked and need more, we can not wait for this to happen. We can only buy at speculative prices. > Tough. > > If you choose that approach to kludging around your IPv4 problems, the consequences of that decision are yours alone. There are other ways of making ?better? use of your remaining IPv4 address space. Though they are also ugly. Get over it. Sorry. > > Your argument seems to be ?I want to plunder the remaining IPv4 at the NCC because I don?t want to buy addreses on the secondary market?. Well, that?s simply not a good enough reason to change the current policy. That approach may well be good for you and your business but it?s not good for the community as a whole. Tragedy of the commons and all that? > > > > From sander at steffann.nl Mon Nov 16 18:02:10 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 16 Nov 2015 19:02:10 +0200 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <5649EB2C.7000007@nethinks.com> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <20151116.143208.1142929817368031559.he@uninett.no> <5649EB2C.7000007@nethinks.com> Message-ID: Hi Garry, > What I could maybe live with would be if the additional addresses would > be available from a pool of returned IPv4 addresses only, and only to > those with available space smaller than /X (like, e.g. /20 or /19) What I am a bit worried about with a policy like that is the 'flapping' effect. At some point the pool of returned addresses runs out, so the NCC has to refuse requests. Then some more addresses are returned and the pool fill up a bit again, but the existing queue of requests will drain it again, etc. This might be implemented with a waiting list in a first-come-first-serve manner, but I expect that the time between sending in a request and getting to the top of the list might get to 'multiple years' quite quickly. So it would add a lot of complexity and still not help the newcomers. Stuff like this is why this working group decided a few years ago to put all the returned space into the main pool instead of making a new pool with a separate policy. If this working group wants to change that now we need to carefully consider the consequences and effects. Cheers, Sander From garry at nethinks.com Tue Nov 17 07:43:10 2015 From: garry at nethinks.com (Garry Glendown) Date: Tue, 17 Nov 2015 07:43:10 +0100 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <20151116.143208.1142929817368031559.he@uninett.no> <5649EB2C.7000007@nethinks.com> Message-ID: <564ACC7E.6080908@nethinks.com> Guten Tag, > Hi Garry, > >> What I could maybe live with would be if the additional addresses would >> be available from a pool of returned IPv4 addresses only, and only to >> those with available space smaller than /X (like, e.g. /20 or /19) > What I am a bit worried about with a policy like that is the 'flapping' effect. At some point the pool of returned addresses runs out, so the NCC has to refuse requests. Then some more addresses are returned and the pool fill up a bit again, but the existing queue of requests will drain it again, etc. > > This might be implemented with a waiting list in a first-come-first-serve manner, but I expect that the time between sending in a request and getting to the top of the list might get to 'multiple years' quite quickly. So it would add a lot of complexity and still not help the newcomers. > > Stuff like this is why this working group decided a few years ago to put all the returned space into the main pool instead of making a new pool with a separate policy. If this working group wants to change that now we need to carefully consider the consequences and effects. Yes it would create a waiting list - which is fine. For newcomers, we still have the last/8 pool to "instantly" provide a /22, with sufficient IPs (hopefully) to last until legacy v4 is finally disabled (I hope to see that day ;) ). And still it allows for at least some growth for new LIRs. As for the policy on how to distribute returned v4 blocks, I could imagine something that includes factors like current allocation (i.e. someone who only has a /22 gets into the waiting list before someone with a larger allocation), number of IPs requested, time since last allocation, whether the LIR has transfered IPs to another LIR, etc. Mit freundlichen Gr??en, Garry Glendown From randy at psg.com Tue Nov 17 10:41:10 2015 From: randy at psg.com (Randy Bush) Date: Tue, 17 Nov 2015 11:41:10 +0200 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <20151116.143208.1142929817368031559.he@uninett.no> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <20151116.143208.1142929817368031559.he@uninett.no> Message-ID: >> Every LIR really has to accept that they have to wean themselves off >> IPv4 and have a serious approach to using IPv6. You?re going to have >> to do this at some point. You might as well do it now. IPv4 >> allocations from the RIRs are not going to last forever. Changing >> the address policy for everyone just so you can continue with an >> IPv4-only networking approach for a few more months is both unfair >> and unwise. > > Well said, Jim. FWIW, I'm agreeing fully with what you say here. The > current "last /8" policy is working the way it should. the only thing i would add, with extreme sadness and some disgust, it that they could do as many have, go nat/cgn. randy From sebastian at karotte.org Tue Nov 17 15:02:09 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Tue, 17 Nov 2015 15:02:09 +0100 Subject: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria) In-Reply-To: <562637BE.7060505@ripe.net> References: <562637BE.7060505@ripe.net> Message-ID: <20151117140209.GA17217@danton.fire-world.de> * Marco Schmidt [2015-10-20 14:51]: > Dear colleagues, > > A new RIPE Policy proposal, "Revision of Last /8 Allocation Criteria", > is now available for discussion. > > The goal of this proposal is to allow LIRs to request an additional /22 > IPv4 allocation from the RIPE NCC every 18 months. FWIW I oppose this proposal. People are starting to feel the pain of IPv4 running out (as was foretold for the last decade) and I'm sorry for them but there is no cure (in the IPv4 world). The last /8 policy is doing what it's supposed to do. It was never supposed to satisfy peoples IPv4 demand, it is supposed to provide an absolute minimum of IPv4 for things like CGNAT and external services. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From mschmidt at ripe.net Tue Nov 17 17:07:28 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 17 Nov 2015 18:07:28 +0200 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) Message-ID: <564B50C0.6080009@ripe.net> Dear colleagues, The draft documents for version 2.0 of the policy proposal 2015-04, "RIPE Resource Transfer Policies" have now been published, along with an impact analysis conducted by the RIPE NCC. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. The key difference from version 1.0 is clarification in the policy text and policy summary regarding the 24-month holding period for scarce resources. You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2015-04/draft We encourage you to read the draft document and send any comments to before 16 December 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From sander at steffann.nl Tue Nov 17 18:01:20 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 17 Nov 2015 19:01:20 +0200 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <564B50C0.6080009@ripe.net> References: <564B50C0.6080009@ripe.net> Message-ID: <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> Hello working group, > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2015-04 Thanks to Marco and the rest of the RIPE NCC for this extensive impact analysis. This impact analysis uncovers a very serious issue that has slipped under our radar in the "Entities That Can Receive a Transfer". The issue raised from the RIPE NCC Executive Board looks completely legitimate to us. For those of you who haven't read the impact analysis yet, this is the core of the issue: > The RIPE NCC impact analysis notes that acceptance of this proposal could significantly affect the stability of the RIR system as a whole by allowing transfer of any resource (including assigned PA space) to any entity including one that is not a member of the RIPE NCC (or any other RIR). This is a serious issue that will affect all of us. The chairs take this issue into the consensus-reaching process and we ask the authors and working group to address this. Your working group chairs, Gert and Sander From rgori at wirem.net Tue Nov 17 19:05:58 2015 From: rgori at wirem.net (Riccardo Gori) Date: Tue, 17 Nov 2015 19:05:58 +0100 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> References: <564B50C0.6080009@ripe.net> <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> Message-ID: <564B6C86.7070909@wirem.net> Dear Colleagues, we have all to thank Eric for the hard work done. When the proposal apperead I thought it was good and would approve such content. In its essence is really fair and clean but the matter is highly complicated. I agree with the board and even Eric evaluated this kind of problem in his Rational analisys Opposing the proposal when he says the word slight change make the document generic. Generic in this case makes it dangerous. I would take care also of board point here: [...] This has the potential to complicate future policy development activity, and it is expected that increased efforts will be needed to explain to the RIPE NCC membership and other stakeholders which policy document applies in which situations, [...] More colleages consider that standing to the Board opinion (and I agree) this will not affect in any way m&a and maybe we will never have a document that does it for many reasons. My opinion is to do not touch anaything at this time. We can ask the Board to consider the matter of entity and more Local Internet Registries. Yes the answer is still yes it is legitime, let it be like other thinks happened in the past and do your best to think 6. If the answer is no it can be touched maybe we can do something on that and slow down a potencial growing burning trend. kind regads Riccardo Il 17/11/2015 18:01, Sander Steffann ha scritto: > Hello working group, > >> You can find the full proposal and the impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2015-04 > Thanks to Marco and the rest of the RIPE NCC for this extensive impact analysis. > > This impact analysis uncovers a very serious issue that has slipped under our radar in the "Entities That Can Receive a Transfer". The issue raised from the RIPE NCC Executive Board looks completely legitimate to us. > > For those of you who haven't read the impact analysis yet, this is the core of the issue: > >> The RIPE NCC impact analysis notes that acceptance of this proposal could significantly affect the stability of the RIR system as a whole by allowing transfer of any resource (including assigned PA space) to any entity including one that is not a member of the RIPE NCC (or any other RIR). > This is a serious issue that will affect all of us. The chairs take this issue into the consensus-reaching process and we ask the authors and working group to address this. > > Your working group chairs, > Gert and Sander > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 WIREM Fiber Revolution - Net-IT s.r.l. Via Emilia Ponente, 1667 47522 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 e-mail: info at wirem.net -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l. via Emilia Ponente, 1667 - 47522 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From frettled at gmail.com Tue Nov 17 20:36:19 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 17 Nov 2015 20:36:19 +0100 Subject: [address-policy-wg] Revision of Last /8 Allocation Criteria In-Reply-To: <0E2CB4D8-7DFB-4446-9E83-FFF60942227E@rfc1035.com> References: <56499BA0.4080502@profesionalhosting.es> <892C0348-2BE5-454E-A9DB-6B128ADEEA16@rfc1035.com> <5649C11B.1040504@profesionalhosting.es> <0E2CB4D8-7DFB-4446-9E83-FFF60942227E@rfc1035.com> Message-ID: On Mon, Nov 16, 2015 at 2:12 PM, Jim Reid wrote: > Tough. > > If you choose that approach to kludging around your IPv4 problems, the > consequences of that decision are yours alone. There are other ways of > making ?better? use of your remaining IPv4 address space. Though they are > also ugly. Get over it. Sorry. > Yup. > > Your argument seems to be ?I want to plunder the remaining IPv4 at the NCC > because I don?t want to buy addreses on the secondary market?. Well, that?s > simply not a good enough reason to change the current policy. That approach > may well be good for you and your business but it?s not good for the > community as a whole. Tragedy of the commons and all that? > > I think the lukewarm reception to my thought experiment also shows that the agenda isn't about solving any real problems with the restrictions under the last /8 policy, but actually _is_ about plundering the remaining IPv4 space. It's therefore been a bit amusing and sad to see how this proposal is so eagerly supported by some of the list participants. Well, I cannot say that I've been swayed away from opposing the proposal. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue Nov 17 20:44:17 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 17 Nov 2015 20:44:17 +0100 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> References: <564B50C0.6080009@ripe.net> <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> Message-ID: On Tue, Nov 17, 2015 at 6:01 PM, Sander Steffann wrote: > Hello working group, > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-04 > > Thanks to Marco and the rest of the RIPE NCC for this extensive impact > analysis. > +1, this impact analysis was also a pleasure to read for this n00b. > > This impact analysis uncovers a very serious issue that has slipped under > our radar in the "Entities That Can Receive a Transfer". The issue raised > from the RIPE NCC Executive Board looks completely legitimate to us. > > For those of you who haven't read the impact analysis yet, this is the > core of the issue: > > > The RIPE NCC impact analysis notes that acceptance of this proposal > could significantly affect the stability of the RIR system as a whole by > allowing transfer of any resource (including assigned PA space) to any > entity including one that is not a member of the RIPE NCC (or any other > RIR). > > This is a serious issue that will affect all of us. The chairs take this > issue into the consensus-reaching process and we ask the authors and > working group to address this. > > I didn't anticipate this issue, either, and I agree that the RIPE NCC's concerns are valid and real. Shouldn't this be a rather straightforward thing to fix in the proposal? Or am I missing something here? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Nov 17 21:55:22 2015 From: gert at space.net (Gert Doering) Date: Tue, 17 Nov 2015 21:55:22 +0100 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <564B50C0.6080009@ripe.net> <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> Message-ID: <20151117205522.GT89490@Space.Net> Hi, On Tue, Nov 17, 2015 at 08:44:17PM +0100, Jan Ingvoldstad wrote: > > This is a serious issue that will affect all of us. The chairs take this > > issue into the consensus-reaching process and we ask the authors and > > working group to address this. > > I didn't anticipate this issue, either, and I agree that the RIPE NCC's > concerns are valid and real. > > Shouldn't this be a rather straightforward thing to fix in the proposal? > > Or am I missing something here? Since the intentions basically are to do "the right thing" (so, PA blocks can only be transferred to LIRs or "member of other RIRs", not to "anyone having a contract", etc.) and just the wording got simplified too much, I do not see unforeseeable problems here. If there is consensus otherwise to go forward, this will need a textual change that very clearly states in no unclear terms what can be done (and by omission, what can not be done), and another impact analysis - so, one extra round through the PDP. But it is not the first time that the IA uncovered wording that needs to be clarified "if read by an outsider", so it's good that we have it :-) 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nigel at titley.com Tue Nov 17 21:58:36 2015 From: nigel at titley.com (Nigel Titley) Date: Tue, 17 Nov 2015 22:58:36 +0200 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20151117205522.GT89490@Space.Net> References: <564B50C0.6080009@ripe.net> <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> <20151117205522.GT89490@Space.Net> Message-ID: <564B94FC.3070806@titley.com> On 17/11/2015 22:55, Gert Doering wrote: > Hi, > > On Tue, Nov 17, 2015 at 08:44:17PM +0100, Jan Ingvoldstad wrote: >>> This is a serious issue that will affect all of us. The chairs take this >>> issue into the consensus-reaching process and we ask the authors and >>> working group to address this. >> I didn't anticipate this issue, either, and I agree that the RIPE NCC's >> concerns are valid and real. >> >> Shouldn't this be a rather straightforward thing to fix in the proposal? >> >> Or am I missing something here? > Since the intentions basically are to do "the right thing" (so, PA blocks > can only be transferred to LIRs or "member of other RIRs", not to "anyone > having a contract", etc.) and just the wording got simplified too much, > I do not see unforeseeable problems here. > > If there is consensus otherwise to go forward, this will need a textual > change that very clearly states in no unclear terms what can be done > (and by omission, what can not be done), and another impact analysis - so, > one extra round through the PDP. But it is not the first time that the > IA uncovered wording that needs to be clarified "if read by an outsider", > so it's good that we have it :-) > And of course the NCC can't fix the problem. That is up to the community. Nigel From gert at space.net Tue Nov 17 22:01:48 2015 From: gert at space.net (Gert Doering) Date: Tue, 17 Nov 2015 22:01:48 +0100 Subject: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <564B94FC.3070806@titley.com> References: <564B50C0.6080009@ripe.net> <4F420C25-7A34-48CE-A24A-8726110B2607@steffann.nl> <20151117205522.GT89490@Space.Net> <564B94FC.3070806@titley.com> Message-ID: <20151117210148.GV89490@Space.Net> Hi, On Tue, Nov 17, 2015 at 10:58:36PM +0200, Nigel Titley wrote: > > If there is consensus otherwise to go forward, this will need a textual > > change that very clearly states in no unclear terms what can be done > > (and by omission, what can not be done), and another impact analysis - so, > > one extra round through the PDP. But it is not the first time that the > > IA uncovered wording that needs to be clarified "if read by an outsider", > > so it's good that we have it :-) > > And of course the NCC can't fix the problem. That is up to the community. Right. Erik to provide new text and the community to agree on that :-) And then the board to verify that we make our intentions really clear (thanks again). 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From valentin.panait at ch-center.com Thu Nov 19 21:14:45 2015 From: valentin.panait at ch-center.com (Valentin Panait) Date: Thu, 19 Nov 2015 22:14:45 +0200 Subject: [address-policy-wg] LIRs with good / bad behavior Message-ID: <564E2DB5.1090308@ch-center.com> Hello everyone, I`m Valentin Panait a newcommer in RIPE Community I work in Internet business from 10 years plus but now i join to you in forced conditions. Now I`m glad that i`m a part of this community and i regret that i don`t do this early. What force me to become RIPE NCC Member/ LIR? I think you know. Bad behavior of some other LIR. HOW? Simple. Make me invoice for my ip`s with almost 300% plus for next year. In this manner i have 3 choises 1. Pay , but after that i was risk to shutdown the bussines. 2. Go to another LIR but i have to renumbering everything and lost almost all clients and ... shut down the bussines 3. Become LIR and accept HIS offer to transfer from him only a half of my ip`s to my LIR for free and he remain with the other half. I need to choose to become LIR. Consequences on my side: Renumberig all clients who was on 3 /22 Lost 62 clients who pay aroud 180 euros/month eatch 2 painful months for technicians, admins, client support team, and ofcourse CLIENTS. Pay aroud 2000 euro to become LIR. Consequences on his side: 3 /22 free and can put them on the BLACK MARKET on min 3euros/IP ... you can calculate how much money... only from one client. And after finish to sold all blocks he will go to Dubai for 50 years on our money. But now on black market the price could be up to 22$/IP THIS IS A GOOD BEHAVIOR? THIS IS WHAT RIPE COMMUNITY WHANT? THIS RESPECT THE RIPE COMMUNITY RULES AND PRINCIPLES? I THINK THE ANSWER IS NO. If someone can count how much IPv4 is for sale on BLACK MARKET today, we will see how much IPv4 is free and can be realocated. Now of course everyone will say: OK but what can we do about this? We have do somethig to stop this black market. I have few ideas and i`ll share with you. About LIR`s with bad behavior make a PUBLIC list of LIR`s and folowing of abuse reports that we receive from LIR`s clients, give a good or bad ratings. RIPE become regulatory authority for maximum price that a LIR can invoice a client for mainteinance ip resources / year. A client who has some IP`s from a bad LIR and he make proof of that with the invoice or proforma, can be tranfered for free to another LIR where he agree LIR conditions or has a better offer. I could be agree to get 10$/year/resource even if it is IP block or ASN and with a long time contract if client whant this. Why? Because i am not agree with what is happend now. I think that everyone hwo has a good behavior should not be afect by this rules. But we need to eliminate or stop who think that the privilege that they have because are old LIR`s and have more IPv4 give them the rights to make frome this a hudge bussines. I think the Internet bussines is to make money from services that is hosted on IP not from the IP`s. PS: A funny mail arrive that sound like this (where is dots i delete private informations): " Hi! We are a ..... LIR and have 5 /22 (=5x 1024) IPs for lease for a very reasonable price (< 1 ?/ Ip/ month).The IPs are from the 185.0.0.0/8 block and have never been used before. They cannot be sold/ transferred as they are within the 24-month holding period. We are looking for a serious (no spam/ abuse), long-term cooperation (1+ year) only. If required, we could provide routing/ colocation/ server hosting too. I'm looking forward to your reply. Kind regards, ............." After my investigation He sad that have 5 /22 - WRONG on his Organisation Mainteiner and everything else that i found about him in RIPE database has only 1 IPv4 /22, 1 IPv6 /32, 2 ASN`s and a lot of mess on Inetnum`s how split that IPv4 /22. What happend with this guys? For this they become LIR to lease IP`s? I think in this case and could be more similar, we can create a WG to find this guys and report them someware. This is another place where we can find free block`s of IPv4. Let`s start to do somethig. Thank you very much that you lost your time to read this and i hope that all of you make a little time to reflect on my ideas. -- Best Regards, Valentin Panait System Administrator +40 741125871 www.ch-center.com ch-center ch-center Any disclosure, copying, distribution, posting or use of the contents of this information is prohibited and may be unlawful. This e-mail may contain proprietary or confidential information and is for the sole use of the intended recipient(s). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chlogo.gif Type: image/gif Size: 603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ripe.jpg Type: image/jpeg Size: 11943 bytes Desc: not available URL: From valentin.panait at ch-center.com Thu Nov 19 21:57:48 2015 From: valentin.panait at ch-center.com (Valentin Panait) Date: Thu, 19 Nov 2015 22:57:48 +0200 Subject: [address-policy-wg] LIRs with good / bad behavior In-Reply-To: <564E3274.5030600@netskin.com> References: <564E2DB5.1090308@ch-center.com> <564E3274.5030600@netskin.com> Message-ID: <564E37CC.2050301@ch-center.com> Hello Corin, In your case i understand but I still don`t understand why force small clients to become LIR only for a /22 and in some case they will not use entirely, when we can do something and fast i think to loose or get in front of user eyes all bad behavior LIRs and of course all rest of us to help clients, and of course help RIPE to get back all that blocks that is use now only for sale. And if you see from a customer perspective you can see cause is too expensive sometimes to become LIR for a /22 and use only /23 or even all /22. This is not a good way. On 11/19/2015 10:35 PM, Corin Langosch wrote: > Hi Valentin, > > if you read the address policy working groups emails/ archives from the past weeks you can see I'm clearly against the > ipv4 business/ market place too. We are not a LIR to make money of IP space, we do real ISP/ hosting business for > several years now. We are short of IPV4 as many other LIRs are, especially those who only got a single /22. That's why > we had to ask some of our customer to become LIRs themselves (just as you were, as it sounds). As they don't need the > *whole* space immediately themselves, why not help them lease it to those who need it - not for astronomic prices but > reasonable ones? This way the space is not wasted and no ones ripped off - in contrast to the behaviour of many old LIRs > with space of /19, /18 up to /8 just laying around for years and just waiting for better prices. > > Sorry again and I hope you got the point. > > Best, > Corin > > __________________________________________________________________________ > Netskin GmbH ? Trottenstrasse 89 ? 8037 Z?rich ? Switzerland > http://www.netskin.com ? fon +41 (0)32 513 40 24 ? fax +41 (0)32 513 28 21 > > Am 19.11.2015 um 21:14 schrieb Valentin Panait: > From sandra.sendra.upv at gmail.com Tue Nov 24 10:27:01 2015 From: sandra.sendra.upv at gmail.com (Sandra Sendra) Date: Tue, 24 Nov 2015 10:27:01 +0100 Subject: [address-policy-wg] CFP: 19th IEEE Global Internet Symposium (GI 2016) Message-ID: <201511240927.tAO9R0TR007962@smtp.upv.es> [Please accept our apologies if you receive multiple copies of this email] ######################################################################## CALL FOR PAPERs 19th IEEE Global Internet Symposium (GI 2016) In conjunction with IEEE INFOCOM 2016 San Francisco, CA, USA April 10-15, 2016 http://www.cs.helsinki.fi/group/eit-sdn/gi2016/ =========================================================== The Global Internet (GI) Symposium is the flagship event established and organized by the Internet Technical Committee (ITC), a joint committee of the IEEE Communications Society (ComSoc) and the Internet Society (ISOC). The 19th IEEE Global Internet Symposium will be collocated with IEEE Infocom 2016. All relevant dates, location, and travel information are available from the IEEE Infocom 2016 conference site:http://infocom2016.ieee-infocom.org/ The IEEE Global Internet Symposium aims to provide a top forum for researchers and practitioners to present and discuss advances in Internet related technologies. The focus of the symposium is on experimental systems and emerging future Internet technologies, and especially on scaling such systems to a global scale. Research on understanding Internet protocols, services, and applications at global scale is also encouraged. The Program Committee also welcomes position papers (which should be clearly marked as such). The topics of interest include, but are not limited to the following: Routing, switching, and addressing Resource management and quality of service Software defined networks and network programming Content delivery and management Energy awareness Next generation network architectures Distributed Internet applications including games, VoIP, and video conferencing Online social networking Peer To Peer networks Novel applications and new paradigms Internet measurement, modeling, and visualization Large scale network operation and performance monitoring Privacy and/or security issues on the Internet Anomaly, intrusion and attack detection Interface among networking, communications and information theory Applications of network science in communication networks Economic aspects of the Internet Important Dates: Paper submission: 22nd December 2015, 11:59 PM PST Notification of acceptance: 8th February 2016 Final manuscripts due: TBA. Symposium: TBA (around April 10-15, 2016) Submission Instructions: Submitted manuscripts must be formatted in standard IEEE camera ready format (doublecolumn,10pt font) and must be submitted via EDAS as PDF files (link https://edas.info/index.php?c=21740). The manuscripts must be no longer than 6 pages. The Program Committee reserves the right to not review papers that violate these formatting rules. Submitted papers must not have been previously published, or be under consideration for publication elsewhere. All submitted papers will be reviewed and judged on originality, technical correctness, relevance, and quality of presentation. All accepted papers must be presented at the symposium by one of the authors. Program Committee Chairs: Stefan Schmid (T-Labs & TU Berlin, Germany) Sasu Tarkoma (University of Helsinki, Finland) Technical Program Committee: Fred Baker (Cisco Systems, USA) Anat Bremler-Barr (IDC Herzliya, Israel) Ruben Cuevas Rumin (Universidad Carlos III de Madrid, Spain) Anja Feldmann (TU Berlin, Germany) Giancarlo Fortino (University of Calabria, Italy) Toru Hasegawa (Osaka University, Japan) James Kempf (Ericsson, USA) Kirill Kogan (IMDEA Networks Institute, Spain) Jaime Lloret Mauri (Polytechnic University of Valencia, Spain) Olaf Maennel (Tallinn University of Technology, Estonia) David Malone (Hamilton Institute, Ireland) Martin May (Technicolor, France) J?rg Ott (TU Munich, Germany) Colin Perkins (University of Glasgow, UK) George C. Polyzos (AUEB, Greece) Radia Perlman (EMC Corporation, USA) Ioannis Psaras (University College London, UK) Chen Qian (University of Kentucky, USA) Peter Reiher (UCLA, USA) Henning Schulzrinne (Columbia University, USA) Hiroshi Shigeno (Keio University, Japan) Michael Sirivianos (Cyprus University of Technology, Cyprus) Rade Stanojevic (Telefonica Research, Spain) Dan Wang (The Hong Kong Polytechnic University, Hong Kong) Gang Zhou (College of William and Mary, USA) ######################################################################## From gert at space.net Tue Nov 24 11:33:13 2015 From: gert at space.net (Gert Doering) Date: Tue, 24 Nov 2015 11:33:13 +0100 Subject: [address-policy-wg] CFP: 19th IEEE Global Internet Symposium (GI 2016) In-Reply-To: <201511240927.tAO9R0TR007962@smtp.upv.es> References: <201511240927.tAO9R0TR007962@smtp.upv.es> Message-ID: <20151124103313.GZ89490@Space.Net> Hi, On Tue, Nov 24, 2015 at 10:27:01AM +0100, Sandra Sendra wrote: > [Please accept our apologies if you receive multiple copies of this email] Actually, no. Please do not spam unrelated mailing lists. And this has NOTHING to do with address-policy. 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Tue Nov 24 11:55:44 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 24 Nov 2015 11:55:44 +0100 Subject: [address-policy-wg] CFP: 19th IEEE Global Internet Symposium (GI 2016) In-Reply-To: <20151124103313.GZ89490@Space.Net> References: <201511240927.tAO9R0TR007962@smtp.upv.es> <20151124103313.GZ89490@Space.Net> Message-ID: <56544230.4080508@schiefner.de> And to whom it may concern: can the sender address be put on moderation for the time being, please? Thanks. On 24.11.2015 11:33, Gert Doering wrote: > Hi, > > On Tue, Nov 24, 2015 at 10:27:01AM +0100, Sandra Sendra wrote: >> [Please accept our apologies if you receive multiple copies of this email] > > Actually, no. Please do not spam unrelated mailing lists. > > And this has NOTHING to do with address-policy. > > Gert Doering > -- APWG chair