From emadaio at ripe.net Tue May 1 15:15:43 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 01 May 2012 15:15:43 +0200 Subject: [address-policy-wg] 2012-01 Policy Proposal Withdrawn (Inter-RIR Address Transfers) Message-ID: Dear Colleagues, The proposal 2012-01,"Inter-RIR Address Transfers", has been withdrawn. It is now archived and can be found at: https://www.ripe.net/ripe/policies/archived-policy-proposals/proposals/2012-01 Reason for withdrawal:With respect to 2012-01, after the feedback and discussion at the RIPE 64 Meeting, the proposer decided to collaborate with other community members in submitting another policy proposal related to IPv4 transfers. Therefore the proposer decided to withdraw this proposal. Best Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Mon May 7 16:18:52 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 07 May 2012 16:18:52 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) Message-ID: Dear Colleagues, A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-04 We encourage you to review this proposal and send your comments to before 4 June 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From sergey at devnull.ru Mon May 7 16:27:07 2012 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 7 May 2012 16:27:07 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: Message-ID: <681253007.20120507162707@devnull.ru> Regarding using last /8 for PI assignments, this proposal looks fair to me. -- Sergey Monday, May 7, 2012, 4:18:52 PM, you wrote: EM> Dear Colleagues, EM> A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation EM> and Assignment Policy for the RIPE NCC Service Region", is now EM> available for discussion. EM> You can find the full proposal at: EM> https://www.ripe.net/ripe/policies/proposals/2012-04 EM> We encourage you to review this proposal and send your comments to EM> before 4 June 2012. EM> Regards EM> Emilio Madaio EM> Policy Development Officer EM> RIPE NCC From jan at go6.si Mon May 7 17:58:22 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 07 May 2012 17:58:22 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <681253007.20120507162707@devnull.ru> References: <681253007.20120507162707@devnull.ru> Message-ID: <4FA7F11E.9010509@go6.si> On 5/7/12 4:27 PM, Sergey Myasoedov wrote: > > Regarding using last /8 for PI assignments, this proposal looks fair to me. Agree. Lets distribute the leftovers and be done with this for good, so people could focus on important things (such as IPv6 deployment :) ) +1 Jan From chrish at consol.net Mon May 7 18:19:09 2012 From: chrish at consol.net (chrish at consol.net) Date: Mon, 07 May 2012 18:19:09 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <201205071419.q47EJQKv063749@gw1.consol.de> References: <201205071419.q47EJQKv063749@gw1.consol.de> Message-ID: <4FA7F5FD.6040508@consol.net> hi! > https://www.ripe.net/ripe/policies/proposals/2012-04 i'd like to support this. regards, Chris From dr at cluenet.de Mon May 7 19:08:54 2012 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 7 May 2012 19:08:54 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <20120507141933.B3655108384@mail1.cluenet.de> References: <20120507141933.B3655108384@mail1.cluenet.de> Message-ID: <20120507170854.GA7890@srv03.cluenet.de> On Mon, May 07, 2012 at 04:18:52PM +0200, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. I support this policy change proposal. It makes no sense to me to disallow PI allocation within the last /8. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From maildanrl at googlemail.com Mon May 7 19:25:11 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 7 May 2012 19:25:11 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4fa7d9e7.07bb0e0a.67ab.ffffdfe0SMTPIN_ADDED@mx.google.com> References: <4fa7d9e7.07bb0e0a.67ab.ffffdfe0SMTPIN_ADDED@mx.google.com> Message-ID: On Mon, May 7, 2012 at 4:18 PM, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. I support this proposal. > It is likely that PI assignments from the last /8 will cause the last /8 to be consumed faster than if PI assignments were prohibited. That's a pro in my opinion. Regards Dan -- Dan Luedtke http://www.danrl.de From Remco.vanMook at eu.equinix.com Mon May 7 19:34:25 2012 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 7 May 2012 18:34:25 +0100 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <201205071419.q47EJNhI007769@rly41b.srv.mailcontrol.com> Message-ID: Alright then, for the sake of argument I'll oppose until I see some convincing numbers. Back in the original last /8 discussion the rationale for choosing a /22 was that it would get us about 16k final allocations, or 1 for every NCC member and room for the membership to double in size. Now, we have a number of new realities: - final /8 applies to all v4 address space when it kicks in, including space that gets returned later; - It also applies to v4 address space that has not been allocated or assigned by RIPE NCC at that date; - An additional 'special case' block was set aside for IXPs. This all impacts, in a positive or negative way, how much future there is in our final /8 policy. I'd like to think that we made a well-considered decision back then, and if we're going to make a fundamental change like this one I'd like to see some numbers in an impact analysis. Based on current distribution, how much space do we anticipate will fall under the final /8 policy, how much of it will be allocated in /22 PA and how much will be allocated in /24 PI? Given the 'one size fits nobody' nature of the final /8 policy, this would be about the number of allocations/assignments done so far, not the size. Personally I'm rather sick and tired of hearing people say 'yes, let's break IPv4 so we all MUST move to IPv6'. If you think this is good policy or even good engineering, please think again. It will make us end up with a broken internet that, surprise, we won't be managing any more. Breaking IPv4 might lead to increased IPv6 adoption, but not on the internet as we know it today. Everybody who wants to connect his organisation to the internet is going to need at least some IPv4 address space for the time being, so why screw it up for new entrants? Finally, I would like to hear how this proposal correlates to the charge for PI space - the good old 2007-01 chestnut. For post-depletion LIRs, the grapes would be quite sour if one could pick up a quarter of the available resources for about one twentieth of the price. Should "Final /8 PIv4" have a separate price tag? Best Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From turchanyi.geza at gmail.com Mon May 7 19:59:36 2012 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Mon, 7 May 2012 19:59:36 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: <201205071419.q47EJNhI007769@rly41b.srv.mailcontrol.com> Message-ID: Good questions, Remco! Thanks, G?za On Mon, May 7, 2012 at 7:34 PM, Remco Van Mook wrote: > > > > Alright then, for the sake of argument I'll oppose until I see some > convincing numbers. Back in the original last /8 discussion the rationale > for choosing a /22 was that it would get us about 16k final allocations, > or 1 for every NCC member and room for the membership to double in size. > Now, we have a number of new realities: > > - final /8 applies to all v4 address space when it kicks in, including > space that gets returned later; > - It also applies to v4 address space that has not been allocated or > assigned by RIPE NCC at that date; > - An additional 'special case' block was set aside for IXPs. > > This all impacts, in a positive or negative way, how much future there is > in our final /8 policy. I'd like to think that we made a well-considered > decision back then, and if we're going to make a fundamental change like > this one I'd like to see some numbers in an impact analysis. Based on > current distribution, how much space do we anticipate will fall under the > final /8 policy, how much of it will be allocated in /22 PA and how much > will be allocated in /24 PI? Given the 'one size fits nobody' nature of > the final /8 policy, this would be about the number of > allocations/assignments done so far, not the size. > > Personally I'm rather sick and tired of hearing people say 'yes, let's > break IPv4 so we all MUST move to IPv6'. If you think this is good policy > or even good engineering, please think again. It will make us end up with > a broken internet that, surprise, we won't be managing any more. Breaking > IPv4 might lead to increased IPv6 adoption, but not on the internet as we > know it today. Everybody who wants to connect his organisation to the > internet is going to need at least some IPv4 address space for the time > being, so why screw it up for new entrants? > > Finally, I would like to hear how this proposal correlates to the charge > for PI space - the good old 2007-01 chestnut. For post-depletion LIRs, the > grapes would be quite sour if one could pick up a quarter of the available > resources for about one twentieth of the price. Should "Final /8 PIv4" > have a separate price tag? > > Best > > Remco > > > > This email is from Equinix Europe Limited or one of its > associated/subsidiary companies. This email, and any files transmitted with > it, contains information which is confidential, may be legally privileged > and is solely for the use of the intended recipient. If you have received > this email in error, please notify the sender and delete this email > immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 > Thomas More Square, London E1W 1YW. Registered in England and Wales, No. > 6293383. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey at devnull.ru Mon May 7 20:16:33 2012 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 7 May 2012 20:16:33 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: <201205071419.q47EJNhI007769@rly41b.srv.mailcontrol.com> Message-ID: <783126130.20120507201633@devnull.ru> Hi Remco, how did you calculate 1/20? Do you mean 1/26? Okay, let's stop calculating. Actually 2007-01 does not conflict with 2012-04. Anyway, after depletion only price will be the difference between PI and PA. Monday, May 7, 2012, 7:34:25 PM, you wrote: RVM> Finally, I would like to hear how this proposal correlates to the charge RVM> for PI space - the good old 2007-01 chestnut. For post-depletion LIRs, the RVM> grapes would be quite sour if one could pick up a quarter of the available RVM> resources for about one twentieth of the price. Should "Final /8 PIv4" RVM> have a separate price tag? -- Sergey From nick at inex.ie Mon May 7 21:20:05 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 07 May 2012 20:20:05 +0100 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: Message-ID: <4FA82065.6050407@inex.ie> Remco, > Alright then, for the sake of argument I'll oppose until I see some > convincing numbers. Back in the original last /8 discussion the rationale > for choosing a /22 was that it would get us about 16k final allocations, > or 1 for every NCC member and room for the membership to double in size. we need to move away from this idea of how to expand the RIPE NCC membership and think more in terms of how to serve the RIPE community. There may be a good deal of overlap between these two goals, but they are not necessarily the same. There is no doubt that if address space can be assigned as PI, then this will reduce the amount available to LIRs and that this is not a good thing. On the other hand, who is to say that a LIR deserves IP address space more than an End User who needs a PI assignment? As it stands, the "last /8" policy makes a default unilateral judgement in favour of the LIR. This strikes me as being an extraordinary position to take. > Now, we have a number of new realities: > > - final /8 applies to all v4 address space when it kicks in, including > space that gets returned later; > - It also applies to v4 address space that has not been allocated or > assigned by RIPE NCC at that date; > - An additional 'special case' block was set aside for IXPs. The special case IXP block is neither here nor there. A /16 makes no difference in the grand scheme of things. What's relevant here is that as a result of 2011-03, the "last /8" policy would be more appropriately called "the dregs" policy - the ipv4 policies which apply to the last /8 will become permanent fixtures applying to all future address space after depletion. Perhaps they won't apply to a huge amount of address space, but there will be a constant and small turnover of address blocks reclaimed by the RIPE NCC for the foreseeable future. Turns out, this is a pretty fundamental change. We had, as a community, created a last /8 policy because we believed that there was something special about the addresses in the bottom of the barrel. Then we realised that there would be a permanent small trickle of addresses into this barrel and that there was really no such thing as the "last /8". In a roundabout sort of way, this policy floats the idea that the entire concept of the last /8 being special is slightly artificial, and that really they're not "special" addresses, they're just "addresses". Same as all the other addresses we've assigned, allocated and used all along. The only difference we've really made is that we've narrowed the mouth of the toothpaste tube so that more people might be able to get a taste. Taking a slightly different viewpoint, 2012-04 makes the last /8 policy more similar to the "run out fairly" model, except that instead of limiting on the basis of expected use within X months, we're putting some hard limits in. > This all impacts, in a positive or negative way, how much future there is > in our final /8 policy. I'd like to think that we made a well-considered > decision back then, and if we're going to make a fundamental change like > this one I'd like to see some numbers in an impact analysis. Based on > current distribution, how much space do we anticipate will fall under the > final /8 policy, how much of it will be allocated in /22 PA and how much > will be allocated in /24 PI? Given the 'one size fits nobody' nature of > the final /8 policy, this would be about the number of > allocations/assignments done so far, not the size. yes, numbers would be interesting and I agree that the impact analysis should include some form of run-out projection of the type you're suggesting. I don't know if these numbers are going to make a fundamental difference to whether this is a good or a bad policy, but no harm will come from having them to hand. btw, do you have any criteria for evaluating these numbers if/when they are produced by the NCC? > Finally, I would like to hear how this proposal correlates to the charge > for PI space - the good old 2007-01 chestnut. For post-depletion LIRs, the > grapes would be quite sour if one could pick up a quarter of the available > resources for about one twentieth of the price. Should "Final /8 PIv4" > have a separate price tag? This is quite a different discussion, and is part of the more fundamental issue of why we have PI and PA in the first place. If they're just addresses, why does the RIPE community want them packaged up and labelled with different colours? What do these colours mean, and how will this impact on ipv6 PI and PA assignment policy? How will it affect the RIPE NCC budget? How can we make the PA and PI charging schemes more aligned? Or even fully aligned? These are all interesting and relevant questions to both the RIPE NCC and the RIPE community, and I believe it to be critically important to the RIPE NCC that they be asked and answered soon. But they are out of scope for this policy proposal. Right now, we have a case of significant bias towards LIRs and this is what this policy proposal seeks to redress. Nick From tore.anderson at redpill-linpro.com Tue May 8 09:11:34 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 08 May 2012 09:11:34 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: Message-ID: <4FA8C726.9030309@redpill-linpro.com> * Remco Van Mook > This all impacts, in a positive or negative way, how much future > there is in our final /8 policy. I'd like to think that we made a > well-considered decision back then, and if we're going to make a > fundamental change like this one I'd like to see some numbers in an > impact analysis. Based on current distribution, how much space do we > anticipate will fall under the final /8 policy, how much of it will > be allocated in /22 PA and how much will be allocated in /24 PI? > Given the 'one size fits nobody' nature of the final /8 policy, this > would be about the number of allocations/assignments done so far, not > the size. Hi, So, by looking in today's delegated-ripencc-latest file... We need to look back on 105 days of delegations in order to as close as possible to a /8s worth of addresses handed out. The numbers are: Total number of delegated addresses: 17,156,520 Total number of delegations: 1,696 Total number of allocated addresses: 14,784,512 (86.17%) Total number of allocations: 701 (41.33%) Total number of assigned addresses: 2,372,008 (13.83%) Total number of assignments: 995 (58.67%) If I, eh, "simulate" the last /8 policy + 2012-04 by assuming that every assignment is a /24 and every allocation is a /22, we would need to look back 3071 days to get to the equivalent of a /8: Total number of delegated addresses: 16,779,776 Total number of delegations: 28,787 Total number of allocated addresses: 12,547,072 (74.77%) Total number of allocations: 12,253 (42.56%) Total number of assigned addresses: 4,232,704 (25.23%) Total number of assignments: 16,534 (57.44%) Note that neither of these filter away additional delegations to LIRs and EUs, something which won't happen under the last /8 policy. I don't make the claim that these numbers necessarily are meaningful or even relevant to the discussion, though. You be the judge of that... > Everybody who wants to connect his organisation to the internet is > going to need at least some IPv4 address space for the time being, so > why screw it up for new entrants? Indeed. I suspect that this the exact problem 2012-04 aims to deal with, as the current last /8 policy *does* ?screw it up for new entrants? [that aren't LIRs]. I have a couple of questions regarding the proposed policy, though (not directed at you Remco): 1) Under the proposed policy, would an LIR be eligible for both a /22 PA allocation and a /24 PI assignment, or is it either-or? (I think the proposal as it currently stands is the former, but is that intentional?) 2) Will ripe-530 section 6.10 (minimum assignment=/24 if multihoming) be in effect under 2012-04? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From jan at go6.si Tue May 8 10:01:48 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 08 May 2012 10:01:48 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: Message-ID: <4FA8D2EC.7060309@go6.si> On 5/7/12 7:34 PM, Remco Van Mook wrote: > > > > Alright then, for the sake of argument I'll oppose until I see some > convincing numbers. Back in the original last /8 discussion the rationale > for choosing a /22 was that it would get us about 16k final allocations, > or 1 for every NCC member and room for the membership to double in size. > Now, we have a number of new realities: So, when we hit the last /8 policy, all those who will then need IPv4 space *must* become an LIR even if one /24 PI would fulfill entirely their need? Not sure everyone appreciates that, specially not small companies or even start-ups :) Cheers, Jan From sp at iphh.net Tue May 8 10:10:09 2012 From: sp at iphh.net (Sascha E. Pollok) Date: Tue, 8 May 2012 10:10:09 +0200 (CEST) Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4FA8D2EC.7060309@go6.si> References: <4FA8D2EC.7060309@go6.si> Message-ID: >> Alright then, for the sake of argument I'll oppose until I see some >> convincing numbers. Back in the original last /8 discussion the rationale >> for choosing a /22 was that it would get us about 16k final allocations, >> or 1 for every NCC member and room for the membership to double in size. >> Now, we have a number of new realities: > > So, when we hit the last /8 policy, all those who will then need IPv4 space > *must* become an LIR even if one /24 PI would fulfill entirely their need? Or they give up on PI-plans and go to a LIR that can assign /24 and then deaggregate and multihome. For the routing table growth this should not matter. I don't say that this would be fair but it is still a feasible way to go. And of course, having PA or PI is still a difference especially when it is about changing ISPs/associated LIRs. -Sascha From stolpe at resilans.se Tue May 8 10:53:06 2012 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 8 May 2012 10:53:06 +0200 (CEST) Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4FA82065.6050407@inex.ie> References: <4FA82065.6050407@inex.ie> Message-ID: On Mon, 7 May 2012, Nick Hilliard wrote: >> Now, we have a number of new realities: >> >> - final /8 applies to all v4 address space when it kicks in, including >> space that gets returned later; >> - It also applies to v4 address space that has not been allocated or >> assigned by RIPE NCC at that date; >> - An additional 'special case' block was set aside for IXPs. > > The special case IXP block is neither here nor there. A /16 makes no > difference in the grand scheme of things. > > What's relevant here is that as a result of 2011-03, the "last /8" policy > would be more appropriately called "the dregs" policy - the ipv4 policies > which apply to the last /8 will become permanent fixtures applying to all > future address space after depletion. Perhaps they won't apply to a huge > amount of address space, but there will be a constant and small turnover of > address blocks reclaimed by the RIPE NCC for the foreseeable future. > > Turns out, this is a pretty fundamental change. We had, as a community, > created a last /8 policy because we believed that there was something > special about the addresses in the bottom of the barrel. Then we realised > that there would be a permanent small trickle of addresses into this barrel > and that there was really no such thing as the "last /8". I totally agree. It is one thing to reserve a certain pool to be handled in a special way (like the /16 for IXPs) but to have a policy claiming new rules on all IPv4 space no matter what, does not make sense to me. > In a roundabout sort of way, this policy floats the idea that the entire > concept of the last /8 being special is slightly artificial, and that > really they're not "special" addresses, they're just "addresses". Same as > all the other addresses we've assigned, allocated and used all along. > > The only difference we've really made is that we've narrowed the mouth of > the toothpaste tube so that more people might be able to get a taste. > > Taking a slightly different viewpoint, 2012-04 makes the last /8 policy > more similar to the "run out fairly" model, except that instead of limiting > on the basis of expected use within X months, we're putting some hard > limits in. Yes. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From stolpe at resilans.se Tue May 8 10:47:54 2012 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 8 May 2012 10:47:54 +0200 (CEST) Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: Message-ID: Very well put Remco. Thank you for speaking up. On Mon, 7 May 2012, Remco Van Mook wrote: > > > > Alright then, for the sake of argument I'll oppose until I see some > convincing numbers. Back in the original last /8 discussion the rationale > for choosing a /22 was that it would get us about 16k final allocations, > or 1 for every NCC member and room for the membership to double in size. > Now, we have a number of new realities: > > - final /8 applies to all v4 address space when it kicks in, including > space that gets returned later; > - It also applies to v4 address space that has not been allocated or > assigned by RIPE NCC at that date; > - An additional 'special case' block was set aside for IXPs. > > This all impacts, in a positive or negative way, how much future there is > in our final /8 policy. I'd like to think that we made a well-considered > decision back then, and if we're going to make a fundamental change like > this one I'd like to see some numbers in an impact analysis. Based on > current distribution, how much space do we anticipate will fall under the > final /8 policy, how much of it will be allocated in /22 PA and how much > will be allocated in /24 PI? Given the 'one size fits nobody' nature of > the final /8 policy, this would be about the number of > allocations/assignments done so far, not the size. > > Personally I'm rather sick and tired of hearing people say 'yes, let's > break IPv4 so we all MUST move to IPv6'. If you think this is good policy > or even good engineering, please think again. It will make us end up with > a broken internet that, surprise, we won't be managing any more. Breaking > IPv4 might lead to increased IPv6 adoption, but not on the internet as we > know it today. Everybody who wants to connect his organisation to the > internet is going to need at least some IPv4 address space for the time > being, so why screw it up for new entrants? > > Finally, I would like to hear how this proposal correlates to the charge > for PI space - the good old 2007-01 chestnut. For post-depletion LIRs, the > grapes would be quite sour if one could pick up a quarter of the available > resources for about one twentieth of the price. Should "Final /8 PIv4" > have a separate price tag? > > Best > > Remco > > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. > > Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From erik at bais.name Tue May 8 11:23:17 2012 From: erik at bais.name (Erik Bais) Date: Tue, 8 May 2012 11:23:17 +0200 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> > You can find the full proposal at: > https://www.ripe.net/ripe/policies/proposals/2011-05 > Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 9 May 2012. I have 1 question before the last-call ends tomorrow. . . In the grand scheme of things and also seeing the other policies popping up for trying to divide whatever is going to be left from the final /8. If we all think that this reservation is a good thing for the good of the internet ... (And I agree on the reasoning) is reserving only a /16 from the final /8 enough? 65k /24's are in the last /8 ... and for future IXP's we 'only' reserve a /16 (256 /24's ) I would rather see that increased to a /14 if possible. Regards, Erik Bais From gert at space.net Tue May 8 11:32:21 2012 From: gert at space.net (Gert Doering) Date: Tue, 8 May 2012 11:32:21 +0200 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> Message-ID: <20120508093221.GX84425@Space.Net> Hi, On Tue, May 08, 2012 at 11:23:17AM +0200, Erik Bais wrote: > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2011-05 > > Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 9 May 2012. > > I have 1 question before the last-call ends tomorrow. . . > > In the grand scheme of things and also seeing the other policies popping up for trying to divide whatever is going to be left from the final /8. > > If we all think that this reservation is a good thing for the good of the internet ... (And I agree on the reasoning) is reserving only a /16 from the final /8 enough? > > 65k /24's are in the last /8 ... and for future IXP's we 'only' reserve a /16 (256 /24's ) > > I would rather see that increased to a /14 if possible. Formally, we can't change anything "just so" at this point in the PDP - so we'd have to go back to review phase, draft a new policy text, and then re-do review phase and last call. If you think this is important enough, please formally voice "strong and sustained opposition" - which is what it takes to bounce the proposal back to review phase. OTOH, since this came from the EIX WG, I think they have a pretty good idea on the number of IXPs to be expected world-wide, and how much growth to expect there over the next 5-10 years. Since they seem to be happy with the proposal as it stands, with a /16, and the constraints that this brings with it (= 256 new small IXPs, or 128 new IXPs with a /23, etc.), I would prefer to accept their assumptions and go forward. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From turchanyi.geza at gmail.com Tue May 8 11:50:23 2012 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 8 May 2012 11:50:23 +0200 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20120508093221.GX84425@Space.Net> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> <20120508093221.GX84425@Space.Net> Message-ID: Hi Gert, I fully aggree with your arguments this time. Best, Geza On Tue, May 8, 2012 at 11:32 AM, Gert Doering wrote: > Hi, > > On Tue, May 08, 2012 at 11:23:17AM +0200, Erik Bais wrote: > > > You can find the full proposal at: > > > https://www.ripe.net/ripe/policies/proposals/2011-05 > > > Please e-mail any final comments about this proposal to > address-policy-wg at ripe.net before 9 May 2012. > > > > I have 1 question before the last-call ends tomorrow. . . > > > > In the grand scheme of things and also seeing the other policies popping > up for trying to divide whatever is going to be left from the final /8. > > > > If we all think that this reservation is a good thing for the good of > the internet ... (And I agree on the reasoning) is reserving only a /16 > from the final /8 enough? > > > > 65k /24's are in the last /8 ... and for future IXP's we 'only' reserve > a /16 (256 /24's ) > > > > I would rather see that increased to a /14 if possible. > > Formally, we can't change anything "just so" at this point in the PDP - so > we'd have to go back to review phase, draft a new policy text, and then > re-do review phase and last call. > > If you think this is important enough, please formally voice "strong and > sustained opposition" - which is what it takes to bounce the proposal > back to review phase. > > OTOH, since this came from the EIX WG, I think they have a pretty good > idea on the number of IXPs to be expected world-wide, and how much growth > to expect there over the next 5-10 years. Since they seem to be happy > with the proposal as it stands, with a /16, and the constraints that this > brings with it (= 256 new small IXPs, or 128 new IXPs with a /23, etc.), > I would prefer to accept their assumptions and go forward. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Tue May 8 12:25:30 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 08 May 2012 12:25:30 +0200 Subject: [address-policy-wg] Ratification of the Global Policy Proposal 2011-01, "Global Policy for post, exhaustion IPv4 allocation mechanisms by the IANA" Message-ID: <4FA8F49A.40603@ripe.net> Dear colleagues, The Global Policy Proposal 2011-01, "Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA" was accepted by the RIPE community in October 2011. The ICANN Board recently ratified the global policy proposal. The resolution is now available at: http://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm The new RIPE document is ripe-529 and is available at: http://www.ripe.net/ripe/docs/ripe-529 Best regards, Emilio Madaio Policy Development Officer RIPE NCC From ebais at a2b-internet.com Tue May 8 12:31:25 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 8 May 2012 12:31:25 +0200 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20120508093221.GX84425@Space.Net> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> <20120508093221.GX84425@Space.Net> Message-ID: <005e01cd2d05$b8a8d090$29fa71b0$@a2b-internet.com> Hi Gert, > > I would rather see that increased to a /14 if possible. > Formally, we can't change anything "just so" at this point in the PDP - so we'd have to go back to review phase, draft a new policy text, and then re-do review phase and last call. > If you think this is important enough, please formally voice "strong and sustained opposition" - which is what it takes to bounce the proposal back to review phase. > OTOH, since this came from the EIX WG, I think they have a pretty good idea on the number of IXPs to be expected world-wide, and how much growth to expect there over the next 5-10 years. Since they seem to be happy with the proposal as it stands, > with a /16, and the constraints that this brings with it (= 256 new small IXPs, or 128 new IXPs with a /23, etc.), I would prefer to accept their assumptions and go forward. I do think that it is important, however if the EIX WG agrees that 'a /16 ought to be enough for all future IXP's in the region.', I would like to see that stated on the list here and I'm happy. My personal (gut) feeling about it, is that a /16 isn't going to last very long and seeing a policy on the roll that could allow PI on that same last /8, it might be better to adjust now, rather than being sorry later. Regards, Erik Bais From randy at psg.com Tue May 8 17:09:05 2012 From: randy at psg.com (Randy Bush) Date: Tue, 08 May 2012 08:09:05 -0700 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4FA82065.6050407@inex.ie> References: <4FA82065.6050407@inex.ie> Message-ID: >> Alright then, for the sake of argument I'll oppose until I see some >> convincing numbers. Back in the original last /8 discussion the rationale >> for choosing a /22 was that it would get us about 16k final allocations, >> or 1 for every NCC member and room for the membership to double in size. > we need to move away from this idea of how to expand the RIPE NCC > membership and think more in terms of how to serve the RIPE community. while i definitely agree with your statement, i that is not how i took remco's comment. i see the final /8 policy (i as an author of the equivalent in apnic) as a fairness issue, trying to ensure there is space for new entrants, after we old hogs gobbled so much of it up. randy From nick at inex.ie Tue May 8 17:24:39 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 08 May 2012 16:24:39 +0100 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: References: <4FA82065.6050407@inex.ie> Message-ID: <4FA93AB7.4050903@inex.ie> On 08/05/2012 16:09, Randy Bush wrote: > i see the final /8 policy (i as an author of the equivalent in apnic) as > a fairness issue, trying to ensure there is space for new entrants, > after we old hogs gobbled so much of it up. There is no fairness in an environment of scarcity. There are only degrees of unfairness. Nick From tore.anderson at redpill-linpro.com Tue May 8 18:02:15 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 08 May 2012 18:02:15 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4FA8C726.9030309@redpill-linpro.com> References: <4FA8C726.9030309@redpill-linpro.com> Message-ID: <4FA94387.3080505@redpill-linpro.com> * Tore Anderson > I don't make the claim that these numbers necessarily are meaningful or > even relevant to the discussion, though. You be the judge of that... Perhaps it is more interested in looking at how things have gone in the APNIC region so far; They started delegating from their last /8 block 386 days ago. Since then they've handed out 1,048,320 addresses from 103/8, or 6.25% of it. Of those 1,048,320 addresses, 173,312 (16.53%) were assigned, and 875,008 (83.47%) were allocated. Out of a total 1,253 delegations, 361 (28.81%) were assignments, while 892 (71.19%) were allocations. (I've disregarded their debogon prefix delegations. Also last /8 delegations made from outside 103/8, if any, aren't counted.) I'm not familiar enough with APNIC's policies regarding the definition of "assignment" vs "allocation" to know whether or not this is relevant to this discussion or not, but if they're roughly the same as in the RIPE region, the APNIC numbers seems to me to indicate that allowing assignments from the last /8 will not dramatically reduce its longevity. Which in turn is enough for me to support allowing PI assignments under our last /8 policy. It's also worth noting, perhaps, that in the APNIC region both allocations and assignments appear to be capped at a /22. 2012-04 proposes capping PI at a /24, which I suppose may further diminish concerns that allowing PI in the first place will make the last /8 go away too quickly. On the other hand, limiting PI at /24 but PA at /22 would still cause the effect of forcing organisations to become LIRs, if the organisation's requirement cannot be fulfilled with a /24 only. That's kind of pointless, if the only assignment they'll ever make as LIRs is to their own organisation. So I think it would be even better if we did like APNIC did and capped both PI and PA at a /22 - that way, all the internet organisations in the region gets to have life rafts of the exact same size. (But perhaps they should be equally priced also...) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From chrish at consol.net Tue May 8 18:08:13 2012 From: chrish at consol.net (chrish at consol.net) Date: Tue, 08 May 2012 18:08:13 +0200 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20120508093221.GX84425@Space.Net> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> <20120508093221.GX84425@Space.Net> Message-ID: <4FA944ED.5090405@consol.net> hi! On 05/08/2012 11:32 AM, Gert Doering wrote: > If you think this is important enough, please formally voice "strong and > sustained opposition" - which is what it takes to bounce the proposal > back to review phase. hmm - just to make sure: i formally voice strong and sustained opposition towards 2011-05. regards, Chris From andy at nosignal.org Tue May 8 20:53:31 2012 From: andy at nosignal.org (Andy Davidson) Date: Tue, 8 May 2012 19:53:31 +0100 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> Message-ID: <5E46ED67-D720-4F23-9639-019DC5E399EB@nosignal.org> On 8 May 2012, at 10:23, Erik Bais wrote: > In the grand scheme of things and also seeing the other policies popping up for trying to divide whatever is going to be left from the final /8. > > If we all think that this reservation is a good thing for the good of the internet ... (And I agree on the reasoning) is reserving only a /16 from the final /8 enough? > > 65k /24's are in the last /8 ... and for future IXP's we 'only' reserve a /16 (256 /24's ) > > I would rather see that increased to a /14 if possible. This was discussed at the eix-wg and address-policy in Vienna. There are 133 known IXPs in Europe (according to Euro-IX) at the moment, and whilst we would all love to see more and more regional peering, the consideration was that reserving addressing room for another ~200 IXPs (in the European region) ... before IPv6 is prevalent ... is acceptable. I trust this answers your concern ? In summary this is a valid question, but it was considered at the time the proposal was drafted. And, if we run out of space for new IXPs before v6 prevalence, then whither the very internet, my colleagues ? Andy Davidson (EIX-WG Co-chair, 2011-05 author, IXP operator) From ebais at a2b-internet.com Tue May 8 21:49:33 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 8 May 2012 21:49:33 +0200 Subject: [address-policy-wg] [policy-announce] 2011-05 Last Call for Comments (Safeguarding future IXPs with IPv4 space) In-Reply-To: <5E46ED67-D720-4F23-9639-019DC5E399EB@nosignal.org> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5658@EXVS002.netsourcing.lan> <5E46ED67-D720-4F23-9639-019DC5E399EB@nosignal.org> Message-ID: <004701cd2d53$b13505b0$139f1110$@a2b-internet.com> Hi Andy, > This was discussed at the eix-wg and address-policy in Vienna. There are 133 known IXPs in Europe (according to Euro-IX) at the moment, and whilst we would all love to see more and more regional peering, the consideration was that > reserving addressing room for another ~200 IXPs (in the European region) ... before IPv6 is prevalent ... is acceptable. > I trust this answers your concern ? In summary this is a valid question, but it was considered at the time the proposal was drafted. Yes it does. > And, if we run out of space for new IXPs before v6 prevalence, then whither the very internet, my colleagues ? :-) Thanks for the answer. Regards, Erik Bais From jrabier at ilico.org Wed May 9 09:14:52 2012 From: jrabier at ilico.org (Julien Rabier) Date: Wed, 9 May 2012 09:14:52 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <20120507141927.BD2DE71216@flexiden.org> References: <20120507141927.BD2DE71216@flexiden.org> Message-ID: <20120509071452.GC5536@fdn.flexiden.org> Le 07 mai ? 16:18, Emilio Madaio a ?crit : > > Dear Colleagues, > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-04 > > We encourage you to review this proposal and send your comments to > before 4 June 2012. Hello, I support this proposal. Julien From emadaio at ripe.net Wed May 9 15:02:46 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 09 May 2012 15:02:46 +0200 Subject: [address-policy-wg] 2012-02 New Policy Proposal (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: Dear colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2012-02 We encourage you to review this proposal and send your comments to before 6 june 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From chrish at consol.net Wed May 9 15:29:00 2012 From: chrish at consol.net (chrish at consol.net) Date: Wed, 09 May 2012 15:29:00 +0200 Subject: [address-policy-wg] 2012-02 New Policy Proposal (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <201205091303.q49D3B8F011328@gw1.consol.de> References: <201205091303.q49D3B8F011328@gw1.consol.de> Message-ID: <4FAA711C.1090008@consol.net> hi! On 05/09/2012 03:02 PM, Emilio Madaio wrote: > http://www.ripe.net/ripe/policies/proposals/2012-02 this proposal doesn't fit with the current hierarchical structure of rirs and lirs. if this hierarchical structure is to be changed, this would be an essential change. introducing such a change in just a subordinate procedure isn't the way to go. i can't see a justification or explanation why the rir/lir hierarchical structure should be changed. furthermore this proposal is incompatible with policy - with the current one, and as it doesn't change the incompatibilities also with the proposed changed policy. i don't think it's reasonable to try to drop the primacy of fair and according to need distribution of ip-space. as the readers of this ml certainly know, the proposed change is actually meant to facilitate the trade of ips, this way implying (well - trying to imply) the change to ips as an asset (with a plethora of further adverse consequences). i formally voice strong and sustained opposition. i'd suggest that inter-rir transfers simply take the canonical way: from current lir, back to current lir's rir, to target lir's rir, to the target lir. regards, Chris From Remco.vanMook at eu.equinix.com Wed May 9 15:50:22 2012 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Wed, 9 May 2012 14:50:22 +0100 Subject: [address-policy-wg] 2012-02 New Policy Proposal (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <4FAA711C.1090008@consol.net> Message-ID: Dear Chris, Your objection to the current transfer policy as accepted by the RIPE community is noted. However, I don't think it relates to this policy proposal. If you feel strongly about changing (or removing, for that matter) the current transfer policy, I suggest you launch a separate policy proposal to do just that. Kind regards, Remco van Mook Director of Interconnection, EMEA remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 09-05-12 15:29, "chrish at consol.net" wrote: >hi! > >On 05/09/2012 03:02 PM, Emilio Madaio wrote: >> http://www.ripe.net/ripe/policies/proposals/2012-02 > >this proposal doesn't fit with the current hierarchical structure of rirs >and lirs. if this hierarchical structure is to be changed, this would be >an essential change. introducing such a change in just a subordinate >procedure isn't the way to go. >i can't see a justification or explanation why the rir/lir hierarchical >structure should be changed. > >furthermore this proposal is incompatible with policy - with the current >one, and as it doesn't change the incompatibilities also with the >proposed changed policy. >i don't think it's reasonable to try to drop the primacy of fair and >according to need distribution of ip-space. > >as the readers of this ml certainly know, the proposed change is actually >meant to facilitate the trade of ips, this way implying (well - trying to >imply) the change to ips as an asset (with a plethora of further adverse >consequences). > >i formally voice strong and sustained opposition. > >i'd suggest that inter-rir transfers simply take the canonical way: from >current lir, back to current lir's rir, to target lir's rir, to the >target lir. > >regards, > > Chris > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From james.blessing at despres.co.uk Wed May 9 15:57:06 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 9 May 2012 14:57:06 +0100 Subject: [address-policy-wg] 2012-02 New Policy Proposal (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <4FAA711C.1090008@consol.net> References: <201205091303.q49D3B8F011328@gw1.consol.de> <4FAA711C.1090008@consol.net> Message-ID: On 9 May 2012 14:29, wrote: > hi! > > On 05/09/2012 03:02 PM, Emilio Madaio wrote: >> ? ? http://www.ripe.net/ripe/policies/proposals/2012-02 > > this proposal doesn't fit with the current hierarchical structure of rirs and lirs. if this hierarchical structure is to be > changed, this would be an essential change. introducing such a change in just a subordinate procedure isn't the way to > go. > i can't see a justification or explanation why the rir/lir hierarchical structure should be changed. Hi, This policy only uses the existing to transfer policy for a transfer between two LIRs within a region to allow an Inter-regional transfer of addresses. If you have objects to the concept of transfers then you need to address the current transfer process rather than this extension. J -- James Blessing 07989 039 476 From frettled at gmail.com Wed May 9 16:04:15 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 9 May 2012 16:04:15 +0200 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4FA94387.3080505@redpill-linpro.com> References: <4FA8C726.9030309@redpill-linpro.com> <4FA94387.3080505@redpill-linpro.com> Message-ID: On Tue, May 8, 2012 at 6:02 PM, Tore Anderson < tore.anderson at redpill-linpro.com> wrote: > It's also worth noting, perhaps, that in the APNIC region both > allocations and assignments appear to be capped at a /22. 2012-04 > proposes capping PI at a /24, which I suppose may further diminish > concerns that allowing PI in the first place will make the last /8 go > away too quickly. On the other hand, limiting PI at /24 but PA at /22 > would still cause the effect of forcing organisations to become LIRs, if > the organisation's requirement cannot be fulfilled with a /24 only. > That's kind of pointless, if the only assignment they'll ever make as > LIRs is to their own organisation. So I think it would be even better if > we did like APNIC did and capped both PI and PA at a /22 - that way, all > the internet organisations in the region gets to have life rafts of the > exact same size. (But perhaps they should be equally priced also...) > I like your reasoning. Regarding the parenthetical comment, I think it would be sane if there was a slightly less-than-proportionate price increase going from /24 to /22, and that this was decoupled from the whole PI/PA choice. Maybe it should cost more to be a LIR, but I think that is a different issue than the address block size. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Thu May 10 14:49:40 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 10 May 2012 14:49:40 +0200 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) Message-ID: Dear Colleagues A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2012-03 We encourage you to review this proposal and send your comments to before 7 June 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From chrish at consol.net Thu May 10 15:07:16 2012 From: chrish at consol.net (Chris) Date: Thu, 10 May 2012 15:07:16 +0200 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: <201205101250.q4ACo5r7005752@gw1.consol.de> References: <201205101250.q4ACo5r7005752@gw1.consol.de> Message-ID: <4FABBD84.4000009@consol.net> hi! On 05/10/2012 02:49 PM, Emilio Madaio wrote: > http://www.ripe.net/ripe/policies/proposals/2012-03 i believe the current policy allowing intra-rir-transfers from lir to lir under identical provisions as regular allocations is just and the way to go. as mentioned before, i also don't regard the attempts to pirate the ip-commons as legitimiate, and this proposal's only effect seems to be to make the anticipated 'owned-ip-product' more attractive than the 'competing product'. i formally voice strong and sustained opposition. regards, Chris From Remco.vanMook at eu.equinix.com Thu May 10 15:17:53 2012 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 10 May 2012 14:17:53 +0100 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: <4FABBD84.4000009@consol.net> Message-ID: Dear Chris, Your objection to the current transfer policy as accepted by the RIPE community is noted, again. However, I don't think it relates to this policy proposal either, as this merely removes an unintended consequence introduced by the run out fairly policy. The current text of the transfer policy remains unchanged and is therefore out of scope for this proposal. If you feel strongly about changing (or removing, for that matter) the current transfer policy in another way, I suggest you launch a separate policy proposal to do just that. Kind regards, Remco van Mook Director of Interconnection, EMEA remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 10-05-12 15:07, "Chris" wrote: >hi! > >On 05/10/2012 02:49 PM, Emilio Madaio wrote: >> http://www.ripe.net/ripe/policies/proposals/2012-03 > >i believe the current policy allowing intra-rir-transfers from lir to lir >under identical provisions as regular allocations is just and the way to >go. > >as mentioned before, i also don't regard the attempts to pirate the >ip-commons as legitimiate, and this proposal's only effect seems to be to >make the anticipated 'owned-ip-product' more attractive than the >'competing product'. > >i formally voice strong and sustained opposition. > >regards, > > Chris This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From frettled at gmail.com Thu May 10 15:39:31 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 10 May 2012 15:39:31 +0200 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: On Thu, May 10, 2012 at 2:49 PM, Emilio Madaio wrote: > > > Dear Colleagues > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2012-03 > If I understand the rationale correctly, the change essentially means that a LIR has more time to actually implement a use of a transferred block, than they have for a new block. I am a n00b at these matters, but I don't quite see why this is an important change, and why as much as 24 months is necessary. Could someone please try to enlighten me? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Thu May 10 17:02:30 2012 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 10 May 2012 17:02:30 +0200 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: On Thu, May 10, 2012 at 3:39 PM, Jan Ingvoldstad wrote: > On Thu, May 10, 2012 at 2:49 PM, Emilio Madaio wrote: >> >> >> >> Dear Colleagues >> >> A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation >> and Assignment Policy for the RIPE NCC Service Region", is now >> available for discussion. >> >> >> >> You can find the full proposal at: >> >> ? ?http://www.ripe.net/ripe/policies/proposals/2012-03 > > > If I understand the rationale correctly, the change essentially means that a > LIR has more time to actually implement a use of a transferred block, than > they have for a new block. > > I am a n00b at these matters, but I don't quite see why this is an important > change, and why as much as 24 months is necessary. > > Could someone please try to enlighten me? wild guess... you got 24months to sell it to someone else? :-) -- Roger Jorgensen? ? ? ? ???| ROJO9-RIPE rogerj at gmail.com? ? ? ?? ?| - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From james.blessing at despres.co.uk Thu May 10 17:14:56 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 10 May 2012 16:14:56 +0100 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: On 10 May 2012 14:39, Jan Ingvoldstad wrote: > If I understand the rationale correctly, the change essentially means that a > LIR has more time to actually implement a use of a transferred block, than > they have for a new block. > > I am a n00b at these matters, but I don't quite see why this is an important > change, and why as much as 24 months is necessary. 24 months was the original time-period for networks to show their networking requirements before the run-out fairly proposals were introduced and it was an attempt to return to those number for transfers rather than have lots of little ones... J -- James Blessing 07989 039 476 From maildanrl at googlemail.com Thu May 10 18:40:48 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Thu, 10 May 2012 18:40:48 +0200 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: Hi, I may go off topic with this, but I have the strong feeling that more and more policies are coming up that regulate and re-regulate transfers (intra-RIR, inter-RIR) becoming more and more specific. I spent less than a year on this mailing list, and I do not know if this is business-as-usual or if this is new, but sometimes I fear we might one day over-regulate things. Maybe it's just me fearing bureaucracy :) Back to topic: The discussion will be interesting! At the moment I find 24 months way to long. best regards, Dan -- Dan Luedtke http://www.danrl.de From randy at psg.com Fri May 11 04:16:23 2012 From: randy at psg.com (Randy Bush) Date: Thu, 10 May 2012 16:16:23 -1000 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: > I fear we might one day over-regulate things. 1999.04.17 randy From erik at bais.name Fri May 11 11:37:32 2012 From: erik at bais.name (Erik Bais) Date: Fri, 11 May 2012 11:37:32 +0200 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5662@EXVS002.netsourcing.lan> Hi Randy, >> I fear we might one day over-regulate things. > 1999.04.17 Perhaps you can explain a bit more by the cryptic post and 'guide the blind'. (??????? (hom?re??)) Erik (who didn't read any ancient Greek teachings) http://bmcr.brynmawr.edu/1999/1999-04-17.html http://en.wikipedia.org/wiki/Homer From randy at psg.com Fri May 11 19:56:04 2012 From: randy at psg.com (Randy Bush) Date: Fri, 11 May 2012 07:56:04 -1000 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5662@EXVS002.netsourcing.lan> References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5662@EXVS002.netsourcing.lan> Message-ID: >>> I fear we might one day over-regulate things. >> 1999.04.17 > Perhaps you can explain a bit more the date was somewhat arbitrary. imiho, we stepped over the line to picayune regulation long ago. randy From nick at inex.ie Mon May 14 20:39:40 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 14 May 2012 19:39:40 +0100 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> Message-ID: <4FB1516C.2040305@inex.ie> On 10/05/2012 17:40, Dan Luedtke wrote: > is business-as-usual or if this is new, but sometimes I fear we might > one day over-regulate things. The question is not whether "we might", but how it will happen, who makes the rules and what rules we end up with. Over-regulation of the Internet is as sure an eventuality in future times as over-regulation of the telcos or over-regulation of the railways in previous eras. Nick From matthew.hattersley at vaioni.com Tue May 15 10:55:08 2012 From: matthew.hattersley at vaioni.com (Matthew Hattersley) Date: Tue, 15 May 2012 08:55:08 +0000 Subject: [address-policy-wg] 2012-03 New Policy Proposal (Intra-RIR Transfer Policy Proposal) In-Reply-To: <4FB1516C.2040305@inex.ie> References: <4fabb98b.86650e0a.3d73.6cc6SMTPIN_ADDED@mx.google.com> <4FB1516C.2040305@inex.ie> Message-ID: <68586C82C4B9CE47B4DD16FBDBC622A318B6AFF8@DBXPRD0610MB358.eurprd06.prod.outlook.com> > Over-regulation of the Internet is as > sure an eventuality in future times as over-regulation of the telcos or over- > regulation of the railways in previous eras. Any large body suffers this, until such time as the regulation constricts the ability of the body in question to function. Followed by a big reboot of the whole process or in the case of governments a revolution. I think RIPE is a fair way off this however. I think in all likelihood we'll be living with over regulation for some time to come. The information transmitted in and with this email is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the Company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. Please also note, Vaioni filter incoming email for spam and inappropriate words. Unfortunately this does mean that sometimes genuine messages can be filtered out. Although we take measures to recover such messages, it must not be assumed that an email has been received by us and important communications should always be followed up by a phone call, fax or printed copy. From jaap at NLnetLabs.nl Wed May 16 11:16:39 2012 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 16 May 2012 11:16:39 +0200 Subject: [address-policy-wg] FYI: ICANN News Alert -- Ratification of Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by the IANA Message-ID: <201205160916.q4G9Gdvu032439@bela.nlnetlabs.nl> This might be of some interest for this group. jaap ICANN News Alert http://www.icann.org/en/news/announcements/announcement-15may12-en.htm ____________________________________ Ratification of Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by the IANA 15 May 2012 The ICANN Board has ratified the Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by the IANA as sent by the Address Supporting Organization (ASO) Council to the ICANN Board on 13 March 2012. The proposal was posted for public comment from 14 March 2012 through 4 April 2012, during which time no comments were submitted. The Global Policy allows the Regional Internet Registries to return IPv4 address space to an IANA-managed pool from which equal parts will be allocated to all five RIRs in a deterministic manner on a regular schedule, once triggered. (http://www.icann.org/en/news/in-focus/global-addressing/allocation-ipv4-post-exhaustion). ICANN staff will be taking all necessary steps to implement the Global Policy. From andy at nosignal.org Mon May 21 10:57:59 2012 From: andy at nosignal.org (Andy Davidson) Date: Mon, 21 May 2012 09:57:59 +0100 Subject: [address-policy-wg] 2012-04 New Policy Proposal (PI Assignments from the last /8) In-Reply-To: <4FA7F11E.9010509@go6.si> References: <681253007.20120507162707@devnull.ru> <4FA7F11E.9010509@go6.si> Message-ID: <1B41A78F-ABC3-4411-8D50-7B53EF2335E2@nosignal.org> On 7 May 2012, at 16:58, Jan Zorz @ go6.si wrote: > On 5/7/12 4:27 PM, Sergey Myasoedov wrote: >> >> Regarding using last /8 for PI assignments, this proposal looks fair to me. > > Agree. Lets distribute the leftovers and be done with this for good, so people could focus on important things (such as IPv6 deployment :) ) +1 At the current run-rate, how long would PI from the final /8 be available ? Is it considered desirable by the community to any space whatsoever of the final /8 for PA, so that new LIRs can form and be given any v4 for a period of time longer than the anticipated run rate ? My mind is not made up on the subject yet, though I am erring on the side of 'no' because after some consideration, I think that v6 is the only long-term answer, and that stalling tactics are all very interesting to discuss. Andy From pascal.gloor at finecom.ch Tue May 22 15:15:47 2012 From: pascal.gloor at finecom.ch (Pascal Gloor) Date: Tue, 22 May 2012 13:15:47 +0000 Subject: [address-policy-wg] Assignment transfer among LIR Message-ID: Dear WG, As a service provider specialized in CATV, we will soon face a competition problem. CATV operators, often, do not operate their IP business, they take these services from a specialized service provider (like us) and therefore the end-users get IP(v4) addresses from that provider. In the future, CATV operators will not be able to change their provider because the new provider will be unable to assign IPv4 space to them. On the other side, there is no need for additional IPs, the CATV operator already has them (from another LIR). If we do not solve this issue, this market will simply and completely freeze, giving way too much power to the 'current' provider (like us) over the CATV operator. I've been thinking a lot about how to solve this issue, so I'll just throw a first pseudo-draft, give me your feedback and we'll make it better. Post-IPv4-Exhaustion customer transfer When a customer changes from LIR A to LIR B: - RIPE NCC will allocate the needed space (out of the 'reserved-for-new-LIR' space) to LIB B, but not larger than the original one. - RIPE NCC will inform LIR A about the transfer and will request the space to be returned. - If LIR A cannot return the space (deaggregation?), RIPE NCC will freeze (how?) it. NOTE: There should maybe be a minimal assignment size for this process, maybe /22. (Why? To avoid a flood of very small assignments transfer requests to RIPE NCC). Let me know what you think, how it can be improved or if you think its BS. Cheers, Pascal From james.blessing at despres.co.uk Tue May 22 15:25:37 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 22 May 2012 14:25:37 +0100 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: On 22 May 2012 14:15, Pascal Gloor wrote: > > Let me know what you think, how it can be improved or if you think its BS. Why not just use IPv6... J -- James Blessing 07989 039 476 From pascal.gloor at finecom.ch Tue May 22 15:33:56 2012 From: pascal.gloor at finecom.ch (Pascal Gloor) Date: Tue, 22 May 2012 13:33:56 +0000 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: Message-ID: >Why not just use IPv6... Using IPv6 does not remove the need of v4, you know that. Plus, my proposal is not about using more v4, but just about keeping the same number of v4 and being able to change ISP. Transforming the PA into PI and allowing the transfer could also be a solution but I don't like it due to possible massive deaggregation. Pascal From james.blessing at despres.co.uk Tue May 22 15:43:34 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 22 May 2012 14:43:34 +0100 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: On 22 May 2012 14:33, Pascal Gloor wrote: >>Why not just use IPv6... > > Using IPv6 does not remove the need of v4, you know that. Plus, my > proposal is not about using more v4, but just about keeping the same > number of v4 and being able to change ISP. Transforming the PA into PI and > allowing the transfer could also be a solution but I don't like it due to > possible massive deaggregation. Really, isn't CATV a closed access network that you have control off? Could you do 6to4 (or something similar) at the border if you need to access v4 content? Or have I misunderstood what you are doing? J -- James Blessing 07989 039 476 From pascal.gloor at finecom.ch Tue May 22 16:18:15 2012 From: pascal.gloor at finecom.ch (Pascal Gloor) Date: Tue, 22 May 2012 14:18:15 +0000 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: Message-ID: >Really, isn't CATV a closed access network that you have control off? >Could you do 6to4 (or something similar) at the border if you need to >access v4 content? Or have I misunderstood what you are doing? 6to4 is IPv6 tunnel over IPv4, not the other way around, what you mean is DNS46/NAT46 which is outdated, maybe 6rd or MAP46 (which is not yet really available). But that's not the point. My point is about post-v4-exhaustion policy, not about transition technologies, nor about lack of v4. It's about keeping the customer assigned v4 space (and not even the IPs, just the assignment size). Pascal From nick at inex.ie Tue May 22 16:47:15 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 May 2012 15:47:15 +0100 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: <4FBBA6F3.3030805@inex.ie> On 22/05/2012 14:15, Pascal Gloor wrote: > - RIPE NCC will allocate the needed space (out of the > 'reserved-for-new-LIR' space) to LIB B, but not larger than the original > one. > - RIPE NCC will inform LIR A about the transfer and will request the > space to be returned. > - If LIR A cannot return the space (deaggregation?), RIPE NCC will freeze > (how?) it. Pascal, Difficult to implement in practice, because ip addresses are assigned under specific conditions and changing them retrospectively is Hard. Specifically, the two problems that I see are that if LIR A has assigned a bunch of IP addresses to a customer: 1. LIR A will not want to lose those IP addresses because in the ipv4 depletion era, they will have nominal trading value. 2. LIR A will also want to use them for customer stickiness. So if the customer moves to LIR B, then there are two policy options for customers in that situation: a) convert all PA space to PI space b) leave as-is Difficult to see how scenario a could be achieved legally. And in scenario b, LIR A may use the IP addresses either to keep the customer or else to charge them a fortune for departing with those IP addresses. The value will be determined to some extent by the going market rate for IP addresses + the nominal cost of getting the customer to renumber. Not cheap, and highly prone to abuse. IOW, I don't see any clear solutions to this problem for existing contracts. Nick From james.blessing at despres.co.uk Tue May 22 16:53:56 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 22 May 2012 15:53:56 +0100 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: On 22 May 2012 15:18, Pascal Gloor wrote: >>Really, isn't CATV a closed access network that you have control off? >>Could you do 6to4 (or something similar) at the border if you need to >>access v4 content? Or have I misunderstood what you are doing? > > 6to4 is IPv6 tunnel over IPv4, not the other way around, what you mean is > DNS46/NAT46 which is outdated, maybe 6rd or MAP46 (which is not yet really > available). My bad, I was thinking Stateless NAT64 (aka SIIT) > But that's not the point. My point is about post-v4-exhaustion policy, not > about transition technologies, nor about lack of v4. It's about keeping > the customer assigned v4 space (and not even the IPs, just the assignment > size). but why are you trying to keep it on IPv4 and not moving to v6 J -- James Blessing 07989 039 476 From jan at go6.si Tue May 22 16:56:18 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 22 May 2012 16:56:18 +0200 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: <4FBBA6F3.3030805@inex.ie> References: <4FBBA6F3.3030805@inex.ie> Message-ID: <4FBBA912.90600@go6.si> On 5/22/12 4:47 PM, Nick Hilliard wrote: > IOW, I don't see any clear solutions to this problem for existing contracts. +1 Probably all those CATV operators should be LIRs in the first place anyway. Cheers, Jan From nick at inex.ie Tue May 22 16:57:09 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 May 2012 15:57:09 +0100 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: <4FBBA945.40802@inex.ie> On 22/05/2012 15:53, James Blessing wrote: > but why are you trying to keep it on IPv4 and not moving to v6 - because ipv6 does not yet have a critical mass - because v6 cpe kit still mostly blows - etc Nick From nick at inex.ie Tue May 22 16:57:39 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 May 2012 15:57:39 +0100 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: <4FBBA912.90600@go6.si> References: <4FBBA6F3.3030805@inex.ie> <4FBBA912.90600@go6.si> Message-ID: <4FBBA963.7000607@inex.ie> On 22/05/2012 15:56, Jan Zorz @ go6.si wrote: > Probably all those CATV operators should be LIRs in the first place anyway. yes. They should. Nick From Tero.Toikkanen at nebula.fi Tue May 22 17:28:51 2012 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Tue, 22 May 2012 15:28:51 +0000 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: <4FBBA912.90600@go6.si> References: <4FBBA6F3.3030805@inex.ie> <4FBBA912.90600@go6.si> Message-ID: > Probably all those CATV operators should be LIRs in the first place anyway. Indeed. Running your own infra with a sub-allocation (or even worse, an assignment) from an LIR has it's risks, which you must take into account when planning your business. Even if you have a contractual agreement saying you can run off with the addresses once you're no longer buying connectivity from the LIR, it's still a risk. (I know some LIRs do allow using their address-space as practically your own, but that's only as long as the contract is valid). Also worth remembering in RIPE region is that if you're running any kind of ISP business with IPv4 PI (as in you have customers who use your addresses), you can't do the same with IPv6 PI. The policy doesn't allow that and it continues to come as a surprise to some. Therefore the only reasonable choice is to become an LIR (and plan your business so that you can afford it :-) ). ____________________________________ Tero Toikkanen Nebula Oy From pascal.gloor at finecom.ch Tue May 22 18:22:31 2012 From: pascal.gloor at finecom.ch (Pascal Gloor) Date: Tue, 22 May 2012 16:22:31 +0000 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: <4FBBA912.90600@go6.si> Message-ID: >Probably all those CATV operators should be LIRs in the first place >anyway. They could, indeed. But as they have no knowledge of IP whatsoever and do not operate any IP device, it was always easier for them that we take care of this. Some did, but they are far from a majority. > Running your own infra with a sub-allocation (or even worse, an >assignment) from an LIR has it's risks, which you must take into account >when planning your business. That is not that case (at least for our customers), we own the infrastructure (Layer2 and above), we run it (for them), they don't. Pascal From pascal.gloor at finecom.ch Tue May 22 18:26:50 2012 From: pascal.gloor at finecom.ch (Pascal Gloor) Date: Tue, 22 May 2012 16:26:50 +0000 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: <4FBBA6F3.3030805@inex.ie> Message-ID: >IOW, I don't see any clear solutions to this problem for existing >contracts. To be honest, me neither, but I wanted some community feedback to see if there would be a solution I didn't think of. I guess we can drop this now, I'll think of something more administrative/boring and less fancy. ;-) Pascal From maildanrl at googlemail.com Tue May 22 19:05:44 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Tue, 22 May 2012 19:05:44 +0200 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: <4FBBA6F3.3030805@inex.ie> Message-ID: Hello, Pascal Gloor wrote: > RIPE NCC will inform LIR A about the transfer and will request the space to be returned. Good luck with that. > I guess we can drop this now, I'll think of something more > administrative/boring and less fancy. ;-) Use IPv6, this could also be something your customer might not get from competitors at the moment. Regards. Dan -- Dan Luedtke http://www.danrl.de From jan at go6.si Tue May 22 21:40:36 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 22 May 2012 21:40:36 +0200 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: <4FBBEBB4.2040405@go6.si> On 5/22/12 6:22 PM, Pascal Gloor wrote: > That is not that case (at least for our customers), we own the > infrastructure (Layer2 and above), we run it (for them), they don't. Why moving elswhere then? Cheers, Jan From h.lu at anytimechinese.com Tue May 22 22:55:37 2012 From: h.lu at anytimechinese.com (Lu Heng) Date: Tue, 22 May 2012 22:55:37 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions Message-ID: Hi Sorry for disturbing. I have one question which I didn't find answer in the policy document. I was wondering how any-cast or uni-cast solution works with cross region possibilities. If we announcing 1.1.1.0/16 in EU, and announcing 1.1.1.0/18 in US, is it against policy? If we announcing 1.1.1.0/16 both in EU and US, is it against policy?(all IP from Ripe) Please if someone can help me clarify this. -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From slz at baycix.de Tue May 22 23:38:44 2012 From: slz at baycix.de (Sascha Lenz) Date: Tue, 22 May 2012 23:38:44 +0200 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: Hi Pascal, Hi all... > Dear WG, > > > As a service provider specialized in CATV, we will soon face a competition > problem. CATV operators, often, do not operate their IP business, they > take these services from a specialized service provider (like us) and > therefore the end-users get IP(v4) addresses from that provider. > [...] basically i share most of the concerns other people already mentioned, so i try to make it brief: I don't really see this happening, the problem is basically self-made (design failure) and not at all only a specific problem of this kind of service, let alone one that might be relevant for a policy change in general. - Change your network design, NOW (or become LIR, or get PI, or everything) - No LIR would give away a part of their allocations for free if they can get $$$ for every IP they "own" soon - There is a reason for PA not being PI, maybe historical, but it's still there (Hello Gert/chairs, reminder - you wanted to share some more thought about the idea of making this go away in the (IPv6-)future? :-) ) - IPv6 transitions methods ARE there and usable, start deploying them today, and you won't have those problems later - There's always CGN, there are CATV providers (also some DSL providers) in my area that don't guarantee you a "public IPv4 address" at all anymore already in their terms and conditions and i actually think that's a smart choice - If you really need "other IPv4 addresses" after depletion because $management is too stupid to avoid this problem, pay the price for stupidity and buy them. I'm pretty sure the policy will allow it by then. Ressource transfer (of ALLOCATIONS that is) is possible, today already. That actually should cover most bases. [...further ranting about $the_world not deploying IPv6 10years ago already deleted due to lack of relevance...] -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From sander at steffann.nl Wed May 23 07:53:56 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 23 May 2012 08:53:56 +0300 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: Message-ID: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> Hello Lu, > Sorry for disturbing. I have one question which I didn't find answer > in the policy document. The RIPE policies cover allocation and assignment. How you announce the addresses (and what other people/companies will accept from you) is out of scope for RIPE policies. The RIPE Routing WG has a recommendations on that (http://www.ripe.net/ripe/docs/ripe-399), but there is no policy. Sander From h.lu at anytimechinese.com Wed May 23 09:18:09 2012 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 23 May 2012 09:18:09 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> Message-ID: hi sander: thanks very much for replying. but if there is no policy for that, is that means people can announce their address in us or region outside ripe region(as i know some people do for their us cdn network for example)., is this also accepted in the policy? On Wed, May 23, 2012 at 7:53 AM, Sander Steffann wrote: > Hello Lu, > >> Sorry for disturbing. I have one question which I didn't find answer >> in the policy document. > > The RIPE policies cover allocation and assignment. How you announce the addresses (and what other people/companies will accept from you) is out of scope for RIPE policies. The RIPE Routing WG has a recommendations on that (http://www.ripe.net/ripe/docs/ripe-399), but there is no policy. > > Sander > -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From tore.anderson at redpill-linpro.com Wed May 23 09:40:21 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 23 May 2012 09:40:21 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> Message-ID: <4FBC9465.3030101@redpill-linpro.com> * Lu Heng > but if there is no policy for that, is that means people can announce > their address in us or region outside ripe region(as i know some > people do for their us cdn network for example)., is this also > accepted in the policy? You can announce them anywhere you like. But you cannot assign them to end users outside outside of the region. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From h.lu at anytimechinese.com Wed May 23 10:16:09 2012 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 23 May 2012 10:16:09 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBC9465.3030101@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: Hi Tore: Thanks for replying. Almost every hosting company here in EU has customer from outside of region, they rent server from EU company for whatever reasons(for making their EU website for example), but they are outside of region. If "end customer from outside of region can not assign IP addresses", then all EU hosting company can not sell any hosting package to a person in US for example, but that is not the case. So where is the limit? On Wed, May 23, 2012 at 9:40 AM, Tore Anderson wrote: > * Lu Heng > >> but if there is no policy for that, is that means people can announce >> their address in us or region outside ripe region(as i know some >> people do for their us cdn network for example)., is this also >> accepted in the policy? > > You can announce them anywhere you like. But you cannot assign them to > end users outside outside of the region. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From randy at psg.com Wed May 23 10:28:23 2012 From: randy at psg.com (Randy Bush) Date: Wed, 23 May 2012 17:28:23 +0900 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBC9465.3030101@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: > You can announce them anywhere you like. But you cannot assign them to > end users outside outside of the region. really? so i have a /16 from ncc and i spread it over pops in ams, lon, and nyc, but i can not have bgp-speaking customers in that address space in nyc? if true, that is soooo broken. randy From sander at steffann.nl Wed May 23 10:29:20 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 23 May 2012 11:29:20 +0300 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBC9465.3030101@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: Hi Tore, > You can announce them anywhere you like. But you cannot assign them to > end users outside outside of the region. This is not limited in policy. The LIR can assign resources to whoever their customers are. Thanks - Sander From tore.anderson at redpill-linpro.com Wed May 23 10:32:24 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 23 May 2012 10:32:24 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: <4FBCA098.4010306@redpill-linpro.com> * Lu Heng > Almost every hosting company here in EU has customer from outside of > region, they rent server from EU company for whatever reasons(for > making their EU website for example), but they are outside of region. > > If "end customer from outside of region can not assign IP addresses", > then all EU hosting company can not sell any hosting package to a > person in US for example, but that is not the case. They can, if the hosted service is in the RIPE service region. For example: You (assuming you're located in China) can come to me and purchase a virtual machine hosted in my data center located in Norway. It will be numbered using RIPE region address space. No problems. I could also announce this address space to peers on a Chinese internet exchange and backhaul the traffic to Norway myself, if I wanted to. Still no problems there. However, if I build a data center in China I cannot use RIPE region address space to number it. (Even if the customers hosted in that were all incorporated in the RIPE region.) If this had been permitted, I doubt there would still be available IPv4 address space in the RIPE region at this point, as organisations in the APNIC region in need of IPv4 address space could just have set up LIRs in the RIPE region and allocate away. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From h.lu at anytimechinese.com Wed May 23 10:36:30 2012 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 23 May 2012 10:36:30 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: Hi What we really want to ask is, we are consider the possibility to built part of our infrastructure in US just like many of colleague here already does. But we find out that we can not become member of ARIN unless we have real company there. Then after research, we found out that many EU company just simply announced their Ripe range in the US for that purpose(to avoid any problem I don't want name any, but you can search yourself). And more after search, many company announced their backbone IP in US like eurorings for example. So, let's conclude: 1. you can announce IP outside of the region. 2. you are not limited to sell whoever is the customer(this customer thing didn't really mentioned in any documentation). Then as Tore said, why for example China telecom become member of Ripe and transfer the IP away? We must have sort of limit in the policy for that. On Wed, May 23, 2012 at 10:29 AM, Sander Steffann wrote: > Hi Tore, > >> You can announce them anywhere you like. But you cannot assign them to >> end users outside outside of the region. > > This is not limited in policy. The LIR can assign resources to whoever their customers are. > > Thanks > - Sander > -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From tore.anderson at redpill-linpro.com Wed May 23 10:41:07 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 23 May 2012 10:41:07 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: <4FBCA2A3.5090400@redpill-linpro.com> * Randy Bush >> You can announce them anywhere you like. But you cannot assign them to >> end users outside outside of the region. > > really? so i have a /16 from ncc and i spread it over pops in ams, lon, > and nyc, but i can not have bgp-speaking customers in that address space > in nyc? if true, that is soooo broken. That is my understanding, at least. I asked this question to the RIR panel at the mic in Rome, whether and APNIC region ISP could (post APNIC depletion) set up a LIR in the RIPE region (or any other region), and allocate addresses from there and assign them to end users in their home region. The answer (which came from Geoff Huston IIRC) was something along the lines of ?no, you have to assign the addresses in the service region from which they were allocated?. If this was not the case, I would not have expected the APNIC depletion from significantly slow down the global rate of IPv4 delegations, only that it would simply shift from the APNIC region to other regions as IPv4-hungry Asian providers started allocating from other regions. But looking at http://www.potaroo.net/tools/ipv4/fig09.png for example, this does not appear to have happened. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From Woeber at CC.UniVie.ac.at Wed May 23 10:54:47 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 23 May 2012 10:54:47 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBC9465.3030101@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: <4FBCA5D7.7080200@CC.UniVie.ac.at> Tore Anderson wrote: > * Lu Heng > > >>but if there is no policy for that, is that means people can announce >>their address in us or region outside ripe region(as i know some >>people do for their us cdn network for example)., is this also >>accepted in the policy? > > > You can announce them anywhere you like. But you cannot assign them to > end users outside outside of the region. I am not aware of such a limitation in the RIPE Region's policies. Wilfried. From tore.anderson at redpill-linpro.com Wed May 23 10:59:24 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 23 May 2012 10:59:24 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <20120523083457.GV2841@h.detebe.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> <20120523083457.GV2841@h.detebe.org> Message-ID: <4FBCA6EC.6010201@redpill-linpro.com> * Elmar K. Bins >> However, if I build a data center in China I cannot use RIPE region >> address space to number it. (Even if the customers hosted in that were >> all incorporated in the RIPE region.) > > I wonder if this might actually be true. Could you show a pointer into > the relevant document? I don't know where it's stated explicitly in any document, however the title of ripe-530 is ?IPv4 Address Allocation and Assignment Policies *for the RIPE NCC Service Region*? (emphasis mine). I'm not aware of any RIPE policy document that covers out-of-region assignments. So from that you might infer that such assignments are not permitted. And the LIR panel at the RIPE meeting in Rome said so, too (see my response to Randy Bush). If on the other hand out-of-region assignments are valid and allowed, I cannot fathom why those fast growing ISPs in China, India, Vietnam and so on that were allocating IPv4 addresses from APNIC at an incredible rate right up until the day APNIC hit the /8 have not simply set up legal organisations in the RIPE region, joined the NCC, and continued allocating from here in more or less the same rate as before APNIC ran out. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From slz at baycix.de Wed May 23 11:00:20 2012 From: slz at baycix.de (Sascha Lenz) Date: Wed, 23 May 2012 11:00:20 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA5D7.7080200@CC.UniVie.ac.at> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> Message-ID: <047B5390-1D4D-4728-8B04-18A8A248BBCF@baycix.de> Hi all, > Tore Anderson wrote: > >> * Lu Heng >> >> >>> but if there is no policy for that, is that means people can announce >>> their address in us or region outside ripe region(as i know some >>> people do for their us cdn network for example)., is this also >>> accepted in the policy? >> >> >> You can announce them anywhere you like. But you cannot assign them to >> end users outside outside of the region. > > I am not aware of such a limitation in the RIPE Region's policies. > Wilfried. > > me neither - and it would contradict common practice, and probably even common sense. So i hope that's just a misunderstanding/-interpretation. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From slz at baycix.de Wed May 23 11:06:04 2012 From: slz at baycix.de (Sascha Lenz) Date: Wed, 23 May 2012 11:06:04 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <047B5390-1D4D-4728-8B04-18A8A248BBCF@baycix.de> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <047B5390-1D4D-4728-8B04-18A8A248BBCF@baycix.de> Message-ID: <2A9E829C-AD7C-4D6E-8D33-A944A33EDDE5@baycix.de> ...replying to myself now, must be the heat here in my room, sending out E-Mails before i thought about the contents properly... > Hi all, > >> Tore Anderson wrote: >> >>> * Lu Heng >>> >>> >>>> but if there is no policy for that, is that means people can announce >>>> their address in us or region outside ripe region(as i know some >>>> people do for their us cdn network for example)., is this also >>>> accepted in the policy? >>> >>> >>> You can announce them anywhere you like. But you cannot assign them to >>> end users outside outside of the region. >> >> I am not aware of such a limitation in the RIPE Region's policies. >> Wilfried. >> >> > > > me neither - and it would contradict common practice, and probably even common sense. > So i hope that's just a misunderstanding/-interpretation. > > ..on a second thought, i can't (or at least could not in the past) get a PI(!) assignment for a customer NOT registered in RIPE NCC service region, so... hm interesting question/problem indeed, somehow. Might the NCC elaborate on this perhaps? :-) Maybe something is in the LIR contracts about this i'm not aware of right now? -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From tore.anderson at redpill-linpro.com Wed May 23 11:12:52 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 23 May 2012 11:12:52 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA2A3.5090400@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> Message-ID: <4FBCAA14.4030903@redpill-linpro.com> * Tore Anderson > That is my understanding, at least. I asked this question to the RIR > panel at the mic in Rome, whether and APNIC region ISP could (post > APNIC depletion) set up a LIR in the RIPE region (or any other > region), and allocate addresses from there and assign them to end > users in their home region. The answer (which came from Geoff Huston > IIRC) was something along the lines of ?no, you have to assign the > addresses in the service region from which they were allocated?. Found it: http://ripe61.ripe.net/archives/video/18/ @ 22:03 -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From ingrid at ripe.net Wed May 23 11:13:15 2012 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 23 May 2012 11:13:15 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA5D7.7080200@CC.UniVie.ac.at> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> Message-ID: <4FBCAA2B.9050104@ripe.net> I would like to give some further clarification on this. The RIPE NCC allocates/assigns address space to organisations who have a need in the RIPE NCC service region. The address space must be originated from the RIPE NCC service region. Due to the diverse nature of businesses, in addition to this there can be announcements from other regions. To respond to Randy, also having BGP-speaking customers outside of the region is no problem. Regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 5/23/12 10:54 AM, Wilfried Woeber, UniVie/ACOnet wrote: > Tore Anderson wrote: > >> * Lu Heng >> >> >>> but if there is no policy for that, is that means people can announce >>> their address in us or region outside ripe region(as i know some >>> people do for their us cdn network for example)., is this also >>> accepted in the policy? >> >> You can announce them anywhere you like. But you cannot assign them to >> end users outside outside of the region. > I am not aware of such a limitation in the RIPE Region's policies. > Wilfried. > > From elmi at 4ever.de Wed May 23 10:34:57 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 23 May 2012 10:34:57 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA098.4010306@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> Message-ID: <20120523083457.GV2841@h.detebe.org> Tore, > However, if I build a data center in China I cannot use RIPE region > address space to number it. (Even if the customers hosted in that were > all incorporated in the RIPE region.) I wonder if this might actually be true. Could you show a pointer into the relevant document? Elmar (Actually doing exactly this. In China.) From tore.anderson at redpill-linpro.com Wed May 23 12:01:13 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 23 May 2012 12:01:13 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCAA2B.9050104@ripe.net> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> Message-ID: <4FBCB569.5060204@redpill-linpro.com> * Ingrid Wijte > I would like to give some further clarification on this. > > The RIPE NCC allocates/assigns address space to organisations who have a > need in the RIPE NCC service region. The address space must be > originated from the RIPE NCC service region. Due to the diverse nature > of businesses, in addition to this there can be announcements from other > regions. Just to make 110% certain, you're saying here that it is the *need* that must be in the RIPE region, not the *organisation*, correct? Example 1: China Unicom sets up a legal organisation in the Netherlands, joins the NCC, and requests an allocation from which they intend to assign addresses to broadband customers in China. They intend to advertise the allocated prefix(es) to peers at AMS-IX (as well as from other exchange points around the world). Example 2: I, representing an existing LIR in the RIPE region, build a data center in Australia and set up a server hosting business there. I want to make an assignment to a new customer in this data center from my IPv4 allocation received from the RIPE NCC, and request that from the NCC hostmater using a ripe-488 form. Assuming all the documentation is otherwise in order and the need is real, will these requests be granted or denied? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From jan at go6.si Wed May 23 12:03:28 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 23 May 2012 12:03:28 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> Message-ID: <4FBCB5F0.4050009@go6.si> On 5/23/12 10:28 AM, Randy Bush wrote: >> You can announce them anywhere you like. But you cannot assign them to >> end users outside outside of the region. > > really? so i have a /16 from ncc and i spread it over pops in ams, lon, > and nyc, but i can not have bgp-speaking customers in that address space > in nyc? if true, that is soooo broken. +1 (I just saw upfront that comment coming in :) :) :) ) Jan From jan at go6.si Wed May 23 12:11:36 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 23 May 2012 12:11:36 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCB569.5060204@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> Message-ID: <4FBCB7D8.5090903@go6.si> On 5/23/12 12:01 PM, Tore Anderson wrote: > Example 1: China Unicom sets up a legal organisation in the Netherlands, > joins the NCC, and requests an allocation from which they intend to > assign addresses to broadband customers in China. They intend to > advertise the allocated prefix(es) to peers at AMS-IX (as well as from > other exchange points around the world). They could also say during the initial alloc process that they'll allocate this resources to potential customers in RIPE-NCC region and the use it elsewhere. Just saying... > > Example 2: I, representing an existing LIR in the RIPE region, build a > data center in Australia and set up a server hosting business there. I > want to make an assignment to a new customer in this data center from my > IPv4 allocation received from the RIPE NCC, and request that from the > NCC hostmater using a ripe-488 form. > > Assuming all the documentation is otherwise in order and the need is > real, will these requests be granted or denied? good questions, wonder what the answers will be :) Cheers, Jan From jan at go6.si Wed May 23 12:12:48 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 23 May 2012 12:12:48 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA6EC.6010201@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> <20120523083457.GV2841@h.detebe.org> <4FBCA6EC.6010201@redpill-linpro.com> Message-ID: <4FBCB820.2020704@go6.si> On 5/23/12 10:59 AM, Tore Anderson wrote: > If on the other hand out-of-region assignments are valid and allowed, I > cannot fathom why those fast growing ISPs in China, India, Vietnam and > so on that were allocating IPv4 addresses from APNIC at an incredible > rate right up until the day APNIC hit the /8 have not simply set up > legal organisations in the RIPE region, joined the NCC, and continued > allocating from here in more or less the same rate as before APNIC ran out. Maybe those IPv4-hungry operators are just not aware of this "option" ;) Jan From shane at time-travellers.org Wed May 23 13:11:54 2012 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 23 May 2012 13:11:54 +0200 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: <4FBBA6F3.3030805@inex.ie> Message-ID: <20120523131154.55f5f50d@shane-eeepc.home.time-travellers.org> Pascal, On Tuesday, 2012-05-22 16:26:50 +0000, Pascal Gloor wrote: > >IOW, I don't see any clear solutions to this problem for existing > >contracts. > > To be honest, me neither, but I wanted some community feedback to see > if there would be a solution I didn't think of. In my mind, this is the MAIN problem with IPv4 exhaustion. Anyone who got IPv4 address before exhaustion can provide services, anyone else cannot. Think back to the Internet in 1990 and where it would be today if the phone companies held all of the IPv4 space and you had to go through them for all connectivity. While James Blessing's "use IPv6" suggestion is perhaps not easy, it's the best answer we have. :( -- Shane From pascal.gloor at finecom.ch Wed May 23 14:30:17 2012 From: pascal.gloor at finecom.ch (Pascal Gloor) Date: Wed, 23 May 2012 12:30:17 +0000 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: <4FBBEBB4.2040405@go6.si> Message-ID: >Why moving elswhere then? It's the other way around. We are the wholesale cable provider and this might be an issue to gain new customers if they don't have IPs and can't have them from us. Pascal From jan at go6.si Wed May 23 14:57:02 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 23 May 2012 14:57:02 +0200 Subject: [address-policy-wg] Assignment transfer among LIR In-Reply-To: References: Message-ID: <4FBCDE9E.9050604@go6.si> On 5/23/12 2:30 PM, Pascal Gloor wrote: >> Why moving elswhere then? > > It's the other way around. We are the wholesale cable provider and this > might be an issue to gain new customers if they don't have IPs and can't > have them from us. I think you nailed it. So it's not the fairness and competitiveness issue but purely lack of resources and IPv4 depletion that is beating your business up (and not just yours). You have several ways out, as already pointed in this discussion: - Big evil CGN - A bit less evil A+P derivates (MAP, 4RD, etc) - when they become available - IPv6 with NAT64/DNS64 in the core Pick your poison :) Cheers, Jan From randy at psg.com Wed May 23 15:31:19 2012 From: randy at psg.com (Randy Bush) Date: Wed, 23 May 2012 22:31:19 +0900 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA2A3.5090400@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> Message-ID: > That is my understanding, at least. I asked this question to the RIR > panel at the mic in Rome, whether and APNIC region ISP could (post APNIC > depletion) set up a LIR in the RIPE region (or any other region), and > allocate addresses from there and assign them to end users in their home > region. The answer (which came from Geoff Huston IIRC) was something > along the lines of ?no, you have to assign the addresses in the service > region from which they were allocated?. you mis-heard i am in the apnic region and chaired address policy sig in apnic for some years. this is not the case. randy From ingrid at ripe.net Wed May 23 17:17:09 2012 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 23 May 2012 17:17:09 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCB569.5060204@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> Message-ID: <4FBCFF75.9050708@ripe.net> Hi Tore, On 5/23/12 12:01 PM, Tore Anderson wrote: > * Ingrid Wijte > >> I would like to give some further clarification on this. >> >> The RIPE NCC allocates/assigns address space to organisations who have a >> need in the RIPE NCC service region. The address space must be >> originated from the RIPE NCC service region. Due to the diverse nature >> of businesses, in addition to this there can be announcements from other >> regions. > Just to make 110% certain, you're saying here that it is the *need* that > must be in the RIPE region, not the *organisation*, correct? The need and the route origination must be in the RIPE NCC service region. > > Example 1: China Unicom sets up a legal organisation in the Netherlands, > joins the NCC, and requests an allocation from which they intend to > assign addresses to broadband customers in China. They intend to > advertise the allocated prefix(es) to peers at AMS-IX (as well as from > other exchange points around the world). This example would be ok for several reasons: The requestor is a RIPE NCC member. They have infrastructure in the region and the address space will originate from the RIPE NCC service region. Other similar examples would be VPN Providers but also Satellite providers that are based in the region and have customers globally. > > Example 2: I, representing an existing LIR in the RIPE region, build a > data center in Australia and set up a server hosting business there. I > want to make an assignment to a new customer in this data center from my > IPv4 allocation received from the RIPE NCC, and request that from the > NCC hostmater using a ripe-488 form. As long as the prefix is originated in the RIPE NCC service region, this would be approved. The LIR has an allocation, is announcing it in the RIPE NCC service region, and is making PA assignments to its customers. Regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC > Assuming all the documentation is otherwise in order and the need is > real, will these requests be granted or denied? > > Best regards, From h.lu at anytimechinese.com Wed May 23 22:00:19 2012 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 23 May 2012 22:00:19 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 9, Issue 17 In-Reply-To: References: Message-ID: Dear Ingrid: Thanks for replying. So is that to speaking: As long as the need is inside the region, part of the infrastructure(CDN network for example) with the IP address can be announced outside of Ripe service region(as I see many are doing that). Am I correct? On Wed, May 23, 2012 at 5:17 PM, wrote: > Send address-policy-wg mailing list submissions to > ? ? ? ?address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > ? ? ? ?address-policy-wg-request at ripe.net > > You can reach the person managing the list at > ? ? ? ?address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > ? 1. Re: Any-cast or uni-cast solutions (Tore Anderson) > ? 2. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) > ? 3. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) > ? 4. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) > ? 5. Re: Assignment transfer among LIR (Shane Kerr) > ? 6. Re: Assignment transfer among LIR (Pascal Gloor) > ? 7. Re: Assignment transfer among LIR (Jan Zorz @ go6.si) > ? 8. Re: Any-cast or uni-cast solutions (Randy Bush) > ? 9. Re: Any-cast or uni-cast solutions (Ingrid Wijte) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 May 2012 12:01:13 +0200 > From: Tore Anderson > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: Ingrid Wijte > Cc: address-policy-wg at ripe.net > Message-ID: <4FBCB569.5060204 at redpill-linpro.com> > Content-Type: text/plain; charset=ISO-8859-1 > > * Ingrid Wijte > >> I would like to give some further clarification on this. >> >> The RIPE NCC allocates/assigns address space to organisations who have a >> need in the RIPE NCC service region. The address space must be >> originated from the RIPE NCC service region. Due to the diverse nature >> of businesses, in addition to this there can be announcements from other >> regions. > > Just to make 110% certain, you're saying here that it is the *need* that > must be in the RIPE region, not the *organisation*, correct? > > Example 1: China Unicom sets up a legal organisation in the Netherlands, > joins the NCC, and requests an allocation from which they intend to > assign addresses to broadband customers in China. They intend to > advertise the allocated prefix(es) to peers at AMS-IX (as well as from > other exchange points around the world). > > Example 2: I, representing an existing LIR in the RIPE region, build a > data center in Australia and set up a server hosting business there. I > want to make an assignment to a new customer in this data center from my > IPv4 allocation received from the RIPE NCC, and request that from the > NCC hostmater using a ripe-488 form. > > Assuming all the documentation is otherwise in order and the need is > real, will these requests be granted or denied? > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > > > > ------------------------------ > > Message: 2 > Date: Wed, 23 May 2012 12:03:28 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg at ripe.net > Message-ID: <4FBCB5F0.4050009 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 10:28 AM, Randy Bush wrote: >>> You can announce them anywhere you like. But you cannot assign them to >>> end users outside outside of the region. >> >> really? ?so i have a /16 from ncc and i spread it over pops in ams, lon, >> and nyc, but i can not have bgp-speaking customers in that address space >> in nyc? ?if true, that is soooo broken. > > +1 > > (I just saw upfront that comment coming in :) :) :) ) > > Jan > > > > ------------------------------ > > Message: 3 > Date: Wed, 23 May 2012 12:11:36 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg at ripe.net > Message-ID: <4FBCB7D8.5090903 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 12:01 PM, Tore Anderson wrote: >> Example 1: China Unicom sets up a legal organisation in the Netherlands, >> joins the NCC, and requests an allocation from which they intend to >> assign addresses to broadband customers in China. They intend to >> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >> other exchange points around the world). > > They could also say during the initial alloc process that they'll > allocate this resources to potential customers in RIPE-NCC region and > the use it elsewhere. Just saying... > >> >> Example 2: I, representing an existing LIR in the RIPE region, build a >> data center in Australia and set up a server hosting business there. I >> want to make an assignment to a new customer in this data center from my >> IPv4 allocation received from the RIPE NCC, and request that from the >> NCC hostmater using a ripe-488 form. >> >> Assuming all the documentation is otherwise in order and the need is >> real, will these requests be granted or denied? > > good questions, wonder what the answers will be :) > > Cheers, Jan > > > > ------------------------------ > > Message: 4 > Date: Wed, 23 May 2012 12:12:48 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg at ripe.net > Message-ID: <4FBCB820.2020704 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 10:59 AM, Tore Anderson wrote: >> If on the other hand out-of-region assignments are valid and allowed, I >> cannot fathom why those fast growing ISPs in China, India, Vietnam and >> so on that were allocating IPv4 addresses from APNIC at an incredible >> rate right up until the day APNIC hit the /8 have not simply set up >> legal organisations in the RIPE region, joined the NCC, and continued >> allocating from here in more or less the same rate as before APNIC ran out. > > Maybe those IPv4-hungry operators are just not aware of this "option" ;) > > Jan > > > > ------------------------------ > > Message: 5 > Date: Wed, 23 May 2012 13:11:54 +0200 > From: Shane Kerr > Subject: Re: [address-policy-wg] Assignment transfer among LIR > To: Pascal Gloor > Cc: "address-policy-wg at ripe.net" > Message-ID: > ? ? ? ?<20120523131154.55f5f50d at shane-eeepc.home.time-travellers.org> > Content-Type: text/plain; charset=US-ASCII > > Pascal, > > On Tuesday, 2012-05-22 16:26:50 +0000, > Pascal Gloor wrote: >> >IOW, I don't see any clear solutions to this problem for existing >> >contracts. >> >> To be honest, me neither, but I wanted some community feedback to see >> if there would be a solution I didn't think of. > > In my mind, this is the MAIN problem with IPv4 exhaustion. Anyone who > got IPv4 address before exhaustion can provide services, anyone else > cannot. > > Think back to the Internet in 1990 and where it would be today if the > phone companies held all of the IPv4 space and you had to go through > them for all connectivity. > > While James Blessing's "use IPv6" suggestion is perhaps not easy, it's > the best answer we have. :( > > -- > Shane > > > > ------------------------------ > > Message: 6 > Date: Wed, 23 May 2012 12:30:17 +0000 > From: Pascal Gloor > Subject: Re: [address-policy-wg] Assignment transfer among LIR > To: "Jan Zorz @ go6.si" , "address-policy-wg at ripe.net" > ? ? ? ? > Message-ID: > Content-Type: text/plain; charset="us-ascii" > >>Why moving elswhere then? > > It's the other way around. We are the wholesale cable provider and this > might be an issue to gain new customers if they don't have IPs and can't > have them from us. > > > Pascal > > > > > > > ------------------------------ > > Message: 7 > Date: Wed, 23 May 2012 14:57:02 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] Assignment transfer among LIR > To: "address-policy-wg at ripe.net" > Message-ID: <4FBCDE9E.9050604 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/12 2:30 PM, Pascal Gloor wrote: >>> Why moving elswhere then? >> >> It's the other way around. We are the wholesale cable provider and this >> might be an issue to gain new customers if they don't have IPs and can't >> have them from us. > > I think you nailed it. > > So it's not the fairness and competitiveness issue but purely lack of > resources and IPv4 depletion that is beating your business up (and not > just yours). > > You have several ways out, as already pointed in this discussion: > > - Big evil CGN > - A bit less evil A+P derivates (MAP, 4RD, etc) - when they become available > - IPv6 with NAT64/DNS64 in the core > > Pick your poison :) > > Cheers, Jan > > > > ------------------------------ > > Message: 8 > Date: Wed, 23 May 2012 22:31:19 +0900 > From: Randy Bush > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: Tore Anderson > Cc: Sander Steffann , Lu Heng > ? ? ? ?, ? ? ?address-policy-wg at ripe.net > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > >> That is my understanding, at least. I asked this question to the RIR >> panel at the mic in Rome, whether and APNIC region ISP could (post APNIC >> depletion) set up a LIR in the RIPE region (or any other region), and >> allocate addresses from there and assign them to end users in their home >> region. The answer (which came from Geoff Huston IIRC) was something >> along the lines of ?no, you have to assign the addresses in the service >> region from which they were allocated?. > > you mis-heard > > i am in the apnic region and chaired address policy sig in apnic for > some years. ?this is not the case. > > randy > > > > ------------------------------ > > Message: 9 > Date: Wed, 23 May 2012 17:17:09 +0200 > From: Ingrid Wijte > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > To: address-policy-wg at ripe.net > Message-ID: <4FBCFF75.9050708 at ripe.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Tore, > > On 5/23/12 12:01 PM, Tore Anderson wrote: >> * Ingrid Wijte >> >>> I would like to give some further clarification on this. >>> >>> The RIPE NCC allocates/assigns address space to organisations who have a >>> need in the RIPE NCC service region. The address space must be >>> originated from the RIPE NCC service region. Due to the diverse nature >>> of businesses, in addition to this there can be announcements from other >>> regions. >> Just to make 110% certain, you're saying here that it is the *need* that >> must be in the RIPE region, not the *organisation*, correct? > The need and the route origination must be in the RIPE NCC service region. >> >> Example 1: China Unicom sets up a legal organisation in the Netherlands, >> joins the NCC, and requests an allocation from which they intend to >> assign addresses to broadband customers in China. They intend to >> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >> other exchange points around the world). > This example would be ok for several reasons: > The requestor is a RIPE NCC member. They have infrastructure in the > region and the address space will originate from the RIPE NCC service > region. > Other similar examples would be VPN Providers but also Satellite > providers that are based in the region and have customers globally. >> >> Example 2: I, representing an existing LIR in the RIPE region, build a >> data center in Australia and set up a server hosting business there. I >> want to make an assignment to a new customer in this data center from my >> IPv4 allocation received from the RIPE NCC, and request that from the >> NCC hostmater using a ripe-488 form. > As long as the prefix is originated in the RIPE NCC service region, this > would be approved. The LIR has an allocation, is announcing it in the > RIPE NCC service region, and is making PA assignments to its customers. > > Regards, > > Ingrid Wijte > > Registration Services Assistant Manager > RIPE NCC > >> Assuming all the documentation is otherwise in order and the need is >> real, will these requests be granted or denied? >> >> Best regards, > > > > End of address-policy-wg Digest, Vol 9, Issue 17 > ************************************************ -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From randy at psg.com Thu May 24 00:32:02 2012 From: randy at psg.com (Randy Bush) Date: Thu, 24 May 2012 07:32:02 +0900 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCFF75.9050708@ripe.net> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> Message-ID: > The need and the route origination must be in the RIPE NCC service > region. ahem! the ncc has repeatedly said over many years that it has nothing to do with routing. randy From shane at time-travellers.org Thu May 24 08:34:51 2012 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 24 May 2012 08:34:51 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> Message-ID: <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> Randy, On Thursday, 2012-05-24 07:32:02 +0900, Randy Bush wrote: > > The need and the route origination must be in the RIPE NCC service > > region. > > ahem! the ncc has repeatedly said over many years that it has nothing > to do with routing. I don't think this is true. For example, I remember the requirements for IPv4 PI space have included peering. I think a more accurate claim is that the RIPE NCC has always said that they don't guarantee that any resource you are issued can be routed. This makes sense, because that is between you and your peers (and the rest of the Internet). So, you may need to meet certain routing requirements to qualify for resources. But once you get them it's up to you to make them work. Cheers, -- Shane From dr at cluenet.de Thu May 24 09:09:22 2012 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 May 2012 09:09:22 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCAA2B.9050104@ripe.net> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> Message-ID: <20120524070922.GB16448@srv03.cluenet.de> On Wed, May 23, 2012 at 11:13:15AM +0200, Ingrid Wijte wrote: > The address space must be originated from the RIPE NCC service region. > Due to the diverse nature of businesses, in addition to this there can > be announcements from other regions. Could you please point us to the policy requiring such routing requirements? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ingrid at ripe.net Thu May 24 15:34:05 2012 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 24 May 2012 15:34:05 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 9, Issue 17 In-Reply-To: References: Message-ID: <4FBE38CD.40601@ripe.net> Hi Lu, As said earlier, the need must be in the RIPE Service Region. The address space must be originated from the RIPE NCC service region. In addition to this there can be announcements from other regions. There is one thing I would like to add regarding the examples posted on the list. The response to the examples given is purely based on the information provided on the list. Where the address space is needed, is only one of the criteria in the evaluation of a request. The evaluation of a request is based on the full set of applicable policy as described in IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region (http://www.ripe.net/ripe/docs/ripe-530) Regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 5/23/12 10:00 PM, Lu Heng wrote: > Dear Ingrid: > > Thanks for replying. > > So is that to speaking: > > As long as the need is inside the region, part of the > infrastructure(CDN network for example) with the IP address can be > announced outside of Ripe service region(as I see many are doing > that). > > Am I correct? > > On Wed, May 23, 2012 at 5:17 PM, wrote: >> Send address-policy-wg mailing list submissions to >> address-policy-wg at ripe.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ripe.net/mailman/listinfo/address-policy-wg >> or, via email, send a message with subject or body 'help' to >> address-policy-wg-request at ripe.net >> >> You can reach the person managing the list at >> address-policy-wg-owner at ripe.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of address-policy-wg digest..." >> >> >> Today's Topics: >> >> 1. Re: Any-cast or uni-cast solutions (Tore Anderson) >> 2. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) >> 3. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) >> 4. Re: Any-cast or uni-cast solutions (Jan Zorz @ go6.si) >> 5. Re: Assignment transfer among LIR (Shane Kerr) >> 6. Re: Assignment transfer among LIR (Pascal Gloor) >> 7. Re: Assignment transfer among LIR (Jan Zorz @ go6.si) >> 8. Re: Any-cast or uni-cast solutions (Randy Bush) >> 9. Re: Any-cast or uni-cast solutions (Ingrid Wijte) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 23 May 2012 12:01:13 +0200 >> From: Tore Anderson >> Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions >> To: Ingrid Wijte >> Cc: address-policy-wg at ripe.net >> Message-ID:<4FBCB569.5060204 at redpill-linpro.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> * Ingrid Wijte >> >>> I would like to give some further clarification on this. >>> >>> The RIPE NCC allocates/assigns address space to organisations who have a >>> need in the RIPE NCC service region. The address space must be >>> originated from the RIPE NCC service region. Due to the diverse nature >>> of businesses, in addition to this there can be announcements from other >>> regions. >> Just to make 110% certain, you're saying here that it is the *need* that >> must be in the RIPE region, not the *organisation*, correct? >> >> Example 1: China Unicom sets up a legal organisation in the Netherlands, >> joins the NCC, and requests an allocation from which they intend to >> assign addresses to broadband customers in China. They intend to >> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >> other exchange points around the world). >> >> Example 2: I, representing an existing LIR in the RIPE region, build a >> data center in Australia and set up a server hosting business there. I >> want to make an assignment to a new customer in this data center from my >> IPv4 allocation received from the RIPE NCC, and request that from the >> NCC hostmater using a ripe-488 form. >> >> Assuming all the documentation is otherwise in order and the need is >> real, will these requests be granted or denied? >> >> Best regards, >> -- >> Tore Anderson >> Redpill Linpro AS - http://www.redpill-linpro.com >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 23 May 2012 12:03:28 +0200 >> From: "Jan Zorz @ go6.si" >> Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions >> To: address-policy-wg at ripe.net >> Message-ID:<4FBCB5F0.4050009 at go6.si> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 5/23/12 10:28 AM, Randy Bush wrote: >>>> You can announce them anywhere you like. But you cannot assign them to >>>> end users outside outside of the region. >>> really? so i have a /16 from ncc and i spread it over pops in ams, lon, >>> and nyc, but i can not have bgp-speaking customers in that address space >>> in nyc? if true, that is soooo broken. >> +1 >> >> (I just saw upfront that comment coming in :) :) :) ) >> >> Jan >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 23 May 2012 12:11:36 +0200 >> From: "Jan Zorz @ go6.si" >> Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions >> To: address-policy-wg at ripe.net >> Message-ID:<4FBCB7D8.5090903 at go6.si> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 5/23/12 12:01 PM, Tore Anderson wrote: >>> Example 1: China Unicom sets up a legal organisation in the Netherlands, >>> joins the NCC, and requests an allocation from which they intend to >>> assign addresses to broadband customers in China. They intend to >>> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >>> other exchange points around the world). >> They could also say during the initial alloc process that they'll >> allocate this resources to potential customers in RIPE-NCC region and >> the use it elsewhere. Just saying... >> >>> Example 2: I, representing an existing LIR in the RIPE region, build a >>> data center in Australia and set up a server hosting business there. I >>> want to make an assignment to a new customer in this data center from my >>> IPv4 allocation received from the RIPE NCC, and request that from the >>> NCC hostmater using a ripe-488 form. >>> >>> Assuming all the documentation is otherwise in order and the need is >>> real, will these requests be granted or denied? >> good questions, wonder what the answers will be :) >> >> Cheers, Jan >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Wed, 23 May 2012 12:12:48 +0200 >> From: "Jan Zorz @ go6.si" >> Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions >> To: address-policy-wg at ripe.net >> Message-ID:<4FBCB820.2020704 at go6.si> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 5/23/12 10:59 AM, Tore Anderson wrote: >>> If on the other hand out-of-region assignments are valid and allowed, I >>> cannot fathom why those fast growing ISPs in China, India, Vietnam and >>> so on that were allocating IPv4 addresses from APNIC at an incredible >>> rate right up until the day APNIC hit the /8 have not simply set up >>> legal organisations in the RIPE region, joined the NCC, and continued >>> allocating from here in more or less the same rate as before APNIC ran out. >> Maybe those IPv4-hungry operators are just not aware of this "option" ;) >> >> Jan >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Wed, 23 May 2012 13:11:54 +0200 >> From: Shane Kerr >> Subject: Re: [address-policy-wg] Assignment transfer among LIR >> To: Pascal Gloor >> Cc: "address-policy-wg at ripe.net" >> Message-ID: >> <20120523131154.55f5f50d at shane-eeepc.home.time-travellers.org> >> Content-Type: text/plain; charset=US-ASCII >> >> Pascal, >> >> On Tuesday, 2012-05-22 16:26:50 +0000, >> Pascal Gloor wrote: >>>> IOW, I don't see any clear solutions to this problem for existing >>>> contracts. >>> To be honest, me neither, but I wanted some community feedback to see >>> if there would be a solution I didn't think of. >> In my mind, this is the MAIN problem with IPv4 exhaustion. Anyone who >> got IPv4 address before exhaustion can provide services, anyone else >> cannot. >> >> Think back to the Internet in 1990 and where it would be today if the >> phone companies held all of the IPv4 space and you had to go through >> them for all connectivity. >> >> While James Blessing's "use IPv6" suggestion is perhaps not easy, it's >> the best answer we have. :( >> >> -- >> Shane >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Wed, 23 May 2012 12:30:17 +0000 >> From: Pascal Gloor >> Subject: Re: [address-policy-wg] Assignment transfer among LIR >> To: "Jan Zorz @ go6.si", "address-policy-wg at ripe.net" >> >> Message-ID: >> Content-Type: text/plain; charset="us-ascii" >> >>> Why moving elswhere then? >> It's the other way around. We are the wholesale cable provider and this >> might be an issue to gain new customers if they don't have IPs and can't >> have them from us. >> >> >> Pascal >> >> >> >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 23 May 2012 14:57:02 +0200 >> From: "Jan Zorz @ go6.si" >> Subject: Re: [address-policy-wg] Assignment transfer among LIR >> To: "address-policy-wg at ripe.net" >> Message-ID:<4FBCDE9E.9050604 at go6.si> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 5/23/12 2:30 PM, Pascal Gloor wrote: >>>> Why moving elswhere then? >>> It's the other way around. We are the wholesale cable provider and this >>> might be an issue to gain new customers if they don't have IPs and can't >>> have them from us. >> I think you nailed it. >> >> So it's not the fairness and competitiveness issue but purely lack of >> resources and IPv4 depletion that is beating your business up (and not >> just yours). >> >> You have several ways out, as already pointed in this discussion: >> >> - Big evil CGN >> - A bit less evil A+P derivates (MAP, 4RD, etc) - when they become available >> - IPv6 with NAT64/DNS64 in the core >> >> Pick your poison :) >> >> Cheers, Jan >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Wed, 23 May 2012 22:31:19 +0900 >> From: Randy Bush >> Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions >> To: Tore Anderson >> Cc: Sander Steffann, Lu Heng >> , address-policy-wg at ripe.net >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >>> That is my understanding, at least. I asked this question to the RIR >>> panel at the mic in Rome, whether and APNIC region ISP could (post APNIC >>> depletion) set up a LIR in the RIPE region (or any other region), and >>> allocate addresses from there and assign them to end users in their home >>> region. The answer (which came from Geoff Huston IIRC) was something >>> along the lines of ?no, you have to assign the addresses in the service >>> region from which they were allocated?. >> you mis-heard >> >> i am in the apnic region and chaired address policy sig in apnic for >> some years. this is not the case. >> >> randy >> >> >> >> ------------------------------ >> >> Message: 9 >> Date: Wed, 23 May 2012 17:17:09 +0200 >> From: Ingrid Wijte >> Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions >> To: address-policy-wg at ripe.net >> Message-ID:<4FBCFF75.9050708 at ripe.net> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hi Tore, >> >> On 5/23/12 12:01 PM, Tore Anderson wrote: >>> * Ingrid Wijte >>> >>>> I would like to give some further clarification on this. >>>> >>>> The RIPE NCC allocates/assigns address space to organisations who have a >>>> need in the RIPE NCC service region. The address space must be >>>> originated from the RIPE NCC service region. Due to the diverse nature >>>> of businesses, in addition to this there can be announcements from other >>>> regions. >>> Just to make 110% certain, you're saying here that it is the *need* that >>> must be in the RIPE region, not the *organisation*, correct? >> The need and the route origination must be in the RIPE NCC service region. >>> Example 1: China Unicom sets up a legal organisation in the Netherlands, >>> joins the NCC, and requests an allocation from which they intend to >>> assign addresses to broadband customers in China. They intend to >>> advertise the allocated prefix(es) to peers at AMS-IX (as well as from >>> other exchange points around the world). >> This example would be ok for several reasons: >> The requestor is a RIPE NCC member. They have infrastructure in the >> region and the address space will originate from the RIPE NCC service >> region. >> Other similar examples would be VPN Providers but also Satellite >> providers that are based in the region and have customers globally. >>> Example 2: I, representing an existing LIR in the RIPE region, build a >>> data center in Australia and set up a server hosting business there. I >>> want to make an assignment to a new customer in this data center from my >>> IPv4 allocation received from the RIPE NCC, and request that from the >>> NCC hostmater using a ripe-488 form. >> As long as the prefix is originated in the RIPE NCC service region, this >> would be approved. The LIR has an allocation, is announcing it in the >> RIPE NCC service region, and is making PA assignments to its customers. >> >> Regards, >> >> Ingrid Wijte >> >> Registration Services Assistant Manager >> RIPE NCC >> >>> Assuming all the documentation is otherwise in order and the need is >>> real, will these requests be granted or denied? >>> >>> Best regards, >> >> >> End of address-policy-wg Digest, Vol 9, Issue 17 >> ************************************************ > > From ingrid at ripe.net Thu May 24 15:34:08 2012 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 24 May 2012 15:34:08 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <20120524070922.GB16448@srv03.cluenet.de> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <20120524070922.GB16448@srv03.cluenet.de> Message-ID: <4FBE38D0.6010002@ripe.net> Hi Daniel, The IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region state that ' These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.' In addition, RFC 2050 says: "This document makes a distinction between the allocation of IP addresses and the assignment of IP addresses. Addresses are allocated to ISPs by regional registries to assign to its customer base. ISPs who exchange routing information with other ISPs at multiple locations and operate without default routing may request space directly from the regional registry in its geographical area. ISPs with no designated regional registry may contact any regional registry and the regional registry may either handle the request or refer the request to an appropriate registry." The RIPE NCC interprets these statements as we explained on the mailing list. If the RIPE community feels this interpretation is not correct, do let us know. Regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 5/24/12 9:09 AM, Daniel Roesen wrote: > On Wed, May 23, 2012 at 11:13:15AM +0200, Ingrid Wijte wrote: >> The address space must be originated from the RIPE NCC service region. >> Due to the diverse nature of businesses, in addition to this there can >> be announcements from other regions. > Could you please point us to the policy requiring such routing > requirements? > > Best regards, > Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu May 24 16:18:42 2012 From: randy at psg.com (Randy Bush) Date: Thu, 24 May 2012 23:18:42 +0900 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBE38D0.6010002@ripe.net> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <20120524070922.GB16448@srv03.cluenet.de> <4FBE38D0.6010002@ripe.net> Message-ID: ingrid, > ISPs who exchange routing information with other ISPs at multiple > locations and operate without default routing may request space > directly from the regional registry in its geographical area. it has been fairly well measured that 70% of ASs have some form of default. so kiss a whole bunch of member LIRs goodbye and recover some precious IPv4 address space or fix that wording. i recommend the latter. randy From drc at virtualized.org Thu May 24 18:12:38 2012 From: drc at virtualized.org (David Conrad) Date: Thu, 24 May 2012 09:12:38 -0700 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> Message-ID: Shane, On May 23, 2012, at 11:34 PM, Shane Kerr wrote: > On Thursday, 2012-05-24 07:32:02 +0900, > Randy Bush wrote: >>> The need and the route origination must be in the RIPE NCC service >>> region. >> >> ahem! the ncc has repeatedly said over many years that it has nothing >> to do with routing. > I don't think this is true. Actually, all the RIRs have said this. > I think a more accurate claim is that the RIPE NCC has always said that > they don't guarantee that any resource you are issued can be routed. All the RIRs have also said this. > So, you may need to meet certain routing requirements to qualify for > resources. Historically, this was _not_ the case. Long, long ago, there was a bit of a dust up between the IAB and (at least some) RIR folks that resulted in RFC 1814. However, that was long ago and policies might have changed. Regards, -drc From mueller at syr.edu Thu May 24 21:15:11 2012 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 24 May 2012 19:15:11 +0000 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA098.4010306@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD217BDEC@SUEX10-mbx-10.ad.syr.edu> Tore, Can you provide any reason to maintain territorial exclusivity of assignments in this way? What benefit to the internet or its users is accomplished? > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Tore Anderson > Sent: Wednesday, May 23, 2012 4:32 AM > To: Lu Heng > Cc: Sander Steffann; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Any-cast or uni-cast solutions > > * Lu Heng > > > Almost every hosting company here in EU has customer from outside of > > region, they rent server from EU company for whatever reasons(for > > making their EU website for example), but they are outside of region. > > > > If "end customer from outside of region can not assign IP addresses", > > then all EU hosting company can not sell any hosting package to a > > person in US for example, but that is not the case. > > They can, if the hosted service is in the RIPE service region. > > For example: You (assuming you're located in China) can come to me and > purchase a virtual machine hosted in my data center located in Norway. > It will be numbered using RIPE region address space. No problems. I > could also announce this address space to peers on a Chinese internet > exchange and backhaul the traffic to Norway myself, if I wanted to. > Still no problems there. > > However, if I build a data center in China I cannot use RIPE region > address space to number it. (Even if the customers hosted in that were > all incorporated in the RIPE region.) If this had been permitted, I > doubt there would still be available IPv4 address space in the RIPE > region at this point, as organisations in the APNIC region in need of > IPv4 address space could just have set up LIRs in the RIPE region and > allocate away. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson at redpill-linpro.com Fri May 25 00:34:35 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 25 May 2012 00:34:35 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <855077AC3D7A7147A7570370CA01ECD217BDEC@SUEX10-mbx-10.ad.syr.edu> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD217BDEC@SUEX10-mbx-10.ad.syr.edu> Message-ID: <4FBEB77B.8090708@redpill-linpro.com> * Milton L Mueller > Can you provide any reason to maintain territorial exclusivity of > assignments in this way? No. I wasn't advocating any particular policy, really, just stating what I understood current RIR practise to be (based on how I interpreted the answers given to me by the RIR panel at RIPE61). Ingrid has clarified that my understanding was incorrect, at least when it comes to the RIPE NCC's practises. I have to admit that I do still find it hard to accept that there are no such territorial exclusivity, based on what has happened since APNIC hit their last /8 policy. The high allocation rate seen in the APNIC region didn't shift to other regions, it just vanished overnight. If all it takes for an organisation to allocate addresses from out-of-region RIRs to in-region end-users is to incorporate in that RIRs region, become a LIR there, and peer at an IX there...those are trivial requirements to meet, really, especially if you're desperate of IPv4 addresses. For example, China Telecom had been allocating huge amounts of IPv4 addresses from APNIC up until the day they hit the last /8 policy. As far as I can tell, China Telecom is incorporated in the UK, they are a RIPE NCC member, and are peering on LINX. If that is all it takes to allocated addresses from the RIPE NCC for use anywhere in the world, I find it very hard to understand why China Telecom hasn't simply continued allocating IPv4 addresses from the RIPE NCC in the same rate as they did from from APNIC before they hit the last /8. > What benefit to the internet or its users is accomplished? My current personal opinion is that it would be best if all regions exhausted more or less at the same time, but admittedly, I haven't given this very much thought. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From randy at psg.com Fri May 25 00:54:47 2012 From: randy at psg.com (Randy Bush) Date: Fri, 25 May 2012 07:54:47 +0900 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBEB77B.8090708@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD217BDEC@SUEX10-mbx-10.ad.syr.edu> <4FBEB77B.8090708@redpill-linpro.com> Message-ID: > Ingrid has clarified that my understanding was incorrect and, to my amusement, made clear that current written policy is technically infeasible. randy From gih at apnic.net Fri May 25 06:24:45 2012 From: gih at apnic.net (Geoff Huston) Date: Fri, 25 May 2012 06:24:45 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCAA14.4030903@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> <4FBCAA14.4030903@redpill-linpro.com> Message-ID: <8936DDAC-0416-4200-8610-6AAB48721941@apnic.net> On 23/05/2012, at 11:12 AM, Tore Anderson wrote: > * Tore Anderson > >> That is my understanding, at least. I asked this question to the RIR >> panel at the mic in Rome, whether and APNIC region ISP could (post >> APNIC depletion) set up a LIR in the RIPE region (or any other >> region), and allocate addresses from there and assign them to end >> users in their home region. The answer (which came from Geoff Huston >> IIRC) was something along the lines of ?no, you have to assign the >> addresses in the service region from which they were allocated?. > > Found it: http://ripe61.ripe.net/archives/video/18/ @ 22:03 > I think I said "we expect some alignment to these regions, but this is an expectation not a hard and fast rule", but I seem to have taken a few hundred words to do so! And I made some reference to human inventiveness that may be used to circumvent any such conventional expectations. :-) regards, Geoff From gih at apnic.net Fri May 25 06:12:29 2012 From: gih at apnic.net (Geoff Huston) Date: Fri, 25 May 2012 06:12:29 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA2A3.5090400@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> Message-ID: On 23/05/2012, at 10:41 AM, Tore Anderson wrote: > * Randy Bush > >>> You can announce them anywhere you like. But you cannot assign them to >>> end users outside outside of the region. >> >> really? so i have a /16 from ncc and i spread it over pops in ams, lon, >> and nyc, but i can not have bgp-speaking customers in that address space >> in nyc? if true, that is soooo broken. > > That is my understanding, at least. I asked this question to the RIR > panel at the mic in Rome, whether and APNIC region ISP could (post APNIC > depletion) set up a LIR in the RIPE region (or any other region), and > allocate addresses from there and assign them to end users in their home > region. The answer (which came from Geoff Huston IIRC) was something > along the lines of ?no, you have to assign the addresses in the service > region from which they were allocated?. no - I don't think it was me (unless of course someone pops up with a video recording of me saying exactly that RIPE meeting! :-) ) I am personally of the school of thought that believes that addresses can be used anywhere on or off the planet, irrespective of which RIR provided the original block allocation or assignment. I don't think any other address management regime makes efficient use of either our common routing system or the underlying address plant. > If this was not the case, I would not have expected the APNIC depletion > from significantly slow down the global rate of IPv4 delegations, only > that it would simply shift from the APNIC region to other regions as > IPv4-hungry Asian providers started allocating from other regions. But > looking at http://www.potaroo.net/tools/ipv4/fig09.png for example, this > does not appear to have happened. I was anticipating such a shift in demand myself, and I too am slightly surprised it has not happened. On the other hand I understand that if APNIC sees a member request from an organization with a home address from outside of the APNIC region there is a typical exchange of "have you considered using as your RIR, as you appear to be outside of our regional service zone?" A typical response may be along the lines of "ah yes, but we intended to deploy these addresses in our in-region network". So I suspect that there is a defacto assumption made by many folk about the regional constraints of the use of addresses, but as far as I am aware it is not a rule that is applied by the routing system itself. regards, Geoff (speaking personally in this case, and I'm probably wrong anyway!) From drc at virtualized.org Fri May 25 06:53:01 2012 From: drc at virtualized.org (David Conrad) Date: Thu, 24 May 2012 21:53:01 -0700 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> Message-ID: <7BEFE009-5BC1-4817-979F-99C1BFE9F198@virtualized.org> On May 24, 2012, at 9:12 PM, Geoff Huston wrote: > I was anticipating such a shift in demand myself, and I too am slightly surprised it has not happened. My guess is that the accelerated consumption we saw at the end of the APNIC pool was a 'run on the bank' with folks requesting more space than they actually needed. If true, we'll soon see an uptick in requests at the various RIRs out of the AP region by the larger players (i.e., the ones able to establish legal presence in the respective regions). Unless, of course, those folks are able to have their requirements met via the market. It will be ... interesting to watch. Regards, -drc From randy at psg.com Fri May 25 08:13:37 2012 From: randy at psg.com (Randy Bush) Date: Fri, 25 May 2012 15:13:37 +0900 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <20120524070922.GB16448@srv03.cluenet.de> <4FBE38D0.6010002@ripe.net> Message-ID: good morning ingrid, >> ISPs who exchange routing information with other ISPs at multiple >> locations and operate without default routing may request space >> directly from the regional registry in its geographical area. > > it has been fairly well measured that 70% of ASs have some form of > default. so kiss a whole bunch of member LIRs goodbye and recover > some precious IPv4 address space or fix that wording. i recommend > the latter. to be really clear on this one, see my preso from ripe/praha http://archive.psg.com/100505.ripe-visibility.pdf and the paper R Bush, O Maennel, M Roughan, S Uhlig, "Internet Optometry: Assessing the Broken Glasses in Internet Reachability", ACM SIGCOMM Internet Measurement Conference, November 2009. "operate without default routing" is just not what's happening. randy From jan at go6.si Fri May 25 18:45:54 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 25 May 2012 18:45:54 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> Message-ID: <4FBFB742.50809@go6.si> On 5/25/12 6:12 AM, Geoff Huston wrote: > I was anticipating such a shift in demand myself, and I too am slightly > surprised it has not happened. here we go :) Jan From tvest at eyeconomics.com Fri May 25 19:55:35 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 25 May 2012 13:55:35 -0400 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <4FBCA098.4010306@redpill-linpro.com> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA098.4010306@redpill-linpro.com> Message-ID: On May 23, 2012, at 4:32 AM, Tore Anderson wrote: > * Lu Heng > >> Almost every hosting company here in EU has customer from outside of >> region, they rent server from EU company for whatever reasons(for >> making their EU website for example), but they are outside of region. >> >> If "end customer from outside of region can not assign IP addresses", >> then all EU hosting company can not sell any hosting package to a >> person in US for example, but that is not the case. > > They can, if the hosted service is in the RIPE service region. > > For example: You (assuming you're located in China) can come to me and > purchase a virtual machine hosted in my data center located in Norway. > It will be numbered using RIPE region address space. No problems. I > could also announce this address space to peers on a Chinese internet > exchange and backhaul the traffic to Norway myself, if I wanted to. > Still no problems there. > > However, if I build a data center in China I cannot use RIPE region > address space to number it. (Even if the customers hosted in that were > all incorporated in the RIPE region.) If this had been permitted, I > doubt there would still be available IPv4 address space in the RIPE > region at this point, as organisations in the APNIC region in need of > IPv4 address space could just have set up LIRs in the RIPE region and > allocate away. Apologies in advance for being pedantic, but unless some non-Chinese operator can attest that they have actually done one of those things -- i.e., use non-CNNIC(any) assigned IP resources to interconnect at a China-based IXP, and/or to provide (or even consume) data center services within China, may I suggest that we choose a different country for our hypothetical examples? To my knowledge, none of those things has actually been permissible, at least for the last 10-12 years. Would love to hear that things have now changed, if they have in fact changed -- but unless/until that can be established it would probably be best not to leave false breadcrumb trails that might easily mislead future address-policy-wg readers. Just a thought, TV (who has walked down many such false trails in the past) From mueller at syr.edu Mon May 28 16:59:55 2012 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 28 May 2012 14:59:55 +0000 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <7BEFE009-5BC1-4817-979F-99C1BFE9F198@virtualized.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> <7BEFE009-5BC1-4817-979F-99C1BFE9F198@virtualized.org> Message-ID: <855077AC3D7A7147A7570370CA01ECD217D39D@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > My guess is that the accelerated consumption we saw at the end of the > APNIC pool was a 'run on the bank' with folks requesting more space than > they actually needed. [Milton L Mueller] What?!?! Do you mean to imply that "needs assessment" does not work as advertised? I am shocked, shocked! From shane at time-travellers.org Tue May 29 11:12:46 2012 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 29 May 2012 11:12:46 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> Message-ID: <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> David, On Thursday, 2012-05-24 09:12:38 -0700, David Conrad wrote: > On May 23, 2012, at 11:34 PM, Shane Kerr wrote: > > On Thursday, 2012-05-24 07:32:02 +0900, > > Randy Bush wrote: > >>> The need and the route origination must be in the RIPE NCC service > >>> region. > >> > >> ahem! the ncc has repeatedly said over many years that it has > >> nothing to do with routing. > > I don't think this is true. > > Actually, all the RIRs have said this. I'm pretty sure that the RIPE NCC has said that it can't guarantee route-ability, not that it has nothing to do with routing. Because, frankly, that would be insane considering the whole point of maintaining these databases of who can use which numbers is to allow people to connect computers together on the Internet! Plus the RIPE NCC runs the ROUTING Information Service (RIS), a ROUTING Registry Database (RRD), a ROUTING Public Key Infrastructure (RPKI) effort, attempts ROUTE de-bogonizing, and so on. My understanding is that the RIRs don't want to get involved with peering relationships between LIRs. I assume that the LIRs are also quite happy with the RIRs staying out of their business. > > So, you may need to meet certain routing requirements to qualify for > > resources. > > Historically, this was _not_ the case. Long, long ago, there was a > bit of a dust up between the IAB and (at least some) RIR folks that > resulted in RFC 1814. However, that was long ago and policies might > have changed. In the very first IPv6 allocation policy, we see the following: a. The requesting organization's IPv6 network must have exterior routing protocol peering relationships with the IPv6 networks of at least three other orga- nizations that have a sub-TLA allocated to them. That's RIPE 196, from the late 20th century. I'm not sure if that counts as "historically" or not. ;) Additionally, the AS number form, the IPv6 PI form, and the temporary PI assignment form in the RIPE region *currently* all request information about peering relationships. (I think, but am not sure, that only the AS number assignment actually requires peering though.) -- Shane From bmanning at vacation.karoshi.com Tue May 29 12:45:04 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 29 May 2012 10:45:04 +0000 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> References: <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> Message-ID: <20120529104504.GB24396@vacation.karoshi.com.> On Tue, May 29, 2012 at 11:12:46AM +0200, Shane Kerr wrote: > > I'm pretty sure that the RIPE NCC has said that it can't guarantee > route-ability, not that it has nothing to do with routing. Because, > frankly, that would be insane considering the whole point of > maintaining these databases of who can use which numbers is to allow > people to connect computers together on the Internet! [elided] > > -- > Shane really! thats a bit more restrictive than I remember it. I remember it as: "who can use which numbers [] to allow people to connect computers together." the "on the Internet" part is overly restrictive or was. /bill (an old skool type) From drc at virtualized.org Tue May 29 16:05:43 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 29 May 2012 07:05:43 -0700 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> Message-ID: <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> Shane, On May 29, 2012, at 2:12 AM, Shane Kerr wrote: > I'm pretty sure that the RIPE NCC has said that it can't guarantee > route-ability, not that it has nothing to do with routing. Because, > frankly, that would be insane considering the whole point of > maintaining these databases of who can use which numbers is to allow > people to connect computers together on the Internet! I thought the whole point of maintaining the databases was to ensure uniqueness and provide contact information in the event of network-related issues. That is a necessary but not sufficient requirement for connecting computers together or the Internet. The point of the statement "RIRs have nothing to do with routing" is to emphasize that the other requirements for connecting computers to the Internet are outside of the RIRs' control. Regards, -drc From drc at virtualized.org Tue May 29 16:06:41 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 29 May 2012 07:06:41 -0700 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <855077AC3D7A7147A7570370CA01ECD217D39D@SUEX10-mbx-10.ad.syr.edu> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA2A3.5090400@redpill-linpro.com> <7BEFE009-5BC1-4817-979F-99C1BFE9F198@virtualized.org> <855077AC3D7A7147A7570370CA01ECD217D39D@SUEX10-mbx-10.ad.syr.edu> Message-ID: On May 28, 2012, at 7:59 AM, Milton L Mueller wrote: >> -----Original Message----- >> My guess is that the accelerated consumption we saw at the end of the >> APNIC pool was a 'run on the bank' with folks requesting more space than >> they actually needed. > [Milton L Mueller] > What?!?! Do you mean to imply that "needs assessment" does not work as advertised? > I am shocked, shocked! "Everybody lies." -- Dr. Gregory House. Regards, -drc From jcurran at arin.net Tue May 29 17:42:02 2012 From: jcurran at arin.net (John Curran) Date: Tue, 29 May 2012 15:42:02 +0000 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> Message-ID: On May 29, 2012, at 10:05 AM, David Conrad wrote: > I thought the whole point of maintaining the databases was to ensure uniqueness and provide contact information in the event of network-related issues. That is a necessary but not sufficient requirement for connecting computers together or the Internet. The point of the statement "RIRs have nothing to do with routing" is to emphasize that the other requirements for connecting computers to the Internet are outside of the RIRs' control. David - As you know, RFC 2050 includes "conservation" (fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space) as well as "routability" (distribution of globally unique Internet addresses in a hierarchical manner thus permitting the routing scalability of the addresses) as equally valid goals to consider in the management of IP address space. Some examples where these goals have come into consideration in various regions include policies that provides for provider-independent assignments for those organizations who multi-home, policies that encourage reutilization of unused address space, etc. It is possible that the goals in RFC 2050 are worth reevaluating (in light of IPv4 runout, the nature of IPv6, etc.) but the community has yet to perform that task and so it should not be surprising in the meantime that some policy discussions in the regions may take into consideration more than simply the single goal of ensuring uniqueness. FYI, /John John Curran President and CEO ARIN From drc at virtualized.org Tue May 29 20:10:29 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 29 May 2012 11:10:29 -0700 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> Message-ID: <58A5DF17-9089-427A-BA96-11302CD07C4E@virtualized.org> John, On May 29, 2012, at 8:42 AM, John Curran wrote: > On May 29, 2012, at 10:05 AM, David Conrad wrote: >> The point of the statement "RIRs have nothing to do with routing" is to emphasize that the other requirements for connecting computers to the Internet are outside of the RIRs' control. > It is possible that the goals in RFC 2050 are worth reevaluating (in light of > IPv4 runout, the nature of IPv6, etc.) but the community has yet to perform > that task and so it should not be surprising in the meantime that some policy > discussions in the regions may take into consideration more than simply the > single goal of ensuring uniqueness. I was, of course, speaking of the historical RIRs that focused on being registries. As I stated, policies change. Regards, -drc From jcurran at arin.net Tue May 29 20:36:25 2012 From: jcurran at arin.net (John Curran) Date: Tue, 29 May 2012 18:36:25 +0000 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <58A5DF17-9089-427A-BA96-11302CD07C4E@virtualized.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> <58A5DF17-9089-427A-BA96-11302CD07C4E@virtualized.org> Message-ID: On May 29, 2012, at 2:10 PM, David Conrad wrote: > On May 29, 2012, at 8:42 AM, John Curran wrote: >> It is possible that the goals in RFC 2050 are worth reevaluating (in light of >> IPv4 runout, the nature of IPv6, etc.) but the community has yet to perform >> that task and so it should not be surprising in the meantime that some policy >> discussions in the regions may take into consideration more than simply the >> single goal of ensuring uniqueness. > > I was, of course, speaking of the historical RIRs that focused on being registries. As I stated, policies change. David - I believe that both presently and historically the RIR communities have considered the goals of "conservation" and "routability" in addition to uniqueness. RFC 2050 is, after all, a historic document. With regards to "policies change", if you believe there should be a new registry model where registries consist solely of providing uniqueness and address block contact information, that does indeed appear to be a change in policy and I'd suggest submitting to the appropriate fora. Thanks! /John John Curran President and CEO ARIN From drc at virtualized.org Tue May 29 21:01:33 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 29 May 2012 12:01:33 -0700 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> <58A5DF17-9089-427A-BA96-11302CD07C4E@virtualized.org> Message-ID: John, On May 29, 2012, at 11:36 AM, John Curran wrote: > I believe that both presently and historically the RIR communities have > considered the goals of "conservation" and "routability" in addition to > uniqueness. Sigh. As much as I might enjoy challenging the hairsplitting and revisionism you wish to engage in, I'll pass this time. Perhaps we can just agree to disagree that historically, the RIRs stated that they "have nothing to do with routing" (since I'm sure you'll just continue to ignore the use of the active verb as opposed to the noun "routability"). Enjoy! Regards, -drc From jcurran at arin.net Tue May 29 21:27:12 2012 From: jcurran at arin.net (John Curran) Date: Tue, 29 May 2012 19:27:12 +0000 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> <58A5DF17-9089-427A-BA96-11302CD07C4E@virtualized.org> Message-ID: On May 29, 2012, at 3:01 PM, David Conrad wrote: > > Sigh. As much as I might enjoy challenging the hairsplitting and revisionism you wish to engage in, I'll pass this time. Perhaps we can just agree to disagree that historically, the RIRs stated that they "have nothing to do with routing" (since I'm sure you'll just continue to ignore the use of the active verb as opposed to the noun "routability"). David - I do not claim to know the practices of all of the RIRs, but in the ARIN region we've been very clear to state that ARIN does not control routing of address blocks, specifically - "Polices must allow for aggregation of Internet number resources in a hierarchical manner to permit the routing scalability which is necessary for proper Internet routing. However, polices cannot guarantee routability of any particular Internet number resource as that is dependent on the actions of the individual Internet operators." Saying that RIRs "do not control routing of address blocks" is very different from saying "have nothing do with routing", and in fact ARIN has several sections in number resource policy which consider routing implications. You said "All the RIRs have said [that they have nothing to do with routing]" but that definitely isn't the case with ARIN either past or present, and could't be for any RIR which has a policy which considers state of routing or intended routing in address policy (as anticipated in RFC 2050, in ARIN NRPM AS & multihome policy, as exists in RIPE 196, etc.) Thanks, /John John Curran President and CEO ARIN From jan at go6.si Tue May 29 21:48:20 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 29 May 2012 21:48:20 +0200 Subject: [address-policy-wg] Any-cast or uni-cast solutions In-Reply-To: <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> References: <426B97D7-27BF-4C73-97DE-20F83F86294D@steffann.nl> <4FBC9465.3030101@redpill-linpro.com> <4FBCA5D7.7080200@CC.UniVie.ac.at> <4FBCAA2B.9050104@ripe.net> <4FBCB569.5060204@redpill-linpro.com> <4FBCFF75.9050708@ripe.net> <20120524083451.3a0637c0@shane-eeepc.home.time-travellers.org> <20120529111246.7ec94d46@shane-eeepc.home.time-travellers.org> <6B703535-348B-4415-AB69-82896C7169FE@virtualized.org> Message-ID: <4FC52804.8010305@go6.si> On 5/29/12 4:05 PM, David Conrad wrote: > Shane, > > On May 29, 2012, at 2:12 AM, Shane Kerr wrote: >> I'm pretty sure that the RIPE NCC has said that it can't guarantee >> route-ability, not that it has nothing to do with routing. >> Because, frankly, that would be insane considering the whole point >> of maintaining these databases of who can use which numbers is to >> allow people to connect computers together on the Internet! > > I thought the whole point of maintaining the databases was to ensure > uniqueness and provide contact information in the event of > network-related issues. That is a necessary but not sufficient > requirement for connecting computers together or the Internet. The > point of the statement "RIRs have nothing to do with routing" is to > emphasize that the other requirements for connecting computers to the > Internet are outside of the RIRs' control. The true point is that routing policy was successfully kept out of IETF, because it has no place there (IETF is protocol re-inventing task force). ...and routing policy was successfully kept out of RIPE (and other RIRs communities), because apparently it does not belong there. Do we need another entity, maybe called "routing police"? I'm taking this to extremes with such a naming suggestion, just to make us think about if we need it and if yes, what would be the purpose. Cheers, Jan From mir at ripe.net Wed May 30 15:23:34 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 30 May 2012 15:23:34 +0200 Subject: [address-policy-wg] New on RIPE Labs: IPv4 still business as usual Message-ID: <4FC61F56.5060801@ripe.net> Dear colleagues, In anticipation of reaching the last /8 of IPv4 addresses in the RIPE NCC service region, we have been looking at the number of IPv4 addresses the RIPE NCC handed out over the last four years. The curves look surprisingly uniform. Please read more on RIPE Labs: https://labs.ripe.net/Members/dfk/ipv4-business-as-usual Kind Regards, Mirjam Kuehne RIPE NCC From emadaio at ripe.net Thu May 31 15:21:54 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 31 May 2012 15:21:54 +0200 Subject: [address-policy-wg] 2011-04 Proposal Accepted (Extension of the Minimum Size for IPv6 Initial Allocation) Message-ID: Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-545 has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-04 The updated RIPE Document is ripe-552 and is available at: http://ripe.net/ripe/docs/ripe-552.html Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC