From gert at space.net Mon Aug 1 13:20:26 2011 From: gert at space.net (Gert Doering) Date: Mon, 1 Aug 2011 13:20:26 +0200 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110728103305.E8BA36A03C@postboy.ripe.net> References: <20110728103305.E8BA36A03C@postboy.ripe.net> Message-ID: <20110801112026.GJ72014@Space.Net> Dear Working Group, On Thu, Jul 28, 2011 at 12:31:21PM +0200, Emilio Madaio wrote: > The Review Period for the proposal 2011-01 has been extended until 25 > August 2011. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-01 This proposal is doing another round of 4-week review phase because of a distinct lack of feedback on it (one question, but no support / objection comments). There currently is a lack of policy at IANA/ICANN regarding distribution of "smaller than a /8" address blocks that happen to show up in the IANA pool - which means that even if such blocks should be found, IANA cannot distribute them to the RIRs. Which those of you that still use IPv4 might then be interested in receiving... This being a global policy, we don't do word smithing on it (the text should be the same in all regions), so your choice is easy: support, or objection. Taking off the WG chair's hat, I think this is necessary housekeeping, and should be done -> *support* (this implies that I don't get to decide whether we have consensus on this one, but Sander will be the neutral WG chair that oversees the process). Putting the hat back on, I welcome your comments! Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From rogerj at gmail.com Tue Aug 2 08:26:44 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Tue, 2 Aug 2011 08:26:44 +0200 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110801112026.GJ72014@Space.Net> References: <20110728103305.E8BA36A03C@postboy.ripe.net> <20110801112026.GJ72014@Space.Net> Message-ID: On Mon, Aug 1, 2011 at 1:20 PM, Gert Doering wrote: > Dear Working Group, > On Thu, Jul 28, 2011 at 12:31:21PM +0200, Emilio Madaio wrote: >> The Review Period for the proposal 2011-01 has been extended until 25 >> August 2011. >> >> You can find the full proposal at: >> >> ? ? http://www.ripe.net/ripe/policies/proposals/2011-01 > > This proposal is doing another round of 4-week review phase because of > a distinct lack of feedback on it (one question, but no support / objection > comments). > > There currently is a lack of policy at IANA/ICANN regarding distribution of > "smaller than a /8" address blocks that happen to show up in the IANA pool - > which means that even if such blocks should be found, IANA cannot distribute > them to the RIRs. ?Which those of you that still use IPv4 might then be > interested in receiving... > > This being a global policy, we don't do word smithing on it (the text should > be the same in all regions), so your choice is easy: support, or objection. I can't atm see anything to pick on, the text seem quite stright forward so supported from here. -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From Remco.vanMook at eu.equinix.com Tue Aug 2 10:13:05 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Tue, 2 Aug 2011 09:13:05 +0100 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110801112026.GJ72014@Space.Net> Message-ID: I support this proposal because there's an obvious need for it - what's not exactly clear to me however is if current IANA inventory (IIRC there was more there than just /8s) will be put into that same 'recovered' pool so no addresses get stuck (other than some scraps < /24). Remco van Mook Director of Interconnection, Europe remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 01-08-11 13:20, "Gert Doering" wrote: >Dear Working Group, > >On Thu, Jul 28, 2011 at 12:31:21PM +0200, Emilio Madaio wrote: >> The Review Period for the proposal 2011-01 has been extended until 25 >> August 2011. >> >> You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-01 > >This proposal is doing another round of 4-week review phase because of >a distinct lack of feedback on it (one question, but no support / >objection >comments). > >There currently is a lack of policy at IANA/ICANN regarding distribution >of >"smaller than a /8" address blocks that happen to show up in the IANA >pool - >which means that even if such blocks should be found, IANA cannot >distribute >them to the RIRs. Which those of you that still use IPv4 might then be >interested in receiving... > >This being a global policy, we don't do word smithing on it (the text >should >be the same in all regions), so your choice is easy: support, or >objection. > >Taking off the WG chair's hat, I think this is necessary housekeeping, and >should be done -> *support* (this implies that I don't get to decide >whether we have consensus on this one, but Sander will be the neutral WG >chair that oversees the process). > >Putting the hat back on, I welcome your comments! > >Gert Doering > -- APWG chair >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From Remco.vanMook at eu.equinix.com Tue Aug 2 11:56:49 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Tue, 2 Aug 2011 10:56:49 +0100 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: Message-ID: Dear all, There appears to be some confusion about in what capacity I send email to the address policy mailing list. While I thought this was obvious, all opinions, policy proposals, support for proposals or lack thereof, mutterings and ramblings I state here are my own and from a personal capacity, unless explicitly stated otherwise. To prevent any further confusion, I'll try to include this in any future postings - please forgive me the extra time you'll spend reading them. As always, feel free to contact me if you have any questions or comments. Remco On 02-08-11 10:13, "Remco Van Mook" wrote: >I support this proposal because there's an obvious need for it - what's >not exactly clear to me however is if current IANA inventory (IIRC there >was more there than just /8s) will be put into that same 'recovered' pool >so no addresses get stuck (other than some scraps < /24). > > >Remco van Mook >Director of Interconnection, Europe > >remco.vanmook at eu.equinix.com >+31 61 135 6365 MOB > >EQUINIX >51-53 Great Marlborough Street >London, W1F 7JT, United Kingdom > > > > > > >On 01-08-11 13:20, "Gert Doering" wrote: > >>Dear Working Group, >> >>On Thu, Jul 28, 2011 at 12:31:21PM +0200, Emilio Madaio wrote: >>> The Review Period for the proposal 2011-01 has been extended until 25 >>> August 2011. >>> >>> You can find the full proposal at: >>> >>> http://www.ripe.net/ripe/policies/proposals/2011-01 >> >>This proposal is doing another round of 4-week review phase because of >>a distinct lack of feedback on it (one question, but no support / >>objection >>comments). >> >>There currently is a lack of policy at IANA/ICANN regarding distribution >>of >>"smaller than a /8" address blocks that happen to show up in the IANA >>pool - >>which means that even if such blocks should be found, IANA cannot >>distribute >>them to the RIRs. Which those of you that still use IPv4 might then be >>interested in receiving... >> >>This being a global policy, we don't do word smithing on it (the text >>should >>be the same in all regions), so your choice is easy: support, or >>objection. >> >>Taking off the WG chair's hat, I think this is necessary housekeeping, >>and >>should be done -> *support* (this implies that I don't get to decide >>whether we have consensus on this one, but Sander will be the neutral WG >>chair that oversees the process). >> >>Putting the hat back on, I welcome your comments! >> >>Gert Doering >> -- APWG chair >>-- >>have you enabled IPv6 on something today...? >> >>SpaceNet AG Vorstand: Sebastian v. Bomhard >>Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>Grundner-Culemann >>D-80807 Muenchen HRB: 136055 (AG Muenchen) >>Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >> > > > >This email is from Equinix Europe Limited or one of its >associated/subsidiary companies. This email, and any files transmitted >with it, contains information which is confidential, may be legally >privileged and is solely for the use of the intended recipient. If you >have received this email in error, please notify the sender and delete >this email immediately. Equinix Europe Limited. Registered Office: >Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in >England and Wales, No. 6293383. > From rhe at nosc.ja.net Tue Aug 2 14:05:32 2011 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 2 Aug 2011 13:05:32 +0100 Subject: [address-policy-wg] Expressing opinions. In-Reply-To: References: Message-ID: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> > There appears to be some confusion about in what capacity I send email to > the address policy mailing list. > > While I thought this was obvious, all opinions, policy proposals, support > for proposals or lack thereof, mutterings and ramblings I state here are > my own and from a personal capacity, unless explicitly stated otherwise. Really? Please folk, let us not get into the situation that some other RIRs are in where those involved feel restricted in voicing their opinions. I'd rather it was the other way around -- all opinions are assumed to be your own unless expressly labelled otherwise. Of course, you and other members of the Exec Board have been elected because other members value your judgement, and therefore your views will have weight regardless of how they are positioned, but official statements are usually clearly labelled enough for everything else to be assumed to be personal opinion. In my opinion, anyway. :) Rob From jim at rfc1035.com Tue Aug 2 14:20:23 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 2 Aug 2011 13:20:23 +0100 Subject: [address-policy-wg] Expressing opinions. In-Reply-To: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> References: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> Message-ID: <5710DCB4-ADCD-4411-93CA-390B47FB31F9@rfc1035.com> On 2 Aug 2011, at 13:05, Rob Evans wrote: > Really? Please folk, let us not get into the situation that some > other RIRs are in where those involved feel restricted in voicing > their opinions. +1 > In my opinion, anyway. :) Is that your personal opinion Rob? Or is that your WG Chair opinion? Or are you wearing your Programme Committee member hat? :-) Sorry: couldn't resist... jim (no hats) :-) From sander at steffann.nl Tue Aug 2 15:37:50 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 2 Aug 2011 15:37:50 +0200 Subject: [address-policy-wg] Expressing opinions. In-Reply-To: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> References: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> Message-ID: <48FF2B01-DFD1-46CE-AEE9-F8458C61ADA4@steffann.nl> Hello Rob, > Really? Please folk, let us not get into the situation that some other RIRs are in where those involved feel restricted in voicing their opinions. > > I'd rather it was the other way around -- all opinions are assumed to be your own unless expressly labelled otherwise. It is. Everybody's opinion is accepted here, and all opinions have equal weight. Even if labeled otherwise. If a NCC board member expresses his opinion, if a working group chair expresses his/her opinion, or if anybody else expresses his/her opinion: all are equal and considered for their content, not for who expressed them. And this is an open community. *Everybody* can join. Obvious to those of us who have been around for some time, but I though I should write it down once in a while :-) Thanks, Sander Steffann APWG Co-chair <-- please note :) From randy at psg.com Tue Aug 2 21:38:27 2011 From: randy at psg.com (Randy Bush) Date: Wed, 03 Aug 2011 04:38:27 +0900 Subject: [address-policy-wg] Expressing opinions. In-Reply-To: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> References: <13F6A77F-84FD-4016-B152-B922B995506D@nosc.ja.net> Message-ID: >> There appears to be some confusion about in what capacity I send >> email to the address policy mailing list. > > Really? Please folk, let us not get into the situation that some > other RIRs are in where those involved feel restricted in voicing > their opinions. it was my fault, too used to other regions with different religions. i agree and apologize. randy From emadaio at ripe.net Fri Aug 5 15:08:24 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 05 Aug 2011 15:08:24 +0200 Subject: [address-policy-wg] IANA implementation analysis of proposal 2011-01, "Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by IANA" Message-ID: <4E3BEB48.40703@ripe.net> Dear Colleagues, In order to provide a more comprehensive overview of the expected implementation aspects of proposal 2011-01, the RIPE NCC sought input from IANA staff. Below is the analysis produced by Leo Vegoda. We hope that this input will be useful to RIPE community discussion of this proposal. We also note that the current Review Phase for the proposal will end on 25 August 2011. Best Regards Emilio Madaio Policy Development Officer RIPE NCC --------oooooooooo-------------- IANA staff impact analysis of RIPE policy proposal 2011-01 This analysis considers the impact of ratification of RIPE policy proposal 2011-01 (as a part of GPP-IPv4-2011) by the ICANN Board of Directors. 1. The policy would require ICANN, as the IANA function operator, to establish a Recovered IPv4 Pool. The pool would have to include ?any fragments that may be left over in the IANA?. In order to do this, ICANN staff would have to work closely with the five RIRs? staffs to make sure the initial pool included all fragments assigned to IANA. It is not clear whether this policy proposal is intended to supersede the IETF?s right to make IPv4 assignments for ?specialised address blocks (such as multicast or anycast blocks)? as documented in section 4.3 of RFC 2860. This should be clarified but that can probably be done by way of assertions from the NRO rather than a revision to the policy text. In the event that the policy is intended to supersede RFC 2860 there is a potential issue with the internal reservation of small blocks address blocks that have been informally reserved for IETF standards track work currently in progress. 2. It would replace the current procedure for Updating legacy Class A IPv4 allocations, which was agreed with the NRO in February 2007. This is because the text includes a statement that ?The Recovered IPv4 Pool will initially contain any fragments that may be left over in the IANA. It will also hold any space returned to the IANA by any other means? and this presumably include address space returned directly by registrants. 3. Once it was activated by an RIR declaring that it has less than a /9 in its inventory, IANA would have to make the first allocation. IANA would then have to make additional allocations on 1 March and 1 September each year, if there is enough address space left in the pool. The minimum allocation size would be a /24 and the ?allocation unit? used in each allocation would be determined by dividing the total pool by five and rounding down to the nearest CIDR boundary. As an example, if the pool contained 27 /24s, each RIR would be allocated a /22 (or the equivalent made from multiple /24 prefixes) because 5.4 /24s is not on a CIDR boundary. There is no text stating that the ?allocation units? must be a single prefix and so it seems reasonable to make them up from a bundle of prefixes when necessary. 4. All address space added to the Recovered IPv4 Pool would be registered as such in the IANA IPv4 Address Space Registry. Similarly, allocations from the pool would also be registered. This would require the granularity of registration to move from /8 boundaries as is currently the case and as such could inflate the size of the registry from 256 lines to several thousand. --------oooooooooo-------------- From ebais at a2b-internet.com Sat Aug 6 12:42:55 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 6 Aug 2011 12:42:55 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <008101cc4c5b$10403500$30c09f00$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> Message-ID: <003401cc5425$9af655e0$d0e301a0$@com> Hi Thomas, A quick update on the status of 2011-02 policy. I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal. So to everyone on the list, let's hear it. I've done a presentation on RIPE62 on the proposal for those not familiar with 2011-02 and you can find the PPT here : http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt You can read the policy proposal itself here: http://www.ripe.net/ripe/policies/proposals/2011-02 In short, the policy proposal is to remove the multi-homing requirement for PI IPv6. Currently, companies can become a LIR and get IPv6, with no multi-home requirement, same with requesting IPv4 PI. And companies that don't want to or (legally) can't become a LIR but do want to have their own IPv6 addresses are required to be multi-homed. The only change in text in the RIPE-512 is: Remove the line: a) demonstrate that it will be multihomed For those that agree with the policy and everything is clear, express your support on the AP-WG-mailing list your support. Kind regards, Erik Bais Co-author of 2011-02 From Jasper.Jans at espritxb.nl Sun Aug 7 14:29:44 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Sun, 7 Aug 2011 14:29:44 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> I support this proposal. -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Erik Bais Sent: Saturday, August 06, 2011 12:43 PM To: 'DI. Thomas Schallar'; 'RIPE Address Policy Working Group' Cc: jordi.palet at consulintel.es Subject: RE: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? Hi Thomas, A quick update on the status of 2011-02 policy. I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal. So to everyone on the list, let's hear it. I've done a presentation on RIPE62 on the proposal for those not familiar with 2011-02 and you can find the PPT here : http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt You can read the policy proposal itself here: http://www.ripe.net/ripe/policies/proposals/2011-02 In short, the policy proposal is to remove the multi-homing requirement for PI IPv6. Currently, companies can become a LIR and get IPv6, with no multi-home requirement, same with requesting IPv4 PI. And companies that don't want to or (legally) can't become a LIR but do want to have their own IPv6 addresses are required to be multi-homed. The only change in text in the RIPE-512 is: Remove the line: a) demonstrate that it will be multihomed For those that agree with the policy and everything is clear, express your support on the AP-WG-mailing list your support. Kind regards, Erik Bais Co-author of 2011-02 Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From jan at go6.si Sun Aug 7 19:21:46 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 07 Aug 2011 19:21:46 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> Message-ID: <4E3EC9AA.8000202@go6.si> On 8/7/11 2:29 PM, Jasper Jans wrote: > I support this proposal. +1 This just means we remove the need to lie anymore to IPRAs about multihoming, if small/medium organization wants their IPv6 block and do not plan to actually be multihomed. :) Actually, with this we remove the only reason why NAT66 could exist :) Get your PI and don't translate addresses, if you change provider you are still good. Cheers, Jan Zorz From Tero.Toikkanen at nebula.fi Mon Aug 8 09:11:40 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Mon, 8 Aug 2011 07:11:40 +0000 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> Message-ID: > I support this proposal. +1 ____________________________________ Tero Toikkanen Network Engineer Nebula Oy Heikkil?ntie 2, FI-00210 Helsinki, Finland E-mail tero.toikkanen at nebula.fi tel +358-9-6818 3810 - fax +358-9-6818 3830 www.nebula.fi From Robert.Guentensperger at swisscom.com Mon Aug 8 07:52:21 2011 From: Robert.Guentensperger at swisscom.com (Robert.Guentensperger at swisscom.com) Date: Mon, 8 Aug 2011 05:52:21 +0000 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <30769820.2177.1312782747932.JavaMail.trustmail@ss000808> I support this policy. Best regards, Robert G?ntensperger |-----Original Message----- |From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- |admin at ripe.net] On Behalf Of Erik Bais |Sent: Saturday, August 06, 2011 12:43 PM |To: 'DI. Thomas Schallar'; 'RIPE Address Policy Working Group' |Cc: jordi.palet at consulintel.es |Subject: RE: [address-policy-wg] Status of 2011-02 Policy Proposal |(Removal of multihomed requirement for IPv6)? | |Hi Thomas, | |A quick update on the status of 2011-02 policy. | |I spoke with the AP-WG-chair last week and the decision is that there |will |be an extended review period to give people the time to ask questions if |needed on the proposal. | |So to everyone on the list, let's hear it. | |I've done a presentation on RIPE62 on the proposal for those not |familiar |with 2011-02 and you can find the PPT here : |http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt | |You can read the policy proposal itself here: |http://www.ripe.net/ripe/policies/proposals/2011-02 | |In short, the policy proposal is to remove the multi-homing requirement |for |PI IPv6. |Currently, companies can become a LIR and get IPv6, with no multi-home |requirement, same with requesting IPv4 PI. |And companies that don't want to or (legally) can't become a LIR but do |want |to have their own IPv6 addresses are required to be multi-homed. | |The only change in text in the RIPE-512 is: | |Remove the line: | |a) demonstrate that it will be multihomed | |For those that agree with the policy and everything is clear, express |your |support on the AP-WG-mailing list your support. | |Kind regards, |Erik Bais |Co-author of 2011-02 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5255 bytes Desc: S/MIME Cryptographic Signature URL: From job at instituut.net Mon Aug 8 10:06:53 2011 From: job at instituut.net (Job Snijders) Date: Mon, 8 Aug 2011 10:06:53 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <750A870D-0F0A-4EF7-AD27-6D2B148F1CAA@instituut.net> Dear All, I agree with removing the multi-homing requirement for IPv6 PI. Its pretty awkward to send your customers to a competitor because to deploy IPv6 PI space he or she needs to be multi-homed. Also, rising technologies such as LISP allow end-users to be multi-homed in a way that is transparent to the DFZ, so why bother restricting people to BGP multi-homing. Kind regards, Job Snijders On 6 aug. 2011, at 12:42, Erik Bais wrote: > Hi Thomas, > > A quick update on the status of 2011-02 policy. > > I spoke with the AP-WG-chair last week and the decision is that there will > be an extended review period to give people the time to ask questions if > needed on the proposal. > > So to everyone on the list, let's hear it. > > I've done a presentation on RIPE62 on the proposal for those not familiar > with 2011-02 and you can find the PPT here : > http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt > > You can read the policy proposal itself here: > http://www.ripe.net/ripe/policies/proposals/2011-02 > > In short, the policy proposal is to remove the multi-homing requirement for > PI IPv6. > Currently, companies can become a LIR and get IPv6, with no multi-home > requirement, same with requesting IPv4 PI. > And companies that don't want to or (legally) can't become a LIR but do want > to have their own IPv6 addresses are required to be multi-homed. > > The only change in text in the RIPE-512 is: > > Remove the line: > > a) demonstrate that it will be multihomed > > For those that agree with the policy and everything is clear, express your > support on the AP-WG-mailing list your support. > > Kind regards, > Erik Bais > Co-author of 2011-02 > From t.schallar at avalon.at Mon Aug 8 10:36:03 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Mon, 08 Aug 2011 10:36:03 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> Message-ID: <4E3F9FF3.9080100@avalon.at> > So to everyone on the list, let's hear it. I also support that proposal! Reasons for me (my company): we have a small IPv4 PI space and want to deploy IPv6. Of course it should also be PI and not PA [the same reasony apply for v6 as for v4]. Our provider has several conections to the Internet hubs, so our current v4 uplink _IS_ already redundant. The same will be the case for IPv6. To have our IPv6 space be explicitly multihomed, we have to * apply for an AS for proper BGP announcement * change fom cheap Internet uplink to expensive transit That will * unnecessarily burn away the last of the remaining 16 Bit AS numbers with additional RIPE fees for us * more than tripple the costs of our Internet connection (simple uplink is cheap, transit is expensive) but without gaining any benefit (that I can see). regards, Thomas From jan at go6.si Mon Aug 8 10:59:17 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Aug 2011 10:59:17 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3F9FF3.9080100@avalon.at> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3F9FF3.9080100@avalon.at> Message-ID: <4E3FA565.4020602@go6.si> On 8/8/11 10:36 AM, DI. Thomas Schallar wrote: > To have our IPv6 space be explicitly multihomed, we have to > > * apply for an AS for proper BGP announcement > * change fom cheap Internet uplink to expensive transit that does not change with removing the multihoming requirement. PI is still PI and you need to announce it via BGP and your ASN. cheers, Jan From paul at meanie.nl Mon Aug 8 11:06:54 2011 From: paul at meanie.nl (Paul Hoogsteder) Date: Mon, 8 Aug 2011 11:06:54 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3FA565.4020602@go6.si> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3F9FF3.9080100@avalon.at> <4E3FA565.4020602@go6.si> Message-ID: <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> > On 8/8/11 10:36 AM, DI. Thomas Schallar wrote: >> To have our IPv6 space be explicitly multihomed, we have to >> >> * apply for an AS for proper BGP announcement >> * change fom cheap Internet uplink to expensive transit > > that does not change with removing the multihoming requirement. PI is > still PI and you need to announce it via BGP and your ASN. Why? We (as a multihomed ISP) announce both our own PA blocks and one of our customers PI block in v4 - why wouldn't that work/be allowed in v6? There's no need for an ASN or BGP capable router at the customer. Paul. From ebais at A2B-Internet.com Mon Aug 8 11:32:24 2011 From: ebais at A2B-Internet.com (Erik Bais) Date: Mon, 8 Aug 2011 11:32:24 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3F9FF3.9080100@avalon.at> <4E3FA565.4020602@go6.si> <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> Message-ID: <7183DCEF-157C-4230-AA1C-278AEE38F8BD@A2B-Internet.com> Hi Paul, That is indeed a very common setup and removing the multi-home requirement for v6 will allow us to do the same for those PI customers. Erik Verstuurd vanaf mijn iPad Op Aug 8, 2011 om 11:06 heeft "Paul Hoogsteder" het volgende geschreven: >> On 8/8/11 10:36 AM, DI. Thomas Schallar wrote: >>> To have our IPv6 space be explicitly multihomed, we have to >>> >>> * apply for an AS for proper BGP announcement >>> * change fom cheap Internet uplink to expensive transit >> >> that does not change with removing the multihoming requirement. PI is >> still PI and you need to announce it via BGP and your ASN. > > Why? We (as a multihomed ISP) announce both our own PA blocks and one of > our customers PI block in v4 - why wouldn't that work/be allowed in v6? > There's no need for an ASN or BGP capable router at the customer. > > Paul. > From jan at go6.si Mon Aug 8 11:31:26 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Aug 2011 11:31:26 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3F9FF3.9080100@avalon.at> <4E3FA565.4020602@go6.si> <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> Message-ID: <4E3FACEE.3090308@go6.si> On 8/8/11 11:06 AM, Paul Hoogsteder wrote: >> On 8/8/11 10:36 AM, DI. Thomas Schallar wrote: >>> To have our IPv6 space be explicitly multihomed, we have to >>> >>> * apply for an AS for proper BGP announcement >>> * change fom cheap Internet uplink to expensive transit >> >> that does not change with removing the multihoming requirement. PI is >> still PI and you need to announce it via BGP and your ASN. > > Why? We (as a multihomed ISP) announce both our own PA blocks and one of > our customers PI block in v4 - why wouldn't that work/be allowed in v6? > There's no need for an ASN or BGP capable router at the customer. True. Not very "clean" way, but definitely possible. It would be nice to have some data on "how common" is this way of announcing PI space. Probably we could find out how many PI allocations don't have their own ASN. Cheers, Jan From stolpe at resilans.se Mon Aug 8 11:25:41 2011 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 8 Aug 2011 11:25:41 +0200 (CEST) Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> Message-ID: On Mon, 8 Aug 2011, Tero Toikkanen wrote: >> I support this proposal. > > +1 I do as well. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From Jasper.Jans at espritxb.nl Mon Aug 8 11:39:32 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 8 Aug 2011 11:39:32 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3FACEE.3090308@go6.si> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3F9FF3.9080100@avalon.at> <4E3FA565.4020602@go6.si> <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> <4E3FACEE.3090308@go6.si> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FEF51A6@EXCH01.campus.local> This is in 95% of the cases also how we run things. >> Why? We (as a multihomed ISP) announce both our own PA blocks and one of >> our customers PI block in v4 - why wouldn't that work/be allowed in v6? >> There's no need for an ASN or BGP capable router at the customer. > > True. Not very "clean" way, but definitely possible. It would be nice to > have some data on "how common" is this way of announcing PI space. > Probably we could find out how many PI allocations don't have their own ASN. Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From jan at go6.si Mon Aug 8 12:03:07 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Aug 2011 12:03:07 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <7183DCEF-157C-4230-AA1C-278AEE38F8BD@A2B-Internet.com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3F9FF3.9080100@avalon.at> <4E3FA565.4020602@go6.si> <900d7f51df339626de0335b0fe547568.squirrel@webmail.prolocation.net> <7183DCEF-157C-4230-AA1C-278AEE38F8BD@A2B-Internet.com> Message-ID: <4E3FB45B.6020607@go6.si> On 8/8/11 11:32 AM, Erik Bais wrote: > Hi Paul, > > That is indeed a very common setup and removing the multi-home > requirement for v6 will allow us to do the same for those PI > customers. So, to me then this looks like we are just tuning the policy to be in sync with real world. +1 Cheers, Jan From cagri.yucel at adaptplc.com Mon Aug 8 11:36:49 2011 From: cagri.yucel at adaptplc.com (Cagri Yucel) Date: Mon, 8 Aug 2011 09:36:49 +0000 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> Hi all, I think multi-homing requirement is a good disincentive to get a PI space purely for portability and carrier independence reasons. If this change goes ahead everyone can simply go for PI and this is likely to have route aggregation utilized less and less. I don't want to start another "millions of routes vs router memory discussion" by any means however I believe we should encourage aggregation whenever possible for practical reasons. Reading recent postings; 1. End-users making false multi-homing declarations to get PI. I think removing requirement is not the solution. Another option is to ask for an evidence to ensure there is a good justification for PI use. 2. Sending end-users to competitor? Why should this happen? I would expect an ISP to be able to offer direct feeds from different providers (this is an actual requirement if they would like to offer highly available services anyhow). 3. End-users paying for LIR to just to get PI space; again if there is a problem with LIR requirements justification, or RIPE membership is being used for a purpose which has not been intended for, removing multi-homing requirement is not the solution. We should rather look into relevant policies to ensure end-users become LIR when they actually need to further assign IPs to their customers. My recommendation is to keep RIPE-512 as it is. Kind regards, Cagri Yucel -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Erik Bais Sent: 06 August 2011 11:43 To: 'DI. Thomas Schallar'; 'RIPE Address Policy Working Group' Cc: jordi.palet at consulintel.es Subject: RE: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? Hi Thomas, A quick update on the status of 2011-02 policy. I spoke with the AP-WG-chair last week and the decision is that there will be an extended review period to give people the time to ask questions if needed on the proposal. So to everyone on the list, let's hear it. I've done a presentation on RIPE62 on the proposal for those not familiar with 2011-02 and you can find the PPT here : http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt You can read the policy proposal itself here: http://www.ripe.net/ripe/policies/proposals/2011-02 In short, the policy proposal is to remove the multi-homing requirement for PI IPv6. Currently, companies can become a LIR and get IPv6, with no multi-home requirement, same with requesting IPv4 PI. And companies that don't want to or (legally) can't become a LIR but do want to have their own IPv6 addresses are required to be multi-homed. The only change in text in the RIPE-512 is: Remove the line: a) demonstrate that it will be multihomed For those that agree with the policy and everything is clear, express your support on the AP-WG-mailing list your support. Kind regards, Erik Bais Co-author of 2011-02 This message has been scanned for viruses by Mail Control - www.adaptplc.com This message has been scanned for viruses by Mail Control - www.adaptplc.com The information in this internet email is confidential and is intended solely for the addressee. If you are not the intended recipient please contact Adapt Group, London, 020 3009 3300. Adapt, Adapt Managed Services and Centric Telecom are all trading names of operating companies wholly owned by Adapt Group Limited (Company No. 05275131) which is registered in England and Wales. Its registered office is 35 New Broad Street, London, EC2M 1NH. From he at uninett.no Mon Aug 8 12:40:48 2011 From: he at uninett.no (Havard Eidnes) Date: Mon, 08 Aug 2011 12:40:48 +0200 (CEST) Subject: [address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <20110808.124048.183700791.he@uninett.no> Hi, I'm not sure I agree with the proposed policy. > I've done a presentation on RIPE62 on the proposal for those not familiar > with 2011-02 and you can find the PPT here: > http://ripe62.ripe.net/presentations/171-2011-02_ripe62.ppt I find the justification given in "where does it come from" on slide 7 to be a bit weak. Specifically, as noted elsewhere in the slide deck, it's not just the LIR fee to get IPv6 PA space which acts as a pushback. So therefore I think the conclusion which says that the community does not care or does not need to worry about the IPv6 DFZ size, or that there are no technical issues, to be weakly founded. So by removing the requirement for multi-homing to get IPv6 PI space yet one more part of the dike to stem the flood into the DFZ is whittled away. Who is willing to predict whether IPv6 PI after this policy is passed is going to be the modern-day equivalent of the old "swamp" in the 192.0.0.0/8 space, where route aggregation is impossible and ownership of address blocks is scattered far and wide. Underlying, and unstated seems to be an assumption that "everyone has a birthgiven right to a non-changing IPv6 address when one changes provider". Is that really a given? Best regards, - H?vard From nick at inex.ie Mon Aug 8 12:51:11 2011 From: nick at inex.ie (Nick Hilliard) Date: Mon, 08 Aug 2011 11:51:11 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <4E3FBF9F.3000407@inex.ie> On 06/08/2011 11:42, Erik Bais wrote: > In short, the policy proposal is to remove the multi-homing requirement for > PI IPv6. > Currently, companies can become a LIR and get IPv6, with no multi-home > requirement, same with requesting IPv4 PI. I don't support this policy as it stands, because it makes it too easy to get PI space instead of PA space. This will cause deaggregation in the ipv6 DFZ. Deaggregation is a serious operational issue which gets monotonically worse over time. It never improves, and 2011-02 will simply aggravate the problem. This is important because we are designing constraints for a protocol which is expected to last for a very long time. We've had 30 years of IPv4 so far, and there's no reason to expect that ipv6 won't last several times that length. If we start off with too liberal a policy, then it will create a nasty mess which will blight DFZ routing in future years. If the policy were changed to add in a clause that the end-user was explicitly required to provide evidence that they needed PI space instead of PA, then I would support it. This change would raise the bar slightly but significantly, and would also align the proposed IPv4 PI policy (2006-05) with the proposed IPv6 PI policy (2011-02) in this particular respect. I believe that there is merit in both of these things. Nick From jan at go6.si Mon Aug 8 13:07:46 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Aug 2011 13:07:46 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3FBF9F.3000407@inex.ie> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <4E3FBF9F.3000407@inex.ie> Message-ID: <4E3FC382.6050309@go6.si> On 8/8/11 12:51 PM, Nick Hilliard wrote: > On 06/08/2011 11:42, Erik Bais wrote: >> In short, the policy proposal is to remove the multi-homing requirement for >> PI IPv6. >> Currently, companies can become a LIR and get IPv6, with no multi-home >> requirement, same with requesting IPv4 PI. > > I don't support this policy as it stands, because it makes it too easy to > get PI space instead of PA space. This will cause deaggregation in the > ipv6 DFZ. > > Deaggregation is a serious operational issue which gets monotonically worse > over time. It never improves, and 2011-02 will simply aggravate the problem. the best solution then is to give IPv6 space to nobody, so routing tabe does not deagregate and grow beyond memory limits :) Joke aside, if enterprises and mid-sized companies can get IPv6 PI without multihoming requirements and this means this lowers the need of NAT66 - I'm all for it. If we think multihoming requirement is a speed-bump for folx requesting IPv6 space, remove it. Maybe we could charge more for PI that does not show multihoming and usual price for PI that does multihoming. Cheers, Jan From emadaio at ripe.net Mon Aug 8 14:08:08 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 08 Aug 2011 14:08:08 +0200 Subject: [address-policy-wg] 2006-05 Last Call for Comments (PI Assignment Size) Message-ID: <20110808120808.67F076A020@postboy.ripe.net> Dear Colleagues, The proposal described in 2006-05 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 5 September 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From Woeber at CC.UniVie.ac.at Mon Aug 8 14:27:05 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 08 Aug 2011 12:27:05 +0000 Subject: [address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <20110808.124048.183700791.he@uninett.no> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <20110808.124048.183700791.he@uninett.no> Message-ID: <4E3FD619.2060900@CC.UniVie.ac.at> Hi H?vard, Community, please allow me follow up on this contribution, and some other comments, by stating that 1) from a purely "traditional" technical point of view, I don't totally like it, but 2) I consciously *do* support the proposal. Actually for various reasons. Please see below... Havard Eidnes wrote: > Hi, > > I'm not sure I agree with the proposed policy. > [...] > > So by removing the requirement for multi-homing to get IPv6 PI > space yet one more part of the dike to stem the flood into the > DFZ is whittled away. Yes, probably. But this "flood" is running into the DFZ since the days well before significant take-up of IPv6. And nobody felt motivated to do anything against it. Has anyone been reading the weekly routing table statistics for all these years, and maybe noticed that there is a ("technically cheap") considerable potential to *shrink* the DFZ? ;-) So, yes, from a purely technical aspect, I agree, from a reality-check point of view I consider the aspect as moot. > Who is willing to predict whether IPv6 PI > after this policy is passed is going to be the modern-day > equivalent of the old "swamp" in the 192.0.0.0/8 space, where > route aggregation is impossible and ownership of address blocks > is scattered far and wide. Maybe, even a good chance for that. But, again, looking back the few decades to classful addressing and the TWD - those "inefficient" approaches made it easy to get IPv4 rolled out and broke the ground for the success of today's Internet. So, I am willing to take the chance here with IPv6 and closely track the result. As someone else has correctly pointed out already, the RIPE Community can change policy at any time. > Underlying, and unstated seems to be an assumption that "everyone > has a birthgiven right to a non-changing IPv6 address when one > changes provider". Is that really a given? No, I guess not. But - on the other hand, my feeling is that the recipients of resources do have some "right" to a consistent set of policies and to a stable environment. *Not* removing the MH requirement for IPv6 PI, but soon having accepted the minimum IPv4 PI assignment size as /24 for *routing reasons* strikes me as - well - royally broken (ref. 2006-05). The policy imbalance IPv4 / IPv6 has already been mentioned. As an aside, those IPv6 PI assignments are going to be made from (a) specific block(s), so the "no routing guarantee" can kick in at any time, at the sole discretion of an individual ISP. > Best regards, > > - H?vard And, last but not least, the current situation does not consider the following two scenarios/aspects: - seeing the NCC motivated to check the MH-ness, from their vantage point(s), while there is no mechanism available to do that "correctly" or decisively[1], and - there is no provision in the existing policy that (explicitely) describes the consequences of (maybe temporarily?) loosing the MH-ness. Hth, with no hats on other than being a "silver surfer" who eventually decided to accept the fact that the Internet, in this millennium, is no longer an exlusively technology-driven environment. I consider this :-) and :-( , but that's OT... Wilfried. [1] the way I am reading the policy, there is no requirement to have all paths, and announcement origins, of a particualr prefix visible in the DFZ or "everywhere" on the 'net. Thus the NCC seeing MH from their vantage point(s) *is* a useful reading, but *not* seeing that from their poisition *doesn't tell them anything*. Which IMHO invalidates the whole concept of requiring MH-ness by expecting the NCC to verify that. From ebais at a2b-internet.com Mon Aug 8 16:54:56 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 8 Aug 2011 16:54:56 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> Message-ID: <000d01cc55db$236b38d0$6a41aa70$@com> Hi Cagri, > I think multi-homing requirement is a good disincentive to get a PI > space purely for portability and carrier independence reasons. This is where I have to disagree with you. Having portable IP space has nothing to do with being multi-homed imho. >From what I see in our customer base, having portable IP space is a seen as an insurance if you like. Customers that apply for PI for different reasons, like building a VPN structure for a car dealer-ship with 200+ outlets or an Iphone app delivery system + apple sandbox that is linked to a specific subnet. Having to renumber those kind of setups are a pain to renumber after the initial setup and companies are hand-cuffed to the IP addresses and the LIR that holds them hostage to it. As long as everything works fine and the ISP is performing as required, everything is ok, however if that changes and other factors like network performance, packetloss, price or constant downtime because other customer(s) of their hoster is having DoS attacks, come into play, it is a different discussion. The requirement for being multi-homed is a discussion about uptime requirement. Sometimes this is driven by the end-customers business regulation and in other situations it is because they want to be-able to manage their own faith in regards of uptime. The question of 'what is being multi-homed' is another discussion. There are plenty of ISP's that provide fully redundant network setups from within their own AS, however as the term 'being multi-homed' in itself isn't clearly defined by this community, it is open for debate. For argument sake, I personally refer to being multi-homed as being connected to more than 1 AS, using BGP. That leaves open, could the originating AS of the PI v6 be the AS of a hoster or does the end-customer requires their own AS ? > If this change goes ahead everyone can simply go for PI and this is likely to > have route aggregation utilized less and less. If the change is approved, it allows end-customers to request PI for v6 (same as they could today apply for PI for v4.) Today, if they can't apply for PI v6, because they are not planning to be multi-homed, they could apply for a LIR membership, request v6, no questions asked. Result: No multi-homing requirement and also the same growth of DFZ as if the end-customer would request PI v6 without multi-homing. > I don't want to start > another "millions of routes vs router memory discussion" by any means > however I believe we should encourage aggregation whenever possible for > practical reasons. The majority of the de-aggregation doesn't come from PI, but from PA space, only a very small part of the PI IPv4 space is actually de-aggregated. And yes, I fully agree with you that aggregation should be done where possible. > Reading recent postings; > > 1. End-users making false multi-homing declarations to get PI. I think > removing requirement is not the solution. Another option is to ask for > an evidence to ensure there is a good justification for PI use. There is no evidence to get for something that is not there yet. If an end-customer doesn't have PI, how could one provide proof that it is multi-homed ? It is the chicken and the egg problem. They don't have an AS yet as they don't have PI yet. And checking after the fact, is that what we want ? And what if some prefix isn't seen twice in the DFZ ? Are you planning to have RIPE NCC revoke it ? All RIPE NCC can do currently is ask for the intention, but enforcing it is just not possible. There are also a number of networks that are fully functioning on actual unique IP's, but are not advertized into the DFZ, but they are still multi-homed. > 2. Sending end-users to competitor? Why should this happen? I would > expect an ISP to be able to offer direct feeds from different providers > (this is an actual requirement if they would like to offer highly > available services anyhow). If an ISP only holds 1 AS and they have a customer who likes their service, but that end-customer wants to run on PI IPv6, today, they would have to get another AS involved to be able to meet the PI v6 requirement. I've asked other ISP's and they stated that they have a secondary AS running for this particular reason. People are creative and very protective on their revenue, so why send customers to competitor X if you don't have to ? > 3. End-users paying for LIR to just to get PI space; again if there is > a problem with LIR requirements justification, or RIPE membership is > being used for a purpose which has not been intended for, removing > multi-homing requirement is not the solution. We should rather look > into relevant policies to ensure end-users become LIR when they > actually need to further assign IPs to their customers. I've seen end-customers in The Netherlands, apply for a LIR membership, because they didn't receive the required IP addresses from their Telco. The current discussion on XXS & XS sized LIR's on the membership mailing list will only speed that up. I'm personally in favor for an increase in the yearly cost (upkeep) for PI. (Both for IPv4 and v6) As this whole discussion in reality is already a financial discussion and not a technical one. There are also legal issues for some end-customers that won't allow them to become a LIR, but they have, at the same time, still the requirement to have their own IP unique addresses. The policy proposal by itself is not technical, as the reality is already providing 'creative' solutions for customers that really want to move ahead. The policy is to make PI IPv6 the same as PI for IPv4. Regards, Erik Bais From t.schallar at avalon.at Mon Aug 8 17:00:55 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Mon, 08 Aug 2011 17:00:55 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> Message-ID: <4E3FFA27.9010202@avalon.at> Hello all! I don't believe that "making it complicated" will change anything in the demand and applications for PI address space. Home Users or small companies with just 1-8 IPv4 addresses resp. one /64 prefix don't need PI now and won't need it in the future. Whatever they need to change is done rather quickly. Big companies however, with several networks and several sites, do need PI. We need PI address space for our infrastructure. No matter how complicated it will get - we already did it resp. will do everything necessary it in the future, to have and keep it. The same for our major customers. When they need PI space they will do whatever is necessary to get it. So as long as there is PI available, you need technological solutions to make it work. Of course I see the problems with growing routing tables. But customers do need PI so they will apply for PI and therefore the routing tables are growing. So you need a solution. And - sorry - it's no solution to just make it complicated/expensive and save the real solution for later. To implement PI you need a provider. A provider is multihomed. So when the provider adds your v4/v6 PI space to his AS, it definitely is multihomed. You won't need your own AS to tell that to the world. :-) More important: I don't believe that I am a great prophet by saying, that the demand of PI space in IPv6 is much greater than it ever was in IPv4! Think of a regular company with several internal networks for DMZ, server-LAN, PC-LAN, VoIP LAN, VPN, development departments and with a couple of firewalls and routers between them. With IPv4 it's no big deal to change the provider. One just has to change the external IP address(es), make DNS adjustments and some tweeks in the firewalls of remote sites (subsidiaries) and within 0.5 to 4 hours the task is complete. Everything internal will stay the same with NAT-ed addresses. But think of a provider change for such a setup with IPv6 on all networks! All routers, machines, servers and - that's the biggest issue - all firewalls are set up for the IPv6 addresses used. Changing them - with no major service disruption during working hours = on the weekend = dozens of hours at the most expensive time rates = several thousand Euros - will cost much much more, than to comply with the "artificially" complcated and unnecessary cost-expensive PI requirements today. So every bigger company WILL REQUEST v6 PI SPACE. At least after their first provider change... ;-) Provider changes are not so rare as one might think! Many small providers offer good packages or features, that big providers won't/can't offer. The customer chooses the small provider and gets PA space. Some years later, the small provider will be absorbed by a bigger provider and the need for change is there. On average, we have one provider change per month with the customers we support. So in my opinion: either if you remove the demand of being multihomed or not: you have to work out technical solutions for the many, many IPv6 PIs that WILL be requested within the next years! Making it complicated or expensive won't change that. It will only add unneccessary workload on all ends. Yes I *DO* support the proposal to remove the multihomed requirement for IPv6 PI. regards, Thoma From sander at steffann.nl Mon Aug 8 17:09:57 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 8 Aug 2011 17:09:57 +0200 Subject: [address-policy-wg] Discussion standards Message-ID: <11F6CE97-3D7C-475B-BEB9-4ED4E6378446@steffann.nl> Hello working group, Declaration of hats: speaking on behalf of the chairs of this working group: Gert D?ring and myself. We have noticed that in the last months a lot of messages about policy proposals contain assumptions, feelings and expectations. While these can be very important in a discussion it is very hard to discuss such statements. Too much of this and it can make policy development nearly impossible. If we want to make good decisions and work towards consensus we need to raise our standards a bit. I want to ask everybody here to add supporting facts, numbers, statistics or other data wherever possible. That doesn't mean that nobody should express their doubts or opinions! All input is still welcome. But please be aware that when trying to judge if consensus has been reached we might give less weight to input that has no data backing it. Thank you, Sander Steffann APWG Co-chair From joao at bondis.org Mon Aug 8 16:42:24 2011 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Mon, 8 Aug 2011 16:42:24 +0200 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <20110728103305.E8BA36A03C@postboy.ripe.net> References: <20110728103305.E8BA36A03C@postboy.ripe.net> Message-ID: <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> IMHO[1] I think this better that what we have now in that it allows us to make use of the last bits of address space and any that may become available later on. Probably not going to make a huge difference in extending IPv4's life but sure stops people complaining about the IANA holding numbers that could be put to use on the Internet. As a matter of local implementation, if this policy is adopted, I would like to request that the RIPE NCC issue public statements to its members each time this policy is exercised, whether it gets new addresses in the period or not. Joao [1] http://oxforddictionaries.com/definition/IMHO On 28 Jul 2011, at 12:31, Emilio Madaio wrote: > > Dear Colleagues, > > The Review Period for the proposal 2011-01 has been extended until 25 > August 2011. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-01 > > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Emilio Madaio > Policy Development Officer > RIPE NCC > From sam-ml at arahant.net Mon Aug 8 16:56:21 2011 From: sam-ml at arahant.net (sam) Date: Mon, 8 Aug 2011 15:56:21 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> Message-ID: Hi all, On Aug 8, 2011, at 10:36 AM, Cagri Yucel wrote: > > 1. End-users making false multi-homing declarations to get PI. I think removing requirement is not the solution. Another option is to ask for an evidence to ensure there is a good justification for PI use. You mean evidence as in "verify" that the PI space gets advertised via both the upstreams claimed during the requesting process? RIPE NCC is kinda strict on requiring mail contacts of the provided upstreams to eventually verify the validity of the data and I believe there's no better way to do it. -- sam From ebais at a2b-internet.com Mon Aug 8 17:32:54 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 8 Aug 2011 17:32:54 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3FBF9F.3000407@inex.ie> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <4E3FBF9F.3000407@inex.ie> Message-ID: <000e01cc55e0$716aed50$5440c7f0$@com> Hi Nick, > I don't support this policy as it stands, because it makes it too easy > to > get PI space instead of PA space. This will cause deaggregation in the > ipv6 DFZ. I don't think it would cause de-aggregation (for definition how I see it, announcing a single allocation into smaller subnets), but it might bring more prefixes in the DFZ. However a PI IPv6 subnet or a PA IPv6 subnet for a new LIR that isn't multi-homed could be seen as equal. So from that perspective, this policy proposal doesn't change anything. What I did already see is v6 PA space being handed out to customers and being announced in smaller prefixes under another AS than the /32 PA that it came from. > If the policy were changed to add in a clause that the end-user was > explicitly required to provide evidence that they needed PI space > instead > of PA, then I would support it. This change would raise the bar > slightly > but significantly, and would also align the proposed IPv4 PI policy > (2006-05) with the proposed IPv6 PI policy (2011-02) in this particular > respect. I believe that there is merit in both of these things. Personally I think that providing evidence is open for motivational discussions. If one can motivate why he/she requires PI, they should get it. I rather don't see such a arguable line taken up in the policy, but much rather see an increase in the (financial) cost for becoming a LIR AND specifically the cost for PI. Along the same line as 2006-05 is, stop BS'ing to the IPRA's, tell them what you / your customer require, without inflating the story. What is the ONLY reason why an end-customer would return their IP addresses ? A financial reason. I dare to say that a lot of space is not returned, because the end-customer or the LIR doesn't feel the pain (the upkeep cost) for it. Increasing the cost for PI will be the way to make sure that end-customers are going to think twice. Do I really need this, or is it just cool to have. However, the RIPE community can't dictate the cost for PI, as that is to be decided in the AGM meeting by the member votes. The initial draft (before publishing) had in fact an increase in the cost for PI, however as these are 2 separate paths to be taken, it was decided not included it in 2011-02. Regards, Erik Bais From nick at inex.ie Mon Aug 8 23:16:57 2011 From: nick at inex.ie (Nick Hilliard) Date: Mon, 08 Aug 2011 22:16:57 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <000e01cc55e0$716aed50$5440c7f0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <4E3FBF9F.3000407@inex.ie> <000e01cc55e0$716aed50$5440c7f0$@com> Message-ID: <4E405249.8010102@inex.ie> Hi Eric, >> I don't support this policy as it stands, because it makes it too >> easy to get PI space instead of PA space. This will cause >> deaggregation in the ipv6 DFZ. > > I don't think it would cause de-aggregation (for definition how I see > it, announcing a single allocation into smaller subnets), but it might > bring more prefixes in the DFZ. That'll teach me a thing or two about attempting to write a coherent email before coffee o'clock on a Monday morning, sigh. Of course, I didn't mean "deaggregation", but was rather talking about excessive growth of the ipv6 dfz due to the announcement of large numbers of ipv6 PI blocks from end users who would do just as well to use PA. There is ample evidence of ipv4 PI address space being used as a generic substitute for PA space in certain geographic regions, and there are no good reasons to think that the situation will be any different for ipv6. Once a swamp is created, it is virtually impossible to drain. > What I did already see is v6 PA space being handed out to customers and > being announced in smaller prefixes under another AS than the /32 PA > that it came from. Yes, that happens. Some end-users do this for (e.g.) load balancing purposes. > Personally I think that providing evidence is open for motivational > discussions. If one can motivate why he/she requires PI, they should get > it. I rather don't see such a arguable line taken up in the policy, but > much rather see an increase in the (financial) cost for becoming a LIR > AND specifically the cost for PI. If an end user requires PI, then they should have a reason for requiring it. I don't want to see PI prefixes handed out like packs of Smarties, because that is objectively harmful to the Internet. I.e. it has a direct impact on the bottom line of service provider budgets. > Along the same line as 2006-05 is, stop BS'ing to the IPRA's, tell them > what you / your customer require, without inflating the story. The changes in 2006-05 are twofold: 1. to allow multihoming as a valid reason for applying and 2. to set the minimum size for prefixes which will be multihomed to be the de-facto /24 that is generally accepted in the Internet dfz. #2 levels the field slightly with respect to the difference in assignment criteria between ipv4 and ipv6. There's nothing in 2006-05 which suggests that the end user doesn't need to provide a reason for requiring PI. Quite the opposite, in fact. > What is the ONLY reason why an end-customer would return their IP > addresses ? A financial reason. I dare to say that a lot of space is not > returned, because the end-customer or the LIR doesn't feel the pain (the > upkeep cost) for it. > > Increasing the cost for PI will be the way to make sure that > end-customers are going to think twice. Do I really need this, or is it > just cool to have. > > However, the RIPE community can't dictate the cost for PI, as that is to > be decided in the AGM meeting by the member votes. It's more difficult than this. Because of the sheer numbers of PI assignments, increasing the "wholesale" cost even by a small amount will have a significant impact on the RIPE NCC's budget. That would create... awkward bureaucratic problems for the RIPE NCC. Nick From Woeber at CC.UniVie.ac.at Tue Aug 9 09:03:59 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Aug 2011 07:03:59 +0000 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E405249.8010102@inex.ie> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <4E3FBF9F.3000407@inex.ie> <000e01cc55e0$716aed50$5440c7f0$@com> <4E405249.8010102@inex.ie> Message-ID: <4E40DBDF.8030100@CC.UniVie.ac.at> [beware: slightly off-topic maybe, but imho fundamentally important] Nick Hilliard wrote: > Hi Eric, [...] >>However, the RIPE community can't dictate the cost for PI, as that is to >>be decided in the AGM meeting by the member votes. This is "just" procedural, but... > It's more difficult than this. Because of the sheer numbers of PI > assignments, increasing the "wholesale" cost even by a small amount will > have a significant impact on the RIPE NCC's budget. That would create... > awkward bureaucratic problems for the RIPE NCC. This line of thinking would be even more than "difficult" to maintain: it would simply turn the funding and charging model for the RIPE NCC's services upside-down. The fundamental assumption is that the charging model provides the money to allow the RIPE NCC to execute the annual activity-plan (as agreed by the AGM), and to maintain a certain level of safety-belt funds to guarantee the stability of the NCC itself. The Service Charges are to be set according to cost and effort *within the NCC* to provide the services (plus the overhead, according to the activity plan). The NCC, for good reasons imho, is a not-for-profit entity and is *not* mandated (nor formally allowed, I presume) to collect money for and/or redistribute to any third party, which is not directly involved or necessary in the management of Number Resources. > Nick I think it is pretty important to keep this in mind, in general. Wilfried. From Woeber at CC.UniVie.ac.at Tue Aug 9 11:49:19 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Aug 2011 09:49:19 +0000 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> References: <20110728103305.E8BA36A03C@postboy.ripe.net> <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> Message-ID: <4E41029F.8010309@CC.UniVie.ac.at> Jo?o Damas wrote: > IMHO[1] I think this better that what we have now in that it allows us > to make use of the last bits of address space and any that may become > available later on. I agree, and thus I support the proposed policy. > Probably not going to make a huge difference in extending IPv4's life > but sure stops people complaining about the IANA holding numbers that > could be put to use on the Internet. Checking the text again, I do see some aspects that may be ambiguous and/or require clarification: Section 1.0, after bullet point 2, The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space. As the different regions do have, or are still discussing, various (micro-)policies to reserve blocks or to set aside blocks for specific purposes, the term "inventory" either needs clarification/definition or there should be an explanation which part(s) of the RIR's IPv4 address space is considered to belong to the "inventory". My personal proposal would be to clearly state that *all* currently unused space in an RIR is considered its "inventory". As an aside, and given the fact that there is no specification about the fate of returned address blocks within a Region, what is expected to happen, when and if no RIR is below the /9 threshold any longer? Will the RIP (Recovered IPv4 Pool :-) ) be declared inactive again, or not? I do understand that this is not very likely. Regarding timelines: It is not clear to me, whether the 1st round of redistribution happens "immediately" after declaring the RIP active, and thereafter will be synched to the March1/Sept1 schedule? Alternatively, the 1st round may be executed at the next scheduled date. My personal preference here would be to act "immediately" and then take up the schedule, with the effect of potentially not having anything to dish out for the next round(s) and thus skip the next scheduled date(s) . However, this approach may run against the intention(?) of proposing a fixed 6m schedule (in order to accumulate a reasonably big RIP?). Maybe the authors could explain the rationale for the particular schedule? > As a matter of local implementation, if this policy is adopted, I would like to > request that the RIPE NCC issue public statements to its members each time this > policy is exercised, whether it gets new addresses in the period or not. Regarding the Impact Analysis: Is there any exisiting or proposed policy in our region that would be impacted or even invalidated by this proposal becoming Global Policy? > Joao > > [1] http://oxforddictionaries.com/definition/IMHO Thanks for the [1] :-) , Wilfried. > On 28 Jul 2011, at 12:31, Emilio Madaio wrote: > > >>Dear Colleagues, >> >>The Review Period for the proposal 2011-01 has been extended until 25 >>August 2011. >> >> >>You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-01 >> >> >>We encourage you to review this policy proposal and send your comments >>to . >> >>Regards, >> >>Emilio Madaio >>Policy Development Officer >>RIPE NCC From swmike at swm.pp.se Tue Aug 9 12:06:48 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 9 Aug 2011 12:06:48 +0200 (CEST) Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3FFA27.9010202@avalon.at> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <44E40544EDC51B4B9E0A6376560FB635323E24D9@GBEXMB02.as24867.intra> <4E3FFA27.9010202@avalon.at> Message-ID: On Mon, 8 Aug 2011, DI. Thomas Schallar wrote: > So as long as there is PI available, you need technological solutions to > make it work. Of course I see the problems with growing routing tables. > But customers do need PI so they will apply for PI and therefore the > routing tables are growing. So you need a solution. And - sorry - it's > no solution to just make it complicated/expensive and save the real > solution for later. I don't agree. Time is money, and having a procedure that requires hours to handle to get PI is a reasonable barrier of entry to start using this global resource. Personally was inclined to apply for AS, PIv4 and PIv6, but after spending 30 minutes on the application documents, I grew tired and stopped. I'm a router guy, I don't really appreciate paperwork. I think the current state of affairs is ok, I support changing the multihomed requirement for IPv6 as per this proposal, but I still feel the situation needs to be monitored and there needs to be a yearly review regarding how many new PI applications are approved, and if it looks like a exponential growth, then it needs to be curbed somehow. Right now there are no facts to support this change growth, but I still fear there might be a change in growth rate if the rules are changed so that it becomes really easy to get PI addresses. -- Mikael Abrahamsson email: swmike at swm.pp.se From emadaio at ripe.net Tue Aug 9 13:31:32 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 09 Aug 2011 13:31:32 +0200 Subject: [address-policy-wg] 2011-02 Review Period extended until 23 August 2011 (Removal of multihomed requirement for IPv6 PI) Message-ID: <20110809113133.16A4D6A056@postboy.ripe.net> Dear Colleagues, The Review Period for the proposed change to RIPE Document has been extended until 23 August 2011. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-02 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From andreas.larsen at ip-only.se Tue Aug 9 16:44:43 2011 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 9 Aug 2011 16:44:43 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E3EC9AA.8000202@go6.si> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <55557D0EBE9495428BFE94EF8BC5EBD201039FEF50B1@EXCH01.campus.local> <4E3EC9AA.8000202@go6.si> Message-ID: +1 I support the proposal On Sun, 2011-08-07 at 19:21 +0200, Jan Zorz @ go6.si wrote: > On 8/7/11 2:29 PM, Jasper Jans wrote: > > I support this proposal. > > +1 > > This just means we remove the need to lie anymore to IPRAs about > multihoming, if small/medium organization wants their IPv6 block and do > not plan to actually be multihomed. :) > > Actually, with this we remove the only reason why NAT66 could exist :) > Get your PI and don't translate addresses, if you change provider you > are still good. > > Cheers, Jan Zorz > -- IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se From boggits at gmail.com Tue Aug 9 17:01:27 2011 From: boggits at gmail.com (boggits) Date: Tue, 9 Aug 2011 16:01:27 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <003401cc5425$9af655e0$d0e301a0$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: On 6 August 2011 11:42, Erik Bais wrote: > I spoke with the AP-WG-chair last week and the decision is that there will > be an extended review period to give people the time to ask questions if > needed on the proposal. I'm still of the opinion that removing the dual homing requirement for PI is a mistake. Having done some work on renumbering on IPv6, its much easier than v4 (assuming that you design the addressing to be portable) and not the barrier that people believe that it is with v4. Please feel free to correct my thinking but PA space is for LIRs to give to customers for their use, PI space is for those customers who require a separate block because they need to be 'independent' of their LIR. The only time this is required (afaict) is when the block *needs* to be routed by a third party for resilience and therefore needs to be multi-homed. By removing that requirement we are 'encouraging' the requisition of additional resources where non is required and increasing the size of the routing table unnecessarily. If there is another problem we are trying to solve (as in PI space not being suitable for sub-allocation) then we are trying to solve it the wrong way... J -- James Blessing 07989 039 476 From slz at baycix.de Tue Aug 9 17:50:55 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 9 Aug 2011 17:50:55 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> Message-ID: <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> Hi, >> I spoke with the AP-WG-chair last week and the decision is that there will >> be an extended review period to give people the time to ask questions if >> needed on the proposal. > > I'm still of the opinion that removing the dual homing requirement for > PI is a mistake. > > Having done some work on renumbering on IPv6, its much easier than v4 > (assuming that you design the addressing to be portable) and not the > barrier that people believe that it is with v4. > > Please feel free to correct my thinking but PA space is for LIRs to > give to customers for their use, PI space is for those customers who > require a separate block because they need to be 'independent' of > their LIR. The only time this is required (afaict) is when the block > *needs* to be routed by a third party for resilience and therefore > needs to be multi-homed. > > By removing that requirement we are 'encouraging' the requisition of > additional resources where non is required and increasing the size of > the routing table unnecessarily. > > If there is another problem we are trying to solve (as in PI space not > being suitable for sub-allocation) then we are trying to solve it the > wrong way... this is a repeat for the 68060th time so i try to be brief: there wasn't a multihoming requirement in the IPv4 PI world lately, or was it? there is no IPv4 PI problem (rather a IPv4 PA deaggregation problem), so there certainly won't be any with IPv6 PI - by design ("one prefix only, usually") there is a problem with this difference between IPv4 and IPv6 PI policies which hinders IPv6 deployment right now This policy change is about NOTHING else than aligning the IPv6 PI policy with the IPv4 PI policy we have for ages. It will not end the world or encourage more IPv6 PI usage than IPv4 PI usage. All other requirements are still the same (roughly). This policy change does not try to solve any other problem than allowing IPv4 PI holders who don't multi-home to be able to get IPv6 PI and do the right thing - getting IPv6 deployment started. If there is a problem with this policy in 5-10 years due to some reasons, we can change the policy again, it's not written in stone. Things change, policies can, too. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From jim at rfc1035.com Tue Aug 9 18:25:22 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 9 Aug 2011 17:25:22 +0100 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> Message-ID: <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> On 9 Aug 2011, at 16:50, Sascha Lenz wrote: > there is no IPv4 PI problem (rather a IPv4 PA deaggregation problem), So there's no problem with IPv4 PI space. Except when there is one. And that can be fixed by calling it something different. I see. :-) > there is a problem with this difference between IPv4 and IPv6 PI > policies which hinders IPv6 deployment right now Please explain Sascha. I just don't get it. IPv6 deployment isn't hindered by the availability of PI space. At least not in the general case. Can you give some actual examples where a problem getting PI IPv6 space has (or is) a showstopper for IPv6 deployment? > This policy change is about NOTHING else than aligning the IPv6 PI > policy with > the IPv4 PI policy we have for ages. That's all very well. However it may be the answer to the wrong question. Suppose we didn't have IPv4 PI space at all. Would we invent this concept for IPv6? If so, why? If not, why not? > This policy change does not try to solve any other problem than > allowing IPv4 PI holders who don't multi-home to be able to get IPv6 > PI and do the right thing - getting IPv6 deployment started. Maybe, but why does someone need IPv6 PI space to start deploying IPv6? > If there is a problem with this policy in 5-10 years due to some > reasons, we can change the policy again, it's not written in stone. > Things change, policies can, too. In that case, let's leave things as they are and revisit this issue in 5-10 years when we understand the actual problems we have then. [Predicting the future is an inexact science.] The policies will be able to change when the need arises in 5-10 years time too. You seem to be saying "Let's repeat all the mistakes everyone made with PI IPv4 space with IPv6. We can always fix that breakage by changing the policies later.". If so, doing the wrong thing now, even if well intentioned, could be storing up even bigger problems for later. I'm neither for or against 2011-02: just trying to better understand the rationale and motivation behind it. From Woeber at CC.UniVie.ac.at Tue Aug 9 20:51:47 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Aug 2011 18:51:47 +0000 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> Message-ID: <4E4181C3.2030307@CC.UniVie.ac.at> Hi Jim, without a direct replay to your last message, let me explain why I am in favour of 2011-02. Jim Reid wrote: [...] > I'm neither for or against 2011-02: just trying to better understand > the rationale and motivation behind it. I am in contact with organisations who want (or are pushed :-) ) to deploy IPv6. Some of them have a very credible reason to use PI addresses, although they do not configure dual-homing *for IPv6* for the very beginning. Still, using PA is a bad choice for them. Possible reactions to this have either been becoming an LIR (potentially a waste of address space, plus additional cost, but option has been selected), or to delay the introduction of IPv6 for the moment; has been done, too :-) Hth, Wilfried. From joao at bondis.org Tue Aug 9 22:35:30 2011 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Tue, 9 Aug 2011 22:35:30 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> Message-ID: <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> On 9 Aug 2011, at 18:25, Jim Reid wrote: Small intermission. > > Please explain Sascha. I just don't get it. IPv6 deployment isn't hindered by the availability of PI space. At least not in the general case. Can you give some actual examples where a problem getting PI IPv6 space has (or is) a showstopper for IPv6 deployment? There are people who clearly sustain the opposite so this is not a statement that has been without challenges which mostly seem to be grounded on the needs of enterprises. Particularly because they can get this in IPv4 and how do you sell anyone a technology that gives you "less" than the previous one? > >> This policy change is about NOTHING else than aligning the IPv6 PI policy with >> the IPv4 PI policy we have for ages. > > That's all very well. However it may be the answer to the wrong question. Suppose we didn't have IPv4 PI space at all. Would we invent this concept for IPv6? If so, why? If not, why not? > Problem is, Jim, we do have IPv4 PI, and people compare fruits. Joao From adriano at rybnet.pl Wed Aug 10 09:44:45 2011 From: adriano at rybnet.pl (Adrian Czapek) Date: Wed, 10 Aug 2011 09:44:45 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> Message-ID: <4E4236ED.50503@rybnet.pl> > > Please explain Sascha. I just don't get it. IPv6 deployment isn't > hindered by the availability of PI space. At least not in the general > case. Can you give some actual examples where a problem getting PI IPv6 > space has (or is) a showstopper for IPv6 deployment? > I have an example - hosting companies can't get PI IPv6, and they are forced to become LIRs in order to get one. Discussed proposal changes nothing for them, thus, you wanted an example where getting PI IPv6 space is stopping IPv6 deployment. > > Maybe, but why does someone need IPv6 PI space to start deploying IPv6? > Because someone don't want to, or need to, to become LIR and get their PA allocation (see example above). Regards -- Adrian From emadaio at ripe.net Wed Aug 10 10:35:35 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 10 Aug 2011 10:35:35 +0200 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <4E41029F.8010309@CC.UniVie.ac.at> References: <20110728103305.E8BA36A03C@postboy.ripe.net> <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> <4E41029F.8010309@CC.UniVie.ac.at> Message-ID: <4E4242D7.3040502@ripe.net> Dear Wilfried, Thank you for the question. On 8/9/11 11:49 AM, Wilfried Woeber, UniVie/ACOnet wrote: > [...] > Regarding the Impact Analysis: > > Is there any exisiting or proposed policy in our region that would be impacted > or even invalidated by this proposal becoming Global Policy? > No. The current Global Policy Proposal does not impact upon or invalidate any existing RIPE Policies or Policy Proposals. Best regards, Emilio Madaio Policy Development Officer RIPE NCC >> [...] From turchanyi.geza at gmail.com Wed Aug 10 11:00:15 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 10 Aug 2011 11:00:15 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> Message-ID: Hi, It is very easy to soften the rules, however, it is always difficult to keep them clear and sharp. Most of the IPv4 PI address space allocation comes from the pre-CIDR period of time. I am pretty sure that all the examples hinted by Wilfried are early allocations, may be even pre-RIPE allocations. On Tue, Aug 9, 2011 at 10:35 PM, Jo?o Damas wrote: > > On 9 Aug 2011, at 18:25, Jim Reid wrote: > > Small intermission. > > > > > Please explain Sascha. I just don't get it. IPv6 deployment isn't > hindered by the availability of PI space. At least not in the general case. > Can you give some actual examples where a problem getting PI IPv6 space has > (or is) a showstopper for IPv6 deployment? > > There are people who clearly sustain the opposite so this is not a > statement that has been without challenges which mostly seem to be grounded > on the needs of enterprises. Particularly because they can get this in IPv4 > and how do you sell anyone a technology that gives you "less" than the > previous one? > > > > >> This policy change is about NOTHING else than aligning the IPv6 PI > policy with > >> the IPv4 PI policy we have for ages. > > > > That's all very well. However it may be the answer to the wrong question. > Suppose we didn't have IPv4 PI space at all. Would we invent this concept > for IPv6? If so, why? If not, why not? > > > > Problem is, Jim, we do have IPv4 PI, and people compare fruits. > > Joao > The address akkocation liberty of the early Internet can not kept any more, because it does not scale!!! CIDR (and PA!) was introduced exactly to limit the growth of the routing table! The real problem for a hosting company is load balancing and not the Provider Aggregated IPv6 address space! Renumbering in IPv6 is not painless, however it can be done, even for a hosting company in case if it would be realy needed in the future... Thanks, Geza -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jasper.Jans at espritxb.nl Wed Aug 10 11:33:16 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Wed, 10 Aug 2011 11:33:16 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> | Most of the IPv4 PI address space allocation comes from the pre-CIDR period of time. I am pretty | sure that all the examples hinted by Wilfried are early allocations, may be even pre-RIPE allocations. If you are implying here that the amount of PI allocated these days vs what was allocated before makes it so that there is hardly any impact - then yea maybe.. i do not have the numbers to support this either way. However if this is supposed to imply that PI was mainly handed out in the old days and these days there are other (better??) options - then I have to disagree - there are obviously many valid reasons these days to still get IPv4 PI space under the rules that exist, and from my personal experience none of these allocations are made to organisations with an AS or dual homing today - hence these organisations can not get IPv6 PI to run dual-stack etc (that is what we all wanted right - run dual-stack while you still can and do not set yourself up for difficult transition setups?). To me it is very strange to have the next version of IP being incompatible from a policy perspective with the previous - this is a severe problem for at least our customers to move to IPv6. All of their reasons to run PI on IPv4 are just as valid on IPv6 however the dual-homing policy line prevents them from making the transition. I am all for learning from our mistakes - but we cannot deploy policy that excludes a group of people when it comes to IPv6 that already qualified for ipv4 PI. If we really have to do the dual-homing requirement (I'm of the opinion we don't) then at the very least make it so that the clause states that you need to be dual-homed for any new IPv6 PI, or must already own IPv4 PI. This way you can prevent people from getting it that do not have it yet but allow the ones that already run IPv4 PI to get IPv6 PI. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From turchanyi.geza at gmail.com Wed Aug 10 11:56:56 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 10 Aug 2011 11:56:56 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: Hi Jasper, On Wed, Aug 10, 2011 at 11:33 AM, Jasper Jans wrote: > I am all for learning from our mistakes - but we cannot deploy policy that > excludes a group of people > when it comes to IPv6 that already qualified for ipv4 PI. If we really have > to do the dual-homing > requirement (I'm of the opinion we don't) > then at the very least make it so that the clause states > that you need to be dual-homed for any new IPv6 PI, or must already own > IPv4 PI. This way you can > prevent people from getting it that do not have it yet but allow the ones > that already run IPv4 PI to > get IPv6 PI. > > Jasper > This is an argument what many people might support -- even me ;-) , --- but I would also add some review period to all PI allocations. Like this: The policy allowing Provider Independent allocation might be revoked later on and if it is revoked then ALL PI holder not fullfilling the new policy will be requested to return their PI address space and renumber to PA address space within 2 years. What do you think about this? Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From boggits at gmail.com Wed Aug 10 11:53:40 2011 From: boggits at gmail.com (boggits) Date: Wed, 10 Aug 2011 10:53:40 +0100 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: On 10 August 2011 10:33, Jasper Jans wrote: > I am all for learning from our mistakes - but we cannot deploy policy that excludes a group of people > when it comes to IPv6 that already qualified for ipv4 PI. If we really have to do the dual-homing > requirement (I'm of the opinion we don't) then at the very least make it so that the clause states > that you need to be dual-homed for any new IPv6 PI, or must already own IPv4 PI. This way you can > prevent people from getting it that do not have it yet but allow the ones that already run IPv4 PI to > get IPv6 PI. That would be an option, adding the requirement for Dual Homing or existing IPv4 PI would seem to solve the issue - it might even increase the number of v4 PI requests and speed depletion which some would see as a good thing. J -- James Blessing 07989 039 476 From Jasper.Jans at espritxb.nl Wed Aug 10 12:10:57 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Wed, 10 Aug 2011 12:10:57 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC1BD@EXCH01.campus.local> | This is an argument what many people might support -- even me ;-) , --- but I would also add some | review period to all PI allocations. Like this: | | The policy allowing Provider Independent allocation might be revoked later on and if it is revoked | then ALL PI holder not fullfilling the new policy will be requested to return their PI address space | and renumber to PA address space within 2 years. I understand where you are coming from - since this will over time bring PI assignments more and more in line with the new policy. I have two issues with this - up until this day the RIPE has always functioned on a basis of proof the requirement and get the allocation basis where once it was handed out it stayed this way. Putting in a review over X amount of time will change the way the RIPE operates in this respect. It also feels a bit like you can have it now - but only if you agree to dual home/get as/become lir within now and X amount of time - so in respect not changing the policy just giving people a grace period. The other issue is - how is the RIPE going to validate - both from a technical perspective as well as from an organisational perspective. This will take resources, costs money, etc. And on what grounds does the RIPE concluded you are still allowed to keep the PI space? You also get into the muddy waters here of having to retrieve an allocation - how is the RIPE going to enforce this? The way I see it we can do one of three things, not change the policy, change the policy to remove the dual homing requirement, or change the policy in such a way that we keep the dual homing but allow for alignment with the IPv4 policy of you already have an allocation. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From Woeber at CC.UniVie.ac.at Wed Aug 10 12:23:44 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 10 Aug 2011 10:23:44 +0000 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: <4E425C30.3090500@CC.UniVie.ac.at> Jasper Jans wrote: > | Most of the IPv4 PI address space allocation comes from the pre-CIDR period of time. Well, pre-CIDR (and pre-RIR times), the notion of "PI" is pretty fuzzy, because everything given out then was sort of PI, including Class A and Class B blocks. But I guess the general understanding here is to mean the 192/8 space. > I am pretty > | sure that all the examples hinted by Wilfried are early allocations, may be even > pre-RIPE allocations. > > If you are implying here that the amount of PI allocated these days vs what was allocated before makes > it so that there is hardly any impact Without wanting to imply anything, just providing us with real figures - iirc NCC Registration Services has given a very nice report recently (at 61 or 62? a recent NRO report?), listing the number of PI assignmenet vs the number of PA allocations, and the percentage of space given out for the 2 categories. Unfortunately, I cannot find this/those presentation/s on short notice right now. Maybe the NCC can help? Again, iirc, IPv4 PI is pretty attractive still in (some parts of) our Service Region; to my personal surprise even after implementation of 2007-01. I take that as quite some folks having pretty good reasons to request that type of addresses. Wilfried. > - then yea maybe.. i do not have the numbers to support this > either way. However if this is supposed to imply that PI was mainly handed out in the old days and > these days there are other (better??) options - then I have to disagree - there are obviously many > valid reasons these days to still get IPv4 PI space under the rules that exist, and from my personal > experience none of these allocations are made to organisations with an AS or dual homing today - hence > these organisations can not get IPv6 PI to run dual-stack etc (that is what we all wanted right - run > dual-stack while you still can and do not set yourself up for difficult transition setups?). > > To me it is very strange to have the next version of IP being incompatible from a policy perspective > with the previous - this is a severe problem for at least our customers to move to IPv6. All of their > reasons to run PI on IPv4 are just as valid on IPv6 however the dual-homing policy line prevents them > from making the transition. > > I am all for learning from our mistakes - but we cannot deploy policy that excludes a group of people > when it comes to IPv6 that already qualified for ipv4 PI. If we really have to do the dual-homing > requirement (I'm of the opinion we don't) then at the very least make it so that the clause states > that you need to be dual-homed for any new IPv6 PI, or must already own IPv4 PI. This way you can > prevent people from getting it that do not have it yet but allow the ones that already run IPv4 PI to > get IPv6 PI. > > Jasper > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer > > > From Jasper.Jans at espritxb.nl Wed Aug 10 12:24:15 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Wed, 10 Aug 2011 12:24:15 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC1D0@EXCH01.campus.local> | That would be an option, adding the requirement for Dual Homing or | existing IPv4 PI would seem to solve the issue - it might even | increase the number of v4 PI requests and speed depletion which some | would see as a good thing. Indeed - the backdoor into IPv6 PI is getting IPv4 PI. This is a limited time only kind of deal since IPv4 is nearly depleted so we know this change will not let too much new PI space slip in for people that not have it today, but will allow organisations to move forward with IPv6 deployments that have IPv4 PI today already. J. Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From Woeber at CC.UniVie.ac.at Wed Aug 10 12:34:26 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 10 Aug 2011 10:34:26 +0000 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: <4E425EB2.4080409@CC.UniVie.ac.at> Turchanyi Geza wrote: > Hi Jasper, [...] > The policy allowing Provider Independent allocation might be revoked later > on and if it is revoked then ALL PI holder not fullfilling the new policy > will be requested to return their PI address space and renumber to PA > address space within 2 years. > > What do you think about this? Maybe easy in some (tech-savvy playground) pockets of the net, but certainly not going to fly in some (many?) pretty stable and/or complex environments. One example: health services area. I'd even venture to say that it would actually be completely contrary to why many organisations opt(ed) for PI... > Thanks, > > G?za Wilfried PS: maybe slightly OT, but why was number portability introduced and has become quite popular in the telephone system? Renumbering a phone is "easy", isn't it ;-) From ebais at A2B-Internet.com Wed Aug 10 12:49:21 2011 From: ebais at A2B-Internet.com (Erik Bais) Date: Wed, 10 Aug 2011 12:49:21 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <4E4236ED.50503@rybnet.pl> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <4E4236ED.50503@rybnet.pl> Message-ID: <9A6C0115-F14F-45B6-8059-F2E38961915F@A2B-Internet.com> Hi Adrian, They can't get IPv6 PI for hosting business.. But would they to enable IPv6 for their own infrastructure ? If they wouldn't give addresses to other entities, they would still fit within the same rules as any other end-customer. Erik Verstuurd vanaf mijn iPad > From james.blessing at despres.co.uk Wed Aug 10 12:49:26 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 10 Aug 2011 11:49:26 +0100 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <4E425EB2.4080409@CC.UniVie.ac.at> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425EB2.4080409@CC.UniVie.ac.at> Message-ID: On 10 August 2011 11:34, Wilfried Woeber, UniVie/ACOnet wrote: > PS: maybe slightly OT, but why was number portability introduced and has become > ? ?quite popular in the telephone system? > ? ?Renumbering a phone is "easy", isn't it ;-) Yes, but there isn't a DNS for Phone Numbers (eNUM doesn't count as it encodes the number in DNS rather than the other way round) that maps addresses for you, if you could use their email address (or other suitable identifier of a person) to make phone calls then you'd be onto a winner and number portability wouldn't be required. Since with IPv6 you are unlikely to be using the IP addresses for anything in day to day use (unlike v4 where you still see lots of manual configuration) and there are explicit functions from an end device to use multiple IP addresses it makes sense to change end user configuration to an automated function. Doing this then makes transition between two blocks of address space (as long as they are the same size) simple (and transparent to the end user). This makes the most import thing that any LIR/RIR can do is to make sure that LIRs are handing blocks of address space out the same size... J -- James Blessing 07989 039 476 From ebais at A2B-Internet.com Wed Aug 10 12:55:56 2011 From: ebais at A2B-Internet.com (Erik Bais) Date: Wed, 10 Aug 2011 12:55:56 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC1D0@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC1D0@EXCH01.campus.local> Message-ID: Hi Jasper, Op Aug 10, 2011 om 12:24 heeft Jasper Jans het volgende geschreven: > | That would be an option, adding the requirement for Dual Homing or > | existing IPv4 PI would seem to solve the issue - it might even > | increase the number of v4 PI requests and speed depletion which some > | would see as a good thing. > > Indeed - the backdoor into IPv6 PI is getting IPv4 PI. This is a limited > time only kind of deal since IPv4 is nearly depleted so we know this > change will not let too much new PI space slip in for people that not > have it today, but will allow organisations to move forward with IPv6 > deployments that have IPv4 PI today already. > > J. > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer > As a LIR we had no requests from customers, could I get only IPv6 PI. IPv6 in all discussions came either later or not at all. Never the otherway around (yet). And by when that would be the case, IPv4 will most likely be depleted already .. Erik From jan at go6.si Wed Aug 10 12:55:16 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 10 Aug 2011 12:55:16 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC1D0@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC1D0@EXCH01.campus.local> Message-ID: <4E426394.2010201@go6.si> On 8/10/11 12:24 PM, Jasper Jans wrote: > | That would be an option, adding the requirement for Dual Homing or > | existing IPv4 PI would seem to solve the issue - it might even > | increase the number of v4 PI requests and speed depletion which some > | would see as a good thing. > > Indeed - the backdoor into IPv6 PI is getting IPv4 PI. This is a limited > time only kind of deal since IPv4 is nearly depleted so we know this > change will not let too much new PI space slip in for people that not > have it today, but will allow organisations to move forward with IPv6 > deployments that have IPv4 PI today already. This is getting complicated. Why bonding IPv4 policy to IPv6 policy? Independent Resources costs money - X EUR/Year. If you are multihomed, IPv6 PI space would cost X EUR/Year If you are not multihomed, IPv6 PI space would automatically cost X x 2 EUR/Year. Now suit yourself and make a decision, what's gonna be. This would probably fix all the fears expressed here in this thread. And in my opinion independent resources are too cheap, but that's just my view and out of scope of this discussion. Cheers, Jan From marcin at leon.pl Wed Aug 10 12:53:00 2011 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 10 Aug 2011 12:53:00 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <9A6C0115-F14F-45B6-8059-F2E38961915F@A2B-Internet.com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <4E4236ED.50503@rybnet.pl> <9A6C0115-F14F-45B6-8059-F2E38961915F@A2B-Internet.com> Message-ID: <4E42630C.5010104@leon.pl> Erik Bais wrote: > Hi Adrian, > > They can't get IPv6 PI for hosting business.. But would they to enable IPv6 for their own infrastructure ? If they wouldn't give addresses to other entities, they would still fit within the same rules as any other end-customer. yeap, and recently such cases were sent to "hell" with the reason "IPv6 PI is only available with direct agreement Customer-RIPE" Regards, Marcin From sm+afrinic at elandsys.com Wed Aug 10 12:45:03 2011 From: sm+afrinic at elandsys.com (S Moonesamy) Date: Wed, 10 Aug 2011 03:45:03 -0700 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <4E41029F.8010309@CC.UniVie.ac.at> References: <20110728103305.E8BA36A03C@postboy.ripe.net> <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> <4E41029F.8010309@CC.UniVie.ac.at> Message-ID: <6.2.5.6.2.20110810031443.0b36b5d8@resistor.net> Hi Wilfried, At 02:49 09-08-2011, Wilfried Woeber, UniVie/ACOnet wrote: >Checking the text again, I do see some aspects that may be ambiguous and/or >require clarification: Please note that the status of GPP-IPv4-2011 in other regions is as follows: AfriNIC: In Last Call APNIC: Endorsed by APNIC EC ARIN: To be discussed at its next Public Policy Meeting LACNIC: In last comments period >Section 1.0, after bullet point 2, > >The Recovered IPv4 Pool will stay inactive until the first RIR has less than >a total of a /9 in its inventory of IPv4 address space. > > >As the different regions do have, or are still discussing, various >(micro-)policies >to reserve blocks or to set aside blocks for specific purposes, the >term "inventory" >either needs clarification/definition or there should be an explanation which >part(s) of the RIR's IPv4 address space is considered to belong to >the "inventory". > >My personal proposal would be to clearly state that *all* currently >unused space >in an RIR is considered its "inventory". The intent is to cover IPv4 address space that is not allocated or assigned, including any address blocks that have been set aside for specific purposes. >As an aside, and given the fact that there is no specification about >the fate of >returned address blocks within a Region, what is expected to happen, >when and if >no RIR is below the /9 threshold any longer? Will the RIP (Recovered >IPv4 Pool :-) ) >be declared inactive again, or not? I do understand that this is not >very likely. The objective is to keep the proposal simple. As such, unlikely events are not taken into account. >Regarding timelines: > >It is not clear to me, whether the 1st round of redistribution >happens "immediately" >after declaring the RIP active, and thereafter will be synched to >the March1/Sept1 >schedule? Alternatively, the 1st round may be executed at the next >scheduled date. > >My personal preference here would be to act "immediately" and then take up the >schedule, with the effect of potentially not having anything to dish >out for the >next round(s) and thus skip the next scheduled date(s) . > >However, this approach may run against the intention(?) of proposing >a fixed 6m >schedule (in order to accumulate a reasonably big RIP?). There is a fixed six month schedule. >Maybe the authors could explain the rationale for the particular schedule? That particular schedule was proposed and nobody objected to it. Regards, S. Moonesamy From mohta at necom830.hpcl.titech.ac.jp Wed Aug 10 13:46:47 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 10 Aug 2011 20:46:47 +0900 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425EB2.4080409@CC.UniVie.ac.at> Message-ID: <4E426FA7.3020601@necom830.hpcl.titech.ac.jp> James Blessing wrote: > Since with IPv6 you are unlikely to be using the IP addresses for > anything in day to day use (unlike v4 where you still see lots of > manual configuration) The reality is that stateless auto configuration is not really stateless and no better than DHCP. > and there are explicit functions from an end > device to use multiple IP addresses it makes sense to change end user > configuration to an automated function. As is proven by hosts with an IPv4 and an IPv6 addresses, IPv6 does not support hosts with multiple addresses better than IPv4. Masataka Ohta From joao at bondis.org Thu Aug 11 11:57:02 2011 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Thu, 11 Aug 2011 11:57:02 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> Message-ID: On 10 Aug 2011, at 11:33, Jasper Jans wrote: > If we really have to do the dual-homing > requirement (I'm of the opinion we don't) then at the very least make it so that the clause states > that you need to be dual-homed for any new IPv6 PI, or must already own IPv4 PI. This way you can > prevent people from getting it that do not have it yet but allow the ones that already run IPv4 PI to > get IPv6 PI. I would be wary of policies that provide advantages to incumbents (people who already have IPv4 or can get it in the next few months) over newcomers. IP networks used to be on the newcomers side and I kindly request those who remember to remind themselves what they thought of the incumbents (not to mention what other parties in charge of "fairness" might think) Joao From Remco.vanMook at eu.equinix.com Thu Aug 11 15:36:18 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 11 Aug 2011 14:36:18 +0100 Subject: [address-policy-wg] 2011-03 New Draft Document Published (Post-depletion IPv4 address recycling) In-Reply-To: Message-ID: Hi James, (just doing some cleanup here) I don't think there's going to be a clash between this and a special resources for IXes proposal (although it's hard to be sure since it hasn't been published yet :) I would suggest that if a proposal to that extent is going to be put forward, it will be done quickly, and keeps the final /8 pool in mind. This proposal merely clarifies which space belongs in that pool. Best, Remco van Mook Director of Interconnection, Europe remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 13-07-11 10:40, "boggits" wrote: >On 13 July 2011 09:34, Emilio Madaio wrote: >> The draft document for the proposal described in 2011-03 has been >> published. The Impact Analysis that was conducted for this proposal >> has also been published. > >I support this proposal with no changes, the only caveat is whether >the special resources for IXs proposal and this clash and there should >be some mention of this... > >J > >-- > >James Blessing >07989 039 476 > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From emadaio at ripe.net Thu Aug 11 16:06:57 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 11 Aug 2011 16:06:57 +0200 Subject: [address-policy-wg] 2011-03 Last Call for Comments (Post-depletion IPv4 address recycling) Message-ID: <20110811140658.C616F6A004@postboy.ripe.net> Dear Colleagues, The proposal described in 2011-03 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-03 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 8 September 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Fri Aug 12 16:17:52 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 12 Aug 2011 16:17:52 +0200 Subject: [address-policy-wg] 2010-01 Proposal Accepted (Temporary Internet Number Assignment Policies) Message-ID: <20110812141752.6FAD76A007@postboy.ripe.net> Dear Colleagues, Consensus has been reached, and the proposal described in 2010-01 has been accepted by the RIPE community. The new policy "Temporary Internet Number Assignment Policies" is available at: https://www.ripe.net/ripe/docs/ripe-526 The updated policies "IPv6 Address Allocation and Assignment Policy", "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" and "Autonomous System (AS) Number Assignment Policies" are available respectively at: https://www.ripe.net/ripe/docs/ripe-523 https://www.ripe.net/ripe/docs/ripe-524 https://www.ripe.net/ripe/docs/ripe-525 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-01 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From aservin at lacnic.net Sat Aug 13 07:01:14 2011 From: aservin at lacnic.net (Arturo Servin) Date: Sat, 13 Aug 2011 00:01:14 -0500 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <6.2.5.6.2.20110810031443.0b36b5d8@resistor.net> References: <20110728103305.E8BA36A03C@postboy.ripe.net> <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> <4E41029F.8010309@CC.UniVie.ac.at> <6.2.5.6.2.20110810031443.0b36b5d8@resistor.net> Message-ID: <68805D33-6981-4C6D-9DB0-FCDCF3E672D6@lacnic.net> On 10 Aug 2011, at 05:45, S Moonesamy wrote: > Hi Wilfried, > At 02:49 09-08-2011, Wilfried Woeber, UniVie/ACOnet wrote: >> Checking the text again, I do see some aspects that may be ambiguous and/or >> require clarification: > > Please note that the status of GPP-IPv4-2011 in other regions is as follows: > > AfriNIC: In Last Call > APNIC: Endorsed by APNIC EC > ARIN: To be discussed at its next Public Policy Meeting > LACNIC: In last comments period Correction. In LACNIC has been ratified by the Board (19/7/2011) Regards, -as -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexlh at ripe.net Wed Aug 17 15:01:03 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 17 Aug 2011 15:01:03 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <4E425C30.3090500@CC.UniVie.ac.at> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> Message-ID: Dear Wilfried, On Aug 10, 2011, at 12:23, Wilfried Woeber, UniVie/ACOnet wrote: > Without wanting to imply anything, just providing us with real figures - > > iirc NCC Registration Services has given a very nice report recently (at 61 > or 62? a recent NRO report?), listing the number of PI assignmenet vs the number > of PA allocations, and the percentage of space given out for the 2 categories. > > Unfortunately, I cannot find this/those presentation/s on short notice right now. > Maybe the NCC can help? At RIPE62 I presented the following: http://ripe62.ripe.net/presentations/209-apwg.pdf (PI section starts at slide 9, numbers from 25 onwards) Adding the IPv4 PI vs the IPv4 ALLOCATED blocks the RIPE NCC has on file at the moment, we see that 3.5% of all IPv4 IPs handed out were assigned/allocated as PI. Best regards, Alex Le Heux From turchanyi.geza at gmail.com Wed Aug 17 19:41:30 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 17 Aug 2011 19:41:30 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> Message-ID: Hi Alex, May I interpret your slide29 in this way: 3,5% off the address space had been allocated as PI in the RIPE NCC service region and this PI address space is responsible for 21% of the BGP prefixes (originated in this region). So 3,5% AND 21%.... In IPv6 PI this ratio probably will be even worse... Best, G?za On Wed, Aug 17, 2011 at 3:01 PM, Alex Le Heux wrote: > Dear Wilfried, > > On Aug 10, 2011, at 12:23, Wilfried Woeber, UniVie/ACOnet wrote: > > > Without wanting to imply anything, just providing us with real figures - > > > > iirc NCC Registration Services has given a very nice report recently (at > 61 > > or 62? a recent NRO report?), listing the number of PI assignmenet vs the > number > > of PA allocations, and the percentage of space given out for the 2 > categories. > > > > Unfortunately, I cannot find this/those presentation/s on short notice > right now. > > Maybe the NCC can help? > > At RIPE62 I presented the following: > > http://ripe62.ripe.net/presentations/209-apwg.pdf > (PI section starts at slide 9, numbers from 25 onwards) > > Adding the IPv4 PI vs the IPv4 ALLOCATED blocks the RIPE NCC has on file at > the moment, we see that 3.5% of all IPv4 IPs handed out were > assigned/allocated as PI. > > Best regards, > > Alex Le Heux > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From millnert at gmail.com Thu Aug 18 15:43:09 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 18 Aug 2011 15:43:09 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> Message-ID: Turchani, On Wed, Aug 17, 2011 at 7:41 PM, Turchanyi Geza wrote: > Hi Alex, > > May I interpret your slide29 in this way: > > 3,5% off the address space had been allocated as PI in the RIPE NCC service > region and this PI address space is responsible for 21% of the BGP prefixes > (originated in this region). > > So 3,5% AND 21%.... > > In IPv6 PI this ratio probably will be even worse... But is that ratio actually such a useful metric for IPv6? I think you overlooked page 30, which IMO is much more useful: 15417 PA allocations => 59126 prefixes in the DFZ, a ratio of 3.8. 16340 PI assignments => 17468 prefizes in the DFZ, a ratio of 1.1. Add to this that many operators have multiple assignments in IPv4, which I must say has to be much less likely to happen in IPv6 than it is in IPv4. I believe there's already been research done to try and determine how they would perform if they had a single assignment large enough for their entire network, e.g. how much is TE, poor design or just simply due to having had to return to RIR iteratively over the years to get more space. If not, someone should look into that. :) Best Regards, Martin From turchanyi.geza at gmail.com Thu Aug 18 23:42:44 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Thu, 18 Aug 2011 23:42:44 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> Message-ID: Hi Martin, These numbers give me a different interpretation: On Thu, Aug 18, 2011 at 3:43 PM, Martin Millnert wrote: > Turchani, > > On Wed, Aug 17, 2011 at 7:41 PM, Turchanyi Geza > wrote: > > Hi Alex, > > > > May I interpret your slide29 in this way: > > > > 3,5% off the address space had been allocated as PI in the RIPE NCC > service > > region and this PI address space is responsible for 21% of the BGP > prefixes > > (originated in this region). > > > > So 3,5% AND 21%.... > > > > In IPv6 PI this ratio probably will be even worse... > > But is that ratio actually such a useful metric for IPv6? > > I think you overlooked page 30, which IMO is much more useful: > 15417 PA allocations => 59126 prefixes in the DFZ, a ratio of 3.8. > 16340 PI assignments => 17468 prefizes in the DFZ, a ratio of 1.1. > PI address space creates very scattered allocation as 16340 PI assignments just covers 3,5% of the RIPE allocated address space. This is the point, is n't it? BTW, the 3,5% is not mentionned on the slides... but it was included in the letter of Alex. Second point: if ALL IPv4 PI holder would request IPv6 PI then you might expect another 17K prefixes in the routing table just from the RIPE Region! And this is just the start! Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From undefine at aramin.net Thu Aug 18 23:59:28 2011 From: undefine at aramin.net (=?UTF-8?B?QW5kcnplaiBEb3BpZXJhxYJh?=) Date: Thu, 18 Aug 2011 23:59:28 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> Message-ID: <4E4D8B40.4030409@aramin.net> W dniu 18.08.2011 23:42, Turchanyi Geza pisze: > Second point: if ALL IPv4 PI holder would request IPv6 PI then you > might expect another 17K prefixes in the routing table just from the > RIPE Region! And this is just the start! Most ipv4 PI holders have more than one prefix - when first was not enought - they get another. Few ISP in poland get 3-4 prefixes when they weren't LIR. For ipv6 one prefix is always enought - so 17k is much to much :) Regards, Andrzej From turchanyi.geza at gmail.com Fri Aug 19 05:41:26 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 19 Aug 2011 05:41:26 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <4E4D8B40.4030409@aramin.net> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> <4E4D8B40.4030409@aramin.net> Message-ID: Hello Andrzej, Good point. You said that some ISPs are using IPv4 PI address space just because they asked it in their very small ISP status, as being pre-LIR. It would have been much better to change back these addresses to PA already long time. Is there anybody who can suggest a cleaning policy? Of course, vleaning is very difficult whan almost all IPv4 address space have gone... ;-(( Anyhow, the danger og creating too many routing table entries by allocating Provider Independent (IPv6) addresses is still exist and should not be overlooked. Best, G?za 2011/8/18 Andrzej Dopiera?a > W dniu 18.08.2011 23:42, Turchanyi Geza pisze: > > Second point: if ALL IPv4 PI holder would request IPv6 PI then you might >> expect another 17K prefixes in the routing table just from the RIPE Region! >> And this is just the start! >> > Most ipv4 PI holders have more than one prefix - when first was not enought > - they get another. Few ISP in poland get 3-4 prefixes when they weren't > LIR. > > For ipv6 one prefix is always enought - so 17k is much to much :) > > Regards, > > Andrzej > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Fri Aug 19 11:06:35 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 19 Aug 2011 11:06:35 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> <4E4D8B40.4030409@aramin.net> Message-ID: <006901cc5e4f$4c793160$e56b9420$@com> Hi Andrzej & Turchanyi, That is a difference in that respect between IPv4 and IPv6. End-customers that request IPv4 PI might find themselves after a while in a situation where the initial request allocation isn't big enough and they can and will request another prefix. For IPv6 that isn't likely and I've heard that some people are a bit concerned about this. One of the things we might want to put into the IPv6 PI limitations is that an end-customer can only request a single IPv6 PI Prefix and to a maximum of a certain size. ( say a /34 ) Anything beyond that should be considered LIR sized and the end-customer should become a LIR and turn in their PI prefix. Regards, Erik Bais From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Turchanyi Geza Sent: Friday, August 19, 2011 5:41 AM To: Andrzej Dopiera?a Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PI for IPv6 == PI for IPv4? Hello Andrzej, Good point. You said that some ISPs are using IPv4 PI address space just because they asked it in their very small ISP status, as being pre-LIR. It would have been much better to change back these addresses to PA already long time. Is there anybody who can suggest a cleaning policy? Of course, vleaning is very difficult whan almost all IPv4 address space have gone... ;-(( Anyhow, the danger og creating too many routing table entries by allocating Provider Independent (IPv6) addresses is still exist and should not be overlooked. Best, G?za 2011/8/18 Andrzej Dopiera?a W dniu 18.08.2011 23:42, Turchanyi Geza pisze: Second point: if ALL IPv4 PI holder would request IPv6 PI then you might expect another 17K prefixes in the routing table just from the RIPE Region! And this is just the start! Most ipv4 PI holders have more than one prefix - when first was not enought - they get another. Few ISP in poland get 3-4 prefixes when they weren't LIR. For ipv6 one prefix is always enought - so 17k is much to much :) Regards, Andrzej _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3843 - Release Date: 08/18/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From turchanyi.geza at gmail.com Fri Aug 19 15:05:40 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 19 Aug 2011 15:05:40 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: <006901cc5e4f$4c793160$e56b9420$@com> References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> <4E4D8B40.4030409@aramin.net> <006901cc5e4f$4c793160$e56b9420$@com> Message-ID: Hi Erik, 2011/8/19 Erik Bais > Hi Andrzej & Turchanyi, **** > > ** ** > > That is a difference in that respect between IPv4 and IPv6. **** > > ** ** > > End-customers that request IPv4 PI might find themselves after a while in a > situation where the initial request allocation isn't big enough and they can > and will request another prefix. > It would have been better and still would be better even in that case to use only one prefix and return the original one to the RIR. > **** > > ** ** > > For IPv6 that isn't likely and I've heard that some people are a bit > concerned about this. **** > > ** ** > > One of the things we might want to put into the IPv6 PI limitations is that > an end-customer can only request a single IPv6 PI Prefix and to a maximum of > a certain size. ( say a /34 ) > The example (/34) given is very fare from that I would support. If an end user needmore than a /48 the and user should provide very detailed plan of its network. (For a home network /60 tipically more than enough). Any organization that might need a /40 (or more) AND PI address space, should become a LIR and contribute in the normal way to the internet address administration costs, I think. **** > > Anything beyond that should be considered LIR sized and the end-customer > should become a LIR and turn in their PI prefix. **** > > ** ** > > Regards,**** > > Erik Bais**** > > ** ** > > *From:* address-policy-wg-admin at ripe.net [mailto: > address-policy-wg-admin at ripe.net] *On Behalf Of *Turchanyi Geza > *Sent:* Friday, August 19, 2011 5:41 AM > *To:* Andrzej Dopiera?a > *Cc:* address-policy-wg at ripe.net > *Subject:* Re: [address-policy-wg] PI for IPv6 == PI for IPv4?**** > > ** ** > > Hello Andrzej, > > Good point. You said that some ISPs are using IPv4 PI address space just > because they asked it in their very small ISP status, as being pre-LIR. > > It would have been much better to change back these addresses to PA already > long time. > > Is there anybody who can suggest a cleaning policy? Of course, vleaning is > very difficult whan almost all IPv4 address space have gone... ;-(( > > Anyhow, the danger og creating too many routing table entries by allocating > Provider Independent (IPv6) addresses is still exist and should not be > overlooked. > > Best, > > G?za > > **** > > 2011/8/18 Andrzej Dopiera?a **** > > W dniu 18.08.2011 23:42, Turchanyi Geza pisze:**** > > ** ** > > Second point: if ALL IPv4 PI holder would request IPv6 PI then you might > expect another 17K prefixes in the routing table just from the RIPE Region! > And this is just the start!**** > > Most ipv4 PI holders have more than one prefix - when first was not enought > - they get another. Few ISP in poland get 3-4 prefixes when they weren't > LIR. > > For ipv6 one prefix is always enought - so 17k is much to much :) > > Regards, > > Andrzej > > **** > > ** ** > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1392 / Virus Database: 1520/3843 - Release Date: 08/18/11*** > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From undefine at aramin.net Fri Aug 19 23:46:51 2011 From: undefine at aramin.net (=?ISO-8859-2?Q?Andrzej_Dopiera=B3a?=) Date: Fri, 19 Aug 2011 23:46:51 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> <4E4D8B40.4030409@aramin.net> <006901cc5e4f$4c793160$e56b9420$@com> Message-ID: <4E4ED9CB.1060903@aramin.net> W dniu 19.08.2011 15:05, Turchanyi Geza pisze: > Hi Erik, > > 2011/8/19 Erik Bais > > > Hi Andrzej & Turchanyi, > > That is a difference in that respect between IPv4 and IPv6. > > End-customers that request IPv4 PI might find themselves after a > while in a situation where the initial request allocation isn't > big enough and they can and will request another prefix. > > > It would have been better and still would be better even in that case > to use only one prefix and return the original one to the RIR. It's not always so simple. When we have dns servers hardcoded in thousands machines, or when we have hosting where clients puts their domains (and we have no control on client's domains) - return any ip class is not easy. On ipv6 - there is problem with renumbering too - but there is no need to get another class - we have just one class which is big enough to end of our life ;) Regards, Andrzej -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.schallar at avalon.at Fri Aug 26 09:20:53 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Fri, 26 Aug 2011 09:20:53 +0200 Subject: [address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E2FF96A.2000802@avalon.at> References: <4E2FF96A.2000802@avalon.at> Message-ID: <4E574955.2040505@avalon.at> Hello! I'm back with the same question I made a month ago: what ist the current status on the multihomed v6 PI topic? The "current" phase on the proposal ended three days ago (August 23rd) and the status is "Awaiting Decision from Working Group Chair". http://www.ripe.net/ripe/policies/proposals/2011-02 What now? regards, Thomas DI. Thomas Schallar wrote 2011-07-27.07 01:41 pm: > Hello! > > What ist the current status on the multihomed v6 PI topic? > > regards, > Thomas From marcoh at marcoh.net Fri Aug 26 10:18:36 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 26 Aug 2011 10:18:36 +0200 Subject: [address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E574955.2040505@avalon.at> References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> Message-ID: On Aug 26, 2011, at 9:20 AM, DI. Thomas Schallar wrote: > Hello! > > I'm back with the same question I made a month ago: what ist the current status on the multihomed v6 PI topic? The "current" phase on the proposal ended three days ago (August 23rd) and the status is "Awaiting Decision from Working Group Chair". > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > What now? > > regards, > Thomas The current state is what it says, it is awaiting a decision from the WG chair(s) together with the proposer on how to move forward. This decision is based on the feedback received on the mailing list during the last round. Usually this can go two ways: - There is rough consensus on the proposal and the suggested text, which will mean the proposal can move to last call - People have suggested changes which need to be included or there seem to be a need for further discussion, in which case the current period will be extended or revised documents will be published together with a new call for feedback More information on the Policy Development Process, including all the phases can be found at http://www.ripe.net/ripe/policies/policy-development-process-glossary and is described in document ripe-500 which can be found in the document store at http://www.ripe.net/ripe/docs/ripe-500 Regards, Marco From pfsinoz at gmail.com Wed Aug 31 09:51:20 2011 From: pfsinoz at gmail.com (Philip Smith) Date: Wed, 31 Aug 2011 17:51:20 +1000 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) In-Reply-To: <4E41029F.8010309@CC.UniVie.ac.at> References: <20110728103305.E8BA36A03C@postboy.ripe.net> <2A638669-D632-41F6-BB0F-B7E09C4062F8@bondis.org> <4E41029F.8010309@CC.UniVie.ac.at> Message-ID: <4E5DE7F8.7090608@gmail.com> Hi Wilfried, Sorry for not responding to this sooner, job transition and time off work didn't help... Wilfried Woeber, UniVie/ACOnet said the following on 9/08/11 19:49 : > > I agree, and thus I support the proposed policy. Thank you! :-) > Checking the text again, I do see some aspects that may be ambiguous and/or > require clarification: > > Section 1.0, after bullet point 2, > > The Recovered IPv4 Pool will stay inactive until the first RIR has less than > a total of a /9 in its inventory of IPv4 address space. > > > As the different regions do have, or are still discussing, various (micro-)policies > to reserve blocks or to set aside blocks for specific purposes, the term "inventory" > either needs clarification/definition or there should be an explanation which > part(s) of the RIR's IPv4 address space is considered to belong to the "inventory". > > My personal proposal would be to clearly state that *all* currently unused space > in an RIR is considered its "inventory". The authors intention was that all currently *unused* space would be considered to be the RIR's inventory. > As an aside, and given the fact that there is no specification about the fate of > returned address blocks within a Region, what is expected to happen, when and if > no RIR is below the /9 threshold any longer? Will the RIP (Recovered IPv4 Pool :-) ) > be declared inactive again, or not? I do understand that this is not very likely. The intention of the authors was that this policy remains until replaced by another policy. Otherwise we'd have written that this policy would no longer apply once no RIR was below the /9 threshold again. > Regarding timelines: > > It is not clear to me, whether the 1st round of redistribution happens "immediately" > after declaring the RIP active, and thereafter will be synched to the March1/Sept1 > schedule? Alternatively, the 1st round may be executed at the next scheduled date. > > My personal preference here would be to act "immediately" and then take up the > schedule, with the effect of potentially not having anything to dish out for the > next round(s) and thus skip the next scheduled date(s) . > > However, this approach may run against the intention(?) of proposing a fixed 6m > schedule (in order to accumulate a reasonably big RIP?). > > Maybe the authors could explain the rationale for the particular schedule? We picked two months of the year, and March/Sept seemed reasonable in that they avoided calendar anniversaries and some major holiday seasons. Hope this helps! philip -- From undefine at aramin.net Fri Aug 19 23:46:51 2011 From: undefine at aramin.net (=?ISO-8859-2?Q?Andrzej_Dopiera=B3a?=) Date: Fri, 19 Aug 2011 23:46:51 +0200 Subject: [address-policy-wg] PI for IPv6 == PI for IPv4? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <008101cc4c5b$10403500$30c09f00$@com> <003401cc5425$9af655e0$d0e301a0$@com> <35F167AF-FD44-4E48-8141-92145F132F70@baycix.de> <2378FEDE-737F-4BFC-AB1C-67CCD5046B3D@rfc1035.com> <3E8012E1-F97C-4D92-9008-D3889732E4F8@bondis.org> <55557D0EBE9495428BFE94EF8BC5EBD201039FFDC179@EXCH01.campus.local> <4E425C30.3090500@CC.UniVie.ac.at> <4E4D8B40.4030409@aramin.net> <006901cc5e4f$4c793160$e56b9420$@com> Message-ID: <4E4ED9CB.1060903@aramin.net> W dniu 19.08.2011 15:05, Turchanyi Geza pisze: > Hi Erik, > > 2011/8/19 Erik Bais > > > Hi Andrzej & Turchanyi, > > That is a difference in that respect between IPv4 and IPv6. > > End-customers that request IPv4 PI might find themselves after a > while in a situation where the initial request allocation isn't > big enough and they can and will request another prefix. > > > It would have been better and still would be better even in that case > to use only one prefix and return the original one to the RIR. It's not always so simple. When we have dns servers hardcoded in thousands machines, or when we have hosting where clients puts their domains (and we have no control on client's domains) - return any ip class is not easy. On ipv6 - there is problem with renumbering too - but there is no need to get another class - we have just one class which is big enough to end of our life ;) Regards, Andrzej -------------- next part -------------- An HTML attachment was scrubbed... URL: