From d.baeza at tvt-datos.es Mon Dec 1 09:25:58 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 01 Dec 2014 09:25:58 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <546B2CBC.20809@CC.UniVie.ac.at> <5478494E.6050806@cc.univie.ac.at> Message-ID: <547C2616.6010907@tvt-datos.es> At least Im not the only one saying IPv6 isnt really deployed. As you all can see, Only a 5% of Google traffic is v6. For sure, google is not the only one, but the most used search engine and their stats can give us an "external eye" to v6 deploy in the world. Again, the current v6 deploy makes me cry like a children. For that reason, I dont support this proposal. We, as community, must try to foment IPv6 over everything. If we dont do anything now, we'll pay in near future, when in 10 years v4 still being the "main protocol" instead of v6. Cheers, -Dani El 30/11/2014 15:38, Jan Ingvoldstad escribi?: > On Fri, Nov 28, 2014 at 11:26 AM, Randy Bush > wrote: > > > Take a look at > > e.g. http://www.vix.at/vix_participants.html?&no_cache=1&L=1, the > > column "IPv6 Routeserver activated". > > > > I presume it wouldn't be useful to have that configured, unless there > > is deployment in these ASNs. > > with all due respect, wilfred. iij has had a backbone configiured for > ipv6 since 1997. but that is anecdote not data. > > > Yep, data is much more useful. > > http://www.google.com/intl/en/ipv6/statistics.html > -- > Jan From frettled at gmail.com Mon Dec 1 09:38:52 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 1 Dec 2014 09:38:52 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <547C2616.6010907@tvt-datos.es> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <546B2CBC.20809@CC.UniVie.ac.at> <5478494E.6050806@cc.univie.ac.at> <547C2616.6010907@tvt-datos.es> Message-ID: On Mon, Dec 1, 2014 at 9:25 AM, Daniel Baeza (Red y Sistemas TVT) < d.baeza at tvt-datos.es> wrote: > At least Im not the only one saying IPv6 isnt really deployed. > I'm not saying it isn't really deployed, so if you counted me as some sort of support to your claim, you need to rethink that. > > As you all can see, Only a 5% of Google traffic is v6. > Did you look at the curve for the uptake of v6 traffic? You've been making theses "IPv6 isn't really deployed" claims for a pretty long time now. Meanwhile, IPv6 traffic at Google has more than tripled. Prediction: You'll be making the claim when IPv6 traffic is 10%, 20%, 40%, and even 50%. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.baeza at tvt-datos.es Mon Dec 1 10:10:41 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 01 Dec 2014 10:10:41 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <546B2CBC.20809@CC.UniVie.ac.at> <5478494E.6050806@cc.univie.ac.at> <547C2616.6010907@tvt-datos.es> Message-ID: <547C3091.2090409@tvt-datos.es> El 01/12/2014 9:38, Jan Ingvoldstad escribi?: > On Mon, Dec 1, 2014 at 9:25 AM, Daniel Baeza (Red y Sistemas TVT) > > wrote: > > At least Im not the only one saying IPv6 isnt really deployed. > > > I'm not saying it isn't really deployed, so if you counted me as some > sort of support to your claim, you need to rethink that. > > > As you all can see, Only a 5% of Google traffic is v6. > > > Did you look at the curve for the uptake of v6 traffic? Yes I did. > > You've been making theses "IPv6 isn't really deployed" claims for a > pretty long time now. Pretty long time? What is "long time" for you? Few months? A year? > > Meanwhile, IPv6 traffic at Google has more than tripled. Please, of course, from 1% to 2% is double. And from 1% to 5% is quintupled. But still being only a 5%... Will it keep the curve or will it relax? Dont really know, we'll see in the upcoming years. > Prediction: > > You'll be making the claim when IPv6 traffic is 10%, 20%, 40%, and even 50%. Bad prediction. Between 10% and 20%, for this year, I think is a good number. We are a very little ISP and around 15% of our traffic is v6 when only a half of our customers have v6 capable m?dems and from that 50%, not all of them have a v6 ready cpe(lot of winxp still outside). Of course, 99% of them is to google services (youtube,gmail,search...) and if we as little isp can do it, Im sure more big ISPs than us can do it too. So please, dont make predictions on what Im going to claim as you dont know me :) If you feel I said something not respectfull, Im very sorry, english is not my native language and sometimes is hard to me to explain what Im thinking with the proper words. To this topic, I love the signature of Gert: "have you enabled IPv6 on something today...?" Cheers, -- Daniel Baeza From ggiannou at gmail.com Mon Dec 1 10:30:34 2014 From: ggiannou at gmail.com (George Giannousopoulos) Date: Mon, 1 Dec 2014 11:30:34 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-02, "Allow PI transfer" In-Reply-To: References: Message-ID: Hello all, Please forgive me if I'm missing something, but shouldn't we implement some kind of PI Listing service, similar to the IPv4 Listing Service for Allocated PA space? Although the parties involved in the PI transfer might not be RIPE NCC Members, I think the RIPE NCC site is the appropriate place for someone to request or offer PI space blocks.. Kind regards, George On Tue, Nov 25, 2014 at 1:04 PM, Ioanna Spyroulia wrote: > > Dear colleagues, > > We are pleased to announce that we have implemented policy proposal > 2014-02, "Allow IPv4 PI transfer?. > > In accordance with the new policy, End Users can transfer complete or > partial blocks of Provider Independent (PI) IPv4 address space that were > previously assigned to them by the RIPE NCC. > > To initiate a PI transfer, the sponsoring LIR of either the transferring > or receiving End User should open a ticket with the RIPE NCC by sending an > email to lir-help at ripe.net. > > The procedure describing the requirements for PI transfers can be found at: > > https://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-of-assigned-pi-space > > The list of all PI assignments transferred under this policy can be found > at: > > https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers > > The archived policy proposal can be found at: > https://www.ripe.net/ripe/policies/proposals/2014-02 > > The updated RIPE Document, "IPv4 Address Allocation and Assignment > Policies for the RIPE NCC Service Region", is available at: > https://www.ripe.net/ripe/docs/ripe-623 > > > Kind regards, > > Ioanna Spyroulia > RIPE NCC Registration Services > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Dec 1 12:58:47 2014 From: gert at space.net (Gert Doering) Date: Mon, 1 Dec 2014 12:58:47 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <547C2616.6010907@tvt-datos.es> References: <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <546B2CBC.20809@CC.UniVie.ac.at> <5478494E.6050806@cc.univie.ac.at> <547C2616.6010907@tvt-datos.es> Message-ID: <20141201115847.GD28745@Space.Net> Hi, On Mon, Dec 01, 2014 at 09:25:58AM +0100, Daniel Baeza (Red y Sistemas TVT) wrote: > For that reason, I dont support this proposal. > > We, as community, must try to foment IPv6 over everything. I agree that we need to see more IPv6 deployment. As far as your opposition to the proposal goes, I consider it to be heard and addressed (because the group considers the requirements in the current policy to be insufficient to actually further IPv6 deployment, and as such, sticking to it is not helping to reach that goal). Since there is quite strong support otherwise, and we only need *rough* consensus, we'll go forward with it anyway. Consensus does not have to be unanimous. 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 d.baeza at tvt-datos.es Mon Dec 1 13:16:27 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 01 Dec 2014 13:16:27 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141201115847.GD28745@Space.Net> References: <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <546B2CBC.20809@CC.UniVie.ac.at> <5478494E.6050806@cc.univie.ac.at> <547C2616.6010907@tvt-datos.es> <20141201115847.GD28745@Space.Net> Message-ID: <547C5C1B.2040009@tvt-datos.es> El 01/12/2014 12:58, Gert Doering escribi?: > Hi, > > On Mon, Dec 01, 2014 at 09:25:58AM +0100, Daniel Baeza (Red y Sistemas TVT) wrote: >> For that reason, I dont support this proposal. >> >> We, as community, must try to foment IPv6 over everything. > > I agree that we need to see more IPv6 deployment. Thanks :D > As far as your opposition to the proposal goes, I consider it to be > heard and addressed (because the group considers the requirements in > the current policy to be insufficient to actually further IPv6 deployment, > and as such, sticking to it is not helping to reach that goal). Im ok with that. I was just pointing my reasons. > Since there is quite strong support otherwise, and we only need *rough* > consensus, we'll go forward with it anyway. Consensus does not have > to be unanimous. Agree. If there is consensus the proposal should go forward. :) -- Daniel Baeza From a.sakun at infomir.eu Mon Dec 1 22:13:25 2014 From: a.sakun at infomir.eu (Sakun Alexey) Date: Mon, 01 Dec 2014 23:13:25 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-02, "Allow PI transfer" Message-ID: <547CD9F5.8030800@infomir.eu> Hi! My question is: is it possible in accordance with a new policy to transfer PI-block from End User to LIR, not to another End User? So LIR becomes valid owner of PI-block and then convertes this PI block to PA in accordance with this procedure: http://www.ripe.net/lir-services/resource-management/converting-pi-to-pa. Here, https://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-of-assigned-pi-space it is written : ... Any legitimate holder of IPv4 PI space can transfer this to another End User or _*MEMBER*_ in the RIPE NCC service region, provided:.. As i understand - it is possible? Thank you. -- Best regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Mon Dec 1 23:12:40 2014 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Mon, 1 Dec 2014 23:12:40 +0100 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-02, "Allow PI transfer" In-Reply-To: <547CD9F5.8030800@infomir.eu> References: <547CD9F5.8030800@infomir.eu> Message-ID: <853A968D-1B19-4B04-85AA-B000880B9FC8@a2b-internet.com> Hi Alexey, A LIR can have infrastructure on PI address space. So, yes. The LIR in that case is the end-user. And PI spaces assigned to the LIR entity can be changed to PA. Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 1 dec. 2014 om 22:13 heeft Sakun Alexey het volgende geschreven: > > Hi! > > My question is: is it possible in accordance with a new policy to transfer PI-block from End User to LIR, not to another End User? So LIR becomes valid owner of PI-block and then > convertes this PI block to PA in accordance with this procedure: http://www.ripe.net/lir-services/resource-management/converting-pi-to-pa. > > Here, > https://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-of-assigned-pi-space > > it is written : ... Any legitimate holder of IPv4 PI space can transfer this to another End User or MEMBER in the RIPE NCC service region, provided:.. > > As i understand - it is possible? > > Thank you. > -- > Best regards, > Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Tue Dec 2 09:58:44 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 2 Dec 2014 09:58:44 +0100 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-02, "Allow PI transfer" In-Reply-To: References: Message-ID: <004101d00e0e$354c2ca0$9fe485e0$@a2b-internet.com> Hi George, There is a statistics page for the PI transfers. You can click on the tab at the top of the table : https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers As for a listing page for PA space, that is not public, but in the LIR portal. And that also has email addresses and phone numbers. Maybe not everyone would like to see that kind of information publicly published. And for PI holders, most of them don?t have an LIR account. Perhaps that would be something that Alex Band might be able to look into, to see if they can fit it into the LIR portal with the same authentication as that they use for RPKI setup for PI holders. I would see that as a Services-WG request and not a AP-WP discussion. Regards, Erik Bais Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens George Giannousopoulos Verzonden: maandag 1 december 2014 10:31 Aan: Ioanna Spyroulia CC: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] Policy Proposal Implemented: 2014-02, "Allow PI transfer" Hello all, Please forgive me if I'm missing something, but shouldn't we implement some kind of PI Listing service, similar to the IPv4 Listing Service for Allocated PA space? Although the parties involved in the PI transfer might not be RIPE NCC Members, I think the RIPE NCC site is the appropriate place for someone to request or offer PI space blocks.. Kind regards, George On Tue, Nov 25, 2014 at 1:04 PM, Ioanna Spyroulia > wrote: Dear colleagues, We are pleased to announce that we have implemented policy proposal 2014-02, "Allow IPv4 PI transfer?. In accordance with the new policy, End Users can transfer complete or partial blocks of Provider Independent (PI) IPv4 address space that were previously assigned to them by the RIPE NCC. To initiate a PI transfer, the sponsoring LIR of either the transferring or receiving End User should open a ticket with the RIPE NCC by sending an email to lir-help at ripe.net . The procedure describing the requirements for PI transfers can be found at: https://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-of-assigned-pi-space The list of all PI assignments transferred under this policy can be found at: https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers The archived policy proposal can be found at: https://www.ripe.net/ripe/policies/proposals/2014-02 The updated RIPE Document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is available at: https://www.ripe.net/ripe/docs/ripe-623 Kind regards, Ioanna Spyroulia RIPE NCC Registration Services -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggiannou at gmail.com Wed Dec 3 10:07:55 2014 From: ggiannou at gmail.com (George Giannousopoulos) Date: Wed, 3 Dec 2014 11:07:55 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-02, "Allow PI transfer" In-Reply-To: <004101d00e0e$354c2ca0$9fe485e0$@a2b-internet.com> References: <004101d00e0e$354c2ca0$9fe485e0$@a2b-internet.com> Message-ID: Hi Erik, I get your point and I fully agree. My initial though was about creating a new listing page for non RIPE-NCC members, as part of the new policy implementation. Apparently, we have to deal with it separately. I'll start a discussion in the Services-WG list as you suggest. Regards, George On Tue, Dec 2, 2014 at 10:58 AM, Erik Bais wrote: > Hi George, > > > > There is a statistics page for the PI transfers. > > > > You can click on the tab at the top of the table : > > > https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers > > > > As for a listing page for PA space, that is not public, but in the LIR > portal. > > And that also has email addresses and phone numbers. Maybe not everyone > would like to see that kind of information publicly published. > > > > And for PI holders, most of them don?t have an LIR account. Perhaps that > would be something that Alex Band might be able to look into, to see if > they can fit it into the LIR portal with the same authentication as that > they use for RPKI setup for PI holders. > > > > I would see that as a Services-WG request and not a AP-WP discussion. > > > > Regards, > > Erik Bais > > > > *Van:* address-policy-wg-bounces at ripe.net [mailto: > address-policy-wg-bounces at ripe.net] *Namens *George Giannousopoulos > *Verzonden:* maandag 1 december 2014 10:31 > *Aan:* Ioanna Spyroulia > *CC:* address-policy-wg at ripe.net > *Onderwerp:* Re: [address-policy-wg] Policy Proposal Implemented: > 2014-02, "Allow PI transfer" > > > > Hello all, > > > > Please forgive me if I'm missing something, but shouldn't we implement > some kind of PI Listing service, similar to the IPv4 Listing Service for > Allocated PA space? > > > > Although the parties involved in the PI transfer might not be RIPE NCC > Members, I think the RIPE NCC site is the appropriate place for someone to > request or offer PI space blocks.. > > > > Kind regards, > > George > > > > On Tue, Nov 25, 2014 at 1:04 PM, Ioanna Spyroulia > wrote: > > > > Dear colleagues, > > We are pleased to announce that we have implemented policy proposal > 2014-02, "Allow IPv4 PI transfer?. > > > In accordance with the new policy, End Users can transfer complete or > partial blocks of Provider Independent (PI) IPv4 address space that were > previously assigned to them by the RIPE NCC. > > To initiate a PI transfer, the sponsoring LIR of either the transferring > or receiving End User should open a ticket with the RIPE NCC by sending an > email to lir-help at ripe.net. > > The procedure describing the requirements for PI transfers can be found at: > > https://www.ripe.net/lir-services/resource-management/ipv4-transfers/transfer-of-assigned-pi-space > > The list of all PI assignments transferred under this policy can be found > at: > > https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers > > The archived policy proposal can be found at: > https://www.ripe.net/ripe/policies/proposals/2014-02 > > The updated RIPE Document, "IPv4 Address Allocation and Assignment > Policies for the RIPE NCC Service Region", is available at: > https://www.ripe.net/ripe/docs/ripe-623 > > > Kind regards, > > Ioanna Spyroulia > > RIPE NCC Registration Services > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Tue Dec 9 16:20:30 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 09 Dec 2014 16:20:30 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: Dear colleagues, The draft document for version 3.0 of the policy proposal 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8", has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 2.0 include: - Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC - Related wording adjustments in the title, summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-04 The draft document is available at: https://www.ripe.net/ripe/policies/proposals/2014-04/draft We encourage you to read the draft document and send any comments to address-policy-wg at ripe.net before 7 January 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Tue Dec 9 17:12:07 2014 From: nick at inex.ie (Nick Hilliard) Date: Tue, 09 Dec 2014 16:12:07 +0000 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <54871F57.7050908@inex.ie> On 09/12/2014 15:20, Marco Schmidt wrote: > - Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC > - Related wording adjustments in the title, summary and rationale of the proposal support. Nick From ak at list.ak.cx Tue Dec 9 18:41:45 2014 From: ak at list.ak.cx (Andre Keller) Date: Tue, 09 Dec 2014 18:41:45 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <54873459.3010700@list.ak.cx> Hi, On 09.12.2014 16:20, Marco Schmidt wrote: > - Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC > - Related wording adjustments in the title, summary and rationale of the proposal I support these changes and the proposal as it now stands. Regards Andr? From dr at cluenet.de Tue Dec 9 23:29:10 2014 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 9 Dec 2014 23:29:10 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <20141209222910.GA22806@srv03.cluenet.de> On Tue, Dec 09, 2014 at 04:20:30PM +0100, Marco Schmidt wrote: > The draft document for version 3.0 of the policy proposal 2014-04, > "Removing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. Supported. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From hamed at skydsl.ir Wed Dec 10 06:13:40 2014 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Wed, 10 Dec 2014 08:43:40 +0330 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: +1 Support -- -------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Dec 10 07:08:48 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Dec 2014 07:08:48 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <20141210070848.5c2c9244@envy.fud.no> * Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-04 It's been shown that the current /22 IPv6 requirement causes difficulties in a particular corner case where the applicant has actually already obtained an IPv6 non-PA delegation and are most likely making use of it too (since returning/renumbering is problematic). This is exactly the opposite of the desired effect of fostering IPv6 deployment, indeed, it could be considered as penalising IPv6 deployment. I believe that at this point in time, the community's awareness and use of IPv6 isn't likely to increase further by keeping the /22 IPv6 requirement. In a nutshell: LIRs who have no interest in IPv6 won't start actual deployment even if the /22 IPv6 requirement forces them to obtain an IPv6 allocation, while LIRs who do have an interest in IPv6 will be perfectly able to obtain and deploy IPv6 without the /22 IPv6 requirement present. Given the above, I think it is time to remove it completely. That seems the simplest and cleanest solution. +1 Tore From st at sct.de Wed Dec 10 12:42:16 2014 From: st at sct.de (Stefan Schiele) Date: Wed, 10 Dec 2014 12:42:16 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <54883198.1020205@sct.de> Hi, Am 09.12.2014 um 16:20 schrieb Marco Schmidt: > - Removal of the IPv6 requirement to receive Pv4 addresses from the RIPE NCC > - Related wording adjustments in the title, summary and rationale of the proposal I do not agree with this proposal. Let me explain that with a simple case: Our company is a LIR for just a few month now; the main reason why we signed up on April this year was that we started to run out of IP addresses and wanted to get that /22 IPv4 allocation (we already had a /24). And for us the only reason to deploy IPv6 was that we had to request an allocation in the first place. In our case we are a software company and we provide hosting services only for our existing customers and for our own software; therefore, the additional /22 IPv4 allocation that we received is suitable to expand our business and still have enough IPv4 address space for a long time. So, actually, we don't need IPv6 yet; and the chances are quite high that if we did not had to request the IPv6 allocation we would still be living happily with IPv4 only. Everyone who decided to deploy IPv6 will automatically inform others. A lot of our customers didn't even know that IPv6 exists; so they need other companies to inform them why they need it and why they should be concerned about it. Additionally we noticed that selling IPv6 is not even for our upstream providers a common process. They are capable of providing IPv6 and generally it works quite fine; however, there is a slight difference between anyone who's keen to sell his company's services and anyone who's fine with selling services if the customer is willing to pay for it. And from my experience the first one applies to IPv4 and the second one to IPv6. There are about 1000 new LIRs per year; if only this new LIRs would have to request an IPv6 allocation I believe that a lot of them would want to have this IPv6 allocation set up an running even if it's only because they've received it (as it was the case for our company). And the same applies to any existing LIR requesting their last /22. From my point of view, the removal of the IPv6 requirement would slow down the process of deploying IPv6; the more everyone is talking about IPv6 to customers as well as to other providers (especially upstream providers) the more public awareness of IPv6 increases and the more selling and buying IPv6 services goes without saying - and that's what we need. Kind Regards, Stefan Schiele -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Dec 10 14:11:27 2014 From: sander at steffann.nl (Sander Steffann) Date: Wed, 10 Dec 2014 14:11:27 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <54883198.1020205@sct.de> References: <54883198.1020205@sct.de> Message-ID: <8699E06B-335E-4415-984C-832CD2A3412E@steffann.nl> Hi Stefan, > Let me explain that with a simple case: Our company is a LIR for just a few month now; the main reason why we signed up on April this year was that we started to run out of IP addresses and wanted to get that /22 IPv4 allocation (we already had a /24). And for us the only reason to deploy IPv6 was that we had to request an allocation in the first place. > > [...] > > From my point of view, the removal of the IPv6 requirement would slow down the process of deploying IPv6; the more everyone is talking about IPv6 to customers as well as to other providers (especially upstream providers) the more public awareness of IPv6 increases and the more selling and buying IPv6 services goes without saying - and that's what we need. I fully agree that there is need for public awareness for IPv6 deployment. However, I think there are better ways for causing awareness and get people talking about IPv6 etc than doing this in address policy. I would suggest that we ask the RIPE NCC to increase their outreach to LIRs that don't have any IPv6 address space, explain the need for IPv6 deployment, promote the trainings provided by the RIPE NCC etc. Just because a RIPE policy doesn't require an LIR to request IPv6 space anymore doesn't mean that the RIPE NCC cannot promote IPv6, especially if we as a community ask them to. Cheers, Sander From ebais at a2b-internet.com Wed Dec 10 14:21:13 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 10 Dec 2014 14:21:13 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <003d01d0147c$32313410$96939c30$@a2b-internet.com> Support +1 From stolpe at resilans.se Wed Dec 10 14:59:32 2014 From: stolpe at resilans.se (Daniel Stolpe) Date: Wed, 10 Dec 2014 14:59:32 +0100 (CET) Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141210070848.5c2c9244@envy.fud.no> References: <20141210070848.5c2c9244@envy.fud.no> Message-ID: On Wed, 10 Dec 2014, Tore Anderson wrote: > * Marco Schmidt > >> https://www.ripe.net/ripe/policies/proposals/2014-04 > > It's been shown that the current /22 IPv6 requirement causes difficulties > in a particular corner case where the applicant has actually already > obtained an IPv6 non-PA delegation and are most likely making use of it > too (since returning/renumbering is problematic). This is exactly the > opposite of the desired effect of fostering IPv6 deployment, indeed, it > could be considered as penalising IPv6 deployment. > > I believe that at this point in time, the community's awareness and use > of IPv6 isn't likely to increase further by keeping the /22 IPv6 > requirement. In a nutshell: LIRs who have no interest in IPv6 won't > start actual deployment even if the /22 IPv6 requirement forces them to > obtain an IPv6 allocation, while LIRs who do have an interest in IPv6 > will be perfectly able to obtain and deploy IPv6 without the /22 IPv6 > requirement present. > > Given the above, I think it is time to remove it completely. That seems > the simplest and cleanest solution. > > +1 > > Tore Very well put. +1 Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From mike at iptrading.com Wed Dec 10 16:13:18 2014 From: mike at iptrading.com (Mike Burns) Date: Wed, 10 Dec 2014 10:13:18 -0500 Subject: [address-policy-wg] 2014-04 New Draft Document and ImpactAnalysis Published (Removing IPv6 Requirement for ReceivingSpace from the Final /8) In-Reply-To: <003d01d0147c$32313410$96939c30$@a2b-internet.com> References: <003d01d0147c$32313410$96939c30$@a2b-internet.com> Message-ID: <670937578BE544A9941D58845A16A09C@MPC> Support. The marginal public awareness utility of the IPv6 requirement is not worth the policy verbiage. Well-intentioned but inappropriate use of policy to burden members with unwanted IPv6 space. It's like I want a piece of cake and mother says okay, but you must also take some more vegetables. The vegetables remain on the plate, uneaten and destined for the garbage, because mother thinks I might try them and like them. I would change my mother's policy if I could! -----Original Message----- From: Erik Bais Sent: Wednesday, December 10, 2014 8:21 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-04 New Draft Document and ImpactAnalysis Published (Removing IPv6 Requirement for ReceivingSpace from the Final /8) Support +1 From gert at space.net Wed Dec 10 20:02:10 2014 From: gert at space.net (Gert Doering) Date: Wed, 10 Dec 2014 20:02:10 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <54883198.1020205@sct.de> References: <54883198.1020205@sct.de> Message-ID: <20141210190210.GF28745@Space.Net> Hi, On Wed, Dec 10, 2014 at 12:42:16PM +0100, Stefan Schiele wrote: > Let me explain that with a simple case: Our company is a LIR for just a > few month now; the main reason why we signed up on April this year was > that we started to run out of IP addresses and wanted to get that /22 > IPv4 allocation (we already had a /24). And for us the only reason to > deploy IPv6 was that we had to request an allocation in the first place. So did you actually *deploy* IPv6, as in "every new service you run and install has IPv6 on it, every new product you build supports IPv6", or did you just *get* an IPv6 block, put it on a shelf, and leave it there? I'm impressed if our existing policy actually had such a big impact, and it wasn't just "the last nudge to get going" - which we could easily achieve by having the NCC IPRAs ensure that LIRs asking for a /22 are aware of IPv6 ("have you considered deploying IPv6?"). 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 martin.pels at ams-ix.net Thu Dec 11 09:36:17 2014 From: martin.pels at ams-ix.net (Martin Pels) Date: Thu, 11 Dec 2014 09:36:17 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <54883198.1020205@sct.de> References: <54883198.1020205@sct.de> Message-ID: <20141211093617.4632c049@fizzix> Hi Stefan, On Wed, 10 Dec 2014 12:42:16 +0100 Stefan Schiele wrote: > There are about 1000 new LIRs per year; if only this new LIRs would have > to request an IPv6 allocation I believe that a lot of them would want to > have this IPv6 allocation set up an running even if it's only because > they've received it (as it was the case for our company). And the same > applies to any existing LIR requesting their last /22. > > From my point of view, the removal of the IPv6 requirement would slow > down the process of deploying IPv6; the more everyone is talking about > IPv6 to customers as well as to other providers (especially upstream > providers) the more public awareness of IPv6 increases and the more > selling and buying IPv6 services goes without saying - and that's what > we need. The proposal does not preclude the RIPE NCC from mentioning to LIRs who request their last /22 that there is such a thing as IPv6 and that an LIR can get an IPv6 allocation with one click if they want it. This can be done as part of the increased outreach that the impact analysis talks about. Kind regards, Martin From ggiannou at gmail.com Thu Dec 11 09:56:54 2014 From: ggiannou at gmail.com (George Giannousopoulos) Date: Thu, 11 Dec 2014 10:56:54 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141211093617.4632c049@fizzix> References: <54883198.1020205@sct.de> <20141211093617.4632c049@fizzix> Message-ID: Hi, I support, provided that the RIPE NCC will inform the applicants about IPv6. Regards, George On Thu, Dec 11, 2014 at 10:36 AM, Martin Pels wrote: > Hi Stefan, > > On Wed, 10 Dec 2014 12:42:16 +0100 > Stefan Schiele wrote: > > > There are about 1000 new LIRs per year; if only this new LIRs would have > > to request an IPv6 allocation I believe that a lot of them would want to > > have this IPv6 allocation set up an running even if it's only because > > they've received it (as it was the case for our company). And the same > > applies to any existing LIR requesting their last /22. > > > > From my point of view, the removal of the IPv6 requirement would slow > > down the process of deploying IPv6; the more everyone is talking about > > IPv6 to customers as well as to other providers (especially upstream > > providers) the more public awareness of IPv6 increases and the more > > selling and buying IPv6 services goes without saying - and that's what > > we need. > > The proposal does not preclude the RIPE NCC from mentioning to LIRs who > request > their last /22 that there is such a thing as IPv6 and that an LIR can get > an > IPv6 allocation with one click if they want it. This can be done as part > of the > increased outreach that the impact analysis talks about. > > Kind regards, > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From st at sct.de Thu Dec 11 10:00:26 2014 From: st at sct.de (Stefan Schiele) Date: Thu, 11 Dec 2014 10:00:26 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <8699E06B-335E-4415-984C-832CD2A3412E@steffann.nl> References: <54883198.1020205@sct.de> <8699E06B-335E-4415-984C-832CD2A3412E@steffann.nl> Message-ID: <54895D2A.7070304@sct.de> Hi Sander, Am 10.12.2014 um 14:11 schrieb Sander Steffann: > I fully agree that there is need for public awareness for IPv6 deployment. However, I think there are better ways for causing awareness and get people talking about IPv6 etc than doing this in address policy. > > I would suggest that we ask the RIPE NCC to increase their outreach to LIRs that don't have any IPv6 address space, explain the need for IPv6 deployment, promote the trainings provided by the RIPE NCC etc. Just because a RIPE policy doesn't require an LIR to request IPv6 space anymore doesn't mean that the RIPE NCC cannot promote IPv6, especially if we as a community ask them to. I would love to see the RIPE NCC doing more to promote IPv6. I've visited training courses a few months ago; and I was told that it's our job as LIRs to promote IPv6 to our customers. In my opinion that sounds quite reasonable; the RIPE NCC can only reach the LIRs; the LIRs are the ones that can improve their customers awareness. Therefore I would say that the RIPE NCC needs the help of as much LIRs as possible to be able to increase general IPv6 deployment. Mike had a very good example with a cake and vegetables: It might be an annoyance if you have to eat more vegetables in order to get a piece of cake; but, if mothers in general wouldn't care about their children's nutrition a lot of us folks would end up eating fast food all the time and in the end suffering from several severe diseases. Regards, Stefan From st at sct.de Thu Dec 11 10:19:37 2014 From: st at sct.de (Stefan Schiele) Date: Thu, 11 Dec 2014 10:19:37 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141210190210.GF28745@Space.Net> References: <54883198.1020205@sct.de> <20141210190210.GF28745@Space.Net> Message-ID: <548961A9.7040909@sct.de> Hi Gert, Am 10.12.2014 um 20:02 schrieb Gert Doering: > So did you actually*deploy* IPv6, as in "every new service you run and > install has IPv6 on it, every new product you build supports IPv6", or > did you just*get* an IPv6 block, put it on a shelf, and leave it there? > > I'm impressed if our existing policy actually had such a big impact, > and it wasn't just "the last nudge to get going" - which we could easily > achieve by having the NCC IPRAs ensure that LIRs asking for a /22 are > aware of IPv6 ("have you considered deploying IPv6?"). We really deployed IPv6 ;-) All servers used for customer software solutions and except for one service all our other services are IPv6 enabled. For sure, we still have some servers in our internal network that are not IPv6 capable (e.g. some print servers); for IPv6 we currently focus on everything that is publicly accessible (and on core components, for sure). Servers that are only used internally get IPv6 enabled on the next OS update or at the time the server will be replaced. I get your point that there is no use in allocation IPv6 space to an LIR if that space is not used; do you know whether statistical data is available how much IPv6 address space that has been allocated to those LIRs which requested their final /22 is actually visible in the BGP routing tables? Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea at ripe.net Thu Dec 11 12:24:16 2014 From: andrea at ripe.net (Andrea Cima) Date: Thu, 11 Dec 2014 12:24:16 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <548961A9.7040909@sct.de> References: <54883198.1020205@sct.de> <20141210190210.GF28745@Space.Net> <548961A9.7040909@sct.de> Message-ID: <54897EE0.2080908@ripe.net> Hi Stefan, On 11/12/14 10:19, Stefan Schiele wrote: > I get your point that there is no use in allocation IPv6 space to an > LIR if that space is not used; do you know whether statistical data is > available how much IPv6 address space that has been allocated to those > LIRs which requested their final /22 is actually visible in the BGP > routing tables? The RIPE NCC has started allocating /22s from the last /8 on 14 September 2012. Since then 4190 IPv6 allocations have been made, out of which 1160 are currently visible in the BGP routing tables. If we take into consideration the total number of IPv6 allocations made by the RIPE NCC, 8398 IPv6 allocations have been made, out of which 4098 are currently visible in the BGP routing tables. I hope this helps. Best regards, Andrea Cima RIPE NCC From mschmidt at ripe.net Thu Dec 11 15:25:06 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 11 Dec 2014 15:25:06 +0100 Subject: [address-policy-wg] 2014-07 New Draft Document and Impact Analysis Published (Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region") Message-ID: Dear colleagues, The proposal described in 2014-07, "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-07 The draft document is available at: https://www.ripe.net/ripe/policies/proposals/2014-07/draft We encourage you to read the draft document and send any comments to address-policy-wg at ripe.net before 9 January 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Dec 11 15:31:00 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 11 Dec 2014 15:31:00 +0100 Subject: [address-policy-wg] 2014-08 New Draft Document and Impact Analysis Published (Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region") Message-ID: Dear colleagues, The proposal described in 2014-08, "Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region"", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-08 The draft document is available at: https://www.ripe.net/ripe/policies/proposals/2014-08/draft We encourage you to read the draft document and send any comments to address-policy-wg at ripe.net before 9 January 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Dec 11 15:39:24 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 11 Dec 2014 15:39:24 +0100 Subject: [address-policy-wg] 2014-10 New Draft Document and Impact Analysis Published (Language Clarification in "IPv6 Addresses for Internet Root Servers In The RIPE Region") Message-ID: Dear colleagues, The proposal described in 2014-10, "Language Clarification in "IPv6 Addresses for Internet Root Servers In The RIPE Region"", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-10 The draft document is available at: https://www.ripe.net/ripe/policies/proposals/2014-10/draft We encourage you to read the draft document and send any comments to address-policy-wg at ripe.net before 9 January 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Dec 11 15:42:23 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 11 Dec 2014 15:42:23 +0100 Subject: [address-policy-wg] 2014-11 New Draft Document and Impact Analysis Published (Language Clarification for "Allocating/Assigning Resources to the RIPE NCC") Message-ID: Dear colleagues, The proposal described in 2014-11, "Language Clarification for "Allocating/Assigning Resources to the RIPE NCC"", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-11 The draft document is available at: https://www.ripe.net/ripe/policies/proposals/2014-11/draft We encourage you to read the draft document and send any comments to address-policy-wg at ripe.net before 9 January 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Thu Dec 11 15:49:30 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 11 Dec 2014 14:49:30 +0000 Subject: [address-policy-wg] Language clarification proposal Message-ID: <5489AEFA.4040907@inex.ie> 2014-07: support 2014-08: support 2014-10: support 2014-11: support Nick From d.baeza at tvt-datos.es Fri Dec 12 10:53:32 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Fri, 12 Dec 2014 10:53:32 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <548ABB1C.3040700@tvt-datos.es> I dont agree. -- Daniel Baeza From ripe-wgs.cs at schiefner.de Fri Dec 12 12:22:55 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 12 Dec 2014 12:22:55 +0100 Subject: [address-policy-wg] Language clarification proposal In-Reply-To: <5489AEFA.4040907@inex.ie> References: <5489AEFA.4040907@inex.ie> Message-ID: <548AD00F.6060403@schiefner.de> On 11.12.2014 15:49, Nick Hilliard wrote: > 2014-07: support > 2014-08: support > 2014-10: support > 2014-11: support Ditto for all four of them. Best, -C. From sander at steffann.nl Sat Dec 13 20:48:35 2014 From: sander at steffann.nl (Sander Steffann) Date: Sat, 13 Dec 2014 20:48:35 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <548ABB1C.3040700@tvt-datos.es> References: <548ABB1C.3040700@tvt-datos.es> Message-ID: <38FF53C0-5AB0-4D28-ADA9-DBBBC9511234@steffann.nl> Hi Daniel, > Op 12 dec. 2014, om 10:53 heeft Daniel Baeza (Red y Sistemas TVT) het volgende geschreven: > > I dont agree. With what exactly? We make policy based on arguments. Please provide us (=this list) with arguments why you don't agree so they can be discussed. Thanks! Sander From d.baeza at tvt-datos.es Sun Dec 14 11:02:36 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Sun, 14 Dec 2014 11:02:36 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <38FF53C0-5AB0-4D28-ADA9-DBBBC9511234@steffann.nl> References: <548ABB1C.3040700@tvt-datos.es> <38FF53C0-5AB0-4D28-ADA9-DBBBC9511234@steffann.nl> Message-ID: <548D603C.9080808@tvt-datos.es> Hi Sander, Sorry, I thought all on the list knew my position about that. I will stole the arguments from Stefan Schiele. I hope he doesnt mind. In our case, we are not a software company providing hosting. We are a little Local ISP in an "small" town (arround 100k population) and same as Stefan Schiele, we runned out of IPv4 and our transit provider, in that moment, couldnt gave us more. Until that moment, I never cared out about IPv6. Only when we was "forced" to have an alloc of IPv6 I cared and thinked about it. Now, I consider myself an IPv6 warrior. >Andrea Cima wrote: >The RIPE NCC has started allocating /22s from the last /8 on 14 >September 2012. Since then 4190 IPv6 allocations have been made, out >of which 1160 are currently visible in the BGP routing tables. That means arround 27%. To be honest, I thought a really lower numbers before Andrea said the real ones. Taking into account the current IPv6 deployment rate, I'm more convinced we need the current requisite of having an IPv6 alloc to request the last /22. The only argument supporting the proposal: >In order to receive an allocation from the final /8, LIRs are >currently required to have received an IPv6 allocation. This >requirement was originally meant to foster IPv6 deployment. However, >in some cases it does the reverse. If LIRs have an existing IPv6 PI >assignment but no IPv6 PA allocation, they do not meet this criterion. >In order to qualify, they need to request an IPv6 allocation and >subsequently return their existing PI assignment (per ripe-589 section >7.1). The problem is LIRs with PI space dont having the requirements to recieve the v4 /22 from the last /8. Why just dont allow PI assignment to be valid to recieve an alloc from the final /8? >Since there is a huge difference between having received an IPv6 >allocation and actually deploying IPv6, there is doubt that the >requirement has in fact lead to wider IPv6 adoption. A 27% from a total of ~50% alloc/published ipv6 that will be lost in the current v6 deployment. TL;DR Requesting an IPv6 allocation dont takes time, its only a procedure. The 27% of LIRs who did the procedure have IPv6 published in BGP and I hope at least half of them have it working too. Just allowing v6PI space to be valid to recieve the /22 from last /8 is easier. And those are my arguments. PD: You asked for them, now you read it! :D El 13/12/2014 20:48, Sander Steffann escribi?: > Hi Daniel, > >> Op 12 dec. 2014, om 10:53 heeft Daniel Baeza (Red y Sistemas TVT) het volgende geschreven: >> >> I dont agree. > > With what exactly? We make policy based on arguments. Please provide us (=this list) with arguments why you don't agree so they can be discussed. > > Thanks! > Sander > -- Daniel Baeza From sander at steffann.nl Sun Dec 14 13:44:20 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 14 Dec 2014 13:44:20 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <548D603C.9080808@tvt-datos.es> References: <548ABB1C.3040700@tvt-datos.es> <38FF53C0-5AB0-4D28-ADA9-DBBBC9511234@steffann.nl> <548D603C.9080808@tvt-datos.es> Message-ID: Hi Daniel, > PD: You asked for them, now you read it! :D Much appreciated! :) Sander From pk at DENIC.DE Sun Dec 14 19:58:44 2014 From: pk at DENIC.DE (Peter Koch) Date: Sun, 14 Dec 2014 19:58:44 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141210190210.GF28745@Space.Net> References: <54883198.1020205@sct.de> <20141210190210.GF28745@Space.Net> Message-ID: <20141214185844.GZ19829@x28.adm.denic.de> On Wed, Dec 10, 2014 at 08:02:10PM +0100, Gert Doering wrote: > So did you actually *deploy* IPv6, as in "every new service you run and > install has IPv6 on it, every new product you build supports IPv6", or > did you just *get* an IPv6 block, put it on a shelf, and leave it there? it appears to me this is asking for more than what was aimed at. If memory serves the idea was to get the message through, even by pushing the issue through LIRs' internal escalation chains. Now, there are some odd conditions with PI holders that need attention and change, but the proposal declares defeat for a non-goal of the current policy. -Peter From ripe.address-policy-wg at ml.karotte.org Mon Dec 15 15:21:52 2014 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Mon, 15 Dec 2014 15:21:52 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: Message-ID: <20141215142152.GC22316@danton.fire-world.de> * Marco Schmidt [2014-12-09 16:30]: > > Dear colleagues, > > The draft document for version 3.0 of the policy proposal 2014-04, > "Removing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. Support 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: 547 bytes Desc: Digital signature URL: From ripe.address-policy-wg at ml.karotte.org Mon Dec 15 15:23:58 2014 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Mon, 15 Dec 2014 15:23:58 +0100 Subject: [address-policy-wg] Language clarification proposal In-Reply-To: <5489AEFA.4040907@inex.ie> References: <5489AEFA.4040907@inex.ie> Message-ID: <20141215142358.GD22316@danton.fire-world.de> * Nick Hilliard [2014-12-11 15:51]: > 2014-07: support > 2014-08: support > 2014-10: support > 2014-11: support Thank you for summing it up. +1 for all. 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: 547 bytes Desc: Digital signature URL: From mschmidt at ripe.net Tue Dec 23 16:07:28 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 23 Dec 2014 16:07:28 +0100 Subject: [address-policy-wg] 2014-12 Draft Document and Impact Analysis Published (Allow IPv6 Transfers) Message-ID: Dear colleagues, The proposal described in 2014-12, "Allow IPv6 Transfers", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2014-12 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2014-12/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 21 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Tue Dec 23 16:18:00 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 23 Dec 2014 16:18:00 +0100 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) Message-ID: Dear colleagues, The proposal described in 2014-13, "Allow AS Number Transfers", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-13 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-13/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 21 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From marty at akamai.com Tue Dec 23 20:43:27 2014 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 23 Dec 2014 14:43:27 -0500 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: Message-ID: Reading the draft? This sentence: "Any holder of Autonomous System (AS) Numbers is allowed to re-assign AS Numbers that were previously assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry System." ?reads to me that transfer or reassignment is allowed inter-rir...I may be missing bits of policy here that explicitly disallow. Apologies if so. Clarification? Best, -M< On Dec 23, 2014, at 10:18 AM, Marco Schmidt wrote: > > Dear colleagues, > > The proposal described in 2014-13, "Allow AS Number Transfers", is now > in its Review Phase. > > The draft document has been published, along with an impact analysis conducted > by the RIPE NCC. > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-13 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-13/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 21 January 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Tue Dec 23 21:37:32 2014 From: randy at psg.com (Randy Bush) Date: Tue, 23 Dec 2014 15:37:32 -0500 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: Message-ID: > "Any holder of Autonomous System (AS) Numbers is allowed to re-assign > AS Numbers that were previously assigned to them by the RIPE NCC or > otherwise through the Regional Internet Registry System." > > ?reads to me that transfer or reassignment is allowed inter-rir. yes, quite well done. if some other rir is so wrapped around the tea party axle to play, that's their disease. no need to propagate it. randy From mschmidt at ripe.net Wed Dec 24 11:51:15 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 24 Dec 2014 11:51:15 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) Message-ID: Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number - The RIPE NCC's need evaluation has been removed - A limit of 1,000 AS Numbers per organisation has been added - There is now a requirement that 16-bit AS Numbers be multihomed after nine months - The requirement that the routing policy must be new and unique has been removed - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-03 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-03/draft We encourage you to read the draft document text and send any comments to before 22 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Wed Dec 24 17:18:04 2014 From: nick at inex.ie (Nick Hilliard) Date: Wed, 24 Dec 2014 16:18:04 +0000 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: <549AE73C.9040800@inex.ie> On 24/12/2014 10:51, Marco Schmidt wrote: > - AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number > - The RIPE NCC's need evaluation has been removed > - A limit of 1,000 AS Numbers per organisation has been added > - There is now a requirement that 16-bit AS Numbers be multihomed after nine months > - The requirement that the routing policy must be new and unique has been removed > - Related wording adjustments in the summary and rationale of the proposal April 1 is three months away; otherwise, an excellent parody. Nick From gert at space.net Wed Dec 24 19:14:27 2014 From: gert at space.net (Gert Doering) Date: Wed, 24 Dec 2014 19:14:27 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <549AE73C.9040800@inex.ie> References: <549AE73C.9040800@inex.ie> Message-ID: <20141224181427.GT34798@Space.Net> Hi, On Wed, Dec 24, 2014 at 04:18:04PM +0000, Nick Hilliard wrote: > April 1 is three months away; otherwise, an excellent parody. So do I take that as support of the policy, or opposition? And if the latter, what are you unhappy about which couldn't be brought up in the previous round already (since this new version really tries to incorporate all feedback that has been given)? 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 ebais at a2b-internet.com Wed Dec 24 19:24:17 2014 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Wed, 24 Dec 2014 19:24:17 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20141224181427.GT34798@Space.Net> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> Message-ID: <8F65A6E7-0719-45AA-92A1-607529897B1D@a2b-internet.com> Perhaps Nick means, Xmas came early this year ;-) Verstuurd vanaf mijn iPad > Op 24 dec. 2014 om 19:14 heeft Gert Doering het volgende geschreven: > > Hi, > >> On Wed, Dec 24, 2014 at 04:18:04PM +0000, Nick Hilliard wrote: >> April 1 is three months away; otherwise, an excellent parody. > > So do I take that as support of the policy, or opposition? And if the > latter, what are you unhappy about which couldn't be brought up in the > previous round already (since this new version really tries to incorporate > all feedback that has been given)? > > 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 From nick at inex.ie Wed Dec 24 22:18:22 2014 From: nick at inex.ie (Nick Hilliard) Date: Wed, 24 Dec 2014 21:18:22 +0000 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20141224181427.GT34798@Space.Net> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> Message-ID: <549B2D9E.4020905@inex.ie> On 24/12/2014 18:14, Gert Doering wrote: > So do I take that as support of the policy, or opposition? And if the > latter, what are you unhappy about which couldn't be brought up in the > previous round already (since this new version really tries to incorporate > all feedback that has been given)? It's the evening of dec 24 so I'm not going to go into a whole rigmarole about the theory of bureaucratic policy. But as a general rule, most ripe community addressing policy over the last couple of years has been veering towards relaxation and simplification of rules rather than making them more complicated. This is particularly the case with ipv4, and almost the same with ipv6 from most practical viewpoints. As a community, we're pretty much together that this is a good thing. Then this proposal happens. It invents a magic number - one thousand. Yes, I'm aware of the distant practical basis for this, but let's not pretend that in every other respect the number isn't pulled straight out of the air because it happens to be an ordinal power of the number of fingers on most peoples' hands. Magical, nay divine, power is assigned to this number: thus far shalt thou abuse and no further! It creates a policy requirement to invoke RPSL, possibly one of the most inscrutably ill-defined languages ever devised, but the requirement is so poorly defined that anything could be credibly hurled into the database. E.g. "from AS23456 import AS-NULL". It creates a requirement to state a need for the ASN which the RIPE NCC will forbidden from evaluating. It also creates a requirement for the RIPE NCC to police this need. Not evaluate, mind you - just police it without evaluation. I'm trying to understand how this could possibly work, so in the unlikely event that there are no further emails from this address, you can assume that my brain has imploded due to a neural singularity. It conveniently ignores the awkward reality that in the event that an organisation might ever want 1001 ASNs, they could spend 10 euros registering a second company and continuing on their merry way. Guys and gals, I have shocking news for you: if someone is dishonest enough to abuse the rules using one organisation, they can just as easily abuse the rules with two different organisations and perpetrate twice as much abuse. Application of iteration theory indicates that this abuse may even scale linearly. The sensible approach to this is to relax the policy requirements for asn assignment - in exactly the same way that the ripe community has relaxed the policy requirements for other number resources - and then apply a small fee to help prevent egregious abuse. Note: not stop, because it is not possible to completely people abusing arbitrary rulesets without harming the common good. This is far simpler, most manageable, smaller, more internally consistent and generally more beneficial for the community than proposing byzantine policy. Look I'm sorry, but this policy draft is absurd and flies in the face of reality, common sense and practical application. Please kill it with fire. Nick From randy at psg.com Wed Dec 24 23:02:20 2014 From: randy at psg.com (Randy Bush) Date: Wed, 24 Dec 2014 17:02:20 -0500 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <549B2D9E.4020905@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> Message-ID: > Look I'm sorry, but this policy draft is absurd and flies in the face of > reality, common sense and practical application. Please kill it with fire. thank you and if you can't figure it out, gert, i agree with nick, but am far less loquacious. randy From marty at akamai.com Wed Dec 24 23:07:31 2014 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 24 Dec 2014 17:07:31 -0500 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <549B2D9E.4020905@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> Message-ID: <4E6EA3E3-84CA-4518-9444-C12490F67DEE@akamai.com> > On Dec 24, 2014, at 16:19, Nick Hilliard wrote: > > > Look I'm sorry, but this policy draft is absurd and flies in the face of > reality, common sense and practical application. Please kill it with fire. > > Nick > > +1 Happy Holidays all. From gert at space.net Wed Dec 24 23:12:21 2014 From: gert at space.net (Gert Doering) Date: Wed, 24 Dec 2014 23:12:21 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> Message-ID: <20141224221221.GV34798@Space.Net> Hi, On Wed, Dec 24, 2014 at 05:02:20PM -0500, Randy Bush wrote: > > Look I'm sorry, but this policy draft is absurd and flies in the face of > > reality, common sense and practical application. Please kill it with fire. > > thank you > > and if you can't figure it out, gert, i agree with nick, but am far less > loquacious. Nick, Randy, thanks - *that* message was very clear. (And I can see the point. The proposal is trying to work around the mishap that the charging scheme removed the fee for AS numbers, which we as APWG cannot directly decide - but of course the message has been sent at the last AGM and I'm fairly sure it has been heard. No idea what will happen on that front, though...) regards, Gert Doering -- 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 Wed Dec 24 23:18:26 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 25 Dec 2014 00:18:26 +0200 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <549B2D9E.4020905@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> Message-ID: <2A694699-F703-4940-BC00-38112FB94D7C@ytti.fi> Hey, You seem to give critic on many aspects, but offer solution to one aspect. You believe the magic 1k should be replaced by small fee. Well, that is what the 1k does, it gives non-zero fee to ASN, so that you dont want to request 32b of them. Same functionality without changes to billing procedure. The requirement for reason to request is for those who come after us, so that they will have data to work with. Why are ASNs needed? Does this seem problematic or wrong? I'm ambivalent on the RPSL aspect. How should it be remedied? Removed? Thanks, -- ++ytti > On 24 Dec 2014, at 23:18, Nick Hilliard wrote: > >> On 24/12/2014 18:14, Gert Doering wrote: >> So do I take that as support of the policy, or opposition? And if the >> latter, what are you unhappy about which couldn't be brought up in the >> previous round already (since this new version really tries to incorporate >> all feedback that has been given)? > > It's the evening of dec 24 so I'm not going to go into a whole rigmarole > about the theory of bureaucratic policy. But as a general rule, most ripe > community addressing policy over the last couple of years has been veering > towards relaxation and simplification of rules rather than making them more > complicated. This is particularly the case with ipv4, and almost the same > with ipv6 from most practical viewpoints. As a community, we're pretty > much together that this is a good thing. > > Then this proposal happens. > > It invents a magic number - one thousand. Yes, I'm aware of the distant > practical basis for this, but let's not pretend that in every other respect > the number isn't pulled straight out of the air because it happens to be an > ordinal power of the number of fingers on most peoples' hands. Magical, > nay divine, power is assigned to this number: thus far shalt thou abuse and > no further! > > It creates a policy requirement to invoke RPSL, possibly one of the most > inscrutably ill-defined languages ever devised, but the requirement is so > poorly defined that anything could be credibly hurled into the database. > E.g. "from AS23456 import AS-NULL". > > It creates a requirement to state a need for the ASN which the RIPE NCC > will forbidden from evaluating. > > It also creates a requirement for the RIPE NCC to police this need. Not > evaluate, mind you - just police it without evaluation. I'm trying to > understand how this could possibly work, so in the unlikely event that > there are no further emails from this address, you can assume that my brain > has imploded due to a neural singularity. > > It conveniently ignores the awkward reality that in the event that an > organisation might ever want 1001 ASNs, they could spend 10 euros > registering a second company and continuing on their merry way. Guys and > gals, I have shocking news for you: if someone is dishonest enough to abuse > the rules using one organisation, they can just as easily abuse the rules > with two different organisations and perpetrate twice as much abuse. > Application of iteration theory indicates that this abuse may even scale > linearly. > > The sensible approach to this is to relax the policy requirements for asn > assignment - in exactly the same way that the ripe community has relaxed > the policy requirements for other number resources - and then apply a small > fee to help prevent egregious abuse. Note: not stop, because it is not > possible to completely people abusing arbitrary rulesets without harming > the common good. > > This is far simpler, most manageable, smaller, more internally consistent > and generally more beneficial for the community than proposing byzantine > policy. > > Look I'm sorry, but this policy draft is absurd and flies in the face of > reality, common sense and practical application. Please kill it with fire. > > Nick > > From job at instituut.net Thu Dec 25 11:39:45 2014 From: job at instituut.net (Job Snijders) Date: Thu, 25 Dec 2014 11:39:45 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <549B2D9E.4020905@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> Message-ID: <20141225103945.GD40149@Vurt.local> Dear Nick, community, On Wed, Dec 24, 2014 at 09:18:22PM +0000, Nick Hilliard wrote: > It invents a magic number - one thousand. Yes, I'm aware of the > distant practical basis for this, but let's not pretend that in every > other respect the number isn't pulled straight out of the air Some background: the 1000 number is based on multiplying the highest amount of ASNs assigned to a single organisation by ten (100 * 10), to ensure there is room for growth. The previous version of the policy did not contain the '1000 ASNs limitation'. To that proposal you responded you were going to need "slightly less than 2^32. (ASNs)". Am I to understand you prefer the previous version of the proposal, because it aligns better with your needs? > It creates a policy requirement to invoke RPSL This is simply not true, this proposal is not creating anything new in that context. Current policy states: "The new unique routing policy should be defined in RPSL language, as used in the RIPE Database." the proposal states: "The routing policy of an Autonomous System should be defined in RPSL in the RIPE Database." Note the word /should/ in the proposed policy. I want to encourage everyone to document the meaningful bits of their routing policy in an accessible way, but as end-user you can also decide to put garbage (or nothing) in the DB. Should the words 'in RPSL' be removed the sentence? Any suggestions? As an active contributor to the current ASN Assignment policy, can you maybe shed some light on why the current policy invoked RPSL the way it does? > > > The sensible approach to this is to relax the policy requirements for > asn assignment - ... - and then apply a small fee to help prevent > egregious abuse. Note: not stop, because it is not possible to > completely people abusing arbitrary rulesets without harming the > common good. So you are using a terrible amount of handwaving and overbreathing to suggest that we refrain from ASN Assignment policy changes until the AGM decides to start charging a yearly fee for ASNs again? What if such a yaerly fee is never introduced? > Look I'm sorry, but this policy draft is absurd and flies in the face > of reality, common sense and practical application. What's absurd is that currently you cannot just get an ASN when you ask for one. From ebais at a2b-internet.com Thu Dec 25 13:10:41 2014 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Thu, 25 Dec 2014 13:10:41 +0100 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: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> Hi, I would like to add to the discussion first that I support the idea of the proposal. There has been some discussions by some in the community that there should be some kind of stop mechanism. Both on the Ap-wg ML and during the meeting in London. The discussion itself currently doesn't go over if an AS should be multihomed but about how do we stop abusers that want to demonstrate the need for 2^32 AS numbers ... How scary that might be .. There are other ways to screw things up ... This discussion should be finished by agreeing that there should be stop somewhere ... There has been 2 suggestions to this scary (automation) AS request that Nick might use when the policy comes into place ... Pay per AS or limit the number of AS'n per organisation. This while nothing currently suggests that Nick or someone else actually wants to request 2^32 AS's ... There is always the option to fix this within 6 months via the AGM with a charge per AS if the RIPE NCC has all AS numbers handed out to a scary evil org based on an island.. And if evil corp wants to keep the requested AS numbers when the AGM puts a ?100 charge per AS, we will see at that point I think.. The intention of the prevention of the abuse is clear .. The policy won't get any better by having the authors go back and redo the draft (again) to the original because there is no nice solution for this 'possible' abuse .. So, on the intention of the policy: clear support. On the implementation: 1000 AS numbers ( as discussed in London) is a good enough number for the majority of the community. It is the cleanest way to implement this in the policy, nope sorry .. But that was also not suggested as such by the authors. The possible loophole came from the community and when they plugged it, the comment is that the policy text isn't clean enough ? I support the intention of the policy and I have peace with this version as it was the result of a good discusssion in London. Merry x-mas y'all, Erik Bais Send from my sofa with a glass of wine @ hand. From marty at akamai.com Sun Dec 28 20:59:35 2014 From: marty at akamai.com (Hannigan, Martin) Date: Sun, 28 Dec 2014 14:59:35 -0500 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: Message-ID: On Dec 23, 2014, at 3:37 PM, Randy Bush wrote: >> "Any holder of Autonomous System (AS) Numbers is allowed to re-assign >> AS Numbers that were previously assigned to them by the RIPE NCC or >> otherwise through the Regional Internet Registry System." >> >> ?reads to me that transfer or reassignment is allowed inter-rir. > > yes, quite well done. Agreed on the policy. I support its continued move forward. Best, -M< -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: