From emadaio at ripe.net Thu Oct 7 20:42:16 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 07 Oct 2010 20:42:16 +0200 Subject: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) Message-ID: <20101007184216.B2FD36A048@postboy.ripe.net> Dear Colleagues, Following the feedback received, the draft document for the proposal 2008-08 described is edited and published. The impact analysis that was conducted for this proposal has also been published You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2008-08.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2008-08-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 4 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Tue Oct 19 17:00:21 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 19 Oct 2010 17:00:21 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) Message-ID: <20101019150022.8FA4B6A005@postboy.ripe.net> Dear Colleagues, A proposed change to RIPE Document is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-07.html We encourage you to review this proposal and send your comments to before 17 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Thu Oct 21 13:36:38 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 21 Oct 2010 13:36:38 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Message-ID: <20101021113639.C265D6A008@postboy.ripe.net> Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Thu Oct 21 13:48:58 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 21 Oct 2010 12:48:58 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20101021113639.C265D6A008@postboy.ripe.net> References: <20101021113639.C265D6A008@postboy.ripe.net> Message-ID: On 21 October 2010 12:36, Emilio Madaio wrote: > ? ?http://ripe.net/ripe/policies/proposals/2006-05.html Either I'm going mental or doesn't the line: "Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10." make the proposal completely pointless J -- James Blessing 07989 039 476 From nick at inex.ie Thu Oct 21 14:01:58 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 21 Oct 2010 13:01:58 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> Message-ID: <4CC02BB6.1050708@inex.ie> On 21/10/2010 12:48, James Blessing wrote: > Either I'm going mental or doesn't the line: > > "Cumulatively, no more than 248 additional IPv4 addresses may be > assigned to any particular End User for the purposes outlined in > section 6.10." > > make the proposal completely pointless In what regard? Nick From james.blessing at despres.co.uk Thu Oct 21 14:05:49 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 21 Oct 2010 13:05:49 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <4CC02BB6.1050708@inex.ie> References: <20101021113639.C265D6A008@postboy.ripe.net> <4CC02BB6.1050708@inex.ie> Message-ID: On 21 October 2010 13:01, Nick Hilliard wrote: > On 21/10/2010 12:48, James Blessing wrote: >> >> Either I'm going mental or doesn't the line: >> >> "Cumulatively, no more than 248 additional IPv4 addresses may be >> assigned to any particular End User for the purposes outlined in >> section 6.10." >> >> make the proposal completely pointless > > In what regard? "The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24" Last time I looked /24 = 256 addresses Therefore you can't give a 'new' end user a /24 as they have no address space to return and 256 > 248. If it was 2048 then I could understand the logic... J -- James Blessing 07989 039 476 From gert at space.net Thu Oct 21 14:10:02 2010 From: gert at space.net (Gert Doering) Date: Thu, 21 Oct 2010 14:10:02 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> Message-ID: <20101021121002.GZ32268@Space.Net> Hi, On Thu, Oct 21, 2010 at 12:48:58PM +0100, James Blessing wrote: > On 21 October 2010 12:36, Emilio Madaio wrote: > > > ? ?http://ripe.net/ripe/policies/proposals/2006-05.html > > Either I'm going mental or doesn't the line: > > "Cumulatively, no more than 248 additional IPv4 addresses may be > assigned to any particular End User for the purposes outlined in > section 6.10." > > make the proposal completely pointless It's a "stop the floodgates" clause to try to prevent abuse of this proposal. For the intended purpose ("give people a /24 that do not have the necessary amount of machines and do not want to lie to the NCC") it should not pose a problem - you have 3 machines plus a router, you need 4 addresses = /29. Add 248 addresses, reach /24. The emphasis is "additional" = "in addition to the addresses the requester can justify". The stopgap function is: if the same entity comes back three months later and asks for another /29-to-be-extended-to-a-/24, they won't get it. "Fill your existing /24 first." If that's not sufficiently clear, we might need to reword. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From james.blessing at despres.co.uk Thu Oct 21 14:23:51 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 21 Oct 2010 13:23:51 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20101021121002.GZ32268@Space.Net> References: <20101021113639.C265D6A008@postboy.ripe.net> <20101021121002.GZ32268@Space.Net> Message-ID: On 21 October 2010 13:10, Gert Doering wrote: > Hi, > > On Thu, Oct 21, 2010 at 12:48:58PM +0100, James Blessing wrote: >> On 21 October 2010 12:36, Emilio Madaio wrote: >> >> > ? ?http://ripe.net/ripe/policies/proposals/2006-05.html >> >> Either I'm going mental or doesn't the line: >> >> "Cumulatively, no more than 248 additional IPv4 addresses may be >> assigned to any particular End User for the purposes outlined in >> section 6.10." >> >> make the proposal completely pointless > > It's a "stop the floodgates" clause to try to prevent abuse of this > proposal. > > For the intended purpose ("give people a /24 that do not have the > necessary amount of machines and do not want to lie to the NCC") it > should not pose a problem - you have 3 machines plus a router, you > need 4 addresses = /29. ?Add 248 addresses, reach /24. > > The emphasis is "additional" = "in addition to the addresses the > requester can justify". > > The stopgap function is: if the same entity comes back three months > later and asks for another /29-to-be-extended-to-a-/24, they won't > get it. ?"Fill your existing /24 first." > > If that's not sufficiently clear, we might need to reword. Okay no I understand the intent better... How about the following situation: I have 256 machines and 1 router, that's 257 addresses required. Under the new wording I can't then have a /23 because I have a requirement for 253 more addresses to make it up... (I admit its unlikely but a potential situation that needs to be resolved) There is also a potential issue where you have a requirement to subnet multiple locations where you are using a number less than the full number of addresses (eg 33 sites with /29 but only 5 address being used at each site to round up to a /23 you need more that 248 addresses...) "Further assignments under section 6.10 will not be permitted for an End User until all existing assignments have reached 80% utilisation" J -- James Blessing 07989 039 476 From slz at baycix.de Thu Oct 21 14:13:38 2010 From: slz at baycix.de (Sascha Lenz) Date: Thu, 21 Oct 2010 14:13:38 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> <4CC02BB6.1050708@inex.ie> Message-ID: Hi, Am 21.10.2010 um 14:05 schrieb James Blessing: > On 21 October 2010 13:01, Nick Hilliard wrote: >> On 21/10/2010 12:48, James Blessing wrote: >>> >>> Either I'm going mental or doesn't the line: >>> >>> "Cumulatively, no more than 248 additional IPv4 addresses may be >>> assigned to any particular End User for the purposes outlined in >>> section 6.10." >>> >>> make the proposal completely pointless >> >> In what regard? > > "The RIPE NCC will assign additional IPv4 addresses to an End User in > order to make the assignment size a multiple of a /24" > > Last time I looked /24 = 256 addresses > > Therefore you can't give a 'new' end user a /24 as they have no > address space to return and 256 > 248. > > If it was 2048 then I could understand the logic... You request a /30 and you don't get a /24. You request a /29 and get a /24. ..and so on. Just no more than 248 "additional" IPs to fill the request so it matches /24 boundaries. I think that's how it's meant(?) though it does not make SO much sense. Should be clearer in wording. But i'm still of the opinion that no new IPv4 policy makes any sense anymore anyways. Do we even have continuous /24s anymore in a few months? :-) Anyways, i support the proposal in general since it wastes remaining IPv4 space, i like that. -- bye -slz From sander at steffann.nl Thu Oct 21 14:35:54 2010 From: sander at steffann.nl (Sander Steffann) Date: Thu, 21 Oct 2010 14:35:54 +0200 Subject: [address-policy-wg] Proposal 2010-02 Message-ID: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> Hello working group, The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward. I think that it is important that we, as a working group, decide about what we are going to do with the last IPv4 addresses. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-02.html So: please comment on this proposal. Thank you, Sander Steffann APWG co-chair From kpn-ip-office at kpn.com Thu Oct 21 15:38:53 2010 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Thu, 21 Oct 2010 15:38:53 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20101021113639.C265D6A008@postboy.ripe.net> References: <20101021113639.C265D6A008@postboy.ripe.net> Message-ID: I'm in favour of this policy Maybe we should change the sentence "Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10." Into something like "Cumulatively, an PI assignment will not reach beyond the next /24 boundary from the motivated need. This might thus result in an PI assignment of more than one subnet of which each subnet is a minimum of a /24". (p.e. a /23, /24 when a need of ~ 520 IP-addresses is motivated). With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office +31 70 45 13398 kpn-ip-office at kpn.com -----Oorspronkelijk bericht----- Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Emilio Madaio Verzonden: donderdag 21 oktober 2010 13:37 Aan: policy-announce at ripe.net CC: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From tore.anderson at redpill-linpro.com Thu Oct 21 15:46:37 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 21 Oct 2010 15:46:37 +0200 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> Message-ID: <4CC0443D.1040401@redpill-linpro.com> * Sander Steffann > The review phase of proposal 2010-02 has ended. During this review > phase no comments were received. Without any feedback this proposal > can't move forward. I think that it is important that we, as a > working group, decide about what we are going to do with the last > IPv4 addresses. ?He who remains silent, agrees?, as we say here in Norway... Anyway. I feel version 3 solves the objections I had against version 2, so I support the proposal. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From scottleibrand at gmail.com Thu Oct 21 15:50:25 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Oct 2010 09:50:25 -0400 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> Message-ID: I don't have an opinion as to whether rationing the last /8 is a good idea, but I do have a comment/question: It seems that section 2 is a no-op, because the space is not really reserved if it's just returned to the pool when the /8 runs out... Is that the intent? Scott On Oct 21, 2010, at 8:35 AM, Sander Steffann wrote: > Hello working group, > > The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward. I think that it is important that we, as a working group, decide about what we are going to do with the last IPv4 addresses. > > You can find the full proposal at: > > http://ripe.net/ripe/policies/proposals/2010-02.html > > So: please comment on this proposal. > > Thank you, > Sander Steffann > APWG co-chair > From sander at steffann.nl Thu Oct 21 15:58:49 2010 From: sander at steffann.nl (Sander Steffann) Date: Thu, 21 Oct 2010 15:58:49 +0200 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> Message-ID: <5EC2AABD-3651-4462-B1B9-764AE35AD3AB@steffann.nl> Hi Scott, > It seems that section 2 is a no-op, because the space is not really reserved if it's just returned to the pool when the /8 runs out... Is that the intent? It makes sure that there is one clearly defined /16 block reserved. Otherwise we might end up with unused fragments all over the whole /8. I don't know if that was the intent of the authors, but it might be useful and it doesn't seem to have any negative side effects. - Sander From scottleibrand at gmail.com Thu Oct 21 16:07:27 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Oct 2010 10:07:27 -0400 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <5EC2AABD-3651-4462-B1B9-764AE35AD3AB@steffann.nl> References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> <5EC2AABD-3651-4462-B1B9-764AE35AD3AB@steffann.nl> Message-ID: <75F8F24B-C814-4507-B3A4-B5DF0FE26FF3@gmail.com> On Oct 21, 2010, at 9:58 AM, Sander Steffann wrote: > Hi Scott, > >> It seems that section 2 is a no-op, because the space is not really reserved if it's just returned to the pool when the /8 runs out... Is that the intent? > > It makes sure that there is one clearly defined /16 block reserved. Otherwise we might end up with unused fragments all over the whole /8. I don't know if that was the intent of the authors, but it might be useful and it doesn't seem to have any negative side effects. Ok. That seems more like implementation detail than policy, but I agree it doesn't hurt. Thanks, Scott From andy at nosignal.org Thu Oct 21 16:18:35 2010 From: andy at nosignal.org (Andy Davidson) Date: Thu, 21 Oct 2010 15:18:35 +0100 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <20101019150022.8FA4B6A005@postboy.ripe.net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> Message-ID: <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> Hi, [ Copied to EIX-wg, since this policy affects assignments to Internet Exchange Points specifically ] On 19 Oct 2010, at 16:00, Emilio Madaio wrote: > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2010-07.html > > > We encourage you to review this proposal and send your comments to > before 17 November 2010. I think that 'open' in the document right now, means 'we are open about the policy for joining', not 'the exchange is open to anyone to join'. Is this the feeling ? If so, the policy should read "there must be a clear and documented policy for others to join", rather than a removal of the requirement for there to be a policy ? Now that IPv6 PI is available to all networks, in addition to Internet Exchange Points, perhaps we do not need to have a special policy for IXPs at all, but I see possible future value in IXPs sitting inside 2001:7f8/32, so I think it should remain. Best wishes, Andy Davidson (Hats: EIX-wg co-chair, uk.dev, LONAP, IXLeeds) From richih.mailinglist at gmail.com Thu Oct 21 23:48:07 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 21 Oct 2010 23:48:07 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20101021121002.GZ32268@Space.Net> References: <20101021113639.C265D6A008@postboy.ripe.net> <20101021121002.GZ32268@Space.Net> Message-ID: On Thu, Oct 21, 2010 at 14:10, Gert Doering wrote: > If that's not sufficiently clear, we might need to reword. The wording is clear once you know the intended meaning. Yet, after reading it twice, I was not certain that I understood the intent and all consequences of this rule before I read your explanantion. IMO, the main problem is that "additional" is ambivalent even though it's used in the first sentence, as well. Thus, I would suggest: The RIPE NCC will assign additional IPv4 addresses to an End User in order to pad the assignment size to a multiple of a /24 if an End User demonstrates: [...] Cumulatively, no more than 248 padding IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10. Richard From david at sargasso.net Fri Oct 22 02:24:55 2010 From: david at sargasso.net (David Croft) Date: Fri, 22 Oct 2010 02:24:55 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> <20101021121002.GZ32268@Space.Net> Message-ID: On 21 October 2010 14:23, James Blessing wrote: > I have 256 machines and 1 router, that's 257 addresses required. Under > the new wording I can't then have a /23 because I have a requirement > for 253 more addresses to make it up... Under that circumstance you'd get a /23 under existing policy. The intent seems to be that if you'd normally be assigned a /29-/25, it's rounded up to a /24. The limit of 248 addresses presumably being to stop abuse, by enabling the NCC to assess this 'slack' across multiple allocations. David From james.blessing at despres.co.uk Fri Oct 22 09:58:52 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 22 Oct 2010 08:58:52 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> <20101021121002.GZ32268@Space.Net> Message-ID: On 22 October 2010 01:24, David Croft wrote: > On 21 October 2010 14:23, James Blessing wrote: >> I have 256 machines and 1 router, that's 257 addresses required. Under >> the new wording I can't then have a /23 because I have a requirement >> for 253 more addresses to make it up... > > Under that circumstance you'd get a /23 under existing policy. Really? Not a /24 and a /29? > The intent seems to be that if you'd normally be assigned a /29-/25, > it's rounded up to a /24. The limit of 248 addresses presumably being > to stop abuse, by enabling the NCC to assess this 'slack' across > multiple allocations. Oh, I agree with what the policy is trying to do. My problem is the wording just needs a little tweak (see my previous suggestion) J -- James Blessing 07989 039 476 From gert at space.net Mon Oct 25 16:16:25 2010 From: gert at space.net (Gert Doering) Date: Mon, 25 Oct 2010 16:16:25 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> Message-ID: <20101025141625.GQ32268@Space.Net> Hi Andy, thanks for forwarding to EIX. We'll discuss this proposal (and the wider topic "how do we want the policy to be?") in the Wednesday APWG time slot in Rome (Thursday APWG time slot conflicts with EIX, which would be non-helpful). Since both of the listed authors of the current RIPE document regarding IPv6 assignments to IXPs are reading this list :-) - Timothy and Leo, could you briefly comment how you remember the intent of the policy? thanks, Gert Doering, APWG chair On Thu, Oct 21, 2010 at 03:18:35PM +0100, Andy Davidson wrote: > > Hi, > > [ Copied to EIX-wg, since this policy affects assignments to Internet Exchange Points specifically ] > > On 19 Oct 2010, at 16:00, Emilio Madaio wrote: > > > You can find the full proposal at: > > > > http://www.ripe.net/ripe/policies/proposals/2010-07.html > > > > > > We encourage you to review this proposal and send your comments to > > before 17 November 2010. > > I think that 'open' in the document right now, means 'we are open about the policy for joining', not 'the exchange is open to anyone to join'. Is this the feeling ? > > If so, the policy should read "there must be a clear and documented policy for others to join", rather than a removal of the requirement for there to be a policy ? > > > Now that IPv6 PI is available to all networks, in addition to Internet Exchange Points, perhaps we do not need to have a special policy for IXPs at all, but I see possible future value in IXPs sitting inside 2001:7f8/32, so I think it should remain. > > > Best wishes, > Andy Davidson > (Hats: EIX-wg co-chair, uk.dev, LONAP, IXLeeds) -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From leo.vegoda at icann.org Mon Oct 25 17:00:31 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 25 Oct 2010 08:00:31 -0700 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <20101025141625.GQ32268@Space.Net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> Message-ID: <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> On Oct 25, 2010, at 7:16 AM, Gert Doering wrote: [?] > Since both of the listed authors of the current RIPE document regarding > IPv6 assignments to IXPs are reading this list :-) - Timothy and Leo, > could you briefly comment how you remember the intent of the policy? My memory of the intention was that the exchange should be open to new members who could meet a set of technical requirements documented in a corporate policy. The kind of requirements we anticipated were things like: - 24/7 NOC - Assigned a unique AS Number - Assigned or allocated address space - Routing policy published in an IRR database It was not intended that the requirements be onerous. The goal was to make sure that membership was available to network operators in general rather than being available to an elite clique. HTH, Leo Vegoda From gert at space.net Mon Oct 25 17:52:34 2010 From: gert at space.net (Gert Doering) Date: Mon, 25 Oct 2010 17:52:34 +0200 Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <1PAPEC-0002KQ-MW@ncuk.net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> <1PAPEC-0002KQ-MW@ncuk.net> Message-ID: <20101025155234.GT32268@Space.Net> Hi, On Mon, Oct 25, 2010 at 04:44:52PM +0100, Sebastien Lahtinen wrote: > Why should an exchange run a 24x7 NOC or not be entitled to restrict who > can peer over it? Well, from what I recall at that time, people were afraid that this would become a "cheap way to get IPv6 PI" (which wasn't otherwise available yet) - just find two friends with an AS number, declare yourself an IXP, and get your prefix. Nowadays, IPv6 PI exists, and the IXP landscape has changed as well - which is why I want to re-open the discussion "how should the IPv6 IXP policy look like?" at the next RIPE meeting's address policy WG meeting. Input from the IXP folks is more than welcome, of course. You help us define "what is an IXP?", we make a policy that works for you... :-) Gert Doering -- AWPG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From andy at nosignal.org Mon Oct 25 18:08:36 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 25 Oct 2010 17:08:36 +0100 Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <20101025155234.GT32268@Space.Net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> <1PAPEC-0002KQ-MW@ncuk.net> <20101025155234.GT32268@Space.Net> Message-ID: <8ED13DE2-8B59-4817-9B43-7355A48C8568@nosignal.org> On 25 Oct 2010, at 16:52, Gert Doering wrote: > Input from the IXP folks is more than welcome, of course. You help us define "what is an IXP?", we make a policy that works for you... :-) I am in favour of light touch policy - let each ixp have some simple/relevant rules on connection (which will always have to be specific to their own market, region, culture), write the rules down, and follow them. If you have a policy which is enforced equally, then for the purpose of this policy, it is 'open' - because the ixp is open about the policy. In terms of the policy, my current preference is 'there must be a clear and documented policy'. My second preference is the wording suggested by Emilio. My last preference is the current wording. -- Best wishes Andy Davidson eix-wg co-chair, personal capacity. From md at ncuk.net Mon Oct 25 17:44:52 2010 From: md at ncuk.net (Sebastien Lahtinen) Date: Mon, 25 Oct 2010 16:44:52 +0100 (BST) Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> Message-ID: <1PAPEC-0002KQ-MW@ncuk.net> On Mon, 25 Oct 2010, Leo Vegoda wrote: > The kind of requirements we anticipated were things like: > > - 24/7 NOC > - Assigned a unique AS Number > - Assigned or allocated address space > - Routing policy published in an IRR database > > It was not intended that the requirements be onerous. The goal was to > make sure that membership was available to network operators in general > rather than being available to an elite clique. I haven't been involved in this discussion, but just to bring an outside perspective into it.. Why should an exchange run a 24x7 NOC or not be entitled to restrict who can peer over it? I realise most European exchanges are mutual (and I hope it stays that way), but we shouldn't be making it more difficult for someone to either start an exchange nor restrict their ability to run it. Having IRR registered routes is far more important than how a business wants to run its internal affairs. Regards, Sebastien. (for transparency: I am a director of a mutual exchange which already has an IPv6 block; but these views are strictly my own, etc.) From leo.vegoda at icann.org Mon Oct 25 20:25:46 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 25 Oct 2010 11:25:46 -0700 Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <1PAPEC-0002KQ-MW@ncuk.net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> <1PAPEC-0002KQ-MW@ncuk.net> Message-ID: Hi Seb, On 25 Oct 2010, at 8:44, Sebastien Lahtinen wrote: > On Mon, 25 Oct 2010, Leo Vegoda wrote: > >> The kind of requirements we anticipated were things like: >> >> - 24/7 NOC >> - Assigned a unique AS Number >> - Assigned or allocated address space >> - Routing policy published in an IRR database >> >> It was not intended that the requirements be onerous. The goal was to >> make sure that membership was available to network operators in general >> rather than being available to an elite clique. > > I haven't been involved in this discussion, but just to bring an outside > perspective into it.. > > Why should an exchange run a 24x7 NOC or not be entitled to restrict who > can peer over it? I realise most European exchanges are mutual (and I hope > it stays that way), but we shouldn't be making it more difficult for > someone to either start an exchange nor restrict their ability to run it. > Having IRR registered routes is far more important than how a business > wants to run its internal affairs. I think I may not have been clear. The requirements I listed above (as examples only) were the kind of thing I expected exchanges to require of prospective members. Of course, an exchange might decide that 24/7 NOC isn't sufficiently important to be a requirement but as long as its policy didn't impose it on some (potential) members but not others that would be fine. The language was written at a time where there was no policy allowing IPv6 PI space and there was a concern that IXP prefixes might be seen as an alternative. But now there is an IPv6 PI policy it makes sense to revisit the language and make it less onerous if it is causing problems for groups starting new IXPs. I've read the proposed change and it seems reasonable to me but I'm certainly not an IXP expert. Regards, Leo From Henk.Steenman at ams-ix.net Tue Oct 26 11:33:54 2010 From: Henk.Steenman at ams-ix.net (Henk Steenman) Date: Tue, 26 Oct 2010 11:33:54 +0200 Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> <1PAPEC-0002KQ-MW@ncuk.net> Message-ID: <6AD2C273-4E0A-49A3-9DC9-0F84D77D6F95@ams-ix.net> On Oct 25, 2010, at 8:25 PM, Leo Vegoda wrote: > Hi Seb, > > On 25 Oct 2010, at 8:44, Sebastien Lahtinen wrote: >> On Mon, 25 Oct 2010, Leo Vegoda wrote: >> >>> The kind of requirements we anticipated were things like: >>> >>> - 24/7 NOC >>> - Assigned a unique AS Number >>> - Assigned or allocated address space >>> - Routing policy published in an IRR database >>> >>> It was not intended that the requirements be onerous. The goal was to >>> make sure that membership was available to network operators in general >>> rather than being available to an elite clique. >> >> I haven't been involved in this discussion, but just to bring an outside >> perspective into it.. >> >> Why should an exchange run a 24x7 NOC or not be entitled to restrict who >> can peer over it? I realise most European exchanges are mutual (and I hope >> it stays that way), but we shouldn't be making it more difficult for >> someone to either start an exchange nor restrict their ability to run it. >> Having IRR registered routes is far more important than how a business >> wants to run its internal affairs. > > I think I may not have been clear. The requirements I listed above (as examples only) were the kind of thing I expected exchanges to require of prospective members. Of course, an exchange might decide that 24/7 NOC isn't sufficiently important to be a requirement but as long as its policy didn't impose it on some (potential) members but not others that would be fine. > > The language was written at a time where there was no policy allowing IPv6 PI space and there was a concern that IXP prefixes might be seen as an alternative. But now there is an IPv6 PI policy it makes sense to revisit the language and make it less onerous if it is causing problems for groups starting new IXPs. > > I've read the proposed change and it seems reasonable to me but I'm certainly not an IXP expert. The definition of an Exchange goes back to a discussion in June 2001. http://www.ripe.net/ripe/maillists/archives/eix-wg/2001/msg00029.html The intention of the "clear and open" was to make sure that the rules to join the exchange were there for everyone, whatever the rules were. Wether you needed an AS number or the existing membership had to vote for new members to join or whatever. As long as this was written down somewhere for everyone to take notice of. As far as I am concerned the definition is clear and should not have been an obstacle for denying IPv6 address space to an Exchange. However if leaving out the word "open" as proposed in the change makes applying the policy less sensitive to the arbitrary ruling of a hostmaster it makes sense to do so. - Henk Steenman From timothy at ripe.net Tue Oct 26 11:40:57 2010 From: timothy at ripe.net (Timothy Lowe) Date: Tue, 26 Oct 2010 11:40:57 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> Message-ID: Hello, Yes as I recall the intention of that point was that the IXP be open to all who wished to join. The main policy discussion revolved around the definition of an exchange point and then that the IXP be open to any who wish to join. The policy has also been interpreted in this way in the past as far as I am aware. As Leo mentioned IPv6 PI was not supported then so the goal was to ensure only IXPs would receive the address block and then only for IXP purposes. Best Regards, Timothy Lowe RIPE NCC Staff On Oct 25, 2010, at 5:00 PM, Leo Vegoda wrote: > On Oct 25, 2010, at 7:16 AM, Gert Doering wrote: > > [?] > >> Since both of the listed authors of the current RIPE document >> regarding >> IPv6 assignments to IXPs are reading this list :-) - Timothy and Leo, >> could you briefly comment how you remember the intent of the policy? > > My memory of the intention was that the exchange should be open to > new members who could meet a set of technical requirements > documented in a corporate policy. The kind of requirements we > anticipated were things like: > > - 24/7 NOC > - Assigned a unique AS Number > - Assigned or allocated address space > - Routing policy published in an IRR database > > It was not intended that the requirements be onerous. The goal was > to make sure that membership was available to network operators in > general rather than being available to an elite clique. > > HTH, > > Leo Vegoda From Henk.Steenman at ams-ix.net Tue Oct 26 13:14:43 2010 From: Henk.Steenman at ams-ix.net (Henk Steenman) Date: Tue, 26 Oct 2010 13:14:43 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> Message-ID: <94900BC7-2CE7-4FD1-9380-585A4A9268D2@ams-ix.net> On Oct 26, 2010, at 11:40 AM, Timothy Lowe wrote: > Hello, > > Yes as I recall the intention of that point was that the IXP be open to all who wished to join. > The main policy discussion revolved around the definition of an exchange point > and then that the IXP be open to any who wish to join. An Exchange point is never open to all who wish to join. There are always some kind of restrictions, even if limited to being a registered company or having an AS. - Henk Steenman > > The policy has also been interpreted in this way in the past as far as I am aware. > As Leo mentioned IPv6 PI was not supported then so the goal was to ensure only IXPs > would receive the address block and then only for IXP purposes. > > Best Regards, > Timothy Lowe > RIPE NCC Staff > > > > On Oct 25, 2010, at 5:00 PM, Leo Vegoda wrote: > >> On Oct 25, 2010, at 7:16 AM, Gert Doering wrote: >> >> [?] >> >>> Since both of the listed authors of the current RIPE document regarding >>> IPv6 assignments to IXPs are reading this list :-) - Timothy and Leo, >>> could you briefly comment how you remember the intent of the policy? >> >> My memory of the intention was that the exchange should be open to new members who could meet a set of technical requirements documented in a corporate policy. The kind of requirements we anticipated were things like: >> >> - 24/7 NOC >> - Assigned a unique AS Number >> - Assigned or allocated address space >> - Routing policy published in an IRR database >> >> It was not intended that the requirements be onerous. The goal was to make sure that membership was available to network operators in general rather than being available to an elite clique. >> >> HTH, >> >> Leo Vegoda > From Henk.Steenman at ams-ix.net Tue Oct 26 13:21:00 2010 From: Henk.Steenman at ams-ix.net (Henk Steenman) Date: Tue, 26 Oct 2010 13:21:00 +0200 Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> <1PAPEC-0002KQ-MW@ncuk.net> Message-ID: On Oct 25, 2010, at 8:25 PM, Leo Vegoda wrote: > Hi Seb, > > On 25 Oct 2010, at 8:44, Sebastien Lahtinen wrote: >> On Mon, 25 Oct 2010, Leo Vegoda wrote: >> >>> The kind of requirements we anticipated were things like: >>> >>> - 24/7 NOC >>> - Assigned a unique AS Number >>> - Assigned or allocated address space >>> - Routing policy published in an IRR database >>> >>> It was not intended that the requirements be onerous. The goal was to >>> make sure that membership was available to network operators in general >>> rather than being available to an elite clique. >> >> I haven't been involved in this discussion, but just to bring an outside >> perspective into it.. >> >> Why should an exchange run a 24x7 NOC or not be entitled to restrict who >> can peer over it? I realise most European exchanges are mutual (and I hope >> it stays that way), but we shouldn't be making it more difficult for >> someone to either start an exchange nor restrict their ability to run it. >> Having IRR registered routes is far more important than how a business >> wants to run its internal affairs. > > I think I may not have been clear. The requirements I listed above (as examples only) were the kind of thing I expected exchanges to require of prospective members. Of course, an exchange might decide that 24/7 NOC isn't sufficiently important to be a requirement but as long as its policy didn't impose it on some (potential) members but not others that would be fine. > > The language was written at a time where there was no policy allowing IPv6 PI space and there was a concern that IXP prefixes might be seen as an alternative. But now there is an IPv6 PI policy it makes sense to revisit the language and make it less onerous if it is causing problems for groups starting new IXPs. > > I've read the proposed change and it seems reasonable to me but I'm certainly not an IXP expert. The definition of an Exchange goes back to a discussion in June 2001. http://www.ripe.net/ripe/maillists/archives/eix-wg/2001/msg00029.html The intention of the "clear and open" was to make sure that the rules to join the exchange were there for everyone, whatever the rules were. Wether you needed an AS number or the existing membership had to vote for new members to join or whatever. As long as this was written down somewhere for everyone to take notice of. As far as I am concerned the definition is clear and should not have been an obstacle for denying IPv6 address space to an Exchange. However if leaving out the word "open" as proposed in the change makes applying the policy less sensitive to the arbitrary ruling of a hostmaster it makes sense to do so. - Henk Steenman From emadaio at ripe.net Tue Oct 26 16:23:35 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 26 Oct 2010 16:23:35 +0200 Subject: [address-policy-wg] 2010-04 Proposal Accepted (80% Rule Ambiguity Cleanup) Message-ID: <20101026142335.F31D36A008@postboy.ripe.net> Dear Colleagues, Consensus has been reached and the proposal for a change to the RIPE Document ripe-492, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-04.html The updated RIPE Document is ripe-498 and is available at: http://ripe.net/ripe/docs/ripe-498.html Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From nick at inex.ie Wed Oct 27 02:01:09 2010 From: nick at inex.ie (Nick Hilliard) Date: Wed, 27 Oct 2010 01:01:09 +0100 Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> Message-ID: <4CC76BC5.4020302@inex.ie> On 21/10/2010 15:18, Andy Davidson wrote: > Now that IPv6 PI is available to all networks, in addition to Internet > Exchange Points, perhaps we do not need to have a special policy for > IXPs at all, but I see possible future value in IXPs sitting inside > 2001:7f8/32, so I think it should remain. On the question at hand, the RIPE NCC's interpretation of the word "open" has caused a lot of trouble. It would probably be better to remove it rather than keep it. >From the point of view of keeping the rules short and sweet, I would see value in scrapping both RIPE-233 (ipv6 for root servers) and RIPE-451 (ipv6 for IXPs), and take their essence into the "IPv6 Address Allocation and Assignment Policy" policy document. It would certainly be possible to note that the RIPE NCC may assign IXPs space from certain netblocks. But in the general case, duplication of policy documents is not useful. Nick From nick at inex.ie Wed Oct 27 02:39:00 2010 From: nick at inex.ie (Nick Hilliard) Date: Wed, 27 Oct 2010 01:39:00 +0100 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> Message-ID: <4CC774A4.3030701@inex.ie> On 21/10/2010 13:35, Sander Steffann wrote: > The review phase of proposal 2010-02 has ended. During this review phase > no comments were received. Without any feedback this proposal can't move > forward. I suspect people aren't commenting because - like me - they don't really understand the consequences of implementing a proposal like this. The obvious impact is that post-depletion, there will be the ability for up to 16384 LIRs to receive a /22 before the /8 runs out. There are currently ~7540 open LIRs, as far as I can make out. This means that potentially up to 8800 new LIRs will be able to open, post depletion. This is good from the following points of view: 1. it removes a barrier to new entry to business. Apart from the direct reasons why this is important, it will also sooth regulators who view barriers to market entry as matters worth investigating. 2. it will create a de-facto stabilising influence on any IPv4 address market which may spring up. I.e. 4 x /24 will cost ?1300 + (?2000/4), assuming a 4 year write-down. Therefore there will be a tendency to fix the lower bound of the price of a /24 to ?1800/4 = ?450 per annum. While relatively high, there is value is market stabilisation. However, the proposal will also turn small quantities of address space into marketable assets, and shelf LIRs are likely to pop up all over the place with the sole intention of garnering ipv4 address space for resale or rental. This is bad for the following reasons: 1. rapid new LIR creation will cause strain on RIPE NCC resources, leading to medium term organisational strain. 2. the RIPE NCC is very likely to put in much more stringent checks to ensure that new LIRs are genuinely in the business of service provisioning. This will be a pain and will cause more paperwork / mouth-frothing / bureaucracy. I am sure that retrospect would point out many other advantages and disadvantages. My own opinion is that the advantages are quite significant. The disadvantages certainly exist, but are less significant. Therefore I support the proposal. There is no right answer for a proposal like this. Contention for scarce resources is fundamentally contentious. We just have to live with that. If it turns out that significant implementation problems arise, the proposal can be changed. Nothing is set in stone. Nick From nick at inex.ie Wed Oct 27 02:55:17 2010 From: nick at inex.ie (Nick Hilliard) Date: Wed, 27 Oct 2010 01:55:17 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> Message-ID: <4CC77875.2010507@inex.ie> On 21/10/2010 14:38, kpn-ip-office at kpn.com wrote: > I'm in favour of this policy > > Maybe we should change the sentence > > "Cumulatively, no more than 248 additional IPv4 addresses may be > assigned to any particular End User for the purposes outlined in section > 6.10." > > Into something like > > "Cumulatively, an PI assignment will not reach beyond the next /24 > boundary from the motivated need. This might thus result in an PI > assignment of more than one subnet of which each subnet is a minimum of > a /24". > > (p.e. a /23, /24 when a need of ~ 520 IP-addresses is motivated). I agree that the wording needs a little work to make the intent clearer, but I'm not convinced that this particular suggestion is necessarily better. Nick From nick at inex.ie Wed Oct 27 03:25:17 2010 From: nick at inex.ie (Nick Hilliard) Date: Wed, 27 Oct 2010 02:25:17 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20101021113639.C265D6A008@postboy.ripe.net> <20101021121002.GZ32268@Space.Net> Message-ID: <4CC77F7D.6080305@inex.ie> On 21/10/2010 13:23, James Blessing wrote: > How about the following situation: > > I have 256 machines and 1 router, that's 257 addresses required. Under > the new wording I can't then have a /23 because I have a requirement > for 253 more addresses to make it up... > > (I admit its unlikely but a potential situation that needs to be resolved) So, can I take it then that you broadly agree with the principle of the policy, but it's just the details which you believe need to be worked on? There are edge cases which cause this policy to creak, and it's not hard to construct "I Cannot Be Played on Record Player X" situations. The policy proposal is not intended to fix 100% of all situations. Instead it is intended to deal with ninety something percent of them. If a policy were created to deal with all potential situations, it would get messy. I did put some thought into this, but retreated from the idea. Incidentally, the reason that 248 was chosen as a cut-off point was that /29 is realistically the smallest chunk of address space that you would want to run a multihomed site on. /29 gives you space for your router interface + two endpoint addresses on a LAN. I already hear you saying "But, but, BUT! You _could_ run a multihomed site on 1, 2 or 4 addresses". Of course you could. But this is not an exercise in playing number games. The intent of /29 is to deal with the smallest realistic network that an end-user is actually going to deploy when they actually go multihomed (1 router + 2 hosts). We could argue endlessly about 248 vs 252 vs 254. But in practice, the exact choice of number is going to make very little difference. > There is also a potential issue where you have a requirement to subnet > multiple locations where you are using a number less than the full > number of addresses (eg 33 sites with /29 but only 5 address being > used at each site to round up to a /23 you need more that 248 > addresses...) This is already a problem with the existing assignment rules. I don't plan to fix this :-) > "Further assignments under section 6.10 will not be permitted for an > End User until all existing assignments have reached 80% utilisation" I don't think it would help to complicate the proposal much more. "Le mieux est l'ennemi du bien". Nick From md at ncuk.net Tue Oct 26 22:06:53 2010 From: md at ncuk.net (Sebastien Lahtinen) Date: Tue, 26 Oct 2010 21:06:53 +0100 (BST) Subject: [eix-wg] Re: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101025141625.GQ32268@Space.Net> <1A1F738F-D138-44A0-A64B-ACC509FCB50C@icann.org> <1PAPEC-0002KQ-MW@ncuk.net> Message-ID: <1PApnJ-0005qU-Tu@ncuk.net> On Mon, 25 Oct 2010, Leo Vegoda wrote: >>> - 24/7 NOC >>> - Assigned a unique AS Number >>> - Assigned or allocated address space >>> - Routing policy published in an IRR database > I think I may not have been clear. The requirements I listed above (as > examples only) were the kind of thing I expected exchanges to require of > prospective members. Ah, thanks.. That puts it in somewhat of a different perspective. I'll climb back into my hole :) seb From niels=apwg at bakker.net Wed Oct 27 13:15:38 2010 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Wed, 27 Oct 2010 13:15:38 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> Message-ID: <20101027111538.GD45727@burnout.tpb.net> * andy at nosignal.org (Andy Davidson) [Thu 21 Oct 2010, 16:40 CEST]: >On 19 Oct 2010, at 16:00, Emilio Madaio wrote: >> http://www.ripe.net/ripe/policies/proposals/2010-07.html [..] > >Now that IPv6 PI is available to all networks, in addition to >Internet Exchange Points, perhaps we do not need to have a special >policy for IXPs at all, but I see possible future value in IXPs >sitting inside 2001:7f8/32, so I think it should remain. IPv6 PI won't work for IXPs as numbers need to be handed out to connected parties, which is not allowed for PIv6 (in contrast to PIv4 under INFRA-AW). -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From jim at rfc1035.com Wed Oct 27 13:39:39 2010 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Oct 2010 12:39:39 +0100 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <4CC774A4.3030701@inex.ie> References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> <4CC774A4.3030701@inex.ie> Message-ID: <5A620D64-FA5B-4707-AC88-A32290CD61D7@rfc1035.com> On 27 Oct 2010, at 01:39, Nick Hilliard wrote: > My own opinion is that the advantages are quite significant. The > disadvantages certainly exist, but are less significant. Therefore I > support the proposal. +1 > There is no right answer for a proposal like this. Contention for > scarce > resources is fundamentally contentious. We just have to live with > that. I agree. There is no perfect solution and I hope we can give up on that quest. So let's settle for something that's good enough -- ie 2010-02 -- and get on with it. There will always be some way for a consensus policy to be gamed. So it's better to have ways of detecting that and acting on it instead of looking for a policy that is immune to manipulation. And have that in place before v4 runs out. > If it turns out that significant implementation problems arise, the > proposal can be changed. Nothing is set in stone. True. Though I doubt this matters. If there are implementation difficulties, these should act as a natural brake on depletion. And anyway the chances are v4 will be gone by the time a revised policy could be adopted. I'm also unsure if strict checks on access the near-empty v4 shelves in the corner shop will matter much when there's a hypermarket next door that's over-filled with v6. From marcoh at marcoh.net Wed Oct 27 14:04:24 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 27 Oct 2010 14:04:24 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <20101027111538.GD45727@burnout.tpb.net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101027111538.GD45727@burnout.tpb.net> Message-ID: <22D71CCF-E10F-4F78-B515-033955F7F118@marcoh.net> On 27 okt 2010, at 13:15, niels=apwg at bakker.net wrote: > * andy at nosignal.org (Andy Davidson) [Thu 21 Oct 2010, 16:40 CEST]: >> On 19 Oct 2010, at 16:00, Emilio Madaio wrote: >>> http://www.ripe.net/ripe/policies/proposals/2010-07.html > [..] >> >> Now that IPv6 PI is available to all networks, in addition to Internet Exchange Points, perhaps we do not need to have a special policy for IXPs at all, but I see possible future value in IXPs sitting inside 2001:7f8/32, so I think it should remain. > > IPv6 PI won't work for IXPs as numbers need to be handed out to connected parties, which is not allowed for PIv6 (in contrast to PIv4 under INFRA-AW). As long as it's one address per customer out of a shared block it's allowed as being infrastructure. What you are not allowed to do is to assign a /64 to each customer, but I don't see a reason for an IXP to do that anyway. MarcoH From marcoh at marcoh.net Wed Oct 27 14:36:23 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 27 Oct 2010 14:36:23 +0200 Subject: [address-policy-wg] 2010-07 New Policy Proposal (Ambiguity cleanup on IPv6 Address Space Policy for IXP) In-Reply-To: <22D71CCF-E10F-4F78-B515-033955F7F118@marcoh.net> References: <20101019150022.8FA4B6A005@postboy.ripe.net> <3F9A4E33-8333-4CC8-A191-73FF8588E72C@nosignal.org> <20101027111538.GD45727@burnout.tpb.net> <22D71CCF-E10F-4F78-B515-033955F7F118@marcoh.net> Message-ID: > As long as it's one address per customer out of a shared block it's allowed as being infrastructure. What you are not allowed to do is to assign a /64 to each customer, but I don't see a reason for an IXP to do that anyway. Been corrected off-list, apparently this is not the case. MarcoH From richih.mailinglist at gmail.com Wed Oct 27 19:52:03 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 27 Oct 2010 19:52:03 +0200 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <4CC774A4.3030701@inex.ie> References: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> <4CC774A4.3030701@inex.ie> Message-ID: On Wed, Oct 27, 2010 at 02:39, Nick Hilliard wrote: > [...] I agree with everything Nick said. If possible, RIPE NCC should weed out people trying to game the system but it's simply impossible to be 100% sure. Richard From marty at akamai.com Thu Oct 28 01:37:56 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 27 Oct 2010 19:37:56 -0400 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <32D65AC2-39E8-47D3-872A-49799974D94B@steffann.nl> Message-ID: Thanks for this. Simple and straight forward enough, but I'm not in support of this proposal. Section two is redundant and linkage to v6 is perfunctory at best so why bother codifying at all? I think we get the message with respect to exhaustion and v6 and further marketing is not necessary. Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead. I don't have a better proposal or more interesting suggestion other than we're probably better off doing nothing than this. Best Regards, -M< On 10/21/10 8:35 AM, "Sander Steffann" wrote: > Hello working group, > > The review phase of proposal 2010-02 has ended. During this review phase no > comments were received. Without any feedback this proposal can't move forward. > I think that it is important that we, as a working group, decide about what we > are going to do with the last IPv4 addresses. > > You can find the full proposal at: > > http://ripe.net/ripe/policies/proposals/2010-02.html > > So: please comment on this proposal. > > Thank you, > Sander Steffann > APWG co-chair > From tore.anderson at redpill-linpro.com Thu Oct 28 08:15:07 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 28 Oct 2010 08:15:07 +0200 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: References: Message-ID: <4CC914EB.4080807@redpill-linpro.com> Hi, * Hannigan, Martin > Section two is redundant and linkage to v6 is perfunctory at best so > why bother codifying at all? I think we get the message with respect > to exhaustion and v6 and further marketing is not necessary. I do agree with you on both of these points, but I don't feel that getting rid of them are reason enough alone to start over again. There's not that much time left, and the two points in question are mostly no-ops and have no real harmful effects. > Allocating each LIR exactly the same sized prefix regardless of > _need_ is pretty unfair sll considered. The addresses could be > utilized more efficiently addressing qualified need instead. > > I don't have a better proposal or more interesting suggestion other > than we're probably better off doing nothing than this. The problem with continuing as before is of course that a single or a small number of LIRs could potentially allocate the entire last /8 over just a few days. In my opinion this situation would be decidedly more unfair than the one proposed here. It would also create a barrier of entry to the market. A startup ISP that can not get _any_ IPv4 addresses to number their LSN, AFT, MX-es, and other critical infrastructure that needs to communicate with the legacy IPv4 internet, would be dead in the water. With not enough addresses to go around achieving complete fairness is impossible. I support 2010-10 as it is the least unfair proposal I've seen so far. It's worth noting that similar policies are adopted in other regions: http://nro.net/documents/comp-pol.html#2-6 Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From Niall.oReilly at ucd.ie Thu Oct 28 12:53:29 2010 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 28 Oct 2010 11:53:29 +0100 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: References: Message-ID: <3175619D-2CE2-4246-B371-C6669AD2E905@ucd.ie> On 28 Oct 2010, at 00:37, Hannigan, Martin wrote: > Allocating each LIR exactly the same sized prefix regardless of _need_ is > pretty unfair sll considered. The addresses could be utilized more > efficiently addressing qualified need instead. As I read the proposal, the allocation of a single prefix of the same size to each LIR is not at all regardless of need, but prioritizes a different need -- that of access to the post-depletion market -- over the pre-depletion need to obtain address allocations for assignment to customers. IIUC, the idea here is that the growing Internet will be IPv6-only; that 6to4 gateways or other continuity measures will be required; that the opportunity for new market entrants to run their own continuity infrastructure should be protected; and that a single, small allocation per LIR will afford this protection. That seems pretty _fair_ to me, in the circumstances. ATB Niall From nick at inex.ie Thu Oct 28 14:19:03 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 28 Oct 2010 13:19:03 +0100 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <3175619D-2CE2-4246-B371-C6669AD2E905@ucd.ie> References: <3175619D-2CE2-4246-B371-C6669AD2E905@ucd.ie> Message-ID: <37020FCE-8F71-4AF9-8C5A-B97A5CE53D30@inex.ie> On 28 Oct 2010, at 11:53, "Niall O'Reilly" wrote: > That seems pretty _fair_ to me, in the circumstances. Post depletion, there will be no such thing as "fair", just varying degrees of "unfair". Nick From marty at akamai.com Thu Oct 28 16:26:07 2010 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 28 Oct 2010 10:26:07 -0400 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <4CC914EB.4080807@redpill-linpro.com> Message-ID: On 10/28/10 2:15 AM, "Tore Anderson" wrote: > Hi, > > * Hannigan, Martin Hi Tore, > >> Section two is redundant and linkage to v6 is perfunctory at best so >> why bother codifying at all? I think we get the message with respect >> to exhaustion and v6 and further marketing is not necessary. > > I do agree with you on both of these points, but I don't feel that > getting rid of them are reason enough alone to start over again. There's > not that much time left, and the two points in question are mostly > no-ops and have no real harmful effects. Point taken. Removing these entirely works in the interest of simplicity and conciseness. > >> Allocating each LIR exactly the same sized prefix regardless of >> _need_ is pretty unfair sll considered. The addresses could be >> utilized more efficiently addressing qualified need instead. >> >> I don't have a better proposal or more interesting suggestion other >> than we're probably better off doing nothing than this. > > The problem with continuing as before is of course that a single or a > small number of LIRs could potentially allocate the entire last /8 over > just a few days. In my opinion this situation would be decidedly more > unfair than the one proposed here. I don't disagree, but I am concerned that such modifications to the need approach without some measure of fairness swings the pendulum too far to the opposite condition, where it enables those that do not have need or reduced need to gain an unfair advantage. Granted, we are talking about a small amount of addresses, but considering the likely exorbitant cost of acquiring even a single address outside of the RIR system I would argue that it matters. > > It would also create a barrier of entry to the market. A startup ISP > that can not get _any_ IPv4 addresses to number their LSN, AFT, MX-es, > and other critical infrastructure that needs to communicate with the > legacy IPv4 internet, would be dead in the water. > Couldn't we argue the opposite saying that the barrier is neutralized with V6? It won't be perfect for the short term, but it does allow entry. > With not enough addresses to go around achieving complete fairness is > impossible. I support 2010-10 as it is the least unfair proposal I've > seen so far. > > It's worth noting that similar policies are adopted in other regions: > > http://nro.net/documents/comp-pol.html#2-6 > Noted with the caveat that no two regions are alike and no single policy fits all with respect to the uniqueness of each RIR. Whether a single ISP takes the entire last /8 or we utilize the Robin Hood approach in the end the consumers are going to pay regardless so it's almost irrelevant. With regards to the NRO comparison of proposals in each RIR region, in the ARIN region austerity measures are implemented with the last /8. Need goes from 1 year to 3 mos. The ARIN measure is also under considerable pressure with respect to conversion from it's existing form to something that is directly tied to transition and more even-handed. It remains to be seen if something will be able to be done to address it prior to full implementation. Best Regards, -M< From randy at psg.com Thu Oct 28 19:10:23 2010 From: randy at psg.com (Randy Bush) Date: Fri, 29 Oct 2010 02:10:23 +0900 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <3175619D-2CE2-4246-B371-C6669AD2E905@ucd.ie> References: <3175619D-2CE2-4246-B371-C6669AD2E905@ucd.ie> Message-ID: > Allocating each LIR exactly the same sized prefix regardless of _need_ > is pretty unfair sll considered. The addresses could be utilized more > efficiently addressing qualified need instead. you're absolutely right. we'll have the ncc go out and manufacture more integers immeduately. why had we never thought of that? embarrassing. randy From marty at akamai.com Thu Oct 28 20:37:14 2010 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 28 Oct 2010 14:37:14 -0400 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: Message-ID: On 10/28/10 1:10 PM, "Randy Bush" wrote: >> Allocating each LIR exactly the same sized prefix regardless of _need_ >> is pretty unfair sll considered. The addresses could be utilized more >> efficiently addressing qualified need instead. > > you're absolutely right. we'll have the ncc go out and manufacture more > integers immeduately. why had we never thought of that? embarrassing. We agree except for the negative cost shifting implications. Need Cost (euro) After Proposal (euro) /32 54.83 0 /31 109.65 0 /30 219.31 0 /29 438.61 0 /28 877.23 0 /27 1,754.46 0 /26 3,508.92 0 /25 7,017.83 0 /24 14,035.66 0 /23 28,071.32 0 /22 56,142.64 0 /21 112,285.29 56,142.64 /20 224,570.57 168,427.93 /19 449,141.15 392,998.50 /18 898,282.29 842,139.65 /17 1,796,564.58 1,740,421.94 /16 3,593,129.16 3,536,986.52 /15 7,186,258.33 7,130,115.69 /14 14,372,516.66 14,316,374.02 /13 28,745,033.32 28,688,890.68 /12 57,490,066.64 57,433,923.99 /11 114,980,133.27 114,923,990.63 /10 229,960,266.55 229,904,123.90 /9 459,920,533.09 459,864,390.45 /8 919,841,066.19 919,784,923.55 Table represents a post depletion cost of $40[1] (FX to euro) subtracting the "value" of a /22 ($56,142.64 FX to euro) as we go down the line with respect to need. The economics of this proposal and their implications are not clear hence my thinking around doing nothing instead. What are the most common 6 prefix sizes allocated in the RIPE region? For example, if it were these: /22 56,142.64 0 /21 112,285.29 56,142.64 /20 224,570.57 168,427.93 /19 449,141.15 392,998.50 /18 898,282.29 842,139.65 /17 1,796,564.58 1,740,421.94 I'd argue that this would be the focused unfairness of this proposal. I'm not even trying to make a big network argument since the damage is noise in the grand scheme of things for most of them. Best, -M< 1. Recently, there was an auction of a swamp /24 on eBay that had been bid up to $40 prior to the closing 60s of the auction where most of the pricing action occurs. I have no evidence to support $40 other than the observation and the widely held belief that this is reasonable. Factors of 10 for your comfort since we do have a reference over 2 years old for addresses @ $4.00. From drc at virtualized.org Thu Oct 28 22:35:19 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 28 Oct 2010 10:35:19 -1000 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: References: Message-ID: <596439AE-6991-4B02-B3E3-4DF3FB3BF276@virtualized.org> Marty, On Oct 28, 2010, at 8:37 AM, Hannigan, Martin wrote: > Table represents a post depletion cost of $40[1] (FX to euro) subtracting > the "value" of a /22 ($56,142.64 FX to euro) as we go down the line with > respect to need. Sorry, I'm confused. How can you estimate the "post depletion cost" prior to depletion occurring? I would find it surprising if the fact that a /24 was bid up to $40 on eBay while folks can still get address space from registries had any relationship with what the price would be when the registries are no longer 'distorting the market'. Regards, -drc From marty at akamai.com Thu Oct 28 22:54:44 2010 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 28 Oct 2010 16:54:44 -0400 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: <596439AE-6991-4B02-B3E3-4DF3FB3BF276@virtualized.org> Message-ID: On 10/28/10 4:35 PM, "David Conrad" wrote: > Marty, > > On Oct 28, 2010, at 8:37 AM, Hannigan, Martin wrote: >> Table represents a post depletion cost of $40[1] (FX to euro) subtracting >> the "value" of a /22 ($56,142.64 FX to euro) as we go down the line with >> respect to need. > > Sorry, I'm confused. How can you estimate the "post depletion cost" prior to > depletion occurring? I would find it surprising if the fact that a /24 was bid > up to $40 on eBay while folks can still get address space from registries had > any relationship with what the price would be when the registries are no > longer 'distorting the market'. > I was clear in the footnote that I only have a reference[1] for the lower number. To answer your question as to why, the table that I provided speaks for itself even if reduced by multiple factors of ten; profit and/or revenue protection. Buy low, sell high, so to speak and I think that the main point is that the cost of an address post depletion is an unknown. While my number looks high, it could go either way. It could be higher which would mean that the damage would be greater or it could be lower which means that it's "not so bad" where YMMV. Best, -M< 1. http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3. pdf From richih.mailinglist at gmail.com Fri Oct 29 00:22:14 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Oct 2010 00:22:14 +0200 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: References: <596439AE-6991-4B02-B3E3-4DF3FB3BF276@virtualized.org> Message-ID: On Thu, Oct 28, 2010 at 22:54, Hannigan, Martin wrote: > While my number > looks high, it could go either way. It could be higher which would mean that > the damage would be greater or it could be lower which means that it's "not > so bad" where YMMV. Which basically boils down to "no one can possibly know". Also, I doubt that the cost for prefixes will be strictly linear. It's in the nature of depletion that not everyone can get what they need/want. The proposal clearly states that its main focus is to prevent prefix hogging if possible and thus limit the impact of a probably frantic migration period and lower the barrier of entry for new LIRs. And while I sincerely hope that IPv6 migration will happen fast, there will definitely be a time when IPv4 will be a hard requirement for any LIR that wants to compete. As you admit yourself, other than doing nothing you don't know of any alternative. Richard From danny at danysek.cz Fri Oct 29 08:47:00 2010 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 29 Oct 2010 08:47:00 +0200 Subject: [address-policy-wg] Proposal 2010-02 In-Reply-To: References: Message-ID: <4CCA6DE4.4010203@danysek.cz> Hello, On 10/28/2010 01:37 AM, Hannigan, Martin wrote: > Allocating each LIR exactly the same sized prefix regardless of _need_ is > pretty unfair sll considered. The addresses could be utilized more > efficiently addressing qualified need instead. Allocations from _last_ /8 in my oppinion are special and we don't need fulfill LIRs needs like "additional /16" here. Allowing larger allocations from last /8 simply stalls implementation of IPv6 in networks around and will exhaust existing space more quickly. And it's typical argument from many network operators even in these days - until they'll have enough IPv4 resources, they'll not care about IPv6 at all. By this proposal, everyone knows in advance, that from some term they'll receive only /22 allocation and nothing more. This proposal simply shifts time of real depletion more closely, BUT there's some special reserve to serve additional requests in accordance to defined rules. This is quite fair, as it's announced in advance. On 10/28/2010 01:37 AM, Hannigan, Martin wrote: > I don't have a better proposal or more interesting suggestion other > than we're probably better off doing nothing than this. Doing nothing is not a option, at least not for me. This sounds like you want to simply depredate land (available addresses) as much as possible a you don't care about the future. I'm seeing proposal 2010-02 as compromise - in my oppinion, some remaining IPv4 address space should be reserved ONLY for _new_ LIRs to give them some IPv4 address space and this proposal efectivelly does this (and in addition, existing LIRs can be served, too). And even there're some economical implications, the proposal itself isn't primary about money and cost of IPv4 address, this is technical proposal. It's about address distribution to new and existing LIRs. And we have to care about new LIRs, we need to reserve some address space for them - as lots of internet resources will be accessible only over IPv4 for long period after depletion. It's about survivance of free allocatable IPv4 address space as long as possible. So, I'm personally SUPPORTING this proposal - as doing something is better than doing nothing and just wait for depletion. And I'm not seeing any major reason, why not support 2010-02 proposal - it's simple and clear. With regards, Daniel From mueller at syr.edu Fri Oct 29 16:17:17 2010 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 29 Oct 2010 10:17:17 -0400 Subject: [address-policy-wg] Proposal 2010-2 In-Reply-To: <20101029100003.10218.56161.Mailman@postboy.ripe.net> References: <20101029100003.10218.56161.Mailman@postboy.ripe.net> Message-ID: <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> > And even there're some economical implications, the proposal itself > isn't primary about money and cost of IPv4 address, this is technical > proposal. It's about address distribution to new and existing LIRs. As long as addresses are scarce, there is no such thing as a purely technical allocation proposal. Any allocation mechanism involves a competitive relationship among LIRs for available resources, and any policy distributes costs and benefits among the contending parties. > And we have to care about new LIRs, we need to reserve some address space > for them - as lots of internet resources will be accessible only over > IPv4 for long period after depletion. It's about survivance of free > allocatable IPv4 address space as long as possible. I agree with this concern, but you seem unaware of the possibilities of strategic behavior by LIRs. Consider: LIR 1, an incumbent, proves it needs a /16 to meet demand caused by growth in the number of its existing customers. LIR 2, a startup, also proves it needs a /16 to start up Your policy privileges any actor in the category LIR 2 and penalizes actors in category LIR 1. Question 1: why are the customers of LIR 2 more important than the customers of LIR 1? Question 2: why wouldn't LIR 1 form a new company and call it a startup to get privileged access to addresses? Or, might LIR 3, LIR 1's long standing competitor, form a new LIR to gain an advantage in the competition for resources? One could argue for your position by noting that LIRs who already have some blocks of ipv4 are in a position to economize on and/or NAT those addresses, whereas an ISP without any can't do that. That provides some answer to Q1. But it doesn't deal with the problems around Q2. From heldal at eml.cc Fri Oct 29 22:53:15 2010 From: heldal at eml.cc (Per Heldal) Date: Fri, 29 Oct 2010 22:53:15 +0200 Subject: [address-policy-wg] Proposal 2010-2 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> References: <20101029100003.10218.56161.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> Message-ID: <1288385595.1790.25.camel@obelix> On Fri, 2010-10-29 at 10:17 -0400, Milton L Mueller wrote: > Consider: > LIR 1, an incumbent, proves it needs a /16 to meet demand caused by growth in the number of its existing customers. > LIR 2, a startup, also proves it needs a /16 to start up > > Your policy privileges any actor in the category LIR 2 and penalizes actors in category LIR 1. Both LIRs would be eligible for address-blocks assigned from the general pool. After depletion this means space that has been reclaimed or in some other way returned to the RIR for reuse. > > > Question 1: why are the customers of LIR 2 more important than the customers of LIR 1? They are not. BOTH LIRs are expected to accomodate _growth_ in customer numbers through IPv6. NEITHER will get a large enough adress-block from the reserve to meet their growth needs. At most they'd get a /20 or /22 to establish transition services, no /16. The RIR's intention is to provide your LIR2 with a small block they can use to provide connectivity to existing IPv4 services for their IPv6 customers. > Question 2: why wouldn't LIR 1 form a new company and call it a startup to get privileged access to addresses? Or, might LIR 3, LIR 1's long standing competitor, form a new LIR to gain an advantage in the competition for resources? > > One could argue for your position by noting that LIRs who already have some blocks of ipv4 are in a position to economize on and/or NAT those addresses, whereas an ISP without any can't do that. That provides some answer to Q1. But it doesn't deal with the problems around Q2. > Exactly. Most, if not all, networks of significant size have a small chunk of spare addresses they can recycle for transition services. A new LIR OTOH has nothing and could theoretically be blocked from entering the market. //per From drc at virtualized.org Fri Oct 29 23:21:37 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 29 Oct 2010 11:21:37 -1000 Subject: [address-policy-wg] Proposal 2010-2 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> References: <20101029100003.10218.56161.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> Message-ID: <1D5971BE-C243-408C-8045-8D959E4E65F3@virtualized.org> On Oct 29, 2010, at 4:17 AM, Milton L Mueller wrote: > I agree with this concern, but you seem unaware of the possibilities of strategic behavior by LIRs. > > Consider: > LIR 1, an incumbent, proves it needs a /16 to meet demand caused by growth in the number of its existing customers. > LIR 2, a startup, also proves it needs a /16 to start up > > Your policy privileges any actor in the category LIR 2 and penalizes actors in category LIR 1. > > Question 1: why are the customers of LIR 2 more important than the customers of LIR 1? They aren't. LIR 1, being forced to jump through different hoops, is considered less important. Or, to put it in less inflammatory terms, is considered more able to absorb the additional costs. > Question 2: why wouldn't LIR 1 form a new company and call it a startup to get privileged access to addresses? A question of cost. LIR 1 would likely run the numbers to see which is cheaper: a) create a subsidiary as you describe b) purchase the necessary space off the black/grey market c) sue RIPE for discriminatory business practices aimed at damaging LIR 1's business (well, OK, since it isn't the US, this probably won't happen). d) migrate to IPv6 and hope no customer wants IPv4 access that can't be accommodated via NAT. > Or, might LIR 3, LIR 1's long standing competitor, form a new LIR to gain an advantage in the competition for resources? You mean LIR 3 might lie? :-) > One could argue for your position by noting that LIRs who already have some blocks of ipv4 are in a position to economize on and/or NAT those addresses, whereas an ISP without any can't do that. That provides some answer to Q1. But it doesn't deal with the problems around Q2. It all boils down to a question of cost. Even economizing/NATing/etc. has a cost so a rational business will look at the various costs and do the cost/benefit analysis. Regards, -drc From jwkckid1 at ix.netcom.com Fri Oct 29 23:36:18 2010 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Fri, 29 Oct 2010 16:36:18 -0500 (GMT-05:00) Subject: [address-policy-wg] Proposal 2010-2 Message-ID: <6838585.1288388178713.JavaMail.root@elwamui-little.atl.sa.earthlink.net> david Milton and all, David is mostly correct here I believe. However first, if there was a more concerted effort to reclaim unused IPv4 addresses much of the cost problem would be mitigated, but still not all. Secondly, if a better replacement for IPv4 than IPv6 was better promoted several years ago now, there would be less of a cost impact problem. Sadly the RIR's in particular are not interested in doing a better more concerted job of reclaiming unused/horded IPv4 addresses and Jim Bound did such a bang up job of promoting a flawed replacement for IPv4, namely IPv6 that the cost of converting is so high that likely customers are reluctant to release their horded/unused IPv4 addresses accordingly. -----Original Message----- >From: David Conrad >Sent: Oct 29, 2010 4:21 PM >To: Milton L Mueller >Cc: "'address-policy-wg at ripe.net'" >Subject: Re: [address-policy-wg] Proposal 2010-2 > >On Oct 29, 2010, at 4:17 AM, Milton L Mueller wrote: >> I agree with this concern, but you seem unaware of the possibilities of strategic behavior by LIRs. >> >> Consider: >> LIR 1, an incumbent, proves it needs a /16 to meet demand caused by growth in the number of its existing customers. >> LIR 2, a startup, also proves it needs a /16 to start up >> >> Your policy privileges any actor in the category LIR 2 and penalizes actors in category LIR 1. >> > >> Question 1: why are the customers of LIR 2 more important than the customers of LIR 1? > >They aren't. LIR 1, being forced to jump through different hoops, is considered less important. Or, to put it in less inflammatory terms, is considered more able to absorb the additional costs. > >> Question 2: why wouldn't LIR 1 form a new company and call it a startup to get privileged access to addresses? > >A question of cost. LIR 1 would likely run the numbers to see which is cheaper: > >a) create a subsidiary as you describe >b) purchase the necessary space off the black/grey market >c) sue RIPE for discriminatory business practices aimed at damaging LIR 1's business (well, OK, since it isn't the US, this probably won't happen). >d) migrate to IPv6 and hope no customer wants IPv4 access that can't be accommodated via NAT. > >> Or, might LIR 3, LIR 1's long standing competitor, form a new LIR to gain an advantage in the competition for resources? > >You mean LIR 3 might lie? :-) > >> One could argue for your position by noting that LIRs who already have some blocks of ipv4 are in a position to economize on and/or NAT those addresses, whereas an ISP without any can't do that. That provides some answer to Q1. But it doesn't deal with the problems around Q2. > >It all boils down to a question of cost. Even economizing/NATing/etc. has a cost so a rational business will look at the various costs and do the cost/benefit analysis. > >Regards, >-drc > Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 Network Eng. SR. Eng. Network data security ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com Phone: 214-244-4827 From heldal at eml.cc Sat Oct 30 01:31:03 2010 From: heldal at eml.cc (Per Heldal) Date: Sat, 30 Oct 2010 01:31:03 +0200 Subject: [address-policy-wg] Proposal 2010-2 In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B34A@SUEX07-MBX-04.ad.syr.edu> References: <20101029100003.10218.56161.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> <1288385595.1790.25.camel@obelix> <75822E125BCB994F8446858C4B19F0D70AC125B34A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <1288395063.1790.35.camel@obelix> On Fri, 2010-10-29 at 17:27 -0400, Milton L Mueller wrote: > > > > > Question 2: why wouldn't LIR 1 form a new company and call it a > > startup to get privileged access to addresses? Or, might LIR 3, LIR 1's > > long standing competitor, form a new LIR to gain an advantage in the > > competition for resources? > > > > > Most, if not all, networks of significant size have a small > > chunk of spare addresses they can recycle for transition services. A > > new LIR OTOH has nothing and could theoretically be blocked from entering > > the market. > > And Question 2? That's best answered with a question. What's the point for an established LIR to go through all that trouble just to get another tiny block? A small hosting-operation might have some use for it, but it makes no sense for your example LIR (regional, national or multi-national network operator). //per From drc at virtualized.org Sat Oct 30 06:10:45 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 29 Oct 2010 18:10:45 -1000 Subject: [address-policy-wg] Proposal 2010-2 In-Reply-To: <1288395063.1790.35.camel@obelix> References: <20101029100003.10218.56161.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> <1288385595.1790.25.camel@obelix> <75822E125BCB994F8446858C4B19F0D70AC125B34A@SUEX07-MBX-04.ad.syr.edu> <1288395063.1790.35.camel@obelix> Message-ID: <0A8EB997-4489-49BE-98FA-8D9D79404F9F@virtualized.org> On Oct 29, 2010, at 1:31 PM, Per Heldal wrote: > What's the point for an established LIR to go through all that trouble > just to get another tiny block? Because they want to add more (IPv4-only) customers? Or more specifically, the value they get from potential new customers that will make use of that space outweighs the cost of going through the trouble. However, a similar question can be asked: at this point in the game, what's the point in starting up a new service dependent on IPv4? > A small hosting-operation might have some use for it, but it makes no > sense for your example LIR (regional, national or multi-national network > operator). Regional, national, and multi-national network operators are going to want to continue adding customers even after the last /8s get allocated. And they're going to have way more money, lawyers, and political power to ensure that they can do so. This policy appears to assume folks are going to play nice as the lifeboat starts taking on water... Oops. Is my cynicism showing again? :-) Regards, -drc From gert at space.net Sun Oct 31 14:23:00 2010 From: gert at space.net (Gert Doering) Date: Sun, 31 Oct 2010 14:23:00 +0100 Subject: [address-policy-wg] Agenda (first draft) for RIPE 61 in Rome Message-ID: <20101031132300.GO32268@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Rome in the following three time slots: Wednesday, November 17, 09:00 - 10:30 Wednesday, November 17, 11:00 - 12:30 Thursday, November 18, 09:00 - 11:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Emilio Madaio [20-30 min] - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE60 2008-07 Efficient Use of Historical IPv4 Resources - withdrawn 2009-01 Global Policy ... Allocation of IPv4 to RIRs - accepted 2010-03 Global Policy State in RIPE PDP - withdrawn 2010-04 80% Rule Ambiguity Cleanup - accepted - brief overview over new proposals (2010-05, 2010-06, 2010-07) C. Document Cosmetic Surgeries Project - Emilio Madaio [10 min] - update on current status - how to go forward? D. Rough Edges of the current policies [30 min] Report from the RIPE NCC Registration Services department on issues and unintended side-effects showing up in the daily implementation of the RIPE policies. Presentation from Alex Le Heux from the RIPE NCC RS: o transfer policy and problems with business take-overs [problem statement] o PI size distribution and its history (growing assignments) [background info] o IPv6 PI vs. IPv4 PI - background data [background info] Discussion about the transfer policy issues, and what to do about it. E. More Rough Edges of the current policies [10 min] "things that have been come up in various fora" o interpretation of "utilisation threshold" in IPv6 policy regarding /48 and /56s - proposal by Arno Meulenkamp for wording cleanup: "It might be good to rephrase the text to "Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of assigned address space in units of /56 blocks." (5.2.1, discussion on ipv6-ops at cluenet.de) [came up in discussion on the ipv6-ops list, presentation by Gert Doering] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- I. Even More Rough Edges of the current policies [45 min] o "end site" definition - RIPE 481, 2.9 2 ADSL links, not connected networks, same legal organization -> is there a conflict or not? 1 /48 or 2? do we need to change the policy / clarify the policy text? [came up in discussion between the WG chairs, presentation by Sander Steffann, discussion] o definition of "openness" in the IPv6 EIX policy initiated by 2010-07, but widening the scope from "wording change" to "figure out what the policy should be, *then* talk about specific wording" [presentation by Gert Doering, discussion] o generic IPv6 PI discussion(?) differences between IPv4 PI and IPv6 PI are being discussed since RIPE 59 - but no specific proposals on the table yet. Is there a need to change the policy, or is it "mostly fine"? [presentation by Gert Doering, discussion] J. New Proposals since RIPE 60 -> Discussion of open policy proposals, Part 1 (new proposals) [20 min] 2010-05 Global Policy for IPv4 Allocation by the IANA post exhaustion (Jason Schiller et. al.) 2010-07 Ambiguity cleanup on IPv6 Address Space Policy for IXP (presentation?) L. Discussion of open policy proposals, Part 2 (ongoing proposals) 2008-08 Initial Certification Policy for PA Space Holders [15 min] (Nigel Titley, CA TF - version 2 update) ---------------------------------------------------------------------- Thursday, 09:00-10:30 ---------------------------------------------------------------------- T. Discussion of open policy proposals (old proposals, part II) ---- old policy proposals ---- 2006-05 PI Assignment Size [15 min] (revived, Nick Hilliard) 2010-01 Temporary Internet Number Assignment Policies [15 min] (Nick Hilliard) 2010-02 Allocations from the last /8 [15 min] (new combined proposal from Philip Smith and Alain Bidron) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) o Martin Hannigan / Jason Schiller: proposal about Inter-RIR transfers Z. AOB From mueller at syr.edu Fri Oct 29 23:27:59 2010 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 29 Oct 2010 17:27:59 -0400 Subject: [address-policy-wg] Proposal 2010-2 In-Reply-To: <1288385595.1790.25.camel@obelix> References: <20101029100003.10218.56161.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D70AC125B342@SUEX07-MBX-04.ad.syr.edu> <1288385595.1790.25.camel@obelix> Message-ID: <75822E125BCB994F8446858C4B19F0D70AC125B34A@SUEX07-MBX-04.ad.syr.edu> > > > Question 2: why wouldn't LIR 1 form a new company and call it a > startup to get privileged access to addresses? Or, might LIR 3, LIR 1's > long standing competitor, form a new LIR to gain an advantage in the > competition for resources? > > > Most, if not all, networks of significant size have a small > chunk of spare addresses they can recycle for transition services. A > new LIR OTOH has nothing and could theoretically be blocked from entering > the market. And Question 2?