From andy at nosignal.org Wed Jun 1 14:16:39 2016 From: andy at nosignal.org (Andy Davidson) Date: Wed, 1 Jun 2016 12:16:39 +0000 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <573B161D.3090908@foobar.org> References: <573B0906.3060708@ripe.net> <573B161D.3090908@foobar.org> Message-ID: <2214977D-2B6B-45CA-B9FD-B55635447EE4@nosignal.org> Hi, I?m late to the party but I note that according to the RIPE NCC website, the good Mr. van Mook has not yet been kind enough to revoke the policy proposal yet, so allow me to say... On 17/05/2016, 14:01, "address-policy-wg on behalf of Nick Hilliard" wrote: >Specifically, it will not deal with the problem that the RIPE NCC was >set up to do, namely to ensure accurate registration of resources. .. that I agree with Nick's sentence, and object to the proposal. Whilst I understand the motive (and it?s a bloody good troll), I specifically object to a proposal which might ask or require an LIR to return in-use resources, which were previously correctly and in good faith, assigned in accordance with policy and procedures. Andy From mschmidt at ripe.net Thu Jun 2 15:37:21 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 02 Jun 2016 15:37:21 +0200 Subject: [address-policy-wg] 2015-05 Policy Proposal Withdrawn (Last /8 Allocation Criteria Revision) Message-ID: Dear colleagues, The proposal 2015-05, "Last /8 Allocation Criteria Revision" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposers decided to withdraw the proposal due to the inability to find an acceptable agreement which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From rgori at wirem.net Thu Jun 2 16:21:44 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 2 Jun 2016 16:21:44 +0200 Subject: [address-policy-wg] 2015-05 Policy Proposal Withdrawn (Last /8 Allocation Criteria Revision) In-Reply-To: References: Message-ID: Dear AP WG list, as Marco reported we decided to withdraw the 2015-05 policy proposal. Summary: This proposal aimed to lower competitive disadvantage of new LIRs allowing the request of an additional IPv4 /22 every 18 months if they meet some requirements: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8. - Only LIRs with less than a /20 in total are eligible to receive additional allocations. - LIRs must document their IPv6 deployment as part of the request. Same solution aimed to address and fix some legitimate but "wasting space" behavior of end-customers signing up as LIR to obtain space that their new small LIRs cannot supply. 2015-05, "Last /8 Allocation Criteria Revision" has been withdrawn due to the inability to find an acceptable agreement which satisfied all parties. kind regards Riccardo Il 02/06/2016 15:37, Marco Schmidt ha scritto: > Dear colleagues, > > > The proposal 2015-05, "Last /8 Allocation Criteria Revision" has been withdrawn. > > It is now archived and can be found at: > > https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ > > > Reason for withdrawal: > > The proposers decided to withdraw the proposal due to the inability to find an acceptable agreement which satisfied all parties. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Mon Jun 6 23:09:20 2016 From: rgori at wirem.net (Riccardo Gori) Date: Mon, 6 Jun 2016 23:09:20 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) Message-ID: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> Hi, although I understand the spirit of this policy in my opinion there's a big problem behind it: seems that has been thought for reasoucers not in use. I really don't get how a space can be de-registered once announced and in use and after have been allocated under regular procedures and business processes. A new entrant would see his investments vanified by a rule that make possibile transferts possbile only for old LIRs that acquired space before 09/2012. I think this really creates barrier to ingress in the market. If a return policy has to be proposed this should address the whole IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and not in use. Anyway we all know that's quite impossible. To address the problem of abuse RIPE NCC should enforce audit and check if the LIR "make assignement(s)" as stated in the policy. This could be a way to get rid of buy/sell just for speculation. I cannot support this policy regards Riccardo -- Ing. Riccardo Gori e-mail:rgori at wirem.net WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying toinfo at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: From gforgx at fotontel.ru Mon Jun 6 23:12:24 2016 From: gforgx at fotontel.ru (Sergey) Date: Tue, 7 Jun 2016 00:12:24 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> Message-ID: <5755E738.1060700@fotontel.ru> Completely agree with Riccardo on this. I've addressed this question via IRC during GM, why the strict audit is not possible - and got a response that it's against policy. Google has supported this concern. If there is problem with policy, the policy should be changed, not workarounds against the policy added. On 06/07/16 00:09, Riccardo Gori wrote: > > Hi, > > although I understand the spirit of this policy in my opinion there's > a big problem behind it: seems that has been thought for reasoucers > not in use. > I really don't get how a space can be de-registered once announced and > in use and after have been allocated under regular procedures and > business processes. > > A new entrant would see his investments vanified by a rule that make > possibile transferts possbile only for old LIRs that acquired space > before 09/2012. > I think this really creates barrier to ingress in the market. > > If a return policy has to be proposed this should address the whole > IPv4 RIPE Region space to be fair and catch where IPs are stockpiled > and not in use. > Anyway we all know that's quite impossible. > > To address the problem of abuse RIPE NCC should enforce audit and > check if the LIR "make assignement(s)" as stated in the policy. > This could be a way to get rid of buy/sell just for speculation. > > I cannot support this policy > > regards > Riccardo > > -- > Ing. Riccardo Gori > e-mail:rgori at wirem.net > > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying toinfo at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- -- Kind regards, CTO at *Foton Telecom CJSC* Tel.: +7 (499) 679-99-99 nic-hdl: SS29286-RIPE AS42861 on PeeringDB , Qrator , BGP.HE.NET /"Amazing photons Carry our data worldwide Never seem to stop" (c) JUNOS/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: From aleksbulgakov at gmail.com Mon Jun 6 23:54:04 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Tue, 7 Jun 2016 00:54:04 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <5755E738.1060700@fotontel.ru> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> Message-ID: Hi. Why are we talking about 185./8 only? There are many unused allocations bigger than /8 but the NCC doesn't want to pay attention to them. E.g. If the LIR has the allocation 31./12 (this is for example only, I didn't check what RIR has 31./8 network) and didn't use it during 5 years (or other period) he should return it to the NCC pool or a part of it. There is 2015-01, that prevents speculations. And I don't see any reasons to implement 2016-03. "Sergey" wrote: > > Completely agree with Riccardo on this. > > I've addressed this question via IRC during GM, why the strict audit is not possible - and got a response that it's against policy. Google has supported this concern. > > If there is problem with policy, the policy should be changed, not workarounds against the policy added. > > > On 06/07/16 00:09, Riccardo Gori wrote: >> >> Hi, >> >> although I understand the spirit of this policy in my opinion there's a big problem behind it: seems that has been thought for reasoucers not in use. >> I really don't get how a space can be de-registered once announced and in use and after have been allocated under regular procedures and business processes. >> >> A new entrant would see his investments vanified by a rule that make possibile transferts possbile only for old LIRs that acquired space before 09/2012. >> I think this really creates barrier to ingress in the market. >> >> If a return policy has to be proposed this should address the whole IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and not in use. >> Anyway we all know that's quite impossible. >> >> To address the problem of abuse RIPE NCC should enforce audit and check if the LIR "make assignement(s)" as stated in the policy. >> This could be a way to get rid of buy/sell just for speculation. >> >> I cannot support this policy >> >> regards >> Riccardo >> >> -- >> >> Ing. Riccardo Gori >> e-mail: rgori at wirem.net >> >> WIREM Fiber Revolution >> Net-IT s.r.l. >> Via Cesare Montanari, 2 >> 47521 Cesena (FC) >> Tel +39 0547 1955485 >> Fax +39 0547 1950285 >> >> -------------------------------------------------------------------- >> CONFIDENTIALITY NOTICE >> This message and its attachments are addressed solely to the persons >> above and may contain confidential information. If you have received >> the message in error, be informed that any use of the content hereof >> is prohibited. Please return it immediately to the sender and delete >> the message. Should you have any questions, please contact us by re- >> plying to info at wirem.net >> Thank you >> WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) >> -------------------------------------------------------------------- > > > -- > Kind regards, > CTO at > Foton Telecom CJSC > Tel.: +7 (499) 679-99-99 > nic-hdl: SS29286-RIPE > AS42861 on PeeringDB, Qrator, BGP.HE.NET > > "Amazing photons > Carry our data worldwide > Never seem to stop" (c) JUNOS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Jun 7 00:17:30 2016 From: jim at rfc1035.com (Jim Reid) Date: Mon, 6 Jun 2016 23:17:30 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> Message-ID: > On 6 Jun 2016, at 22:54, Aleksey Bulgakov wrote: > > Why are we talking about 185./8 only? We are not. You might be though. :-) Current policy applies to ALL IPv4 address space held by the NCC. Or that may be obtained by the NCC somehow, say because it was returned by an LIR or a future allocation from IANA of freshly reclaimed space. This policy has been commonly called ?last /8? as a sort of shorthand by the community. Sadly, this name is misleading. Some have assumed the policy only applies to allocations made by the NCC out of its last /8: 185/8. It doesn?t. It applies to all allocations from now on regardless of which chunk of a /8 held by the NCC gets chosen to issue a one-time-only /22 to an LIR. The policy became known as ?last /8? because it came into effect as soon as the NCC had to make an allocation from its final /8 allocation from IANA. ie An LIR's request was too big to be satisfied from a block elsewhere in the NCC?s pool of available space and therefore had to come from an allocation out of 185/8. At that point, the previous policy of needs-based allocation ended and LIRs could only get a single /22. From elvis at v4escrow.net Tue Jun 7 00:22:52 2016 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 7 Jun 2016 01:22:52 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> Message-ID: <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> Hi, On 6/7/16 1:17 AM, Jim Reid wrote: >> On 6 Jun 2016, at 22:54, Aleksey Bulgakov wrote: >> >> Why are we talking about 185./8 only? > We are not. You might be though. :-) Why are we still talking about this proposal? I was under the impression that it will be withdrawn soon after the RIPE Meeting. If that is the case, let's withdraw it and stop the noise :) If not, Remco, please let us know what you want to do with it as it is obvious that this version will never be accepted. thanks, elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksbulgakov at gmail.com Tue Jun 7 00:27:43 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Tue, 7 Jun 2016 01:27:43 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> Message-ID: So, if this policy is approved, all allocations will have 'final-allocated' status and return to the NCC if there are more than 2 allocations with 'final-allocated' status. Or I don't understand this policy and it should be changed 7 ???? 2016 ?. 1:17 ???????????? "Jim Reid" ???????: > > > On 6 Jun 2016, at 22:54, Aleksey Bulgakov > wrote: > > > > Why are we talking about 185./8 only? > > We are not. You might be though. :-) > > Current policy applies to ALL IPv4 address space held by the NCC. Or that > may be obtained by the NCC somehow, say because it was returned by an LIR > or a future allocation from IANA of freshly reclaimed space. > > This policy has been commonly called ?last /8? as a sort of shorthand by > the community. Sadly, this name is misleading. Some have assumed the policy > only applies to allocations made by the NCC out of its last /8: 185/8. It > doesn?t. It applies to all allocations from now on regardless of which > chunk of a /8 held by the NCC gets chosen to issue a one-time-only /22 to > an LIR. > > The policy became known as ?last /8? because it came into effect as soon > as the NCC had to make an allocation from its final /8 allocation from > IANA. ie An LIR's request was too big to be satisfied from a block > elsewhere in the NCC?s pool of available space and therefore had to come > from an allocation out of 185/8. At that point, the previous policy of > needs-based allocation ended and LIRs could only get a single /22. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksbulgakov at gmail.com Tue Jun 7 00:30:44 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Tue, 7 Jun 2016 01:30:44 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> Message-ID: I was disagree with Elvis about 2015-01, but I agree now. Dear, chairs. Could you, please, tell if this proposal is opened for discuss or withdrawn. :) 7 ???? 2016 ?. 1:23 ???????????? "Elvis Daniel Velea" ???????: > Hi, > On 6/7/16 1:17 AM, Jim Reid wrote: > > On 6 Jun 2016, at 22:54, Aleksey Bulgakov wrote: > > Why are we talking about 185./8 only? > > > We are not. You might be though. :-) > > Why are we still talking about this proposal? I was under the impression > that it will be withdrawn soon after the RIPE Meeting. > > If that is the case, let's withdraw it and stop the noise :) If not, > Remco, please let us know what you want to do with it as it is obvious that > this version will never be accepted. > > thanks, > elvis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Jun 7 01:14:52 2016 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Jun 2016 00:14:52 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> Message-ID: <31B75E16-42AA-45F9-B436-0F512B5CF473@rfc1035.com> > On 6 Jun 2016, at 23:22, Elvis Daniel Velea wrote: > > Hi, > On 6/7/16 1:17 AM, Jim Reid wrote: >>> On 6 Jun 2016, at 22:54, Aleksey Bulgakov >>> wrote: >>> >>> Why are we talking about 185./8 only? >>> >> We are not. You might be though. :-) > Why are we still talking about this proposal? I was under the impression that it will be withdrawn soon after the RIPE Meeting. I was only explaining what resources are covered by the current policy (ie last /8). Nothing to do with 2016-03. That proposal?s deader than Elvis. Not you obviously, the other one who played Vegas a lot in the 70s. :-) From gert at space.net Tue Jun 7 09:45:41 2016 From: gert at space.net (Gert Doering) Date: Tue, 7 Jun 2016 09:45:41 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> Message-ID: <20160607074541.GG79185@Space.Net> Hi, On Tue, Jun 07, 2016 at 12:54:04AM +0300, Aleksey Bulgakov wrote: > E.g. If the LIR has the allocation 31./12 (this is for example only, I > didn't check what RIR has 31./8 network) and didn't use it during 5 years > (or other period) he should return it to the NCC pool or a part of it. That would certainly be welcome, but there are no contractual or policy requirements that could *force* the LIR to return the space (or would allow the RIPE NCC to take it back). Allocation policy has always been geared to "here's a block, you fill it, then you come back and ask for the next block" - the situation "here's a block, and if you do *not* fill it, give back the unused part in years time" just did not happen during the growth years of the IPv4 Internet, so the policy does not have any clauses for it. Changing the policy to apply to old blocks would be retroactively applying policy to *holders*, which is generally a no-go area (and I disagree with some members of the community here on what is "retroactive" - I think that affecting future(!) *actions* regarding a block is ok, but changing the de-facto *status* of something people rely on is highly problematic) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Tue Jun 7 09:48:32 2016 From: gert at space.net (Gert Doering) Date: Tue, 7 Jun 2016 09:48:32 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> Message-ID: <20160607074832.GH79185@Space.Net> Hi, On Tue, Jun 07, 2016 at 01:30:44AM +0300, Aleksey Bulgakov wrote: > I was disagree with Elvis about 2015-01, but I agree now. > > Dear, chairs. Could you, please, tell if this proposal is opened for > discuss or withdrawn. :) As per https://www.ripe.net/participate/policies/current-proposals/current-policy-proposals it is in discussion phase until 21 Jun 2016. Easy to find with google. Since you did not see an announcement either by Remco or Marco that it has been withdrawn, it has not - the proposer is free to take the feedback from the discussion phase and work that into a "v2" of the proposal, for example, instead of withdrawing. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rgori at wirem.net Tue Jun 7 14:14:46 2016 From: rgori at wirem.net (Riccardo Gori) Date: Tue, 7 Jun 2016 14:14:46 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> Message-ID: <9e55255a-f8a8-e4fa-cb08-e9adfaaca204@wirem.net> Hi Aleksey, Il 06/06/2016 23:54, Aleksey Bulgakov ha scritto: > > Hi. > > Why are we talking about 185./8 only? There are many unused > allocations bigger than /8 but the NCC doesn't want to pay attention > to them. > As you can read on the top of 2016-03 proposal states: * Explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA This would apply to the whole reamining pool. > > E.g. If the LIR has the allocation 31./12 (this is for example only, I > didn't check what RIR has 31./8 network) and didn't use it during 5 > years (or other period) he should return it to the NCC pool or a part > of it. > > There is 2015-01, that prevents speculations. And I don't see any > reasons to implement 2016-03. > > "Sergey" > wrote: > > > > Completely agree with Riccardo on this. > > > > I've addressed this question via IRC during GM, why the strict audit > is not possible - and got a response that it's against policy. Google > has supported this concern. > > > > If there is problem with policy, the policy should be changed, not > workarounds against the policy added. > > > > > > On 06/07/16 00:09, Riccardo Gori wrote: > >> > >> Hi, > >> > >> although I understand the spirit of this policy in my opinion > there's a big problem behind it: seems that has been thought for > reasoucers not in use. > >> I really don't get how a space can be de-registered once announced > and in use and after have been allocated under regular procedures and > business processes. > >> > >> A new entrant would see his investments vanified by a rule that > make possibile transferts possbile only for old LIRs that acquired > space before 09/2012. > >> I think this really creates barrier to ingress in the market. > >> > >> If a return policy has to be proposed this should address the whole > IPv4 RIPE Region space to be fair and catch where IPs are stockpiled > and not in use. > >> Anyway we all know that's quite impossible. > >> > >> To address the problem of abuse RIPE NCC should enforce audit and > check if the LIR "make assignement(s)" as stated in the policy. > >> This could be a way to get rid of buy/sell just for speculation. > >> > >> I cannot support this policy > >> > >> regards > >> Riccardo > >> > >> -- > >> > >> Ing. Riccardo Gori > >> e-mail:rgori at wirem.net > >> > >> WIREM Fiber Revolution > >> Net-IT s.r.l. > >> Via Cesare Montanari, 2 > >> 47521 Cesena (FC) > >> Tel +39 0547 1955485 > >> Fax +39 0547 1950285 > >> > >> -------------------------------------------------------------------- > >> CONFIDENTIALITY NOTICE > >> This message and its attachments are addressed solely to the persons > >> above and may contain confidential information. If you have received > >> the message in error, be informed that any use of the content hereof > >> is prohibited. Please return it immediately to the sender and delete > >> the message. Should you have any questions, please contact us by re- > >> plying toinfo at wirem.net > >> Thank you > >> WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > >> -------------------------------------------------------------------- > > > > > > -- > > Kind regards, > > CTO at > > Foton Telecom CJSC > > Tel.: +7 (499) 679-99-99 > > nic-hdl: SS29286-RIPE > > AS42861 on PeeringDB, Qrator,BGP.HE.NET > > > > "Amazing photons > > Carry our data worldwide > > Never seem to stop" (c) JUNOS > regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From aleksbulgakov at gmail.com Tue Jun 7 15:22:49 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Tue, 7 Jun 2016 16:22:49 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <9e55255a-f8a8-e4fa-cb08-e9adfaaca204@wirem.net> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <9e55255a-f8a8-e4fa-cb08-e9adfaaca204@wirem.net> Message-ID: *5.1 Allocations made by the RIPE NCC to LIRs* 4. All allocations will be marked in the RIPE database as ?ALLOCATED FINAL? 5. An allocation marked "ALLOCATED FINAL" is valid as long as it remains with the LIR it was allocated to. If an LIR, due to mergers, acquisitions or other means gains additional allocations marked "ALLOCATED FINAL", all but the equivalent of a single /22 will be de-registered by the RIPE NCC within 180 days. More than one /22 from the 185./8 are additional and others are not. What will happen with already received additional /22 from the 185./8? 7 ???? 2016 ?. 15:14 ???????????? "Riccardo Gori" ???????: > Hi Aleksey, > Il 06/06/2016 23:54, Aleksey Bulgakov ha scritto: > > Hi. > > Why are we talking about 185./8 only? There are many unused allocations > bigger than /8 but the NCC doesn't want to pay attention to them. > > > As you can read on the top of 2016-03 proposal states: > > > - Explicitly state that the current IPv4 allocation policy applies to > all available IPv4 address space held by the RIPE NCC that has not been > reserved or marked to be returned to IANA > > This would apply to the whole reamining pool. > > E.g. If the LIR has the allocation 31./12 (this is for example only, I > didn't check what RIR has 31./8 network) and didn't use it during 5 years > (or other period) he should return it to the NCC pool or a part of it. > > There is 2015-01, that prevents speculations. And I don't see any reasons > to implement 2016-03. > > "Sergey" wrote: > > > > Completely agree with Riccardo on this. > > > > I've addressed this question via IRC during GM, why the strict audit is > not possible - and got a response that it's against policy. Google has > supported this concern. > > > > If there is problem with policy, the policy should be changed, not > workarounds against the policy added. > > > > > > On 06/07/16 00:09, Riccardo Gori wrote: > >> > >> Hi, > >> > >> although I understand the spirit of this policy in my opinion there's a > big problem behind it: seems that has been thought for reasoucers not in > use. > >> I really don't get how a space can be de-registered once announced and > in use and after have been allocated under regular procedures and business > processes. > >> > >> A new entrant would see his investments vanified by a rule that make > possibile transferts possbile only for old LIRs that acquired space before > 09/2012. > >> I think this really creates barrier to ingress in the market. > >> > >> If a return policy has to be proposed this should address the whole > IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and > not in use. > >> Anyway we all know that's quite impossible. > >> > >> To address the problem of abuse RIPE NCC should enforce audit and check > if the LIR "make assignement(s)" as stated in the policy. > >> This could be a way to get rid of buy/sell just for speculation. > >> > >> I cannot support this policy > >> > >> regards > >> Riccardo > >> > >> -- > >> > >> Ing. Riccardo Gori > >> e-mail: rgori at wirem.net > >> > >> WIREM Fiber Revolution > >> Net-IT s.r.l. > >> Via Cesare Montanari, 2 > >> 47521 Cesena (FC) > >> Tel +39 0547 1955485 > >> Fax +39 0547 1950285 > >> > >> -------------------------------------------------------------------- > >> CONFIDENTIALITY NOTICE > >> This message and its attachments are addressed solely to the persons > >> above and may contain confidential information. If you have received > >> the message in error, be informed that any use of the content hereof > >> is prohibited. Please return it immediately to the sender and delete > >> the message. Should you have any questions, please contact us by re- > >> plying to info at wirem.net > >> Thank you > >> WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > >> -------------------------------------------------------------------- > > > > > > -- > > Kind regards, > > CTO at > > Foton Telecom CJSC > > Tel.: +7 (499) 679-99-99 > > nic-hdl: SS29286-RIPE > > AS42861 on PeeringDB, Qrator, BGP.HE.NET > > > > "Amazing photons > > Carry our data worldwide > > Never seem to stop" (c) JUNOS > > regards > Riccardo > -- > > Ing. Riccardo Gori > e-mail: rgori at wirem.net > Mobile: +39 339 8925947 > Mobile: +34 602 009 437 > Profile: https://it.linkedin.com/in/riccardo-gori-74201943 > > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying to info at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From t.schallar at avalon.at Wed Jun 8 08:53:40 2016 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Wed, 8 Jun 2016 08:53:40 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <9e55255a-f8a8-e4fa-cb08-e9adfaaca204@wirem.net> Message-ID: <29fbadad-aeec-04a7-c6b2-092013137cf3@avalon.at> Hi! Aleksey Bulgakov schrieb am 07.06.2016 um 15:22: > What will happen with already received additional /22 from the 185./8? My suggestion is, that the proposal should also apply for those LIRs. But of course you have to give them time to re-allocate their IP space, before they have to give the additional /22's back. I would think about 1-3 years. How many multiple last-/22 allocations do we talk about? 10? 1000? regards, Thomas From sylvain.vallerot at opdop.net Thu Jun 9 11:04:16 2016 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Thu, 09 Jun 2016 11:04:16 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <573B0906.3060708@ripe.net> References: <573B0906.3060708@ripe.net> Message-ID: <57593110.7030007@opdop.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, On 17/05/2016 14:05, Marco Schmidt wrote: > - These allocation are not transferrable > - LIRs may only retain one final /22 following a merger or acquisition > - Sub-allocations are not possible These would be correct if applied to End Users, unfortunately your proposition is applying to LIRs. So as I understand it, 2016-03 results in making a LIR's dimension void, e.g. to assimilate a LIR to an End User. So I oppose this proposal. As I already explained some time ago, a fair "last /8" policy evolution should tend to apply abuse control on End Users and let LIRs make an independant job correctly : there is no point in having LIRs limited in distributing IP ressources to new born ops, and the new born ops shall not be forced to become LIRs to exists. Best regards, S. Vallerot - -- http://www.opdop.fr - mutualiser et interconnecter en coop?rative Opdop - Soci?t? Coop?rative d'Inter?t Collectif sous forme de SARL sur IRC r?seau geeknode #opdop - t?l: 0950 31 54 74, 06 86 38 38 68 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAldZMRAACgkQJBGsD8mtnRFRxQD9GU7d+khzmyPkw2LD4cZGw8aK xCkq9A/WlrHPStVCmngA/206953O/oEOn91DEZ0l4+YO1Q5X5X8vhz4PO62XiIdJ =JQRL -----END PGP SIGNATURE----- From ripe at liopen.fr Thu Jun 9 11:43:09 2016 From: ripe at liopen.fr (Denis Fondras) Date: Thu, 9 Jun 2016 11:43:09 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <57593110.7030007@opdop.net> References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> Message-ID: <20160609094309.GD16361@enforcer.ledeuns.net> > These would be correct if applied to End Users, unfortunately your > proposition is applying to LIRs. > > So as I understand it, 2016-03 results in making a LIR's dimension > void, e.g. to assimilate a LIR to an End User. > > So I oppose this proposal. > I fully agree with you but it seems some think that prefixes from last-/8 is not intended to be used and distributed as we used to. Which I can comprehend, because as LIR we need to understand and make our end-users understand there is no IPv4 available anymore. Is there an official statement on this point ? Can LIR from the last-/8 distribute addresses to customers or only use it on CGN ? From arash_mpc at parsun.com Thu Jun 9 11:53:55 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Thu, 9 Jun 2016 19:53:55 +1000 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <29fbadad-aeec-04a7-c6b2-092013137cf3@avalon.at> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <9e55255a-f8a8-e4fa-cb08-e9adfaaca204@wirem.net> <29fbadad-aeec-04a7-c6b2-092013137cf3@avalon.at> Message-ID: <012e01d1c234$e5ba8830$b12f9890$@parsun.com> Hi, Re-allocate their IP space to what? Would be any new allocation for them in 1-3 years? Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of DI. Thomas Schallar Sent: Wednesday, 8 June 2016 4:54 PM To: Aleksey Bulgakov Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) Hi! Aleksey Bulgakov schrieb am 07.06.2016 um 15:22: > What will happen with already received additional /22 from the 185./8? My suggestion is, that the proposal should also apply for those LIRs. But of course you have to give them time to re-allocate their IP space, before they have to give the additional /22's back. I would think about 1-3 years. How many multiple last-/22 allocations do we talk about? 10? 1000? regards, Thomas From gert at space.net Thu Jun 9 13:17:34 2016 From: gert at space.net (Gert Doering) Date: Thu, 9 Jun 2016 13:17:34 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <20160609094309.GD16361@enforcer.ledeuns.net> References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> <20160609094309.GD16361@enforcer.ledeuns.net> Message-ID: <20160609111734.GH79185@Space.Net> Hi, On Thu, Jun 09, 2016 at 11:43:09AM +0200, Denis Fondras wrote: > Is there an official statement on this point ? Can LIR from the last-/8 > distribute addresses to customers or only use it on CGN ? Policy is clear on that: you can use the addresses any way you want. *BUT*: do not come back later and ask for more if you used them carelessly - thus, it may be generally a good idea to use the last scraps of IPv4 to enable communication between your IPv6 customer base and those folks out there that still have no IPv6. So it's sort of implied that the intended usage is "for IPv6<->IPv4 gatewaying" (or to dual-stack your mail and DNS servers, etc. etc.), but policy doesn't formally say so. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From t.schallar at avalon.at Thu Jun 9 14:46:09 2016 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Thu, 9 Jun 2016 14:46:09 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <012e01d1c234$e5ba8830$b12f9890$@parsun.com> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <9e55255a-f8a8-e4fa-cb08-e9adfaaca204@wirem.net> <29fbadad-aeec-04a7-c6b2-092013137cf3@avalon.at> <012e01d1c234$e5ba8830$b12f9890$@parsun.com> Message-ID: Hello Arash! Arash Naderpour schrieb am 09.06.2016 um 11:53: > Would be any new allocation for them in 1-3 years? No, of course not. > Re-allocate their IP space to what? Either to remaining IP fragments in older blocks or to CGN and/or IPv6. The very same what any provider has to do with its customers. As I asked before: how many ISPs do have more than one "final" /22 in Use? If this would be a small number, we can skip any discussion about them and what to do. regards, Thomas From mschmidt at ripe.net Thu Jun 9 16:04:09 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 09 Jun 2016 16:04:09 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: Message-ID: Dear Thomas, Please allow me to answer your question: On 2016-06-09 14:46:09 CET, DI. Thomas Schallar wrote: > As I asked before: how many ISPs do have more than one "final" /22 in Use? > Currently we see 414 LIRs that have more than one /22 from the range 185/8 registered to them. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From frettled at gmail.com Thu Jun 9 17:23:24 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 9 Jun 2016 17:23:24 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <57593110.7030007@opdop.net> References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> Message-ID: On Thu, Jun 9, 2016 at 11:04 AM, Sylvain Vallerot < sylvain.vallerot at opdop.net> wrote: > > These would be correct if applied to End Users, unfortunately your > proposition is applying to LIRs. > > So as I understand it, 2016-03 results in making a LIR's dimension > void, e.g. to assimilate a LIR to an End User. > Several (and I would say many) LIRs _are_ end users, and the distinction between LIR and end users is not, as far as I have understood past and current policy, not intended to be watertight. In other words, it's fine for a LIR to be an end user, and in principle, it seems sensible that policy acknowledges that, but avoids making unnecessary limitations that interfere with that. > > So I oppose this proposal. > > As I already explained some time ago, a fair "last /8" policy > evolution should tend to apply abuse control on End Users and let > LIRs make an independant job correctly : there is no point in > having LIRs limited in distributing IP ressources to new born ops, > and the new born ops shall not be forced to become LIRs to exists. > This has already happened. There has been a huge amount of new LIRs registered in order to acquire a share of the remaining pool. Your arguments do not seem to be arguments against 2016-03, but against current policy. If you want to change current policy, you should do as the authors of 2015-05 and 2016-03: gather support, make a proposal yourself. Please note that I'm not flagging any preference for or against the policy proposal. I think it's a bit too much like deck chair rearrangement, and my feelings for it are more "meh" than anything else, at least for now. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at vpsville.ru Fri Jun 10 13:32:03 2016 From: alex at vpsville.ru (Alexey Galaev) Date: Fri, 10 Jun 2016 15:32:03 +0400 (MSK) Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> Message-ID: <1585988178.3688.1465558323034.JavaMail.zimbra@vpsville.ru> Hello. There are a lot of negative opinions about this proposal. I hope that this proposal will be withdrawn. BR, Alexey Galaev +7 985 3608004, http://vpsville.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Fri Jun 10 15:16:10 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Fri, 10 Jun 2016 14:16:10 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: On 9 June 2016 at 15:04, Marco Schmidt wrote: > > Currently we see 414 LIRs that have more than one /22 from the range 185/8 > registered to them. > That's quite interesting. I had a look in the DFZ (as received from Level(3) this afternoon) I can see 13742 advertisements of space from 185/8, 5 of them are for /21 and 1 is for a /20. The advertisements include de-aggregations (e.g. a /22 and a /23 for the same prefix) Looking a the /22 adverts. there are 5613 in the DFZ with 4090 distinct AS origins. This means that over 1500 AS's are advertising more than one /22. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Fri Jun 10 15:23:20 2016 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Fri, 10 Jun 2016 13:23:20 +0000 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: , Message-ID: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> Aled, The data you provided is not relevant. For example, we have a significant number of Customers who have a number of servers with us, are LIRs themselves, but we do BGP for them, as such there is a significant number of /22s originated from our AS, yet not owned, nor operated by us. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 10 Jun 2016, at 14:17, Aled Morris > wrote: On 9 June 2016 at 15:04, Marco Schmidt > wrote: Currently we see 414 LIRs that have more than one /22 from the range 185/8 registered to them. That's quite interesting. I had a look in the DFZ (as received from Level(3) this afternoon) I can see 13742 advertisements of space from 185/8, 5 of them are for /21 and 1 is for a /20. The advertisements include de-aggregations (e.g. a /22 and a /23 for the same prefix) Looking a the /22 adverts. there are 5613 in the DFZ with 4090 distinct AS origins. This means that over 1500 AS's are advertising more than one /22. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Fri Jun 10 17:19:15 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Fri, 10 Jun 2016 16:19:15 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> Message-ID: On Friday, 10 June 2016, Dominik Nowacki wrote: > Aled, > The data you provided is not relevant. > > For example, we have a significant number of Customers who have a number > of servers with us, are LIRs themselves, but we do BGP for them, as such > there is a significant number of /22s originated from our AS, yet not > owned, nor operated by us. > I'm curious to know what benefit such customers perceive from being LIRs (rather than just taking IP address space from you). From what you say they don't run their own networks - do they assign resources to their downstream customers? Not from the 185/8 allocation obviously. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From ck-lists at cksoft.de Fri Jun 10 17:27:52 2016 From: ck-lists at cksoft.de (Christian Kratzer) Date: Fri, 10 Jun 2016 17:27:52 +0200 (CEST) Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> Message-ID: Hi, On Fri, 10 Jun 2016, Aled Morris wrote: > On Friday, 10 June 2016, Dominik Nowacki wrote: > >> Aled, >> The data you provided is not relevant. >> >> For example, we have a significant number of Customers who have a number >> of servers with us, are LIRs themselves, but we do BGP for them, as such >> there is a significant number of /22s originated from our AS, yet not >> owned, nor operated by us. >> > > I'm curious to know what benefit such customers perceive from being LIRs > (rather than just taking IP address space from you). From what you say they > don't run their own networks - do they assign resources to their downstream > customers? Not from the 185/8 allocation obviously. simple reasons: - get more space than your upstream is willing to give to you - you want but cannot get pi space so getting your own pa space is a good substitute Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From ripe-wgs at radu-adrian.feurdean.net Sat Jun 11 14:01:40 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 11 Jun 2016 14:01:40 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> Message-ID: <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> On Fri, Jun 10, 2016, at 17:19, Aled Morris wrote: > I'm curious to know what benefit such customers perceive from being LIRs > (rather than just taking IP address space from you). Hi, They have "their own" space, one /22 for them alone. Not sure this is something easy (even less cost-effective) enough to obtain these days. > From what you say they don't run their own networks - do they assign > resources to their downstream customers? Don't know about Dominik's customers, but some of them do. You can find several kinds of network-less service providers out there in the wild. Then there's the issue of things done "inside out" : ISPs running on ASSIGNED PI (not very willing to deal with RIPE / RIPE NCC) and end-users on ALLOCATED PA (willing to do so). From noc at ntx.ru Sat Jun 11 20:28:58 2016 From: noc at ntx.ru (NTX NOC) Date: Sat, 11 Jun 2016 21:28:58 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <1585988178.3688.1465558323034.JavaMail.zimbra@vpsville.ru> References: <29443ee5-1cb7-8401-9677-d6807e4e9d07@wirem.net> <5755E738.1060700@fotontel.ru> <233c45d4-15de-0bf7-af0a-65e44a035d3e@v4escrow.net> <1585988178.3688.1465558323034.JavaMail.zimbra@vpsville.ru> Message-ID: <4dca0e83-cc5d-030f-138d-dec2424cbbc2@ntx.ru> Hello, I agree with Alexey. Too bad negative effect. // Nikolay at NTX On 10.06.2016 14:32, Alexey Galaev wrote: > Hello. > There are a lot of negative opinions about this proposal. > I hope that this proposal will be withdrawn. > > BR, > Alexey Galaev > +7 985 3608004, http://vpsville.ru From noc at ntx.ru Sat Jun 11 20:45:03 2016 From: noc at ntx.ru (NTX NOC) Date: Sat, 11 Jun 2016 21:45:03 +0300 Subject: [address-policy-wg] IPv4 reserved space Message-ID: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Dear all, As we see ISPs and community would like to have more IPv4 space in use. I would like to ask a question what do people think about other side of IPv4 numeration space. Because we have in IPv4 a lot of addresses not in use at all but that space could be easy used. 240.0.0.0/4 Reserved (former Class E network) RFC 1700 it's 16 */8 networks. More then 256 Millions of routable and never used IPv4. 185/8 network has about 6.4M free and total RIPE has about 15M free IPv4 and we all say 185/8 will be enough for 2-3 years and rest - for some more time. But 256 M Ipv4 space could be enough for years! Space reserved for future Use. But will the future come to us or not? https://en.wikipedia.org/wiki/IPv4 https://tools.ietf.org/html/rfc1700 Is far as I see routers could easy start to use that IP space. People spend a lot of time and money to get some IPs but not to ask IANA to allow use this space. Technically it's very easy to start use IPs from such ranges. What does community thinks about it? Yuri From phessler at theapt.org Sat Jun 11 20:56:46 2016 From: phessler at theapt.org (Peter Hessler) Date: Sat, 11 Jun 2016 20:56:46 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Message-ID: <20160611185646.GQ31815@gir.theapt.org> Implementation detail: many operating systems hard-code that range as invalid network space. The effort to make it available would be _less_ than getting everyone else in the world upgraded to IPv6. On 2016 Jun 11 (Sat) at 21:45:03 +0300 (+0300), NTX NOC wrote: :Dear all, : :As we see ISPs and community would like to have more IPv4 space in use. : :I would like to ask a question what do people think about other side of :IPv4 numeration space. Because we have in IPv4 a lot of addresses not in :use at all but that space could be easy used. : :240.0.0.0/4 Reserved (former Class E network) RFC 1700 : :it's 16 */8 networks. More then 256 Millions of routable and never used :IPv4. 185/8 network has about 6.4M free and total RIPE has about 15M :free IPv4 and we all say 185/8 will be enough for 2-3 years and rest - :for some more time. But 256 M Ipv4 space could be enough for years! : :Space reserved for future Use. But will the future come to us or not? : :https://en.wikipedia.org/wiki/IPv4 :https://tools.ietf.org/html/rfc1700 : :Is far as I see routers could easy start to use that IP space. People :spend a lot of time and money to get some IPs but not to ask IANA to :allow use this space. Technically it's very easy to start use IPs from :such ranges. : :What does community thinks about it? : :Yuri : -- Isn't it interesting that the same people who laugh at science fiction listen to weather forecasts and economists? -- Kelvin Throop III From tom.smyth at wirelessconnect.eu Sat Jun 11 20:57:08 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Sat, 11 Jun 2016 19:57:08 +0100 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Message-ID: Yuri, I wouldn't have a difficulty with it :) ... I dont see a reason why it wouldnt work ... although you would want everyone who is filtering bogons manually from their routers and the 240.0.0.0/4 has been considered a bogon for quite some time... so alot of people who do rudimentary prefix filtering on their border routers would have to update to make that range usable ... I have heard arguments that some Operating systems have that range filtered out and is non configurable... but I doubt the IPv6 adoption advocates ... or the IPv4 Sellers would like that idea too much as it would cause the price per ipv4 to collapse... I reckon this question has been asked before and I'm sure someone will point us to that discussion before... Hope this helps, On Sat, Jun 11, 2016 at 7:45 PM, NTX NOC wrote: > Dear all, > > As we see ISPs and community would like to have more IPv4 space in use. > > I would like to ask a question what do people think about other side of > IPv4 numeration space. Because we have in IPv4 a lot of addresses not in > use at all but that space could be easy used. > > 240.0.0.0/4 Reserved (former Class E network) RFC 1700 > > it's 16 */8 networks. More then 256 Millions of routable and never used > IPv4. 185/8 network has about 6.4M free and total RIPE has about 15M > free IPv4 and we all say 185/8 will be enough for 2-3 years and rest - > for some more time. But 256 M Ipv4 space could be enough for years! > > Space reserved for future Use. But will the future come to us or not? > > https://en.wikipedia.org/wiki/IPv4 > https://tools.ietf.org/html/rfc1700 > > Is far as I see routers could easy start to use that IP space. People > spend a lot of time and money to get some IPs but not to ask IANA to > allow use this space. Technically it's very easy to start use IPs from > such ranges. > > What does community thinks about it? > > Yuri > > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Sat Jun 11 21:00:24 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 11 Jun 2016 21:00:24 +0200 (CEST) Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Message-ID: On Sat, 11 Jun 2016, NTX NOC wrote: > What does community thinks about it? People have looked into this before. It's not feasible, not enough client OSes support it. People even tried this in the IETF, lots of years ago: https://tools.ietf.org/html/draft-savolainen-indicating-240-addresses-01 IPv4 stone is blead dry. Even if we doubled number of IPv4 addresses by means of some unknown magic, it wouldn't buy is any significant amount of time. The solution is IPv6. There is no other way to fix this. Direct your energy in that direction. -- Mikael Abrahamsson email: swmike at swm.pp.se From noc at ntx.ru Sat Jun 11 21:14:11 2016 From: noc at ntx.ru (NTX NOC) Date: Sat, 11 Jun 2016 22:14:11 +0300 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <20160611185646.GQ31815@gir.theapt.org> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> Message-ID: On 11.06.2016 21:56, Peter Hessler wrote: > many operating systems hard-code that range as > invalid network space. Could you give any OS examples? I looks to my Juniper docs and see http://www.juniper.net/documentation/en_US/junos13.3/topics/topic-map/martian-addresses.html It's not allowed by default but in one click you can make it work 240.0.0.0/4 orlonger -- allowed About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 by default to customers. Nobody wants it, nobody needs it. Yuri From swmike at swm.pp.se Sat Jun 11 21:27:44 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 11 Jun 2016 21:27:44 +0200 (CEST) Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> Message-ID: On Sat, 11 Jun 2016, NTX NOC wrote: > About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 > by default to customers. Nobody wants it, nobody needs it. ... and yet here you are, asking for obscure IPv4 blocks that are non-working in most operating systems available today, whilst all of them support IPv6 already. So "need" is in the eye of te beholder it seems. -- Mikael Abrahamsson email: swmike at swm.pp.se From gforgx at fotontel.ru Sat Jun 11 21:33:58 2016 From: gforgx at fotontel.ru (Sergey) Date: Sat, 11 Jun 2016 22:33:58 +0300 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> Message-ID: <575C67A6.8020702@fotontel.ru> Agree with Mikael. This is not a provocative question, but are NTX so worried about this proposal because it would affect their businesses selling and leasing IPv4 space? Their webpage mentions it at the top. The IP addresses aren't here to sell them. They're to be routed and used. This is just a tool. The IPv6 deployment is the only solution. On 06/11/16 22:27, Mikael Abrahamsson wrote: > On Sat, 11 Jun 2016, NTX NOC wrote: > >> About IPv6 - still now in Russia there are no Home ISPs who gives >> IPv6 by default to customers. Nobody wants it, nobody needs it. > > ... and yet here you are, asking for obscure IPv4 blocks that are > non-working in most operating systems available today, whilst all of > them support IPv6 already. > > So "need" is in the eye of te beholder it seems. > -- Kind regards, CTO at *Foton Telecom CJSC* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Sat Jun 11 21:38:37 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Sat, 11 Jun 2016 20:38:37 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> Message-ID: On 11 June 2016 at 13:01, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > On Fri, Jun 10, 2016, at 17:19, Aled Morris wrote: > > > I'm curious to know what benefit such customers perceive from being LIRs > > (rather than just taking IP address space from you). > > Hi, > > They have "their own" space, one /22 for them alone. I agree that's all they want. Do we really want dozens (hundreds even) of "members" who have no interest whatsoever in the good of the community, participating in the policy making, education or technical standards? Worst case, what if they got together and voted to demutualise RIPE? Realistically, I'd rather we went back to offering /24 (or less) of PI space to end users via their existing LIRs rather than burning /22's for end-users who think they might be missing out if they don't lay claim to their IPv4 space now. Many of the ISPs I know are advising their large business customers to "register with RIPE for IPv4 space" without really bothering to understand, or caring, they are joining a membership organisation. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at kwaoo.net Sat Jun 11 21:44:30 2016 From: noc at kwaoo.net (Jack) Date: Sat, 11 Jun 2016 21:44:30 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> Message-ID: On 11/06/2016 21:38, Aled Morris wrote: > Do we really want dozens (hundreds even) of "members" who have no interest > whatsoever in the good of the community, participating in the policy > making, education or technical standards? > > Worst case, what if they got together and voted to demutualise RIPE? That is called "democracy" Damn poor, there is so many of them. -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From gforgx at fotontel.ru Sat Jun 11 21:55:30 2016 From: gforgx at fotontel.ru (Sergey) Date: Sat, 11 Jun 2016 22:55:30 +0300 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> Message-ID: <575C6CB2.5070805@fotontel.ru> This simply is not true: https://version6.ru/isp Also during the last ENOG in Moscow I've seen a lot of End-User ISPs actually trying to implement IPv6 right now. Making efforts to keep up legacy protocols running on the Internet is a step back. On 06/11/16 22:14, NTX NOC wrote: > About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 > by default to customers. Nobody wants it, nobody needs it. Yuri -- Kind regards, CTO at *Foton Telecom CJSC* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sat Jun 11 22:05:42 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 11 Jun 2016 22:05:42 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> Message-ID: <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Hi, Small clarification: > Do we really want dozens (hundreds even) of "members" who have no interest whatsoever in the good of the community, participating in the policy making, education or technical standards? Being a member of the RIPE NCC has nothing to do with policy making (or education or standards for that matter). This is a RIPE community working group, not a RIPE NCC working group. Everybody is welcome to participate in this working group, not just RIPE NCC members. See https://www.ripe.net/participate/ripe Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Sat Jun 11 22:25:48 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 11 Jun 2016 22:25:48 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Message-ID: <846DCD0F-1C11-47D5-AC2B-03D2047E87CB@steffann.nl> Hi, > As we see ISPs and community would like to have more IPv4 space in use. > > I would like to ask a question what do people think about other side of > IPv4 numeration space. Because we have in IPv4 a lot of addresses not in > use at all but that space could be easy used. > > 240.0.0.0/4 Reserved (former Class E network) RFC 1700 I remember people looking into that years ago, and the conclusion was that in too many routers and operating systems the 240/4 block was hard-coded as unusable. I just checked the Linux source code and that restriction was removed there around 2008, but similar code was present in so many different places that it wasn't a viable solution. Remember that it wouldn't just be the organisation getting a block from 240/4, it would also affect everybody trying to communicate with them. Operating systems refusing to connect to a 240/4 address would make any website hosted on a 240/4 address badly reachable. Same for DNS servers hosted on such an address etc. > it's 16 */8 networks. More then 256 Millions of routable and never used > IPv4. That is actually not that much. In 2012 when we ran out of free IPv4 space for normal use the rate of allocation world-wide was more than a /8 per month. Even if we could use 240/4 these days, it would probably last us a year or so, and then we would be back where we are today. So in short: - 240/4 use is problematic - software needs to be changed in many places to make it usable - same for configurations (bogon filters etc) - it wouldn't last us much longer than a year anyway - we still need to move to IPv6 because we will have again run out Even shorter: we would use up 240/4 in less time than we would need to make it actually usable, so let's not. If we are changing stuff let's just spend our energy on implementing IPv6 instead. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Sat Jun 11 22:33:43 2016 From: gert at space.net (Gert Doering) Date: Sat, 11 Jun 2016 22:33:43 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Message-ID: <20160611203343.GK79185@Space.Net> Hi, On Sat, Jun 11, 2016 at 09:45:03PM +0300, NTX NOC wrote: > 240.0.0.0/4 Reserved (former Class E network) RFC 1700 Many OSes do not support it, because it is not unicast address space (coming behind the multicast range 224.0.0.0/4). Some do, but if you put your webservers in there, you want to make sure that *all* clients can use it. So lots of software and hardware upgrades would be needed to ensure it's actually useful. And if you do that, why not do IPv6? The other reason why this is not a useful avenue to purchase is that 16 /8s would be burnt up in like 1.5 years time if we return to the old regime of "show me your need, and I give you enough address space for it" - many large providers could easily use up a few /12 here and there... bang, first /8 gone. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Sat Jun 11 22:34:56 2016 From: gert at space.net (Gert Doering) Date: Sat, 11 Jun 2016 22:34:56 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> Message-ID: <20160611203456.GL79185@Space.Net> Hi, On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: > About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 > by default to customers. Nobody wants it, nobody needs it. The "nobody needs it" is a misconception. Direct your energy there to make people understand that IPv4 is game over. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From aled.w.morris at googlemail.com Sat Jun 11 22:50:10 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Sat, 11 Jun 2016 21:50:10 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: On 11 June 2016 at 21:05, Sander Steffann wrote: > Being a member of the RIPE NCC has nothing to do with policy making (or > education or standards for that matter). This is a RIPE community working > group, not a RIPE NCC working group. Everybody is welcome to participate in > this working group, not just RIPE NCC members. > > Sorry yes, I was clumsy in my wording. I am just surprised that we encourage organisations who don't participate (or have any interest in participating) in the RIPE policy process, or any of the mechanics of Internet governance, to join the RIPE NCC and therefore get a vote on budget and board member decisions. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sat Jun 11 22:54:25 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 11 Jun 2016 22:54:25 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: <824DCA59-DAB3-45DB-8040-8A32FC64C573@steffann.nl> Hi Aled, > Sorry yes, I was clumsy in my wording. No apologies required! I just wanted to make sure that everybody reading the messages (and archives) understands the difference. Some things are obvious for people who have been around for some time but can be confusing to those who haven't. I was just making sure that everybody understands what is being discussed :) Cheers! Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Sat Jun 11 22:59:26 2016 From: randy at psg.com (Randy Bush) Date: Sat, 11 Jun 2016 13:59:26 -0700 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: > I am just surprised that we encourage organisations who don't > participate (or have any interest in participating) in the RIPE policy > process, or any of the mechanics of Internet governance, to join the > RIPE NCC and therefore get a vote on budget and board member > decisions. this may seem a bit strange, but there are isps out there who are interested in running a network, and not internet policy, governance, and other things about layer seven. there really are. randy From aled.w.morris at googlemail.com Sat Jun 11 23:44:15 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Sat, 11 Jun 2016 22:44:15 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: On 11 June 2016 at 21:59, Randy Bush wrote: > > I am just surprised that we encourage organisations who don't > > participate (or have any interest in participating) in the RIPE policy > > process, or any of the mechanics of Internet governance, to join the > > RIPE NCC and therefore get a vote on budget and board member > > decisions. > > this may seem a bit strange, but there are isps out there who are > interested in running a network, and not internet policy, governance, > and other things about layer seven. there really are. > > OK if they are Internet Service Providers, but my concern is RIPE are giving address space to end users, basically because there is no PI mechanism anymore. So for all those people who argue we should be preserving the remaining address space in order to allow for new ISPs entering the market for as long as possible (which I agree with), we need to be realistic about end users who want (what was once called) PI space and not make the only option to be "become an LIR" with the result that we erode the free pool faster (i.e. allocating /22 when a /24 would be more than adequate.) Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From gforgx at fotontel.ru Sat Jun 11 23:50:29 2016 From: gforgx at fotontel.ru (Sergey) Date: Sun, 12 Jun 2016 00:50:29 +0300 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: <575C87A5.2000500@fotontel.ru> Agree on this. It's not only we erode the free pool faster, but we get a lot of unconscious RIPE NCC members this way. On 06/12/16 00:44, Aled Morris wrote: > > > So for all those people who argue we should be preserving the > remaining address space in order to allow for new ISPs entering the > market for as long as possible (which I agree with), we need to be > realistic about end users who want (what was once called) PI space and > not make the only option to be "become an LIR" with the result that we > erode the free pool faster (i.e. allocating /22 when a /24 would be > more than adequate.) > > Aled -- Kind regards, CTO at *Foton Telecom CJSC* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Sun Jun 12 00:04:16 2016 From: tore at fud.no (Tore Anderson) Date: Sun, 12 Jun 2016 00:04:16 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: <20160612000416.106a5bc7@envy> * Aled Morris > So for all those people who argue we should be preserving the remaining > address space in order to allow for new ISPs entering the market for as > long as possible (which I agree with), we need to be realistic about end > users who want (what was once called) PI space and not make the only > option to be "become an LIR" It's not the only option, PI blocks may still be acquired: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/ipv4/transfer-of-assigned-pi-space https://www.ripe.net/publications/docs/ripe-655#IPv6_PI_Assignments > with the result that we erode the free pool faster > (i.e. allocating /22 when a /24 would be more than adequate.) The simplest way of slowing down the allocation rate is probably to reduce the allocation size from /22 to either /23 or /24. Tore From ripe-wgs at radu-adrian.feurdean.net Sun Jun 12 00:14:43 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 12 Jun 2016 00:14:43 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <9ADBC3F8-F09F-48BA-8C87-302F3757489C@clouvider.co.uk> <1465646500.3133156.634602777.73B79A3A@webmail.messagingengine.com> <934D7B81-EFAA-4EBC-B93A-291DA03D18B2@steffann.nl> Message-ID: <1465683283.4101555.634898161.2BB18096@webmail.messagingengine.com> On Sat, Jun 11, 2016, at 22:50, Aled Morris wrote: > I am just surprised that we encourage organisations who don't participate > (or have any interest in participating) in the RIPE policy process, or any > of the mechanics of Internet governance, to join the RIPE NCC and > therefore get a vote on budget and board member decisions. Well, hopefully (depends for who), they don't (https://www.ripe.net/participate/meetings/gm/meetings/may-2016/voting-report). At least not yet. But you do have a valid point. Just hope they don't come with the idea that the NCC should stop following community's policies (and hand things over to national governments, or decice policies to be followed at the GM). -- Radu-Adrian FEURDEAN fr.ccs From Alexander.Koeppe at merckgroup.com Sun Jun 12 16:08:42 2016 From: Alexander.Koeppe at merckgroup.com (Alexander Koeppe) Date: Sun, 12 Jun 2016 14:08:42 +0000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> , <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> Message-ID: I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex > Am 11.06.2016 um 22:35 schrieb Gert Doering : > > Hi, > >> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >> About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 >> by default to customers. Nobody wants it, nobody needs it. > > The "nobody needs it" is a misconception. Direct your energy there to > make people understand that IPv4 is game over. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. From noc at kwaoo.net Sun Jun 12 16:35:08 2016 From: noc at kwaoo.net (Jack) Date: Sun, 12 Jun 2016 16:35:08 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> Message-ID: On 12/06/2016 16:08, Alexander Koeppe wrote: > This time and energy would be better off spent in just deploying v6. Sure, but how ? The only valuable idea I fetched, if it is only possible, is to make a united RIR team (RIPE & ARIN, at least), and try to convince Google, Yahoo and microsoft to priorize v6-reachable web site (with a real priority), like google did for TLS, if I recall That would probably motive the hosting world in this issue, making v6-only ISP viable > It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. > > -- Alex > > >> Am 11.06.2016 um 22:35 schrieb Gert Doering : >> >> Hi, >> >>> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >>> About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 >>> by default to customers. Nobody wants it, nobody needs it. >> >> The "nobody needs it" is a misconception. Direct your energy there to >> make people understand that IPv4 is game over. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> > > > This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. > > > > Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. > -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From dominik at clouvider.co.uk Sun Jun 12 16:38:44 2016 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Sun, 12 Jun 2016 14:38:44 +0000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> , Message-ID: <542F32F8-DD3C-4ADA-A92F-2F205AECDFB1@clouvider.co.uk> Well, Google's and Microsoft's systems are already reachable via IPv6, and systems do prefer making a connection over IPv6 where possible. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 12 Jun 2016, at 16:35, Jack > wrote: On 12/06/2016 16:08, Alexander Koeppe wrote: This time and energy would be better off spent in just deploying v6. Sure, but how ? The only valuable idea I fetched, if it is only possible, is to make a united RIR team (RIPE & ARIN, at least), and try to convince Google, Yahoo and microsoft to priorize v6-reachable web site (with a real priority), like google did for TLS, if I recall That would probably motive the hosting world in this issue, making v6-only ISP viable It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex Am 11.06.2016 um 22:35 schrieb Gert Doering >: Hi, On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 by default to customers. Nobody wants it, nobody needs it. The "nobody needs it" is a misconception. Direct your energy there to make people understand that IPv4 is game over. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Sun Jun 12 16:39:59 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 00:39:59 +1000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> , <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> Message-ID: <023501d1c4b8$4e804230$eb80c690$@parsun.com> And I don't understand why some people think that everyone can deploy IPv6, it is simply not available everywhere. It is not about difficulty, it is about possibility. Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Alexander Koeppe Sent: Monday, 13 June 2016 12:09 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex > Am 11.06.2016 um 22:35 schrieb Gert Doering : > > Hi, > >> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >> About IPv6 - still now in Russia there are no Home ISPs who gives >> IPv6 by default to customers. Nobody wants it, nobody needs it. > > The "nobody needs it" is a misconception. Direct your energy there to > make people understand that IPv4 is game over. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. From gforgx at fotontel.ru Sun Jun 12 16:41:01 2016 From: gforgx at fotontel.ru (Sergey) Date: Sun, 12 Jun 2016 17:41:01 +0300 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <023501d1c4b8$4e804230$eb80c690$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> Message-ID: <575D747D.4080204@fotontel.ru> Where exactly it is not possible? On 06/12/16 17:39, Arash Naderpour wrote: > And I don't understand why some people think that everyone can deploy IPv6, > it is simply not available everywhere. > It is not about difficulty, it is about possibility. > > Regards, > > Arash > > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Alexander Koeppe > Sent: Monday, 13 June 2016 12:09 AM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 > reserved space > > I don't understand how much time and energy is being put into the discussion > about keeping vintage IP alive. > This time and energy would be better off spent in just deploying v6. > It's just not that difficult. You just need to develop a stepwise approach. > A one-shot would probably fail. > > -- Alex > > >> Am 11.06.2016 um 22:35 schrieb Gert Doering : >> >> Hi, >> >>> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >>> About IPv6 - still now in Russia there are no Home ISPs who gives >>> IPv6 by default to customers. Nobody wants it, nobody needs it. >> The "nobody needs it" is a misconception. Direct your energy there to >> make people understand that IPv4 is game over. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> > > This message and any attachment are confidential and may be privileged or > otherwise protected from disclosure. If you are not the intended recipient, > you must not copy this message or attachment or disclose the contents to any > other person. If you have received this transmission in error, please notify > the sender immediately and delete the message and any attachment from your > system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not > accept liability for any omissions or errors in this message which may arise > as a result of E-Mail-transmission or for damages resulting from any > unauthorized changes of the content of this message and any attachment > thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not > guarantee that this message is free of viruses and does not accept liability > for any damages caused by any virus transmitted therewith. > > > > Click http://www.merckgroup.com/disclaimer to access the German, French, > Spanish and Portuguese versions of this disclaimer. > > -- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Sun Jun 12 16:41:40 2016 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Sun, 12 Jun 2016 14:41:40 +0000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <023501d1c4b8$4e804230$eb80c690$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> , <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> , <023501d1c4b8$4e804230$eb80c690$@parsun.com> Message-ID: Not available ? Please name a global carrier that does not support IPv6. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 12 Jun 2016, at 16:40, Arash Naderpour > wrote: And I don't understand why some people think that everyone can deploy IPv6, it is simply not available everywhere. It is not about difficulty, it is about possibility. Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Alexander Koeppe Sent: Monday, 13 June 2016 12:09 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex Am 11.06.2016 um 22:35 schrieb Gert Doering >: Hi, On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 by default to customers. Nobody wants it, nobody needs it. The "nobody needs it" is a misconception. Direct your energy there to make people understand that IPv4 is game over. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at kwaoo.net Sun Jun 12 16:44:00 2016 From: noc at kwaoo.net (Jack) Date: Sun, 12 Jun 2016 16:44:00 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <023501d1c4b8$4e804230$eb80c690$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> Message-ID: Well, there where difficulties 5 years ago, when you said "Let's go, deploy IPv6 !" So, 5 years ago, you failed going beyond these difficulties But today, you fixed them, whatever they were (hardware ? network design ? you worked on this issue) So, the problem is gone by now. Can't believe you did nothing about that issue :) On 12/06/2016 16:39, Arash Naderpour wrote: > And I don't understand why some people think that everyone can deploy IPv6, > it is simply not available everywhere. > It is not about difficulty, it is about possibility. > > Regards, > > Arash > > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Alexander Koeppe > Sent: Monday, 13 June 2016 12:09 AM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 > reserved space > > I don't understand how much time and energy is being put into the discussion > about keeping vintage IP alive. > This time and energy would be better off spent in just deploying v6. > It's just not that difficult. You just need to develop a stepwise approach. > A one-shot would probably fail. > > -- Alex > > >> Am 11.06.2016 um 22:35 schrieb Gert Doering : >> >> Hi, >> >>> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >>> About IPv6 - still now in Russia there are no Home ISPs who gives >>> IPv6 by default to customers. Nobody wants it, nobody needs it. >> >> The "nobody needs it" is a misconception. Direct your energy there to >> make people understand that IPv4 is game over. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> > > > This message and any attachment are confidential and may be privileged or > otherwise protected from disclosure. If you are not the intended recipient, > you must not copy this message or attachment or disclose the contents to any > other person. If you have received this transmission in error, please notify > the sender immediately and delete the message and any attachment from your > system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not > accept liability for any omissions or errors in this message which may arise > as a result of E-Mail-transmission or for damages resulting from any > unauthorized changes of the content of this message and any attachment > thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not > guarantee that this message is free of viruses and does not accept liability > for any damages caused by any virus transmitted therewith. > > > > Click http://www.merckgroup.com/disclaimer to access the German, French, > Spanish and Portuguese versions of this disclaimer. > > -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From Alexander.Koeppe at merckgroup.com Sun Jun 12 16:55:53 2016 From: Alexander.Koeppe at merckgroup.com (Alexander Koeppe) Date: Sun, 12 Jun 2016 14:55:53 +0000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <542F32F8-DD3C-4ADA-A92F-2F205AECDFB1@clouvider.co.uk> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> , , <542F32F8-DD3C-4ADA-A92F-2F205AECDFB1@clouvider.co.uk> Message-ID: I agree. The framework is there. Now up to each and every of us. I'm working for an enterprise and our approach starting at the outside and moving towards inside works quite well for us. Of course we're far from being finished. But for what's critical we're good for now. For a internet service provider I'd guess it goes the other way round. There is no master plan as each entity is different. But keeping the steps small and doable w/o losing the focus of the goal was always a successful way, at least for me. Every internet depending businesses like hosting providers or service providers that still ignore v6 today will get the bill sooner or later. -- Alex Am 12.06.2016 um 16:38 schrieb Dominik Nowacki >: Well, Google's and Microsoft's systems are already reachable via IPv6, and systems do prefer making a connection over IPv6 where possible. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Sun Jun 12 17:08:28 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 01:08:28 +1000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> , <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> , <023501d1c4b8$4e804230$eb80c690$@parsun.com> Message-ID: <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> I was not talking about a global carrier and if they can provide IPv6 or not, It was about availability and possibilities to have IPv6 connectivity everywhere. There are two different subject. Arash From: Dominik Nowacki [mailto:dominik at clouvider.co.uk] Sent: Monday, 13 June 2016 12:42 AM To: Arash Naderpour Cc: Alexander Koeppe ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Not available ? Please name a global carrier that does not support IPv6. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969 . Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 12 Jun 2016, at 16:40, Arash Naderpour > wrote: And I don't understand why some people think that everyone can deploy IPv6, it is simply not available everywhere. It is not about difficulty, it is about possibility. Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Alexander Koeppe Sent: Monday, 13 June 2016 12:09 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex Am 11.06.2016 um 22:35 schrieb Gert Doering >: Hi, On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 by default to customers. Nobody wants it, nobody needs it. The "nobody needs it" is a misconception. Direct your energy there to make people understand that IPv4 is game over. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gforgx at fotontel.ru Sun Jun 12 17:10:18 2016 From: gforgx at fotontel.ru (Sergey) Date: Sun, 12 Jun 2016 18:10:18 +0300 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> Message-ID: <575D7B5A.1020006@fotontel.ru> Global carriers provide that connectivity. What's the problem? On 06/12/16 18:08, Arash Naderpour wrote: > > I was not talking about a global carrier and if they can provide IPv6 > or not, It was about availability and possibilities to have IPv6 > connectivity everywhere. There are two different subject. > > Arash > > *From:*Dominik Nowacki [mailto:dominik at clouvider.co.uk] > *Sent:* Monday, 13 June 2016 12:42 AM > *To:* Arash Naderpour > *Cc:* Alexander Koeppe ; > address-policy-wg at ripe.net > *Subject:* Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: > IPv4 reserved space > > Not available ? > > Please name a global carrier that does not support IPv6. > > With Kind Regards, > > Dominik Nowacki > > Clouvider Limited is a limited company registered in England and > Wales. Registered number: 08750969 . Registered office: > 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that > Clouvider Limited may monitor email traffic data and also the content > of email for the purposes of security and staff training. This message > contains confidential information and is intended only for the > intended recipient. If you do not believe you are the intended > recipient you should not disseminate, distribute or copy this e-mail. > Please notify abuse at clouvider.net of this > e-mail immediately by e-mail if you have received this e-mail by > mistake and delete this e-mail from your system. E-mail transmission > cannot be guaranteed to be secure or error-free as information could > be intercepted, corrupted, lost, destroyed, arrive late or incomplete, > or contain viruses. Clouvider Limited nor any of its employees > therefore does not accept liability for any errors or omissions in the > contents of this message, which arise as a result of e-mail > transmission. If verification is required please request a hard-copy > version. > > > On 12 Jun 2016, at 16:40, Arash Naderpour > wrote: > > And I don't understand why some people think that everyone can > deploy IPv6, > it is simply not available everywhere. > It is not about difficulty, it is about possibility. > > Regards, > > Arash > > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Alexander Koeppe > Sent: Monday, 13 June 2016 12:09 AM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** > Re: IPv4 > reserved space > > I don't understand how much time and energy is being put into the > discussion > about keeping vintage IP alive. > This time and energy would be better off spent in just deploying v6. > It's just not that difficult. You just need to develop a stepwise > approach. > A one-shot would probably fail. > > -- Alex > > > > Am 11.06.2016 um 22:35 schrieb Gert Doering >: > > Hi, > > On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: > > About IPv6 - still now in Russia there are no Home ISPs > who gives > > IPv6 by default to customers. Nobody wants it, nobody > needs it. > > The "nobody needs it" is a misconception. Direct your energy > there to > > make people understand that IPv4 is game over. > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > > Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > This message and any attachment are confidential and may be > privileged or > otherwise protected from disclosure. If you are not the intended > recipient, > you must not copy this message or attachment or disclose the > contents to any > other person. If you have received this transmission in error, > please notify > the sender immediately and delete the message and any attachment > from your > system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries > do not > accept liability for any omissions or errors in this message which > may arise > as a result of E-Mail-transmission or for damages resulting from any > unauthorized changes of the content of this message and any attachment > thereto. Merck KGaA, Darmstadt, Germany and any of its > subsidiaries do not > guarantee that this message is free of viruses and does not accept > liability > for any damages caused by any virus transmitted therewith. > > > > Click http://www.merckgroup.com/disclaimer to access the German, > French, > Spanish and Portuguese versions of this disclaimer. > -- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Sun Jun 12 17:30:15 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 01:30:15 +1000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <575D7B5A.1020006@fotontel.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> Message-ID: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. As I said it is not about the difficulty of deploying IPv6, when it is not lawful and is not available to ISPs they have to stick with IPv4. Please refer to ripe ncc lab report and see some IPv4 import figures https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers Arash P.S last month they started advertising of the IPv6 blocks but no plan to provide a service to ISPs as yet. From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sergey Sent: Monday, 13 June 2016 1:10 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Global carriers provide that connectivity. What's the problem? On 06/12/16 18:08, Arash Naderpour wrote: I was not talking about a global carrier and if they can provide IPv6 or not, It was about availability and possibilities to have IPv6 connectivity everywhere. There are two different subject. Arash From: Dominik Nowacki [mailto:dominik at clouvider.co.uk] Sent: Monday, 13 June 2016 12:42 AM To: Arash Naderpour Cc: Alexander Koeppe ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Not available ? Please name a global carrier that does not support IPv6. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969 . Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 12 Jun 2016, at 16:40, Arash Naderpour > wrote: And I don't understand why some people think that everyone can deploy IPv6, it is simply not available everywhere. It is not about difficulty, it is about possibility. Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Alexander Koeppe Sent: Monday, 13 June 2016 12:09 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex Am 11.06.2016 um 22:35 schrieb Gert Doering >: Hi, On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 by default to customers. Nobody wants it, nobody needs it. The "nobody needs it" is a misconception. Direct your energy there to make people understand that IPv4 is game over. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -- Kind regards, CTO at Foton Telecom CJSC (ru.fotontelecom) Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at liopen.fr Sun Jun 12 17:56:22 2016 From: ripe at liopen.fr (Denis Fondras) Date: Sun, 12 Jun 2016 17:56:22 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> Message-ID: <20160612155622.GO16361@enforcer.ledeuns.net> > As an example in Iran there is only one exit point (AS12880 and AS48159 > belongs to one organization) from country to global carriers controlled by > government and as they have no LI platform yet on IPv6 there is simply no > IPv6 service availability or possibility for Iranian service providers. > You may talk to your exit points (and government if applicable) and tell them there is no IPv4 anymore and they have to enable IPv6 to allow you (and your country) to make business and grow. From silvia.hagen at sunny.ch Sun Jun 12 18:01:23 2016 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Sun, 12 Jun 2016 16:01:23 +0000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> Message-ID: Great idea. Doesn't Google also do that with not responsive, handy unfriendly websites? Silvia -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Jack Gesendet: Sonntag, 12. Juni 2016 16:35 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space On 12/06/2016 16:08, Alexander Koeppe wrote: > This time and energy would be better off spent in just deploying v6. Sure, but how ? The only valuable idea I fetched, if it is only possible, is to make a united RIR team (RIPE & ARIN, at least), and try to convince Google, Yahoo and microsoft to priorize v6-reachable web site (with a real priority), like google did for TLS, if I recall That would probably motive the hosting world in this issue, making v6-only ISP viable > It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. > > -- Alex > > >> Am 11.06.2016 um 22:35 schrieb Gert Doering : >> >> Hi, >> >>> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >>> About IPv6 - still now in Russia there are no Home ISPs who gives >>> IPv6 by default to customers. Nobody wants it, nobody needs it. >> >> The "nobody needs it" is a misconception. Direct your energy there >> to make people understand that IPv4 is game over. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> > > > This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. > > > > Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. > -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From noc at kwaoo.net Sun Jun 12 18:10:37 2016 From: noc at kwaoo.net (Jack) Date: Sun, 12 Jun 2016 18:10:37 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <20160612155622.GO16361@enforcer.ledeuns.net> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> <20160612155622.GO16361@enforcer.ledeuns.net> Message-ID: <4fed8ec8-fc8c-52ff-22b8-137b882402e1@kwaoo.net> Before talking about Iran, we may want to cleanup our area (RIPE's) According to https://www.google.fr/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption: 12% IPv6 in UK 11% in France 23% in Germany Work to do there; On 12/06/2016 17:56, Denis Fondras wrote: >> As an example in Iran there is only one exit point (AS12880 and AS48159 >> belongs to one organization) from country to global carriers controlled by >> government and as they have no LI platform yet on IPv6 there is simply no >> IPv6 service availability or possibility for Iranian service providers. >> > > You may talk to your exit points (and government if applicable) and tell them > there is no IPv4 anymore and they have to enable IPv6 to allow you (and your > country) to make business and grow. > -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From jim at rfc1035.com Sun Jun 12 18:15:10 2016 From: jim at rfc1035.com (Jim Reid) Date: Sun, 12 Jun 2016 17:15:10 +0100 Subject: [address-policy-wg] IPv6 connectivity in Iran In-Reply-To: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> Message-ID: > On 12 Jun 2016, at 16:30, Arash Naderpour wrote: > > As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. > > There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. Well that lack of IPv6 appears to be a major gap in the market and a worthwhile business opportunity with huge growth potential. So is the lack of an in-country IXP. IMO it?s up to the Iranian Internet community to tackle these issues and make the most of these business opporrtunities. It is probably inappropriate for this WG to discuss how to exploit these gaps. They can?t really be helped (or hindered) by RIPE address policy anyway. Mind you if anyone is minded to set up an IXP in Iran, they will have to move quickly if they need/want some IPv4 from the NCC for local interconnect and peering. PS: Apologies for a meaningful and relevant Subject: header. From Alexander.Koeppe at merckgroup.com Sun Jun 12 18:21:39 2016 From: Alexander.Koeppe at merckgroup.com (Alexander Koeppe) Date: Sun, 12 Jun 2016 16:21:39 +0000 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru>,<024c01d1c4bf$5560f430$0022dc90$@parsun.com> Message-ID: Of course strongly governmentally controlled countries (governments use to have less people understanding how the internet works) doesn't make that easier. And as you pointed out, a few seem to understand. But because transit is lacking v6 at the moment, that cannot be the reason not making up the network for dual stack. One day the few voices in become more and the transit issue will be gone, and you're just a few steps away setting your services to production. Von meinem iPhone gesendet Am 12.06.2016 um 17:30 schrieb Arash Naderpour >: As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. As I said it is not about the difficulty of deploying IPv6, when it is not lawful and is not available to ISPs they have to stick with IPv4. Please refer to ripe ncc lab report and see some IPv4 import figures https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers Arash P.S last month they started advertising of the IPv6 blocks but no plan to provide a service to ISPs as yet. From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sergey Sent: Monday, 13 June 2016 1:10 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Global carriers provide that connectivity. What's the problem? On 06/12/16 18:08, Arash Naderpour wrote: I was not talking about a global carrier and if they can provide IPv6 or not, It was about availability and possibilities to have IPv6 connectivity everywhere. There are two different subject. Arash From: Dominik Nowacki [mailto:dominik at clouvider.co.uk] Sent: Monday, 13 June 2016 12:42 AM To: Arash Naderpour Cc: Alexander Koeppe ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Not available ? Please name a global carrier that does not support IPv6. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 12 Jun 2016, at 16:40, Arash Naderpour > wrote: And I don't understand why some people think that everyone can deploy IPv6, it is simply not available everywhere. It is not about difficulty, it is about possibility. Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Alexander Koeppe Sent: Monday, 13 June 2016 12:09 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex Am 11.06.2016 um 22:35 schrieb Gert Doering >: Hi, On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 by default to customers. Nobody wants it, nobody needs it. The "nobody needs it" is a misconception. Direct your energy there to make people understand that IPv4 is game over. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -- Kind regards, CTO at Foton Telecom CJSC (ru.fotontelecom) Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB, Qrator, BGP.HE.NET http://ipv6actnow.org/ This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sun Jun 12 19:42:07 2016 From: gert at space.net (Gert Doering) Date: Sun, 12 Jun 2016 19:42:07 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <023501d1c4b8$4e804230$eb80c690$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> Message-ID: <20160612174207.GO79185@Space.Net> Hi, On Mon, Jun 13, 2016 at 12:39:59AM +1000, Arash Naderpour wrote: > And I don't understand why some people think that everyone can deploy IPv6, > it is simply not available everywhere. > It is not about difficulty, it is about possibility. Work with your regulator to *make* it possible - like the rest of the world has. It might take a while, but "not doing anything and complaining that IPv4 has run out" is not the right approach. (You *should* have started to work with your regulator 10+ years ago, it's not like this is coming as a surprise) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From leo.vegoda at icann.org Sun Jun 12 21:53:47 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 12 Jun 2016 19:53:47 +0000 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> Message-ID: NTX NOC wrote: [...] > I would like to ask a question what do people think about other > side of IPv4 numeration space. Because we have in IPv4 a lot of > addresses not in use at all but that space could be easy used. > > 240.0.0.0/4 Reserved (former Class E network) RFC 1700 > > it's 16 */8 networks. More then 256 Millions of routable and never > used IPv4. 185/8 network has about 6.4M free and total RIPE has > about 15M free IPv4 and we all say 185/8 will be enough for 2-3 > years and rest - for some more time. But 256 M Ipv4 space could > be enough for years! > > Space reserved for future Use. But will the future come to us or not? > > https://en.wikipedia.org/wiki/IPv4 > https://tools.ietf.org/html/rfc1700 > > Is far as I see routers could easy start to use that IP space. People > spend a lot of time and money to get some IPs but not to ask IANA to > allow use this space. Technically it's very easy to start use IPs from > such ranges. > > What does community thinks about it? There are two I-Ds on this specific issue from 2008: https://tools.ietf.org/html/draft-fuller-240space-02 https://tools.ietf.org/html/draft-wilson-class-e-02 I believe progress on them stopped because the cost/benefit analysis meant it made much more sense to deploy IPv6. On the broader issue, decisions on what is and is not unicast IPv4 address space are made in the IETF. If you do want to head down this road, I suggest that you do so by writing an I-D and getting discussion on it in the IETF. The RFC Editor has a page, with appropriate links, on the process, here: https://www.rfc-editor.org/pubprocess/ Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From ripe-wgs at radu-adrian.feurdean.net Sun Jun 12 22:26:08 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 12 Jun 2016 22:26:08 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> Message-ID: <1465763168.194190.635448369.7790F6A3@webmail.messagingengine.com> On Sun, Jun 12, 2016, at 16:44, Jack wrote: > But today, you fixed them, whatever they were (hardware ? network design > ? you worked on this issue) You just failed to mention the 2 most important: - management - money Unless you manage to bring in money by using IPv6 and *NOT* IPv4, it remains either a "submarine project" or an explicit NO-GO. For me, I'm pretty happy to get to the point where I am : services started "from scratch" during the last 3 years are IPv6 "active by default" (unless the client decides to go IPv6-only). I may even get a chance to go beyond the "one-man show" and convince the rest of the operations-team to think IPv6 (en enforce it wherever possible). But the problem remains with the money-making services, which is basically "IPv4-based access" (a.k.a. no IPv4 = no money in). A state where "no IPv6 = no money in" seems to be light-years away. If I want to keep deploying IPv6 I *must* be effective enough so that it doesn't "take up valuable work time" (read time spent on v4-ony stuff). > So, the problem is gone by now. ???? (see above) So yes, some people may have explicit no-go for IPv6 deployment. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Sun Jun 12 22:42:34 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 12 Jun 2016 22:42:34 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <20160612155622.GO16361@enforcer.ledeuns.net> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> <20160612155622.GO16361@enforcer.ledeuns.net> Message-ID: <1465764154.197198.635460585.6A43532D@webmail.messagingengine.com> On Sun, Jun 12, 2016, at 17:56, Denis Fondras wrote: > You may talk to your exit points (and government if applicable) and tell them > there is no IPv4 anymore and they have to enable IPv6 to allow you (and your > country) to make business and grow. You may also ask the french fiscal administration to have their on-line declaration website dual-stacked. But you do know things don't work this way. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Sun Jun 12 22:54:21 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 12 Jun 2016 22:54:21 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <20160612174207.GO79185@Space.Net> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <20160612174207.GO79185@Space.Net> Message-ID: <1465764861.200048.635468249.2A2AD14C@webmail.messagingengine.com> On Sun, Jun 12, 2016, at 19:42, Gert Doering wrote: > Work with your regulator to *make* it possible - like the rest of the world has. I don't think that we (most people on this list) have IPv6 because the local regulator allowed us to. On the contrary, I think *our* regulator doesn't care very much (if at all) about this - it just doesn't force us to use IPv4 (like some others do). There are more than 50 regulators in the RIPE area, and not all of them do a job the we could consider "good". -- Radu-Adrian FEURDEAN fr.ccs From drc at virtualized.org Sun Jun 12 23:22:31 2016 From: drc at virtualized.org (David Conrad) Date: Sun, 12 Jun 2016 14:22:31 -0700 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <1465763168.194190.635448369.7790F6A3@webmail.messagingengine.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <1465763168.194190.635448369.7790F6A3@webmail.messagingengine.com> Message-ID: <085777E1-6CA4-4DBD-8017-E5EF35A7F122@virtualized.org> Radu-Adrian, On Jun 12, 2016, at 1:26 PM, Radu-Adrian FEURDEAN wrote: > Unless you manage to bring in money by using IPv6 and *NOT* IPv4, it > remains either a "submarine project" or an explicit NO-GO. In most businesses, there are two (non-exclusive) ways to get traction on doing pretty much anything: 1) it generates more revenue. 2) it reduces costs. It is and always has been a bit unlikely that IPv6 will ever generate more revenue -- the vast majority of customers do not and should not care about something as esoteric as the particular bit layouts at an intermediate layer of the network. As such, you're left with #2. Until relatively recently, it was difficult to make the case for #2, however one nice thing about markets is that they can provide explicit signals that help businesses decide. While there were free pools, the RIR system masked those signals, ironically making it harder for businesses to see the need to migrate to IPv6. We've mostly solved that problem, and the spot price for obtaining IPv4 addresses and/or the costs associated with CGN are now a direct and obvious cost network service providers will need to account for and (likely) pass on to their customers. My view is that forward-looking network service providers will likely try to reduce those costs by minimizing the use of IPv4 where possible, migrating their internal infrastructure to IPv6 and selling a native IPv6/CGN'd IPv4 solution by default, having non-CGN'd IPv4 as an extra cost option (at least for new customers and increasingly, old customers when their contracts renew). Now that most ISP network gear supports IPv6, the first part of that would make sense regardless of the regulatory environment. Regards, -drc (speaking only for myself) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jordi.palet at consulintel.es Sun Jun 12 23:34:47 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 12 Jun 2016 23:34:47 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> Message-ID: <476AC2D4-4FB0-490C-A19F-AECC4B669CCD@consulintel.es> How we could help the government and their organizations to: 1) Understand the need 2) Deploy it at their organizations If you have the right contacts, I will be happy to help. Regards, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Arash Naderpour Responder a: Fecha: domingo, 12 de junio de 2016, 17:30 Para: 'Sergey' , Asunto: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space >As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. > >There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. > >As I said it is not about the difficulty of deploying IPv6, when it is not lawful and is not available to ISPs they have to stick with IPv4. Please refer to ripe ncc lab report and see some IPv4 import figures https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers > >Arash > >P.S last month they started advertising of the IPv6 blocks but no plan to provide a service to ISPs as yet. > >From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sergey >Sent: Monday, 13 June 2016 1:10 AM >To: address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space > > > >Global carriers provide that connectivity. What's the problem? >On 06/12/16 18:08, Arash Naderpour wrote: > > >I was not talking about a global carrier and if they can provide IPv6 or not, It was about availability and possibilities to have IPv6 connectivity everywhere. There are two different subject. > >Arash > >From: Dominik Nowacki [mailto:dominik at clouvider.co.uk] >Sent: Monday, 13 June 2016 12:42 AM >To: Arash Naderpour >Cc: Alexander Koeppe ; address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space > > > >Not available ? > > > >Please name a global carrier that does not support IPv6. >With Kind Regards, > >Dominik Nowacki > >Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969 . Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. > > >On 12 Jun 2016, at 16:40, Arash Naderpour wrote: > >And I don't understand why some people think that everyone can deploy IPv6, >it is simply not available everywhere. >It is not about difficulty, it is about possibility. > >Regards, > >Arash > > >-----Original Message----- >From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On >Behalf Of Alexander Koeppe >Sent: Monday, 13 June 2016 12:09 AM >To: address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 >reserved space > >I don't understand how much time and energy is being put into the discussion >about keeping vintage IP alive. >This time and energy would be better off spent in just deploying v6. >It's just not that difficult. You just need to develop a stepwise approach. >A one-shot would probably fail. > >-- Alex > > > > > > >Am 11.06.2016 um 22:35 schrieb Gert Doering : > > > >Hi, > > > >On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: > >About IPv6 - still now in Russia there are no Home ISPs who gives > >IPv6 by default to customers. Nobody wants it, nobody needs it. > > > >The "nobody needs it" is a misconception. Direct your energy there to > >make people understand that IPv4 is game over. > > > >Gert Doering > > -- NetMaster > >-- > >have you enabled IPv6 on something today...? > > > >SpaceNet AG Vorstand: Sebastian v. Bomhard > >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > > >Grundner-Culemann > > > > >D-80807 Muenchen HRB: 136055 (AG Muenchen) > >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > >This message and any attachment are confidential and may be privileged or >otherwise protected from disclosure. If you are not the intended recipient, >you must not copy this message or attachment or disclose the contents to any >other person. If you have received this transmission in error, please notify >the sender immediately and delete the message and any attachment from your >system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not >accept liability for any omissions or errors in this message which may arise >as a result of E-Mail-transmission or for damages resulting from any >unauthorized changes of the content of this message and any attachment >thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not >guarantee that this message is free of viruses and does not accept liability >for any damages caused by any virus transmitted therewith. > > > >Click http://www.merckgroup.com/disclaimer to access the German, French, >Spanish and Portuguese versions of this disclaimer. > > > > > > > > > >-- >Kind regards, >CTO at >Foton Telecom CJSC (ru.fotontelecom) >Tel.: +7 (499) 679-99-99 >AS42861 on PeeringDB , Qrator , BGP.HE.NET > >http://ipv6actnow.org/ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Sun Jun 12 23:40:10 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 12 Jun 2016 23:40:10 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <20160612155622.GO16361@enforcer.ledeuns.net> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> <20160612155622.GO16361@enforcer.ledeuns.net> Message-ID: <26728BDA-9E88-477A-BEE7-39293579D564@consulintel.es> In the worst case, you could also setup a tunnel to another upstream provider, even with BGP, such as HE. It may be not optimal, but better than having not IPv6 at all, right ? Regards, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Denis Fondras Responder a: Fecha: domingo, 12 de junio de 2016, 17:56 Para: Asunto: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space >> As an example in Iran there is only one exit point (AS12880 and AS48159 >> belongs to one organization) from country to global carriers controlled by >> government and as they have no LI platform yet on IPv6 there is simply no >> IPv6 service availability or possibility for Iranian service providers. >> > >You may talk to your exit points (and government if applicable) and tell them >there is no IPv4 anymore and they have to enable IPv6 to allow you (and your >country) to make business and grow. > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From arash_mpc at parsun.com Mon Jun 13 02:27:05 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 10:27:05 +1000 Subject: [address-policy-wg] IPv6 deployment Message-ID: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> The point is that not all countries are the same when it comes to rules , some regulatory or government organizations may force ISPs in some area to stick with IPv4, as they simply don't have IPv6 ready LI platforms. I'm sure that there are some plans to deploy IPv6 in all countries soon or later it would be done (even Iran has a v6 road map), but telling others to go and deploy IPv6 (or it is not difficult to deploy) does not change the fact that there are more limitations out there. anyway, thanks for your thoughtful advises. Regards, Arash P.S even in Australia the biggest service provider (Telstra) is not providing IPv6 service to residential customers as of today, -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Monday, 13 June 2016 3:42 AM To: Arash Naderpour Cc: 'Alexander Koeppe' ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Hi, On Mon, Jun 13, 2016 at 12:39:59AM +1000, Arash Naderpour wrote: > And I don't understand why some people think that everyone can deploy > IPv6, it is simply not available everywhere. > It is not about difficulty, it is about possibility. Work with your regulator to *make* it possible - like the rest of the world has. It might take a while, but "not doing anything and complaining that IPv4 has run out" is not the right approach. (You *should* have started to work with your regulator 10+ years ago, it's not like this is coming as a surprise) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From gforgx at fotontel.ru Mon Jun 13 02:31:30 2016 From: gforgx at fotontel.ru (Sergey) Date: Mon, 13 Jun 2016 03:31:30 +0300 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> References: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> Message-ID: <069D0F6E-A8EC-4FD6-8FC6-DCAC0ED4424D@fotontel.ru> But you have already been pointed at using, e. g., HE's BGP-enabled tunnel service. What's the problem with using it and deploying IPv6 on your own network? 13 ???? 2016 ?. 3:27:05 GMT+03:00, Arash Naderpour ?????: >The point is that not all countries are the same when it comes to rules >, >some regulatory or government organizations may force ISPs in some area >to >stick with IPv4, as they simply don't have IPv6 ready LI platforms. > >I'm sure that there are some plans to deploy IPv6 in all countries soon >or >later it would be done (even Iran has a v6 road map), but telling >others to >go and deploy IPv6 (or it is not difficult to deploy) does not change >the >fact that there are more limitations out there. > >anyway, thanks for your thoughtful advises. > >Regards, > >Arash > >P.S even in Australia the biggest service provider (Telstra) is not >providing IPv6 service to residential customers as of today, > > > >-----Original Message----- >From: Gert Doering [mailto:gert at space.net] >Sent: Monday, 13 June 2016 3:42 AM >To: Arash Naderpour >Cc: 'Alexander Koeppe' ; >address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: >IPv4 >reserved space > >Hi, > >On Mon, Jun 13, 2016 at 12:39:59AM +1000, Arash Naderpour wrote: >> And I don't understand why some people think that everyone can deploy > >> IPv6, it is simply not available everywhere. >> It is not about difficulty, it is about possibility. > >Work with your regulator to *make* it possible - like the rest of the >world >has. It might take a while, but "not doing anything and complaining >that >IPv4 has run out" is not the right approach. > >(You *should* have started to work with your regulator 10+ years ago, >it's >not like this is coming as a surprise) > >Gert Doering > -- NetMaster >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- ???????? ?? ?????????, ??????? ? K-9 Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Mon Jun 13 02:36:14 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 10:36:14 +1000 Subject: [address-policy-wg] IPv6 deployment Message-ID: <004201d1c50b$998b9970$cca2cc50$@parsun.com> Hi Jim, Agree here with you, this is not appropriate to discuss how to exploit the existing gaps here in APWG, I was just trying to explain that technical difficulties are not the only reason IPv6 is not deployed everywhere. It should be first be available and possible (from legal point of view) to deploy it which is not yet in all area. Regards, Arash Naderpour -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: Monday, 13 June 2016 2:15 AM To: Arash Naderpour Cc: RIPE Address Policy WG List Subject: IPv6 connectivity in Iran > On 12 Jun 2016, at 16:30, Arash Naderpour wrote: > > As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. > > There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. Well that lack of IPv6 appears to be a major gap in the market and a worthwhile business opportunity with huge growth potential. So is the lack of an in-country IXP. IMO it?s up to the Iranian Internet community to tackle these issues and make the most of these business opporrtunities. It is probably inappropriate for this WG to discuss how to exploit these gaps. They can?t really be helped (or hindered) by RIPE address policy anyway. Mind you if anyone is minded to set up an IXP in Iran, they will have to move quickly if they need/want some IPv4 from the NCC for local interconnect and peering. PS: Apologies for a meaningful and relevant Subject: header. From jordi.palet at consulintel.es Mon Jun 13 02:39:11 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 12 Jun 2016 19:39:11 -0500 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> References: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> Message-ID: I think we understand that, but we can help the government and regulator to deploy and even mandate IPv6 for public administration, etc. I?ve quite good experience on this in many countries. And that includes LI (Lawful Interception) support for that, of course. Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Arash Naderpour Responder a: Fecha: domingo, 12 de junio de 2016, 19:27 Para: 'Gert Doering' CC: Asunto: Re: [address-policy-wg] IPv6 deployment >The point is that not all countries are the same when it comes to rules , >some regulatory or government organizations may force ISPs in some area to >stick with IPv4, as they simply don't have IPv6 ready LI platforms. > >I'm sure that there are some plans to deploy IPv6 in all countries soon or >later it would be done (even Iran has a v6 road map), but telling others to >go and deploy IPv6 (or it is not difficult to deploy) does not change the >fact that there are more limitations out there. > >anyway, thanks for your thoughtful advises. > >Regards, > >Arash > >P.S even in Australia the biggest service provider (Telstra) is not >providing IPv6 service to residential customers as of today, > > > >-----Original Message----- >From: Gert Doering [mailto:gert at space.net] >Sent: Monday, 13 June 2016 3:42 AM >To: Arash Naderpour >Cc: 'Alexander Koeppe' ; >address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 >reserved space > >Hi, > >On Mon, Jun 13, 2016 at 12:39:59AM +1000, Arash Naderpour wrote: >> And I don't understand why some people think that everyone can deploy >> IPv6, it is simply not available everywhere. >> It is not about difficulty, it is about possibility. > >Work with your regulator to *make* it possible - like the rest of the world >has. It might take a while, but "not doing anything and complaining that >IPv4 has run out" is not the right approach. > >(You *should* have started to work with your regulator 10+ years ago, it's >not like this is coming as a surprise) > >Gert Doering > -- NetMaster >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Mon Jun 13 02:40:59 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 12 Jun 2016 19:40:59 -0500 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <004201d1c50b$998b9970$cca2cc50$@parsun.com> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> Message-ID: <362CCB7D-483D-4A41-9200-9A3736E00CA4@consulintel.es> I don?t think the regulator is forbidding using a 6in4 tunnel because LI regulation, otherwise, they will not allow any kind of VPN, etc? Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Arash Naderpour Responder a: Fecha: domingo, 12 de junio de 2016, 19:36 Para: 'Jim Reid' CC: 'RIPE Address Policy WG List' Asunto: Re: [address-policy-wg] IPv6 deployment >Hi Jim, > >Agree here with you, this is not appropriate to discuss how to exploit the existing gaps here in APWG, I was just trying to explain that technical difficulties are not the only reason IPv6 is not deployed everywhere. It should be first be available and possible (from legal point of view) to deploy it which is not yet in all area. > >Regards, > >Arash Naderpour > >-----Original Message----- >From: Jim Reid [mailto:jim at rfc1035.com] >Sent: Monday, 13 June 2016 2:15 AM >To: Arash Naderpour >Cc: RIPE Address Policy WG List >Subject: IPv6 connectivity in Iran > > >> On 12 Jun 2016, at 16:30, Arash Naderpour wrote: >> >> As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. >> >> There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. > >Well that lack of IPv6 appears to be a major gap in the market and a worthwhile business opportunity with huge growth potential. So is the lack of an in-country IXP. IMO it?s up to the Iranian Internet community to tackle these issues and make the most of these business opporrtunities. It is probably inappropriate for this WG to discuss how to exploit these gaps. They can?t really be helped (or hindered) by RIPE address policy anyway. Mind you if anyone is minded to set up an IXP in Iran, they will have to move quickly if they need/want some IPv4 from the NCC for local interconnect and peering. > >PS: Apologies for a meaningful and relevant Subject: header. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From arash_mpc at parsun.com Mon Jun 13 03:01:47 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 11:01:47 +1000 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <069D0F6E-A8EC-4FD6-8FC6-DCAC0ED4424D@fotontel.ru> References: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> <069D0F6E-A8EC-4FD6-8FC6-DCAC0ED4424D@fotontel.ru> Message-ID: <000a01d1c50f$2b5be8c0$8213ba40$@parsun.com> Hi, I have IPv6 deployed in my network since 2009 (I?m not in Iran). The problem of using a 6to4 service in Iran to provide service to end-users is that there would be no censorship or control by the government (LI = Lawful interception) and doing that is a crime in some countries. Arash From: Sergey [mailto:gforgx at fotontel.ru] Sent: Monday, 13 June 2016 10:32 AM To: Arash Naderpour ; 'Gert Doering' Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 deployment But you have already been pointed at using, e. g., HE's BGP-enabled tunnel service. What's the problem with using it and deploying IPv6 on your own network? 13 ???? 2016 ?. 3:27:05 GMT+03:00, Arash Naderpour > ?????: The point is that not all countries are the same when it comes to rules , some regulatory or government organizations may force ISPs in some area to stick with IPv4, as they simply don't have IPv6 ready LI platforms. I'm sure that there are some plans to deploy IPv6 in all countries soon or later it would be done (even Iran has a v6 road map), but telling others to go and deploy IPv6 (or it is not difficult to deploy) does not change the fact that there are more limitations out there. anyway, thanks for your thoughtful advises. Regards, Arash P.S even in Australia the biggest service provider (Telstra) is not providing IPv6 service to residential customers as of today, -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Monday, 13 June 2016 3:42 AM To: Arash Naderpour > Cc: 'Alexander Koeppe' >; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Hi, On Mon, Jun 13, 2016 at 12:39:59AM +1000, Arash Naderpour wrote: And I don't understand why some people think that everyone can deploy IPv6, it is simply not available everywhere. It is not about difficulty, it is about possibility. Work with your regulator to *make* it possible - like the rest of the world has. It might take a while, but "not doing anything and complaining that IPv4 has run out" is not the right approach. (You *should* have started to work with your regulator 10+ years ago, it's not like this is coming as a surprise) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- ???????? ?? ?????????, ??????? ? K-9 Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Mon Jun 13 09:54:43 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 13 Jun 2016 09:54:43 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <085777E1-6CA4-4DBD-8017-E5EF35A7F122@virtualized.org> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <1465763168.194190.635448369.7790F6A3@webmail.messagingengine.com> <085777E1-6CA4-4DBD-8017-E5EF35A7F122@virtualized.org> Message-ID: <1465804483.3864948.635780217.34E5ED33@webmail.messagingengine.com> On Sun, Jun 12, 2016, at 23:22, David Conrad wrote: > Radu-Adrian, > > On Jun 12, 2016, at 1:26 PM, Radu-Adrian FEURDEAN > wrote: > > Unless you manage to bring in money by using IPv6 and *NOT* IPv4, it > > remains either a "submarine project" or an explicit NO-GO. > > In most businesses, there are two (non-exclusive) ways to get traction on > doing pretty much anything: > > 1) it generates more revenue. > 2) it reduces costs. David, For the moment neither of those applies to IPv6 deployments. Cost reductions only applies to a limited number of players (those for which a 25% reduction in v4 traffic does end up in cost reduction, which implies a certain size). > more revenue -- the vast majority of customers do not and should not care > about something as esoteric as the particular bit layouts at an At some point, some categories of customers will have to start caring about this if we want to move forward. Especially those that need "port redirections to access the 2-3 devices in their office". > one nice thing about markets is that they can provide explicit signals > that help businesses decide. While there were free pools, the RIR system > masked those signals, ironically making it harder for businesses to see For the moment it's old big players that mask those signals : "$incumbent does provide us a /28 (or a /27). If you can't do the same, we will not buy the service from you". As long as this is only one random customer/prospect, you may be able to deal with it (let it stay with the incumbent or provide it the block needed). When you have lots of them, you have a problem. It's THEM that have to start caring about IPv6. > CGN are now a direct and obvious cost network service providers will need > to account for and (likely) pass on to their customers. When you go from ZERO to something (CGN-wise) you don't do any cost reduction. > migrating their internal infrastructure to IPv6 and selling a native > IPv6/CGN'd IPv4 solution by default, having non-CGN'd IPv4 as an extra > cost option (at least for new customers and increasingly, As explained above, as of today no IPv4 = no business. I am willing to wait for the things to change, but in the meantime it's IPv6 that is under life support (that I have to provide alone). > old customers when their contracts renew). Today, this is more painful for them than switching to another provider that does provide them with the needed IPv4 space. Those providers DO exist. > Now that most ISP network gear supports IPv6, the first part of that would > make sense regardless of the regulatory environment. This pretty much looks like "lab in production". usually it's not very well seen. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Mon Jun 13 10:20:16 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 13 Jun 2016 10:20:16 +0200 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <069D0F6E-A8EC-4FD6-8FC6-DCAC0ED4424D@fotontel.ru> References: <004101d1c50a$54053fb0$fc0fbf10$@parsun.com> <069D0F6E-A8EC-4FD6-8FC6-DCAC0ED4424D@fotontel.ru> Message-ID: <1465806016.3869409.635812705.05256781@webmail.messagingengine.com> On Mon, Jun 13, 2016, at 02:31, Sergey wrote: > What's the problem with using it and deploying IPv6 on your own network? My understanding is that his problem is "going to jail" if he does so. From ripe-wgs at radu-adrian.feurdean.net Mon Jun 13 10:25:07 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 13 Jun 2016 10:25:07 +0200 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <362CCB7D-483D-4A41-9200-9A3736E00CA4@consulintel.es> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> <362CCB7D-483D-4A41-9200-9A3736E00CA4@consulintel.es> Message-ID: <1465806307.3870061.635819721.73EF1A89@webmail.messagingengine.com> On Mon, Jun 13, 2016, at 02:40, JORDI PALET MARTINEZ wrote: > I don?t think the regulator is forbidding using a 6in4 tunnel because LI > regulation, otherwise, they will not allow any kind of VPN, etc? I don't think they do. But chasing 100 000 users running VPNs is not the same thing as chasing 10 ISPs providing VPN-like services (by default) to users. From nick at foobar.org Mon Jun 13 12:47:06 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 13 Jun 2016 11:47:06 +0100 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <004201d1c50b$998b9970$cca2cc50$@parsun.com> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> Message-ID: <575E8F2A.1090308@foobar.org> Arash Naderpour wrote: > Agree here with you, this is not appropriate to discuss how to > exploit the existing gaps here in APWG, I was just trying to explain > that technical difficulties are not the only reason IPv6 is not > deployed everywhere. It should be first be available and possible > (from legal point of view) to deploy it which is not yet in all > area. Arash, individually, people are probably sympathetic to the fact that companies and organisations in Iran are unable to deploy ipv6 for legal reasons. However, if the iranian government / regulatory authorities insist on shooting themselves in the foot by prohibiting ipv6, it's not the responsibility of the RIPE community to work around the damage that this causes. The IPv4 boat has sailed. It's now time to move on. Nick From arash_mpc at parsun.com Mon Jun 13 14:41:21 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 13 Jun 2016 22:41:21 +1000 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <575E8F2A.1090308@foobar.org> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> <575E8F2A.1090308@foobar.org> Message-ID: <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> Hi Nick, That was just an example to let community knows that it is not only technical difficulties preventing some areas sticking to IPv4, There are more countries out there (I can prepare a list if you are really interested) with similar or other type of non-technical limitations. RIPE Community does not belongs just to the ones who have possibility to deploy IPv6, (even if it is not the community responsibility to work around the damages some governments are causing) Regards, Arash -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Monday, 13 June 2016 8:47 PM To: Arash Naderpour Cc: 'Jim Reid' ; 'RIPE Address Policy WG List' Subject: Re: [address-policy-wg] IPv6 deployment Arash Naderpour wrote: > Agree here with you, this is not appropriate to discuss how to exploit > the existing gaps here in APWG, I was just trying to explain that > technical difficulties are not the only reason IPv6 is not deployed > everywhere. It should be first be available and possible (from legal > point of view) to deploy it which is not yet in all area. Arash, individually, people are probably sympathetic to the fact that companies and organisations in Iran are unable to deploy ipv6 for legal reasons. However, if the iranian government / regulatory authorities insist on shooting themselves in the foot by prohibiting ipv6, it's not the responsibility of the RIPE community to work around the damage that this causes. The IPv4 boat has sailed. It's now time to move on. Nick From swmike at swm.pp.se Mon Jun 13 14:44:31 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 13 Jun 2016 14:44:31 +0200 (CEST) Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> <575E8F2A.1090308@foobar.org> <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> Message-ID: On Mon, 13 Jun 2016, Arash Naderpour wrote: > Hi Nick, > > That was just an example to let community knows that it is not only > technical difficulties preventing some areas sticking to IPv4, There are > more countries out there (I can prepare a list if you are really > interested) with similar or other type of non-technical limitations. > > RIPE Community does not belongs just to the ones who have possibility to > deploy IPv6, (even if it is not the community responsibility to work > around the damages some governments are causing) Sure. There are lots of governments implementing all kinds of policies that make things worse for the general population in that country. Unfortunately, there is nothing RIPE can do to help these countries and their goverments, because RIPE doesn't have huge blocks of addresses to give out. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Mon Jun 13 14:58:33 2016 From: gert at space.net (Gert Doering) Date: Mon, 13 Jun 2016 14:58:33 +0200 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> <575E8F2A.1090308@foobar.org> <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> Message-ID: <20160613125833.GH79185@Space.Net> Hi, On Mon, Jun 13, 2016 at 10:41:21PM +1000, Arash Naderpour wrote: > There are more countries out there (I can prepare a list if you are really interested) with similar or other type of non-technical limitations. I am. In some cases ties exist to actually start working on these limitations. (And it helps understand the environment we all have to operate in) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nick at foobar.org Mon Jun 13 15:02:12 2016 From: nick at foobar.org (Nick Hilliard) Date: Mon, 13 Jun 2016 14:02:12 +0100 Subject: [address-policy-wg] IPv6 deployment In-Reply-To: <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> References: <004201d1c50b$998b9970$cca2cc50$@parsun.com> <575E8F2A.1090308@foobar.org> <00ad01d1c570$e5f67b80$b1e37280$@parsun.com> Message-ID: <575EAED4.50906@foobar.org> Arash Naderpour wrote: > That was just an example to let community knows that it is not only > technical difficulties preventing some areas sticking to IPv4, > There are more countries out there (I can prepare a list if you are > really interested) with similar or other type of non-technical > limitations. > > RIPE Community does not belongs just to the ones who have possibility > to deploy IPv6, (even if it is not the community responsibility to > work around the damages some governments are causing) Arash, what do you propose as a solution then? Nick From sylvain.vallerot at opdop.net Mon Jun 13 17:15:37 2016 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 13 Jun 2016 17:15:37 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <20160609094309.GD16361@enforcer.ledeuns.net> References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> <20160609094309.GD16361@enforcer.ledeuns.net> Message-ID: <575ECE19.805@opdop.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 09/06/2016 11:43, Denis Fondras wrote: > I fully agree with you but it seems some think that prefixes from last-/8 is not > intended to be used and distributed as we used to. Which I can comprehend, I agree with this : remaining IPs are not intended to be used as we used to. But they are still meant to be distributed to end users, aren't they ? Best regards, Sylvain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAldezhgACgkQJBGsD8mtnRGuaAEAm9Z8unbCXbXSIpw+9pxG2ce9 lBFdNK+hp572a3zmuIQA/1ibyaANpmeapUtLCmRp6ioSTt8YW5TbdQvQohM+D7NR =+T7o -----END PGP SIGNATURE----- From sylvain.vallerot at opdop.net Mon Jun 13 17:23:37 2016 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 13 Jun 2016 17:23:37 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> Message-ID: <575ECFF9.6020001@opdop.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, dear Jan, On 09/06/2016 17:23, Jan Ingvoldstad wrote: > In other words, it's fine for a LIR to be an end user, and in > principle, it seems sensible that policy acknowledges that, but > avoids making unnecessary limitations that interfere with that. I agree that a lot of LIRs are End Users. But the important point is that most End Users, however, are *not* LIRs which really means we cannot take the ones for the others. So, if the meaning of "last /8" policy is to let End Users have a minimal vital access to the ressource, then we must really write "End User" when we think "End User". Which leads to a very different wording (and meaning) of the policy that is to be obeyed by a LIR. Best regards, Sylvain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAldez/kACgkQJBGsD8mtnREZFgD+INALGOduxHzQ+4hX51fLXey8 3Ys5t8DDJNe448pWbK8A/i+Sfudir5dprT0LXKQSONFN9KYgond3sKSWW8Ki06pF =gta2 -----END PGP SIGNATURE----- From aled.w.morris at googlemail.com Mon Jun 13 17:29:41 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Mon, 13 Jun 2016 16:29:41 +0100 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: <575ECE19.805@opdop.net> References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> <20160609094309.GD16361@enforcer.ledeuns.net> <575ECE19.805@opdop.net> Message-ID: On 13 June 2016 at 16:15, Sylvain Vallerot wrote: > I agree with this : remaining IPs are not intended to be used as we used > to. > > But they are still meant to be distributed to end users, aren't they ? > RIPE-649 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Section 5.1 Allocations made by the RIPE NCC to LIRs ... 3. The LIR must confirm it will make assignment(s) from the allocation. ... It doesn't say who these assignments are to, they could be to the LIR itself for their own use (as it will be in the case of end-users who have become LIRs purely to obtain some "psuedo-PI" address space.) Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Mon Jun 13 17:40:52 2016 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 13 Jun 2016 17:40:52 +0200 Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) In-Reply-To: References: <573B0906.3060708@ripe.net> <57593110.7030007@opdop.net> <20160609094309.GD16361@enforcer.ledeuns.net> <575ECE19.805@opdop.net> Message-ID: <575ED404.4010004@opdop.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Aled, dear all, On 13/06/2016 17:29, Aled Morris wrote: > On 13 June 2016 at 16:15, Sylvain Vallerot > wrote: >> I agree with this : remaining IPs are not intended to be used as we used to. >> But they are still meant to be distributed to end users, aren't they ? > > RIPE-649 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" > Section 5.1 Allocations made by the RIPE NCC to LIRs > 3. The LIR must confirm it will make assignment(s) from the allocation. > ... > > It doesn't say who these assignments are to, they could be to the LIR > itself for their own use (as it will be in the case of end-users who > have become LIRs purely to obtain some "psuedo-PI" address space.) LIRs being (quite likely) End Users, this is fine. But we definitely cannot assume that all End Users are LIRs, nor make a policy take it for granted. Put in another words we cannot have a policy say that an End User needs to be a LIR to have a chance to get access to the ressource. Allowing future End Users to have a tiny bit of IPv4 to bootstrap means allowing *End Users*, not just those that are LIRs. Right ? I would appreciate a confirmation from the "sitting-ones" that my understanding of the spirit of the last /8 policy is correct on this point because I sometimes doubt it when reading things like proposal 2013-03. Best regards, Sylvain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlde1AMACgkQJBGsD8mtnRHH4gD/duowiNMLW8a1E1SRuYj3UgBK QczJw7sdCw4bGICrmvEA/AjXyqIkX0xBBxk91zTgbIbVvqsVlEaPBZ/F9bygbaki =ZT3L -----END PGP SIGNATURE----- From sander at steffann.nl Mon Jun 13 18:26:27 2016 From: sander at steffann.nl (Sander Steffann) Date: Mon, 13 Jun 2016 18:26:27 +0200 Subject: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space In-Reply-To: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> Message-ID: Hi Arash, > As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. If your government is making your work impossible there is little the rest of the world can do about it. The world is out of free IPv4 space. The space that is reserved is for new entrants that need a tiny bit to connect to the old IPv4-only world. The days of running networks on only IPv4 are over. Everybody needs more addresses, and IPv6 is the only protocol that can provide them, so everybody needs to move. Including your government. I am sorry. I understand that your personal/business situation sucks in regard to this, but your government is the only one who can fix this :( Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From noc at ntx.ru Mon Jun 13 19:04:07 2016 From: noc at ntx.ru (NTX NOC) Date: Mon, 13 Jun 2016 20:04:07 +0300 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <024c01d1c4bf$5560f430$0022dc90$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> Message-ID: <39bd5c47-04de-d5c6-f748-4c0395684a30@ntx.ru> Agree, Almost in Russia, very big country with a lot of ISPs - I can't find any big home ISP who gives IPv6 by default. Most of ISPs get there Ipv6 blocks and play with it. But it's not so good for customers. ISPs prefer still to get IPv4 blocks in additional to the space they have but not to switch to IPv6. IPv6 will grow very slow in additional with IPv4. So those protocols will live together for long-long time and we need to spend some time for IPv4 as well. Yuri On 12.06.2016 18:30, Arash Naderpour wrote: > As an example in Iran there is only one exit point (AS12880 and AS48159 > belongs to one organization) from country to global carriers controlled > by government and as they have no LI platform yet on IPv6 there is > simply no IPv6 service availability or possibility for Iranian service > providers. > > > > There is no possibility to have a direct peering with a global carrier > and as a result no native IPv6 connectivity yet. there is also no IXP > in the country. > > > > As I said it is not about the difficulty of deploying IPv6, when it is > not lawful and is not available to ISPs they have to stick with IPv4. > Please refer to ripe ncc lab report and see some IPv4 import figures > https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers > > > > Arash > > P.S last month they started advertising of the IPv6 blocks but no plan > to provide a service to ISPs as yet. > > > > *From:*address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *On > Behalf Of *Sergey > *Sent:* Monday, 13 June 2016 1:10 AM > *To:* address-policy-wg at ripe.net > *Subject:* Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: > IPv4 reserved space > > > > Global carriers provide that connectivity. What's the problem? > > On 06/12/16 18:08, Arash Naderpour wrote: > > I was not talking about a global carrier and if they can provide > IPv6 or not, It was about availability and possibilities to have > IPv6 connectivity everywhere. There are two different subject. > > > > Arash > > > > *From:*Dominik Nowacki [mailto:dominik at clouvider.co.uk] > *Sent:* Monday, 13 June 2016 12:42 AM > *To:* Arash Naderpour > > *Cc:* Alexander Koeppe > ; address-policy-wg at ripe.net > > *Subject:* Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** > Re: IPv4 reserved space > > > > Not available ? > > > > Please name a global carrier that does not support IPv6. > > With Kind Regards, > > Dominik Nowacki > > Clouvider Limited is a limited company registered in England and > Wales. Registered number: 08750969 . Registered > office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please > note that Clouvider Limited may monitor email traffic data and also > the content of email for the purposes of security and staff > training. This message contains confidential information and is > intended only for the intended recipient. If you do not believe you > are the intended recipient you should not disseminate, distribute or > copy this e-mail. Please notify abuse at clouvider.net > of this e-mail immediately by e-mail if > you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure > or error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. Clouvider > Limited nor any of its employees therefore does not accept liability > for any errors or omissions in the contents of this message, which > arise as a result of e-mail transmission. If verification is > required please request a hard-copy version. > > > On 12 Jun 2016, at 16:40, Arash Naderpour > wrote: > > And I don't understand why some people think that everyone can > deploy IPv6, > it is simply not available everywhere. > It is not about difficulty, it is about possibility. > > Regards, > > Arash > > > -----Original Message----- > From: address-policy-wg > [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Alexander Koeppe > Sent: Monday, 13 June 2016 12:09 AM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** > Re: IPv4 > reserved space > > I don't understand how much time and energy is being put into > the discussion > about keeping vintage IP alive. > This time and energy would be better off spent in just deploying v6. > It's just not that difficult. You just need to develop a > stepwise approach. > A one-shot would probably fail. > > -- Alex > > > > > Am 11.06.2016 um 22:35 schrieb Gert Doering >: > > > > Hi, > > > > On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: > > About IPv6 - still now in Russia there are no Home ISPs > who gives > > IPv6 by default to customers. Nobody wants it, nobody > needs it. > > > > The "nobody needs it" is a misconception. Direct your > energy there to > > make people understand that IPv4 is game over. > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. > Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > > Grundner-Culemann > > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > This message and any attachment are confidential and may be > privileged or > otherwise protected from disclosure. If you are not the intended > recipient, > you must not copy this message or attachment or disclose the > contents to any > other person. If you have received this transmission in error, > please notify > the sender immediately and delete the message and any attachment > from your > system. Merck KGaA, Darmstadt, Germany and any of its > subsidiaries do not > accept liability for any omissions or errors in this message > which may arise > as a result of E-Mail-transmission or for damages resulting from any > unauthorized changes of the content of this message and any > attachment > thereto. Merck KGaA, Darmstadt, Germany and any of its > subsidiaries do not > guarantee that this message is free of viruses and does not > accept liability > for any damages caused by any virus transmitted therewith. > > > > Click http://www.merckgroup.com/disclaimer to access the German, > French, > Spanish and Portuguese versions of this disclaimer. > > > > > -- > Kind regards, > CTO at > *Foton Telecom CJSC (ru.fotontelecom)* > Tel.: +7 (499) 679-99-99 > AS42861 on PeeringDB , Qrator > , BGP.HE.NET > > http://ipv6actnow.org/ > From noc at ntx.ru Mon Jun 13 19:09:50 2016 From: noc at ntx.ru (NTX NOC) Date: Mon, 13 Jun 2016 20:09:50 +0300 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <575C67A6.8020702@fotontel.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> Message-ID: <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> Not correct. My opinion is that all IPs space should be completely free for all members. It's like letters in the alphabet. You should not pay for letters, you should not pay for your unique name+surname (symbols that allow to identify you like IP address numbers). So to allow progress to come in we need to use abilities, that we have, reasonably. And here I asked about reserved IPv4 space. I am here in this discussions because we try to help people to get IP space easy and faster. And I am show here that there a lot of space that could be used. Yuri On 11.06.2016 22:33, Sergey wrote: > Agree with Mikael. This is not a provocative question, but are NTX so > worried about this proposal because it would affect their businesses > selling and leasing IPv4 space? Their webpage mentions it at the top. > > The IP addresses aren't here to sell them. They're to be routed and > used. This is just a tool. The IPv6 deployment is the only solution. From david.ponzone at ipeva.fr Mon Jun 13 19:17:10 2016 From: david.ponzone at ipeva.fr (David Ponzone) Date: Mon, 13 Jun 2016 19:17:10 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> Message-ID: When a resource is scarce, either you define a high-enough price (GSM frequencies for instance) or you enforce a policy on how it's used. The issue is that even if you free 2 or 3 /8 from 240/4 or DoD, that's still a scarce resource, given the current growth and the forthcoming IoT invasion. David Ponzone > Le 13 juin 2016 ? 19:09, NTX NOC a ?crit : > > Not correct. My opinion is that all IPs space should be completely free > for all members. It's like letters in the alphabet. You should not pay > for letters, you should not pay for your unique name+surname (symbols > that allow to identify you like IP address numbers). > > So to allow progress to come in we need to use abilities, that we have, > reasonably. And here I asked about reserved IPv4 space. > > I am here in this discussions because we try to help people to get IP > space easy and faster. And I am show here that there a lot of space that > could be used. > > Yuri > >> On 11.06.2016 22:33, Sergey wrote: >> Agree with Mikael. This is not a provocative question, but are NTX so >> worried about this proposal because it would affect their businesses >> selling and leasing IPv4 space? Their webpage mentions it at the top. >> >> The IP addresses aren't here to sell them. They're to be routed and >> used. This is just a tool. The IPv6 deployment is the only solution. > > > > *********************************************************************************************************** > Le service MailSecure d'IPeva confirme l'absence de virus et de spam dans ce message. > *********************************************************************************************************** > > From gert at space.net Mon Jun 13 19:52:33 2016 From: gert at space.net (Gert Doering) Date: Mon, 13 Jun 2016 19:52:33 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> Message-ID: <20160613175233.GM79185@Space.Net> Hi, On Mon, Jun 13, 2016 at 08:09:50PM +0300, NTX NOC wrote: > And I am show here that there a lot of space that could be used. You did not listen to the answers that stated that it's - *not* "a lot of" space - and "it can *not* be used" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gforgx at fotontel.ru Mon Jun 13 19:56:27 2016 From: gforgx at fotontel.ru (Sergey) Date: Mon, 13 Jun 2016 20:56:27 +0300 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <39bd5c47-04de-d5c6-f748-4c0395684a30@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <1102955607.3531.1465677320069.JavaMail.totemomail@DE36S02AEGW01> <023501d1c4b8$4e804230$eb80c690$@parsun.com> <024301d1c4bc$4eb97dd0$ec2c7970$@parsun.com> <575D7B5A.1020006@fotontel.ru> <024c01d1c4bf$5560f430$0022dc90$@parsun.com> <39bd5c47-04de-d5c6-f748-4c0395684a30@ntx.ru> Message-ID: <575EF3CA.5010303@fotontel.ru> You have already been pointed at: https://version6.ru/isp. My, perhaps too optimistic prognosis, is that we'll have IPv6 as a mainstream IP protocol by 2018. The figures of the current growth make me believe in this. On 06/13/16 20:04, NTX NOC wrote: > Agree, > > Almost in Russia, very big country with a lot of ISPs - I can't find any > big home ISP who gives IPv6 by default. > Most of ISPs get there Ipv6 blocks and play with it. But it's not so > good for customers. ISPs prefer still to get IPv4 blocks in additional > to the space they have but not to switch to IPv6. > > IPv6 will grow very slow in additional with IPv4. > So those protocols will live together for long-long time and we need to > spend some time for IPv4 as well. > > > Yuri > > On 12.06.2016 18:30, Arash Naderpour wrote: >> As an example in Iran there is only one exit point (AS12880 and AS48159 >> belongs to one organization) from country to global carriers controlled >> by government and as they have no LI platform yet on IPv6 there is >> simply no IPv6 service availability or possibility for Iranian service >> providers. >> >> >> >> There is no possibility to have a direct peering with a global carrier >> and as a result no native IPv6 connectivity yet. there is also no IXP >> in the country. >> >> >> >> As I said it is not about the difficulty of deploying IPv6, when it is >> not lawful and is not available to ISPs they have to stick with IPv4. >> Please refer to ripe ncc lab report and see some IPv4 import figures >> https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers >> >> >> >> Arash >> >> P.S last month they started advertising of the IPv6 blocks but no plan >> to provide a service to ISPs as yet. >> >> >> >> *From:*address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *On >> Behalf Of *Sergey >> *Sent:* Monday, 13 June 2016 1:10 AM >> *To:* address-policy-wg at ripe.net >> *Subject:* Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: >> IPv4 reserved space >> >> >> >> Global carriers provide that connectivity. What's the problem? >> >> On 06/12/16 18:08, Arash Naderpour wrote: >> >> I was not talking about a global carrier and if they can provide >> IPv6 or not, It was about availability and possibilities to have >> IPv6 connectivity everywhere. There are two different subject. >> >> >> >> Arash >> >> >> >> *From:*Dominik Nowacki [mailto:dominik at clouvider.co.uk] >> *Sent:* Monday, 13 June 2016 12:42 AM >> *To:* Arash Naderpour >> >> *Cc:* Alexander Koeppe >> ; address-policy-wg at ripe.net >> >> *Subject:* Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** >> Re: IPv4 reserved space >> >> >> >> Not available ? >> >> >> >> Please name a global carrier that does not support IPv6. >> >> With Kind Regards, >> >> Dominik Nowacki >> >> Clouvider Limited is a limited company registered in England and >> Wales. Registered number: 08750969 . Registered >> office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please >> note that Clouvider Limited may monitor email traffic data and also >> the content of email for the purposes of security and staff >> training. This message contains confidential information and is >> intended only for the intended recipient. If you do not believe you >> are the intended recipient you should not disseminate, distribute or >> copy this e-mail. Please notify abuse at clouvider.net >> of this e-mail immediately by e-mail if >> you have received this e-mail by mistake and delete this e-mail from >> your system. E-mail transmission cannot be guaranteed to be secure >> or error-free as information could be intercepted, corrupted, lost, >> destroyed, arrive late or incomplete, or contain viruses. Clouvider >> Limited nor any of its employees therefore does not accept liability >> for any errors or omissions in the contents of this message, which >> arise as a result of e-mail transmission. If verification is >> required please request a hard-copy version. >> >> >> On 12 Jun 2016, at 16:40, Arash Naderpour > > wrote: >> >> And I don't understand why some people think that everyone can >> deploy IPv6, >> it is simply not available everywhere. >> It is not about difficulty, it is about possibility. >> >> Regards, >> >> Arash >> >> >> -----Original Message----- >> From: address-policy-wg >> [mailto:address-policy-wg-bounces at ripe.net] On >> Behalf Of Alexander Koeppe >> Sent: Monday, 13 June 2016 12:09 AM >> To: address-policy-wg at ripe.net >> Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** >> Re: IPv4 >> reserved space >> >> I don't understand how much time and energy is being put into >> the discussion >> about keeping vintage IP alive. >> This time and energy would be better off spent in just deploying v6. >> It's just not that difficult. You just need to develop a >> stepwise approach. >> A one-shot would probably fail. >> >> -- Alex >> >> >> >> >> Am 11.06.2016 um 22:35 schrieb Gert Doering > >: >> >> >> >> Hi, >> >> >> >> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >> >> About IPv6 - still now in Russia there are no Home ISPs >> who gives >> >> IPv6 by default to customers. Nobody wants it, nobody >> needs it. >> >> >> >> The "nobody needs it" is a misconception. Direct your >> energy there to >> >> make people understand that IPv4 is game over. >> >> >> >> Gert Doering >> >> -- NetMaster >> >> -- >> >> have you enabled IPv6 on something today...? >> >> >> >> SpaceNet AG Vorstand: Sebastian v. >> Bomhard >> >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> >> Grundner-Culemann >> >> >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> >> >> >> >> >> This message and any attachment are confidential and may be >> privileged or >> otherwise protected from disclosure. If you are not the intended >> recipient, >> you must not copy this message or attachment or disclose the >> contents to any >> other person. If you have received this transmission in error, >> please notify >> the sender immediately and delete the message and any attachment >> from your >> system. Merck KGaA, Darmstadt, Germany and any of its >> subsidiaries do not >> accept liability for any omissions or errors in this message >> which may arise >> as a result of E-Mail-transmission or for damages resulting from any >> unauthorized changes of the content of this message and any >> attachment >> thereto. Merck KGaA, Darmstadt, Germany and any of its >> subsidiaries do not >> guarantee that this message is free of viruses and does not >> accept liability >> for any damages caused by any virus transmitted therewith. >> >> >> >> Click http://www.merckgroup.com/disclaimer to access the German, >> French, >> Spanish and Portuguese versions of this disclaimer. >> >> >> >> >> -- >> Kind regards, >> CTO at >> *Foton Telecom CJSC (ru.fotontelecom)* >> Tel.: +7 (499) 679-99-99 >> AS42861 on PeeringDB , Qrator >> , BGP.HE.NET >> >> http://ipv6actnow.org/ >> -- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB , Qrator , BGP.HE.NET http://ipv6actnow.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Mon Jun 13 21:28:11 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 13 Jun 2016 21:28:11 +0200 (CEST) Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> Message-ID: On Mon, 13 Jun 2016, NTX NOC wrote: > Not correct. My opinion is that all IPs space should be completely free > for all members. It's like letters in the alphabet. You should not pay > for letters, you should not pay for your unique name+surname (symbols > that allow to identify you like IP address numbers). > > So to allow progress to come in we need to use abilities, that we have, > reasonably. And here I asked about reserved IPv4 space. > > I am here in this discussions because we try to help people to get IP > space easy and faster. And I am show here that there a lot of space that > could be used. Well, using 240/3 isn't something that realistic. It is a lot easier to deply IPv6 than to get 240/3 working for any significant amount of users. We have run out of "letters" to use. The answer to the problem with "we've run out of letters" is to deploy IPv6. It's unfortunate that ISPs in your market aren't interested in Ipv6 deployment, but it's the only answer to your question. -- Mikael Abrahamsson email: swmike at swm.pp.se From arash_mpc at parsun.com Tue Jun 14 03:55:12 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Tue, 14 Jun 2016 11:55:12 +1000 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> Message-ID: <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> >Well, using 240/3 isn't something that realistic. It is a lot easier to deply IPv6 than to get 240/3 working for any significant amount of users. Some may prefer easier ways (which is not that much easy to others) and some may not, My question is that is this working group the right place to discuss about the 240/3 or it should be done in higher level like between RIRs or IANA? Regards, Arash From michel at arneill-py.sacramento.ca.us Tue Jun 14 04:25:58 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 14 Jun 2016 02:25:58 +0000 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> Message-ID: > Arash Naderpour wrote : > My question is that is this working group the right place to discuss about the 240/3 > or it should be done in higher level like between RIRs or IANA? It has been done at higher levels multiple times in the last 15 years, and you are wasting your time and everyone else's. Broken record syndrome. Guys and girls, stop feeding the troll. Michel. From swmike at swm.pp.se Tue Jun 14 07:36:56 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 14 Jun 2016 07:36:56 +0200 (CEST) Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> Message-ID: On Tue, 14 Jun 2016, Arash Naderpour wrote: > My question is that is this working group the right place to discuss > about the 240/3 or it should be done in higher level like between RIRs > or IANA? You need to bring it to the IETF. IANA would most likely do what IETF asks it to do, and then the RIRs would follow suit. As was stated before (check out the link to the IETF draft, I'd imagine if you follow that trail you'll find discussions as well), the IETF took a look at this in 2008 or so, and it was deemed to be not practically feasible way of solving the problem. I'd say this hasn't changed. So most likely, if you go there and pitch the idea, you'll get the same reaction as you did here. -- Mikael Abrahamsson email: swmike at swm.pp.se From tore at fud.no Tue Jun 14 07:38:16 2016 From: tore at fud.no (Tore Anderson) Date: Tue, 14 Jun 2016 07:38:16 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> Message-ID: <20160614073816.0050f84d@echo.ms.redpill-linpro.com> Good morning Arash, * "Arash Naderpour" > My question is that is this working group the right place to discuss > about the 240/3 or it should be done in higher level like between > RIRs or IANA? RIPE AP-WG is not the right place to begin this process, the IETF is. The process would go something like this: You submit a draft to the IETF to direct IANA to do something with with 240/3, e.g., reclassify it as regular unicast IPv4 address space that may be distributed to the RIRs. You'll then need to gain consensus for your draft and have it published as an RFC. The /3 would then within six months be split up into five equal parts and be distributed to each RIR over a period of a few years. ~6.4 /8s per RIR, that is. The initial and biggest IANA->RIR trance would happen no later than six months after your RFC was published. (If you're not happy with that you'd need to seek global consensus between the five RIR communities to change the ?Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA??policy.) The RIPE NCC would add any address space received from the IANA in this manner to the so-called ?last /8? pool. So assuming you've already received your final /22 under the current policy but want one or more additional allocations from 240/3, you'll at this point need to return to the RIPE AP-WG with a proposal to change the so-called ?last /8? policy into something else that would facilitate that. Assuming you manage all of the above, all that remains in order to make 240/3 usable on the public Internet is to convince all the operating system/device/router vendors in the world to develop and release software/firmware updates to make 240/3 usable, and then of course to convince every network operator and end-user on the Internet to download and install these patches. Devices/software no longer being supported by the manufacturer would probably need to be replaced outright. If by some miracle you would be able to pull it all off, keep in mind that the ~107M addresses gained by the RIPE NCC would all be used up within two years if we return to the pre-depletion allocation policy and consumption rate. Ask yourself: ?then what?? Maybe you can now see why folks are telling you that this would be a colossal waste of time and that your efforts would be much better spent on IPv6. With IPv6, the process is already underway and most of the above steps have already been completed, and at the end of that process we're actually covered for the rest of our lifetimes and beyond. Tore From david.ponzone at ipeva.fr Tue Jun 14 08:31:23 2016 From: david.ponzone at ipeva.fr (David Ponzone) Date: Tue, 14 Jun 2016 08:31:23 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <20160614073816.0050f84d@echo.ms.redpill-linpro.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> <20160614073816.0050f84d@echo.ms.redpill-linpro.com> Message-ID: <8D867CD5-0C4D-4394-91D3-647EE9351EB0@ipeva.fr> But really, if you expect to be taken seriously, you should write your draft about 240/4, not 240/3 :) David Ponzone > Le 14 juin 2016 ? 07:38, Tore Anderson a ?crit : > > Good morning Arash, > > * "Arash Naderpour" > >> My question is that is this working group the right place to discuss >> about the 240/3 or it should be done in higher level like between >> RIRs or IANA? > > RIPE AP-WG is not the right place to begin this process, the IETF is. > > The process would go something like this: > > You submit a draft to the IETF to direct IANA to do something with with > 240/3, e.g., reclassify it as regular unicast IPv4 address space that > may be distributed to the RIRs. You'll then need to gain consensus for > your draft and have it published as an RFC. > > The /3 would then within six months be split up into five equal parts > and be distributed to each RIR over a period of a few years. ~6.4 /8s > per RIR, that is. The initial and biggest IANA->RIR trance would happen > no later than six months after your RFC was published. (If you're not > happy with that you'd need to seek global consensus between the five RIR > communities to change the ?Global Policy for Post Exhaustion IPv4 > Allocation Mechanisms by the IANA? policy.) > > The RIPE NCC would add any address space received from the IANA in this > manner to the so-called ?last /8? pool. So assuming you've already > received your final /22 under the current policy but want one or more > additional allocations from 240/3, you'll at this point need to return > to the RIPE AP-WG with a proposal to change the so-called ?last /8? > policy into something else that would facilitate that. > > Assuming you manage all of the above, all that remains in order to make > 240/3 usable on the public Internet is to convince all the operating > system/device/router vendors in the world to develop and release > software/firmware updates to make 240/3 usable, and then of course to > convince every network operator and end-user on the Internet to > download and install these patches. Devices/software no longer being > supported by the manufacturer would probably need to be replaced > outright. > > If by some miracle you would be able to pull it all off, keep in mind > that the ~107M addresses gained by the RIPE NCC would all be used up > within two years if we return to the pre-depletion allocation policy > and consumption rate. Ask yourself: ?then what?? > > Maybe you can now see why folks are telling you that this would be a > colossal waste of time and that your efforts would be much better spent > on IPv6. With IPv6, the process is already underway and most of the > above steps have already been completed, and at the end of that process > we're actually covered for the rest of our lifetimes and beyond. > > Tore > > > *********************************************************************************************************** > Le service MailSecure d'IPeva confirme l'absence de virus et de spam dans ce message. > *********************************************************************************************************** > > From swmike at swm.pp.se Tue Jun 14 08:34:45 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 14 Jun 2016 08:34:45 +0200 (CEST) Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <20160614073816.0050f84d@echo.ms.redpill-linpro.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> <20160614073816.0050f84d@echo.ms.redpill-linpro.com> Message-ID: On Tue, 14 Jun 2016, Tore Anderson wrote: > The /3 would then within six months be split up into five equal parts > and be distributed to each RIR over a period of a few years. ~6.4 /8s Well, it's only 16 /8s, so 3.2 /8s per RIR. Tore, great email summing up the problems with this proposal. -- Mikael Abrahamsson email: swmike at swm.pp.se From tore at fud.no Tue Jun 14 09:03:16 2016 From: tore at fud.no (Tore Anderson) Date: Tue, 14 Jun 2016 09:03:16 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> <20160614073816.0050f84d@echo.ms.redpill-linpro.com> Message-ID: <20160614090316.1d1e4d21@echo.ms.redpill-linpro.com> * Mikael Abrahamsson > On Tue, 14 Jun 2016, Tore Anderson wrote: > > > The /3 would then within six months be split up into five equal parts > > and be distributed to each RIR over a period of a few years. ~6.4 /8s > > Well, it's only 16 /8s, so 3.2 /8s per RIR. Nnngh. Thanks David and Mikael. (This is why you should never write e-mails while not under the influence of coffee, kids.) Anyway this part needs corrections (emphasised with **) too: > If by some miracle you would be able to pull it all off, keep in mind > that the **~54M** addresses gained by the RIPE NCC would all be used > up within **one year** if we return to the pre-depletion allocation > policy and consumption rate. Ask yourself: ?then what?? I'm assuming here an allocation rate of ~0.3 /8s per month, cf. https://labs.ripe.net/Members/wilhelm/global-patterns-in-ipv4-allocation-statistics Probably this estimate is way too low though, due to the unmet demand that has been building up in the LIRs over the course of the last four years. My guess is that we'd easily manage to fully deplete the first 240/4 IANA->RIR tranche (containing a /7) before the six months have passed before the second tranche (containing a /8) comes, and so on until the IANA recovered IPv4 pool is all gone. Tore From gert at space.net Tue Jun 14 09:36:38 2016 From: gert at space.net (Gert Doering) Date: Tue, 14 Jun 2016 09:36:38 +0200 Subject: [address-policy-wg] IPv4 reserved space In-Reply-To: <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> References: <40d4af1b-7e3b-0b6e-0e11-17fbf508a3e6@ntx.ru> <20160611185646.GQ31815@gir.theapt.org> <575C67A6.8020702@fotontel.ru> <83c83226-1541-b63d-7719-5728d7ce9132@ntx.ru> <015801d1c5df$d98ab4a0$8ca01de0$@parsun.com> Message-ID: <20160614073638.GP79185@Space.Net> Hi, On Tue, Jun 14, 2016 at 11:55:12AM +1000, Arash Naderpour wrote: > >Well, using 240/3 isn't something that realistic. It is a lot easier to > deply IPv6 than to get 240/3 working for any significant amount of users. > > Some may prefer easier ways (which is not that much easy to others) and some > may not, 240/3 is not going to be easy. *Every* device out there would need to be changed (or at least *checked*) to ensure that it understands that these addresse are not special and can be used as normal unicast space. I could imagine that LI equipment that does not handle IPv6 will not handle Class E space either... > My question is that is this working group the right place to discuss about > the 240/3 or it should be done in higher level like between RIRs or IANA? It has been said before that 240/3 needs to be designated as unicast address space in the IETF first, then IANA could distribute to the RIRs. Pointers to the relevant drafts have been given. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nick at foobar.org Tue Jun 14 11:22:48 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 14 Jun 2016 10:22:48 +0100 Subject: [address-policy-wg] Create FAQ? (was: Re: IPv4 reserved space) Message-ID: <575FCCE8.9090509@foobar.org> Tore Anderson wrote: > If by some miracle you would be able to pull it all off, keep in mind > that the ~107M addresses gained by the RIPE NCC would all be used up > within two years if we return to the pre-depletion allocation policy > and consumption rate. Ask yourself: ?then what?? > > Maybe you can now see why folks are telling you that this would be a > colossal waste of time APWG Chairs, Is there any possibility of creating a FAQ? There are a bunch of issues which are coming up repeatedly, of which this is one. Nick From sander at steffann.nl Tue Jun 14 12:09:10 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 14 Jun 2016 12:09:10 +0200 Subject: [address-policy-wg] [apwg-chairs] Create FAQ? (was: Re: IPv4 reserved space) In-Reply-To: <575FCCE8.9090509@foobar.org> References: <575FCCE8.9090509@foobar.org> Message-ID: Hi Nick, > Is there any possibility of creating a FAQ? There are a bunch of > issues which are coming up repeatedly, of which this is one. I agree. There are many things that the people who have been involved for a long time know, but which might not be obvious for others. I'll see if I can put something together on ipv6guide.net. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Tue Jun 14 12:20:26 2016 From: randy at psg.com (Randy Bush) Date: Tue, 14 Jun 2016 19:20:26 +0900 Subject: [address-policy-wg] Create FAQ? (was: Re: IPv4 reserved space) In-Reply-To: <575FCCE8.9090509@foobar.org> References: <575FCCE8.9090509@foobar.org> Message-ID: ok, for your faq. the last few times around the 240 track. draft-fuller-240space-00.txt tried to make it usable and the nanog thread off vince's preso which starts at https://www.nanog.org/mailinglist/mailarchives/old_archive/2007-10/msg00451.html the ietf int area thread on the matter http://osdir.com/ml/ietf.int/2007-12/msg00050.html draft-wilson-class-e-02.txt figured it was not globally usable so wanted to move it to private use draft-weil-shared-transition-space-request-15.txt tried to grab it as semi-private space for the usual suspects i have found nothing which has added any new information since randy From leo.vegoda at icann.org Tue Jun 14 17:05:46 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 14 Jun 2016 15:05:46 +0000 Subject: [address-policy-wg] [apwg-chairs] Create FAQ? (was: Re: IPv4 reserved space) In-Reply-To: References: <575FCCE8.9090509@foobar.org> Message-ID: <9c94d1e5ccda40498e74057e6832dc27@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Sander Steffann wrote: [...] > > Is there any possibility of creating a FAQ? There are a bunch of > > issues which are coming up repeatedly, of which this is one. > > I agree. There are many things that the people who have been involved > for a long time know, but which might not be obvious for others. I'll see > if I can put something together on ipv6guide.net. A little while ago, Marla Azinger and I wrote this document to describe some of the issues: https://www.rfc-editor.org/rfc/rfc6319.txt Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From sander at steffann.nl Tue Jun 14 17:22:05 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 14 Jun 2016 17:22:05 +0200 Subject: [address-policy-wg] [apwg-chairs] Create FAQ? (was: Re: IPv4 reserved space) In-Reply-To: <9c94d1e5ccda40498e74057e6832dc27@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <575FCCE8.9090509@foobar.org> <9c94d1e5ccda40498e74057e6832dc27@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: > A little while ago, Marla Azinger and I wrote this document to describe some > of the issues: > > https://www.rfc-editor.org/rfc/rfc6319.txt Thanks Leo! Sander From mschmidt at ripe.net Thu Jun 16 15:58:47 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 16 Jun 2016 15:58:47 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Message-ID: Dear colleagues, The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. The goal of this proposal is to ban transfers of allocations made under the final /8 policy. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Several restrictions have been removed - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From remco.vanmook at gmail.com Thu Jun 16 16:14:08 2016 From: remco.vanmook at gmail.com (Remco van Mook) Date: Thu, 16 Jun 2016 16:14:08 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Thank you Marco. Dear all, I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. Looking forward to a positive discussion, Remco * any suggestions for a better title for this space are most welcome as well > On 16 Jun 2016, at 15:58 , Marco Schmidt wrote: > > Dear colleagues, > > The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. > > The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. > As a result, a new Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Several restrictions have been removed > - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > We encourage you to review this policy proposal and send your comments to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From james.blessing at despres.co.uk Thu Jun 16 16:24:20 2016 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 16 Jun 2016 15:24:20 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: On 16 June 2016 at 14:58, Marco Schmidt wrote: > Dear colleagues, > > The Discussion Period for the policy proposal 2016-03, "Locking Down the > Final /8 Policy" has been extended until 15 July 2016. > Couple of thoughts Do we need to have the option for an LIR to transfer to and LIR who hasn't already had their final allocation? Are there any other documents that are affected by the creation of this new type of space? As it stands I'm neutral on the proposal J -- James Blessing 07989 039 476 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Dickinson at sky.uk Thu Jun 16 16:41:25 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Thu, 16 Jun 2016 14:41:25 +0000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Hi Remco, I'm still thinking this through, but a few questions jumped out at me, which imply there is still wordsmithing required. Given that the wording implies retroactively applying to everything previously allocated in 185/8, what will happen to those ALLOCATED FINAL allocations that have already been transferred? And where there are already multiple such ALLOCATED FINAL allocations within a single LIR? What is the policy for Merger & Acquisition with respect to ALLOCATED FINAL allocations as opposed to resource transfer? Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Remco van Mook Sent: 16 June 2016 15:14 To: Marco Schmidt ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Thank you Marco. Dear all, I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. Looking forward to a positive discussion, Remco * any suggestions for a better title for this space are most welcome as well > On 16 Jun 2016, at 15:58 , Marco Schmidt wrote: > > Dear colleagues, > > The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. > > The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. > As a result, a new Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Several restrictions have been removed > - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > We encourage you to review this policy proposal and send your comments to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From jim at rfc1035.com Thu Jun 16 16:42:25 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 16 Jun 2016 15:42:25 +0100 Subject: [address-policy-wg] comments on the revised 2016-03 In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <163A71B1-7C1E-451F-87E5-FE2419E1DCB9@rfc1035.com> > On 16 Jun 2016, at 15:14, Remco van Mook wrote: > I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. Remco, all, I think further tweaks are needed. Sorry. First, I think it would be helpful if there was a clear statement in the policy text that the rule of one LIR, one /22 applies to ALL future allocations made by the NCC and not just those which are made out of 185/8. There has been some confusion that the ?last /8 policy? -- yes, a better name is needed -- only applies to allocations from 185/8. Second, stating that a final /22 cannot be transferred seems over-restrictive. Although I agree with the proposal?s intention that LIR?s can?t/shouldn't sell their last ever /22, that does appear to prevent types of transfer that probably should be allowed: for instance LIR mergers/acquisitions or reorganisations. It might also be an idea to say that if an LIR doesn?t have ALLOCATED FINAL space and somehow acquires an LIR which does have one of those /22s, the acquiring LIR can?t get an allocation of ALLOCATED FINAL space because it now has one of these as a result of the merger/acquisition/whatever. From aleksbulgakov at gmail.com Thu Jun 16 16:53:16 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 16 Jun 2016 17:53:16 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Message-ID: Hi. What if some one opens business, become a LIR (pay money for it) then understand that he need to close his business? But he cannot even sell IPs because of this proposal. I think, the NCC can create special section in LIR portal (there is already one) but there will be IPs from the last /8 only. And when new LIR will request the resources, the NCC will check it in LIR portal and suggest to take one of them. It will save the last /8 for new members. So I oppose this proposal. 2016-06-16 17:41 GMT+03:00 Dickinson, Ian : > Hi Remco, > > I'm still thinking this through, but a few questions jumped out at me, which imply there is still wordsmithing required. > > Given that the wording implies retroactively applying to everything previously allocated in 185/8, what will happen to those ALLOCATED FINAL allocations that have already been transferred? And where there are already multiple such ALLOCATED FINAL allocations within a single LIR? > > What is the policy for Merger & Acquisition with respect to ALLOCATED FINAL allocations as opposed to resource transfer? > > Ian > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Remco van Mook > Sent: 16 June 2016 15:14 > To: Marco Schmidt ; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) > > > Thank you Marco. > > Dear all, > > I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. > > Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. > > Looking forward to a positive discussion, > > Remco > > * any suggestions for a better title for this space are most welcome as well > >> On 16 Jun 2016, at 15:58 , Marco Schmidt wrote: >> >> Dear colleagues, >> >> The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. >> >> The goal of this proposal is to ban transfers of allocations made under the final /8 policy. >> >> The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. >> As a result, a new Discussion Phase has started for the proposal. >> >> Some of the differences from version 1.0 include: >> - Several restrictions have been removed >> - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2016-03 >> >> We encourage you to review this policy proposal and send your comments to . >> >> Regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. > > Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From jim at rfc1035.com Thu Jun 16 16:59:02 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 16 Jun 2016 15:59:02 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Message-ID: > On 16 Jun 2016, at 15:53, Aleksey Bulgakov wrote: > > What if some one opens business, become a LIR (pay money for it) then > understand that he need to close his business? Same as what?s supposed to happen today. They return the space to the NCC. From aleksbulgakov at gmail.com Thu Jun 16 17:03:55 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 16 Jun 2016 18:03:55 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Message-ID: And will lose his money 2016-06-16 17:59 GMT+03:00 Jim Reid : > >> On 16 Jun 2016, at 15:53, Aleksey Bulgakov wrote: >> >> What if some one opens business, become a LIR (pay money for it) then >> understand that he need to close his business? > > Same as what?s supposed to happen today. They return the space to the NCC. > -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From jim at rfc1035.com Thu Jun 16 17:13:18 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 16 Jun 2016 16:13:18 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Message-ID: <78F77E4E-08FE-423E-B7EF-53309D1F3B66@rfc1035.com> > On 16 Jun 2016, at 16:03, Aleksey Bulgakov wrote: > > And will lose his money So what? Whenever a business ceases trading, it almost always does that because it ran out of money. It can?t be the NCC?s fault that an LIR closes or goes bust. And while that LIR was in business and paying its NCC fees, it got all the benefits of NCC membership. It has to pay for those services. From tom at kebab.org.pl Thu Jun 16 17:14:46 2016 From: tom at kebab.org.pl (=?UTF-8?B?IlRvbWFzeiDFmmzEhXNraSBAIEtFQkFCIg==?=) Date: Thu, 16 Jun 2016 17:14:46 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Message-ID: <5762C266.6050705@kebab.org.pl> W dniu 2016-06-16 o 16:59, Jim Reid pisze: >> On 16 Jun 2016, at 15:53, Aleksey Bulgakov wrote: >> >> What if some one opens business, become a LIR (pay money for it) then >> understand that he need to close his business? > Same as what?s supposed to happen today. They return the space to the NCC. > > Jim, please stop kidding. Do you know anyone, who returned the addresses to RIPE? In my 25 year career in IT I have not met anyone who did. My 3 cents - proposal 2016-03 is in contradiction with the possibility of opening multiple LIR, which is nothing more than selling IP for money and build additional income for RIPE. best regards Tomasz ?l?ski pl.skonet From nick at foobar.org Thu Jun 16 17:28:51 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 16 Jun 2016 16:28:51 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C266.6050705@kebab.org.pl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> Message-ID: <5762C5B3.7070402@foobar.org> Tomasz ?l?ski @ KEBAB wrote: > Jim, please stop kidding. Do you know anyone, who returned the addresses > to RIPE? In my 25 year career in IT I have not met anyone who did. rather than speculating, maybe someone from the RIPE NCC could provide information on how much address space has been returned to the registry over the last couple of years? Nick From nick at foobar.org Thu Jun 16 17:39:36 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 16 Jun 2016 16:39:36 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <5762C838.8080008@foobar.org> Remco van Mook wrote: > Explicitly states that the current IPv4 allocation policy applies to > all available IPv4 address space held by the RIPE NCC that has not > been reserved or marked to be returned to IANA This is probably useful. It would also probably be useful to define a term to replace the name "last /8" so that it can be referred to specifically in the policy documentation, e.g. "the remaining unallocated ipv4 pool" or something along those lines. Totally not as catchy as "the last /8", but sadly that is the nature of policy. > Adds a consideration to the IPv4 allocation policy that the LIR > should conserve whole or part of their final /22 allocation for > interoperability purposes Neutral on this. People will do what they are going to do, even if it's short-sighted. > Bans transfers of final /22 allocations > Changes the ?status?field in the RIPE Database to reflect the > transferability of an INETNUM I'm against this because it conflicts with the core purpose of the RIPE registry, which is to ensure accurate registration of resources. Formally banning transfers will not stop transfers; it will only stop those transfers from being registered which will lead to inaccurate registry information. Overall, I am against the core proposal, namely banning transfers from the remaining unallocated ipv4 pool. Nick From apwg at c4inet.net Thu Jun 16 17:44:52 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 16 Jun 2016 16:44:52 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <20160616154452.GI862@cilantro.c4inet.net> On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: >I would encourage everyone to carefully read this second version >(and not just respond "no, still hate it, kill it with fire") as >it is quite different from the first version. Nope, still hate it, kill it with fire. >Basically the only restriction left is to disallow transfers on >all "last /8 space"* going forward, and there is some language >added to the policy that tries to raise awareness that if you >just go and parcel out that entire allocation to endusers, you >might end up feeling a little bit silly a couple of years from >now. There are many non-speculative reasons why a LIR might want to transfer resources to another. There are also many LIRs now who have (or *will have* if this passes) no ipv4 resources other than this ALLOCATED FINAL space. these LIRs are bascially damned to forever (or until ipv6 is ubiquitous, whichever happens first) to not change their organisational structure in any way for fear of losing even this allocation. This can only lead to a proliferation of LIRs for resource protection purposes, a lot of painful and unneccessary re-numbering and, ultimately, to unrecorded "black market" trading of resources - something the "last /8" policy was specifically intended to prevent. Disclaimer: Nothing in shis statement shall be construed as accepting the right of the "community" to regulate M&A or any other business decisions a LIR may or may not make. rgds, Sascha Luck From uros at ub330.net Thu Jun 16 17:45:50 2016 From: uros at ub330.net (Uros Gaber) Date: Thu, 16 Jun 2016 17:45:50 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C5B3.7070402@foobar.org> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> <5762C5B3.7070402@foobar.org> Message-ID: The latest auctions by the Ministry for children, education and gender equality - national agency for learning and IT (https://ipv4.stil.dk/) show a "good" example of "returning" the address space to the RIPE pool. And if these kind of members would actually return the space then I think these kind of proposals would have no meaning. Kind regards, Uros Gaber On Thu, Jun 16, 2016 at 5:28 PM, Nick Hilliard wrote: > Tomasz ?l?ski @ KEBAB wrote: > > Jim, please stop kidding. Do you know anyone, who returned the addresses > > to RIPE? In my 25 year career in IT I have not met anyone who did. > > rather than speculating, maybe someone from the RIPE NCC could provide > information on how much address space has been returned to the registry > over the last couple of years? > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Thu Jun 16 18:17:48 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 16 Jun 2016 16:17:48 +0000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C266.6050705@kebab.org.pl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> Message-ID: Tomasz Slaski wrote: [...] > Jim, please stop kidding. Do you know anyone, who returned > the addresses to RIPE? In my 25 year career in IT I have not met > anyone who did. I'm neither supporting nor opposing the proposed policy. However, I note that there are a number of cases where organizations with large blocks of IPv4 address space they no longer need have returned that space. Several /8s were returned to global pool of unallocated IPv4 address space in 2007 and 2008. More recently, Interop returned more than 99% of a /8 to ARIN: https://www.arin.net/announcements/2010/20101020.html Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From apwg at c4inet.net Thu Jun 16 18:28:41 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 16 Jun 2016 17:28:41 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C266.6050705@kebab.org.pl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> Message-ID: <20160616162841.GJ862@cilantro.c4inet.net> On Thu, Jun 16, 2016 at 05:14:46PM +0200, "Tomasz ?l?ski @ KEBAB" wrote: >Jim, please stop kidding. Do you know anyone, who returned the >addresses to RIPE? In my 25 year career in IT I have not met anyone >who did. I returned a private /24 PI a long time ago. Knowing what I do now, I wouldn't have done it, though. cheers, Sascha Luck From h.lu at anytimechinese.com Thu Jun 16 19:59:03 2016 From: h.lu at anytimechinese.com (h.lu at anytimechinese.com) Date: Thu, 16 Jun 2016 19:59:03 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> Message-ID: <0D8EE720-4860-4B00-B981-D14E157694BD@anytimechinese.com> Hi To best of my knowledge, most of large return has been done by none profit org. Most for profit org and some gov on the other hand, are choosing to sell it > On 16 Jun 2016, at 18:17, Leo Vegoda wrote: > > Tomasz Slaski wrote: > > [...] > >> Jim, please stop kidding. Do you know anyone, who returned >> the addresses to RIPE? In my 25 year career in IT I have not met >> anyone who did. > > I'm neither supporting nor opposing the proposed policy. However, I note that > there are a number of cases where organizations with large blocks of IPv4 > address space they no longer need have returned that space. Several /8s were > returned to global pool of unallocated IPv4 address space in 2007 and 2008. > More recently, Interop returned more than 99% of a /8 to ARIN: > > https://www.arin.net/announcements/2010/20101020.html > > Kind regards, > > Leo Vegoda From ripe-wgs at radu-adrian.feurdean.net Thu Jun 16 20:01:26 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 16 Jun 2016 20:01:26 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C266.6050705@kebab.org.pl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> Message-ID: <1466100086.3550800.639881601.228D08F2@webmail.messagingengine.com> On Thu, Jun 16, 2016, at 17:14, Tomasz ?l?ski @ KEBAB wrote: > My 3 cents - proposal 2016-03 is in contradiction with the possibility > of opening multiple LIR, which is nothing more than selling IP for money > and build additional income for RIPE. The main problem being that "multiple LIRs" is voted by the memebership (RIPE NCC), while policy (including 2016-03) is "agreed" by the RIPE community (people on working-group lists). Yes, I do agree there is an "ideological split" between the two. -- Radu-Adrian FEURDEAN fr.ccs From elvis at velea.eu Thu Jun 16 20:03:17 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 16 Jun 2016 21:03:17 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C838.8080008@foobar.org> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> Message-ID: <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> Hi Remco, On 6/16/16 6:39 PM, Nick Hilliard wrote: > Remco van Mook wrote: >> I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. Still hate it, kill it! >> Explicitly states that the current IPv4 allocation policy applies to >> all available IPv4 address space held by the RIPE NCC that has not >> been reserved or marked to be returned to IANA > This is probably useful. It would also probably be useful to define a > term to replace the name "last /8" so that it can be referred to > specifically in the policy documentation, e.g. "the remaining > unallocated ipv4 pool" or something along those lines. Totally not as > catchy as "the last /8", but sadly that is the nature of policy. while updating this to a form where it would be very clear is something I applaud, I do not think it is a must. > >> Adds a consideration to the IPv4 allocation policy that the LIR >> should conserve whole or part of their final /22 allocation for >> interoperability purposes > Neutral on this. People will do what they are going to do, even if it's > short-sighted. a good addition, also feeling neutral on telling LIRs what to use the resources for. > >> Bans transfers of final /22 allocations >> Changes the ?status?field in the RIPE Database to reflect the >> transferability of an INETNUM > I'm against this because it conflicts with the core purpose of the RIPE > registry, which is to ensure accurate registration of resources. > Formally banning transfers will not stop transfers; it will only stop > those transfers from being registered which will lead to inaccurate > registry information. could not have said it better. While this is an interesting attempt, it will only drive _some_ transfers to the underground. Bad idea from my point of view. Additionally, it would still apply retroactively and people which since 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after the moment of the allocation) will end up with an allocation that is no longer transferable. I do not like policy proposals that apply retroactively, you should have thought of this in 2012 before the 'run out'. > > Overall, I am against the core proposal, namely banning transfers from > the remaining unallocated ipv4 pool. +1 > Nick > elvis From leo.vegoda at icann.org Thu Jun 16 20:26:03 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 16 Jun 2016 18:26:03 +0000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <0D8EE720-4860-4B00-B981-D14E157694BD@anytimechinese.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> <0D8EE720-4860-4B00-B981-D14E157694BD@anytimechinese.com> Message-ID: <003caa1a36f4470f8f007e5aa2da0791@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Hi Lu, You wrote: > To best of my knowledge, most of large return has been done by none profit org. > > Most for profit org and some gov on the other hand, are choosing to sell it I can't complete total knowledge. However, I would not classify any of the organizations I referred to in my previous message as non-profits. Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From sander at steffann.nl Thu Jun 16 20:30:00 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 16 Jun 2016 20:30:00 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> Message-ID: <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> Hi Aleksey, > And will lose his money The money is a membership fee that allowed them to hold resources while they were a member. Stop being a member = stop holding resources. Allocations are for running networks with, not making money... Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Thu Jun 16 20:40:48 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 16 Jun 2016 20:40:48 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C838.8080008@foobar.org> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> Message-ID: <9BF5B338-5BA5-44AD-96EB-EB4C8D0BD2A4@steffann.nl> Hi Nick, Not speaking in favour or against this proposal, just thinking about the possible effects: > I'm against this because it conflicts with the core purpose of the RIPE > registry, which is to ensure accurate registration of resources. > Formally banning transfers will not stop transfers; it will only stop > those transfers from being registered which will lead to inaccurate > registry information. I had the same feeling in the beginning, but after thinking about it a bit more I am not so sure anymore. Not transferring the resources means keeping the LIR running to hold them. If the LIR closes then the resources go back to the NCC and the unregistered new holder will end up with empty hands. Both the cost of keeping the LIR open (which will rise beyond the cost of "legally" buying space after a few years) and the risk for the receiver to lose their address space if the seller stops paying the NCC membership fee are strong incentives to just stop trading in ALLOCATED FINAL space. And M&A is still possible if people really want to move this address space around, and that will make sure the registration is updated. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tom at kebab.org.pl Thu Jun 16 20:42:28 2016 From: tom at kebab.org.pl (=?UTF-8?B?IlRvbWFzeiDFmmzEhXNraSBAIEtFQkFCIg==?=) Date: Thu, 16 Jun 2016 20:42:28 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> Message-ID: <5762F314.6050104@kebab.org.pl> W dniu 2016-06-16 o 20:30, Sander Steffann pisze: > Hi Aleksey, > >> And will lose his money > The money is a membership fee that allowed them to hold resources while they were a member. Stop being a member = stop holding resources. Allocations are for running networks with, not making money... > > Cheers, > Sander > You can't make money without allocations. Networks are not running to keep flashing lights on the devices and drawing graphs in cacti. They earn money in prevailing cases. Best regards -- Tomasz ?l?ski pl.skonet From sander at steffann.nl Thu Jun 16 20:46:47 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 16 Jun 2016 20:46:47 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762F314.6050104@kebab.org.pl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> <5762F314.6050104@kebab.org.pl> Message-ID: <2BBB52A0-7419-4575-B034-E0664683AA6B@steffann.nl> Hi, > You can't make money without allocations. Networks are not running to keep flashing lights on the devices and drawing graphs in cacti. They earn money in prevailing cases. Indeed, and while you still run a network you remain a member and you keep your address space. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ripe-wgs at radu-adrian.feurdean.net Thu Jun 16 21:07:35 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 16 Jun 2016 21:07:35 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> Message-ID: <1466104055.3567997.639944201.5BD5D417@webmail.messagingengine.com> On Thu, Jun 16, 2016, at 20:30, Sander Steffann wrote: > they were a member. Stop being a member = stop holding resources. > Allocations are for running networks with, not making money... I find this inconsistent. Either we do it for *ALL* allocations (including the ones allocated prior to the 2012/09 ipocalipse), effectively banning or heavily restricting transfers, or we keep it the way it is today, i.e. for *NO* allocations. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Thu Jun 16 21:20:38 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 16 Jun 2016 21:20:38 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C5B3.7070402@foobar.org> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> <5762C5B3.7070402@foobar.org> Message-ID: <1466104838.3570201.639954385.2C663437@webmail.messagingengine.com> On Thu, Jun 16, 2016, at 17:28, Nick Hilliard wrote: > rather than speculating, maybe someone from the RIPE NCC could provide > information on how much address space has been returned to the registry > over the last couple of years? Hi, https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph Says 8.21 million returned ot recovered. http://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml Says (32+16+8+2+1+1+0.25+1+0.25+0.5)*65536 = 4063232 recovered. That gives a total of 4146768 IPs, slightly less than a /10. Or slightly more then the amount recovered from IANA. Marco, can you confirm this ? -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Thu Jun 16 21:31:16 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 16 Jun 2016 21:31:16 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <1466105476.3573447.639964673.6FA73406@webmail.messagingengine.com> On Thu, Jun 16, 2016, at 16:14, Remco van Mook wrote:Dear all, > > I would encourage everyone to carefully read this second version (and not Done. > just respond "no, still hate it, kill it with fire") as it is quite > different from the first version. Yes, it is "quite" different (depending on the definition of "quite"). But still hate it, kill it with fire. Use napalm if necessary. > Basically the only restriction left is to disallow transfers on all "last > /8 space"* going forward, and there is some language added to the policy > that tries to raise awareness that if you just go and parcel out that > entire allocation to endusers, you might end up feeling a little bit > silly a couple of years from now. And makes clear the retroactive intent. In fact, only use fire to kill it if you don't have anything more effective (to kill it). -- Radu-Adrian FEURDEAN fr.ccs From gert at space.net Thu Jun 16 22:15:34 2016 From: gert at space.net (Gert Doering) Date: Thu, 16 Jun 2016 22:15:34 +0200 Subject: [address-policy-wg] comments on the revised 2016-03 In-Reply-To: <163A71B1-7C1E-451F-87E5-FE2419E1DCB9@rfc1035.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <163A71B1-7C1E-451F-87E5-FE2419E1DCB9@rfc1035.com> Message-ID: <20160616201534.GG79185@Space.Net> Hi, On Thu, Jun 16, 2016 at 03:42:25PM +0100, Jim Reid wrote: > Second, stating that a final /22 cannot be transferred seems > over-restrictive. Although I agree with the proposal???s intention > that LIR???s can???t/shouldn't sell their last ever /22, that does > appear to prevent types of transfer that probably should be allowed: > for instance LIR mergers/acquisitions or reorganisations. M&As are not "transfers according to policy". (v1.0 tried to also block M&A-style transfers by restricting LIRs to only ever hold a single /22 and return anything more they end up having, but that got taken out). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matei at profisol.ro Thu Jun 16 22:23:42 2016 From: matei at profisol.ro (Storch Matei) Date: Thu, 16 Jun 2016 23:23:42 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> Message-ID: Hi Elvis and all, I fully agree with your reason for not agreeing with this proposal, mainly the fact that it acts retroactively. The only problem I see with your reason is that it would have fully applied to 2015-01, in the exact same manner. LIRs received an allocation knowing they will be able to transfer it if needed/wanted, and all of a sudden, they became nontransferable for 2 years, aplicable to resources already allocated. If the policy only applied to resources allocated after the adoption of the policy, there would have been no such problem. Difference of course is that with this proposal, the final allocation will NEVER be transferable via the RIPE standard transfer process. And in this case, the aplicability to only the resources allocated after the adoption is a no-go in my opinion, because it will cause tons of confusion and will be very difficult for RIPE NCC to manage. So, just to reiterate, this policy wants to change the rules of the "game" during the game, which is not ok at all. Since at the time of the allocation (let's say 20th september 2012) these allocations didn't have a special status (except beeing the last allocation received by that LIR from RIPE) and were treated exactly like any other resources previously allocated, this must not ever change. Regardless of the reasons behind the request for the final /22, at the moment of allocation, they were "normal" resources. If in the meantime the LIR does not have a use for those resources anymore, or just considers that it's a better business to cash-in 7-10k euro, they are entitled to do so. Just like with legacy resource holders, they were allocated resources before the RIRs, and they were entitled to keep those resources per the initial conditions of allocation and transfer them, etc. Matei Storch -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Elvis Daniel Velea Sent: Thursday, June 16, 2016 21:03 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Hi Remco, On 6/16/16 6:39 PM, Nick Hilliard wrote: > Remco van Mook wrote: >> I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. Still hate it, kill it! >> Explicitly states that the current IPv4 allocation policy applies to >> all available IPv4 address space held by the RIPE NCC that has not >> been reserved or marked to be returned to IANA > This is probably useful. It would also probably be useful to define a > term to replace the name "last /8" so that it can be referred to > specifically in the policy documentation, e.g. "the remaining > unallocated ipv4 pool" or something along those lines. Totally not as > catchy as "the last /8", but sadly that is the nature of policy. while updating this to a form where it would be very clear is something I applaud, I do not think it is a must. > >> Adds a consideration to the IPv4 allocation policy that the LIR >> should conserve whole or part of their final /22 allocation for >> interoperability purposes > Neutral on this. People will do what they are going to do, even if > it's short-sighted. a good addition, also feeling neutral on telling LIRs what to use the resources for. > >> Bans transfers of final /22 allocations Changes the ?status?field in >> the RIPE Database to reflect the transferability of an INETNUM > I'm against this because it conflicts with the core purpose of the > RIPE registry, which is to ensure accurate registration of resources. > Formally banning transfers will not stop transfers; it will only stop > those transfers from being registered which will lead to inaccurate > registry information. could not have said it better. While this is an interesting attempt, it will only drive _some_ transfers to the underground. Bad idea from my point of view. Additionally, it would still apply retroactively and people which since 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after the moment of the allocation) will end up with an allocation that is no longer transferable. I do not like policy proposals that apply retroactively, you should have thought of this in 2012 before the 'run out'. > > Overall, I am against the core proposal, namely banning transfers from > the remaining unallocated ipv4 pool. +1 > Nick > elvis From apwg at c4inet.net Thu Jun 16 22:29:41 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 16 Jun 2016 21:29:41 +0100 Subject: [address-policy-wg] comments on the revised 2016-03 In-Reply-To: <20160616201534.GG79185@Space.Net> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <163A71B1-7C1E-451F-87E5-FE2419E1DCB9@rfc1035.com> <20160616201534.GG79185@Space.Net> Message-ID: <20160616202941.GK862@cilantro.c4inet.net> On Thu, Jun 16, 2016 at 10:15:34PM +0200, Gert Doering wrote: >M&As are not "transfers according to policy". More precisely, not *yet*. 2015-04 is attempting to change that (in an, IMO, somewhat unethical way) rgds, Sascha Luck From lists at velder.li Thu Jun 16 22:46:48 2016 From: lists at velder.li (Patrick Velder) Date: Thu, 16 Jun 2016 22:46:48 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> Message-ID: <57631038.5070808@velder.li> +1 Am 16.06.2016 um 22:23 schrieb Storch Matei: > Hi Elvis and all, > > I fully agree with your reason for not agreeing with this proposal, mainly the fact that it acts retroactively. The only problem I see with your reason is that it would have fully applied to 2015-01, in the exact same manner. LIRs received an allocation knowing they will be able to transfer it if needed/wanted, and all of a sudden, they became nontransferable for 2 years, aplicable to resources already allocated. If the policy only applied to resources allocated after the adoption of the policy, there would have been no such problem. Difference of course is that with this proposal, the final allocation will NEVER be transferable via the RIPE standard transfer process. And in this case, the aplicability to only the resources allocated after the adoption is a no-go in my opinion, because it will cause tons of confusion and will be very difficult for RIPE NCC to manage. > > So, just to reiterate, this policy wants to change the rules of the "game" during the game, which is not ok at all. Since at the time of the allocation (let's say 20th september 2012) these allocations didn't have a special status (except beeing the last allocation received by that LIR from RIPE) and were treated exactly like any other resources previously allocated, this must not ever change. Regardless of the reasons behind the request for the final /22, at the moment of allocation, they were "normal" resources. If in the meantime the LIR does not have a use for those resources anymore, or just considers that it's a better business to cash-in 7-10k euro, they are entitled to do so. Just like with legacy resource holders, they were allocated resources before the RIRs, and they were entitled to keep those resources per the initial conditions of allocation and transfer them, etc. > > > Matei Storch > > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Elvis Daniel Velea > Sent: Thursday, June 16, 2016 21:03 > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) > > Hi Remco, > > On 6/16/16 6:39 PM, Nick Hilliard wrote: >> Remco van Mook wrote: >>> I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. > Still hate it, kill it! > >>> Explicitly states that the current IPv4 allocation policy applies to >>> all available IPv4 address space held by the RIPE NCC that has not >>> been reserved or marked to be returned to IANA >> This is probably useful. It would also probably be useful to define a >> term to replace the name "last /8" so that it can be referred to >> specifically in the policy documentation, e.g. "the remaining >> unallocated ipv4 pool" or something along those lines. Totally not as >> catchy as "the last /8", but sadly that is the nature of policy. > while updating this to a form where it would be very clear is something I applaud, I do not think it is a must. >>> Adds a consideration to the IPv4 allocation policy that the LIR >>> should conserve whole or part of their final /22 allocation for >>> interoperability purposes >> Neutral on this. People will do what they are going to do, even if >> it's short-sighted. > a good addition, also feeling neutral on telling LIRs what to use the resources for. >>> Bans transfers of final /22 allocations Changes the ?status?field in >>> the RIPE Database to reflect the transferability of an INETNUM >> I'm against this because it conflicts with the core purpose of the >> RIPE registry, which is to ensure accurate registration of resources. >> Formally banning transfers will not stop transfers; it will only stop >> those transfers from being registered which will lead to inaccurate >> registry information. > could not have said it better. While this is an interesting attempt, it will only drive _some_ transfers to the underground. Bad idea from my point of view. > > Additionally, it would still apply retroactively and people which since > 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after the moment of the allocation) will end up with an allocation that is no longer transferable. I do not like policy proposals that apply retroactively, you should have thought of this in 2012 before the 'run out'. > >> Overall, I am against the core proposal, namely banning transfers from >> the remaining unallocated ipv4 pool. > +1 >> Nick >> > elvis > > > From rgori at wirem.net Thu Jun 16 23:47:02 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 16 Jun 2016 23:47:02 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: Hi all, I strongly, strongly and again strongly oppose this proposal. This policy still does not take into account that resoucers can be announced and in use and all of this after beeing allocated under regular procedures and business processes. A new entrant would see his investments vanified by a rule that make possibile transferts possbile only for old LIRs that acquired space before 09/2012 With this policy any new LIR would be out of the market before entering it. I didn't look deeply because I have no time for family reasons now but I am pretty sure that I can find easily in the list archive that IP Transfert policies were accepted even 'cause in case of network acquisition or M&A or many other cases renumbering customers is very difficoult, and having ability to transfert resources is the most easy way to keep consistence on database. We were in Bucarest when celebrating Romania as the biggest transfert country were JUMP Management choosed to sell to its customers their allocation making them able to keep their business running! How can my new LIR company can compete in the market going to its customer stating "be aware that the assignement I giving you if I sell my company will be returned and you need to find a new LIR and renumber your network, and sorry most important... I will never be able to sell you this block or part of it but hummm yes if you go to an LIR made before 09/2012 you can have it...." End users will run far away from every new LIR choosing as default a LIR made before 09/2012. This creates barrier to ingress in the market. The full control of IP market will be in the hand of LIR (and PI holders) made before 09/2012. Barriers to ingress in the market. This is not leaving space to new entrants this is assuring control of IP market today. Again: If a return policy has to be proposed this should address the whole IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and not in use. I am pretty sure that everyone here agree that this is not possibile... About 5.1. 4. plase don't don't don't state in the policy that /22 is for "transition purposes" In 2015-05 we tried to introduce ripeness stars and IPv6 deployment as a requirement for an additional /22 and at Address Policy Working Group in Copenhagen last 25/05 some of you experienced explained to me publically that we can't force old or new LIRs to deploy IPv6 and this is even the reason why the IPv6 requirement was removed from "last /8" allocation policy. Someone else said it's LIR responsability to choose how to use space... IPv6 will come....bla bla bla. You teached, I learned. At the same Address Policy Working Group well populated by experienced people commong understanding was that is better to leave things as is since "last /8" is doing its best after the 2015-01 fix came. For the above reasons and the non reached consensus we were encouraged to withdrawn 2015-05. I can't believe we are still discussing about this 2016-03. personally the only fix I would accept is to "Explicitly states that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC [...]" regards Riccardo Il 16/06/2016 15:58, Marco Schmidt ha scritto: > Dear colleagues, > > The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. > > The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. > As a result, a new Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Several restrictions have been removed > - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > We encourage you to review this policy proposal and send your comments to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From nick at foobar.org Thu Jun 16 23:47:54 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 16 Jun 2016 22:47:54 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <57631E8A.4010005@foobar.org> Riccardo Gori wrote: > I strongly, strongly and again strongly oppose this proposal. does this count for three votes? Nick From rgori at wirem.net Thu Jun 16 23:53:39 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 16 Jun 2016 23:53:39 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C838.8080008@foobar.org> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> Message-ID: <756c60ec-c235-997b-b7b1-1d7a90afefdc@wirem.net> Il 16/06/2016 17:39, Nick Hilliard ha scritto: > Remco van Mook wrote: >> Explicitly states that the current IPv4 allocation policy applies to >> all available IPv4 address space held by the RIPE NCC that has not >> been reserved or marked to be returned to IANA > This is probably useful. It would also probably be useful to define a > term to replace the name "last /8" so that it can be referred to > specifically in the policy documentation, e.g. "the remaining > unallocated ipv4 pool" or something along those lines. Totally not as > catchy as "the last /8", but sadly that is the nature of policy. I agree too this can be useful. I think even Jim can agree. We had a quick chat about it in Copenhagen. I even wrote apwg chair about a new proposal simply add this clarification but stopped since Marco noticed was already in this unacceptable 2016-03. > >> Adds a consideration to the IPv4 allocation policy that the LIR >> should conserve whole or part of their final /22 allocation for >> interoperability purposes > Neutral on this. People will do what they are going to do, even if it's > short-sighted. > >> Bans transfers of final /22 allocations >> Changes the ?status?field in the RIPE Database to reflect the >> transferability of an INETNUM > I'm against this because it conflicts with the core purpose of the RIPE > registry, which is to ensure accurate registration of resources. > Formally banning transfers will not stop transfers; it will only stop > those transfers from being registered which will lead to inaccurate > registry information. > > Overall, I am against the core proposal, namely banning transfers from > the remaining unallocated ipv4 pool. completely agree > > Nick > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Thu Jun 16 23:58:00 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 16 Jun 2016 23:58:00 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5762C266.6050705@kebab.org.pl> <5762C5B3.7070402@foobar.org> Message-ID: <5cedcd2b-a9e7-0092-bb03-3977bc6e7c70@wirem.net> Il 16/06/2016 17:45, Uros Gaber ha scritto: > The latest auctions by the Ministry for children, education and gender > equality - national agency for learning and IT (https://ipv4.stil.dk/) > show a "good" example of "returning" the address space to the RIPE pool. wonderful > > And if these kind of members would actually return the space then I > think these kind of proposals would have no meaning. > > Kind regards, > Uros Gaber > > On Thu, Jun 16, 2016 at 5:28 PM, Nick Hilliard > wrote: > > Tomasz ?l?ski @ KEBAB wrote: > > Jim, please stop kidding. Do you know anyone, who returned the > addresses > > to RIPE? In my 25 year career in IT I have not met anyone who did. > > rather than speculating, maybe someone from the RIPE NCC could provide > information on how much address space has been returned to the > registry > over the last couple of years? > > Nick > > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Thu Jun 16 23:58:52 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 16 Jun 2016 23:58:52 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160616154452.GI862@cilantro.c4inet.net> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160616154452.GI862@cilantro.c4inet.net> Message-ID: Hi all again Il 16/06/2016 17:44, Sascha Luck [ml] ha scritto: > On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: >> I would encourage everyone to carefully read this second version >> (and not just respond "no, still hate it, kill it with fire") as >> it is quite different from the first version. > > Nope, still hate it, kill it with fire. completely agree > >> Basically the only restriction left is to disallow transfers on >> all "last /8 space"* going forward, and there is some language >> added to the policy that tries to raise awareness that if you >> just go and parcel out that entire allocation to endusers, you >> might end up feeling a little bit silly a couple of years from >> now. > > There are many non-speculative reasons why a LIR might want to > transfer resources to another. There are also many LIRs now who > have (or *will have* if this passes) no ipv4 resources > other than this ALLOCATED FINAL space. these LIRs are bascially > damned to forever (or until ipv6 is ubiquitous, whichever happens > first) to not change their organisational structure in any way > for fear of losing even this allocation. > > This can only lead to a proliferation of LIRs for resource > protection purposes, a lot of painful and unneccessary > re-numbering and, ultimately, to unrecorded "black market" > trading of resources - something the "last /8" policy was > specifically intended to prevent. > > Disclaimer: Nothing in shis statement shall be construed as > accepting the right of the "community" to regulate M&A or any > other business decisions a LIR may or may not make. completely agree with Sascha > > rgds, > Sascha Luck > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Fri Jun 17 00:12:45 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 17 Jun 2016 00:12:45 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <57631E8A.4010005@foobar.org> References: <57631E8A.4010005@foobar.org> Message-ID: <535b023c-98fa-c8a7-aa86-ddebb3ecca8d@wirem.net> just one, even my multiple replies are for my one opinion. regards Riccardo Il 16/06/2016 23:47, Nick Hilliard ha scritto: > Riccardo Gori wrote: >> I strongly, strongly and again strongly oppose this proposal. > does this count for three votes? > > Nick -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From nick at foobar.org Fri Jun 17 00:14:01 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 16 Jun 2016 23:14:01 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <535b023c-98fa-c8a7-aa86-ddebb3ecca8d@wirem.net> References: <57631E8A.4010005@foobar.org> <535b023c-98fa-c8a7-aa86-ddebb3ecca8d@wirem.net> Message-ID: <576324A9.7050301@foobar.org> Riccardo Gori wrote: > just one, even my multiple replies are for my one opinion. so you just strongly oppose this proposal then. Right, ok. Glad we have that sorted. Nick From sander at steffann.nl Fri Jun 17 00:59:53 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 00:59:53 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <4ABC9CB5-5B45-4C58-97C9-C7EA7E5F908E@steffann.nl> Hi Riccardo, I'm sorry, but there is some FUD here that I need to address. Again: I don't care whether this policy gets consensus or not, but I do care about the quality of the arguments. That is what Gert and/or I have to base consensus on later. > A new entrant would see his investments vanified Address space is not an investment. The only reasons transfers were allowed in the first place (and this was not an easy decision back then) is to keep the database information accurate and to get some unused address space back in use. > by a rule that make possibile transferts possbile only for old LIRs that acquired space before 09/2012 > With this policy any new LIR would be out of the market before entering it. No, new LIRs get exactly the same "free" /22 as before. Only now they can not transfer/sell it, they can use it to run their network with. That is not pushing new LIRs out of the market. Unless your business is to sell off address space. In that case: that is what this proposal is trying to prevent, so the remaining address space is saved for organisations that run networks. > I didn't look deeply because I have no time for family reasons now but I am pretty sure that I can find easily in the list archive that IP Transfert policies were accepted even 'cause in case of network acquisition or M&A or many other cases renumbering customers is very difficoult, and having ability to transfert resources is the most easy way to keep consistence on database. We still have M&A for cases where businesses split up, merge, get sold etc. That is not affected by this policy proposal. > We were in Bucarest when celebrating Romania as the biggest transfert country were JUMP Management choosed to sell to its customers their allocation making them able to keep their business running! An LIR assigns addresses to its customers. That is how the allocation/assignment model works. Selling PA addresses isn't part of that. And besides: you can only sell allocations to other LIRs, so those "customers" have to be LIRs anyway, so they can get their own /22. > How can my new LIR company can compete in the market going to its customer stating "be aware that the assignement I giving you if I sell my company will be returned and you need to find a new LIR and renumber your network, Selling your company is M&A. That is unaffected by this policy proposal (important change in version 2), so no problem anymore. > and sorry most important... I will never be able to sell you this block or part of it Where did this idea of selling customers parts of an LIRs PA space come from? The receiver of a (part of a) PA allocation has to be an LIR themselves and therefore can get their own /22 for free. Even if you want this business model then surely setting up an LIR for a customer and getting a /22 for them provides much more than selling off a part of your own /22 ever can. > End users will run far away from every new LIR choosing as default a LIR made before 09/2012. This creates barrier to ingress in the market. Why? The LIR still has their PA allocation, can use it to provide service to customers etc. Nobody is taking a PA allocation away from the LIR. > The full control of IP market will be in the hand of LIR (and PI holders) made before 09/2012. Barriers to ingress in the market. I'm sorry, I don't care about "the IP market". Its only purpose is to get addresses to LIRs that need them. The last /22 allocation provides new LIRs with a free block to start running their network with, not to provide them with a free asset that they can then sell for profit. RIPE is about running networks. > This is not leaving space to new entrants this is assuring control of IP market today. New entrants become an LIR and get their /22. After that they can participate in the market of getting unused address space back in use all they want. It's not the RIPE community's job to provide them with new stuff they can sell. Everybody can become an LIR. Those thinking about selling parts of their /22 should think about what they are doing. If they want to help customers and provide a good service to them: help them set up an LIR if they need to (which they would also need to do to be able to receive a PA transfer). Get them their own /22 that no-one can take away from them. > Again: If a return policy has to be proposed this should address the whole IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and not in use. > I am pretty sure that everyone here agree that this is not possibile... This is not a return policy proposal, this is a policy proposal that tries to stop people from using the scarce IPv4 resources that the RIPE NCC has left for their own profit instead of for the good of the community. > About 5.1. 4. > plase don't don't don't state in the policy that /22 is for "transition purposes" > In 2015-05 we tried to introduce ripeness stars and IPv6 deployment as a requirement for an additional /22 and at Address Policy Working Group in Copenhagen last 25/05 some of you experienced explained to me publically that we can't force old or new LIRs to deploy IPv6 and this is even the reason why the IPv6 requirement was removed from "last /8" allocation policy. > Someone else said it's LIR responsability to choose how to use space... IPv6 will come....bla bla bla. You teached, I learned. Apparently there are still lots of people that don't understand that the IPv4 barrel is as good as empty. I have to admit that I do sympathise with efforts to get rid of this FUD that IPv4 can still be "business as usual". Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From arash_mpc at parsun.com Fri Jun 17 02:58:20 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Fri, 17 Jun 2016 10:58:20 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466104055.3567997.639944201.5BD5D417@webmail.messagingengine.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <9B3BFE0A18160E40BAF1950414D10FAE5B25FEF4@WPMBX010.bskyb.com> <5B3A592C-4A7C-4DE7-9F95-F132A1EB6D60@steffann.nl> <1466104055.3567997.639944201.5BD5D417@webmail.messagingengine.com> Message-ID: <027801d1c833$5a3057e0$0e9107a0$@parsun.com> >I find this inconsistent. Either we do it for *ALL* allocations (including the ones allocated prior to the 2012/09 ipocalipse), effectively banning or heavily >restricting transfers, or we keep it the way it is today, i.e. for *NO* allocations. Not sure why returning some /22 to RIPE NCC free pool can save the new-comers but other allocations prior 2012 cannot. If returning an allocation is something visible it should be for all allocations not only to the smallest ones, it is not fair. Regards, Arash From tore at fud.no Fri Jun 17 07:41:28 2016 From: tore at fud.no (Tore Anderson) Date: Fri, 17 Jun 2016 07:41:28 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> Message-ID: <20160617074128.651f15f6@echo.ms.redpill-linpro.com> * Elvis Daniel Velea > Additionally, it would still apply retroactively and people which since > 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after > the moment of the allocation) will end up with an allocation that is no > longer transferable. Elvis, while there are valid arguments against this proposal, this is not one of them. If it was, then we could essentially just disband the AP-GW as pretty much every single policy proposal ever made would "apply retroactively". Including the ones that made various forms of transfers possible in the first place; suddenly, many old non-transferable blocks were "retroactively" changed to become transferable. Note that the RIPE NCC SSA says: > Article 6 ? Compliance > > 6.1 The Member acknowledges applicability of, and adheres to, the RIPE > Policies and RIPE NCC procedural documents. The RIPE Policies and the > RIPE NCC procedural documents are publicly available from the RIPE NCC > Document Store. These documents, which may be revised and updated from > time to time, form an integral part of and apply fully to the RIPE NCC > Standard Service Agreement. A member who believes that transferability is an immutable and everlasting property of address space has not read what they've signed. If this proposal truly "applied retroactively" with regards to transfers, it would have had to annul all the transfers *made prior to its adoption* and stated the previously transferred address space was to be forcibly returned to its original holder or the NCC. > I do not like policy proposals that apply retroactively Uhm, so what about your 2015-01 proposal then? That one "applied retroactively" no less than this one. Anyway. I withdraw my earlier objection to 2016-03. I'm not at all convinced it's a good idea or worth the trouble, but if the community really wants to go down this road I won't try to block the path. Consider me neutral/abstaining. Tore From rgori at wirem.net Fri Jun 17 08:09:11 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 17 Jun 2016 08:09:11 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160617074128.651f15f6@echo.ms.redpill-linpro.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> <20160617074128.651f15f6@echo.ms.redpill-linpro.com> Message-ID: <466580db-8b7b-b584-5397-6141fa980f78@wirem.net> Hi, Il 17/06/2016 07:41, Tore Anderson ha scritto: > * Elvis Daniel Velea > >> Additionally, it would still apply retroactively and people which since >> 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after >> the moment of the allocation) will end up with an allocation that is no >> longer transferable. > Elvis, while there are valid arguments against this proposal, this is > not one of them. > > If it was, then we could essentially just disband the AP-GW as pretty > much every single policy proposal ever made would "apply > retroactively". Including the ones that made various forms of transfers > possible in the first place; suddenly, many old non-transferable blocks > were "retroactively" changed to become transferable. > > Note that the RIPE NCC SSA says: > >> Article 6 ? Compliance >> >> 6.1 The Member acknowledges applicability of, and adheres to, the RIPE >> Policies and RIPE NCC procedural documents. The RIPE Policies and the >> RIPE NCC procedural documents are publicly available from the RIPE NCC >> Document Store. These documents, which may be revised and updated from >> time to time, form an integral part of and apply fully to the RIPE NCC >> Standard Service Agreement. > A member who believes that transferability is an immutable and > everlasting property of address space has not read what they've signed. > > If this proposal truly "applied retroactively" with regards to > transfers, it would have had to annul all the transfers *made prior to > its adoption* and stated the previously transferred address space was > to be forcibly returned to its original holder or the NCC. > >> I do not like policy proposals that apply retroactively > Uhm, so what about your 2015-01 proposal then? That one "applied > retroactively" no less than this one. I don't think 2015-01 apply retroactively. I think allocation made before implementation of 2015-01 are free from limitations. I'll open a ticket about it and check and let you know. > > Anyway. I withdraw my earlier objection to 2016-03. I'm not at all > convinced it's a good idea or worth the trouble, but if the community > really wants to go down this road I won't try to block the path. > Consider me neutral/abstaining. > > Tore > regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From payam at rasana.net Fri Jun 17 11:22:35 2016 From: payam at rasana.net (Payam Poursaied) Date: Fri, 17 Jun 2016 11:22:35 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <027801d1c833$5a3057e0$0e9107a0$@parsun.com> Message-ID: +1 My point of view is such policies in practice would punish the newcomers rather than those who got plenty of resources in the old days [probably without proper justification] I remember the days which our LIR was negotiating with a RIPE NCC IP analyst and he declined our request although we had proved that our need was even more than what we submitted in our application, and eventually the block which he approved was less than what we requested. And at those time, some other western LIRs got their IP blocks. These days we are trying to buy new IP blocks, and those LIRs are selling! That funny story is the real story! While the proposed policy looks very rational, but it is not going to solve the issue! The demand is there so the market will find a way to satisfy the demand! If I were the gentleman who proposed this policy, I would have proposed another policy to push the LIRs who had not used their IPs (or pretending to use that) in favor of LIRs in the developing countries who really can't serve new customers due to lack of IP space. we should not close our eyes on the approvals which were given to LIRs who got plenty of IPs, and they were supposed to use all the IPs within two years following the allocation, and still they have a lot of un-assigned (and even un-advertised!) ones! On 2016-06-17 02:58:20 CET, Arash Naderpour wrote: > >I find this inconsistent. Either we do it for *ALL* allocations (including > the ones allocated prior to the 2012/09 ipocalipse), effectively banning or > heavily >restricting transfers, or we keep it the way it is today, i.e. for > *NO* allocations. > > Not sure why returning some /22 to RIPE NCC free pool can save the > new-comers but other allocations prior 2012 cannot. If returning an > allocation is something visible it should be for all allocations not only to > the smallest ones, it is not fair. > > Regards, > > Arash > > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From sander at steffann.nl Fri Jun 17 11:43:33 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 11:43:33 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: Hi Payam, > My point of view is such policies in practice would punish the newcomers rather than those who got plenty of resources in the old days [probably without proper justification] > I remember the days which our LIR was negotiating with a RIPE NCC IP analyst and he declined our request although we had proved that our need was even more than what we submitted in our application, and eventually the block which he approved was less than what we requested. > And at those time, some other western LIRs got their IP blocks. Please don't make allegations like that. I have worked for western LIRs and we had exactly the same process and issues as everybody else. > These days we are trying to buy new IP blocks, and those LIRs are selling! > > That funny story is the real story! While the proposed policy looks very rational, but it is not going to solve the issue! > The demand is there so the market will find a way to satisfy the demand! People with demand for a /22 can set up their own LIR. No need to let someone else set up an LIR and just sell the space > If I were the gentleman who proposed this policy, I would have proposed another policy to push the LIRs who had not used their IPs (or pretending to use that) in favor of LIRs in the developing countries who really can't serve new customers due to lack of IP space. > > we should not close our eyes on the approvals which were given to LIRs who got plenty of IPs, and they were supposed to use all the IPs within two years following the allocation, and still they have a lot of un-assigned (and even un-advertised!) ones! > > > > On 2016-06-17 02:58:20 CET, Arash Naderpour wrote: >>> I find this inconsistent. Either we do it for *ALL* allocations (including >> the ones allocated prior to the 2012/09 ipocalipse), effectively banning or >> heavily >restricting transfers, or we keep it the way it is today, i.e. for >> *NO* allocations. >> >> Not sure why returning some /22 to RIPE NCC free pool can save the >> new-comers but other allocations prior 2012 cannot. If returning an >> allocation is something visible it should be for all allocations not only to >> the smallest ones, it is not fair. >> >> Regards, >> >> Arash > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From sander at steffann.nl Fri Jun 17 11:58:30 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 11:58:30 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> Sorry, got bumped into and accidentally hit Send before I was done :) Here is the rest: Hi Payam, > My point of view is such policies in practice would punish the newcomers rather than those who got plenty of resources in the old days [probably without proper justification] > I remember the days which our LIR was negotiating with a RIPE NCC IP analyst and he declined our request although we had proved that our need was even more than what we submitted in our application, and eventually the block which he approved was less than what we requested. > And at those time, some other western LIRs got their IP blocks. Please don't make allegations like that. I have worked for western LIRs and we had exactly the same process and issues as everybody else. > These days we are trying to buy new IP blocks, and those LIRs are selling! > > That funny story is the real story! While the proposed policy looks very rational, but it is not going to solve the issue! > The demand is there so the market will find a way to satisfy the demand! People with demand for a /22 can set up their own LIR. No need to let someone else set up an LIR and just sell the space. > If I were the gentleman who proposed this policy, I would have proposed another policy to push the LIRs who had not used their IPs (or pretending to use that) in favor of LIRs in the developing countries who really can't serve new customers due to lack of IP space. That is what the /22s are for: to allow newcomers (from anywhere within the region, we don't discriminate on location) access to some free IPv4 addresses. > we should not close our eyes on the approvals which were given to LIRs who got plenty of IPs, and they were supposed to use all the IPs within two years following the allocation It happens. Business plans change, market conditions change. Some people may even have lied about their needs in such a way that it is impossible to prove. Remember: allocations were made based on expected growth. Expectations often don't come true exactly the way people planned things. ISP planning often happens for 3-to-6-month periods. The 24 month estimates for allocation requests have always been difficult to judge. > , and still they have a lot of un-assigned (and even un-advertised!) ones! Advertising space in the global routing table has never been a requirement. There are use cases where unique addresses are required but don't need to be advertised. Think for example about private interconnection networks between companies. The companies will already be using all the RFC1918 space internally, so to avoid addressing conflicts the interconnect network needs unique addresses. Same as IXP space, which is often also not routed. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From payam at rasana.net Fri Jun 17 12:55:30 2016 From: payam at rasana.net (Payam Poursaied) Date: Fri, 17 Jun 2016 15:25:30 +0430 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> Message-ID: <025301d1c886$c6f394c0$54dabe40$@rasana.net> Hi Sander It was not about allegation! It was about efficiency of policies and procedures in place during those days. Those practices led to today's situation. Statistics are clear. See who is selling, who is buying and which LIR still has un-assigned/un-advertised/no-traffic IP blocks. >People with demand for a /22 can set up their own LIR. No need to let someone else set up an LIR and just sell the space The way I interpret the proposal is: it only address part of the problem! And by partially handling the problem, you would not be able to help the internet community. I would suggest to look at the problem from a wider angel. The issue is lack of IPv4 for those who need IPv4! I emphasize: it is not "lack of IPv4" only! It is "lack of IPv4 for those who need". As I believe there are still enough IPv4 but they is not well and fair distributed! While there are IPv4 for sale and trades get happened, it means still there are enough IP :) You are more knowledgeable than me in IPv4 space utilization. You must have seen heat-maps of IPv4 usage. Your point on use cases which do not need having the allocated blocks advertised makes sense, but the portion of such uses cases might not be considerable. And I would love to hear from IP analysts that how often they have the approved allocations based on such use cases (i.e. size-wise) > People with demand for a /22 can set up their own LIR. No need to let someone else set up an LIR and just sell the space. > That is what the /22s are for: to allow newcomers (from anywhere within the region, we don't discriminate on location) access to some free IPv4 addresses. Sander, Please let me know who are the buyers in the current market? The new LIR? Or the existing ISPs who do not have enough IP to server their customers. My point was the demand is there in the market. By this proposal, nothing happens to solve the main issue but it moves the money direction to those who hold IP space from long time ago. If an ISP need IP, it wold purchase! No question! Unless the pricing make the business plan out of balance. So this proposal would not help the eco system. It only causes price increase and those who can benefit from selling IP blocks. Please look to this problem as a "system dynamic" problem. Buy putting some restriction in a part of eco system, without tackling the real problem, nothing would get better. > It happens. Business plans change, market conditions change. Some people may even have lied about their needs in such a way that it is impossible to prove. Remember: allocations were made based on expected growth. Expectations often don't come true exactly the way people planned things. ISP planning often happens for 3-to-6-month periods. The 24 month estimates for allocation requests have always been difficult to judge. In response to this par of you email: 1- That is the most easiest way of justifying. why not to create and enforce policies which return the not-in-time-used-ip-blocks-beacuase-of-business-plans-change-and-market-cond itions-change o the free pool? 2- for sure nobody can judge before something happens. But when it happens, it could be judged. So after 24-month period you can judge, and there are lots of over-2-year allocations which could be studies :) 3-my understanding is the whole proposed policy is based on pre-judgment. It wanted to prevent the speculation of IPv4 which is fine, but how do you know that those who received blocks after September 14th 2012 are speculators? Their business plans could get changed. Their market could get changed as well. Quite similar to what you said. 4- Also as Arash mentioned, why do you want to only make the recent allocations unattractive for speculation, please make the whole allocations unattractive for such purpose:) My suggesting is instead of removing the main problem (i.e. "lack of IPv4 for those who need"), please bring policies on the table which help those who really require IP, can get IP. Best Regards -Payam -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sander Steffann Sent: June 17, 2016 2:29 PM To: Payam Poursaied Cc: address-policy-wg at ripe.net Working Group Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Sorry, got bumped into and accidentally hit Send before I was done :) Here is the rest: Hi Payam, > My point of view is such policies in practice would punish the > newcomers rather than those who got plenty of resources in the old days [probably without proper justification] I remember the days which our LIR was negotiating with a RIPE NCC IP analyst and he declined our request although we had proved that our need was even more than what we submitted in our application, and eventually the block which he approved was less than what we requested. > And at those time, some other western LIRs got their IP blocks. Please don't make allegations like that. I have worked for western LIRs and we had exactly the same process and issues as everybody else. > These days we are trying to buy new IP blocks, and those LIRs are selling! > > That funny story is the real story! While the proposed policy looks very rational, but it is not going to solve the issue! > The demand is there so the market will find a way to satisfy the demand! People with demand for a /22 can set up their own LIR. No need to let someone else set up an LIR and just sell the space. > If I were the gentleman who proposed this policy, I would have proposed another policy to push the LIRs who had not used their IPs (or pretending to use that) in favor of LIRs in the developing countries who really can't serve new customers due to lack of IP space. That is what the /22s are for: to allow newcomers (from anywhere within the region, we don't discriminate on location) access to some free IPv4 addresses. > we should not close our eyes on the approvals which were given to LIRs > who got plenty of IPs, and they were supposed to use all the IPs > within two years following the allocation It happens. Business plans change, market conditions change. Some people may even have lied about their needs in such a way that it is impossible to prove. Remember: allocations were made based on expected growth. Expectations often don't come true exactly the way people planned things. ISP planning often happens for 3-to-6-month periods. The 24 month estimates for allocation requests have always been difficult to judge. > , and still they have a lot of un-assigned (and even un-advertised!) ones! Advertising space in the global routing table has never been a requirement. There are use cases where unique addresses are required but don't need to be advertised. Think for example about private interconnection networks between companies. The companies will already be using all the RFC1918 space internally, so to avoid addressing conflicts the interconnect network needs unique addresses. Same as IXP space, which is often also not routed. Cheers, Sander From jim at rfc1035.com Fri Jun 17 13:06:02 2016 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Jun 2016 12:06:02 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <025301d1c886$c6f394c0$54dabe40$@rasana.net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> Message-ID: <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> > On 17 Jun 2016, at 11:55, Payam Poursaied wrote: > > why not to create and enforce > policies which return the > not-in-time-used-ip-blocks-beacuase-of-business-plans-change-and-market-cond > itions-change o the free pool? Feel free to write up and submit a policy proposal along these lines since it seems to be something that matters to you. IMO such a policy would be impractical, expensive to implement, easy to subvert and unlikely to result in much IPv4 space getting returned for reallocation. But maybe you know something I don?t. Even if space was returned from this hypothetical policy, it still doesn?t resolve anything. We still run out of IPv4 because there?s not enough of it. At best, all your policy might achieve is delay complete v4 exhaustion at the NCC by a couple of weeks. Then what? From sander at steffann.nl Fri Jun 17 13:19:54 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 13:19:54 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <025301d1c886$c6f394c0$54dabe40$@rasana.net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> Message-ID: <2EE8C5FB-AB8A-4DBE-B914-53E9DA192F65@steffann.nl> Hi, > My suggesting is instead of removing the main problem (i.e. "lack of IPv4 > for those who need"), please bring policies on the table which help those > who really require IP, can get IP. I wish we could, but IPv4 has run out. If we went back to the previous allocation policy and would hand out addresses from the pool based on bed then that pool would be empty in a month or two, and then we would be in a worse situation than we are now because then even handing out a /22 to a new LIR would be impossible. We allowed transfers to get unused allocations back in use. If you need more than your /22 then that is where you need to go. RIPE NCC doesn't have enough addresses to give everybody what they want. Cheers, Sander From payam at rasana.net Fri Jun 17 13:31:30 2016 From: payam at rasana.net (Payam Poursaied) Date: Fri, 17 Jun 2016 16:01:30 +0430 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2EE8C5FB-AB8A-4DBE-B914-53E9DA192F65@steffann.nl> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <2EE8C5FB-AB8A-4DBE-B914-53E9DA192F65@steffann.nl> Message-ID: <027101d1c88b$ce78af00$6b6a0d00$@rasana.net> Hi Sander Thank you for your reply > We allowed transfers to get unused allocations back in use. If you need more than your /22 then that is where you need to go. RIPE NCC doesn't have enough addresses to give everybody what they want. So, let's keep the transfers and not restrict part of that. Also 24-month lock after transfer is still there. And once more, you know the eco system better. Please consider the whole system. In the supply-demand market is there. This proposal would create a second grade IP blocks and bring more trade games in -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sander Steffann Sent: June 17, 2016 3:50 PM To: Payam Poursaied Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Hi, > My suggesting is instead of removing the main problem (i.e. "lack of > IPv4 for those who need"), please bring policies on the table which > help those who really require IP, can get IP. I wish we could, but IPv4 has run out. If we went back to the previous allocation policy and would hand out addresses from the pool based on bed then that pool would be empty in a month or two, and then we would be in a worse situation than we are now because then even handing out a /22 to a new LIR would be impossible. We allowed transfers to get unused allocations back in use. If you need more than your /22 then that is where you need to go. RIPE NCC doesn't have enough addresses to give everybody what they want. Cheers, Sander From payam at rasana.net Fri Jun 17 13:47:16 2016 From: payam at rasana.net (Payam Poursaied) Date: Fri, 17 Jun 2016 16:17:16 +0430 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> Message-ID: <027901d1c88e$01b81ed0$05285c70$@rasana.net> Hi Jim Thank you for sharing your viewpoint. I'm not as knowledgeable as Sander to comment on possibility of the implementing and enforcing such policy, but not being able to do so, does not mean not to react to the policy which might not lead to its original intention. Let's think for a better way to make it work for everybody and allow more people on the earth to gain access to the Internet. Best Regards -Payam -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: June 17, 2016 3:36 PM To: Payam Poursaied Cc: RIPE Address Policy WG List Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) > On 17 Jun 2016, at 11:55, Payam Poursaied wrote: > > why not to create and enforce > policies which return the > not-in-time-used-ip-blocks-beacuase-of-business-plans-change-and-market-cond > itions-change o the free pool? Feel free to write up and submit a policy proposal along these lines since it seems to be something that matters to you. IMO such a policy would be impractical, expensive to implement, easy to subvert and unlikely to result in much IPv4 space getting returned for reallocation. But maybe you know something I don?t. Even if space was returned from this hypothetical policy, it still doesn?t resolve anything. We still run out of IPv4 because there?s not enough of it. At best, all your policy might achieve is delay complete v4 exhaustion at the NCC by a couple of weeks. Then what? From jim at rfc1035.com Fri Jun 17 14:05:30 2016 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Jun 2016 13:05:30 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <027901d1c88e$01b81ed0$05285c70$@rasana.net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> <027901d1c88e$01b81ed0$05285c70$@rasana.net> Message-ID: > On 17 Jun 2016, at 12:47, Payam Poursaied wrote: > > Let's think for a better way to make it work for everybody and allow more people on the earth to gain access to the Internet. Indeed. That better way is already here. It?s called IPv6. The effort that?s being wasted here haggling over the dregs of v4 would be better spent deploying IPv6. From sebastian at karotte.org Fri Jun 17 14:39:50 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 17 Jun 2016 14:39:50 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <025301d1c886$c6f394c0$54dabe40$@rasana.net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> Message-ID: <20160617123950.GA23322@danton.fire-world.de> * Payam Poursaied [2016-06-17 13:00]: > My suggesting is instead of removing the main problem (i.e. "lack of IPv4 > for those who need"), please bring policies on the table which help those > who really require IP, can get IP. THERE. IS. NO. IPv4. LEFT! Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From sebastian at karotte.org Fri Jun 17 14:52:57 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 17 Jun 2016 14:52:57 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <20160617125257.GB23322@danton.fire-world.de> * Remco van Mook [2016-06-16 16:18]: > > Thank you Marco. > > Dear all, > > I would encourage everyone to carefully read this second version > (and not just respond "no, still hate it, kill it with fire") as it > is quite different from the first version. > > Basically the only restriction left is to disallow transfers on all > "last /8 space"* going forward, and there is some language added to > the policy that tries to raise awareness that if you just go and > parcel out that entire allocation to endusers, you might end up > feeling a little bit silly a couple of years from now. Hello, I support the proposal. The /22 policy was made so that new LIRs can implement transition methods from IPv4 to IPv6. If the LIR merges or is acquired they can keep the space. If they stop business they don't need the transition methods any more because *they're no longer in business*. I'm aware that this is not an ideal solution but I think it will make it more difficult to game the system for profit. I'm saying this fully aware that I and others would have a lot less headaches if we would just remove the limits of the last /8 policy and let everything go down in flames. Our LIR has enough address space left but right now I still have it in me to try making sure that new LIRs get some address space that is useful for them to provide services. NOT for some shadow LIRs that just want to make profit from the space. If you're doing this you get no sympathy from me. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From payam at rasana.net Fri Jun 17 15:10:26 2016 From: payam at rasana.net (Payam Poursaied) Date: Fri, 17 Jun 2016 17:40:26 +0430 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160617123950.GA23322@danton.fire-world.de> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> Message-ID: <02e501d1c899$a0cac5d0$e2605170$@rasana.net> Hi Sebastian By RIPE NCC policy definition you are right. In reality there IPv4. If there wasn't, there shouldn't have been IPv4 trades. When demands could not get satisfied, then there won't be anymore IPv4 -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sebastian Wiesinger Sent: June 17, 2016 5:10 PM To: Payam Poursaied Cc: 'Sander Steffann' ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) * Payam Poursaied [2016-06-17 13:00]: > My suggesting is instead of removing the main problem (i.e. "lack of > IPv4 for those who need"), please bring policies on the table which > help those who really require IP, can get IP. THERE. IS. NO. IPv4. LEFT! Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From me at payam124.com Fri Jun 17 15:13:46 2016 From: me at payam124.com (Payam Poursaied) Date: Fri, 17 Jun 2016 17:43:46 +0430 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> <027901d1c88e$01b81ed0$05285c70$@rasana.net> Message-ID: <02e901d1c89a$18a54c60$49efe520$@payam124.com> So let's not spend on this proposal and spend on deploying IPv6 which is the better way. -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jim Reid Sent: June 17, 2016 4:36 PM To: Payam Poursaied Cc: RIPE Address Policy WG List Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) > On 17 Jun 2016, at 12:47, Payam Poursaied wrote: > > Let's think for a better way to make it work for everybody and allow more people on the earth to gain access to the Internet. Indeed. That better way is already here. It?s called IPv6. The effort that?s being wasted here haggling over the dregs of v4 would be better spent deploying IPv6. From mschmidt at ripe.net Fri Jun 17 16:50:07 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 17 Jun 2016 16:50:07 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <5762C5B3.7070402@foobar.org> Message-ID: Dear Nick, Radu and colleagues, Thank you for raising this question. On 2016-06-16 17:28:51 CET, Nick Hilliard wrote: > rather than speculating, maybe someone from the RIPE NCC could provide > information on how much address space has been returned to the registry > over the last couple of years? The overall number that Radu calculated is almost correct. Around 4.5 million IPs have been returned since we reached the last /8 in September 2012. Looking at LIRs only, around 1.66 million IPs have been returned by our members. This consists of around 1.6 million allocated addresses and 63,000 assigned addresses from 930 different LIRs. The majority of these returns came from the closure of LIR accounts. After a quarantine period, returned address space is added to our available IPv4 pool and will be allocated according to the policy. I hope this helps. Kind regards Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From gert at space.net Fri Jun 17 17:01:28 2016 From: gert at space.net (Gert Doering) Date: Fri, 17 Jun 2016 17:01:28 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <466580db-8b7b-b584-5397-6141fa980f78@wirem.net> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> <20160617074128.651f15f6@echo.ms.redpill-linpro.com> <466580db-8b7b-b584-5397-6141fa980f78@wirem.net> Message-ID: <20160617150128.GR79185@Space.Net> Hi, On Fri, Jun 17, 2016 at 08:09:11AM +0200, Riccardo Gori wrote: > > Uhm, so what about your 2015-01 proposal then? That one "applied > > retroactively" no less than this one. > I don't think 2015-01 apply retroactively. > I think allocation made before implementation of 2015-01 are free from > limitations. Both do not apply retroactively, as in "transfers that happened before the proposal came into effect are nullified". Both proposal *do* apply to all *future* transfers - regardless of the allocation date of the to-be-transferred address space. This is the way our policy changes have always worked: affecting future *actions* to be done with numbers. Only one single proposal ever affected pre-existing assignments in a big way, 2007-01 - and that was seen as necessary (and in hindsight, given the amount of attempted fraud regarding address blocks, it was a very good decision). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From contact at prager-it.com Fri Jun 17 19:32:50 2016 From: contact at prager-it.com (Stefan Prager) Date: Fri, 17 Jun 2016 19:32:50 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: Message-ID: Dear colleagues, I suggest to just look at the facts here. Local Internet Registries(LIRs) before the 15th September 2012 have received Provider Aggregatable(PA) allocations from the RIPE NCC. Local Internet Registries after the 14th September 2012 have also received Provider Aggregatable(PA) allocations from the RIPE NCC. There is no mention in the Service Agreement that allocations provided after 14th September 2012 are to be treated differently than those handed out before the 15th September 2012. There is also no mention in the respective policies, as was mentioned during one of the talks at RIPE-72 in Denmark, that allocations received after the 14th September 2012 are to be used for the sole purpose of providing legacy connections to IPv4 networks. Therefore it seems inconceivable that this proposal is allowed to go forward any longer than it already has as it would seek to single out already heavily disadvantaged members even more for the sole reason that they happen to be holding an allocation received after the 14th September 2012. Fellow policy shaping participants, I believe we have several options here: a) Modify this proposal to forbid all types of transfers including mergers and acquisitions. This will provide a level playing field for all RIPE NCC members and not single out members solely on the fact that they have received an allocation after the 14th September 2012. b) Modify this proposal to change the allocation status only for new allocations allocated after this proposal has been accepted and implemented. c) Declare that no consensus has been reached. Additionally I would like to mention that some people seem to think that this proposal will stifle the Local Internet Registry application rate. Let me assure you, it will not. Those of you that believe that this would be the result of the acceptance of this proposal don't fully grasp the reality of the situation we are in. People currently need IPv4 resources to run a business. They don't need IPv6 resources yet and won't be requiring IPv6 resources for the foreseeable future either. A business is required to take the necessary steps to secure their survival and let me assure you they will do just that, just as any business should. Now where do we go from here? I am in favour of making sensible policies that will provide IPv4 address space for the foreseeable future for new members however this proposal is certainly not a way to achieve that as it does not solve the problem at hand. I have been giving this quite some thought which is the reason why I will be putting forward the following proposal within the next week: => Lower the initial allocation a new RIPE NCC member receives down to a /24. => A new member may request an additional /24 every twelve months until he has reached a /22. For aggregation purposes the RIPE NCC will reserve a consecutive /22 for as long as it is possible so new members may reach a consecutive /22 after they have requested four /24 subnets over a time span of four years. Additionally, as I understand it this is something that needs to be voted on, I would like to lower the initial signup fee of currently 2000,00 Euros down to just 500,00 Euros. In case they request an additional /24 after twelve months they will need to pay an additional instalment of 500,00 Euros which will bring the total amount still to 2000,00 Euros if they requested 4x /24 allocations over a period of 4 years. After each allocation the RIPE NCC will aggregate the allocation whenever possible. Subsequently if a new member requests a second /24 the allocation will be enlarged to a /23. In the end he will be left with one /22 if there is sufficient consecutive address space left to do so. In cases where the Local Internet Registry does not require any IPv4 address space it should also not be required to pay any fees apart from the membership fees. Kind Regards, Stefan Prager -- Prager-IT e.U. VAT Number: ATU69773505 Austrian Company Register: 438885w Skype: Prager-IT contact at prager-it.com +43 680 300 99 80 Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From remco.vanmook at gmail.com Fri Jun 17 21:09:21 2016 From: remco.vanmook at gmail.com (Remco van Mook) Date: Fri, 17 Jun 2016 21:09:21 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> Hi Stefan, > On 17 Jun 2016, at 19:32 , Stefan Prager wrote: > > There is no mention in the Service Agreement that allocations provided after 14th September 2012 are to be treated differently than those handed out before the 15th September 2012. There is also no mention in the respective policies, as was mentioned during one of the talks at RIPE-72 in Denmark, that allocations received after the 14th September 2012 are to be used for the sole purpose of providing legacy connections to IPv4 networks. > > Therefore it seems inconceivable that this proposal is allowed to go forward any longer than it already has as it would seek to single out already heavily disadvantaged members even more for the sole reason that they happen to be holding an allocation received after the 14th September 2012. Let me get this straight - you oppose a proposed change in policy because the change itself is not part of current policy? Also, those "heavily disadvantaged members" as you describe them, only have received address space thanks to a particularly selfless decision by the community at the time to dedicate the last remaining address space to that purpose, rather than just blowing through it by early 2013. Remco heavily disadvantaged member -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ripe-wgs at radu-adrian.feurdean.net Fri Jun 17 22:18:08 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 17 Jun 2016 22:18:08 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> Message-ID: <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> On Fri, Jun 17, 2016, at 21:09, Remco van Mook wrote: > Let me get this straight - you oppose a proposed change in policy because > the change itself is not part of current policy? No, more people than you expected oppose it because you make an explicit reference to allocation made after a certain date in the past: All allocations made by the RIPE NCC to LIRs after 14 September 2012 will be marked in the RIPE Database as ?ALLOCATED FINAL?. Just remove "after 14 September 2012" and you ban all transfers. Not necessarily a bad idea. > Also, those "heavily disadvantaged members" as you describe them, only > have received address space thanks to a particularly selfless decision by > the community at the time to dedicate the last remaining address space to > that purpose, rather than just blowing through it by early 2013. Like in "we won't kill you with a bullet in the head, we will kill you by letting you slowly bleed to death". Thanks. Now you try to regulate how you are allowed (or not) to heal yourself. -- Radu-Adrian FEURDEAN fr.ccs From sebastian at karotte.org Fri Jun 17 22:37:21 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 17 Jun 2016 22:37:21 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> Message-ID: <20160617203721.GA17344@danton.fire-world.de> * Radu-Adrian FEURDEAN [2016-06-17 22:21]: > No, more people than you expected oppose it because you make an explicit > reference to allocation made after a certain date in the past: > > All allocations made by the RIPE NCC to LIRs after 14 September 2012 > will be marked in the RIPE Database as ?ALLOCATED FINAL?. > This is the date when the last /8 policy kicked in. It could also say "all blocks allocated by the last /8 policy" or some wording like that. You must know that? Why does the date bother you? > Just remove "after 14 September 2012" and you ban all transfers. Not > necessarily a bad idea. That would revert us to back to pre-market policy. Who would want that and why? > > Also, those "heavily disadvantaged members" as you describe them, only > > have received address space thanks to a particularly selfless decision by > > the community at the time to dedicate the last remaining address space to > > that purpose, rather than just blowing through it by early 2013. > > Like in "we won't kill you with a bullet in the head, we will kill you > by letting you slowly bleed to death". Thanks. > Now you try to regulate how you are allowed (or not) to heal yourself. We can only heal everyone by moving to IPv6. There is no cure in IPv4 land. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From rgori at wirem.net Fri Jun 17 22:49:59 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 17 Jun 2016 22:49:59 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> Hi, Il 17/06/2016 19:32, Stefan Prager ha scritto: > Dear colleagues, > > I suggest to just look at the facts here. > > Local Internet Registries(LIRs) before the 15th September 2012 have received Provider Aggregatable(PA) allocations from the RIPE NCC. Local Internet Registries after the 14th September 2012 have also received Provider Aggregatable(PA) allocations from the RIPE NCC. > > There is no mention in the Service Agreement that allocations provided after 14th September 2012 are to be treated differently than those handed out before the 15th September 2012. There is also no mention in the respective policies, as was mentioned during one of the talks at RIPE-72 in Denmark, that allocations received after the 14th September 2012 are to be used for the sole purpose of providing legacy connections to IPv4 networks. > Therefore it seems inconceivable that this proposal is allowed to go forward any longer than it already has as it would seek to single out already heavily disadvantaged members even more for the sole reason that they happen to be holding an allocation received after the 14th September 2012. > > Fellow policy shaping participants, I believe we have several options here: > > a) Modify this proposal to forbid all types of transfers including mergers and acquisitions. This will provide a level playing field for all RIPE NCC members and not single out members solely on the fact that they have received an allocation after the 14th September 2012. > > b) Modify this proposal to change the allocation status only for new allocations allocated after this proposal has been accepted and implemented. > > c) Declare that no consensus has been reached. I am strongly against to every proposal that higher the disvlaantage to already disvantaged new and future pyers (LIRs after 09/2012) > > > Additionally I would like to mention that some people seem to think that this proposal will stifle the Local Internet Registry application rate. Let me assure you, it will not. Those of you that believe that this would be the result of the acceptance of this proposal don't fully grasp the reality of the situation we are in. > > People currently need IPv4 resources to run a business. They don't need IPv6 resources yet and won't be requiring IPv6 resources for the foreseeable future either. A business is required to take the necessary steps to secure their survival and let me assure you they will do just that, just as any business should. > > Now where do we go from here? I am in favour of making sensible policies that will provide IPv4 address space for the foreseeable future for new members however this proposal is certainly not a way to achieve that as it does not solve the problem at hand. > > I have been giving this quite some thought which is the reason why I will be putting forward the following proposal within the next week: > > => Lower the initial allocation a new RIPE NCC member receives down to a /24. > > => A new member may request an additional /24 every twelve months until he has reached a /22. > > For aggregation purposes the RIPE NCC will reserve a consecutive /22 for as long as it is possible so new members may reach a consecutive /22 after they have requested four /24 subnets over a time span of four years. I think this could not be easy standing on current allocation rate but we should ask registration services if techincally possible. > > Additionally, as I understand it this is something that needs to be voted on, I would like to lower the initial signup fee of currently 2000,00 Euros down to just 500,00 Euros. In case they request an additional /24 after twelve months they will need to pay an additional instalment of 500,00 Euros which will bring the total amount still to 2000,00 Euros if they requested 4x /24 allocations over a period of 4 years. After each allocation the RIPE NCC will aggregate the allocation whenever possible. Subsequently if a new member requests a second /24 the allocation will be enlarged to a /23. In the end he will be left with one /22 if there is sufficient consecutive address space left to do so. > > In cases where the Local Internet Registry does not require any IPv4 address space it should also not be required to pay any fees apart from the membership fees. This proposal is interesting and fair. You have to consider RIPE NCC techincally does not sell space. Your proposal pratically is to change the allocation model in a pay per use and this to me looks really interesting. I would apply this model to the whole IPv4 space. All the already allocated and future allocations. In Remcko view (as in 2016-03 for ALLOCATED-FINAL) starting tomorrow in a pay per use model for everyone is not retroactive 'cause is just a policy change for future year fee memberships. Stockpiles ip will vanish, so much returned space voluntary!!!! IPv4 will last very longer and Remcko will be appy and I'll be happy too. I'll pay every year my membership exacly for what I am assigning to my customers and using > > Kind Regards, > Stefan Prager > > -- > Prager-IT e.U. > VAT Number: ATU69773505 > Austrian Company Register: 438885w > > Skype: Prager-IT > contact at prager-it.com > +43 680 300 99 80 > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From sander at steffann.nl Fri Jun 17 23:11:18 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 23:11:18 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> Message-ID: <8B3179A6-4ED2-4A69-ADBD-A668AA8257A8@steffann.nl> Hi, > Like in "we won't kill you with a bullet in the head, we will kill you > by letting you slowly bleed to death". Thanks. > Now you try to regulate how you are allowed (or not) to heal yourself. I'm sorry, but this policy proposal limits selling the last /22 LIRs get from RIPE NCC. How is preventing to sell off your addresses in any way considered "healing yourself"? Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From remco.vanmook at gmail.com Fri Jun 17 23:30:03 2016 From: remco.vanmook at gmail.com (Remco van Mook) Date: Fri, 17 Jun 2016 23:30:03 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> Message-ID: <9684AB7D-D9CE-4FF0-87B3-6FF7FFD54BCD@gmail.com> Hi Radu, > On 17 Jun 2016, at 22:18 , Radu-Adrian FEURDEAN wrote: > > On Fri, Jun 17, 2016, at 21:09, Remco van Mook wrote: >> Let me get this straight - you oppose a proposed change in policy because >> the change itself is not part of current policy? > > No, more people than you expected oppose it because you make an explicit > reference to allocation made after a certain date in the past: > > All allocations made by the RIPE NCC to LIRs after 14 September 2012 > will be marked in the RIPE Database as ?ALLOCATED FINAL?. > > > Just remove "after 14 September 2012" and you ban all transfers. Not > necessarily a bad idea. > 1. I make specific reference to the date that 'final /8' came into effect in the same way it's used in current policy. It's not just some random day. If there was any other way to reference 'every allocation made under this policy' that wasn't hopelessly broken or confusing I would have done so. 2. You're making assumptions about my expectations. Please don't. 3. 2007-08 also impacted previously allocated IPv4 space in a massive way. The concept introduced in that policy is what's called 'transfers' these days. I remember because I wrote it. 4. I don't see how this piece of your response in any way relates to my question to Stefan. >> Also, those "heavily disadvantaged members" as you describe them, only >> have received address space thanks to a particularly selfless decision by >> the community at the time to dedicate the last remaining address space to >> that purpose, rather than just blowing through it by early 2013. > > Like in "we won't kill you with a bullet in the head, we will kill you > by letting you slowly bleed to death". Thanks. > Now you try to regulate how you are allowed (or not) to heal yourself. I don't understand what you're trying to say here. Who is "we", who is "you" and what does "heal yourself" mean in this context? Remco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Fri Jun 17 23:48:48 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 23:48:48 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> Message-ID: Hi Riccardo, > I am strongly against to every proposal that higher the disvlaantage to already disvantaged new and future pyers (LIRs after 09/2012) You keep bringing that up, but how is preventing those newer LIRs from selling their addresses in any way disadvantaging them? On one hand you keep saying new LIRs don't get enough address space, and on the other hand you're saying that it is bad that they can't sell their space. Which one is it? This proposal doesn't prevent new LIRs from buying address space. And if they want to buy /22s from other newer LIRs they can as easily (and cheaper) open their own second LIR. The RIPE NCC membership explicitly allowed that during the last AGM. Two scenarios: One - Someone opens up an LIR - They get their /22 (free) - They sell it off to another LIR for a profit Two - That other LIR opens up a second LIR - They get their /22 (free) - They merge that new LIR with their old LIR using M&A This policy proposal is stopping scenario One but not scenario Two. The previous version of the proposal did, but as that didn't get any support this version removed that restriction. So what is this proposal blocking for new LIRs? Not buying space, not opening up a second LIR and getting that /22 from RIPE NCC. It only limits those LIRs from *selling* their /22 for profit. I'm sorry, but if that is your business model then you are exactly the kind of business that this proposal is trying to stop. The IPv4 allocation policy has very few requirements, and one of them is that the LIR has to use it for assign addresses from. If the intention is to sell those addresses then you are already in violation of the current policy. That is *NOT* why you were given that /22 in the first place. And as far as judging consensus goes, arguments that boil down to "I am currently violating the policy by requesting my /22 for the wrong reasons, and this proposal is stopping me from doing that" will not be taken into account. There are plenty of other arguments that need to be discussed, like the potential impact on the accuracy of the registry that Nick brought up. But there is too much FUD and noise in this discussion. I don't mind if you send opposing arguments, but as I have said before I do care about the quality of the discussion. If you respond this policy in its current form then I'd like to see good argumentation with concrete examples of issues, not some hand-waving like "this is disadvantaging new LIRs" without any explanation of how that exactly would work. Then we have something to discuss that people can respond to. Consensus building works by explaining the issues and people trying to address them. Pretend I'm stupid and spell it out for me :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Fri Jun 17 23:52:30 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 23:52:30 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <58F491E8-9EA5-443E-B4F4-D7FB6E395CC8@steffann.nl> Hello Stefan, > Therefore it seems inconceivable that this proposal is allowed to go forward any longer than it already has Excuse me, but that is not your call to make. Sander APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Fri Jun 17 23:58:53 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jun 2016 23:58:53 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: Hi Stefan, > Additionally, as I understand it this is something that needs to be voted on, I would like to lower the initial signup fee of currently 2000,00 Euros down to just 500,00 Euros. In case they request an additional /24 after twelve months they will need to pay an additional instalment of 500,00 Euros which will bring the total amount still to 2000,00 Euros if they requested 4x /24 allocations over a period of 4 years. After each allocation the RIPE NCC will aggregate the allocation whenever possible. Subsequently if a new member requests a second /24 the allocation will be enlarged to a /23. In the end he will be left with one /22 if there is sufficient consecutive address space left to do so. > > In cases where the Local Internet Registry does not require any IPv4 address space it should also not be required to pay any fees apart from the membership fees. Membership fees are out-of-scope for the RIPE Address Policy Working Group. The RIPE community makes the policy, the RIPE NCC and its members determine the membership fees. This working group is part of the RIPE community and not involved in setting membership fees. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ripe-wgs at radu-adrian.feurdean.net Sat Jun 18 00:03:02 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 18 Jun 2016 00:03:02 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160617203721.GA17344@danton.fire-world.de> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> <20160617203721.GA17344@danton.fire-world.de> Message-ID: <1466200982.2447501.641076497.6D013FEB@webmail.messagingengine.com> On Fri, Jun 17, 2016, at 22:37, Sebastian Wiesinger wrote: > that. You must know that? Why does the date bother you? Because it is in the past. > That would revert us to back to pre-market policy. Who would want that and why? Those that would like all allocations to be treated the same. > We can only heal everyone by moving to IPv6. There is no cure in IPv4 land. Just stop telling me how to heal. I like your new diet, I practice it myself, but for the moment it is far from allowing me to live. In order to survive I need extras that can only be found in limited quantities. And you want to explain me how you're doing me a favor by increasing the price, while people having stocks (and putting on me pressure that makes the new diet irrelevant) can happily live ever after ... ? With 2015-05 I tried to fix the issue, but number of people in the community were against, the reason being mainly "make v4 last as long as possible". For me that reason makes it clear that IPv4 address space is meant to be the new equivalent of gold. Today, IPv6 is only a distraction, in the next years a "possible but unlikely option" and *AN* alternative in the future. But it will not become *THE* solution before IPv4 availability goes to ZERO (0.000000, not 0.1 or 0.01 or even 0.001). Trying to explain me that on 14 Sept 2022 a new start-up (especially a content-related one) will legitimately need a /22 worth of provider-agnostic IPv4 space *ALONE* (i.e. IPv6 still as optional as today), for me it seems exaggerate. Same thing on 14 Sept 2027 (regardless of the allocation size) is totally unacceptable. Even today I find it hard to hear "save v4 for future entrants" with no incentive (or even obligation) to deploy v6. As for the market, today, mid-2016, the market doesn't have any explicit need for IPv6. On the contrary, the market *DOES* require IPv4 explicitly : no v4 = no business (mostly because "static public IPv4 address required"). Best case, very optimistic scenario, "not enough business". At least in my area and most of my market. I would be interested to hear the situation in other areas/markets : do a customer that is only give IPv6 stay with you for more than 1 year by using the service and never calling the support ? I have examples with IPv4-only (they ignore v6, some voluntarily, some not) customers. I also have customers that explicitly request IPv6 to be disabled (most likely because they don't know how to dot it themselves). IPv6 is only acceptable as long as it comes together with IPv4. But that doesn't meant that it will be used. So yes, I oppose this policy as I oppose by principle anything that: - changes the rules selectively, especially based on age (my most important no-go for 2016-03) - does it retroactively - tries to unbalance even more an already unbalanced market -- Radu-Adrian FEURDEAN fr.ccs From sebastian at karotte.org Sat Jun 18 00:54:05 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Sat, 18 Jun 2016 00:54:05 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466200982.2447501.641076497.6D013FEB@webmail.messagingengine.com> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> <20160617203721.GA17344@danton.fire-world.de> <1466200982.2447501.641076497.6D013FEB@webmail.messagingengine.com> Message-ID: <20160617225405.GB17344@danton.fire-world.de> * Radu-Adrian FEURDEAN [2016-06-18 00:06]: > On Fri, Jun 17, 2016, at 22:37, Sebastian Wiesinger wrote: > > that. You must know that? Why does the date bother you? > > Because it is in the past. Yesterday is in the past but it doesn't bother me because today is weekend. *Why* does it bother you? > > That would revert us to back to pre-market policy. Who would want that and why? > > Those that would like all allocations to be treated the same. Which would make us run out in a few days. We've discussed this multiple times. > > We can only heal everyone by moving to IPv6. There is no cure in IPv4 land. > > Just stop telling me how to heal. I like your new diet, I practice it > myself, but for the moment it is far from allowing me to live. In order > to survive I need extras that can only be found in limited quantities. > And you want to explain me how you're doing me a favor by increasing the > price, while people having stocks (and putting on me pressure that makes > the new diet irrelevant) can happily live ever after ... ? I have no idea what you mean. Seriously. What price? > With 2015-05 I tried to fix the issue, but number of people in the > community were against, the reason being mainly "make v4 last as long as > possible". For me that reason makes it clear that IPv4 address space is > meant to be the new equivalent of gold. Today, IPv6 is only a > distraction, in the next years a "possible but unlikely option" and *AN* > alternative in the future. But it will not become *THE* solution before > IPv4 availability goes to ZERO (0.000000, not 0.1 or 0.01 or even > 0.001). No, not "make v4 last as long as possible" but "make it possible for new entrants to get a small piece of v4 as long as possible". That is a difference. This pool has no impact on the transfer market. Perhaps you can find your "gold" there. > Trying to explain me that on 14 Sept 2022 a new start-up (especially a > content-related one) will legitimately need a /22 worth of > provider-agnostic IPv4 space *ALONE* (i.e. IPv6 still as optional as > today), for me it seems exaggerate. Same thing on 14 Sept 2027 > (regardless of the allocation size) is totally unacceptable. Even today > I find it hard to hear "save v4 for future entrants" with no incentive > (or even obligation) to deploy v6. I don't exactly understand what you mean. You can't force people to deploy IPv6. A content start-up in 2022 will need to deploy IPv6 to reach the people on the Internet that only have IPv6. > As for the market, today, mid-2016, the market doesn't have any explicit > need for IPv6. On the contrary, the market *DOES* require IPv4 > explicitly : no v4 = no business (mostly because "static public IPv4 > address required"). Best case, very optimistic scenario, "not enough > business". At least in my area and most of my market. I would be > interested to hear the situation in other areas/markets : do a customer > that is only give IPv6 stay with you for more than 1 year by using the > service and never calling the support ? I have examples with IPv4-only > (they ignore v6, some voluntarily, some not) customers. I also have > customers that explicitly request IPv6 to be disabled (most likely > because they don't know how to dot it themselves). IPv6 is only > acceptable as long as it comes together with IPv4. But that doesn't > meant that it will be used. As I said, you can't force people to adopt IPv6. They will see that they cannot reach their customers very well with IPv4 only in the future. We have many customers that have deployed IPv6 right now exactly because of this. Services that depend on end-to-end reachability (for example some VPN services) don't work very well with DS-Lite and CGNs. As many people have stated, if your new business depends on large quantities of IPv4 space it will fail. That is nothing we can change. Almost all our customers need IPv4 but most of them only need a very small space for addressing their services. If you need more IPv4 you will need to to NAT (CGN) or other workarounds. > So yes, I oppose this policy as I oppose by principle anything that: > - changes the rules selectively, especially based on age (my most > important no-go for 2016-03) The date is the activation of the last /8 pool. It has nothing to do with the "age" of the aggregation only the addresses in the pool. > - does it retroactively As was stated it will not change any transfers retroactively. It will only apply to future transfers as it always has been with transfer policy. > - tries to unbalance even more an already unbalanced market How does it unbalance the market? It is quite a small pool. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From ripe-wgs at radu-adrian.feurdean.net Sat Jun 18 01:22:47 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 18 Jun 2016 01:22:47 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> Message-ID: <1466205767.2465469.641121201.7A8C10F4@webmail.messagingengine.com> On Fri, Jun 17, 2016, at 23:48, Sander Steffann wrote: > Two scenarios: > > One > - Someone opens up an LIR > - They get their /22 (free) > - They sell it off to another LIR for a profit > > Two > - That other LIR opens up a second LIR > - They get their /22 (free) > - They merge that new LIR with their old LIR using M&A Three: - That other LIR opens up a second LIR - They get their /22 (free) - They can no longer apply "M&A" because the definition of "M&A" changed, and they have to do a regular transfer. On a general basis, there may be reasons for which you have to proceed with a regular transfer, other than "get IPs from NCC in order to sell them". It is my understanding, and please someone from RIPE NCC confirm or infirm that in public, that M&A has "slightly" changed recently, and the following operations are no longer M&A: - merging several existing LIRs having the same owner. - re-organisation of address space between the LIRs of a group. - purchasing a company but keeping the purchased company's legal entity (you accountant will give you good reasons for this; if you live in counties like France, your HR will give a few more reasons). - putting together resources of several entities within a group without proceeding with heavy legal and administrative paperwork. > So what is this proposal blocking for new LIRs? Not buying space, not > opening up a second LIR and getting that /22 from RIPE NCC. It only > limits those LIRs from *selling* their /22 for profit. For allocations prior to the unlikely application of the policy, it only gives one shot for some business processes. For those made after that hypothetic date, zero. Unless someone from RIPE NCC (registration services or board preferred) can infirm my understanding of recent M&A changes. > currently violating the policy by requesting my /22 for the wrong reasons Policy-wise, there are no "wrong reasons". If we decide to create them however, there are two possibilities : - all allocations done *AFTER* the application of "wrong reasons policy" would be concerned. Not those done before. - in addition to the above, if we want to apply this to transferred space, *ALL* space transferred (regardless of the initial allocation date) should be concerned. > examples of issues, not some hand-waving like "this is disadvantaging new > LIRs" without any explanation of how that exactly would work. Then we See my comment above, under reserve of validation from NCC staff: - "old LIR" got a /20 on Aug 2012. They never needed to pay more than one membership fee - "new company #1" /22 on July 2015, another one on Dec 2015 (on a sister company) and anther one on June 2016 (another sister company, since "additional" LIRs is still not officially reinstated). Due to the new M&A rules, the ressources have to be transferred (regular transfer) in order for the LIRs to be consolidated. If 2016-03 goes "live" before July 2017, "new company #1" is stuck with 3 memberships forever for less space the "old LIR". - "new company #2" did similar things to "new company #1", just at different dates (2014/10 and 2015/09) and on the same legal entity. Not having had enough time to sort out the merger due to "have to run a business" they can no longer do the merge today and have to wait until 2016/10, provided that 2015-03 does not go live by then. If for the same reasons the merger is left over until after 2016-03 goes live, they will also have to stay with 2 memberships forever. - "new company #3" which just got their /22 will face the risk of having to pay one membership per /22 forever. -- Radu-Adrian FEURDEAN fr.ccs From rgori at wirem.net Sat Jun 18 05:54:58 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 18 Jun 2016 05:54:58 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> Message-ID: <245f8b8d-973f-52aa-59be-784a6a6be8b9@wirem.net> Sorry Sander, thank you for your reply. I didn't reply to your first email 'cause i was busy. That's why my comment could not be understood at this time. I'll reply to your first email in reply to mine and I'll get here later.. regards Riccardo Il 17/06/2016 23:48, Sander Steffann ha scritto: > Hi Riccardo, > >> I am strongly against to every proposal that higher the disvlaantage to already disvantaged new and future pyers (LIRs after 09/2012) > You keep bringing that up, but how is preventing those newer LIRs from selling their addresses in any way disadvantaging them? On one hand you keep saying new LIRs don't get enough address space, and on the other hand you're saying that it is bad that they can't sell their space. Which one is it? > > This proposal doesn't prevent new LIRs from buying address space. And if they want to buy /22s from other newer LIRs they can as easily (and cheaper) open their own second LIR. The RIPE NCC membership explicitly allowed that during the last AGM. > > Two scenarios: > > One > - Someone opens up an LIR > - They get their /22 (free) > - They sell it off to another LIR for a profit > > Two > - That other LIR opens up a second LIR > - They get their /22 (free) > - They merge that new LIR with their old LIR using M&A > > This policy proposal is stopping scenario One but not scenario Two. The previous version of the proposal did, but as that didn't get any support this version removed that restriction. > > So what is this proposal blocking for new LIRs? Not buying space, not opening up a second LIR and getting that /22 from RIPE NCC. It only limits those LIRs from *selling* their /22 for profit. > > I'm sorry, but if that is your business model then you are exactly the kind of business that this proposal is trying to stop. The IPv4 allocation policy has very few requirements, and one of them is that the LIR has to use it for assign addresses from. If the intention is to sell those addresses then you are already in violation of the current policy. That is *NOT* why you were given that /22 in the first place. > > And as far as judging consensus goes, arguments that boil down to "I am currently violating the policy by requesting my /22 for the wrong reasons, and this proposal is stopping me from doing that" will not be taken into account. There are plenty of other arguments that need to be discussed, like the potential impact on the accuracy of the registry that Nick brought up. But there is too much FUD and noise in this discussion. > > I don't mind if you send opposing arguments, but as I have said before I do care about the quality of the discussion. If you respond this policy in its current form then I'd like to see good argumentation with concrete examples of issues, not some hand-waving like "this is disadvantaging new LIRs" without any explanation of how that exactly would work. Then we have something to discuss that people can respond to. Consensus building works by explaining the issues and people trying to address them. Pretend I'm stupid and spell it out for me :) > > Cheers, > Sander > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Sat Jun 18 07:11:06 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 18 Jun 2016 07:11:06 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <4ABC9CB5-5B45-4C58-97C9-C7EA7E5F908E@steffann.nl> References: <4ABC9CB5-5B45-4C58-97C9-C7EA7E5F908E@steffann.nl> Message-ID: Hi Sander, thank you for your reply Il 17/06/2016 00:59, Sander Steffann ha scritto: > Hi Riccardo, > > I'm sorry, but there is some FUD here that I need to address. Again: I don't care whether this policy gets consensus or not, but I do care about the quality of the arguments. That is what Gert and/or I have to base consensus on later. >> A new entrant would see his investments vanified > Address space is not an investment. The only reasons transfers were allowed in the first place (and this was not an easy decision back then) is to keep the database information accurate and to get some unused address space back in use. About investements: To set up my ISP I needed networking, infrastructure, IP transit, hosting services, IP addresses. I payed a signup fee and that was an investement to be an LIR and do better business as an ISP. I pay annualy a membership fees and this is part of the costs to run the business. if I look to my management server (a couple of server hotsed outside my network) I see that I pay 16 ? per month for a /29 as part of the contract with my hosting provider... so actually yes IP space is a small part of the investements or costs in any case. About transferts: The same is today. Main reasons for a transfert are not renumbering and database consistence or unused IPs? Unused Ips is not my case I have so few. This proposal puts the new LIRs in a worse condition even it already is. We are not SICK, we are late entrants. I don't see any reason to create CLASS-E "unusable LIRs" to keep them far from the IP market old LIRs created. Policies are making possibile every kind of transfert, inter RIR, PA, PI and so on and what? all of this for LIRs holding stockpiled space? The rules are there. If we change the rule change it for everyone and you'll find me really in favor of that. >> by a rule that make possibile transferts possbile only for old LIRs that acquired space before 09/2012 >> With this policy any new LIR would be out of the market before entering it. > No, new LIRs get exactly the same "free" /22 as before. Only now they can not transfer/sell it, they can use it to run their network with. That is not pushing new LIRs out of the market. Unless your business is to sell off address space. In that case: that is what this proposal is trying to prevent, so the remaining address space is saved for organisations that run Are you really thinking that I came out with a proposal like 2015-05 to catch more IPs to sell them? I am not selling IPs 'cause i need them for assignements to customers but the first thing my they ask me when I propose consulting for IPv6 trasnition is "can I have the assigned space for me one day to keep on running the network" And what I aswer normally is "I surely can make you and IPv6 ALLOCATED-BY-LIR; for IPv4 let's see what happens maybe in the future you won't need, let's see" >> I didn't look deeply because I have no time for family reasons now but I am pretty sure that I can find easily in the list archive that IP Transfert policies were accepted even 'cause in case of network acquisition or M&A or many other cases renumbering customers is very difficoult, and having ability to transfert resources is the most easy way to keep consistence on database. > We still have M&A for cases where businesses split up, merge, get sold etc. That is not affected by this policy proposal. The evidence of a disvantage of newcomers is still there. Black market will substitute normal transfert regulations and creative implementations of M&A will come to overcome the policy, transparency will go far from database and statistics and transfert evidence. You want all of this? >> We were in Bucarest when celebrating Romania as the biggest transfert country were JUMP Management choosed to sell to its customers their allocation making them able to keep their business running! > An LIR assigns addresses to its customers. That is how the allocation/assignment model works. Selling PA addresses isn't part of that. And besides: you can only sell allocations to other LIRs, so those "customers" have to be LIRs anyway, so they can get their own /22. Again, selling PA is out there and there are many here on the list proud of it. We were in Bucarest celebrating this good manner of JUMP Management making space available to their end users signin up as new members. Second: avoid my customers to sign up and waste a /22 while needing only a /24 was exacly the purpose of 2015-05 I tried to explain everyone (with Radu who shared the same point about this) that many customers are signin up wasting space just for the needing of a /24. This customer is mine not yours. And what you want me to have no address space to serve him so we can let him create his own LIR? He is in a completely different kind of business nothing to deal with internet but the use!!!! In your opinion I have to force him to be like me, so the day after he can kid me like someone did on the list about the big space we hold? Don't say that lovering first allocation to /23 or /24 solve the problem beacuse you already know that this makes only my customers indipendent from me. This means put every newcomer LIRs after 14/09/2012 out of the market You want my customers equal to me out of the internet market, but you want to keep well signed that old LIRs are sigltly different. >> How can my new LIR company can compete in the market going to its customer stating "be aware that the assignement I giving you if I sell my company will be returned and you need to find a new LIR and renumber your network, > Selling your company is M&A. That is unaffected by this policy proposal (important change in version 2), so no problem anymore. > >> and sorry most important... I will never be able to sell you this block or part of it > Where did this idea of selling customers parts of an LIRs PA space come from? The receiver of a (part of a) PA allocation has to be an LIR themselves and therefore can get their own /22 for free. Even if you want this business model then surely setting up an LIR for a customer and getting a /22 for them provides much more than selling off a part of your own /22 ever can. Just as an example? transition Sander, I repeated more than one time in this list that I have customers that ask for a /24 and IPv6 transition consulting services to run their new datacenter or multihome their networks. Perfect legitimate neeedings. Do I really need to explain any detail on the list about my business model? Want to join the smallest business? I don't think RIPE NCC need to take care of mine small business. I am really disappointed about you are treating us (new comers LIR after 14/09/2015). We don't force anything: we don't force LIRs or end user use IPv6 bla bla bla. Proposing introducing only a light control on IPv6 deployment I was adviced that every LIR is free to do what he need with space publically at RIPE72. >> End users will run far away from every new LIR choosing as default a LIR made before 09/2012. This creates barrier to ingress in the market. > Why? The LIR still has their PA allocation, can use it to provide service to customers etc. Nobody is taking a PA allocation away from the LIR. I am in doubt if RIPE NCC will go legal or illegal forcing companies to keep running or closing LIRs. >> The full control of IP market will be in the hand of LIR (and PI holders) made before 09/2012. Barriers to ingress in the market. > I'm sorry, I don't care about "the IP market". Its only purpose is to get addresses to LIRs that need them. The last /22 allocation provides new LIRs with a free block to start running their network with, not to provide them with a free asset that they can then sell for profit. RIPE is about running networks. > >> This is not leaving space to new entrants this is assuring control of IP market today. IP market is there. I would have preffered an IPv4 transfert model without it but if it has been approved so we should care about it. > New entrants become an LIR and get their /22. After that they can participate in the market of getting unused address space back in use all they want. It's not the RIPE community's job to provide them with new stuff they can sell. > > Everybody can become an LIR. Those thinking about selling parts of their /22 should think about what they are doing. If they want to help customers and provide a good service to them: help them set up an LIR if they need to (which they would also need to do to be able to receive a PA transfer). Get them their own /22 that no-one can take away from them. > >> Again: If a return policy has to be proposed this should address the whole IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and not in use. >> I am pretty sure that everyone here agree that this is not possibile... > This is not a return policy proposal, this is a policy proposal that tries to stop people from using the scarce IPv4 resources that the RIPE NCC has left for their own profit instead of for the good of the community. This is higher the disadvantage to get rid of newcomers for the reason explained above. >> About 5.1. 4. >> plase don't don't don't state in the policy that /22 is for "transition purposes" >> In 2015-05 we tried to introduce ripeness stars and IPv6 deployment as a requirement for an additional /22 and at Address Policy Working Group in Copenhagen last 25/05 some of you experienced explained to me publically that we can't force old or new LIRs to deploy IPv6 and this is even the reason why the IPv6 requirement was removed from "last /8" allocation policy. >> Someone else said it's LIR responsability to choose how to use space... IPv6 will come....bla bla bla. You teached, I learned. > Apparently there are still lots of people that don't understand that the IPv4 barrel is as good as empty. I have to admit that I do sympathise with efforts to get rid of this FUD that IPv4 can still be "business as usual". > > Cheers, > Sander Sorry my english is not so good and I didn't understood that last comment. sorry for the late reply but I was really busy these days regards Riccardo -- Ing. Riccardo Gori e-mail:rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile:https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying toinfo at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: From sander at steffann.nl Sat Jun 18 07:12:09 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 18 Jun 2016 07:12:09 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466205767.2465469.641121201.7A8C10F4@webmail.messagingengine.com> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <1466205767.2465469.641121201.7A8C10F4@webmail.messagingengine.com> Message-ID: <0313A283-8349-416E-8913-35812E326AF5@steffann.nl> Hi Radu, Thank you for providing concrete cases! This is now something that can be discussed. > Three: > - That other LIR opens up a second LIR > - They get their /22 (free) > - They can no longer apply "M&A" because the definition of "M&A" > changed, and they have to do a regular transfer. > > On a general basis, there may be reasons for which you have to proceed > with a regular transfer, other than "get IPs from NCC in order to sell > them". > > It is my understanding, and please someone from RIPE NCC confirm or > infirm that in public, that M&A has "slightly" changed recently, and the > following operations are no longer M&A: > - merging several existing LIRs having the same owner. > - re-organisation of address space between the LIRs of a group. > - purchasing a company but keeping the purchased company's legal entity > (you accountant will give you good reasons for this; if you live in > counties like France, your HR will give a few more reasons). > - putting together resources of several entities within a group without > proceeding with heavy legal and administrative paperwork. So basically what you are worried about is that RIPE NCC will not treat all M&A as M&A and might apply the transfer policy instead, and that with this proposal stopping transfers of the /22 the M&A would be blocked, causing such members to be forced to keep multiple LIRs open. Let's ask our friendly PDO to ask his colleagues within RIPE NCC how the cases you mention would be treated. >> currently violating the policy by requesting my /22 for the wrong reasons > > Policy-wise, there are no "wrong reasons". Yes there are. The policy explicitly states "The LIR must confirm it will make assignment(s) from the allocation". If you request an allocation without the intention of making assignments from it you have lied during your allocation request. That is a policy violation. But anyway: let's wait for the RIPE NCC to get back to this list with more data on M&A! Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Sat Jun 18 07:54:51 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 18 Jun 2016 07:54:51 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <4ABC9CB5-5B45-4C58-97C9-C7EA7E5F908E@steffann.nl> Message-ID: <51D45499-B166-4D13-B5BE-9F6FCB8BFA80@steffann.nl> Hi Riccardo, >>> A new entrant would see his investments vanified >>> >> Address space is not an investment. The only reasons transfers were allowed in the first place (and this was not an easy decision back then) is to keep the database information accurate and to get some unused address space back in use. > > About investments: > To set up my ISP I needed networking, infrastructure, IP transit, hosting services, IP addresses. > I payed a signup fee and that was an investement to be an LIR and do better business as an ISP. I pay annualy a membership fees and this is part of the costs to run the business. > if I look to my management server (a couple of server hotsed outside my network) I see that I pay 16 ? per month for a /29 as part of the contract with my hosting provider... so actually yes IP space is a small part of the investements or costs in any case. You're taking this out of context. We're talking about 2016-03 here. Everything you mention is about the cost of running an ISP. This proposal doesn't change a thing for that: you still get your /22. The only thing that changes is that you can't sell it. > About transferts: > The same is today. Main reasons for a transfert are not renumbering and database consistence or unused IPs? Unused Ips is not my case I have so few. > This proposal puts the new LIRs in a worse condition even it already is. We are not SICK, we are late entrants. I don't see any reason to create CLASS-E "unusable LIRs" to keep them far from the IP market old LIRs created. What are you talking about? The only thing this proposal prevents is from selling a single /22. Jumping from there to "unusable LIRs" makes no sense. > Are you really thinking that I came out with a proposal like 2015-05 to catch more IPs to sell them? We're not talking about 2015-05 here... > I am not selling IPs 'cause i need them for assignements to customers In that case this policy proposal doesn't change anything for you. > but the first thing my they ask me when I propose consulting for IPv6 trasnition is "can I have the assigned space for me one day to keep on running the network" And the answer to that has always been "no". Please read section 7 of https://www.ripe.net/publications/docs/ripe-649. It contains this text: """ Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. """ >> We still have M&A for cases where businesses split up, merge, get sold etc. That is not affected by this policy proposal. > The evidence of a disvantage of newcomers is still there. How? All that this proposal limits is them selling their /22, which you keep telling me is not your intention. > Black market will substitute normal transfers regulations Please read my reply to Nick Hilliard two days ago, we were discussing the same issue and I am not yet sure that this is true. > and creative implementations of M&A will come to overcome the policy, M&A are explicitly allowed, based on feedback from the working group. > transparency will go far from database and statistics and transfert evidence. > You want all of this? I wouldn't want that, but I cannot see how you reach that conclusion... >>> We were in Bucarest when celebrating Romania as the biggest transfert country were JUMP Management choosed to sell to its customers their allocation making them able to keep their business running! >>> >> An LIR assigns addresses to its customers. That is how the allocation/assignment model works. Selling PA addresses isn't part of that. And besides: you can only sell allocations to other LIRs, so those "customers" have to be LIRs anyway, so they can get their own /22. > > Again, selling PA is out there and there are many here on the list proud of it. > We were in Bucarest celebrating this good manner of JUMP Management making space available to their end users signin up as new members. > > Second: avoid my customers to sign up and waste a /22 while needing only a /24 was exacly the purpose of 2015-05 > I tried to explain everyone (with Radu who shared the same point about this) that many customers are signin up wasting space just for the needing of a /24. Then assign /24s, or even smaller, to your customers from your PA allocation. That is what it is for! > This customer is mine not yours. And what you want me to have no address space to serve him so we can let him create his own LIR? He is in a completely different kind of business nothing to deal with internet but the use!!!! And this is related to you not being able to sell your /22 anymore under this policy proposal in what way exactly? > This means put every newcomer LIRs after 14/09/2012 out of the market You keep saying that, but not being able to sell your /22 really doesn't do that. > Just as an example? transition > Sander, I repeated more than one time in this list that I have customers that ask for a /24 and IPv6 transition consulting services to run their new datacenter or multihome their networks. Perfect legitimate needing. Again: you have a PA allocation, make assignments from it. This has nothing to do with selling your /22. > Do I really need to explain any detail on the list about my business model? Want to join the smallest business? I don't think RIPE NCC need to take care of mine small business. > I am really disappointed about you are treating us (new comers LIR after 14/09/2015). Excuse me? This community has written policy so that you can have a /22 for free with your LIR membership instead of nothing. > We don't force anything: we don't force LIRs or end user use IPv6 bla bla bla. You are being confronted with the fact that IPv4 has run out for normal business purposes. Yes, that is annoying. You need to either organise your network infrastructure in such a way that you minimise the amount of IPv4 addresses you need, and if you still need more addresses you'll have to find someone who will transfer them to you. Still: 2016-03 doesn't change anything in that regard. > Proposing introducing only a light control on IPv6 deployment I was adviced that every LIR is free to do what he need with space publically at RIPE72. Yes, every LIR is free to do whatever they wish, and that includes the freedom of dealing with the consequences. It does not entitle anybody to use their addresses and then come for more. It means that it is up to each LIR to choose how they deal with the limited number of addresses they have. >> Why? The LIR still has their PA allocation, can use it to provide service to customers etc. Nobody is taking a PA allocation away from the LIR. > I am in doubt if RIPE NCC will go legal or illegal forcing companies to keep running or closing LIRs. Sorry, I have no idea what you mean here. > IP market is there. I would have preffered an IPv4 transfert model without it but if it has been approved so we should care about it. There is an IPv4 market. This working group allowed it so that there was an incentive to get unused address space back in use. This working group also created the policy that gives you a /22 now, so that new entrants can start running your network without having to go to that market immediately. The only thing 2016-03 is doing (as of version 2) is to stop people from getting /22s to sell them on. People running a network and requesting a /22 for themselves without the intention of selling it (as you assure us you are) will not be impacted by this proposal. > This is higher the disadvantage to get rid of newcomers for the reason explained above. "to get rid of newcomers"? No idea what you are talking about... >> Apparently there are still lots of people that don't understand that the IPv4 barrel is as good as empty. I have to admit that I do sympathise with efforts to get rid of this FUD that IPv4 can still be "business as usual". > Sorry my english is not so good and I didn't understood that last comment. It means that, as you have discovered, you can't just run IPv4 networks like it was done 5 or 10 years ago. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rgori at wirem.net Sat Jun 18 08:02:47 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 18 Jun 2016 08:02:47 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> Message-ID: <6c7bc3c7-fb0f-852f-7c9e-cb0e86a04780@wirem.net> Hi Sander, here I am, thank you for your reply Il 17/06/2016 23:48, Sander Steffann ha scritto: > Hi Riccardo, > >> I am strongly against to every proposal that higher the disvlaantage to already disvantaged new and future pyers (LIRs after 09/2012) > You keep bringing that up, but how is preventing those newer LIRs from selling their addresses in any way disadvantaging them? On one hand you keep saying new LIRs don't get enough address space, and on the other hand you're saying that it is bad that they can't sell their space. Which one is it? I am basically saying that the rule of the game are already there and working quite well. And since I am an afterlife (14/09/2015) LIR this would put us in an even worste condition to make work our small business. > > This proposal doesn't prevent new LIRs from buying address space. And if they want to buy /22s from other newer LIRs they can as easily (and cheaper) open their own second LIR. The RIPE NCC membership explicitly allowed that during the last AGM. > > Two scenarios: > > One > - Someone opens up an LIR > - They get their /22 (free) > - They sell it off to another LIR for a profit > > Two > - That other LIR opens up a second LIR > - They get their /22 (free) > - They merge that new LIR with their old LIR using M&A > > This policy proposal is stopping scenario One but not scenario Two. The previous version of the proposal did, but as that didn't get any support this version removed that restriction. > > So what is this proposal blocking for new LIRs? Not buying space, not opening up a second LIR and getting that /22 from RIPE NCC. It only limits those LIRs from *selling* their /22 for profit. > > I'm sorry, but if that is your business model then you are exactly the kind of business that this proposal is trying to stop. The IPv4 allocation policy has very few requirements, and one of them is that the LIR has to use it for assign addresses from. If the intention is to sell those addresses then you are already in violation of the current policy. That is *NOT* why you were given that /22 in the first place. > > And as far as judging consensus goes, arguments that boil down to "I am currently violating the policy by requesting my /22 for the wrong reasons, and this proposal is stopping me from doing that" will not be taken into account. There are plenty of other arguments that need to be discussed, like the potential impact on the accuracy of the registry that Nick brought up. But there is too much FUD and noise in this discussion. Sorry Sander, but I think you are kidding at this point. Already explained my business model and has no primary scope in IP selling, if it was so I would qualify myself as an IP Broker. I am not. Please don't treat me like a baby. Problems are slightly different: You know is very easy to keep opened a zero cost company in many countries that can hold the LIR and everyone with a piece of brain can easily make private contract to title the assignements to ends customers or other LIRs for black money. This is called black market and is really easy to implement with 2016-03 around. I argued about the fairness of the treatement of new LIRs but also pointed out practical problems like databases consistence and black market. With 2016-03 once stockpiled the IPs will stuck there and the easiest method to speculate on those IPs is black market. Do you think speculators didn't tought about it? Is exacly the same thing will happen all over the world if you say no more transfert will be approved. Can even higher dramattically market price and speculators will be really really happy. I will not be surprised if will make appear black market brokers as well. Please you want someone else goes this way not me. Please look ar RIPE IPv6 course attended list, RIPE meetings... and my IP transit contracts, presence of my AS number in NAMEX, MIX and AMS-IS and my space annouced and in use I am still convinced the only way to stop abusing is to use the current policy and check out the assignements and enforce audit procedure. > > I don't mind if you send opposing arguments, but as I have said before I do care about the quality of the discussion. If you respond this policy in its current form then I'd like to see good argumentation with concrete examples of issues, not some hand-waving like "this is disadvantaging new LIRs" without any explanation of how that exactly would work. Then we have something to discuss that people can respond to. Consensus building works by explaining the issues and people trying to address them. Pretend I'm stupid and spell it out for me :) I am strongly against 2016-03 because will give us a flowering black market zero transparency and no database consistence. enough quality? > > Cheers, > Sander > cheers and regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From arash_mpc at parsun.com Sat Jun 18 08:07:19 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Sat, 18 Jun 2016 16:07:19 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Message-ID: <03c601d1c927$aede5950$0c9b0bf0$@parsun.com> Hi, This policy can affect the members that already received some /22 or smaller blocks (from 185/8 range) from the market. They already paid to sellers to obtain those blocks and this policy make it impossible for them to transfer it out later if they don't need it. I'm opposing the policy, it make unnecessary limitation and put a part of community in an unfair situation. If returning an allocation is something visible it can be done to any allocation, not just the smallest ones. Regards, Arash Naderpour From rgori at wirem.net Sat Jun 18 08:29:42 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 18 Jun 2016 08:29:42 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <03c601d1c927$aede5950$0c9b0bf0$@parsun.com> References: <03c601d1c927$aede5950$0c9b0bf0$@parsun.com> Message-ID: <7f967e39-e072-120a-4d58-eeb9d4f10c85@wirem.net> Il 18/06/2016 08:07, Arash Naderpour ha scritto: > Hi, > > This policy can affect the members that already received some /22 or smaller > blocks (from 185/8 range) from the market. They already paid to sellers to > obtain those blocks and this policy make it impossible for them to transfer > it out later if they don't need it. completely agree > > I'm opposing the policy, it make unnecessary limitation and put a part of > community in an unfair situation. If returning an allocation is something > visible it can be done to any allocation, not just the smallest ones. > > Regards, > > Arash Naderpour > > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From mozafary at greenweb.ir Sat Jun 18 09:44:14 2016 From: mozafary at greenweb.ir (Mozafary Mohammad) Date: Sat, 18 Jun 2016 11:14:14 +0330 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <03c601d1c927$aede5950$0c9b0bf0$@parsun.com> References: <03c601d1c927$aede5950$0c9b0bf0$@parsun.com> Message-ID: <153fa204-3eec-7d9d-6869-16e9af4b5999@greenweb.ir> I'm agree with Arash. On 6/18/2016 9:37 AM, Arash Naderpour wrote: > Hi, > > This policy can affect the members that already received some /22 or smaller > blocks (from 185/8 range) from the market. They already paid to sellers to > obtain those blocks and this policy make it impossible for them to transfer > it out later if they don't need it. > > I'm opposing the policy, it make unnecessary limitation and put a part of > community in an unfair situation. If returning an allocation is something > visible it can be done to any allocation, not just the smallest ones. > > Regards, > > Arash Naderpour > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Sat Jun 18 09:04:55 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 18 Jun 2016 09:04:55 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <8B3179A6-4ED2-4A69-ADBD-A668AA8257A8@steffann.nl> References: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> <1466194688.2421913.641044897.70EF603C@webmail.messagingengine.com> <8B3179A6-4ED2-4A69-ADBD-A668AA8257A8@steffann.nl> Message-ID: <1466233495.2575932.641331505.70CD46CE@webmail.messagingengine.com> On Fri, Jun 17, 2016, at 23:11, Sander Steffann wrote: > I'm sorry, but this policy proposal limits selling the last /22 LIRs get > from RIPE NCC. How is preventing to sell off your addresses in any way > considered "healing yourself"? It doesn't only limit "selling", it limits "transfer by policy". The M&A has become stricter (pending written confirmation) and pushes some legitimate cases in policy territory. -- Radu-Adrian FEURDEAN fr.ccs From contact at prager-it.com Sat Jun 18 12:58:48 2016 From: contact at prager-it.com (Stefan Prager) Date: Sat, 18 Jun 2016 12:58:48 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1575B0CA-8E9C-40EB-93CC-17C9AA67F28B@gmail.com> Message-ID: > On 2016-06-17 21:09:21 CET, Remco van Mook wrote: > Let me get this straight - you oppose a proposed change in policy because the change itself is not part of current policy? I strongly oppose your proposal as it seeks to selectively strip Provider Aggregatable(PA) resource holders of their rights solely justified by your belief that this is how allocations allocated after the 14th September 2012 are supposed to be treated. If you are concerned about people selling off address space allocated after the 14th September 2012 for profit you can propose to change the holding period from two years to three or four years or even introduce a transfer fee like other Regional Internet Registries(RIRs) have in place. Such changes would be just and apply to all Provider Aggregatable(PA) allocations and not just to Provider Aggregatable(PA) allocations allocated after the 14th September 2012. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ripe at liopen.fr Sat Jun 18 13:35:18 2016 From: ripe at liopen.fr (Denis Fondras) Date: Sat, 18 Jun 2016 13:35:18 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <20160618113518.GA16361@enforcer.ledeuns.net> On Fri, Jun 17, 2016 at 07:32:50PM +0200, Stefan Prager wrote: > People currently need IPv4 resources to run a business. They don't need IPv6 > resources yet and won't be requiring IPv6 resources for the foreseeable future > either. A business is required to take the necessary steps to secure their > survival and let me assure you they will do just that, just as any business > should. > Is this RIPE role to make your business sustainable ? I mean, if I had a transportation business I know I will have to buy gas on the market to have my business run. Even if the truck came with a filled tank when I bought/leased it. Whatever the market price is. Even if my competitors reserved litre of gas in when the price was low. Being a business manager myself, the first thing I learned is that market/competition/rules might change anytime and I have to adapt for survival. As of today, IPv4 from RIPE NCC is reserved for newer entrants, just like your startup might benefit from tax exemption, access to business incubator or any other advantage in its early-stage and only in the early-stage. Plenty of IPv4 is available on market. Go there with your wallet if you need more. Denis From gert at space.net Sat Jun 18 14:49:27 2016 From: gert at space.net (Gert Doering) Date: Sat, 18 Jun 2016 14:49:27 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> Message-ID: <20160618124927.GV79185@Space.Net> hi, On Fri, Jun 17, 2016 at 10:49:59PM +0200, Riccardo Gori wrote: > I am strongly against to every proposal that higher the disvlaantage to > already disvantaged new and future pyers (LIRs after 09/2012) This proposal actually will only disadvantage "young LIRs" if they want to do stuff with their /22 that is frowned upon by the community - namely, trade, instead of "use for customers". The *reason* why this is proposed is to discourage stockpiling of /22s (by opening many new LIRs, waiting two years, transfer it all into a joint LIR and close the others off) - taking away /22s that are supposed to be used by further new entrants into the market. A LIR that receives space, runs a network, addresses its customers, and might even be potentially bought one day is *not* affected (unlike version 1 of the proposal) - though the proposal might be clearer on the intended effects of M&A. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From arash_mpc at parsun.com Sat Jun 18 15:46:56 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Sat, 18 Jun 2016 23:46:56 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160618124927.GV79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> Message-ID: <03fb01d1c967$e37c3e80$aa74bb80$@parsun.com> >This proposal actually will only disadvantage "young LIRs" if they want to do stuff with their /22 that is frowned upon by the community - namely, trade, instead of "use for customers". That's not true, it can affect any holder of /22 from 185/8 not only "young LIRs". Even if it was limited to "young LIRs" it was not acceptable to me as they need to be treated same as "old LIRs", These who become a member earlier already have enough advantage over the newer ones, and this policy grant them more and I cannot agree with that. Regards, Arash From frettled at gmail.com Sat Jun 18 16:26:27 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 18 Jun 2016 16:26:27 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <03fb01d1c967$e37c3e80$aa74bb80$@parsun.com> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <03fb01d1c967$e37c3e80$aa74bb80$@parsun.com> Message-ID: On Sat, Jun 18, 2016 at 3:46 PM, Arash Naderpour wrote: > > >This proposal actually will only disadvantage "young LIRs" if they want to > do stuff with their /22 that is frowned upon by the community - namely, > trade, instead of "use for customers". > > That's not true, it can affect any holder of /22 from 185/8 Can you please stop writing that? It is not about 185/8. It's about all allocations made after a certain point in time. > not only "young > LIRs". > Even if it was limited to "young LIRs" it was not acceptable to me as they > need to be treated same as "old LIRs", These who become a member earlier > already have enough advantage over the newer ones, and this policy grant > them more and I cannot agree with that. > I really cannot see how that is true. The policy proposal provides new LIRs with better protection from "shark" LIRs who don't want to run businesses with their allocated space. The proposal is all about protecting new LIRs who actually will do assignments with their allocated space. I do agree, though, with the repeated criticism about how M&A is handled. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Sat Jun 18 17:02:50 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 18 Jun 2016 17:02:50 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160618124927.GV79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> Message-ID: Hi Gert, Il 18/06/2016 14:49, Gert Doering ha scritto: > hi, > > On Fri, Jun 17, 2016 at 10:49:59PM +0200, Riccardo Gori wrote: >> I am strongly against to every proposal that higher the disvlaantage to >> already disvantaged new and future pyers (LIRs after 09/2012) > This proposal actually will only disadvantage "young LIRs" if they want > to do stuff with their /22 that is frowned upon by the community - namely, > trade, instead of "use for This would disvantage every LIR that received or will reiceve an ad-normal PA allocation. Please leave the idea of ab-normal LIRs. > The *reason* why this is proposed is to discourage stockpiling of /22s > (by opening many new LIRs, waiting two years, transfer it all into a > joint LIR and close the others off) - taking away /22s that are supposed > to be used by further new entrants into the market. > > A LIR that receives space, runs a network, addresses its customers, and > might even be potentially bought one day is *not* affected (unlike > version 1 of the proposal) - though the proposal might be clearer on the > intended effects of M&A. Nobody protects new LIRs speculator stockpile /22 in a zero cost company/person without network or assignements and black sell it the same day it has been allocated with a private contract registered elsewhere from RIPE database. This policy is useless. Audit and control is useful, transparency is a must we discussed it at last general > > Gert Doering > -- APWG chair regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From noc at ntx.ru Sat Jun 18 18:47:37 2016 From: noc at ntx.ru (NTX NOC) Date: Sat, 18 Jun 2016 19:47:37 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <09f02056-d51b-131e-b31b-4a42b4404d27@ntx.ru> I oppose this proposal too. 1) it limits in rights all new LIRs. As I told in previous discussions LIR stats show the same rate of new LIR registration (250-300 LIRs avg) per month. It's about 40% of 185 is free and that means it will be about 7000 new LIRs in it. That will be enough for 2 years, and after RIPE has reseved space and reserve pool that could not be used for (as I remember 2 years) and another IPv4 space will be given to market. So there are enough space for 4-6 years with current situation. 2) RIPE here is not to limit abilities of the members to use IPv4 space. RIPE should give opposites. ISPs will take care about all others. But in current case RIPE take part in business significant parts and that's not good. 3) Those policy add new fields and statuses to the database. And this is not good too. System should stay simple and useful. It's not good direction to make it more complex because there are a lot of question to current one system. Yuri at NTX On 18.06.2016 13:58, Stefan Prager wrote: >> On 2016-06-17 21:09:21 CET, Remco van Mook wrote: >> Let me get this straight - you oppose a proposed change in policy because the change itself is not part of current policy? > > > I strongly oppose your proposal as it seeks to selectively strip Provider Aggregatable(PA) resource holders of their rights solely justified by your belief that this is how allocations allocated after the 14th September 2012 are supposed to be treated. If you are concerned about people selling off address space allocated after the 14th September 2012 for profit you can propose to change the holding period from two years to three or four years or even introduce a transfer fee like other Regional Internet Registries(RIRs) have in place. Such changes would be just and apply to all Provider Aggregatable(PA) allocations and not just to Provider Aggregatable(PA) allocations allocated after the 14th September 2012. > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From ripe-wgs at radu-adrian.feurdean.net Sat Jun 18 20:43:45 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 18 Jun 2016 20:43:45 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160618124927.GV79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> Message-ID: <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> On Sat, Jun 18, 2016, at 14:49, Gert Doering wrote: > A LIR that receives space, runs a network, addresses its customers, and > might even be potentially bought one day is *not* affected (unlike > version 1 of the proposal) - though the proposal might be clearer on the > intended effects of M&A. It happens that it may well be impacted, depending on how the purchase has been performed. Transfer by policy does not mean only "sell for profit". Another "legitimate" case that will no longer be possible was an argument what was given to me during the discussion of 2015-05: A company becomes LIR because they need "some provider independent" space (which today is limited to ALLOCATED PA) which usually equals to "less than a /24 of actual need, but still a /24 for routing purposes". They don't really need more than a /24 now and on short/medium term, and they estimate that they will not need more than a second /24 (size chose for routing purposes only) even in the longer term. Someone argued that it would be legitimate and desirable for that LIR to put the remaining /23 (considered not ever be a need) on the market. Did this became non-legitimate over-night ? > The *reason* why this is proposed is to discourage stockpiling of /22s > (by opening many new LIRs, waiting two years, transfer it all into a > joint LIR and close the others off) - taking away /22s that are supposed > to be used by further new entrants into the market. What exactly means stockpiling ? Opening additional LIRs to satisfy one organisation's own need ? In what is stockpiling "last /8 space" worse than "stokpiling IP space" in general ? Especially for already-acquired space ? -- Radu-Adrian FEURDEAN fr.ccs From Ondrej.Caletka at cesnet.cz Sat Jun 18 22:45:54 2016 From: Ondrej.Caletka at cesnet.cz (=?utf-8?Q?Ond=C5=99ej?= Caletka) Date: Sat, 18 Jun 2016 22:45:54 +0200 Subject: [address-policy-wg] Support for 2016-03 v2.0 In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <20160618204554.GE7702@oskarpc.cesnet.cz> On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: > Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. Hello list, I support this version of 2016-03. I think the allocations made after entering the post-depletion phase (that could be maybe a better name than the "last /8") should be either used for operating a network or returned to RIPE NCC. Since there used to be a needs-based policy for pre-depletion allocations, stockpiling addresses for the sole purpose of selling them in the future was not as trivial as it is now. One had to not only have enough money but also cheat in the needs evaluation process.Now, when the needs-based approach is gone, we need something else to conserve at least something for new players for as long as possible. I also like the idea of special status "ALLOCATED FINAL". I think it is a good starting point for the AGM to adopt a charging scheme which would require additional recurring fee for LIRs holding more than one such allocation. This is IMHO the only way how to prevent people from opening new LIRs as a better alternative to the IPv4 market. -- Best regards Ond?ej Caletka An Internet user, who still haven't opened his own Internet-based business -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From frettled at gmail.com Sat Jun 18 23:27:55 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 18 Jun 2016 23:27:55 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <09f02056-d51b-131e-b31b-4a42b4404d27@ntx.ru> References: <09f02056-d51b-131e-b31b-4a42b4404d27@ntx.ru> Message-ID: On Sat, Jun 18, 2016 at 6:47 PM, NTX NOC wrote: > I oppose this proposal too. > > 1) it limits in rights all new LIRs. As I told in previous discussions > LIR stats show the same rate of new LIR registration (250-300 LIRs avg) > per month. It's about 40% of 185 is free and that means it will be about > 7000 new LIRs in it. That will be enough for 2 years, and after RIPE has > reseved space and reserve pool that could not be used for (as I remember > 2 years) and another IPv4 space will be given to market. > So there are enough space for 4-6 years with current situation. > False. This proposal does not change when space can be used. > > 2) RIPE here is not to limit abilities of the members to use IPv4 > space. RIPE should give opposites. ISPs will take care about all others. > But in current case RIPE take part in business significant > parts and that's not good. > False. The proposal will not limit the abilities of the members to use IPv4 space. > > 3) Those policy add new fields and statuses to the database. And this is > not good too. System should stay simple and useful. It's not good > direction to make it more complex because there are a lot of question to > current one system. > This is the only one of your objections that has some merit. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at ntx.ru Sat Jun 18 23:30:13 2016 From: noc at ntx.ru (NTX NOC) Date: Sun, 19 Jun 2016 00:30:13 +0300 Subject: [address-policy-wg] Support for 2016-03 v2.0 In-Reply-To: <20160618204554.GE7702@oskarpc.cesnet.cz> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160618204554.GE7702@oskarpc.cesnet.cz> Message-ID: <2d375aaf-1f9f-c665-7f1f-80441566f2cf@ntx.ru> If you will look into the future - all last 185 will be FINAL. And all LIRs will have to return the space or use it and pay to RIPE for usage even they work as with PIs as PI. reserved space also will be FINAL. But then after some due to space exchange under ripe more and more space will become FINAL. So transfer policy will conflict with the space. My opinion - just make easier for new companies to get IPs until RIPE has it and RIPE has enough. So I don't understand why to make life harder but not easier. Yuri at NTX On 18.06.2016 23:45, Ond?ej Caletka wrote: > On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: >> Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. > > Hello list, > > I support this version of 2016-03. I think the allocations made after > entering the post-depletion phase (that could be maybe a better name > than the "last /8") should be either used for operating a network or > returned to RIPE NCC. > > Since there used to be a needs-based policy for pre-depletion > allocations, stockpiling addresses for the sole purpose of selling them > in the future was not as trivial as it is now. One had to not only have > enough money but also cheat in the needs evaluation process.Now, when > the needs-based approach is gone, we need something else to conserve at > least something for new players for as long as possible. > > I also like the idea of special status "ALLOCATED FINAL". I think it is > a good starting point for the AGM to adopt a charging scheme which would > require additional recurring fee for LIRs holding more than one such > allocation. This is IMHO the only way how to prevent people from opening > new LIRs as a better alternative to the IPv4 market. > From frettled at gmail.com Sat Jun 18 23:33:12 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 18 Jun 2016 23:33:12 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> Message-ID: On Sat, Jun 18, 2016 at 8:43 PM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > > What exactly means stockpiling ? Opening additional LIRs to satisfy one > organisation's own need ? > No, to "stockpile" is to store something without using it. "Need" doesn't come into it. > In what is stockpiling "last /8 space" worse than "stokpiling IP space" > in general ? Especially for already-acquired space ? > > What is done, is done. Stockpiling *more* space means there will be even less even more quickly for future LIRs, or fewer future LIRs, and it also increases operating costs, because the IP space available on the market becomes less even more quickly. You seem to think it's a problem that already-acquired space is "unused", why don't you think it's a problem that even more space stays "unused"? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Sat Jun 18 23:38:38 2016 From: danny at danysek.cz (Daniel Suchy) Date: Sat, 18 Jun 2016 23:38:38 +0200 Subject: [address-policy-wg] Support for 2016-03 v2.0 In-Reply-To: <20160618204554.GE7702@oskarpc.cesnet.cz> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160618204554.GE7702@oskarpc.cesnet.cz> Message-ID: Hello, even I uderstand motivation, I cannot aggre with Ondrej. IP address was, is and always will be only technical resource - and we're loosing that point in APWG.... And such policy is quite unfair to "new" LIRs (holding only last /22) - as it's trying to revoke rights, which have "old" LIRs holding old allocatios before "last /8" policy was introduced. I think we cannot make difference between "old" and "new" allocations - in terms of last /8 policy, where we're taking care only about address space allocated after certain date. There's RIPE analysis about address really available: https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-last-slash-8 - and I don't undersand such "panic", as numbers about space available are pretty clear... Do we really want do block new organisations with new allocations, but allow old (happy) one to do anything with addresses tehy have...? That's not fair. Motivation mentioned above is shift movement to IPv6 - but, basically holders of smaller/never allocations have IPv6 implemented already (or at least are trying to implement) - or in IPv4, they have deployments of CGNAT solutions already. There're organisations, which have large allocations and they're sometimes not taking care - they have enough IPv4 addresses, nothing is pushing them to implement IPv6, or save address space by implementation of some NAT solution. If they decide to sell their business, policy will allow that - but, if "new" resource holder will try similar thing, policy will ban then? My point is simple - there should be ONLY ONE POLICY - independent on time of allocation. Such policy must limit not only new LIRs (using addresses from last /8), but also old LIRs holding addresses from old allocations. And if we really want to reclaim some address space, we should review current allocations - in terms of current situation in IPv4 world. With regards, Daniel On 18.06.16 22:45, Ond?ej Caletka wrote: > On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: >> Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. > > Hello list, > > I support this version of 2016-03. I think the allocations made after > entering the post-depletion phase (that could be maybe a better name > than the "last /8") should be either used for operating a network or > returned to RIPE NCC. > > Since there used to be a needs-based policy for pre-depletion > allocations, stockpiling addresses for the sole purpose of selling them > in the future was not as trivial as it is now. One had to not only have > enough money but also cheat in the needs evaluation process.Now, when > the needs-based approach is gone, we need something else to conserve at > least something for new players for as long as possible. > > I also like the idea of special status "ALLOCATED FINAL". I think it is > a good starting point for the AGM to adopt a charging scheme which would > require additional recurring fee for LIRs holding more than one such > allocation. This is IMHO the only way how to prevent people from opening > new LIRs as a better alternative to the IPv4 market. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: OpenPGP digital signature URL: From noc at ntx.ru Sat Jun 18 23:41:34 2016 From: noc at ntx.ru (NTX NOC) Date: Sun, 19 Jun 2016 00:41:34 +0300 Subject: [address-policy-wg] Support for 2016-03 v2.0 In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160618204554.GE7702@oskarpc.cesnet.cz> Message-ID: +1 On 19.06.2016 0:38, Daniel Suchy wrote: > Do we really want do block new organisations with new allocations, but > allow old (happy) one to do anything with addresses tehy have...? That's > not fair. +1 >There're organisations, which have large allocations and they're >sometimes not taking care - they have enough IPv4 addresses, nothing is >pushing them to implement IPv6, or save address space by implementation >of some NAT solution. If they decide to sell their business, policy will >allow that - but, if "new" resource holder will try similar thing, >policy will ban then? Yuri at NTX From frettled at gmail.com Sun Jun 19 12:02:10 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 19 Jun 2016 12:02:10 +0200 Subject: [address-policy-wg] Support for 2016-03 v2.0 In-Reply-To: References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160618204554.GE7702@oskarpc.cesnet.cz> Message-ID: On Sat, Jun 18, 2016 at 11:38 PM, Daniel Suchy wrote: > Hello, > Hello, > > Do we really want do block new organisations with new allocations, but > allow old (happy) one to do anything with addresses tehy have...? That's > not fair. > I'm afraid that "fair" in that regard, is impossible to achieve. > There're organisations, which have large allocations and they're > sometimes not taking care - they have enough IPv4 addresses, nothing is > pushing them to implement IPv6, or save address space by implementation > of some NAT solution. If they decide to sell their business, policy will > allow that - but, if "new" resource holder will try similar thing, > policy will ban then? > No, the new policy does not ban selling their business (merger/acquisition). My point is simple - there should be ONLY ONE POLICY - independent on > time of allocation. Such policy must limit not only new LIRs (using > addresses from last /8), but also old LIRs holding addresses from old > allocations. > Why do you want to do that? > > And if we really want to reclaim some address space, we should review > current allocations - in terms of current situation in IPv4 world. > > How do you propose to go about that? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Jun 19 15:31:19 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 19 Jun 2016 15:31:19 +0200 Subject: [address-policy-wg] Support for 2016-03 v2.0 In-Reply-To: <2d375aaf-1f9f-c665-7f1f-80441566f2cf@ntx.ru> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160618204554.GE7702@oskarpc.cesnet.cz> <2d375aaf-1f9f-c665-7f1f-80441566f2cf@ntx.ru> Message-ID: <05CEBB24-102E-4DDC-A730-79C0EC8FAF89@steffann.nl> Hi Yuri, > If you will look into the future - all last 185 will be FINAL. > And all LIRs will have to return the space or use it and pay to RIPE for > usage even they work as with PIs as PI. > reserved space also will be FINAL. > > But then after some due to space exchange under ripe more and more space > will become FINAL. So transfer policy will conflict with the space. You seem to be under the false impression that all space transferred will also be marked ALLOCATED FINAL. This is incorrect, this policy only marks the /22s handed out by RIPE NCC as such. > My opinion - just make easier for new companies to get IPs until RIPE > has it and RIPE has enough. So I don't understand why to make life > harder but not easier. This is out of scope. We already discussed a policy that tried that and it didn't get consensus. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Mon Jun 20 10:00:50 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 10:00:50 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> Message-ID: <20160620080050.GY79185@Space.Net> Hi, On Sat, Jun 18, 2016 at 05:02:50PM +0200, Riccardo Gori wrote: > > Il 18/06/2016 14:49, Gert Doering ha scritto: > > hi, > > > > On Fri, Jun 17, 2016 at 10:49:59PM +0200, Riccardo Gori wrote: > >> I am strongly against to every proposal that higher the disvlaantage to > >> already disvantaged new and future pyers (LIRs after 09/2012) > > This proposal actually will only disadvantage "young LIRs" if they want > > to do stuff with their /22 that is frowned upon by the community - namely, > > trade, instead of "use for > This would disvantage every LIR that received or will reiceve an > ad-normal PA allocation. You keep repeating this, which does not make it more true. Please explain how this proposal would affect a LIR that intends to use the /22 to number its customers (and/or its own infrastructure), and is not intending to sell off the address space as quickly as possible to make a quick profit. > Please leave the idea of ab-normal LIRs. This is not an "idea" but observed behaviour by a few bad actors. [..] > Nobody protects new LIRs speculator stockpile /22 in a zero cost > company/person without network or assignements and black sell it the > same day it has been allocated > with a private contract registered elsewhere from RIPE database. > This policy is useless. Audit and control is useful, transparency is a > must we discussed it at last general This paragraph does not make sense. Yes, people can get a /22 and "black sell it", even with 2016-01 - but the risk for the buyer is much higher than getting a "white" /22 on the address market, because the seller has to keep open the LIR forever in this case - and if the LIR is ever closed, the /22 has to be returned to the RIPE NCC. So why should a buyer take this risk? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Mon Jun 20 10:04:33 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 10:04:33 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> Message-ID: <20160620080433.GZ79185@Space.Net> Hi, On Sat, Jun 18, 2016 at 08:43:45PM +0200, Radu-Adrian FEURDEAN wrote: > Another "legitimate" case that will no longer be possible was an > argument what was given to me during the discussion of 2015-05: > A company becomes LIR because they need "some provider independent" > space (which today is limited to ALLOCATED PA) which usually equals to > "less than a /24 of actual need, but still a /24 for routing purposes". > They don't really need more than a /24 now and on short/medium term, and > they estimate that they will not need more than a second /24 (size chose > for routing purposes only) even in the longer term. Someone argued that > it would be legitimate and desirable for that LIR to put the remaining > /23 (considered not ever be a need) on the market. Did this became > non-legitimate over-night ? I would consider this also as a fringe case - legitimate according to the letter of the policy, but not according to the spirit. These /22s are not for trading. But I'm close to giving up on this and calling a ban on further changes to the IPv4 policy - the "new LIR" folks here are accting in a fairly irresponsible way regarding *future* participants, while at the same time complaining that they are treated unfairly by the old LIRs - totally ignoring the fact that *without the foresight of these old LIRs* you wouldn't have any space at all today. This is not the way to do bottom-up policy making - "I want my cookie and I want it now, and I do not care for the greater good". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From arash.naderpour at gmail.com Fri Jun 17 15:05:03 2016 From: arash.naderpour at gmail.com (Arash Naderpour) Date: Fri, 17 Jun 2016 23:05:03 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> <027901d1c88e$01b81ed0$05285c70$@rasana.net> Message-ID: IPv6 is not the answer for everything no matter how manytime you repeat that, it is not availble and possible to deploy everywhere. Arash On Friday, 17 June 2016, Jim Reid wrote: > > > On 17 Jun 2016, at 12:47, Payam Poursaied > wrote: > > > > Let's think for a better way to make it work for everybody and allow > more people on the earth to gain access to the Internet. > > Indeed. That better way is already here. It?s called IPv6. The effort > that?s being wasted here haggling over the dregs of v4 would be better > spent deploying IPv6. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash.naderpour at gmail.com Fri Jun 17 15:39:30 2016 From: arash.naderpour at gmail.com (Arash Naderpour) Date: Fri, 17 Jun 2016 23:39:30 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160617123950.GA23322@danton.fire-world.de> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> Message-ID: > THERE. IS. NO. IPv4. LEFT! > And is that the reason policy is trying to return only smallest allocations and let the big allocation holders continue selling their ones? Arash -------------- next part -------------- An HTML attachment was scrubbed... URL: From ww at hubs.net.uk Mon Jun 20 10:39:05 2016 From: ww at hubs.net.uk (William Waites) Date: Mon, 20 Jun 2016 08:39:05 +0000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080433.GZ79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <8660t4gspi.fsf@naartjie.uucp> Gert Doering writes: > But I'm close to giving up on this and calling a ban on further > changes to the IPv4 policy For what it's worth, the new version suits us just fine. Marking the numbers as non-transferrable should raise the barrier for speculators which seems likely to help the situation. Raising the barrier much higher would put new entrants, particularly in rural areas in conditions of market failure at a serious disadvantage. I would still like to see some requirement to demonstrate that addresses are actually assigned and in use even in the case of mergers though. Best wishes, -w -- William Waites Network Engineer HUBS AS60241 From gert at space.net Mon Jun 20 10:42:40 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 10:42:40 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> Message-ID: <20160620084240.GB79185@Space.Net> Hi, On Fri, Jun 17, 2016 at 11:39:30PM +1000, Arash Naderpour wrote: > > THERE. IS. NO. IPv4. LEFT! > > And is that the reason policy is trying to return only smallest allocations > and let the big allocation holders continue selling their ones? This policy is not about "return allocations", but about reducing the burn rate by reserving /22s for those who actually want to run a network with it, instead of trade away quickly for a short gain. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From frettled at gmail.com Mon Jun 20 10:50:36 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 20 Jun 2016 10:50:36 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> Message-ID: On Fri, Jun 17, 2016 at 3:39 PM, Arash Naderpour wrote: > > THERE. IS. NO. IPv4. LEFT! >> > > And is that the reason policy is trying to return only smallest > allocations and let the big allocation holders continue selling their ones? > As Gert wrote, it is not about returning allocations. It also seems as if you're missing a vital point: This policy proposal will most likely increase the time period where network providers will be able to get IPv4 address space for interoperability. Regarding what big allocation holders do, this policy proposal changes nothing. Big allocation holders cannot be affected directly by policy change. But if big allocation holders want to transfer away part of their allocations, to others, or new entrants, who need more space, that is mostly a benevolent market mechanism, as it only increases the use of these allocations. In other words: win-win. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksbulgakov at gmail.com Mon Jun 20 11:01:19 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Mon, 20 Jun 2016 12:01:19 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620084240.GB79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> Message-ID: Hi. I think there is 2015-01 and it is enough to prevent reselling for undistributed 185./8 and others proposals make more problems for all - members, RIPE stuff, member's customers. E.g. is multiple accoutns when executive board suspend it and then asked to vote to allow it again. The IPs aren't burn (it is not oil or gas) even some one sell it. Simply the owner is some LIR but not the NCC. May be it will increase the price, no more. But the NCC wants to have exclusive rights to sell it (but RIPE is not organisation to make profit or I am wrong? :) ) and creates new proposals. 2016-06-20 11:42 GMT+03:00 Gert Doering : > Hi, > > On Fri, Jun 17, 2016 at 11:39:30PM +1000, Arash Naderpour wrote: >> > THERE. IS. NO. IPv4. LEFT! >> >> And is that the reason policy is trying to return only smallest allocations >> and let the big allocation holders continue selling their ones? > > This policy is not about "return allocations", but about reducing the > burn rate by reserving /22s for those who actually want to run a network > with it, instead of trade away quickly for a short gain. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From jim at rfc1035.com Mon Jun 20 11:10:52 2016 From: jim at rfc1035.com (Jim Reid) Date: Mon, 20 Jun 2016 10:10:52 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <395BD4BE-CE01-4736-B99E-8FFA1D4A59D4@rfc1035.com> <027901d1c88e$01b81ed0$05285c70$@rasana.net> Message-ID: <75985C05-B941-429E-8269-B4834A5395E7@rfc1035.com> > On 17 Jun 2016, at 14:05, Arash Naderpour wrote: > > IPv6 is not the answer for everything no matter how manytime you repeat that More or bigger IPv4 allocations from the NCC are not the answer no matter how often you repeat that either. So what are you doing to do? Any efforts you make to get more/bigger IPv4 allocations from the NCC are doomed to fail. There isn?t any left. Well not enough to give everyone as much as they think they need or want. Even if you could consensus for a more liberal allocation policy for IPv4, we?ll burn through the remaining IPv4 address space in a matter of weeks. At that point we?re right back where you started: out of IPv4 and whining for more. Except this time there is absolutely nothing left at the NCC for anyone. Wouldn?t your effort be better spent doing something about IPv6 deployment in your network and in your country? From phessler at theapt.org Mon Jun 20 11:12:27 2016 From: phessler at theapt.org (Peter Hessler) Date: Mon, 20 Jun 2016 11:12:27 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080433.GZ79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <20160620091227.GW31815@gir.theapt.org> On 2016 Jun 20 (Mon) at 10:04:33 +0200 (+0200), Gert Doering wrote: :But I'm close to giving up on this and calling a ban on further changes :to the IPv4 policy +1 -- The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain From ripe-wgs at radu-adrian.feurdean.net Mon Jun 20 11:14:24 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 20 Jun 2016 11:14:24 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080433.GZ79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <1466414064.2539373.642683185.7F5F666B@webmail.messagingengine.com> On Mon, Jun 20, 2016, at 10:04, Gert Doering wrote: > But I'm close to giving up on this and calling a ban on further changes > to the IPv4 policy - +1 > the "new LIR" folks here are accting in a fairly irresponsible way > regarding *future* participants, while at the same time complaining -1, but that's another story, not necessarily worth discussing (see above). -- Radu-Adrian FEURDEAN fr.ccs From arash_mpc at parsun.com Mon Jun 20 11:15:32 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 20 Jun 2016 19:15:32 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> Message-ID: <00d901d1cad4$4e1e9680$ea5bc380$@parsun.com> Maybe I?m misunderstanding this policy, so can you please help me with following example? Company A already bought and IPv4 allocation from company B in 2014, the allocation was made originally as a last /22 to company B in 2013. None of them are new-comers and have become member before 2012. My understanding from 2016-03 is that over a night that /22 allocation will be ?FINAL ALLOCATION? (because it was originally allocated by RIPE NCC after a certain date) and company A cannot transfer it to any other member if one day they don?t need it. (and returning that /22 to RIPE NCC is the only option for them if they want to close their business in the future) Can you please correct me if I?m wrong? Thanks, Arash Naderpour -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Jun 20 11:16:50 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 11:16:50 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> Message-ID: <20160620091650.GC79185@Space.Net> Hi, On Mon, Jun 20, 2016 at 06:56:47PM +1000, Arash Naderpour wrote: > > This policy is not about "return allocations", but about reducing the > > burn rate by reserving /22s for those who actually want to run a network > > with it, instead of trade away quickly for a short gain. > > When an allocation is not transferable to another member, one day they need > to be returned to RIPE NCC. Yes. But that's a side effect of not allowing transfers of these /22s. Basically, the discussion *should* try to focus on this point, and not run around the mill with non-sensical arguments. - do we want to restrict trading of "last /8 policy" /22s, yes or no? If we want restrictions, then this will have consequences (like, if you close your LIR and are not selling off the whole business, the /22 will be returned). If we want *no* restrictions, this will also have consequences - namely, some (few) people making money based on resources other folks have set aside to be there for the long-term good of the RIPE region, which many others see as immoral and abusive. But do not complain about the potential consequences, please just answer the question. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From aleksbulgakov at gmail.com Mon Jun 20 11:20:33 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Mon, 20 Jun 2016 12:20:33 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620091650.GC79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> Message-ID: Trading is restricted by 2015-01. Don't you see it? Open the transfer statistics and look it. But WG find the problem where is not a problem. 2016-06-20 12:16 GMT+03:00 Gert Doering : > Hi, > > On Mon, Jun 20, 2016 at 06:56:47PM +1000, Arash Naderpour wrote: >> > This policy is not about "return allocations", but about reducing the >> > burn rate by reserving /22s for those who actually want to run a network >> > with it, instead of trade away quickly for a short gain. >> >> When an allocation is not transferable to another member, one day they need >> to be returned to RIPE NCC. > > Yes. But that's a side effect of not allowing transfers of these /22s. > > Basically, the discussion *should* try to focus on this point, and not > run around the mill with non-sensical arguments. > > - do we want to restrict trading of "last /8 policy" /22s, yes or no? > > If we want restrictions, then this will have consequences (like, if you > close your LIR and are not selling off the whole business, the /22 will > be returned). > > If we want *no* restrictions, this will also have consequences - namely, > some (few) people making money based on resources other folks have set > aside to be there for the long-term good of the RIPE region, which many > others see as immoral and abusive. > > But do not complain about the potential consequences, please just answer > the question. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From jim at rfc1035.com Mon Jun 20 11:23:12 2016 From: jim at rfc1035.com (Jim Reid) Date: Mon, 20 Jun 2016 10:23:12 +0100 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: <20160620091650.GC79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> Message-ID: > On 20 Jun 2016, at 10:16, Gert Doering wrote: > > - do we want to restrict trading of "last /8 policy" /22s, yes or no? > ... > But do not complain about the potential consequences, please just answer > the question. No. Maybe. Depends. If we do tweak the current policy, there?s one consequence that has to be considered though: the integrity and accuracy of the RIPE database. PS: Apologies for starting a new thread with a meaningful and relevant Subject: header. From radu at pengooin.net Mon Jun 20 11:26:04 2016 From: radu at pengooin.net (Radu Gheorghiu) Date: Mon, 20 Jun 2016 12:26:04 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620091650.GC79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> Message-ID: <5767B6AC.50204@pengooin.net> Hi, Do we actually know how many such instances exists where someone spawned LIRs for profit? I don't care how many LIRs a company has spawned, I care if they did it for profit. I doubt we have any idea. To be honest I think we are debating a policy here based on the supposition that there are a lot of LIRs doing this, without any actual proof. And even if they did it for profit, it's not like the IPs are going in some other galaxy. They remain in the RIPE region part of some LIR. That LIR will eventually either close, or transfer their IPv4. So it's not like the IPv4 is vanishing. I don't see where the problem is. The IPv4 pool is going to be depleted sooner or later, no matter what policy we come up to meanwhile. What then? The real solution is to stop changing policy, or lower the "/22" allocation size to "/24". This will provide a good enough start in terms of IPv4 resources, and the newly established LIRs are free to get their extra IPv4 from somewhere else, just like they are free to get their resources from somewhere else when they start with just a "/22". Regards, Radu Gheorghiu On 06/20/2016 12:16 PM, Gert Doering wrote: > Hi, > > On Mon, Jun 20, 2016 at 06:56:47PM +1000, Arash Naderpour wrote: >>> This policy is not about "return allocations", but about reducing the >>> burn rate by reserving /22s for those who actually want to run a network >>> with it, instead of trade away quickly for a short gain. >> When an allocation is not transferable to another member, one day they need >> to be returned to RIPE NCC. > Yes. But that's a side effect of not allowing transfers of these /22s. > > Basically, the discussion *should* try to focus on this point, and not > run around the mill with non-sensical arguments. > > - do we want to restrict trading of "last /8 policy" /22s, yes or no? > > If we want restrictions, then this will have consequences (like, if you > close your LIR and are not selling off the whole business, the /22 will > be returned). > > If we want *no* restrictions, this will also have consequences - namely, > some (few) people making money based on resources other folks have set > aside to be there for the long-term good of the RIPE region, which many > others see as immoral and abusive. > > But do not complain about the potential consequences, please just answer > the question. > > Gert Doering > -- NetMaster From gert at space.net Mon Jun 20 11:27:28 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 11:27:28 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> Message-ID: <20160620092728.GD79185@Space.Net> Hi, On Mon, Jun 20, 2016 at 12:20:33PM +0300, Aleksey Bulgakov wrote: > Trading is restricted by 2015-01. Don't you see it? Open the transfer > statistics and look it. But WG find the problem where is not a > problem. Please answer the question asked, if replying to a mail with a question in it. Also, proper quoting would be most most polite. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From d.baeza at tvt-datos.es Mon Jun 20 11:27:29 2016 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 20 Jun 2016 11:27:29 +0200 Subject: [address-policy-wg] 2016-03 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> Message-ID: Hi, There is already 2015-01 to prevent abusing of the last /8 so we totally oppose 2016-03. Regards, --Daniel From radu at pengooin.net Mon Jun 20 11:30:21 2016 From: radu at pengooin.net (Radu Gheorghiu) Date: Mon, 20 Jun 2016 12:30:21 +0300 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620091650.GC79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> Message-ID: <5767B7AD.9090900@pengooin.net> Hello, I think your question is badly worded but answering it anyway, I do not want to restrict transfers of /22s from the "last /18". I oppose this policy. Regards, Radu Gheorghiu On 06/20/2016 12:16 PM, Gert Doering wrote: > Hi, > > On Mon, Jun 20, 2016 at 06:56:47PM +1000, Arash Naderpour wrote: >>> This policy is not about "return allocations", but about reducing the >>> burn rate by reserving /22s for those who actually want to run a network >>> with it, instead of trade away quickly for a short gain. >> When an allocation is not transferable to another member, one day they need >> to be returned to RIPE NCC. > Yes. But that's a side effect of not allowing transfers of these /22s. > > Basically, the discussion *should* try to focus on this point, and not > run around the mill with non-sensical arguments. > > - do we want to restrict trading of "last /8 policy" /22s, yes or no? > > If we want restrictions, then this will have consequences (like, if you > close your LIR and are not selling off the whole business, the /22 will > be returned). > > If we want *no* restrictions, this will also have consequences - namely, > some (few) people making money based on resources other folks have set > aside to be there for the long-term good of the RIPE region, which many > others see as immoral and abusive. > > But do not complain about the potential consequences, please just answer > the question. > > Gert Doering > -- NetMaster From jim at rfc1035.com Mon Jun 20 11:30:32 2016 From: jim at rfc1035.com (Jim Reid) Date: Mon, 20 Jun 2016 10:30:32 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080433.GZ79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: > On 20 Jun 2016, at 09:04, Gert Doering wrote: > > But I'm close to giving up on this and calling a ban on further changes > to the IPv4 policy +1 > - the "new LIR" folks here are accting in a fairly > irresponsible way regarding *future* participants, while at the same > time complaining that they are treated unfairly by the old LIRs - totally > ignoring the fact that *without the foresight of these old LIRs* you > wouldn't have any space at all today. Indeed. The irony of this is completely lost on these "new LIR? folks?. A possible compromise might be a requirement for future IPv4 policy proposals to show that they do not disadvantage future participants or increase the burn rate of the remaining IPv4 pool. Same thing really. From gert at space.net Mon Jun 20 11:32:57 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 11:32:57 +0200 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> Message-ID: <20160620093257.GE79185@Space.Net> Hi, On Mon, Jun 20, 2016 at 10:23:12AM +0100, Jim Reid wrote: > > On 20 Jun 2016, at 10:16, Gert Doering wrote: > > > > - do we want to restrict trading of "last /8 policy" /22s, yes or no? > > ... > > But do not complain about the potential consequences, please just answer > > the question. > > No. Maybe. Depends. > > If we do tweak the current policy, there???s one consequence that has to be considered though: the integrity and accuracy of the RIPE database. Of course, right you are. Changing policy must not be done without considering the consquences, and I did not want to imply that. The problem with this thread, though, is that people have been complaining about lots of implicit things, which might or might not actually *be* a consequence of the change (like, stuff no longer present in v2), without bothering to consider the proposal itself. And this, frankly, is just a little bit annoying. (Regarding the DB accuracy, I think Sander has answered this upthread in a way I find convincing: if trading for these /22s is limited, of course someone who trades "under the desk" will not be able to update the registry, so potentially someone else uses the /22 and can not document that. Would I buy a /22 that I can not legally transfer into my LIR? No, because I'm all at the mercy of the seller - if he closes his LIR, "my" /22 is gone. So I'd go and find a unencumbed /22 on the market - and in my book, this would mean "mission accomplished, trading discouraged") Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From frettled at gmail.com Mon Jun 20 11:45:39 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 20 Jun 2016 11:45:39 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> Message-ID: On Mon, Jun 20, 2016 at 11:01 AM, Aleksey Bulgakov wrote: > Hi. > > I think there is 2015-01 and it is enough to prevent reselling for > undistributed 185./8 and others proposals make more problems for all - > members, RIPE stuff, member's customers. E.g. is multiple accoutns > when executive board suspend it and then asked to vote to allow it > again. The IPs aren't burn (it is not oil or gas) even some one sell > it. Simply the owner is some LIR but not the NCC. May be it will > increase the price, no more. But the NCC wants to have exclusive > rights to sell it (but RIPE is not organisation to make profit or I am > wrong? :) ) and creates new proposals. > You are wrong in the sense of "not even wrong". 1) It's not about 185/8 2) It's not "burning" as in setting fire to something, but as in further reducing the available address space for registration. 3) You've got the whole "ownership" thing mixed up. 4) You've got the whole "rights to sell" thing mixed up. 5) You've got the whole "make profit" thing mixed up. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Mon Jun 20 11:50:59 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 20 Jun 2016 11:50:59 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: On Mon, Jun 20, 2016 at 11:30 AM, Jim Reid wrote: > > > On 20 Jun 2016, at 09:04, Gert Doering wrote: > > > > But I'm close to giving up on this and calling a ban on further changes > > to the IPv4 policy > > +1 > I'm almost there. In the early discussion phase, I was tending towards being against the proposal being discussed, with a certain does of "meh, doesn't matter much". But then all the extremely bad opposing non-arguments kindof have convinced me that 2016-03 is needed, and should probably be implemented. After that, though, I think further changes are unnecessary. > > A possible compromise might be a requirement for future IPv4 policy > proposals to show that they do not disadvantage future participants or > increase the burn rate of the remaining IPv4 pool. Same thing really. > > How does one go about restricting future policy proposals? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Jun 20 12:13:29 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 12:13:29 +0200 Subject: [address-policy-wg] restricting future policy proposals July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <20160620101329.GF79185@Space.Net> Hi, On Mon, Jun 20, 2016 at 11:50:59AM +0200, Jan Ingvoldstad wrote: > How does one go about restricting future policy proposals? Re-read https://www.ripe.net/publications/docs/ripe-642, this is not easily doable within the PDP (which makes sense). One could argue that "The proposal is usually submitted via the chair of that WGs" (2.1, "Creating a proposal") would give the WG chair veto power, but that's not the idea here - it's "the WG chair *helps* with the submission" (and while we've tried talking proposers out of particularily contentious proposals before, when they insisted in going forward, we've let them gain their own experiences...). So, the one true way would be to call for WG consensus on guidelines how a future proposal *should* be (OTOH there might be reasons for having exceptions, hard to predict...) and measure future proposals on these guidelines. (In case it's not obvious why we, as the WG, would *want* to go there: what is happening right now is totally killing our policy development process - heated and repetitive discussions, with lots of selfish or irrational arguments, effectively burning valuable attention time from those who are still interested in contributing to the common goal of a sustainable Internet, working mostly well for all of us) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jim at rfc1035.com Mon Jun 20 12:19:22 2016 From: jim at rfc1035.com (Jim Reid) Date: Mon, 20 Jun 2016 11:19:22 +0100 Subject: [address-policy-wg] restricting policy proposals In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: > On 20 Jun 2016, at 10:50, Jan Ingvoldstad wrote: > > How does one go about restricting future policy proposals? How about the NCC?s Policy Development Officer puts bad or poorly judged ones in the bottom of a locked filing cabinet hidden in an abandoned toilet with a sign on the door saying ?Beware of the Leopard?. :-) From elvis at velea.eu Mon Jun 20 12:53:29 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Mon, 20 Jun 2016 13:53:29 +0300 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: <20160620093257.GE79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> <20160620093257.GE79185@Space.Net> Message-ID: <6753644494662334406@unknownmsgid> Hi Gert, I am surprised to see that you are defending this proposal more than the proposer :) > On Jun 20, 2016, at 12:33, Gert Doering [...] > (Regarding the DB accuracy, I think Sander has answered this upthread > in a way I find convincing: if trading for these /22s is limited, of > course someone who trades "under the desk" will not be able to update > the registry, so potentially someone else uses the /22 and can not document > that. Would I buy a /22 that I can not legally transfer into my LIR? legally? > No, because I'm all at the mercy of the seller - if he closes his LIR, > "my" /22 is gone. So I'd go and find a unencumbed /22 on the market - and > in my book, this would mean "mission accomplished, trading discouraged") If things would be so simple... Look at what's happening in ARIN. Lots of transfers (some very large ones as well) are done by means of financial/contractual artifices (furures contracts and such) avoiding the needs based criteria from the policy. Millions of IPs seem to change hands but the transfer are not recorded in the registry. While *you* would not trade a 'last allocated' block, it does not mean that these will not trade. I have been extremely happy with the very simple (non-restrictive) transfer policy that we have had for years and I think this proposal will only complicate things. Yet an other colour of the IPv4 space is something we should avoid. Numbers are numbers and giving them colours - legacy, anycast, PA, PI -, and now non-transferable is something we as a community should avoid. And if it were to still work on the IPv4 policy, I would do my best to clean all these colours away and keep only one. The M&As have been an issue for years and these will become the next issue if this proposal gets accepted. I also await the response from the NCC before commenting further on this issue. I also do not think it's ok to have a policy change the status of a resource 'in the middle of the game' and think that even if accepted, this proposal should cause a change of status only from the moment it is implemented. > > Gert Doering > -- APWG chair /elvis From radu at pengooin.net Mon Jun 20 12:56:37 2016 From: radu at pengooin.net (Radu Gheorghiu) Date: Mon, 20 Jun 2016 13:56:37 +0300 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: <6753644494662334406@unknownmsgid> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> <20160620093257.GE79185@Space.Net> <6753644494662334406@unknownmsgid> Message-ID: <5767CBE5.3080409@pengooin.net> Well said! Regards, Radu Gheorghiu On 06/20/2016 01:53 PM, Elvis Daniel Velea wrote: > Hi Gert, > > I am surprised to see that you are defending this proposal more than > the proposer :) > >> On Jun 20, 2016, at 12:33, Gert Doering > [...] >> (Regarding the DB accuracy, I think Sander has answered this upthread >> in a way I find convincing: if trading for these /22s is limited, of >> course someone who trades "under the desk" will not be able to update >> the registry, so potentially someone else uses the /22 and can not document >> that. Would I buy a /22 that I can not legally transfer into my LIR? > legally? > >> No, because I'm all at the mercy of the seller - if he closes his LIR, >> "my" /22 is gone. So I'd go and find a unencumbed /22 on the market - and >> in my book, this would mean "mission accomplished, trading discouraged") > If things would be so simple... > > Look at what's happening in ARIN. Lots of transfers (some very large > ones as well) are done by means of financial/contractual artifices > (furures contracts and such) avoiding the needs based criteria from > the policy. Millions of IPs seem to change hands but the transfer are > not recorded in the registry. > > While *you* would not trade a 'last allocated' block, it does not mean > that these will not trade. > > I have been extremely happy with the very simple (non-restrictive) > transfer policy that we have had for years and I think this proposal > will only complicate things. > > Yet an other colour of the IPv4 space is something we should avoid. > Numbers are numbers and giving them colours - legacy, anycast, PA, PI > -, and now non-transferable is something we as a community should > avoid. And if it were to still work on the IPv4 policy, I would do my > best to clean all these colours away and keep only one. > > The M&As have been an issue for years and these will become the next > issue if this proposal gets accepted. I also await the response from > the NCC before commenting further on this issue. > > I also do not think it's ok to have a policy change the status of a > resource 'in the middle of the game' and think that even if accepted, > this proposal should cause a change of status only from the moment it > is implemented. > >> Gert Doering >> -- APWG chair > /elvis > From sebastian at karotte.org Mon Jun 20 13:17:48 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Mon, 20 Jun 2016 13:17:48 +0200 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: <6753644494662334406@unknownmsgid> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> <20160620093257.GE79185@Space.Net> <6753644494662334406@unknownmsgid> Message-ID: <20160620111748.GA25830@danton.fire-world.de> * Elvis Daniel Velea [2016-06-20 12:57]: > Hi Gert, > > I am surprised to see that you are defending this proposal more than > the proposer :) > > > On Jun 20, 2016, at 12:33, Gert Doering > [...] > > (Regarding the DB accuracy, I think Sander has answered this upthread > > in a way I find convincing: if trading for these /22s is limited, of > > course someone who trades "under the desk" will not be able to update > > the registry, so potentially someone else uses the /22 and can not document > > that. Would I buy a /22 that I can not legally transfer into my LIR? > > legally? legally = there is no offical way to transfer the /22. You're violating the policy. > > No, because I'm all at the mercy of the seller - if he closes his LIR, > > "my" /22 is gone. So I'd go and find a unencumbed /22 on the market - and > > in my book, this would mean "mission accomplished, trading discouraged") > > If things would be so simple... > > Look at what's happening in ARIN. Lots of transfers (some very large > ones as well) are done by means of financial/contractual artifices > (furures contracts and such) avoiding the needs based criteria from > the policy. Millions of IPs seem to change hands but the transfer are > not recorded in the registry. ARIN is a completely different situation. There is no needs based criteria in the RIPE region. It is really simple to transfer address space. This was done exactly to avoid these constructs and false database entries. > I have been extremely happy with the very simple (non-restrictive) > transfer policy that we have had for years and I think this proposal > will only complicate things. It will complicate things for whom? It does not touch anything except the prefixes allocated under the last /8 policy. > Yet an other colour of the IPv4 space is something we should avoid. > Numbers are numbers and giving them colours - legacy, anycast, PA, PI > -, and now non-transferable is something we as a community should > avoid. And if it were to still work on the IPv4 policy, I would do my > best to clean all these colours away and keep only one. That would mean we run out of space tomorrow. This is not what this whole policy is about. It was about preserving space for newcomers. Still most people arguing here seem to have just their short term gain in view. > The M&As have been an issue for years and these will become the next > issue if this proposal gets accepted. I also await the response from > the NCC before commenting further on this issue. Then we will tackle this issue if and when it arises. > I also do not think it's ok to have a policy change the status of a > resource 'in the middle of the game' and think that even if accepted, > this proposal should cause a change of status only from the moment it > is implemented. You always reference "the game". What game exactly do you think this game is? Can you name the rules and goals of the game? Because I find it really difficult to argue this as a game. Because it seems everybody is playing a different game. For the second part, as was stated repeatedly it will only change transfers from the date it is implemented. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From gert at space.net Mon Jun 20 13:21:44 2016 From: gert at space.net (Gert Doering) Date: Mon, 20 Jun 2016 13:21:44 +0200 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: <6753644494662334406@unknownmsgid> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> <20160620093257.GE79185@Space.Net> <6753644494662334406@unknownmsgid> Message-ID: <20160620112144.GG79185@Space.Net> Hi, On Mon, Jun 20, 2016 at 01:53:29PM +0300, Elvis Daniel Velea wrote: > I am surprised to see that you are defending this proposal more than > the proposer :) I'm trying to not side either way, but the poor quality of some of the arguments is annoying me enough to try to counter them. > > On Jun 20, 2016, at 12:33, Gert Doering > [...] > > (Regarding the DB accuracy, I think Sander has answered this upthread > > in a way I find convincing: if trading for these /22s is limited, of > > course someone who trades "under the desk" will not be able to update > > the registry, so potentially someone else uses the /22 and can not document > > that. Would I buy a /22 that I can not legally transfer into my LIR? > legally? "according to the rules that govern transfers" - make it "formally" or "contractually" or whatever word you like more. > > No, because I'm all at the mercy of the seller - if he closes his LIR, > > "my" /22 is gone. So I'd go and find a unencumbed /22 on the market - and > > in my book, this would mean "mission accomplished, trading discouraged") > > If things would be so simple... > > Look at what's happening in ARIN. Lots of transfers (some very large > ones as well) are done by means of financial/contractual artifices > (furures contracts and such) avoiding the needs based criteria from > the policy. Millions of IPs seem to change hands but the transfer are > not recorded in the registry. > > While *you* would not trade a 'last allocated' block, it does not mean > that these will not trade. Well, in that case I can only say "I recommend this to all my competitors" - it would be tremendously silly to buy a /22 that can not be registered to my company, and that the NCC *will* request back (= no route objects, no reverse DNS, no inetnums) if the seller's LIR is closed. Someone buying addresses on the market should understand the market they are operating in - and if not, they should hire a broker to make sure that they will get value for their money. [..] > I also do not think it's ok to have a policy change the status of a > resource 'in the middle of the game' and think that even if accepted, > this proposal should cause a change of status only from the moment it > is implemented. Where was that argument when transfers were initially allowed? Following this argument, we couldn't do any policy changes that affect future actions for pre-existing allocations or assignments. Funny that we could do so in the past just fine. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mje at posix.co.za Mon Jun 20 13:41:59 2016 From: mje at posix.co.za (Mark Elkins) Date: Mon, 20 Jun 2016 13:41:59 +0200 Subject: [address-policy-wg] restricting policy proposals In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <5767D687.2080507@posix.co.za> On 20/06/2016 12:19, Jim Reid wrote: > >> On 20 Jun 2016, at 10:50, Jan Ingvoldstad >> wrote: >> >> How does one go about restricting future policy proposals? > > How about the NCC?s Policy Development Officer puts bad or poorly > judged ones in the bottom of a locked filing cabinet hidden in an > abandoned toilet with a sign on the door saying ?Beware of the > Leopard?. :-) ... in a locked basement with broken stairs? -- Mark James ELKINS - Posix Systems - (South) Africa mje at posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4230 bytes Desc: S/MIME Cryptographic Signature URL: From mje at posix.co.za Mon Jun 20 14:45:05 2016 From: mje at posix.co.za (Mark Elkins) Date: Mon, 20 Jun 2016 14:45:05 +0200 Subject: [address-policy-wg] restricting policy proposals In-Reply-To: <5767D687.2080507@posix.co.za> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> <5767D687.2080507@posix.co.za> Message-ID: <5767E551.2060807@posix.co.za> Found it! On 20/06/2016 13:41, Mark Elkins wrote: > > > On 20/06/2016 12:19, Jim Reid wrote: >> >>> On 20 Jun 2016, at 10:50, Jan Ingvoldstad >>> wrote: >>> >>> How does one go about restricting future policy proposals? >> >> How about the NCC?s Policy Development Officer puts bad or poorly >> judged ones in the bottom of a locked filing cabinet hidden in an >> abandoned toilet with a sign on the door saying ?Beware of the >> Leopard?. :-) > > ... in a locked basement with broken stairs? ?But the plans were on display?? ?On display? I eventually had to go down to the cellar to find them.? ?That?s the display department.? ?With a flashlight.? ?Ah, well, the lights had probably gone.? ?So had the stairs.? ?But look, you found the notice, didn?t you?? ?Yes,? said Arthur, ?yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ?Beware of the Leopard.? -- Mark James ELKINS - Posix Systems - (South) Africa mje at posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4230 bytes Desc: S/MIME Cryptographic Signature URL: From remco.vanmook at gmail.com Mon Jun 20 14:50:47 2016 From: remco.vanmook at gmail.com (Remco van Mook) Date: Mon, 20 Jun 2016 14:50:47 +0200 Subject: [address-policy-wg] 2016-03: trading the last /22? In-Reply-To: <6753644494662334406@unknownmsgid> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> <20160620091650.GC79185@Space.Net> <20160620093257.GE79185@Space.Net> <6753644494662334406@unknownmsgid> Message-ID: Hi Elvis, > On 20 Jun 2016, at 12:53 , Elvis Daniel Velea wrote: > > Hi Gert, > > I am surprised to see that you are defending this proposal more than > the proposer :) Since I'm the proposer I might as well respond. You know full well I'm capable of defending myself in any argument, so I'm kind of sad to see this half-accusation flying around, even as a joke - it isn't actually about the proposal. Given the state of the the discussion around v2 of this proposal, with about 120 emails as of this afternoon, of which a substantial part are rants, oneliners, conspiracy theories and off-topic anger, I've all but lost track on what substantive arguments have been presented that haven't already been addressed in this discussion. And so, I can well imagine, have others. Between Gert as chair of this working group and me as a proposer, I have the easier job in this discussion as I only need to respond to the bits I think are relevant to the proposal; Gert however, has the unfortunate task of having to keep track of proponents, opposers and substantive arguments against the proposal as written. With that out of the way, responding to the well-made observation by James Blessing last week: "Do we need to have the option for an LIR to transfer to and LIR who hasn't already had their final allocation?" I think that's a very good point. Ideally, we'd repeal the transfer ban from this proposed policy when the RIPE NCC runs out of address space to satisfy article 5.1 of the IPv4 allocation policy - after all, the aim of the proposal is to restrict speculative behaviour while sticking with 'business as usual' for all others. Unfortunately, looking at the quagmire that we've walked into, I'd be very surprised if we'd have any functional IPv4 policy forming body left at that point. As for the other implication of this question, meaning a transfer before that day, I don't see why you'd want to do that; on top of that, making that carve-out likely creates yet another loophole for speculative purposes. I think we'd do ourselves and the chairs a massive favour if we can keep this discussion civil and to the point. Kind regards, Remco -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pk at DENIC.DE Mon Jun 20 15:08:39 2016 From: pk at DENIC.DE (Peter Koch) Date: Mon, 20 Jun 2016 15:08:39 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> Message-ID: <20160620130839.GF11187@x28.adm.denic.de> Remco, On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: > I would encourage everyone to carefully read this second version (and not just respond "no, still hate it, kill it with fire") as it is quite different from the first version. I have read version 2, also in comparison with version 1. Thanks for removing the DNS and route: objects restrictions. > Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. while the intent is laudable, making it a requirement under 5.1 mixes the formal part and the informational in a confusing way. That said, does "should reserve at least part of this allocation for interoperability with networks that are only reachable using IPv4" mean "should assign at least part of this allocation ... to itself"? And further along the lines of educational text: the references in section need some re-adjustment (this isn't new in 2.0, but for good housekeeping) since RFC 3330 has been finally obsoleted by RFC 6890 (and may or may not be applicable anyway) and RFC 2993 isn't really the final word on NAT any more, especially with that earlier remark on "for interoperability with networks that are only reachable using IPv4". The clarification part remains complicated because of indirections: 5.3 refers to 5.1 only, but the new "ALLOCATED FINAL" then extends the validity across the remaining sections. I'd suggest to give up 5.3 and merge the new text with the final paragraph of 5.2 accordingly. -Peter From pk at DENIC.DE Mon Jun 20 15:16:58 2016 From: pk at DENIC.DE (Peter Koch) Date: Mon, 20 Jun 2016 15:16:58 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080433.GZ79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <20160620131658.GG11187@x28.adm.denic.de> Hi Gert, On Mon, Jun 20, 2016 at 10:04:33AM +0200, Gert Doering wrote: > But I'm close to giving up on this and calling a ban on further changes > to the IPv4 policy - the "new LIR" folks here are accting in a fairly I'd hope you're at least half kidding here. While I'd agree that > This is not the way to do bottom-up policy making - "I want my cookie and > I want it now, and I do not care for the greater good". is about to explore the edges of what can be reasonable dealt with in a consensus based process under runout conditions, any eternity stamp on policy would be unwise not only for formal reasons, but also because it would prohibit clarifications and more substantial actions in this whac-a-mole game. The PDP, though, already gives the chairs some leeway of throttling or dampening the influx of proposals. -Peter From remco.vanmook at gmail.com Mon Jun 20 15:37:34 2016 From: remco.vanmook at gmail.com (Remco van Mook) Date: Mon, 20 Jun 2016 15:37:34 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620130839.GF11187@x28.adm.denic.de> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <20160620130839.GF11187@x28.adm.denic.de> Message-ID: Hi Peter, > On 20 Jun 2016, at 15:08 , Peter Koch wrote: > > while the intent is laudable, making it a requirement under 5.1 mixes > the formal part and the informational in a confusing way. That said, > does "should reserve at least part of this allocation for interoperability with > networks that are only reachable using IPv4" mean "should assign at least part > of this allocation ... to itself"? That mix is for all it's pros and cons, intentional. LIRs 'must' be informed (the must part of that point) about the special condition this block is being allocated in, much in the same way as they 'must' make assignments from the allocation - whether to customers, self or infrastructure. The 'should' part is phrased in such a way that because I didn't want an explicit reference to any other standard or technology in the IPv4 allocation policy. Whether the space is used for IPv6 migration or whatever protocol next century makes no difference, if you want to talk to IPv4 here's the block of space to do that with. > And further along the lines of educational text: the references in section need > some re-adjustment (this isn't new in 2.0, but for good housekeeping) since > RFC 3330 has been finally obsoleted by RFC 6890 (and may or may not be applicable > anyway) and RFC 2993 isn't really the final word on NAT any more, especially > with that earlier remark on "for interoperability with networks that are only > reachable using IPv4". > Noted. > The clarification part remains complicated because of indirections: 5.3 refers to > 5.1 only, but the new "ALLOCATED FINAL" then extends the validity across the > remaining sections. I'd suggest to give up 5.3 and merge the new text with the > final paragraph of 5.2 accordingly. The IPv4 allocation policy as it stands is not what I'd call a thing of beauty, and if rewritten in its entirety should probably look a lot different. The way I see it, paragraphs 5.2 and 5.3 serve different purposes, and merging them removes that bit of much needed clarity. To be clear - it's not my intention to rewrite the whole policy; just adding some bits and pieces that I felt were needed. If I can clean up a paragraph that I'm editing anyway, so much the better. Thanks for your feedback. Best regards Remco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex at vpsville.ru Mon Jun 20 19:04:36 2016 From: alex at vpsville.ru (Alexey Galaev) Date: Mon, 20 Jun 2016 21:04:36 +0400 (MSK) Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <1631143488.10227.1466442276046.JavaMail.zimbra@vpsville.ru> I?m inclined to disagree with proposal I used to see and I have a different take on it. We have the main problem: there are no IPv4 address space for all. This proposal just take privilege to old LIR's and limit in rights all new LIR's. But this does not solve the problem. We need to use IPv4 more effectively and stimulate to use IPv6. Why can't we add some payment for ALL current IPv4 blocks? For example, 0.5$/year for IP. All unusable IPv4 will be returned as unprofitable. What the difference between unused space from last /8 and unused space from first /8? And what the differnce between old and new LIR's? Also we need simple rules and right for all. A lot of new statuses and fields is not good to perception system. BR, Alexey Galaev +7 985 3608004, http://vpsville.ru ----- ???????? ????????? ----- ??: "Stefan Prager" ????: address-policy-wg at ripe.net ????????????: ???????, 18 ???? 2016 ? 13:58:48 ????: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) > On 2016-06-17 21:09:21 CET, Remco van Mook wrote: > Let me get this straight - you oppose a proposed change in policy because the change itself is not part of current policy? I strongly oppose your proposal as it seeks to selectively strip Provider Aggregatable(PA) resource holders of their rights solely justified by your belief that this is how allocations allocated after the 14th September 2012 are supposed to be treated. If you are concerned about people selling off address space allocated after the 14th September 2012 for profit you can propose to change the holding period from two years to three or four years or even introduce a transfer fee like other Regional Internet Registries(RIRs) have in place. Such changes would be just and apply to all Provider Aggregatable(PA) allocations and not just to Provider Aggregatable(PA) allocations allocated after the 14th September 2012. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From frettled at gmail.com Mon Jun 20 20:06:17 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 20 Jun 2016 20:06:17 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1631143488.10227.1466442276046.JavaMail.zimbra@vpsville.ru> References: <1631143488.10227.1466442276046.JavaMail.zimbra@vpsville.ru> Message-ID: On Mon, Jun 20, 2016 at 7:04 PM, Alexey Galaev wrote: > I?m inclined to disagree with proposal I used to see and I have a > different take on it. > > We have the main problem: there are no IPv4 address space for all. This > proposal just take privilege to old LIR's and limit in rights all new > LIR's. But this does not solve the problem. We need to use IPv4 more > effectively and stimulate to use IPv6. Why can't we add some payment for > ALL current IPv4 blocks? Because this group decides address policy, not membership fees. > For example, 0.5$/year for IP. All unusable IPv4 will be returned as > unprofitable. What the difference between unused space from last /8 and > unused space from first /8? The difference is that there is no "unused space from first /8". > And what the differnce between old and new LIR's? > The difference appears to be that the old LIRs wanted new LIRs to have a chance to exist, while new LIRs do not want new LIRs to exist. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Mon Jun 20 21:31:45 2016 From: rgori at wirem.net (Riccardo Gori) Date: Mon, 20 Jun 2016 21:31:45 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080433.GZ79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <1466275425.3556936.641574361.6381E750@webmail.messagingengine.com> <20160620080433.GZ79185@Space.Net> Message-ID: <933a1b00-8b9e-064d-6051-6e95deff7b1f@wirem.net> Hi, Il 20/06/2016 10:04, Gert Doering ha scritto: > I would consider this also as a fringe case - legitimate according to the > letter of the policy, but not according to the spirit. These /22s are > not for trading. There is space allocated for trading? > > But I'm close to giving up on this and calling a ban on further changes > to the IPv4 policy I would support it. > - the "new LIR" folks here are accting in a fairly > irresponsible way regarding *future* participants, while at the same > time complaining that they are treated unfairly by the old LIRs - totally > ignoring the fact that *without the foresight of these old LIRs* you > wouldn't have any space at all today. To punish the bad behavior of one this 2016-03 policy would have many bad side effect as I already thanked old LIRs didn't request their /22 if you part of those I am perfectly aware I have to be thankful about this filantropy. > This is not the way to do bottom-up policy making - "I want my cookie and > I want it now, and I do not care for the greater good". bottom up is to listen arguments from everyone in the community and find a reasonable agreement that satisfies all parties > > Gert Doering > -- APWG chair regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Mon Jun 20 22:14:57 2016 From: rgori at wirem.net (Riccardo Gori) Date: Mon, 20 Jun 2016 22:14:57 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620080050.GY79185@Space.Net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> Message-ID: <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> Hi Gert, thank you for your reply Il 20/06/2016 10:00, Gert Doering ha scritto: > Hi, > > On Sat, Jun 18, 2016 at 05:02:50PM +0200, Riccardo Gori wrote: >> Il 18/06/2016 14:49, Gert Doering ha scritto: >>> hi, >>> >>> On Fri, Jun 17, 2016 at 10:49:59PM +0200, Riccardo Gori wrote: >>>> I am strongly against to every proposal that higher the disvlaantage to >>>> already disvantaged new and future pyers (LIRs after 09/2012) >>> This proposal actually will only disadvantage "young LIRs" if they want >>> to do stuff with their /22 that is frowned upon by the community - namely, >>> trade, instead of "use for >> This would disvantage every LIR that received or will reiceve an >> ad-normal PA allocation. > You keep repeating this, which does not make it more true. > > Please explain how this proposal would affect a LIR that intends to use > the /22 to number its customers (and/or its own infrastructure), and is not > intending to sell off the address space as quickly as possible to make a > quick profit. Teorically not, but practically creates class-b LIRs. I am against speculators but I would not like discrimination between old and new LIRs. I wouldn't like to be discriminated. You would like to be? Let's choose that in the future only ALLOCATED-FINAL can be transferabble 'cause those allocation are for higher prospective of an IPv6 transition (we don't force IPv6 adoption) and old allocation can stay stuck there and unused so we can go 6 happier. To be serius: If you allow the creation of a category-b LIR I can't see positivity in it. A less capable LIR born invalid. Suppose your business for some reason has lot of customers for exmaple 'cause you grows dual stack and IPv6 is spreading. You can sell it one piece, but can happen you can even sell only customers and infrastructure and the acquiring company has enough address space or simply not interested because working IPv6. You may want to transfer part of space to your new company just created to set up a new datacenter or just keep on with IPv6 transition consulting services. You may even want transfer part of the space to companies that need it. Why shouldn't be possible? This LIR did no speculation at all, actually did really a good job of moving customers IPv6 and growing a company. Just reached the task that is not even more mentioned in IPv4 allocation policy today. Where's the quick profit? years of work on IPv4/IPv6 transition with infrastructure costs, ip transit and so on? > >> Please leave the idea of ab-normal LIRs. > This is not an "idea" but observed behaviour by a few bad actors. We must find the way to hurt only the few bad actors not all new LIRs. > > [..] >> Nobody protects new LIRs speculator stockpile /22 in a zero cost >> company/person without network or assignements and black sell it the >> same day it has been allocated >> with a private contract registered elsewhere from RIPE database. >> This policy is useless. Audit and control is useful, transparency is a >> must we discussed it at last general > This paragraph does not make sense. > > Yes, people can get a /22 and "black sell it", even with 2016-01 - but > the risk for the buyer is much higher than getting a "white" /22 on the > address market, because the seller has to keep open the LIR forever in > this case - and if the LIR is ever closed, the /22 has to be returned to > the RIPE NCC. So why should a buyer take this risk? Elvis gived later today an example of what's happening in ARIN about that. I think we all would prefer transparency. > > Gert Doering > -- APWG chair regards Riccardo -- WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- From sander at steffann.nl Mon Jun 20 23:00:22 2016 From: sander at steffann.nl (Sander Steffann) Date: Mon, 20 Jun 2016 23:00:22 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> Message-ID: <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Hi Riccardo, > Teorically not, but practically creates class-b LIRs. I am against speculators but I would not like discrimination between old and new LIRs. There is none, please stop repeating that. > I wouldn't like to be discriminated. You would like to be? This is a ridiculous statement. Enough. Every LIR is the same with the same rights. Under the proposed policy every LIR gets a /22, and no LIR can sell that /22. What you keep complaining about is that new LIRs can't get as many IPv4 addresses for free as LIRs that started before September 2012. That is just the way it is. Policy changes over time, and things that were possible in the past are no longer possible today. Circumstances change. If we (the community) hadn't changed the policy like that then there would be no addresses to give out at all anymore. But all of that has nothing to do with this policy discussion. In your previous message you spoke about the bottom up process, that it means that everybody has to be listened to. That is almost correct. What it means is that everybody is allowed to speak and have their arguments considered seriously. If those arguments are found to be false then they can be put aside, and nobody is required to keep listening to endless repeats of those same rejected arguments. Cheers, Sander From arash_mpc at parsun.com Tue Jun 21 02:19:29 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Tue, 21 Jun 2016 10:19:29 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <1631143488.10227.1466442276046.JavaMail.zimbra@vpsville.ru> Message-ID: <028d01d1cb52$95e95a30$c1bc0e90$@parsun.com> >The difference appears to be that the old LIRs wanted new LIRs to have a chance to exist, while new LIRs do not want new LIRs to exist. 2016-03 is giving more advantage to the old LIRs which is not fair (fairness is not impossible to achieve, at least we need to try), 2015-01 is enough to prevent new LIRs from trading their /22 if that?s their only intention to become a member. 2016-03 is trying to solve a problem but also adding more. I agree that the community should think about the future and new-comers but that does not mean everyone has to agree to a bad policy, resulting in returning smallest blocks by new LIRs while letting old ones continue selling bigger blocks. I know this policy is not about returning allocations (no need to repeat that again) but some restrictions coming from this are not really acceptable. Arash -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash.naderpour at gmail.com Mon Jun 20 10:56:47 2016 From: arash.naderpour at gmail.com (Arash Naderpour) Date: Mon, 20 Jun 2016 18:56:47 +1000 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <20160620084240.GB79185@Space.Net> References: <5E559932-DC0A-43EF-8110-3FAAFD65F730@steffann.nl> <025301d1c886$c6f394c0$54dabe40$@rasana.net> <20160617123950.GA23322@danton.fire-world.de> <20160620084240.GB79185@Space.Net> Message-ID: > > > > This policy is not about "return allocations", but about reducing the > burn rate by reserving /22s for those who actually want to run a network > with it, instead of trade away quickly for a short gain. > > When an allocation is not transferable to another member, one day they need to be returned to RIPE NCC. Arash -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Tue Jun 21 09:17:58 2016 From: rgori at wirem.net (Riccardo Gori) Date: Tue, 21 Jun 2016 09:17:58 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Message-ID: Hi Sander, Il 20/06/2016 23:00, Sander Steffann ha scritto: > Hi Riccardo, > >> Teorically not, but practically creates class-b LIRs. I am against speculators but I would not like discrimination between old and new LIRs. > There is none, please stop repeating that. I can ask the same If we had a proposal that changes the policy behaviour creating a new fantasy example category "ALLOCATED BEFORE FINAL" to all allocation created before 14/09/2012 this would be discriminating anyone received such kind of allocation from who didn't. Positive or negative discrimination depends on how it will affect such allocation. In all cases would create problems. History repeating. The current policies even in other RIR (i think it, i am not so informed about that and can be wrong) are trying to move over "colors" and not using them to discriminate between allocations. PI can be converted in PA easily in RIPE. Why shouldn't be the same for an newly invented "ALLOCATED BEFORE FINAL" or an "ALLOCATED FINAL"? At RIPE meetings Registration Services make an update about the status of the database and there's some slide titeled "IPv4 blocks with status that cause issues" You know what? there's is mentioned ALLOCATED PI, ALLOCATED UNSPECIFIED. This means discrimination between allocation creates problem to LIRs. I really don't see any reason to create fantasy colors when at RIPE meetings it has been asked publically to take an effort on moving over it. I invite you to read these from Registration Services update about different colors allocations: https://ripe71.ripe.net/presentations/86-FeedbackRS-RIPE71.pdf https://ripe72.ripe.net/presentations/112-FeedbackRS-RIPE72_final.pdf [...] RIPE NCC encourages: - LIRs to strive to convert to ASSIGNED PA ?Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.? - LIRs to not create new ASSIGNED PI - Where possible to convert to ALLOCATED PA [...] > >> I wouldn't like to be discriminated. You would like to be? > This is a ridiculous statement. Enough. read above. > > Every LIR is the same with the same rights. Under the proposed policy every LIR gets a /22, and no LIR can sell that /22. True but unnecessary > > What you keep complaining about is that new LIRs can't get as many IPv4 addresses for free as LIRs that started before September 2012. That is just the way it is. Policy changes over time, and things that were possible in the past are no longer possible today. Circumstances change. If we (the community) hadn't changed the policy like that then there would be no addresses to give out at all anymore. I am not complaing about that discussing this policy I was just thanking again old LIRs 'cause Gert remembered me the same note here. > > But all of that has nothing to do with this policy discussion. In your previous message you spoke about the bottom up process, that it means that everybody has to be listened to. That is almost correct. > > What it means is that everybody is allowed to speak and have their arguments considered seriously. If those arguments are found to be false then they can be put aside, and nobody is required to keep listening to endless repeats of those same rejected arguments. > > Cheers, > Sander > I am not thinking my arguments are false. regards Riccardo -- WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From lists at velder.li Tue Jun 21 10:53:07 2016 From: lists at velder.li (Patrick Velder) Date: Tue, 21 Jun 2016 10:53:07 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Message-ID: <57690073.1070701@velder.li> Hi What about assignments from the ALLOCATED FINAL? Will it be "ASSIGNED FINAL"? Or partitioned space "LIR-PARTITIONED FINAL" :-) Regards Patrick On 21.06.2016 09:17, Riccardo Gori wrote: > > Hi Sander, > > Il 20/06/2016 23:00, Sander Steffann ha scritto: >> Hi Riccardo, >> >>> Teorically not, but practically creates class-b LIRs. I am against speculators but I would not like discrimination between old and new LIRs. >> There is none, please stop repeating that. > I can ask the same > If we had a proposal that changes the policy behaviour creating a new > fantasy example category "ALLOCATED BEFORE FINAL" to all allocation > created before 14/09/2012 this would be discriminating anyone received > such kind of allocation from who didn't. > Positive or negative discrimination depends on how it will affect such > allocation. In all cases would create problems. History repeating. > The current policies even in other RIR (i think it, i am not so > informed about that and can be wrong) are trying to move over "colors" > and not using them to discriminate between allocations. > > PI can be converted in PA easily in RIPE. Why shouldn't be the same > for an newly invented "ALLOCATED BEFORE FINAL" or an "ALLOCATED FINAL"? > > At RIPE meetings Registration Services make an update about the status > of the database and there's some slide titeled "IPv4 blocks with > status that cause issues" > You know what? there's is mentioned ALLOCATED PI, ALLOCATED > UNSPECIFIED. This means discrimination between allocation creates > problem to LIRs. > I really don't see any reason to create fantasy colors when at RIPE > meetings it has been asked publically to take an effort on moving over it. > > I invite you to read these from Registration Services update about > different colors allocations: > https://ripe71.ripe.net/presentations/86-FeedbackRS-RIPE71.pdf > https://ripe72.ripe.net/presentations/112-FeedbackRS-RIPE72_final.pdf > > [...] > RIPE NCC encourages: > - LIRs to strive to convert to ASSIGNED PA > ?Where possible, LIRs should work to make contractual arrangements to > convert PI addresses into PA addresses.? > - LIRs to not create new ASSIGNED PI > - Where possible to convert to ALLOCATED PA > [...] > >>> I wouldn't like to be discriminated. You would like to be? >> This is a ridiculous statement. Enough. > read above. >> Every LIR is the same with the same rights. Under the proposed policy every LIR gets a /22, and no LIR can sell that /22. > True but unnecessary >> What you keep complaining about is that new LIRs can't get as many IPv4 addresses for free as LIRs that started before September 2012. That is just the way it is. Policy changes over time, and things that were possible in the past are no longer possible today. Circumstances change. If we (the community) hadn't changed the policy like that then there would be no addresses to give out at all anymore. > I am not complaing about that discussing this policy I was just > thanking again old LIRs 'cause Gert remembered me the same note here. >> But all of that has nothing to do with this policy discussion. In your previous message you spoke about the bottom up process, that it means that everybody has to be listened to. That is almost correct. >> >> What it means is that everybody is allowed to speak and have their arguments considered seriously. If those arguments are found to be false then they can be put aside, and nobody is required to keep listening to endless repeats of those same rejected arguments. >> >> Cheers, >> Sander >> > I am not thinking my arguments are false. > regards > Riccardo > -- > > > > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying toinfo at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: From randy at psg.com Tue Jun 21 11:06:20 2016 From: randy at psg.com (Randy Bush) Date: Tue, 21 Jun 2016 11:06:20 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Message-ID: i have had an epiphany! RIR stands for Rinse and Infinite Repeat. this expains it all. i feel much better now. randy From sander at steffann.nl Tue Jun 21 11:06:48 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2016 11:06:48 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Message-ID: <8D7D60E5-DCE4-43D4-87C9-AEC1189EDDF2@steffann.nl> Hi Riccardo, > If we had a proposal that changes the policy behaviour creating a new fantasy example category "ALLOCATED BEFORE FINAL" to all allocation created before 14/09/2012 this would be discriminating anyone received such kind of allocation from who didn't. Every LIR can receive that allocation. > PI can be converted in PA easily in RIPE ??? > I invite you to read these from Registration Services update about different colors allocations: > https://ripe71.ripe.net/presentations/86-FeedbackRS-RIPE71.pdf > https://ripe72.ripe.net/presentations/112-FeedbackRS-RIPE72_final.pdf Thank you, I know very well what happened in my own working group. > [...] > RIPE NCC encourages: > - LIRs to strive to convert to ASSIGNED PA > ?Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.? > - LIRs to not create new ASSIGNED PI > - Where possible to convert to ALLOCATED PA > [...] That is from a slide talking about ALLOCATED PI, you seem to be taking it out of context and applying it to all PI. > I am not thinking my arguments are false. Yeah, that bit is obvious. However, you have repeated your point over and over again without providing any convincing data to back it up, so we're stopping this argument now. Feel free to discuss other issues you see, but the "class-b LIRs" argument has now been discussed, considered and found incorrect. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Tue Jun 21 11:07:51 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2016 11:07:51 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <57690073.1070701@velder.li> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> <57690073.1070701@velder.li> Message-ID: Hi Patrick, > What about assignments from the ALLOCATED FINAL? Will it be "ASSIGNED FINAL"? Or partitioned space "LIR-PARTITIONED FINAL" :-) Nope, only the allocation will get a different status. The LIR can still use it like before, assign from it etc. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Tue Jun 21 11:09:00 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2016 11:09:00 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Message-ID: <44441FB0-3E61-4EC7-ABB1-26A5EB30D470@steffann.nl> Hi Randy, > i have had an epiphany! RIR stands for Rinse and Infinite Repeat. this > expains it all. i feel much better now. Good one ;) Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From swmike at swm.pp.se Tue Jun 21 11:20:09 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 21 Jun 2016 11:20:09 +0200 (CEST) Subject: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy Message-ID: I just had a thought. What we're trying to do is to make sure there are IPv4 addresses available to new entrants. We're trying to do this by making a LIR get one post-exhaustion /22 each. The LIR fee is the limiting factor in trying to stop people from getting many /22:s. People have been trying to game this, by getting /22 and closing the LIR, thus avoiding the LIR fee. Changes in the policy has been all about trying to limit transfers etc, setting policy from what should happen with /22s, stopping transfers (so people still have to pay LIR fees, one per /22 etc). Since it's actually the post-exhaustion /22 we're after why not do this: The post-exhaustion /22 comes with a fee that is equivalent to the LIR fee. If a LIR contains one post-exhaustion /22, then this fee is waived. Doesn't this just solve the problem everybody is arguing about? Now all of a sudden it's not cheap to get multiple /22s, and we don't care any more if people keep their LIRs open or not, it still costs the same. -- Mikael Abrahamsson email: swmike at swm.pp.se From radu at pengooin.net Tue Jun 21 11:28:44 2016 From: radu at pengooin.net (Radu Gheorghiu) Date: Tue, 21 Jun 2016 12:28:44 +0300 Subject: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy In-Reply-To: References: Message-ID: <576908CC.4050401@pengooin.net> Hello, I think this was discussed during the last RIPE meeting and it was rejected by Nigel due to not being "legal" to raise fees like this. Regards, Radu On 06/21/2016 12:20 PM, Mikael Abrahamsson wrote: > > I just had a thought. > > What we're trying to do is to make sure there are IPv4 addresses > available to new entrants. We're trying to do this by making a LIR get > one post-exhaustion /22 each. The LIR fee is the limiting factor in > trying to stop people from getting many /22:s. People have been trying > to game this, by getting /22 and closing the LIR, thus avoiding the > LIR fee. Changes in the policy has been all about trying to limit > transfers etc, setting policy from what should happen with /22s, > stopping transfers (so people still have to pay LIR fees, one per /22 > etc). > > Since it's actually the post-exhaustion /22 we're after why not do this: > > The post-exhaustion /22 comes with a fee that is equivalent to the LIR > fee. If a LIR contains one post-exhaustion /22, then this fee is waived. > > Doesn't this just solve the problem everybody is arguing about? Now > all of a sudden it's not cheap to get multiple /22s, and we don't care > any more if people keep their LIRs open or not, it still costs the same. > From jim at rfc1035.com Tue Jun 21 11:29:58 2016 From: jim at rfc1035.com (Jim Reid) Date: Tue, 21 Jun 2016 10:29:58 +0100 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> Message-ID: > On 21 Jun 2016, at 10:06, Randy Bush wrote: > > RIR stands for Rinse and Infinite Repeat. That surely means LIR stands for Launder and Infinite Repeat. From sander at steffann.nl Tue Jun 21 11:35:56 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2016 11:35:56 +0200 Subject: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy In-Reply-To: References: Message-ID: <5DA9A6D7-CE90-4500-B8C1-1063B263987F@steffann.nl> Hi Mikael, > I just had a thought. > > What we're trying to do is to make sure there are IPv4 addresses available to new entrants. We're trying to do this by making a LIR get one post-exhaustion /22 each. The LIR fee is the limiting factor in trying to stop people from getting many /22:s. People have been trying to game this, by getting /22 and closing the LIR, thus avoiding the LIR fee. Changes in the policy has been all about trying to limit transfers etc, setting policy from what should happen with /22s, stopping transfers (so people still have to pay LIR fees, one per /22 etc). > > Since it's actually the post-exhaustion /22 we're after why not do this: > > The post-exhaustion /22 comes with a fee that is equivalent to the LIR fee. If a LIR contains one post-exhaustion /22, then this fee is waived. > > Doesn't this just solve the problem everybody is arguing about? Now all of a sudden it's not cheap to get multiple /22s, and we don't care any more if people keep their LIRs open or not, it still costs the same. We are always very careful with linking policy to charging. We tried that in the past and usually ran into some issues. If, however, the RIPE NCC would adapt the charging scheme in this way then it would probably make some policy proposals less relevant :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jim at rfc1035.com Tue Jun 21 11:36:34 2016 From: jim at rfc1035.com (Jim Reid) Date: Tue, 21 Jun 2016 10:36:34 +0100 Subject: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy In-Reply-To: References: Message-ID: <179160E6-FD6A-4775-B26A-BFEBC4539EB3@rfc1035.com> > On 21 Jun 2016, at 10:20, Mikael Abrahamsson wrote: > > The post-exhaustion /22 comes with a fee that is equivalent to the LIR fee. If a LIR contains one post-exhaustion /22, then this fee is waived. It?s up to the NCC membership to make decisions about fees, not this WG. FWIW, I think we?re doomed to debate policy proposals on IPv4, none of which reach consensus, until the NCC?s address pool is gone. Some of those debates may well continue long after that point. :-( From ripe-wgs at radu-adrian.feurdean.net Tue Jun 21 11:52:34 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 21 Jun 2016 11:52:34 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <8D7D60E5-DCE4-43D4-87C9-AEC1189EDDF2@steffann.nl> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> <8D7D60E5-DCE4-43D4-87C9-AEC1189EDDF2@steffann.nl> Message-ID: <1466502754.3746581.643884177.4C971B24@webmail.messagingengine.com> On Tue, Jun 21, 2016, at 11:06, Sander Steffann wrote: > > PI can be converted in PA easily in RIPE > > ??? https://www.ripe.net/manage-ips-and-asns/resource-management/converting-pi-to-pa ASSIGNED PI -> ALLOCATED PA on request. -- Radu-Adrian FEURDEAN fr.ccs From swmike at swm.pp.se Tue Jun 21 11:55:15 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 21 Jun 2016 11:55:15 +0200 (CEST) Subject: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy In-Reply-To: <5DA9A6D7-CE90-4500-B8C1-1063B263987F@steffann.nl> References: <5DA9A6D7-CE90-4500-B8C1-1063B263987F@steffann.nl> Message-ID: On Tue, 21 Jun 2016, Sander Steffann wrote: > We are always very careful with linking policy to charging. We tried > that in the past and usually ran into some issues. If, however, the RIPE > NCC would adapt the charging scheme in this way then it would probably > make some policy proposals less relevant :) Ok, thanks for the clarification. I think this is however something that makes things a lot harder. It's like trying to do sports with your hands tied behind your back. Yes, you can probably get things done but it's a lot harder and usually results in a lot more work. Well, can't we at least take that idea to the current policy proposals, that we don't talk about "LIRs who have received a post-exhaustion /22" but instead talking about "LIRs containing..." What's happened in the past is less interesting than current situation? -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Tue Jun 21 12:00:01 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2016 12:00:01 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466502754.3746581.643884177.4C971B24@webmail.messagingengine.com> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> <8D7D60E5-DCE4-43D4-87C9-AEC1189EDDF2@steffann.nl> <1466502754.3746581.643884177.4C971B24@webmail.messagingengine.com> Message-ID: <67ACC771-C911-4981-A154-DEC461E77D63@steffann.nl> Hi Radu, >>> PI can be converted in PA easily in RIPE >> >> ??? > > https://www.ripe.net/manage-ips-and-asns/resource-management/converting-pi-to-pa > > ASSIGNED PI -> ALLOCATED PA on request. Ah, that one. Thanks for the link-local I was getting confused by the mixed arguments about ALLOCATED PI. Cheers! Sander From sander at steffann.nl Tue Jun 21 12:29:56 2016 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2016 12:29:56 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <67ACC771-C911-4981-A154-DEC461E77D63@steffann.nl> References: <738559ae-e64d-91c2-bd1c-3896138db4b2@wirem.net> <20160618124927.GV79185@Space.Net> <20160620080050.GY79185@Space.Net> <8c787feb-8780-8bc4-8219-2b4f54ee5e29@wirem.net> <6763C3B8-B19A-479B-9B8F-7C14F86BE365@steffann.nl> <8D7D60E5-DCE4-43D4-87C9-AEC1189EDDF2@steffann.nl> <1466502754.3746581.643884177.4C971B24@webmail.messagingengine.com> <67ACC771-C911-4981-A154-DEC461E77D63@steffann.nl> Message-ID: Hi, > Ah, that one. Thanks for the link-local I was getting confused by the mixed arguments about ALLOCATED PI. My auto-complete is getting too used to IPv6 terminology ;) s/-local/./ Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mschmidt at ripe.net Tue Jun 21 14:01:20 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 21 Jun 2016 14:01:20 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <1466205767.2465469.641121201.7A8C10F4@webmail.messagingengine.com> Message-ID: Dear Radu, Thank you for your question: On 2016-06-18 01:22:47 CET, Radu-Adrian FEURDEAN wrote: > It is my understanding, and please someone from RIPE NCC confirm or > infirm that in public, that M&A has "slightly" changed recently, and the > following operations are no longer M&A: > - merging several existing LIRs having the same owner. > - re-organisation of address space between the LIRs of a group. > - purchasing a company but keeping the purchased company's legal entity > (you accountant will give you good reasons for this; if you live in > counties like France, your HR will give a few more reasons). > - putting together resources of several entities within a group without > proceeding with heavy legal and administrative paperwork. > Current procedures allow the transfer of resources between LIR accounts belonging to the same member. If the member decides to close one of their LIR accounts after such a transfer, they must first ensure that the annual membership fee has been paid for that account. I would also like to highlight Nigel's email on behalf of the Executive Board in April, which states that mergers, acquisitions, bankruptcies and liquidations must be supported by official documentation issued by national authorities (e.g. Chamber of Commerce): https://www.ripe.net/ripe/mail/archives/ncc-announce/2016-April/001031.html You mention several examples ? some of these refer to mergers and acquisitions, while others relate to the movement of Internet resources without an actual merger or acquisition taking place, such as combining the resources of related legal entities without legal and administrative paperwork. Following Nigel's clarification, our merger and acquisitions procedure is only applied to actual mergers and acquisitions. All other resource transfers between separate legal entities must be handled according to the transfer sections in the relevant RIPE Policies (for IPv4, IPv6 and AS Numbers). I hope this answers your question. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From nick at foobar.org Wed Jun 22 15:37:17 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 22 Jun 2016 14:37:17 +0100 Subject: [address-policy-wg] ipv6 assignments Message-ID: <576A948D.7050306@foobar.org> Apropos of one of those endless arguments on the Internet (where everything is true, because it says it on the Internet), I had a discussion with Kurtis about the definition of an ipv6 "End Site", which is specified in section 2.9 of RIPE-655. This says: > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > - that service provider assigning address space to the End User > - that service provider providing transit service for the End User to other sites > - that service provider carrying the End User's traffic > - that service provider advertising an aggregate prefix route that contains the End User's assignment Our reading of this is that each of these conditions is mandatory, i.e. logical AND, because logical OR does not make sense. Term 2.9.2 states that an ipv6 End Site is only an End Site if the service provider is providing transit service for the End User to other sites. Section 5.4 and 5.4.1 then state: > LIRs must make IPv6 assignments in accordance with the following provisions. > > End Users are assigned an End Site assignment from their LIR or ISP. So the policy appears to state that an IPv6 assignment can only be issued to an end user if the end user has a transit service to more than one site, presumably ipv4 because demanding ipv6 connectivity would create a circular requirement. In other words, ipv4 connectivity to multiple different sites appears to be a mandatory prerequisite in order to get an IPv6 assignment. Could someone in the RIPE NCC please confirm that this policy is being policed as stated? And if not, when can we expect all non-compliant assignments in the RIPE NCC service region to be revoked? Nick From mschmidt at ripe.net Wed Jun 22 17:18:08 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 22 Jun 2016 17:18:08 +0200 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <576A948D.7050306@foobar.org> Message-ID: Dear Nick, Thank you for raising this question. On 2016-06-22 15:37:17 CET, Nick Hilliard wrote: > > 2.9. End Site > > > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > > > - that service provider assigning address space to the End User > > - that service provider providing transit service for the End User to other sites > > - that service provider carrying the End User's traffic > > - that service provider advertising an aggregate prefix route that contains the End User's assignment > > Our reading of this is that each of these conditions is mandatory, i.e. > logical AND, because logical OR does not make sense. Term 2.9.2 states > that an ipv6 End Site is only an End Site if the service provider is > providing transit service for the End User to other sites. > The RIPE NCC's current understanding is that the points in the list in section 2.9 are seen as logical OR, with the first point "assigning address space" as the mandatory one. The other requirements are considered optional. For example, it seems reasonable for an LIR to provide address space to an End User, while the End User takes care themselves for routing and traffic management. If all points were mandatory, it would be extremely difficult for service providers to make IPv6 assignments. For example, only End Users with multiple sites would be entitled to receive an IPv6 assignment. This seems to be against the spirit of the IPv6 policy, which aims to allow networks to access IPv6. If the RIPE community disagrees with this understanding or feels that the current wording of section 2.9 is ambiguous, we invite a policy proposal that provides an adjusted End Site definition. I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From nick at foobar.org Wed Jun 22 21:31:52 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 22 Jun 2016 20:31:52 +0100 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: References: Message-ID: <576AE7A8.8080309@foobar.org> Marco Schmidt wrote: > If the RIPE community disagrees with this understanding or feels that > the current wording of section 2.9 is ambiguous, we invite a policy > proposal that provides an adjusted End Site definition. > > I hope this clarifies. Hi Marco, Thanks for clarifying. The alternative was awkward: http://i.imgur.com/J8vJwYR.jpg It looks like the interpretation and the wording are slightly at variance, albeit in favour of common sense, so the wording should probably be regarded as a policy bug which needs to be fixed. Nick From gert at space.net Wed Jun 22 22:14:23 2016 From: gert at space.net (Gert Doering) Date: Wed, 22 Jun 2016 22:14:23 +0200 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <576AE7A8.8080309@foobar.org> References: <576AE7A8.8080309@foobar.org> Message-ID: <20160622201423.GD79185@Space.Net> Hi, On Wed, Jun 22, 2016 at 08:31:52PM +0100, Nick Hilliard wrote: > It looks like the interpretation and the wording are slightly at > variance, albeit in favour of common sense, so the wording should > probably be regarded as a policy bug which needs to be fixed. It's very very old text which came from the very first version of the IPv6 policy (and nobody ever dared touch the definition of "site", because there's endless ratholing). But maybe now is the time to go where no man has gone this year, and propose an IPv6 related policy proposal - any volunteers? :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nick at foobar.org Wed Jun 22 22:40:27 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 22 Jun 2016 21:40:27 +0100 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <20160622201423.GD79185@Space.Net> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> Message-ID: <576AF7BB.1070800@foobar.org> Gert Doering wrote: > But maybe now is the time to go where no man has gone this year, and > propose an IPv6 related policy proposal - any volunteers? :-) I'll take a look at it. Nick From elvis at velea.eu Wed Jun 22 22:49:35 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 22 Jun 2016 23:49:35 +0300 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <576AF7BB.1070800@foobar.org> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> <576AF7BB.1070800@foobar.org> Message-ID: <-4579264028269443913@unknownmsgid> let's also chip in the possibility to make /64 assignments while redefining the definition. plenty that keep coming at the RIPE Meeting with all kind of cases where they want to use IPv6 (PI) but membership is not accesible. https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf /elvis Excuse the briefness of this mail, it was sent from a mobile device. > On Jun 22, 2016, at 23:40, Nick Hilliard wrote: > > Gert Doering wrote: >> But maybe now is the time to go where no man has gone this year, and >> propose an IPv6 related policy proposal - any volunteers? :-) > > I'll take a look at it. > > Nick > From kurtis at kurtis.pp.se Wed Jun 22 22:59:45 2016 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 22 Jun 2016 21:59:45 +0100 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <-4579264028269443913@unknownmsgid> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> <576AF7BB.1070800@foobar.org> <-4579264028269443913@unknownmsgid> Message-ID: <06E8ABD9-002A-4572-92DF-3B9BE6B5F7A6@kurtis.pp.se> > On 22 Jun 2016, at 21:49, Elvis Daniel Velea wrote: > > let's also chip in the possibility to make /64 assignments while > redefining the definition. plenty that keep coming at the RIPE Meeting > with all kind of cases where they want to use IPv6 (PI) but membership > is not accesible. > > https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf I think that is a orthogonally different problem though, and therefor are two different policy proposals. Best Regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 204 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kurtis at kurtis.pp.se Wed Jun 22 23:00:33 2016 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 22 Jun 2016 22:00:33 +0100 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <576AF7BB.1070800@foobar.org> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> <576AF7BB.1070800@foobar.org> Message-ID: <4F6E1DA4-18DA-4037-A421-A0EA43A82B2A@kurtis.pp.se> > On 22 Jun 2016, at 21:40, Nick Hilliard wrote: > > Gert Doering wrote: >> But maybe now is the time to go where no man has gone this year, and >> propose an IPv6 related policy proposal - any volunteers? :-) > > I'll take a look at it. I?d be happy to help Nick! /Feeling slightly guilty Best Regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 204 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rgori at wirem.net Thu Jun 23 07:43:39 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 23 Jun 2016 07:43:39 +0200 Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) In-Reply-To: <466580db-8b7b-b584-5397-6141fa980f78@wirem.net> References: <2AC4DD6E-25FC-4A72-AAA3-E91D7FC8CBC2@gmail.com> <5762C838.8080008@foobar.org> <4cfbe3aa-3837-c087-6137-edd982f1437d@velea.eu> <20160617074128.651f15f6@echo.ms.redpill-linpro.com> <466580db-8b7b-b584-5397-6141fa980f78@wirem.net> Message-ID: Hi Tore, Hi Elvis, I opened the ticket and I can confirm Tore clarification on that. Il 17/06/2016 08:09, Riccardo Gori ha scritto: > > Hi, > > > Il 17/06/2016 07:41, Tore Anderson ha scritto: >> * Elvis Daniel Velea >> >>> Additionally, it would still apply retroactively and people which since >>> 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after >>> the moment of the allocation) will end up with an allocation that is no >>> longer transferable. >> Elvis, while there are valid arguments against this proposal, this is >> not one of them. >> >> If it was, then we could essentially just disband the AP-GW as pretty >> much every single policy proposal ever made would "apply >> retroactively". Including the ones that made various forms of transfers >> possible in the first place; suddenly, many old non-transferable blocks >> were "retroactively" changed to become transferable. >> >> Note that the RIPE NCC SSA says: >> >>> Article 6 ? Compliance >>> >>> 6.1 The Member acknowledges applicability of, and adheres to, the RIPE >>> Policies and RIPE NCC procedural documents. The RIPE Policies and the >>> RIPE NCC procedural documents are publicly available from the RIPE NCC >>> Document Store. These documents, which may be revised and updated from >>> time to time, form an integral part of and apply fully to the RIPE NCC >>> Standard Service Agreement. >> A member who believes that transferability is an immutable and >> everlasting property of address space has not read what they've signed. >> >> If this proposal truly "applied retroactively" with regards to >> transfers, it would have had to annul all the transfers *made prior to >> its adoption* and stated the previously transferred address space was >> to be forcibly returned to its original holder or the NCC. Alrticle 6: This is the part of the agreement I like most 'cause confirms that community policies can change everything even on already allocated space. Only as fantasy examples: forbid transfer, return space or annual fees per held IP . I think the community alway choosed to go the esiest and fairier path. Elvis policy extended the current 24 months restriction to all PA space held by members and fixed the loophole of newly allocated that avoided the restriction. I consider it fair. >> >>> I do not like policy proposals that apply retroactively >> Uhm, so what about your 2015-01 proposal then? That one "applied >> retroactively" no less than this one. > I don't think 2015-01 apply retroactively. > I think allocation made before implementation of 2015-01 are free from > limitations. > I'll open a ticket about it and check and let you know. Confirmed Tore point. >> Anyway. I withdraw my earlier objection to 2016-03. I'm not at all >> convinced it's a good idea or worth the trouble, but if the community >> really wants to go down this road I won't try to block the path. >> Consider me neutral/abstaining. >> >> Tore >> > regards > Riccardo > -- > Ing. Riccardo Gori > e-mail:rgori at wirem.net > Mobile: +39 339 8925947 > Mobile: +34 602 009 437 > Profile:https://it.linkedin.com/in/riccardo-gori-74201943 > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying toinfo at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From gert at space.net Thu Jun 23 08:26:36 2016 From: gert at space.net (Gert Doering) Date: Thu, 23 Jun 2016 08:26:36 +0200 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <-4579264028269443913@unknownmsgid> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> <576AF7BB.1070800@foobar.org> <-4579264028269443913@unknownmsgid> Message-ID: <20160623062636.GE79185@Space.Net> Hi, On Wed, Jun 22, 2016 at 11:49:35PM +0300, Elvis Daniel Velea wrote: > let's also chip in the possibility to make /64 assignments while > redefining the definition. plenty that keep coming at the RIPE Meeting > with all kind of cases where they want to use IPv6 (PI) but membership > is not accesible. > > https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf No, IPv6 PI policy is a different topic and needs to be covered by a different proposal. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From elvis at velea.eu Thu Jun 23 11:48:22 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 23 Jun 2016 12:48:22 +0300 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <20160623062636.GE79185@Space.Net> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> <576AF7BB.1070800@foobar.org> <-4579264028269443913@unknownmsgid> <20160623062636.GE79185@Space.Net> Message-ID: <3771523012983434574@unknownmsgid> Hi, Excuse the briefness of this mail, it was sent from a mobile device. > On Jun 23, 2016, at 09:26, Gert Doering wrote: > > Hi, > >> On Wed, Jun 22, 2016 at 11:49:35PM +0300, Elvis Daniel Velea wrote: >> let's also chip in the possibility to make /64 assignments while >> redefining the definition. plenty that keep coming at the RIPE Meeting >> with all kind of cases where they want to use IPv6 (PI) but membership >> is not accesible. >> >> https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf > > No, IPv6 PI policy is a different topic and needs to be covered by a > different proposal. I only proposed this because in my mind it could have easily been solved when redefining the end site definition. /elvis > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From gert at space.net Thu Jun 23 11:49:35 2016 From: gert at space.net (Gert Doering) Date: Thu, 23 Jun 2016 11:49:35 +0200 Subject: [address-policy-wg] ipv6 assignments In-Reply-To: <3771523012983434574@unknownmsgid> References: <576AE7A8.8080309@foobar.org> <20160622201423.GD79185@Space.Net> <576AF7BB.1070800@foobar.org> <-4579264028269443913@unknownmsgid> <20160623062636.GE79185@Space.Net> <3771523012983434574@unknownmsgid> Message-ID: <20160623094935.GN79185@Space.Net> Hi, On Thu, Jun 23, 2016 at 12:48:22PM +0300, Elvis Daniel Velea wrote: > > No, IPv6 PI policy is a different topic and needs to be covered by a > > different proposal. > > I only proposed this because in my mind it could have easily been > solved when redefining the end site definition. No. This is a totally different part of the policy that disallows sub-assignments. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: