From michel at arneill-py.sacramento.ca.us Sat Oct 1 04:32:27 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 30 Sep 2011 19:32:27 -0700 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie><47C99329-19C2-428C-B692-30FA063A6339@steffann.nl><20110928135535.GA24136@srv03.cluenet.de><20110928205724.GV3290@x27.adm.denic.de><20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF740@newserver.arneill-py.local> > Mikael Abrahamsson wrote: > We still need to in the long term. IPv6 PI, ie keeping state > for all end-users in all DFZ routers on the Internet, does > not scale with billions of routes. We have known that for 20 years; it was part of the very design of IPv6: small, aggregated DFZ. Unfortunately, nobody has been able to deliver it. Another undelivered feature is easy renumbering, which is why we are starting to see all kinds of IPv6 NAT. Time to wake up: Even IPv4 address shortage has not triggered IPv6 adoption; no PI and no NAT are small perks compared to address shortage. > So yes, there is no solution right now, that doesn't mean > IPv6 PI is any kind of long term solution. This is the wording I object. By writing this, you are saying that the quest for the Holy Grail has not stopped and implying that we will find it. Don't get me wrong: 10 years ago I wrote that, too. But now the game has changed: we do not have another 20 or 50 years to deploy IPv6. For the same reasons most have eliminated other protocols such as IPX, Appletalk, DECNET, etc in favor of IPv4, we do not have eternity before people start to fall back on IPv4-only networks, if IPv6 adoption remains at the current levels and growth rate. It's too late to talk about making IPv6 better. The only game left is the survival of IPv6, not dreams for 50 years from now. > We know it's bad, we still use it because there is no better > way right now. That doesn't mean we should give up. I'm saying that not only we should give up, but we must give up. Although they are not the main reason, never-ending changes in deployment strategies are one of the factors that slow down adoption. Time to finalize deployment scenario has come. By keeping the quest for the Holy Grail open, you send the wrong message out. The message you are sending out is that you are still looking for ways to slow distribution of IPv6 PI addresses, and this is one of the things that makes potential adopters run away from it and invest in CGNs instead. > It's again tragedy of the commons. For the individual user, > PI is always the easiest way out. For humanity/Internet as > a whole in the long term, not so much. Denial to recognize the fact that organizations will always go for the easy way out is precisely where we collectively have failed. The grand scheme of doing what is right does not work in the real word. You are still in denial that the initial design objectives have not been met. Michel. From turchanyi.geza at gmail.com Sat Oct 1 09:00:55 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sat, 1 Oct 2011 09:00:55 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF740@newserver.arneill-py.local> References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <392CB277BC2EAE4FB83C1206954BA6CEF740@newserver.arneill-py.local> Message-ID: Hello Michel, What we learned in the past is that PI address disstribution does not scale - it provoques routing tables what we can not handle. This was the reason while CIDR and PA address allocation had benn introduced and even pushed in some extent. On Sat, Oct 1, 2011 at 4:32 AM, Michel Py < michel at arneill-py.sacramento.ca.us> wrote: > > Mikael Abrahamsson wrote: > > We still need to in the long term. IPv6 PI, ie keeping state > > for all end-users in all DFZ routers on the Internet, does > > not scale with billions of routes. > > We have known that for 20 years; it was part of the very design of IPv6: > small, aggregated DFZ. Unfortunately, nobody has been able to deliver > it. Wrong. The IPv6 DFZ is small as an ISP has only 1-2 hugh IPv6 address block. IPv6 PI will destroy this structure, this is the danger. > Another undelivered feature is easy renumbering, which is why we are > starting to see all kinds of IPv6 NAT. > > NAT is used also for monitoring the traffic. IPv6 without NAT is delayed because many organisation wants to monitor the traffic (for company secret keeping, for example) and these companies have no tools at the moment (these tools are under development by operation system developer, wich will allows traffic monitoring at your computer(. > Time to wake up: Even IPv4 address shortage has not triggered IPv6 > adoption; no PI and no NAT are small perks compared to address shortage. > > > Really time to wake up! > > So yes, there is no solution right now, that doesn't mean > > IPv6 PI is any kind of long term solution. > IPv6 PI really not long term solution. > > This is the wording I object. By writing this, you are saying that the > quest for the Holy Grail has not stopped and implying that we will find > it. Don't get me wrong: 10 years ago I wrote that, too. But now the game > has changed: we do not have another 20 or 50 years to deploy IPv6. > > For the same reasons most have eliminated other protocols such as IPX, > Appletalk, DECNET, etc in favor of IPv4, we do not have eternity before > people start to fall back on IPv4-only networks, if IPv6 adoption > remains at the current levels and growth rate. > > It's too late to talk about making IPv6 better. The only game left is > the survival of IPv6, not dreams for 50 years from now. > > > Fully aggree, the the only game left is the survival of the IPv6. AND fast implementation by content providers (which is still the a week point, with a few exeptions and coordinated efforts of Goggle) AND fast provision by massive home network providers. > We know it's bad, we still use it because there is no better > > way right now. That doesn't mean we should give up. > > I'm saying that not only we should give up, but we must give up. > Although they are not the main reason, never-ending changes in > deployment strategies are one of the factors that slow down adoption. > Time to finalize deployment scenario has come. > > By keeping the quest for the Holy Grail open, you send the wrong message > out. The message you are sending out is that you are still looking for > ways to slow distribution of IPv6 PI addresses, and this is one of the > things that makes potential adopters run away from it and invest in CGNs > instead. > > > > It's again tragedy of the commons. For the individual user, > > PI is always the easiest way out. For humanity/Internet as > > a whole in the long term, not so much. > > Denial to recognize the fact that organizations will always go for the > easy way out is precisely where we collectively have failed. The grand > scheme of doing what is right does not work in the real word. > > It must, sorry. However, you are right that we are facing to the social aspects of the Internet transition. We know that the humanity must reduce the green-house effects by reducing CO2 production, we know thast fueling our cars should be drastically changed and we know that massive IPv6 deployment with smart routing table is a must. > You are still in denial that the initial design objectives have not been > met. > Social problems are everywhere, including this mailing list. No surprise. > > Michel. > > Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Sat Oct 1 20:36:25 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 1 Oct 2011 11:36:25 -0700 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20110930051713.GA11849@vacation.karoshi.com.> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> >> Michel Py wrote: >> I hate to sound brutal, but why should I believe that you >> will find the Holy Grail that everyone else has been searching >> for over the last 15 years? I heard it all, I wrote part of it. >> There is NO solution to make renumbering easy and there is NO >> solution nearly as good as PI for multihoming. > Bill Manning wrote: > DFZ slots are for those who pay for them... This is not the way I see it. Paying for DFZ slots is embedded in "cost of doing business" for large / T1 ISPs, and in the recurring charges they charge to smaller ISPs or customers. If there was a monetary value, it would be relatively easy to collect a fee based on the number of prefixes announced upstream. I do not see that happening. It's all about money. The collective cost of announcing a prefix in the DFZ is less than the collective cost of having a complex and impossible to troubleshoot multihoming mechanism based on PA. As long as a DFZ slot does not cost $100 or $1000 a month, organizations will not go for a more complex mechanism. We are several orders of magnitude below the cost threshold. As of ID/LOC schemes, there is this myth that the table is small but in practice large environments will have to maintain a very large ID/LOC map which brings us back to the size of the DFZ again. Michel. From turchanyi.geza at gmail.com Sat Oct 1 22:47:10 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sat, 1 Oct 2011 22:47:10 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: Michel, On Sat, Oct 1, 2011 at 8:36 PM, Michel Py < michel at arneill-py.sacramento.ca.us> wrote: > >> Michel Py wrote: > >> I hate to sound brutal, but why should I believe that you > >> will find the Holy Grail that everyone else has been searching > >> for over the last 15 years? I heard it all, I wrote part of it. > >> There is NO solution to make renumbering easy and there is NO > >> solution nearly as good as PI for multihoming. > > > Bill Manning wrote: > > DFZ slots are for those who pay for them... > > This is not the way I see it. Paying for DFZ slots is embedded in "cost > of doing business" for large / T1 ISPs, and in the recurring charges > they charge to smaller ISPs or customers. If there was a monetary value, > it would be relatively easy to collect a fee based on the number of > prefixes announced upstream. I do not see that happening. > > It's all about money. The collective cost of announcing a prefix in the > DFZ is less than the collective cost of having a complex and impossible > to troubleshoot multihoming mechanism based on PA. As long as a DFZ slot > does not cost $100 or $1000 a month, organizations will not go for a > more complex mechanism. We are several orders of magnitude below the > cost threshold. > I would like to see your calculation. How many line cards have you included? My rough estimation would be about 300 000 line cards today, but is is realy rough, actually I guessed on the AS numbers, multiplied by a not to high constant. DFZ slots must include not only the routers, but the cost of the slowing down of the convergence. This is an issue for all of us. Unfortunately the shortage of the IPv4 space will increase the DFZ already at the IPv4 level. Let us not to create more burden at this stage of the transition. G?za > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aservin at lacnic.net Sat Oct 1 22:53:42 2011 From: aservin at lacnic.net (Arturo Servin) Date: Sat, 1 Oct 2011 17:53:42 -0300 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: Actually, today is not: http://labs.ripe.net/Members/gih/routing-2011 But let's see in a few months. /as On 1 Oct 2011, at 17:47, Turchanyi Geza wrote: > > > Unfortunately the shortage of the IPv4 space will increase the DFZ already at the IPv4 level. Let us not to create more burden at this stage of the transition. > > G?za > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualized.org Sat Oct 1 22:50:59 2011 From: drc at virtualized.org (David Conrad) Date: Sat, 1 Oct 2011 10:50:59 -1000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: On Oct 1, 2011, at 8:36 AM, Michel Py wrote: > As of ID/LOC schemes, there is this myth that the table is small but in > practice large environments will have to maintain a very large ID/LOC > map which brings us back to the size of the DFZ again. The timescales within which lookups in an ID/LOC map must occur are a bit different than those in a FIB. Regards, -drc From turchanyi.geza at gmail.com Sun Oct 2 00:37:00 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sun, 2 Oct 2011 00:37:00 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: Hello Arturo, many thanks for your link! On Sat, Oct 1, 2011 at 10:53 PM, Arturo Servin wrote: > > Actually, today is not: > > http://labs.ripe.net/Members/gih/routing-2011 > > But let's see in a few months. > > /as > > On 1 Oct 2011, at 17:47, Turchanyi Geza wrote: > > > > Unfortunately the shortage of the IPv4 space will increase the DFZ already > at the IPv4 level. Let us not to create more burden at this stage of the > transition. > > I expects increase in the number of the entires in DFZ due to address block trading, splitting... Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmanning at vacation.karoshi.com Sun Oct 2 05:07:49 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 2 Oct 2011 03:07:49 +0000 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: <20111002030749.GA5410@vacation.karoshi.com.> On Sat, Oct 01, 2011 at 10:50:59AM -1000, David Conrad wrote: > On Oct 1, 2011, at 8:36 AM, Michel Py wrote: > > As of ID/LOC schemes, there is this myth that the table is small but in > > practice large environments will have to maintain a very large ID/LOC > > map which brings us back to the size of the DFZ again. > > The timescales within which lookups in an ID/LOC map must occur are a bit different than those in a FIB. > > Regards, > -drc Two words... PRE FETCH /bill From michel at arneill-py.sacramento.ca.us Sun Oct 2 06:02:15 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 1 Oct 2011 21:02:15 -0700 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF742@newserver.arneill-py.local> >> Michel Py wrote: >> As of ID/LOC schemes, there is this myth that the table is >> small but in practice large environments will have to >> maintain a very large ID/LOC map which brings us back to >> the size of the DFZ again. > David Conrad wrote: > The timescales within which lookups in an ID/LOC map > must occur are a bit different than those in a FIB. This is true, but put it back in prospective: the ID/LOC map may gain another order of magnitude. So may Moore's law over a few years, and we're back to square one. Think about it as the TCP sliding window: ID/LOC skews the window a bit, but the gain obtained is questionable compared to the loss due to the increased complexity. How good does it do to you to optimize 100Mbit Ethernet when it is cheaper to build GigE? I'm not saying I like it, but that's the way it is. Simplicity is priceless. Michel. From ebais at a2b-internet.com Sun Oct 2 10:18:40 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 2 Oct 2011 10:18:40 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF742@newserver.arneill-py.local> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> <392CB277BC2EAE4FB83C1206954BA6CEF742@newserver.arneill-py.local> Message-ID: <001401cc80db$e515b520$af411f60$@com> Hi Michel and David, I like a technical discussion about scaling routers probably as much as you, however that is a bit outside the scope of the suggested policy I think. The policy proposal is to get it in line with v4 and also ARIN is having a similar policy. For companies that don't want to deal with the multi-homing requirement currently sign up to become a LIR. This particular part of the v6 policy (the multi-homing requirement) has been an issue for while already and it needs to be fixed. Although nobody can look into the future, experience from the ARIN region, figures from RIPE on PI (v4 and v6) in the DFZ, the supplied de-aggregation info, it doesn't show that with this policy the routing table will explode. As I also stated in my presentation on RIPE 62 in Amsterdam on 2011-02, currently it is a financial discussion for an end-customer, not a technical one. An end-customer can already decide for v6 without the multi-homing requirement, but somehow an end-customers that can't become a LIR or don't see themselves as an ISP, can't deploy v6 because they have no multi-homed network setup. There are people unlike ourselves, that just don't want to deal with the RIPE 'stuff' and are happy to leave that up to others if they can. Will this policy open the gates for everything to start requesting everything they like ? No. There are still other limitations in v6 that we don't see in v4 (like restrictions for colocation or DSL/access address usage, sub-allocation etc. ) You still need PA for those kind of requests. Kind regards, Erik Bais From nick at inex.ie Sun Oct 2 11:39:50 2011 From: nick at inex.ie (Nick Hilliard) Date: Sun, 02 Oct 2011 10:39:50 +0100 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> Message-ID: <4E883166.107@inex.ie> On 01/10/2011 19:36, Michel Py wrote: > It's all about money. The collective cost of announcing a prefix in the > DFZ is less than the collective cost of having a complex and impossible > to troubleshoot multihoming mechanism based on PA. As long as a DFZ slot > does not cost $100 or $1000 a month, organizations will not go for a > more complex mechanism. We are several orders of magnitude below the > cost threshold. Can we move past this notion of charging for DFZ slots? There is no practical way of doing it and constantly harping on about it is pointless and distracting. Nick From gert at space.net Sun Oct 2 19:51:23 2011 From: gert at space.net (Gert Doering) Date: Sun, 2 Oct 2011 19:51:23 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: References: <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> Message-ID: <20111002175123.GX72014@Space.Net> Hi, On Fri, Sep 30, 2011 at 05:43:37PM +0200, Martin Millnert wrote: > I was actually looking for you the other day on IRC... I saw a couple > of /48's in DFZ coming not from PIv6, but allocated by LIR's (thus, > announced with different origin than the /32 they came from), the > other day. IIRC, your data captured these [ easier-than-PIv6 ] > allocations as well. Is that right? My scripts break down the numbers by raw size (so-many /48s, so-many /32s), which is where the numbers that Sander posted came from - so it's actually even less PIv6 than /48s out there, yes: http://www.space.net/~gert/RIPE/R62-v6-table/page24.html I have another script that breaks down the numbers by region and by category (PA/PI/IXP/...), but haven't run that one since May - the May numbers are here: http://www.space.net/~gert/RIPE/R62-v6-table/page26.html http://www.space.net/~gert/RIPE/R62-v6-table/page28.html the "more specifics from PA netblocks" show up in the "subnets" column of the "LIR" rows, and indeed, in May we had about 1800 PA deaggregates in the table, of about 5500 routes in total. I'll re-run these scripts some time next week, and post fully up-to-date numbers. > It would be interesting to see graphs of these and over time, if > possible, to try and detect and correlate changes with policy, > somehow. In slide 26 you can get an idea on the effects of PI on the global table over time. That slide shows the majority of "non-PA" routes to be from the ARIN region (which is in line with them having the first IPv6 PI policy at all, and a fairly liberal with that), and they had reached ~700 "non-PA" routes in May (with ~1400 "PA" routes). You can't really see policy changes there, except for the "from now on, you can have PI!" kickoff - but what you can see is the effect of the RIR IPv6 marketing campaigns, notably APNIC in early 2010. Gert Doering -- with the IPv6 numbers hat on -- 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Sun Oct 2 19:55:39 2011 From: gert at space.net (Gert Doering) Date: Sun, 2 Oct 2011 19:55:39 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <4E85D183.2080902@inex.ie> References: <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E85D183.2080902@inex.ie> Message-ID: <20111002175539.GY72014@Space.Net> Hi, On Fri, Sep 30, 2011 at 03:26:11PM +0100, Nick Hilliard wrote: > On 30/09/2011 09:28, Turchanyi Geza wrote: > > In summary: we do not have the technology which would allow a very liberal > > PI allocation policy, therefore a very liberal PI allocation policy is not > > possible now. > > > > Strict limits must be kept. > > I get the impression that people are talking about something which lies > somewhere between "very liberal" and "strict limits". Indeed, and to stress a point that Mikael has already made: even with that change, it's still not "single click" easy to get PIv6. PIv6 still needs application forms to be filled, a contract to be signed, and yearly fees to be paid - which shifts the balance somewhat away from "PIv6 is the easy way" (but if people have appropriate usage scenarios, it's still *possible* to get PIv6). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From michel at arneill-py.sacramento.ca.us Sun Oct 2 21:01:05 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 2 Oct 2011 12:01:05 -0700 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <001401cc80db$e515b520$af411f60$@com> References: <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <20110930051713.GA11849@vacation.karoshi.com.> <392CB277BC2EAE4FB83C1206954BA6CEF741@newserver.arneill-py.local> <392CB277BC2EAE4FB83C1206954BA6CEF742@newserver.arneill-py.local> <001401cc80db$e515b520$af411f60$@com> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF743@newserver.arneill-py.local> > Erik Bais wrote: > Hi Michel and David, > I like a technical discussion about scaling routers > probably as much as you, however that is a bit outside > the scope of the suggested policy I think. It is, guilty as charged. I apologize. I support the policy. Anything that can facilitate IPv6 deployment today has to be done, regardless of long-term consequences and even if it means establishing precedents that nobody really likes. Michel. From millnert at gmail.com Mon Oct 3 18:04:10 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 3 Oct 2011 18:04:10 +0200 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: <20110728143102.GE6394@x27.adm.denic.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728004352.GA69269@cilantro.c4inet.net> <002A367D-623E-4588-AA41-7A190841718F@rfc1035.com> <20110728143102.GE6394@x27.adm.denic.de> Message-ID: (FYI only), On Thu, Jul 28, 2011 at 4:31 PM, Peter Koch wrote: >?One of the problems is that 2008-08 was about the "how", not the "if". A related follow-up on the 'if', w.r.t centralization of routing infrastructure/authority (or, by extension, name-lookup systems and ... default-installed, trusted root CAs): http://isoc.org/wp/newsletter/?p=4639 "The open, decentralized, and global nature of the Internet has set the foundation for an unprecedented growth for the potential of freedom of expression and peaceful assembly throughout the world. " Kind regards, Martin From millnert at gmail.com Mon Oct 3 18:49:56 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 3 Oct 2011 18:49:56 +0200 Subject: [address-policy-wg] Proposal 2011-02 moving to Last Call In-Reply-To: <20111002175123.GX72014@Space.Net> References: <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <20111002175123.GX72014@Space.Net> Message-ID: Geert, thanks! On Sun, Oct 2, 2011 at 7:51 PM, Gert Doering wrote: >> It would be interesting to see graphs of these and over time, if >> possible, to try and detect and correlate changes with policy, >> somehow. > > In slide 26 you can get an idea on the effects of PI on the global > table over time. ?That slide shows the majority of "non-PA" routes to > be from the ARIN region (which is in line with them having the first > IPv6 PI policy at all, and a fairly liberal with that), and they had > reached ~700 "non-PA" routes in May (with ~1400 "PA" routes). > > You can't really see policy changes there, except for the "from now on, > you can have PI!" kickoff - but what you can see is the effect of the RIR > IPv6 marketing campaigns, notably APNIC in early 2010. I was unclear. I meant, from now on and into the future. :) (ie, keep doing the stats.) Looking forward for your re-run. Thanks again, Regards, Martin From Woeber at CC.UniVie.ac.at Mon Oct 3 20:12:40 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 03 Oct 2011 18:12:40 +0000 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> Message-ID: <4E89FB18.7090700@CC.UniVie.ac.at> Turchanyi Geza wrote: [...] > So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow a > few hundred thousands more IPv6 routes at all (not even would allow an 0.25M > IPv6 limit) -- and speed of processing is an other issue... Even right now a large proportion of the router boxes on the Internet are *not* capable of dealing with the full routing table in the DFZ. This has been the case for many years already, btw. Still the 'net was and is pretty healthy and packets get shipped to the correct destination. [...] > Strict limits must be kept. I still believe that it is the ISPs' job to manage the DFZ and to decide which prefixes to accept - or maybe not. I am pretty sure that the PI address blocks are taken from a well-documented space, so it is up to the (individual) ISP(s) to manage their routing environment. I do not see a mandate for the policy and/or the NCC to prohibit a (maybe small) number of participants from doing "the right thing" - from their point of view. In the very end, the money that keeps the IPSs going and earning money is coming from customers, isn't it? :-) > Thanks, > > G?za Cheers, Wilfried. From maildanrl at googlemail.com Tue Oct 4 08:41:59 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Tue, 4 Oct 2011 08:41:59 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <20111002175539.GY72014@Space.Net> References: <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E85D183.2080902@inex.ie> <20111002175539.GY72014@Space.Net> Message-ID: It is time for PIv6 to become really as easy as * filling out the form (as one did for PIv4) * signing the contract (as one did for PIv4) * paying the fees (as one did for PIv4). I have seen people using SixXS tunnels to be more provider independent. Seriously! Tunneling the traffic of hosts/servers, who are IPv6 capable and well-konfigured through IPv4 is not what we want at all, is it? regards, Dan Luedtke -- danrl / Dan Luedtke http://www.danrl.de From turchanyi.geza at gmail.com Tue Oct 4 09:38:57 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 4 Oct 2011 09:38:57 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <4E89FB18.7090700@CC.UniVie.ac.at> References: <4E7C929D.2020901@inex.ie> <47C99329-19C2-428C-B692-30FA063A6339@steffann.nl> <20110928135535.GA24136@srv03.cluenet.de> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E89FB18.7090700@CC.UniVie.ac.at> Message-ID: Hello Wilfried, On Mon, Oct 3, 2011 at 8:12 PM, Wilfried Woeber, UniVie/ACOnet < Woeber at cc.univie.ac.at> wrote: > Turchanyi Geza wrote: > [...] > > So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow > a > > few hundred thousands more IPv6 routes at all (not even would allow an > 0.25M > > IPv6 limit) -- and speed of processing is an other issue... > > Even right now a large proportion of the router boxes on the Internet are > *not* capable of dealing with the full routing table in the DFZ. This has > been the case for many years already, btw. Still the 'net was and is pretty > healthy and packets get shipped to the correct destination. > Well, what you say is true, however, it is easy to interpret it in a wrong way. What I says: before accepteng a "principle", or policy, we should be able to understand, at least roughly, the financial consequences. I also says, that I seriously doubt that the PI space allocation should be "liberized" in order to push through the IPv6 deployment. The first real question, what will be, or might be the consequence if DFZ routing table growth further significantly. Please keep in your calculation that an IPv6 entry need twice as much address space in the routing table than an IPv4 entries. The conseqences are two folds: SLOW DOWN in the routing and forced upgrade of ALL routing cards that are able to support "only" 0,5M IPv4 routing entries AND are involved in DFZ zone handling. I think, it would be crucial to know how many router cards would be included in the Internet today. I made a very a rough estimation: 300 000 cards. Of course, there are much more cards in the backbones. May be I am wrong, however, please do not neglect this issue. Let's clarify first: roughly how many router cards MUST be upgraded if the typical 0,5M limit reached (counting twice en IPv6 enty). In parallel, we should better understand the slow-down consequences as well. > [...] > > > Strict limits must be kept. > The above mentionned limits are the strict limits, not to forget. http://labs.ripe.net/Members/gih/routing-2011 The picture of Geoff Huston shows that we are getting too close to the typical existing limits. > I still believe that it is the ISPs' job to manage the DFZ and to decide > which > prefixes to accept - or maybe not. I am pretty sure that the PI address > blocks > are taken from a well-documented space, so it is up to the (individual) > ISP(s) > to manage their routing environment. > NO, we should not dreams about policy blindly and we should not separate our knowledge and question marks. > I do not see a mandate for the policy and/or the NCC to prohibit a (maybe > small) > number of participants from doing "the right thing" - from their point of > view. > We are responsible for the problems provoked by the grows of the Internet. > > In the very end, the money that keeps the IPSs going and earning money is > coming > from customers, isn't it? :-) > Well, this statement might be read that my approach is not customer oriented enough. In opposite, it is. I do not want to suggest "solutions" for customers that would slow down the Internet and increase seriously the price of the service if these "solutions" would not be used just in very exeptional case. Slowing down the internet is not customer freindly at all. Increasing the service price would be? I am pretty sure that IPv6 PI space needed only in very exeptional cases, and I also pretty sure that we MUST say this to everybody clearly and without delay. Your freind since 20 years, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Tue Oct 4 09:51:08 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 4 Oct 2011 09:51:08 +0200 (CEST) Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E89FB18.7090700@CC.UniVie.ac.at> Message-ID: On Tue, 4 Oct 2011, Turchanyi Geza wrote: > Let's clarify first: roughly how many router cards MUST be upgraded if > the typical 0,5M limit reached (counting twice en IPv6 enty). > > In parallel, we should better understand the slow-down consequences as > well. While I agree with you, this is way too late, and people don't generally care about this cost (at least not officially). RIPE is disconnected from routing, and the routing subsystem is not something people generally care about in this policy wg (my opinion). RIPE hands out addresses, they do not do routing. So let's make the IPv6 PI policy the same as IPv4 (remove multihoming) and then we monitor growth. When it hits 100k IPv6 PI (or some other number) prefixes, let's review again. My dystopian view is that this won't be fixed but instead vendors will have to create routers that can handle many million of routes in the next decades. This will cost a lot of money, but that might still be cheaper than trying to get smaller ISPs and enterprise to aquire and handle renumbering mechanisms that haven't even been developed yet. -- Mikael Abrahamsson email: swmike at swm.pp.se From turchanyi.geza at gmail.com Tue Oct 4 10:21:22 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 4 Oct 2011 10:21:22 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E89FB18.7090700@CC.UniVie.ac.at> Message-ID: Hello Mikael, On Tue, Oct 4, 2011 at 9:51 AM, Mikael Abrahamsson wrote: > On Tue, 4 Oct 2011, Turchanyi Geza wrote: > > Let's clarify first: roughly how many router cards MUST be upgraded if the >> typical 0,5M limit reached (counting twice en IPv6 enty). >> >> In parallel, we should better understand the slow-down consequences as >> well. >> > > While I agree with you, this is way too late, and people don't generally > care about this cost (at least not officially). RIPE is disconnected from > routing, and the routing subsystem is not something people generally care > about in this policy wg (my opinion). > > RIPE hands out addresses, they do not do routing. > Well, there was a routing-wg of RIPE... > > So let's make the IPv6 PI policy the same as IPv4 (remove multihoming) and > then we monitor growth. When it hits 100k IPv6 PI (or some other number) > prefixes, let's review again. > > NO.Address allocation should not follow "a la mode" trends. The limits of the existing infrastrucure should not be forgotten. My dystopian view is that this won't be fixed but instead vendors will have > to create routers that can handle many million of routes in the next > decades. This will cost a lot of money, but that might still be cheaper than > trying to get smaller ISPs and enterprise to aquire and handle renumbering > mechanisms that haven't even been developed yet. > > > I do not want to stop the development at all. BUT. let's first develop the new technology, test it, prove it, then we might enjoy the freedom created. BUT doing the other way around will create just mess. Or even a collapse, within one or may be one and half year. Please think about this limit also. > -- > Mikael Abrahamsson email: swmike at swm.pp.se > Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.eriksson at iis.se Tue Oct 4 10:18:21 2011 From: jorgen.eriksson at iis.se (=?Windows-1252?Q?J=F6rgen_Eriksson?=) Date: Tue, 4 Oct 2011 10:18:21 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E89FB18.7090700@CC.UniVie.ac.at> Message-ID: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> On Tue, 4 Oct 2011, Mikael Abrahamsson wrote: >My dystopian view is that this won't be fixed but instead vendors will >have to create routers that can handle many million of routes in the >next decades. > As they have done during the last 20+ years. This is the way of the Internet. If you want to be there - keep upgrading! Yes, it cost money. Big money. And if your business case does not include this - sorry, but then you have done a really bad job! /Jorgen From rhe at nosc.ja.net Tue Oct 4 11:27:08 2011 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 4 Oct 2011 10:27:08 +0100 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E89FB18.7090700@CC.UniVie.ac.at> Message-ID: > > RIPE hands out addresses, they do not do routing. > > Well, there was a routing-wg of RIPE... Was and is, and indeed perhaps some of the discussion on where the routing table for IPv4 and IPv6 may be in a decade is best suited for that list. I will, however, proffer a reminder that the RIPE NCC hands out addresses based on policies that the RIPE community decides. This discussion on 2011-02 is in 'last call,' which is supposed to mean that 'we as a community have reached consensus, are there any major show-stoppers we have missed?' Perhaps we can move the future of routing discussion over to the routing working group (although having an aim for the discussion would be useful) and leave the discussion on this list to either 'nothing new, carry on' or 'whoah! we've completely missed this before.' All the best, Rob From michel at arneill-py.sacramento.ca.us Tue Oct 4 18:19:00 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 4 Oct 2011 09:19:00 -0700 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> References: <4E7C929D.2020901@inex.ie><20110928205724.GV3290@x27.adm.denic.de><20110929185645.GY72014@Space.Net><392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local><4E89FB18.7090700@CC.UniVie.ac.at> <983F177 05339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> > Mikael Abrahamsson wrote: > My dystopian view is that this won't be fixed but instead > vendors will have to create routers that can handle many > million of routes in the next decades. Indeed. And, somewhere at Cisco and Juniper, someone doesn't mind that this will require very expensive TCAM (or whatever comes next) in the forwarding plane and fancy ASICs to push packets at Terabit wire speed. That's what their business is about. > J?rgen Eriksson wrote: > As they have done during the last 20+ years. This is the way > of the Internet. If you want to be there - keep upgrading! Yes, > it cost money. Big money. And if your business case does not > include this - sorry, but then you have done a really bad job! I will not be sorry. Buying out the customers of incapable competitors when they go belly up does not shock me. Michel. From he at uninett.no Tue Oct 4 19:14:19 2011 From: he at uninett.no (Havard Eidnes) Date: Tue, 04 Oct 2011 19:14:19 +0200 (CEST) Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> Message-ID: <20111004.191419.388904311.he@uninett.no> >> Mikael Abrahamsson wrote: >> My dystopian view is that this won't be fixed but instead >> vendors will have to create routers that can handle many >> million of routes in the next decades. > > Indeed. And, somewhere at Cisco and Juniper, someone doesn't > mind that this will require very expensive TCAM (or whatever > comes next) in the forwarding plane and fancy ASICs to push > packets at Terabit wire speed. That's what their business is > about. Well... So far Cisco and Juniper have been able to piggyback their use of TCAM resources with what's available in the marketplace. From what I've picked up from reputable sources, we're pushing the limits, and Moore's law does not appear to apply to the rather specialized market of humungous TCAM chips. I'm not sufficiently of an optimist that I think we won't hit a technological limit in the case of us collectively injecting too much entropy into the global routing table. Therefore I've voiced my concerns over this proposal earlier, and I continue to hold this view. Regards, - H?vard From nick at inex.ie Tue Oct 4 19:35:58 2011 From: nick at inex.ie (Nick Hilliard) Date: Tue, 04 Oct 2011 18:35:58 +0100 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <20111004.191419.388904311.he@uninett.no> References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> Message-ID: <4E8B43FE.80905@inex.ie> On 04/10/2011 18:14, Havard Eidnes wrote: > Well... So far Cisco and Juniper have been able to piggyback their > use of TCAM resources with what's available in the marketplace. From > what I've picked up from reputable sources, we're pushing the limits, > and Moore's law does not appear to apply to the rather specialized > market of humungous TCAM chips. TCAM is not the only lookup system suitable for packet forwarding lookups: Juniper have been using RLDRAM II since 2007 (FCS of m120). And Cisco have started using RLDRAM in the ASR1000 packet processing engine. I'm not trying to understate how difficult this sort of thing is, btw. Packet forwarding engines are hard. Nick From millnert at gmail.com Tue Oct 4 20:36:54 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 4 Oct 2011 20:36:54 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <4E7C929D.2020901@inex.ie> <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <392CB277BC2EAE4FB83C1206954BA6CEF73E@newserver.arneill-py.local> <4E89FB18.7090700@CC.UniVie.ac.at> Message-ID: On Tue, Oct 4, 2011 at 9:51 AM, Mikael Abrahamsson wrote: > RIPE is disconnected from routing, and the routing subsystem is not > something people generally care about in this policy wg (my opinion). > > RIPE hands out addresses, they do not do routing. This is quite true. There's no minimum IPv4 PI assignment size, for example. Best, Martin From michel at arneill-py.sacramento.ca.us Wed Oct 5 02:07:33 2011 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 4 Oct 2011 17:07:33 -0700 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <20111004.191419.388904311.he@uninett.no> References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se><392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> > Havard Eidnes wrote: > From what I've picked up from reputable sources, we're pushing > the limits, and Moore's law does not appear to apply to the > rather specialized market of humungous TCAM chips. I'm not > sufficiently of an optimist that I think we won't hit a > technological limit in the case of us collectively injecting > too much entropy into the global routing table. Getting back to the policy part and not the technicalities of forwarding plane implementation: this is not the point. Keep in mind that part the very design of IPv6 is precisely the uncertainties around hitting a wall at some point. 10 years ago, I defended your position for the same reasons you do, and I am not among those saying that there is no risk, or that it will work the next 20 years the same way it worked the past 20. Nobody has a crystal ball. Here is the point: now the name of the game is no longer making it right, it's making it happen at all. We do not have the luxury of contemplating a 15 year deployment horizon anymore. What we are weighing in now are 2 opposite risks: the risk of hitting a wall in DFZ size in the future, against the risk of a total deployment failure. Michel. From turchanyi.geza at gmail.com Wed Oct 5 09:18:11 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 5 Oct 2011 09:18:11 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: On Wed, Oct 5, 2011 at 2:07 AM, Michel Py < michel at arneill-py.sacramento.ca.us> wrote: > > Havard Eidnes wrote: > > From what I've picked up from reputable sources, we're pushing > > the limits, and Moore's law does not appear to apply to the > > rather specialized market of humungous TCAM chips. I'm not > > sufficiently of an optimist that I think we won't hit a > > technological limit in the case of us collectively injecting > > too much entropy into the global routing table. > > Getting back to the policy part and not the technicalities of forwarding > plane implementation: this is not the point. > > Keep in mind that part the very design of IPv6 is precisely the > uncertainties around hitting a wall at some point. 10 years ago, I > defended your position for the same reasons you do, and I am not among > those saying that there is no risk, or that it will work the next 20 > years the same way it worked the past 20. Nobody has a crystal ball. > > Here is the point: now the name of the game is no longer making it > right, it's making it happen at all. We do not have the luxury of > contemplating a 15 year deployment horizon anymore. What we are weighing > in now are 2 opposite risks: the risk of hitting a wall in DFZ size in > the future, against the risk of a total deployment failure. > Blowing up the DFZ zone wont accelerate the deployement of IPv6, in opposite, it will make harder to maintain the IPv4 service as well. The crucial points of the delay of IPv6 deployement are the following - load balancing at the content provision providers' site; - home network transition; - traffic monitoring at the entreprise, where the enterprise management would like to control and monitor, what is going on. For the later point the Obama administration defined a deadline of September 2012, if I remember well. There is a new working group at IETF for home network transition, started this summer. Unfortunatly the loadbalancing issues are vendor specifics. So these issues create delay, unfortunately. I still missed the arguments why would provide any help in the transition if PI allocations would be "liberized", just to be pleased for a small set of PI belivers? If PI belivers happen to complete their transition as the last ones, in two yeears -- should we care? Blowing up the DFZ is a big problem. It should not happen in the near future. Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Wed Oct 5 11:39:49 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 5 Oct 2011 11:39:49 +0200 (CEST) Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: On Wed, 5 Oct 2011, Turchanyi Geza wrote: > I still missed the arguments why would provide any help in the > transition if PI allocations would be "liberized", just to be pleased > for a small set of PI belivers? Well, there are many tens of thousands of them in the RIPE region alone, don't know if that can be called "small". > Blowing up the DFZ is a big problem. It should not happen in the near > future. If IPv6 PI follows IPv4 PI, it's not going to blow up in the near future. My worry is long term, not short term. -- Mikael Abrahamsson email: swmike at swm.pp.se From turchanyi.geza at gmail.com Wed Oct 5 21:52:26 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 5 Oct 2011 21:52:26 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: On Wed, Oct 5, 2011 at 11:39 AM, Mikael Abrahamsson wrote: [..] > If IPv6 PI follows IPv4 PI, it's not going to blow up in the near future. > > My worry is long term, not short term. > > If the policy guaranties this, its OK. However, what is your guess: how many IPv4 routing entries will be the in the DFZ table in November 2011 and how many in November 2012? In November 2013? Roughly, in two years? What will slow down the growth? What might increase? How many IPv6 entries can be added if the total capacity of the line card is 0.5M IPv4 routing entry? Lets see: http://labs.ripe.net/Members/gih/BGPRoutingTable2011.png If there are no more IPv4 addresses to be allocated by the RIRs, the routing tably still will increase due to exchangeng (selling) slots of addresses. OK. if we would be able to stop the increase of the IPv4 address entries at 440 000 then we would have rooms for 30 000 IPv6 routing entries. 30 000 IPv6 entries are not too many, there are more AS in use today. Therefore it would be better to stop the increase at lower level - otherwise huge investment will be needed world wide soon. In the other hand if the small IP address slots would be very limited both at IPv4 and IPv6 level then the IPv4->IPv6 transition could be executed with the line cards capable to handle 0.5M IPv4 routes. Either we restrict ourself within a narrow lane or hugh investments AND toleration of SLOW DOWN is unavoidable. Best, G?za > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From millnert at gmail.com Wed Oct 5 23:47:47 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 5 Oct 2011 23:47:47 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: Turchanyi, It looks like we're circulating back to the same implementation-specific, 10-year-old-router-design arguments: On Wed, Oct 5, 2011 at 9:52 PM, Turchanyi Geza wrote: > On Wed, Oct 5, 2011 at 11:39 AM, Mikael Abrahamsson > wrote: > > [..] > >> >> If IPv6 PI follows IPv4 PI, it's not going to blow up in the near future. >> >> My worry is long term, not short term. > How many IPv6 entries can be added if the total capacity of the line card is > 0.5M IPv4 routing entry? If the capacity of any packet forwarding engine cannot fit X+Y route entries, it cannot fit X+Y route entries. Gotcha. While I speak only for myself, I think I dare say that your voice of reservation towards the policy proposal has been heard on the list. Best, Martin From randy at psg.com Thu Oct 6 00:45:56 2011 From: randy at psg.com (Randy Bush) Date: Thu, 06 Oct 2011 07:45:56 +0900 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: > While I speak only for myself, I think I dare say that your voice of > reservation towards the policy proposal has been heard on the list. aside from geza, a lot of old dogs have expressed similar reservations. geza has just had more persistence than the rest of us. randy From maildanrl at googlemail.com Thu Oct 6 07:36:43 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Thu, 6 Oct 2011 07:36:43 +0200 Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: Hella Geza, On Wed, Oct 5, 2011 at 9:52 PM, Turchanyi Geza wrote: > How many IPv6 entries can be added if the total capacity of the line card is > 0.5M IPv4 routing entry? Are there no line cards with larger capacity in development? Will we still be limited to 0.5M when the problem (i think it is a long term problem) arises? Don't get me wrong, I know what your concerns are, and I think you have good reason for them. I just don't like fitting IPv6 development (if there still is one, sometimes we are just stuck) into routers, I would rather change the routers to cope with the "new" technology. I haven't seen much line cards holding DFZ in my life, since I used quagga and bird. Why is this such a big problem with those line cards? Is it _our_ problem or the _vendors_ one, once the table reaches 0.5M? Would you buy a line card that cannot handle your line? regards, danrl From swmike at swm.pp.se Thu Oct 6 07:55:57 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 6 Oct 2011 07:55:57 +0200 (CEST) Subject: [address-policy-wg] scaling # of prefixes Re: Proposal 2011-02 moving to Last Call In-Reply-To: References: <983F17705339E24699AA251B458249B57F8F4CB7BB@EXCHANGE2K7.office.nic.se> <392CB277BC2EAE4FB83C1206954BA6CEF746@newserver.arneill-py.local> <20111004.191419.388904311.he@uninett.no> <392CB277BC2EAE4FB83C1206954BA6CEF747@newserver.arneill-py.local> Message-ID: On Thu, 6 Oct 2011, Dan Luedtke wrote: > Are there no line cards with larger capacity in development? Will we > still be limited to 0.5M when the problem (i think it is a long term > problem) arises? There are very few platforms today with a 0.5M limit, buying them even a few years back, would be a mistake. The most popular platforms I would say have a 1M or more forwarding table limit, meaning they'll do ~750k IPv4 and 125k IP6 routes (IPv6 takes double space) or 500k IPv4 and 250 IPv6 routes, or any mix in between. There are platforms on the market that do twice this, and scalability numbers keep going up. I'd say the route ratios (routes in DFZ and number of routes handled by cutting edge platforms) and convergence times have been fairly constant in the last 10 years, even as IPv4 routes have gone from ~100-150k to 350k. There is plenty of equipment developed 10+ ago that still can handle the current number of DFZ routes. However, there is still a cost to this as equipment will have to be replaced due to their route memory not being enough, instead of other factors (forwarding speed for example). This is still a problem, it's still costing money, but I'd venture to guess it's not big enough amount to make sure someone will actually fix this. As long as we keep the current growth rate, it's not really a technical problem. It also means there won't be any improvement in convergence time, which actually IS a technical problem, but not one seen to be a big enough of a problem either, I guess. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Tue Oct 11 18:15:40 2011 From: gert at space.net (Gert Doering) Date: Tue, 11 Oct 2011 18:15:40 +0200 Subject: [address-policy-wg] Items for the AP WG meeting agenda? Message-ID: <20111011161540.GX72014@Space.Net> Hi APWG folks, RIPE 63 is nearing, and Sander and I are working on the agenda for the meeting. We have three time slots: Wednesday, 09:00-12:30, and Thursday, 09:00-10:30, so we have plenty of time to discuss things that *you* want to see discussed... So far the agenda has all the usual stuff (reporting on the PDP, discussion of open policy proposals), which will be published in the next days - we're still working on details, and waiting for some confirmations. If there is anything non-standard that you want to see, please let me or Sander know. 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 emadaio at ripe.net Thu Oct 20 13:19:53 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 20 Oct 2011 13:19:53 +0200 Subject: [address-policy-wg] 2006-05 Proposal Accepted (PI Assignment Size) Message-ID: Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-527, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05 The updated RIPE document is ripe-528 and is available at: http://www.ripe.net/ripe/docs/ripe-528 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Thu Oct 20 16:39:01 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 20 Oct 2011 16:39:01 +0200 Subject: [address-policy-wg] 2011-01 Proposal Accepted (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA) Message-ID: Dear Colleagues, Consensus has been reached, and the proposal described in 2011-01, "Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01 The new RIPE document is ripe-529 and is available at: http://www.ripe.net/ripe/docs/ripe-529 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Fri Oct 21 12:44:55 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 21 Oct 2011 12:44:55 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) 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: www.ripe.net/ripe/policies/proposals/2011-04 We encourage you to review this proposal and send your comments to before 18 November 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From boggits at gmail.com Fri Oct 21 13:01:12 2011 From: boggits at gmail.com (boggits) Date: Fri, 21 Oct 2011 12:01:12 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <1319193932_16094@mail.webtapestry.net> References: <1319193932_16094@mail.webtapestry.net> Message-ID: On 21 October 2011 11:44, Emilio Madaio wrote: > ? ?www.ripe.net/ripe/policies/proposals/2011-04 Okay, I can see the logic, but please can we not do this :) I'm all for allowing a policy that says LIR can request a /29 rather than a /32 and that deploying 6rd is a valid reason for allocating a /29 as an initial block but can we do this by having the LIR send the documentation in and having it reviewed for logic. J -- James Blessing 07989 039 476 From gert at space.net Fri Oct 21 13:42:00 2011 From: gert at space.net (Gert Doering) Date: Fri, 21 Oct 2011 13:42:00 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> Message-ID: <20111021114200.GB72014@Space.Net> Hi, On Fri, Oct 21, 2011 at 12:01:12PM +0100, boggits wrote: > On 21 October 2011 11:44, Emilio Madaio wrote: > > ? ?www.ripe.net/ripe/policies/proposals/2011-04 > > Okay, I can see the logic, but please can we not do this :) > > I'm all for allowing a policy that says LIR can request a /29 rather > than a /32 and that deploying 6rd is a valid reason for allocating a > /29 as an initial block but can we do this by having the LIR send the > documentation in and having it reviewed for logic. The feedback we got at the last RIPE meeting was "please do not tie this to a specific transition technology, and go down the rathole of potentially having to revoke the allocation if 6rd is no longer in use". So the proposers have decided to go for the "minimum fuzz" thing - ask for it, get it. I'm not exactly sure how you're proposing to modify this? "Special case for 6rd only"? 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 boggits at gmail.com Fri Oct 21 14:02:16 2011 From: boggits at gmail.com (boggits) Date: Fri, 21 Oct 2011 13:02:16 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111021114200.GB72014@Space.Net> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> Message-ID: On 21 October 2011 12:42, Gert Doering wrote: > I'm not exactly sure how you're proposing to modify this? ?"Special case > for 6rd only"? Send a guidance note... "Dear IPRAs, The AP-WG believe that 6RD as discussed in RFC5969 is a valid reason to request more than a /32 in order to give end user networks a sensible level of address space but please make sure that requests above a /29 have followed the correct mathematical calculations. Love The AP-WG" ... this doesn't require a change to the policy (correct me if I'm wrong) and stops people just requesting a /29 without a challenge. J -- James Blessing 07989 039 476 From emadaio at ripe.net Fri Oct 21 17:55:58 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 21 Oct 2011 17:55:58 +0200 Subject: [address-policy-wg] 2011-03 Proposal Accepted (Post-depletion IPv4 address recycling) Message-ID: Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-528, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-03 The updated RIPE policy document is ripe-530 and is available at: http://www.ripe.net/ripe/docs/ripe-530 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From jan at go6.si Fri Oct 21 22:58:48 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 21 Oct 2011 22:58:48 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> Message-ID: <4EA1DD08.4010809@go6.si> On 10/21/11 2:02 PM, boggits wrote: > On 21 October 2011 12:42, Gert Doering wrote: > >> I'm not exactly sure how you're proposing to modify this? "Special case >> for 6rd only"? > > Send a guidance note... > > "Dear IPRAs, > > The AP-WG believe that 6RD as discussed in RFC5969 is a valid reason > to request more than a /32 in order to give end user networks a > sensible level of address space but please make sure that requests > above a /29 have followed the correct mathematical calculations. > > Love > The AP-WG" > > ... this doesn't require a change to the policy (correct me if I'm > wrong) and stops people just requesting a /29 without a challenge. Hi, We went through long discussion regarding this and this also needs a change of a policy, making one particular technology special. The common voice from community was "please, don't make 6rd special, because we don't know what follows". And, /29 is not a considerable waste of space, specially if we know that legacy IPv6 initial allocations were done with /29 reservation, so that place is there and will not be used by anyone else other than LIR, that got /32 from the beginning of this reservation. Why not making IPv6 more easily deployable, without those restrictions from IPv4 and legacy thinking about maximum conservation? Cheers, Jan From madams at netcologne.de Mon Oct 24 10:02:39 2011 From: madams at netcologne.de (Michael Adams) Date: Mon, 24 Oct 2011 10:02:39 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA1DD08.4010809@go6.si> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> Message-ID: <4EA51B9F.8020007@netcologne.de> Am 21.10.2011 22:58, schrieb Jan Zorz @ go6.si: > We went through long discussion regarding this and this also needs a change of a policy, making one particular technology special. > > The common voice from community was "please, don't make 6rd special, because we don't know what follows". Hi, I think it's a good idea not making one particular technology special. Also we are not going for 6RD we are having other problems regarding a initial /32 instead of a /29. We got a /32 some years ago. Now we find ourselves in a situation where we are having a need for /29. We also can justifiy it and we would get an assignement if we would do an initial request now. Following the current policy we are having two choices. 1) Returning the /32 and getting a /29 (which does not include the former /32). For us this is no option. 2) Stick to policy for subsequent allocations. In our case this means additional unneccessary work. Anyway it ends in a /29 for us. I'm conviced a /29 will be very helpful for proper addressing plans and I'm strongly supporting this proposal. > Why not making IPv6 more easily deployable, without those restrictions from IPv4 and legacy thinking about maximum conservation? ACK. cheers, Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Gesch?ftsf?hrer Gesellschaft f?r Telekommunikation mbH Dr. Hans Konle (Sprecher) Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 K?ln HRB 25580, Amtsgericht K?ln From rogerj at gmail.com Mon Oct 24 10:27:56 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 24 Oct 2011 10:27:56 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA51B9F.8020007@netcologne.de> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: Sound like a good idea to make it easier to get a /29, but Michael Adams had one sentence that I think I've heard before..... On Mon, Oct 24, 2011 at 10:02 AM, Michael Adams wrote: > I'm conviced a /29 will be very helpful for proper addressing plans and I'm strongly supporting this proposal. Isn't that almost the same that was said when we went from /35 to /32, and now again when we go to /29? Nothing wrong in that, the world keep growing so it's just fair the address-space grow with it. -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From swmike at swm.pp.se Mon Oct 24 10:41:40 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 24 Oct 2011 10:41:40 +0200 (CEST) Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: On Mon, 24 Oct 2011, Roger J?rgensen wrote: > Isn't that almost the same that was said when we went from /35 to /32, > and now again when we go to /29? Nothing wrong in that, the world keep > growing so it's just fair the address-space grow with it. Haven't we already reserved the encompassing /29 per initial /32 the past few years? Does this proposal suggest that a /26 should be reserved for an initial allocation of /29? -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Mon Oct 24 10:49:17 2011 From: gert at space.net (Gert Doering) Date: Mon, 24 Oct 2011 10:49:17 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <20111024084917.GQ72014@Space.Net> Hi, On Mon, Oct 24, 2011 at 10:41:40AM +0200, Mikael Abrahamsson wrote: > On Mon, 24 Oct 2011, Roger J?rgensen wrote: > > > Isn't that almost the same that was said when we went from /35 to /32, > > and now again when we go to /29? Nothing wrong in that, the world keep > > growing so it's just fair the address-space grow with it. > > Haven't we already reserved the encompassing /29 per initial /32 the past > few years? Yes. > Does this proposal suggest that a /26 should be reserved for an > initial allocation of /29? It doesn't say so (otherwise it would have been written down :) ), but since the NCC has moved from "allocate linearily, always leaving 3 bits in reserve" to "binary chop", no reservations are needed anymore (or, phrased differently, "reservations automatically use all the space still available"). If you look at the stats files, this is nicely visible in recent allocations: ripencc|FI|ipv6|2a03:9b80::|32|20111011|allocated ripencc|PT|ipv6|2a03:9c80::|32|20111011|allocated ripencc|SE|ipv6|2a03:9a80::|32|20111011|allocated ripencc|GB|ipv6|2a03:9e80::|32|20111012|allocated ripencc|RS|ipv6|2a03:9d80::|32|20111012|allocated ripencc|DE|ipv6|2a03:a080::|32|20111013|allocated ripencc|FI|ipv6|2a03:9f80::|32|20111013|allocated ripencc|IT|ipv6|2a03:a280::|32|20111014|allocated ripencc|IT|ipv6|2a03:a380::|32|20111014|allocated ripencc|RU|ipv6|2a03:a180::|32|20111014|allocated 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 maildanrl at googlemail.com Mon Oct 24 11:59:51 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 24 Oct 2011 11:59:51 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA51B9F.8020007@netcologne.de> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: Hallo, On Mon, Oct 24, 2011 at 10:02 AM, Michael Adams wrote: > 2) Stick to policy for subsequent allocations. In our case this > means additional unneccessary work. Anyway it ends in a /29 for us. Isn't it better to change that procedure to not require unnecessary work? The space is reserved for growth and to contain fragmentation. Instead of increasing the initial allocation I propose to make it easier to request subsequent allocations from the prior reserved /29. A short notice "hey, we are growing" should be enough. If it's not, then we need to change that. Handing out /29 initially might lead to over-generous network planing, but one should not be having problems getting the rest of one's /29 when growing! But maybe I am just not getting your point?! regards. ?danrl -- Dan Luedtke http://www.danrl.de From madams at netcologne.de Mon Oct 24 14:12:24 2011 From: madams at netcologne.de (Michael Adams) Date: Mon, 24 Oct 2011 14:12:24 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <4EA55628.70408@netcologne.de> Am 24.10.2011 11:59, schrieb Dan Luedtke: > Isn't it better to change that procedure to not require unnecessary work? For us this would be sufficient. Something like "If you qualify for an initial /29 you may extend your /32 directly to a /29 an skip the HD-ratio rule." would perfectly match for us. But I can imagine other scenarios where a /29 from the beginning might be more usefull. 6RD is one them. > The space is reserved for growth and to contain fragmentation. Instead > of increasing the initial allocation I propose to make it easier to > request subsequent allocations from the prior reserved /29. A short > notice "hey, we are growing" should be enough. If it's not, then we Sounds similar. In case you have a /32 and a short notice is enough you can assign a /29 initially and save the time for a subsequent allocation request. In my interpretation "short notice" means you don't have have to fulfill the HD-ratio criteria. There might be other valid reasons than growing. > need to change that. Handing out /29 initially might lead to > over-generous network planing, but one should not be having problems > getting the rest of one's /29 when growing! Actually we are having problems to get the rest of our /29. Our plans have changed since we got our /32 and we can't qualify for subsequent allocation due to the HD ratio. But we need the /29 for a complete v6 roll-out based on the current planning. Right now we have no other choice than to change our planning until we fulfill the HD-ratio criteria. An extension of the minimum allocation size would cover our case because it would allow Ripe to give us "our" /29. cheers, Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Gesch?ftsf?hrer Gesellschaft f?r Telekommunikation mbH Dr. Hans Konle (Sprecher) Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 K?ln HRB 25580, Amtsgericht K?ln From jan at go6.si Mon Oct 24 14:36:39 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 24 Oct 2011 14:36:39 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <4EA55BD7.9050101@go6.si> On 10/24/11 10:41 AM, Mikael Abrahamsson wrote: Haven't we already reserved the encompassing /29 per initial /32 the > past few years? Does this proposal suggest that a /26 should be reserved > for an initial allocation of /29? ROTFL :) No. Cheers, Jan From maildanrl at googlemail.com Mon Oct 24 14:51:11 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 24 Oct 2011 14:51:11 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA55628.70408@netcologne.de> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <4EA55628.70408@netcologne.de> Message-ID: Hallo, On Mon, Oct 24, 2011 at 2:12 PM, Michael Adams wrote: > Am 24.10.2011 11:59, schrieb Dan Luedtke: >> Isn't it better to change that procedure to not require unnecessary work? > For us this would be sufficient. Something like "If you qualify for an initial > /29 you may extend your /32 directly to a /29 an skip the HD-ratio rule." would > perfectly match for us. I am not a RIPE member (just a regular customer of a LIR), so I don't know if I can propose a policy change, but I am sure you can. -- snip -- 5.2.1. Subsequent allocation criteria Subsequent allocation will be provided when an organisation (i.e. ISP/LIR): a) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below; b) qualifies in accordance with the criteria for an initial allocation of /29. -- snap -- Something like this? regards. ?danrl -- Dan Luedtke http://www.danrl.de From gert at space.net Mon Oct 24 14:56:47 2011 From: gert at space.net (Gert Doering) Date: Mon, 24 Oct 2011 14:56:47 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <4EA55628.70408@netcologne.de> Message-ID: <20111024125647.GX72014@Space.Net> Hi, On Mon, Oct 24, 2011 at 02:51:11PM +0200, Dan Luedtke wrote: > I am not a RIPE member (just a regular customer of a LIR), so I don't > know if I can propose a policy change, but I am sure you can. To propose policy change, you just need to be interested in RIPE policy making (and have an asbestos suit for some of the discussions). Regarding your proposal: please let's stick to proposal 2011-04 in this thread - changing the "subsequent allocation rule" is a different change and should be discussed in a separate thread. This is not meant to discourage that discussion, but to help people trying to follow the list archives to see what's related to 2011-04, and what's a new discussion. thanks, Gert Doering -- WG 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 slz at baycix.de Mon Oct 24 15:10:09 2011 From: slz at baycix.de (Sascha Lenz) Date: Mon, 24 Oct 2011 15:10:09 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111021103803.0EAE02A01D1@mx00.baycix.de> References: <20111021103803.0EAE02A01D1@mx00.baycix.de> Message-ID: Hi, > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > www.ripe.net/ripe/policies/proposals/2011-04 > > We encourage you to review this proposal and send your comments to > before 18 November 2011. Short: I support it. Long: well, i'm one of those guys who prefer to implement native IPv6 from scratch and skip all those crappy transition methods completely. It actually works im my world. ...but unfortunately(?) my world is huge corporate networks and rather small scale ISPs, haven't worked for a big ISPs for a decade now, so i guess there could be a case for 6rd somewhere else. It's a little awkward that the proposal mentions "small ISPs", because with small ISPs there shouldn't be a problem to implement native IPv6... Anyways, the reason why i do support the proposal is just getting the additional bits for proper subnetting, that actually is a little PITA if you're a "not-big-yet-but-not-so-little-anymore"-type ISP. Doing network design meant to last more than some years the right way is a little hard there with a /32 sometimes. So i would welcome /29s instead of /32s. I cannot always justify more than an initial /32 at the moment. If that also helps with 6RD deployments, and it certainly does, sure, good thing. I don't see any downside of that since even for the earlier Allocations this was reserved already. But we should be clear here: /29 should be the end of the road for "no documentation needed". -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From Remco.vanMook at eu.equinix.com Mon Oct 24 15:29:42 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 24 Oct 2011 14:29:42 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <201110211045.p9LAjceI014178@rly21a.srv.mailcontrol.com> Message-ID: All, I support the thought that LIRs should be able to get up to a /29 as an initial allocation with no documentation required. However, that doesn't mean I support the policy proposal in its current form. Here's why. In the current policy text, it's very clear cut that unless you provide documentation (which means you've thought about how to deploy), you get a /32. I would not want a situation where people get a /29 without thinking, making a mess of it and then come back. So you could get a /29 if you asked for it specifically, otherwise you get a /32. So I would propose the following: Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For initial allocations up to /29 no additional documentation is necessary. Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure. --snip-- And, of course, using up your /29 in one go means no additional adjacent reserved address space on the RIPE NCC books, but that's an implementation issue :) Best Remco van Mook Director of Interconnection, Europe remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 21-10-11 12:44, "Emilio Madaio" wrote: > >Dear Colleagues, > >A new RIPE Policy Proposal has been made and is now available for >discussion. > >You can find the full proposal at: > > www.ripe.net/ripe/policies/proposals/2011-04 > >We encourage you to review this proposal and send your comments to > before 18 November 2011. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > > 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 jan at go6.si Mon Oct 24 16:45:41 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 24 Oct 2011 16:45:41 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: Message-ID: <4EA57A15.5020809@go6.si> On 10/24/11 3:29 PM, Remco Van Mook wrote: > > All, > > I support the thought that LIRs should be able to get up to a /29 as an > initial allocation with no documentation required. Hi, Good :) > However, that doesn't > mean I support the policy proposal in its current form. Here's why. In the > current policy text, it's very clear cut that unless you provide > documentation (which means you've thought about how to deploy), you get a > /32. I would not want a situation where people get a /29 without thinking, > making a mess of it and then come back. So you could get a /29 if you > asked for it specifically, otherwise you get a /32. Well, this part was meant to figure it out when implementing changed policy. My suggestion was that IPRA warns LIR that is requesting the initial IPv6 allocation, that /32 means different charges in the future than /29, so LIR can decide and get what they need. I was warned, that this is implementation specific issue and should not be part of the policy. Being said that, /32 still exists as minimum alloc size just to prevent someone saying "RIPE-NCC would like to pay us more" - we already discussed that in Dubrovnik, remember? :) > > So I would propose the following: > > Organisations that meet the initial allocation criteria are eligible to > receive an initial allocation of /32. For initial allocations up to /29 no > additional documentation is necessary. > > Organisations may qualify for an initial allocation greater than /29 by > submitting documentation that reasonably justifies the request. If so, the > allocation size will be based on the number of existing users and the > extent of the organisation's infrastructure. So, your suggestion is to give out /32 by default for clueless, but if someone requests more (up to /29) - fine, here it is. Hmm... looks like this makes sense. What others think? > > > --snip-- > > And, of course, using up your /29 in one go means no additional adjacent > reserved address space on the RIPE NCC books, but that's an implementation > issue :) With binary chops one must be very unlucky to get non-expansible space :) Cheers, Jan From andy at nosignal.org Mon Oct 24 18:07:02 2011 From: andy at nosignal.org (Andy Davidson) Date: Mon, 24 Oct 2011 17:07:02 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <040023B1-1D0F-4B54-94C6-2C4A19642235@nosignal.org> Hi there, On 24 Oct 2011, at 09:41, Mikael Abrahamsson wrote: > Haven't we already reserved the encompassing /29 per initial /32 the past few years? Does this proposal suggest that a /26 should be reserved for an initial allocation of /29? This might be a good idea. Asking for impact analysis stats might be funny, along the lines of "RIPENCC running out in 2 millennia rather than 6", but impact analysis/due diligence is important. If we decided to reserve a /26 per future lir, is this in line with and permitted by any global policy, should RIPENCC need to go and ask for more v6 ? Andy From andy at nosignal.org Mon Oct 24 18:02:22 2011 From: andy at nosignal.org (Andy Davidson) Date: Mon, 24 Oct 2011 17:02:22 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: Message-ID: <32353BCD-5769-4A4F-A32A-DA96035C129D@nosignal.org> Hi there, On 24 Oct 2011, at 14:29, Remco Van Mook wrote: > Organisations that meet the initial allocation criteria are eligible to > receive an initial allocation of /32. For initial allocations up to /29 no > additional documentation is necessary. > > Organisations may qualify for an initial allocation greater than /29 by > submitting documentation that reasonably justifies the request. If so, the > allocation size will be based on the number of existing users and the > extent of the organisation's infrastructure. Support the policy in general (so please implement in some similar form after discussion) but strongly support the exact methodology proposed by Remco above. Andy From randy at psg.com Mon Oct 24 19:29:15 2011 From: randy at psg.com (Randy Bush) Date: Mon, 24 Oct 2011 10:29:15 -0700 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: >> I'm conviced a /29 will be very helpful for proper addressing plans >> and I'm strongly supporting this proposal. > Isn't that almost the same that was said when we went from /35 to /32, > and now again when we go to /29? > Nothing wrong in that, the world keep growing so it's just fair the > address-space grow with it. why are we screwing around? let's go straight to a /16 or at least a /20. randy From gert at space.net Mon Oct 24 19:38:15 2011 From: gert at space.net (Gert Doering) Date: Mon, 24 Oct 2011 19:38:15 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <20111024173815.GH72014@Space.Net> Hi, On Mon, Oct 24, 2011 at 10:29:15AM -0700, Randy Bush wrote: > >> I'm conviced a /29 will be very helpful for proper addressing plans > >> and I'm strongly supporting this proposal. > > Isn't that almost the same that was said when we went from /35 to /32, > > and now again when we go to /29? > > Nothing wrong in that, the world keep growing so it's just fair the > > address-space grow with it. > > why are we screwing around? let's go straight to a /16 or at least a > /20. So you're proposing to adjust the proposal for a minimum size of /20? It's a tough fit inside RIPE's /12, but I always thought that was too narrow-minded in the first place. With a /20 per LIR, RIPE would need a /7 now and a /6 soonish - which would be nicely utilizing the available space inside FP001... 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 drc at virtualized.org Mon Oct 24 20:52:06 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 24 Oct 2011 11:52:06 -0700 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111024173815.GH72014@Space.Net> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <20111024173815.GH72014@Space.Net> Message-ID: On Oct 24, 2011, at 10:38 AM, Gert Doering wrote: >>> Nothing wrong in that, the world keep growing so it's just fair the >>> address-space grow with it. >> >> why are we screwing around? let's go straight to a /16 or at least a /20. > > So you're proposing to adjust the proposal for a minimum size of /20? > > It's a tough fit inside RIPE's /12, but I always thought that was too > narrow-minded in the first place. With a /20 per LIR, RIPE would need > a /7 now and a /6 soonish - which would be nicely utilizing the available > space inside FP001... Somebody (or hopefully somebodies) forgot a smiley. Regards, -drc From millnert at gmail.com Mon Oct 24 20:56:06 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 24 Oct 2011 20:56:06 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111021114200.GB72014@Space.Net> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> Message-ID: Hi, On Fri, Oct 21, 2011 at 1:42 PM, Gert Doering wrote: > Hi, > > On Fri, Oct 21, 2011 at 12:01:12PM +0100, boggits wrote: >> On 21 October 2011 11:44, Emilio Madaio wrote: >> > ? ?www.ripe.net/ripe/policies/proposals/2011-04 >> >> Okay, I can see the logic, but please can we not do this :) >> >> I'm all for allowing a policy that says LIR can request a /29 rather >> than a /32 and that deploying 6rd is a valid reason for allocating a >> /29 as an initial block but can we do this by having the LIR send the >> documentation in and having it reviewed for logic. > > The feedback we got at the last RIPE meeting was "please do not tie this > to a specific transition technology, and go down the rathole of potentially > having to revoke the allocation if 6rd is no longer in use". > > So the proposers have decided to go for the "minimum fuzz" thing - ask > for it, get it. > > I'm not exactly sure how you're proposing to modify this? ?"Special case > for 6rd only"? My personal opinion on 6RD is: if it is to be treated as a special case, it should be a special case, meaning it is a temporary allocation (like all others, but with emphasis), valid only so long it is used. A 6RD allocation should be 100% 6RD and no other use of it should be allowed, so that it can easily be returned once the 6RD deployment is no longer in use. That, or, roll native. ;) Best, Martin From rogerj at gmail.com Mon Oct 24 21:17:12 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 24 Oct 2011 21:17:12 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <20111024173815.GH72014@Space.Net> Message-ID: a bit off topic... On Mon, Oct 24, 2011 at 8:52 PM, David Conrad wrote: > On Oct 24, 2011, at 10:38 AM, Gert Doering wrote: >>>> Nothing wrong in that, the world keep growing so it's just fair the >>>> address-space grow with it. >>> >>> why are we screwing around? ?let's go straight to a /16 or at least a /20. >> >> So you're proposing to adjust the proposal for a minimum size of /20? >> >> It's a tough fit inside RIPE's /12, but I always thought that was too >> narrow-minded in the first place. ?With a /20 per LIR, RIPE would need >> a /7 now and a /6 soonish - which would be nicely utilizing the available >> space inside FP001... > > Somebody (or hopefully somebodies) forgot a smiley. well, why? I don't say /20 or /16 is the right size but we started with /35, then to /32 and now to /29. Seems like we are pushing things every few years. So why not go bigger this time? And we got the space to waste if people are afraid of that to, we're still only on the first out of 7-8 big block (2000::/3...) -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From jan at go6.si Mon Oct 24 21:28:47 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 24 Oct 2011 21:28:47 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <4EA5BC6F.90005@go6.si> On 10/24/11 7:29 PM, Randy Bush wrote: > why are we screwing around? let's go straight to a /16 or at least a > /20. it would not be fair to legacy v6 allocations :) can only expand to /29 without renumbering :S cheers, Jan From randy at psg.com Mon Oct 24 23:36:27 2011 From: randy at psg.com (Randy Bush) Date: Mon, 24 Oct 2011 14:36:27 -0700 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA5BC6F.90005@go6.si> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <4EA5BC6F.90005@go6.si> Message-ID: >> why are we screwing around? let's go straight to a /16 or at least a >> /20. > it would not be fair to legacy v6 allocations :) well, they could convert to a /16. but they would only be allowed to change their whois data on odd numbered wednesdays while standing on their left foot randy From randy at psg.com Mon Oct 24 23:37:26 2011 From: randy at psg.com (Randy Bush) Date: Mon, 24 Oct 2011 14:37:26 -0700 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <20111024173815.GH72014@Space.Net> Message-ID: > Somebody (or hopefully somebodies) forgot a smiley. i have not found an emoticon for dripping sarcasm. a business opportunity for an ascii artist. randy From jan at go6.si Tue Oct 25 01:04:31 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 25 Oct 2011 01:04:31 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <4EA5BC6F.90005@go6.si> Message-ID: <4EA5EEFF.1010200@go6.si> On 10/24/11 11:36 PM, Randy Bush wrote: >>> why are we screwing around? let's go straight to a /16 or at least a >>> /20. >> it would not be fair to legacy v6 allocations :) > > well, they could convert to a /16. but they would only be allowed to > change their whois data on odd numbered wednesdays while standing on > their left foot There were suggestions to go directly to /24 (as then you can easily deploy 6RD, give out /56 and have no incentive to go to native v6), but this did not seem a good idea to many of people we discussed with about this matter. When mentioning this to you, you had no preferences and/or objections :) I know it's politics and policy, but we just exposed the problem from real operations world towards policy-making community and community decided we need to deal with this issue. We are also well aware, that "6rd is wrong way of doing right thing (or even vice-versa)", but it out there and happening. whois data and wednesdays, well, this is implementation issue, not policy so we can fix that later on :) :) :) cheers, Jan From maildanrl at googlemail.com Tue Oct 25 08:01:28 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Tue, 25 Oct 2011 08:01:28 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA5EEFF.1010200@go6.si> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <4EA5BC6F.90005@go6.si> <4EA5EEFF.1010200@go6.si> Message-ID: > A 6RD allocation should be 100% 6RD and no other use of it should be allowed, so that it can easily be returned once the 6RD deployment is no longer in use. I agree regarding allocations that were requested for use with 6RD. However, LIR/ISP requesting space from "their own" /29 should not require documentation when used for 6RD. For some reason, ISPs tend to deploy 6RD inside "their own" /29 rather than requesting a new /2x. > That, or, roll native. ;) I like the rolling native part :) When it comes to mobile network, we might be stuck to transition technologies forever(tm). There will be parts of the network that will never be LTE only, like strange sensors in some (hopefully not mission critical) infrastructure and things like that. So chances are, when looking at mobile networks, that a 6RD deployment will never be returned. :( regards. ?danrl -- Dan Luedtke http://www.danrl.de From jan at go6.si Tue Oct 25 08:49:39 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 25 Oct 2011 08:49:39 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> Message-ID: <4EA65C03.50903@go6.si> On 10/24/11 8:56 PM, Martin Millnert wrote: > My personal opinion on 6RD is: if it is to be treated as a special > case, it should be a special case, meaning it is a temporary > allocation (like all others, but with emphasis), valid only so long it > is used. A 6RD allocation should be 100% 6RD and no other use of it > should be allowed, so that it can easily be returned once the 6RD > deployment is no longer in use. > > That, or, roll native. ;) Hi, Special case means special IPv6 space and special allocations out of that and that means burning RIPE-NCC resources claiming that space back later on - and good luck with that, as we know that allocations rarely can be returned, because somebody deployed something else in that space and is now sorry :) Cheers, Jan From ahmed at tamkien.com Tue Oct 25 09:44:56 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Tue, 25 Oct 2011 10:44:56 +0300 Subject: [address-policy-wg] 2011-04 New Policy Proposal Message-ID: Interesting to see a v6-in-v4 access protocol triggering a significant change in allocation policy. As 6rd gobbles up 32 bits for the v4 address at the consumers v6 assignment, there is an alternative in RFC 5572 (TSP) that presents v6-in-v4 access on CPEs without such a need. And TSP can be implemented as a software client so LIRs do not need to change the CPEs to roll out IPv6 to end users. -Ahmed ------------------------------ Message: 8 Date: Mon, 24 Oct 2011 21:28:47 +0200 From: "Jan Zorz @ go6.si" Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) To: address-policy-wg at ripe.net Message-ID: <4EA5BC6F.90005 at go6.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/24/11 7:29 PM, Randy Bush wrote: > why are we screwing around? let's go straight to a /16 or at least a > /20. it would not be fair to legacy v6 allocations :) can only expand to /29 without renumbering :S cheers, Jan From jan at go6.si Tue Oct 25 11:04:20 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 25 Oct 2011 11:04:20 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: References: Message-ID: <4EA67B94.2090305@go6.si> On 10/25/11 9:44 AM, Ahmed Abu-Abed wrote: > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented > as a software client so LIRs do not need to change the CPEs to roll out > IPv6 to end users. Dear Ahmed, We are aware of many similar technologies that would fulfill the same or similar goal, but what we are doing here is just listen to complains and requests from the field and try to make deployment of IPv6 (native or as service in this case) as easy as possible with this change of the policy proposal. Reality usually wins :) Cheers, Jan From emadaio at ripe.net Tue Oct 25 11:51:26 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 25 Oct 2011 11:51:26 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: Dear Colleagues, A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation and Assignment Policies 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/2011-05 We encourage you to review this proposal and send your comments to before 22 November 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From boggits at gmail.com Tue Oct 25 12:15:16 2011 From: boggits at gmail.com (boggits) Date: Tue, 25 Oct 2011 11:15:16 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <1319536310_27586@mail.webtapestry.net> References: <1319536310_27586@mail.webtapestry.net> Message-ID: On 25 October 2011 10:51, Emilio Madaio wrote: > ? ?http://www.ripe.net/ripe/policies/proposals/2011-05 > I support this policy J -- James Blessing 07989 039 476 From maildanrl at googlemail.com Tue Oct 25 16:57:07 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Tue, 25 Oct 2011 16:57:07 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4ea686af.072f0e0a.78ac.57f9SMTPIN_ADDED@mx.google.com> References: <4ea686af.072f0e0a.78ac.57f9SMTPIN_ADDED@mx.google.com> Message-ID: I support this proposal. One question: Is it the same /16 in 5.6.2 as in 5.6.3? Or does that mean that two /16 will be held back? regards. ?danrl -- Dan Luedtke http://www.danrl.de From brian.nisbet at heanet.ie Tue Oct 25 19:06:17 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 25 Oct 2011 18:06:17 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <4EA6EC89.6050408@heanet.ie> On 25/10/2011 10:51, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies 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/2011-05 I support this policy. Brian. From Remco.vanMook at eu.equinix.com Tue Oct 25 20:06:05 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Tue, 25 Oct 2011 19:06:05 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <201110250951.p9P9pjBv029415@rly14a.srv.mailcontrol.com> Message-ID: Hi all, As I already indicated when this was last presented at the RIPE meeting, I strongly support a proposal to this end. The one thing I'm missing is the criteria for the size of the assignment - when does an IXP get a /24, /23 or a /22? With 'run out fairly' as accepted policy I don't think the timeframes set there are in any way realistic for Internet exchanges. So, clean as the current proposal is, I'd suggest making it a bit messier and adding very explicit criteria. With some first hand experience in setting up Exchanges, I would suggest the following: - a new IXP gets a /24 - an existing IXP that runs out of its /24 (whether from this /16 or another range) gets a /23 and has to return the old /24 - an existing IXP that runs out of its /23 (whether from this /16 or another range) gets a /22 and has to return the old /23 (Yes, this means renumbering every single time. Yes, it's a pain. Yes, if you run out of a /22 for your peering LAN you're fresh out of luck.) And while we're at it, I would suggest to add to 5.6.4: c. Any address space that is returned by an IXP will be added to the reserve as outlined in 5.6.2. Sorry :) Best, Remco van Mook Director of Interconnection, Europe remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 25-10-11 11:51, "Emilio Madaio" wrote: > > >Dear Colleagues, > >A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation >and Assignment Policies 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/2011-05 > >We encourage you to review this proposal and send your comments to > before 22 November 2011. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > > 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 andy at nosignal.org Tue Oct 25 20:43:14 2011 From: andy at nosignal.org (Andy Davidson) Date: Tue, 25 Oct 2011 19:43:14 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: <4ea686af.072f0e0a.78ac.57f9SMTPIN_ADDED@mx.google.com> Message-ID: Hi there, On 25 Oct 2011, at 15:57, Dan Luedtke wrote: > I support this proposal. > > One question: > Is it the same /16 in 5.6.2 as in 5.6.3? > Or does that mean that two /16 will be held back? Hi Thanks for your support. An additional /16 is proposed. Andy From gert at space.net Tue Oct 25 21:03:11 2011 From: gert at space.net (Gert Doering) Date: Tue, 25 Oct 2011 21:03:11 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: <201110250951.p9P9pjBv029415@rly14a.srv.mailcontrol.com> Message-ID: <20111025190311.GD72014@Space.Net> Hi, On Tue, Oct 25, 2011 at 07:06:05PM +0100, Remco Van Mook wrote: > With some first hand experience in setting up Exchanges, I would suggest > the following: > > - a new IXP gets a /24 > - an existing IXP that runs out of its /24 (whether from this /16 or > another range) gets a /23 and has to return the old /24 > - an existing IXP that runs out of its /23 (whether from this /16 or > another range) gets a /22 and has to return the old /23 I think this is all logical to people setting up exchanges - but indeed, it might be useful to make this clear to people evaluating such a request, quite likely having never worked at an IXP yet... Andy, you're taking notes? :-) 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 millnert at gmail.com Wed Oct 26 07:17:48 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 26 Oct 2011 07:17:48 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4ea686b2.0d060e0a.7bce.fffff93bSMTPIN_ADDED@mx.google.com> References: <4ea686b2.0d060e0a.7bce.fffff93bSMTPIN_ADDED@mx.google.com> Message-ID: Hi, On Oct 25, 2011, at 11:51, "Emilio Madaio" wrote: > http://www.ripe.net/ripe/policies/proposals/2011-05 I support this policy. I do have a question for clarification: andy, you speak about "peering LAN" in singular. How is the policy to be interpreted by the IPRAs for IXPs requesting space for different-size MTU peering LANs? A luxury we can't afford after runout, or? Best, Martin From millnert at gmail.com Wed Oct 26 07:25:39 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 26 Oct 2011 07:25:39 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> <4EA5BC6F.90005@go6.si> <4EA5EEFF.1010200@go6.si> Message-ID: <390D035C-CD2F-413A-9D04-92030851BC9C@gmail.com> Hi, On Oct 25, 2011, at 8:01, Dan Luedtke wrote: >> A 6RD allocation should be 100% 6RD and no other use of it should be allowed, so that it can easily be returned once the 6RD deployment is no longer in use. > I agree regarding allocations that were requested for use with 6RD. > However, LIR/ISP requesting space from "their own" /29 should not > require documentation when used for 6RD. For some reason, ISPs tend to > deploy 6RD inside "their own" /29 rather than requesting a new /2x. Requests for more space than /32 SHOULD require documentation, so your pretext I do not agree with. Moreover, it is easy and completely rational to, on your "subnet" lines, indicate if there is a 6RD subnet present in your plan/motivation. Additionally, it is very easy to subnet in such a way that 6RD is placed in the higher bits of the /29 or so, such that the space can be returned when no longer use. Admittedly, this gets more tricky with an initial allocation. >> That, or, roll native. ;) > I like the rolling native part :) > When it comes to mobile network, we might be stuck to transition > technologies forever(tm). There will be parts of the network that will > never be LTE only, like strange sensors in some (hopefully not mission > critical) infrastructure and things like that. So chances are, when > looking at mobile networks, that a 6RD deployment will never be > returned. :( See other email. > Best, Martin From millnert at gmail.com Wed Oct 26 07:36:19 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 26 Oct 2011 07:36:19 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA65C03.50903@go6.si> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> Message-ID: Hi, On Oct 25, 2011, at 8:49, "Jan Zorz @ go6.si" wrote: > On 10/24/11 8:56 PM, Martin Millnert wrote: >> My personal opinion on 6RD is: if it is to be treated as a special >> case, it should be a special case, meaning it is a temporary >> allocation (like all others, but with emphasis), valid only so long it >> is used. A 6RD allocation should be 100% 6RD and no other use of it >> should be allowed, so that it can easily be returned once the 6RD >> deployment is no longer in use. >> >> That, or, roll native. ;) > > Hi, > > Special case means special IPv6 space and special allocations out of that and that means burning RIPE-NCC resources claiming that space back later on - and good luck with that, as we know that allocations rarely can be returned, because somebody deployed something else in that space and is now sorry :) > > Cheers, Jan With the enormous economical disaster looming, isnt providing jobs a good thing? ;) Seriously though, I cannot support a policy proposal for 6RD or other transition technologies that burns this much v4 space ( ie , full mapping of ipv4), that does not explicitly attach requirements on the space to A) not be used for anything but the transition technology, and B) clearly be marked by the NCC as being of transition tech $FOO, and finally C) very explicitly be only valid as long as the use stays. Failing any of these points, I do not support the proposal on the basis that it is careless use of v6 space. Regarding mobile networks, there is little differentiation here to other link layers as far as address assignment goes I think. And again, numbering must be done in the way I describe if this or similar proposals is to have my support. So, I guess to make it clear, until the proposal has texts like the above in it, I do not support the proposal. Best, Martin From slz at baycix.de Wed Oct 26 08:02:56 2011 From: slz at baycix.de (Sascha Lenz) Date: Wed, 26 Oct 2011 08:02:56 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20111025094546.AFD572A018F@mx00.baycix.de> References: <20111025094546.AFD572A018F@mx00.baycix.de> Message-ID: <50B5C73E-83F5-40F7-A5D4-1B8C61F734AF@baycix.de> Hi, Am 25.10.2011 um 11:51 schrieb Emilio Madaio: > > > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies 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/2011-05 > > We encourage you to review this proposal and send your comments to > before 22 November 2011. i'm not a fan of "special entities", but IXPs actually are a bit special and the proposal again makes some examples why, so i do support this proposal. Reserving an(other) /16 for this purpose doesn't really hurt anyone either. I am not quite sure if 180days for returning the old prefix is really enough in a world where it's hard to reach some peering partners and get reactions in under 360days :-) but i'm not an IXP operator so what do i know... I just assume it's reasonable? -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From swmike at swm.pp.se Wed Oct 26 07:46:33 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Oct 2011 07:46:33 +0200 (CEST) Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> Message-ID: On Wed, 26 Oct 2011, Martin Millnert wrote: > Seriously though, I cannot support a policy proposal for 6RD or other > transition technologies that burns this much v4 space ( ie , full > mapping of ipv4), that does not explicitly attach requirements on the > space to A) not be used for anything but the transition technology, and > B) clearly be marked by the NCC as being of transition tech $FOO, and > finally C) very explicitly be only valid as long as the use stays. I agree with the above. I do not like to blanket increase to /29 and keep it there for everybody, but I do want people using 6RD who need to map the entire IPv4 space (which isn't strictly needed, if you're a small network you can map just part of the IPv4 space into IPv6 space, for instance on /16 border instead of at /0. I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike. 6RD is a transitioning tech that I would like to see gone in 5 years, and until then I believe a single /64 in the home should be enough for these transitioning tech users. When they get native IPv6, they can get their /56. If an ISP wants to give more space to their end users using 6RD, they'll have to do more granular 6RD mapping. So I guess my counter-proposal is to give everybody a /32, and if they say 6RD then they may get a /31 instead, with the additional /32 usage being reviewed every 5 years or so. -- Mikael Abrahamsson email: swmike at swm.pp.se From babak at farrokhi.net Wed Oct 26 08:19:02 2011 From: babak at farrokhi.net (Babak Farrokhi) Date: Wed, 26 Oct 2011 09:49:02 +0330 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: <4ea686af.072f0e0a.78ac.57f9SMTPIN_ADDED@mx.google.com> Message-ID: <0BFE377F-83CF-4989-BAB8-04D0FC3AFB8D@farrokhi.net> Hi, I support this policy. Babak On Oct 25, 2011, at 10:13 PM, Andy Davidson wrote: > > > Hi there, > > On 25 Oct 2011, at 15:57, Dan Luedtke wrote: > >> I support this proposal. >> >> One question: >> Is it the same /16 in 5.6.2 as in 5.6.3? >> Or does that mean that two /16 will be held back? > > Hi > > Thanks for your support. > > An additional /16 is proposed. > > Andy > From jan at go6.si Wed Oct 26 09:59:53 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 26 Oct 2011 09:59:53 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> Message-ID: <4EA7BDF9.7010800@go6.si> On 10/26/11 7:36 AM, Martin Millnert wrote: > Failing any of these points, I do not support the proposal on the > basis that it is careless use of v6 space. Hi, At first, my thoughts was to go exactly the way you propose. But, then we had long discussions with many people, also RIPE-NCC staff (I just needed some data and how IPRAs operate), and then we presented the proposal at RIPE62 in Amsterdam. If you remember, one of proposed solutions was also separate v6 space for transition mechanisms and temporary allocations, but this idea did not manage to fly (maybe before the presentation, but not after). The message we got back was "don't think v4 way, let's enable people to deploy IPv6 and not install speed bumps". If this is a request, then our first thought was - let's go straight to /29 as minimum initial allocation - but this could be seen from some individuals as "ripping more money from LIRs", so we introduced "from /32 to /29" option. I agree with all you said, just it seems it does not work this way. ARIN did that, but RIPE community want's it differently. But, if we hear many more suggestions in this way, we can withdraw the proposal and go different way, but for now - let's hear what community has to say :) Cheers, Jan From andy at nosignal.org Wed Oct 26 10:18:58 2011 From: andy at nosignal.org (Andy Davidson) Date: Wed, 26 Oct 2011 09:18:58 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: Message-ID: <5ACAD7C6-8309-44F1-96A8-1B79D24DC4B0@nosignal.org> On 25 Oct 2011, at 19:06, Remco Van Mook wrote: > With some first hand experience in setting up Exchanges, I would suggest > the following: > - a new IXP gets a /24 > - an existing IXP that runs out of its /24 (whether from this /16 or > another range) gets a /23 and has to return the old /24 > - an existing IXP that runs out of its /23 (whether from this /16 or > another range) gets a /22 and has to return the old /23 > (Yes, this means renumbering every single time. Yes, it's a pain. Yes, if > you run out of a /22 for your peering LAN you're fresh out of luck.) This is sane logic, but it feels very much like userland^Wimplementation documentation rathe than policy to me. Agree ? I don't mind it being in the policy though as it sounds very sane. > And while we're at it, I would suggest to add to 5.6.4: > > c. Any address space that is returned by an IXP will be added to the > reserve as outlined in 5.6.2. Agreed. Andy From andy at nosignal.org Wed Oct 26 10:21:25 2011 From: andy at nosignal.org (Andy Davidson) Date: Wed, 26 Oct 2011 09:21:25 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: <4ea686b2.0d060e0a.7bce.fffff93bSMTPIN_ADDED@mx.google.com> Message-ID: On 26 Oct 2011, at 06:17, Martin Millnert wrote: > I do have a question for clarification: andy, you speak about "peering LAN" in singular. How is the policy to be interpreted by the IPRAs for IXPs requesting space for different-size MTU peering LANs? A luxury we can't afford after runout, or? Sounds like an edge case, but in my mind this is just a second peering LAN, so still meets the description of a peering lan for situation described in the policy. Andy From jan at go6.si Wed Oct 26 10:22:19 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 26 Oct 2011 10:22:19 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> Message-ID: <4EA7C33B.1040005@go6.si> On 10/26/11 7:46 AM, Mikael Abrahamsson wrote: > On Wed, 26 Oct 2011, Martin Millnert wrote: > >> Seriously though, I cannot support a policy proposal for 6RD or other >> transition technologies that burns this much v4 space ( ie , full >> mapping of ipv4), that does not explicitly attach requirements on the >> space to A) not be used for anything but the transition technology, >> and B) clearly be marked by the NCC as being of transition tech $FOO, >> and finally C) very explicitly be only valid as long as the use stays. > > I agree with the above. I do not like to blanket increase to /29 and > keep it there for everybody, but I do want people using 6RD who need to > map the entire IPv4 space (which isn't strictly needed, if you're a > small network you can map just part of the IPv4 space into IPv6 space, > for instance on /16 border instead of at /0. Agree. > > I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike. No. 6RD in it's natural form "needs" /24 in order to give /56 to users. /30 is a compromise to give /62 (4 subnets) to end user. > 6RD is a transitioning tech that I would like to see gone in 5 years, We all wish that but usually temporary solutions are most permanent ones. Old DSLAMs are there to stay and probably we'll see this stuff in the networks for next 10 or 15 years. > and until then I believe a single /64 in the home should be enough for > these transitioning tech users. When they get native IPv6, they can get > their /56. If an ISP wants to give more space to their end users using > 6RD, they'll have to do more granular 6RD mapping. We would really like to prevent abusive/proxy/crap technologies to emerge just to be able to split that /64 in more subnets. Please, do us a favor and re-think :) > > So I guess my counter-proposal is to give everybody a /32, and if they > say 6RD then they may get a /31 instead, with the additional /32 usage > being reviewed every 5 years or so. This introduces an incentive to lie to IPRAs. We know that in IPv4, the trend is to lie to get more space. We are well aware of that so our proposal tends not to introduce an incentive to start lie to IPRAs. One incentive already emerged there, if you have hosting datacenter and no need to be LIR, don't say you'll give IPv6 addresses to your customers (servers) if you want to get IPv6 PI space. I hope this one will also be removed. Cheers, Jan From Remco.vanMook at eu.equinix.com Wed Oct 26 11:20:49 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Wed, 26 Oct 2011 10:20:49 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <5ACAD7C6-8309-44F1-96A8-1B79D24DC4B0@nosignal.org> Message-ID: Hi Andy, I agree that being this specific in policy might be overdoing it a bit, but at this point in time I don't want any ambiguity in ipv4 allocation policy and I'm not aware of any other kind of document where the community can put guidance on implementation. Best, Remco ----- Original Message ----- From: Andy Davidson [mailto:andy at nosignal.org] Sent: Wednesday, October 26, 2011 09:18 AM To: Remco Van Mook Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) On 25 Oct 2011, at 19:06, Remco Van Mook wrote: > With some first hand experience in setting up Exchanges, I would suggest > the following: > - a new IXP gets a /24 > - an existing IXP that runs out of its /24 (whether from this /16 or > another range) gets a /23 and has to return the old /24 > - an existing IXP that runs out of its /23 (whether from this /16 or > another range) gets a /22 and has to return the old /23 > (Yes, this means renumbering every single time. Yes, it's a pain. Yes, if > you run out of a /22 for your peering LAN you're fresh out of luck.) This is sane logic, but it feels very much like userland^Wimplementation documentation rathe than policy to me. Agree ? I don't mind it being in the policy though as it sounds very sane. > And while we're at it, I would suggest to add to 5.6.4: > > c. Any address space that is returned by an IXP will be added to the > reserve as outlined in 5.6.2. Agreed. Andy 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 swmike at swm.pp.se Wed Oct 26 12:05:32 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Oct 2011 12:05:32 +0200 (CEST) Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA7C33B.1040005@go6.si> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> Message-ID: On Wed, 26 Oct 2011, Jan Zorz @ go6.si wrote: >> I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike. > > No. 6RD in it's natural form "needs" /24 in order to give /56 to users. Yes, "needs" indeed. It's not a MUST though, it's just operationally easier. With 6RD you can take a IPv6 /36, map 8 bits of IPv4 into a IPv4 /24, map 24 bits into IPv6, and now you have that /60 you wanted for your customers. Yes, you "wasted" an IPv4 /24, but if you're that big so you need avoid doing 6RD on IPv4 /16 level (map 16 bits of IPv4 into a single IPv4 6RD relay address), give that relay a /40, then you can give your customers a /56, "wasting" a single IPv4 address per /16 with some additional configuration. Just to give some perspective if someone still thinks one can't deploy 6RD without mapping all of IPv4 space into IPv6. It's not true, it's just more complex. -- Mikael Abrahamsson email: swmike at swm.pp.se From jan at go6.si Wed Oct 26 12:47:53 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 26 Oct 2011 12:47:53 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> Message-ID: <4EA7E559.2070407@go6.si> On 10/26/11 12:05 PM, Mikael Abrahamsson wrote: > On Wed, 26 Oct 2011, Jan Zorz @ go6.si wrote: > >>> I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike. >> >> No. 6RD in it's natural form "needs" /24 in order to give /56 to users. > > Yes, "needs" indeed. It's not a MUST though, it's just operationally > easier. Exactly. But... (there's always a but), operators are yelling about small margins, about not having money to invest in more complex operations, about operations overhead and so on and so on. Personally, I would go with multiple 6RD domains and be done with it. Again, this are facts, complains and questions we get from real life on the operational field. > > With 6RD you can take a IPv6 /36, map 8 bits of IPv4 into a IPv4 /24, > map 24 bits into IPv6, and now you have that /60 you wanted for your > customers. Yes, you "wasted" an IPv4 /24, but if you're that big so you > need avoid doing 6RD on IPv4 /16 level (map 16 bits of IPv4 into a > single IPv4 6RD relay address), give that relay a /40, then you can give > your customers a /56, "wasting" a single IPv4 address per /16 with some > additional configuration. > > Just to give some perspective if someone still thinks one can't deploy > 6RD without mapping all of IPv4 space into IPv6. It's not true, it's > just more complex. Yes. Easily possible, but not heavily practiced in real life. Least possible complexity, least possible operational overhead. If we get them this option, IPv6 service gets deployed. Note the usage of the word "service", not "native" :) Cheers, Jan From millnert at gmail.com Wed Oct 26 13:55:01 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 26 Oct 2011 13:55:01 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA7E559.2070407@go6.si> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> <4EA7E559.2070407@go6.si> Message-ID: <1319630101.3501.12.camel@natalie.csbnet.se> Jan, On Wed, 2011-10-26 at 12:47 +0200, Jan Zorz @ go6.si wrote: > On 10/26/11 12:05 PM, Mikael Abrahamsson wrote: > > On Wed, 26 Oct 2011, Jan Zorz @ go6.si wrote: > > > >>> I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike. > >> > >> No. 6RD in it's natural form "needs" /24 in order to give /56 to users. > > > > Yes, "needs" indeed. It's not a MUST though, it's just operationally > > easier. > > Exactly. > > But... (there's always a but), operators are yelling about small > margins, about not having money to invest in more complex operations, > about operations overhead and so on and so on. > > Personally, I would go with multiple 6RD domains and be done with it. > > Again, this are facts, complains and questions we get from real life on > the operational field. Knowing you represent Go6, I do wonder what operators are requesting this. It wouldn't hurt if they came here and voiced their opinions directly either. The APWG-ml community is not a 1:1 map to RIPE region operators, so the community response you will get here may or may not be what you want. > > With 6RD you can take a IPv6 /36, map 8 bits of IPv4 into a IPv4 /24, > > map 24 bits into IPv6, and now you have that /60 you wanted for your > > customers. Yes, you "wasted" an IPv4 /24, but if you're that big so you > > need avoid doing 6RD on IPv4 /16 level (map 16 bits of IPv4 into a > > single IPv4 6RD relay address), give that relay a /40, then you can give > > your customers a /56, "wasting" a single IPv4 address per /16 with some > > additional configuration. > > > > Just to give some perspective if someone still thinks one can't deploy > > 6RD without mapping all of IPv4 space into IPv6. It's not true, it's > > just more complex. > > Yes. > > Easily possible, but not heavily practiced in real life. Least possible > complexity, least possible operational overhead. If we get them this > option, IPv6 service gets deployed. Note the usage of the word > "service", not "native" :) I wish it was feasible to counter-suggest that those who spend more effort get a better service to customers and 'market forces' takes care of the rest (ie, native IPv6 provides the best service, and competition eats up those 15 year old DSLAMs...). (On second thought, isn't it?) IMHO, we're not necessarily helped with deploying IPv6 services at unlimited cost. And being too lazy to not map 32 bits of IPv4 space into 6RD strikes me like such a thing (and if you want to do it, you still could, with the A,B,C and attached justifying documentation.) Best, Martin From jan at go6.si Wed Oct 26 14:51:15 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 26 Oct 2011 14:51:15 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <1319630101.3501.12.camel@natalie.csbnet.se> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> <4EA7E559.2070407@go6.si> <1319630101.3501.12.camel@natalie.csbnet.se> Message-ID: <4EA80243.1090507@go6.si> On 10/26/11 1:55 PM, Martin Millnert wrote: >> Again, this are facts, complains and questions we get from real life on >> the operational field. > > Knowing you represent Go6, I do wonder what operators are requesting > this. Hi, I'm not going into names, but even many of them who are looking into multiple domains now would go into one domain 6RD if this would be even remotely possible. While doing IPv6 world-tour with Go6 presentation I talk to many of them at the events and there is repeating story, over and over again. > It wouldn't hurt if they came here and voiced their opinions > directly either. The APWG-ml community is not a 1:1 map to RIPE region > operators, so the community response you will get here may or may not be > what you want. This is a pitty. I would also like them to voice out their opinion here. Looks like *I* need this policy to change, but I don't, even in my country there will be no 6RD deployment, we cause we did our homework right. So, this effort is purely to ease some things for others. > I wish it was feasible to counter-suggest that those who spend more > effort get a better service to customers and 'market forces' takes care > of the rest (ie, native IPv6 provides the best service, and competition > eats up those 15 year old DSLAMs...). This is how it is supposed to go, yes. > > (On second thought, isn't it?) > > IMHO, we're not necessarily helped with deploying IPv6 services at > unlimited cost. And being too lazy to not map 32 bits of IPv4 space into > 6RD strikes me like such a thing (and if you want to do it, you still > could, with the A,B,C and attached justifying documentation.) I'll leave the cost calculations to operators and their staff, but, again, from what I hear, there are economical issues that I even don't properly understand (as I'm not economist). Cheers from OECD meeting in Paris :) :) :) Jan From fweimer at bfk.de Wed Oct 26 15:43:28 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 26 Oct 2011 13:43:28 +0000 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <82zkgp75s2.fsf@totally-fudged-out-message-id> (Emilio Madaio's message of "Tue, 25 Oct 2011 11:51:26 +0200") References: <82zkgp75s2.fsf@totally-fudged-out-message-id> Message-ID: <8262jb27i7.fsf@mid.bfk.de> * Emilio Madaio: > http://www.ripe.net/ripe/policies/proposals/2011-05 I oppose this policy. IXPs shouldn't be special-cased. The assumption of a single peering LAN per organization does not seem to match the requirements of the industry. It is odd that preexisting PI space must be returned, but not existing PA space. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Wed Oct 26 15:36:25 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 26 Oct 2011 13:36:25 +0000 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: (Randy Bush's message of "Mon, 24 Oct 2011 10:29:15 -0700") References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA1DD08.4010809@go6.si> <4EA51B9F.8020007@netcologne.de> Message-ID: <82aa8n27ty.fsf@mid.bfk.de> * Randy Bush: > why are we screwing around? let's go straight to a /16 or at least a > /20. At a certain point, necessary bits for internal routing will have to come from the other end of the address. This should have been done for 6RD. It shouldn't be avoided by the next protocol which needs longer network identifiers. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From madams at netcologne.de Wed Oct 26 15:44:46 2011 From: madams at netcologne.de (Michael Adams) Date: Wed, 26 Oct 2011 15:44:46 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <1319630101.3501.12.camel@natalie.csbnet.se> References: <1319193932_16094@mail.webtapestry.net> <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> <4EA7E559.2070407@go6.si> <1319630101.3501.12.camel@natalie.csbnet.se> Message-ID: <4EA80ECE.1000600@netcologne.de> Am 26.10.2011 13:55, schrieb Martin Millnert: > Knowing you represent Go6, I do wonder what operators are requesting > this. It wouldn't hurt if they came here and voiced their opinions > directly either. The APWG-ml community is not a 1:1 map to RIPE region > operators, so the community response you will get here may or may not be > what you want. We'll not go for 6RD. But if we would it would be easier with a simple mapping mechanism. Not only from the technical point of view. Complexity is sometimes not easy to sell to everyone inside the company. Especially if you have several v4 /15, /16, /.... and dynamic dial-in-pools for residential customers distributed over all of them and also inside every prefix. For example an easy to understand mechanism may help to answer support calls. Another example. From time to time the firwall / server people are asking for a list of all our dial-in-pools in order to configure access lists for services or spam fighting or .... It's additional work (for people, firewalls, loadbalancers, servers...) to take care about a list of prefixes instead one prefix. If we would like to introduce 6RD it would be much easier with a /29 and a subnetting plan. Just keep it simple. But we want to do native v6 and we need additional bits to make the v6 pools on our access routers big enough for all our residential customers from the beginning. Fortunately the policy text itself is not mentioning 6RD and so it solves our problem too. Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Gesch?ftsf?hrer Gesellschaft f?r Telekommunikation mbH Dr. Hans Konle (Sprecher) Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 K?ln HRB 25580, Amtsgericht K?ln From tom at someaddress.net Wed Oct 26 16:34:12 2011 From: tom at someaddress.net (Tom Hodgson) Date: Wed, 26 Oct 2011 15:34:12 +0100 (BST) Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20111025095148.20991A4801F@argon.sov.someaddress.net> References: <20111025095148.20991A4801F@argon.sov.someaddress.net> Message-ID: On Tue, 25 Oct 2011, Emilio Madaio wrote: > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > I do wonder how many special cases we will see crop up before we've let v4 exit stage left, however the benefits brought by the reservation of a /16 for increased network interconnection I think justify the addition to the policy. There is a question of whether the IXP should just become an LIR to receive an allocation that way, however I neither believe that an IXP should be forced into becoming an LIR or that all IXPs necessarily have an appropriate entity with which to do so, especially when they are in the startup phase. Therefore I support this policy. -- Tom Hodgson tom at someaddress.net From matt.parker at ripe.net Wed Oct 26 17:49:54 2011 From: matt.parker at ripe.net (Matt Parker) Date: Wed, 26 Oct 2011 17:49:54 +0200 Subject: [address-policy-wg] Policy Proposal: 2006-05 "PI Assignment Size" implemented Message-ID: <4EA82C22.9010808@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that the policy described in proposal 2006-05, "PI Assignment Size", has been implemented. Requests for IPv4 Provider Independent (PI) address space received on or after Wednesday, 27 October 2011, will be evaluated by the RIPE NCC Registration Services Department under the new policy. The RIPE policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2006-05 The following RIPE Documents have been updated to reflect this policy implementation: http://www.ripe.net/ripe/docs/ipv4-policies http://www.ripe.net/ripe/docs/pi-requestsupport Regards, Matt Parker RIPE NCC Registration Services From gert at space.net Wed Oct 26 19:00:25 2011 From: gert at space.net (Gert Doering) Date: Wed, 26 Oct 2011 19:00:25 +0200 Subject: [address-policy-wg] AP WG Agenda for RIPE63 Message-ID: <20111026170025.GP72014@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following three time slots: Wednesday, Nov 02, 09:00 - 10:30 Wednesday, Nov 02, 11:00 - 12:30 Thursday, Nov 03, 09:00 - 11:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Emilio Madaio - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE61 [list of things that the WG chairs collective agrees on] - brief overview over new proposals (2011-04, 2011-05) C. Policy Development Office Activities - Emilio Madaio D. Feedback From NCC Registration Service - Alex le Heux (Emilio and Alex will give the WG some insights on policy development topics from the NCC side) E Discussion of open policy proposals, part I 2011-02 IPv6 PI assignment policy / removal of multihoming req. (current status, by the AP WG chairs) 2011-04 initial IPv6 allocation size / 6rd (Jan Zorz) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- J. Welcome back K. Discussion of open policy proposals, part II 2011-05 IPv4 Assignments to IXPs from the Last /8 (Andy Davidson, representing the EIX WG) L. on (Inter-RIR) transfers - Dave Wilson (tbc) M. IPv4 maintenance policy - Rob Blokzijl Introduction to a Work-in-Progress document about governance of IPv4 resources in the RIPE region after run-out + Q&A. N. On Renumbering IPv6 networks - N.N. [ report from the discussion in the IPv6 WG on Tuesday ] O. On Certificates - from the APWG chair [ what happened, and what next ] ---------------------------------------------------------------------- Thursday, 09:00-10:30 ---------------------------------------------------------------------- R. On IPv6 PI/PA Unification Discussion how the IPv6 PA/PI policies can be reworked in a fundamental way to better fit the needs of all IPv6 Users. Discussion led by working group chairs. S. Rough Edges of the current policies "if things show up" T. Discussion of open policy proposals "if we need more time" Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- 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 gert at space.net Wed Oct 26 19:47:31 2011 From: gert at space.net (Gert Doering) Date: Wed, 26 Oct 2011 19:47:31 +0200 Subject: [address-policy-wg] AP WG Agenda for RIPE63 In-Reply-To: <20111026170025.GP72014@Space.Net> References: <20111026170025.GP72014@Space.Net> Message-ID: <20111026174731.GQ72014@Space.Net> Hi, On Wed, Oct 26, 2011 at 07:00:25PM +0200, Gert Doering wrote: > below you can find a draft for the RIPE address policy WG meeting's agenda, > which will take place in Amsterdam in the following three time slots: Well. Please don't change your travel plans yet, of course we meet in Vienna. (I think we've spent three weeks discussing bits of the agenda, but nobody reall reads the boilerplate text... except Wolfang :) - thanks) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Henk.Steenman at ams-ix.net Wed Oct 26 22:15:04 2011 From: Henk.Steenman at ams-ix.net (Henk Steenman) Date: Wed, 26 Oct 2011 22:15:04 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: <20111025095148.20991A4801F@argon.sov.someaddress.net> Message-ID: <4D858B15-471A-4880-9518-273A0510B76D@ams-ix.net> I fully support this proposal - Henk Steenman On Oct 26, 2011, at 4:34 PM, Tom Hodgson wrote: > On Tue, 25 Oct 2011, Emilio Madaio wrote: >> >> A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation >> and Assignment Policies for the RIPE NCC Service Region", is now >> available for discussion. >> > > > I do wonder how many special cases we will see crop up before we've let v4 exit stage left, however the benefits brought by the reservation of a /16 for increased network interconnection I think justify the addition to the policy. There is a question of whether the IXP should just become an LIR to receive an allocation that way, however I neither believe that an IXP should be forced into becoming an LIR or that all IXPs necessarily have an appropriate entity with which to do so, especially when they are in the startup phase. > > Therefore I support this policy. > > -- > Tom Hodgson > tom at someaddress.net > From wolfgang.tremmel at de-cix.net Wed Oct 26 22:22:03 2011 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Wed, 26 Oct 2011 22:22:03 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4D858B15-471A-4880-9518-273A0510B76D@ams-ix.net> References: <20111025095148.20991A4801F@argon.sov.someaddress.net> <4D858B15-471A-4880-9518-273A0510B76D@ams-ix.net> Message-ID: <4EA86BEB.3090603@de-cix.net> On 26.10.11 22:15, Henk Steenman wrote: > I fully support this proposal I also support this proposal best regards, Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.tremmel at de-cix.net DE-CIX Management GmbH Phone: +49 69 1730 902-26 Lindleystr. 12, 60314 Frankfurt Mobile: +49 171 8600 816 Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln From gert at space.net Wed Oct 26 22:56:32 2011 From: gert at space.net (Gert Doering) Date: Wed, 26 Oct 2011 22:56:32 +0200 Subject: [address-policy-wg] IPv6 routing table stats In-Reply-To: <20111002175123.GX72014@Space.Net> References: <20110928205724.GV3290@x27.adm.denic.de> <20110929185645.GY72014@Space.Net> <20111002175123.GX72014@Space.Net> Message-ID: <20111026205632.GU72014@Space.Net> Hi, speaking to myself again... On Sun, Oct 02, 2011 at 07:51:23PM +0200, Gert Doering wrote: > On Fri, Sep 30, 2011 at 05:43:37PM +0200, Martin Millnert wrote: > > I was actually looking for you the other day on IRC... I saw a couple > > of /48's in DFZ coming not from PIv6, but allocated by LIR's (thus, > > announced with different origin than the /32 they came from), the > > other day. IIRC, your data captured these [ easier-than-PIv6 ] > > allocations as well. Is that right? [..] > I'll re-run these scripts some time next week, and post fully up-to-date > numbers. So here's the (to-be-) weekly updated numbers: http://www.space.net/~gert/RIPE/weekly/ http://www.space.net/~gert/RIPE/weekly/2011/43/ most of the material is "the slides that I always do", just with the most recent numbers - there is one image that's new, and that's breaking down the routing table by "LIR prefixes", "non-LIR prefixes" (=PI), and "more specifics of either category". The text has more explanation how the matching to categories is done. ... sending this, I see questions coming up "can we have this for 5-year ranges" - yes, can be done, but the apparatus isn't there yet. Stay tuned. Gert Doering -- IPv6 number geek -- 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ula at ripn.net Thu Oct 27 10:17:10 2011 From: ula at ripn.net (Larisa Yurkina) Date: Thu, 27 Oct 2011 12:17:10 +0400 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4EA86BEB.3090603@de-cix.net> References: <20111025095148.20991A4801F@argon.sov.someaddress.net> <4D858B15-471A-4880-9518-273A0510B76D@ams-ix.net> <4EA86BEB.3090603@de-cix.net> Message-ID: <4EA91385.7080404@ripn.net> Wolfgang Tremmel wrote, 27.10.2011 0:22: > On 26.10.11 22:15, Henk Steenman wrote: > >> I fully support this proposal >> > > I also support this proposal > > best regards, > Wolfgang > > I support this proposal. -- Larisa Yurkina RosNIIROS tel: +7(495)737-0604 From vpages at rezopole.net Thu Oct 27 11:01:57 2011 From: vpages at rezopole.net (Vincent PAGES) Date: Thu, 27 Oct 2011 11:01:57 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <4EA91E05.8070700@rezopole.net> HI, I'm the technical manager of LyonIX (Lyon Internet Exchange http://www.lyonix.net) We support the proposal. Regards, -- Vincent PAGES - Responsable Technique Rezopole - Lyonix Rezopole inaugure SaintetIX le 17 Novembre 2011 Mail: vpages at rezopole.net Standard: +33 4 27 46 00 50 Fax: +33 4 27 46 00 51 PGP: 7E06128C Skype: vincent.rezopole REZOPOLE (LYONIX Le GIX NAP de Lyon / Rhone-Alpes) 5 passage de l'avenir 69200 V?nissieux France - Email : info at lyonix.net - Web : www.lyonix.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at titley.com Thu Oct 27 14:25:34 2011 From: nigel at titley.com (Nigel Titley) Date: Thu, 27 Oct 2011 13:25:34 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <4EA94DBE.4000905@titley.com> On 25/10/2011 10:51, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > I hate to be a killjoy here, but doesn't the average IXP use less than a /22? Part of the rational says: "Much of the work that goes into creating Internet Exchange Points today is done in regions of the world where there is no Internet Exchange Point yet. Opening an IXP helps to develop the Internet and Internet community in that region, so the work really is 'good of the Internet'. Starving these regions of an opportunity to build a simple open Internet Exchange Point would be severely damaging to Internet users in regions under-served by IXPs." But a brand new IXP will be able to get a /22 under the existing rules. Surely that's enough? I have a general dislike of "special cases" especially where they don't seem to be necessary. And this seems to be unnecessary. Nigel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Oct 27 15:26:11 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 27 Oct 2011 14:26:11 +0100 Subject: [address-policy-wg] ring-fencing v4 space for IXPs in 2011-05 In-Reply-To: <4EA94DBE.4000905@titley.com> References: <4EA94DBE.4000905@titley.com> Message-ID: <168C766C-899A-49C1-B388-610C0EE3EF1F@rfc1035.com> On 27 Oct 2011, at 13:25, Nigel Titley wrote: > But a brand new IXP will be able to get a /22 under the existing > rules. Surely that's enough? > > I have a general dislike of "special cases" especially where they > don't seem to be necessary. And this seems to be unnecessary. +1 on both points. I wonder too about how this policy could be gamed. What happens if new (or existing) LIRs pretend to be IXPs to snatch extra v4 space they wouldn't otherwise get? Once the v4 ship really starts to sink, people are bound to grap hold of anything that looks like a lifeboat and make sure nobody else gets to climb aboard. From andy at nosignal.org Thu Oct 27 16:56:16 2011 From: andy at nosignal.org (Andy Davidson) Date: Thu, 27 Oct 2011 15:56:16 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4EA94DBE.4000905@titley.com> References: <4EA94DBE.4000905@titley.com> Message-ID: <5F51EF2C-8865-4D85-B616-364E58846A5F@nosignal.org> On 27 Oct 2011, at 13:25, Nigel Titley wrote: > Part of the rational says: "Much of the work that goes into creating Internet Exchange Points today is done in regions of the world where there is no Internet Exchange Point yet. Opening an IXP helps to develop the Internet and Internet community in that region, so the work really is 'good of the Internet'. Starving these regions of an opportunity to build a simple open Internet Exchange Point would be severely damaging to Internet users in regions under-served by IXPs." > > But a brand new IXP will be able to get a /22 under the existing rules. Surely that's enough? Hi, Nigel and Jim Thanks for the emails. Almost no IXPs have PA, and most community based ones don't have budget for their own LIR. This policy allows successful IXPs to be born in 2012 as they have been between 1994 and 2011. i.e. the equivalent of PI. It will provide policy parity with IPv6 too, where IXP specific policy exists in order to sidestep restrictions designed for other networks. Thanks Andy From nigel at titley.com Thu Oct 27 17:42:45 2011 From: nigel at titley.com (Nigel Titley) Date: Thu, 27 Oct 2011 16:42:45 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <5F51EF2C-8865-4D85-B616-364E58846A5F@nosignal.org> References: <4EA94DBE.4000905@titley.com> <5F51EF2C-8865-4D85-B616-364E58846A5F@nosignal.org> Message-ID: <4EA97BF5.9060404@titley.com> On 27/10/2011 15:56, Andy Davidson wrote: > Thanks for the emails. > > Almost no IXPs have PA, and most community based ones don't have budget for their own LIR. This policy allows successful IXPs to be born in 2012 as they have been between 1994 and 2011. i.e. the equivalent of PI. It will provide policy parity with IPv6 too, where IXP specific policy exists in order to sidestep restrictions designed for other networks. Hmm, yes, I see what you mean. I think what might have confused me is the 5.6 section heading "Use of last /8 for PA allocations". The IXP allocation section (not being PA, as you've pointed out) doesn't really belong here. And yes, I agree this is nit-picking, before anyone says it for me. And following the clarification I'm happy with the intent of the proposal (whilst still being unhappy with special cases in general). Nigel From andy at nosignal.org Thu Oct 27 18:53:05 2011 From: andy at nosignal.org (Andy Davidson) Date: Thu, 27 Oct 2011 17:53:05 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4EA97BF5.9060404@titley.com> References: <4EA94DBE.4000905@titley.com> <5F51EF2C-8865-4D85-B616-364E58846A5F@nosignal.org> <4EA97BF5.9060404@titley.com> Message-ID: <274B49E0-BA0C-4644-B2B2-9E1EC4760400@nosignal.org> Hi there, On 27 Oct 2011, at 16:42, Nigel Titley wrote: > On 27/10/2011 15:56, Andy Davidson wrote: >> Thanks for the emails. >> >> Almost no IXPs have PA, and most community based ones don't have budget for their own LIR. This policy allows successful IXPs to be born in 2012 as they have been between 1994 and 2011. i.e. the equivalent of PI. It will provide policy parity with IPv6 too, where IXP specific policy exists in order to sidestep restrictions designed for other networks. > Hmm, yes, I see what you mean. I think what might have confused me is the 5.6 section heading "Use of last /8 for PA allocations". The IXP allocation section (not being PA, as you've pointed out) doesn't really belong here. I see. You are right, well spotted. Maybe we should vary the section headed to "Uses of the final /8" ? > And yes, I agree this is nit-picking, before anyone says it for me. > > And following the clarification I'm happy with the intent of the proposal (whilst still being unhappy with special cases in general). Thank you for your support and good ideas. Andy From andy at nosignal.org Thu Oct 27 18:54:55 2011 From: andy at nosignal.org (Andy Davidson) Date: Thu, 27 Oct 2011 17:54:55 +0100 Subject: [address-policy-wg] ring-fencing v4 space for IXPs in 2011-05 In-Reply-To: <168C766C-899A-49C1-B388-610C0EE3EF1F@rfc1035.com> References: <4EA94DBE.4000905@titley.com> <168C766C-899A-49C1-B388-610C0EE3EF1F@rfc1035.com> Message-ID: <868FD730-A75F-42B0-8E78-22A26E621ED0@nosignal.org> Hi Jim -- On 27 Oct 2011, at 14:26, Jim Reid wrote: > I wonder too about how this policy could be gamed. What happens if new (or existing) LIRs pretend to be IXPs to snatch extra v4 space they wouldn't otherwise get? The IPRAs were very diligent enough to prevent this from happening when IXPs were allowed v6 PI, when all other organisations were not. There was a clean definition written which has stood firm in later analysis in ap sessions. I think this risk is well mitigated against. Andy From jim at rfc1035.com Thu Oct 27 20:05:13 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 27 Oct 2011 19:05:13 +0100 Subject: [address-policy-wg] ring-fencing v4 space for IXPs in 2011-05 In-Reply-To: <868FD730-A75F-42B0-8E78-22A26E621ED0@nosignal.org> References: <4EA94DBE.4000905@titley.com> <168C766C-899A-49C1-B388-610C0EE3EF1F@rfc1035.com> <868FD730-A75F-42B0-8E78-22A26E621ED0@nosignal.org> Message-ID: <7DFAFCE2-1DBC-43E6-93E8-68074020BD41@rfc1035.com> On 27 Oct 2011, at 17:54, Andy Davidson wrote: >> I wonder too about how this policy could be gamed. What happens if >> new (or existing) LIRs pretend to be IXPs to snatch extra v4 space >> they wouldn't otherwise get? > > The IPRAs were very diligent enough to prevent this from happening > when IXPs were allowed v6 PI, when all other organisations were not. > > There was a clean definition written which has stood firm in later > analysis in ap sessions. > > I think this risk is well mitigated against. OK. Thanks Andy. I raised this as a theoretical concern. So provided the IPRAs can keep a lid on potential abuse of the policy, that's (sort of) fine. That'll be "good enough" IMO. I don't have a strong objection to the proposal even though I still have some reservations. From barry at opensolutions.ie Thu Oct 27 20:36:29 2011 From: barry at opensolutions.ie (Barry O'Donovan) Date: Thu, 27 Oct 2011 19:36:29 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20111025095217.ABF766138D@mail.opensolutions.ie> References: <20111025095217.ABF766138D@mail.opensolutions.ie> Message-ID: <4EA9A4AD.1020600@opensolutions.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/10/11 10:51, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service > Region", is now available for discussion. We support this policy. - Barry - -- Kind regards, Barry O'Donovan http://www.opensolutions.ie/ Open Source Solutions Ltd Lynx House, Old Church Road, Lower Kilmacud Road, Stillorgan, Co. Dublin. Open Source Solutions Limited is a company registered in the Republic of Ireland (#438231). Open Source Solutions Limited trades as Open Solutions (registered business name #329120). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ppK0ACgkQ9qwC7To4L8xItACdEfwnvF3KijY7um0Pba0/VfsQ ly0An1TO9dfQfDjKm9TCDt4kexwS589H =uiRD -----END PGP SIGNATURE----- From andy at nosignal.org Thu Oct 27 21:30:22 2011 From: andy at nosignal.org (Andy Davidson) Date: Thu, 27 Oct 2011 20:30:22 +0100 Subject: [address-policy-wg] ring-fencing v4 space for IXPs in 2011-05 In-Reply-To: <7DFAFCE2-1DBC-43E6-93E8-68074020BD41@rfc1035.com> References: <4EA94DBE.4000905@titley.com> <168C766C-899A-49C1-B388-610C0EE3EF1F@rfc1035.com> <868FD730-A75F-42B0-8E78-22A26E621ED0@nosignal.org> <7DFAFCE2-1DBC-43E6-93E8-68074020BD41@rfc1035.com> Message-ID: Hi there, On 27 Oct 2011, at 19:05, Jim Reid wrote: > OK. Thanks Andy. I raised this as a theoretical concern. So provided the IPRAs can keep a lid on potential abuse of the policy, that's (sort of) fine. That'll be "good enough" IMO. I don't have a strong objection to the proposal even though I still have some reservations. Thanks for helping to give the policy proper scrutiny and for your support ! Best wishes, Andy From andy at lonap.net Wed Oct 26 18:25:55 2011 From: andy at lonap.net (Andy Davidson) Date: Wed, 26 Oct 2011 17:25:55 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <6B4D51FB-1F05-4E5B-AC6E-E1345A5AFDD4@lonap.net> References: <6B4D51FB-1F05-4E5B-AC6E-E1345A5AFDD4@lonap.net> Message-ID: <94BFBB64-8315-49DE-A76F-58DA126DB927@lonap.net> > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 I support this proposal. -harald > > We encourage you to review this proposal and send your comments to > before 22 November 2011. -- Harald Michl Vienna University - ACOnet www.ACO.net - VIX www.VIX.at Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: +43 1 4277 - 14078 (Fax: - 9140) HM3550-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From michiel.appelman at ams-ix.net Fri Oct 28 09:11:31 2011 From: michiel.appelman at ams-ix.net (Michiel Appelman) Date: Fri, 28 Oct 2011 09:11:31 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <3C519C12-543B-4EEE-A5C9-E253F474D8E4@ams-ix.net> I fully support the new policy proposal. -- Michiel Appelman AMS-IX From steven.bakker at ams-ix.net Fri Oct 28 10:03:32 2011 From: steven.bakker at ams-ix.net (Steven Bakker) Date: Fri, 28 Oct 2011 10:03:32 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <4EAA61D4.8070107@ams-ix.net> Just piping in to say I support this proposal. -- Steven From t.schallar at avalon.at Fri Oct 28 10:23:07 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Fri, 28 Oct 2011 10:23:07 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 PI ? Message-ID: <4EAA666B.5010905@avalon.at> Hello! Four days ago the current phase on http://www.ripe.net/ripe/policies/proposals/2011-02 ended (Sep.26th-Oct.24th). What now? regards, Thomas From ahmed at tamkien.com Fri Oct 28 11:01:53 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Fri, 28 Oct 2011 11:01:53 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal Message-ID: In reality RIPE will be giving up a finite resource for implementing one particular type of a transition protocol, i.e. 6rd. Can't the response be go back to your vendor and ask them to implement a different transition protocol that doesn't waste address space ? After all, there are many such protocols out there. -Ahmed Date: Tue, 25 Oct 2011 11:04:20 +0200 From: "Jan Zorz @ go6.si" Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal To: address-policy-wg at ripe.net Message-ID: <4EA67B94.2090305 at go6.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/25/11 9:44 AM, Ahmed Abu-Abed wrote: > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented > as a software client so LIRs do not need to change the CPEs to roll out > IPv6 to end users. Dear Ahmed, We are aware of many similar technologies that would fulfill the same or similar goal, but what we are doing here is just listen to complains and requests from the field and try to make deployment of IPv6 (native or as service in this case) as easy as possible with this change of the policy proposal. Reality usually wins :) Cheers, Jan -------------------------------------------------- From: "Ahmed Abu-Abed" Sent: Tuesday, October 25, 2011 9:44 AM To: "RIPE Address Policy" Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented as > a software client so LIRs do not need to change the CPEs to roll out IPv6 > to end users. > > -Ahmed > > ------------------------------ > > Message: 8 > Date: Mon, 24 Oct 2011 21:28:47 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > (Extension of the Minimum Size for IPv6 Initial Allocation) > To: address-policy-wg at ripe.net > Message-ID: <4EA5BC6F.90005 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/24/11 7:29 PM, Randy Bush wrote: >> why are we screwing around? let's go straight to a /16 or at least a >> /20. > > it would not be fair to legacy v6 allocations :) > > can only expand to /29 without renumbering :S > > cheers, Jan > From Remco.vanMook at eu.equinix.com Fri Oct 28 11:14:13 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Fri, 28 Oct 2011 10:14:13 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: Message-ID: Dear Ahmed, I would have completely agreed with you five years ago. Problem is, we've managed to run out of time and 6rd is one of the few transition protocols that has a chance of being implemented in many eyeball networks in the next 12-18 months. I don't like 6RD much either (actually I also don't like how IPv6 reserves 64 bits for the host part), but this is address policy and not the protocol police. Address space that is used is not wasted, and if LIRs use it below the thresholds set in IPv6 allocation policy (which, surprise surprise, 6rd is likely to do) at least those LIRs won't be entitled to any followup address space until they've cleaned up. Best regards, Remco van Mook Director of Interconnection, Europe remco.vanmook at eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 28-10-11 11:01, "Ahmed Abu-Abed" wrote: >In reality RIPE will be giving up a finite resource for implementing one >particular type of a transition protocol, i.e. 6rd. > >Can't the response be go back to your vendor and ask them to implement a >different transition protocol that doesn't waste address space ? After >all, >there are many such protocols out there. > >-Ahmed > > >Date: Tue, 25 Oct 2011 11:04:20 +0200 >From: "Jan Zorz @ go6.si" >Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal >To: address-policy-wg at ripe.net >Message-ID: <4EA67B94.2090305 at go6.si> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 10/25/11 9:44 AM, Ahmed Abu-Abed wrote: >> Interesting to see a v6-in-v4 access protocol triggering a significant >> change in allocation policy. >> >> As 6rd gobbles up 32 bits for the v4 address at the consumers v6 >> assignment, there is an alternative in RFC 5572 (TSP) that presents >> v6-in-v4 access on CPEs without such a need. And TSP can be implemented >> as a software client so LIRs do not need to change the CPEs to roll out >> IPv6 to end users. > >Dear Ahmed, > >We are aware of many similar technologies that would fulfill the same or >similar goal, but what we are doing here is just listen to complains and >requests from the field and try to make deployment of IPv6 (native or as >service in this case) as easy as possible with this change of the policy >proposal. > >Reality usually wins :) > >Cheers, Jan > >-------------------------------------------------- >From: "Ahmed Abu-Abed" >Sent: Tuesday, October 25, 2011 9:44 AM >To: "RIPE Address Policy" >Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > >> Interesting to see a v6-in-v4 access protocol triggering a significant >> change in allocation policy. >> >> As 6rd gobbles up 32 bits for the v4 address at the consumers v6 >> assignment, there is an alternative in RFC 5572 (TSP) that presents >> v6-in-v4 access on CPEs without such a need. And TSP can be implemented >>as >> a software client so LIRs do not need to change the CPEs to roll out >>IPv6 >> to end users. >> >> -Ahmed >> >> ------------------------------ >> >> Message: 8 >> Date: Mon, 24 Oct 2011 21:28:47 +0200 >> From: "Jan Zorz @ go6.si" >> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal >> (Extension of the Minimum Size for IPv6 Initial Allocation) >> To: address-policy-wg at ripe.net >> Message-ID: <4EA5BC6F.90005 at go6.si> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 10/24/11 7:29 PM, Randy Bush wrote: >>> why are we screwing around? let's go straight to a /16 or at least a >>> /20. >> >> it would not be fair to legacy v6 allocations :) >> >> can only expand to /29 without renumbering :S >> >> cheers, Jan >> > 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 jan at go6.si Fri Oct 28 11:17:32 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 28 Oct 2011 11:17:32 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: References: Message-ID: <4EAA732C.70400@go6.si> On 10/28/11 11:01 AM, Ahmed Abu-Abed wrote: > In reality RIPE will be giving up a finite resource for implementing one > particular type of a transition protocol, i.e. 6rd. Hi, Arguably "infinite" resource. More towards "infinite" than to "finite" resource. No. RIPE-NCC would be giving out resources, that people need to deploy IPv6, native or as a service. > > Can't the response be go back to your vendor and ask them to implement a > different transition protocol that doesn't waste address space ? After > all, there are many such protocols out there. It surely can. Good luck with that :) 6RD is here, even chipset vendors are building HW acceleration support for it. Again, to be clear, I'm not perfectly ok with 6RD, as it is resources wastefull mechanism and "wrong way of doing right thing" and we'll probably never use it in our country, but still, that's my personal opinion and has nothing to do with the fact, that it's being widely deployed or at least many of opers would deploy it today if they had the v6 resources to do that. But, hitting the HD ration bump for additional allocation seems to be the show-stopper for them. Cheers, Jan From jan at go6.si Fri Oct 28 11:18:55 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 28 Oct 2011 11:18:55 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: References: Message-ID: <4EAA737F.8090506@go6.si> On 10/28/11 11:14 AM, Remco Van Mook wrote: > > Dear Ahmed, > > I would have completely agreed with you five years ago. Problem is, we've > managed to run out of time and 6rd is one of the few transition protocols > that has a chance of being implemented in many eyeball networks in the > next 12-18 months. I don't like 6RD much either (actually I also don't > like how IPv6 reserves 64 bits for the host part), but this is address > policy and not the protocol police. > > Address space that is used is not wasted, and if LIRs use it below the > thresholds set in IPv6 allocation policy (which, surprise surprise, 6rd is > likely to do) at least those LIRs won't be entitled to any followup > address space until they've cleaned up. +1 Thnx :) Cheers, Jan From ebais at a2b-internet.com Fri Oct 28 11:25:59 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 28 Oct 2011 11:25:59 +0200 Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 PI ? In-Reply-To: <4EAA666B.5010905@avalon.at> References: <4EAA666B.5010905@avalon.at> Message-ID: <007301cc9553$9aa6d230$cff47690$@com> Hi Thomas, > Four days ago the current phase on > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > ended (Sep.26th-Oct.24th). What now? This means that all the great minds of the RIPE WG's (the WG chairs) need to agree that consensus was reached (or not) and give their feedback to the AP-WG chairs. When they all agree there is consensus, they will inform Emilio and us on the outcome. There is no formal time for that step and in some cases did could take some time, due to the history of a proposal or the amount of time it takes for some of the WG chairs to go through all the emails. But having a RIPE meeting next week might help in a nudge or two :) This is what I've heard on the process as it was explained by Sander to me. Regards, Erik Bais From ot at cisco.com Fri Oct 28 11:30:54 2011 From: ot at cisco.com (Ole Troan) Date: Fri, 28 Oct 2011 11:30:54 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: References: Message-ID: Ahmed, > In reality RIPE will be giving up a finite resource for implementing one particular type of a transition protocol, i.e. 6rd. finite => there are 67 million /29s. and there is what < 15000 ISPs in the world? given that we only use 1/8 of the IPv6 address space for this model of addressing. do we get it wrong, we have 7 more tries. the biggest hurdle we have now is to get IPv6 deployed; if we don't succeed in that it doesn't much matter that we have conserved address space that no-one uses... ;-) cheers, Ole > > Can't the response be go back to your vendor and ask them to implement a different transition protocol that doesn't waste address space ? After all, there are many such protocols out there. > > -Ahmed > > > Date: Tue, 25 Oct 2011 11:04:20 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > To: address-policy-wg at ripe.net > Message-ID: <4EA67B94.2090305 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/25/11 9:44 AM, Ahmed Abu-Abed wrote: >> Interesting to see a v6-in-v4 access protocol triggering a significant >> change in allocation policy. >> >> As 6rd gobbles up 32 bits for the v4 address at the consumers v6 >> assignment, there is an alternative in RFC 5572 (TSP) that presents >> v6-in-v4 access on CPEs without such a need. And TSP can be implemented >> as a software client so LIRs do not need to change the CPEs to roll out >> IPv6 to end users. > > Dear Ahmed, > > We are aware of many similar technologies that would fulfill the same or > similar goal, but what we are doing here is just listen to complains and > requests from the field and try to make deployment of IPv6 (native or as > service in this case) as easy as possible with this change of the policy > proposal. > > Reality usually wins :) > > Cheers, Jan > > -------------------------------------------------- > From: "Ahmed Abu-Abed" > Sent: Tuesday, October 25, 2011 9:44 AM > To: "RIPE Address Policy" > Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > >> Interesting to see a v6-in-v4 access protocol triggering a significant change in allocation policy. >> >> As 6rd gobbles up 32 bits for the v4 address at the consumers v6 assignment, there is an alternative in RFC 5572 (TSP) that presents v6-in-v4 access on CPEs without such a need. And TSP can be implemented as a software client so LIRs do not need to change the CPEs to roll out IPv6 to end users. >> >> -Ahmed >> >> ------------------------------ >> >> Message: 8 >> Date: Mon, 24 Oct 2011 21:28:47 +0200 >> From: "Jan Zorz @ go6.si" >> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal >> (Extension of the Minimum Size for IPv6 Initial Allocation) >> To: address-policy-wg at ripe.net >> Message-ID: <4EA5BC6F.90005 at go6.si> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 10/24/11 7:29 PM, Randy Bush wrote: >>> why are we screwing around? let's go straight to a /16 or at least a >>> /20. >> >> it would not be fair to legacy v6 allocations :) >> >> can only expand to /29 without renumbering :S >> >> cheers, Jan > From nick at inex.ie Fri Oct 28 11:53:53 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 28 Oct 2011 10:53:53 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: References: Message-ID: <4EAA7BB1.7040902@inex.ie> On 28/10/2011 10:30, Ole Troan wrote: > finite => there are 67 million /29s. and there is what < 15000 ISPs in the world? Last I looked which was many months ago, ~37000 ASNs with a time-consistent average of 1.4 ipv6 prefixes each. Nick From tom at portfast.co.uk Fri Oct 28 11:49:54 2011 From: tom at portfast.co.uk (Tom Bird) Date: Fri, 28 Oct 2011 10:49:54 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: Message-ID: <4EAA7AC2.8090608@portfast.co.uk> On 25/10/11 10:51, Emilio Madaio wrote: > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 Morning, I support this proposal. -- Tom Bird Director, http://www.portfast.co.uk/ : AS8916 UK Limited company #6061075 : +44 1777 29 28 27 From david.freedman at uk.clara.net Fri Oct 28 12:28:23 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 28 Oct 2011 10:28:23 +0000 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <94BFBB64-8315-49DE-A76F-58DA126DB927@lonap.net> Message-ID: Support. David Freedman Claranet. From: Andy Davidson > Date: Wed, 26 Oct 2011 17:25:55 +0100 To: EURO-IX Members List > Subject: Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Resent-From: Harald Michl > Resent-To: > Resent-Date: Fri, 28 Oct 2011 09:18:48 +0200 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-05 I support this proposal. -harald We encourage you to review this proposal and send your comments to > before 22 November 2011. -- Harald Michl > Vienna University - ACOnet www.ACO.net - VIX www.VIX.at Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: +43 1 4277 - 14078 (Fax: - 9140) HM3550-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Fri Oct 28 13:51:36 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 28 Oct 2011 13:51:36 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4EAA7AC2.8090608@portfast.co.uk> References: <4EAA7AC2.8090608@portfast.co.uk> Message-ID: <00af01cc9567$f27b9fe0$d772dfa0$@com> Hi, > On 25/10/11 10:51, Emilio Madaio wrote: > > > You can find the full proposal at: > > > > http://www.ripe.net/ripe/policies/proposals/2011-05 I want to start with stating that I support the overall intention of this proposal. On the topic of why this should be placed in the final /8 and the combination of LIR's and IXP's, I would ask the community look into the following: There are basically 2 types of IXP's and in order to make use of this particular type of space, I would recommend that it would be limited to none commercial - not for profit - IXP's. - Commercial IXP's aka for profit IXP's, should also be able to sign-up for a LIR status and get IP space from there. - Non-profit IXP's, for the good of the internet, should be able to get IP space under this particular policy. This should be fairly easy for an IPRA to check. Regards, Erik Bais From job at instituut.net Fri Oct 28 13:58:22 2011 From: job at instituut.net (Job Snijders) Date: Fri, 28 Oct 2011 13:58:22 +0200 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: Message-ID: Dear All, > From: Andy Davidson > >> You can find the full proposal at: >> >> >> http://www.ripe.net/ripe/policies/proposals/2011-05 I support this proposal. Kind regards, Job Snijders From andy at nosignal.org Fri Oct 28 14:04:06 2011 From: andy at nosignal.org (Andy Davidson) Date: Fri, 28 Oct 2011 13:04:06 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <00af01cc9567$f27b9fe0$d772dfa0$@com> References: <4EAA7AC2.8090608@portfast.co.uk> <00af01cc9567$f27b9fe0$d772dfa0$@com> Message-ID: On 28 Oct 2011, at 12:51, Erik Bais wrote: >> On 25/10/11 10:51, Emilio Madaio wrote: >> >>> You can find the full proposal at: >>> >>> http://www.ripe.net/ripe/policies/proposals/2011-05 > > I want to start with stating that I support the overall intention of this > proposal. Thank you for your support. > - Commercial IXP's aka for profit IXP's, should also be able to sign-up for a LIR status and get IP space from there. > - Non-profit IXP's, for the good of the internet, should be able to get IP space under this particular policy. > This should be fairly easy for an IPRA to check. This might be hard for IPRAs IMO. How about an IXP which has a commercial (non-association) constitution but no intention to profit from members ? How about an IXP which is a free product of a commercial company, that will charge no fees ? How about an IXP with an non-profit constitution, and association, that does in fact make a large constitution and possibly is permitted to redistribute it ? Euro-IX identified 127 IXPs in Europe. I think we could count up about 150 different constitutions in those 127 if we looked hard enough and solicited enough opinions. ;-) I think that even a commercial IXP has the power to be 'good of the internet', even though my personal opinion strongly favours community owned and run initiatives. I think we may see more commercial IXPs in the future in regions where the fledgling community can not bear the risk. Many thanks for writing with an opinion. Andy From andy at nosignal.org Fri Oct 28 14:08:49 2011 From: andy at nosignal.org (Andy Davidson) Date: Fri, 28 Oct 2011 13:08:49 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: References: <4EAA7AC2.8090608@portfast.co.uk> <00af01cc9567$f27b9fe0$d772dfa0$@com> Message-ID: On 28 Oct 2011, at 13:04, Andy Davidson wrote: > This might be hard for IPRAs IMO. How about an IXP which has a commercial (non-association) constitution but no intention to profit from members ? How about an IXP which is a free product of a commercial company, that will charge no fees ? How about an IXP with an non-profit constitution, and association, that does in fact make a large constitution and possibly is permitted to redistribute it ? Sorry, the third example is supposed to be ... "How about an IXP with an non-profit constitution, and association, that does in fact make a large surplus and possibly is permitted to redistribute it ?" From gert at space.net Fri Oct 28 14:28:51 2011 From: gert at space.net (Gert Doering) Date: Fri, 28 Oct 2011 14:28:51 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: <4EAA7BB1.7040902@inex.ie> References: <4EAA7BB1.7040902@inex.ie> Message-ID: <20111028122851.GP72014@Space.Net> Hi, On Fri, Oct 28, 2011 at 10:53:53AM +0100, Nick Hilliard wrote: > On 28/10/2011 10:30, Ole Troan wrote: > > finite => there are 67 million /29s. and there is what < 15000 ISPs in the world? > > Last I looked which was many months ago, ~37000 ASNs with a time-consistent > average of 1.4 ipv6 prefixes each. Thanks for poking me to add these to http://www.space.net/~gert/RIPE/weekly/ We're not at 1.57 prefixes per AS (on average), with about 6600 active IPv6 ASes. (And no, we don't have 37000 ASNs with 1.4 ipv6 prefixes each yet - if we had, I would start celebrating, and then go on turning off IPv4) Gert Doering -- IPv6 number guy -- 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 jim at rfc1035.com Fri Oct 28 15:20:41 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 28 Oct 2011 14:20:41 +0100 Subject: [address-policy-wg] 2011-05 and profit/non-profit IXPs In-Reply-To: <00af01cc9567$f27b9fe0$d772dfa0$@com> References: <4EAA7AC2.8090608@portfast.co.uk> <00af01cc9567$f27b9fe0$d772dfa0$@com> Message-ID: On 28 Oct 2011, at 12:51, Erik Bais wrote: > There are basically 2 types of IXP's and in order to make use of this > particular type of space, I would recommend that it would be limited > to none > commercial - not for profit - IXP's. > > This should be fairly easy for an IPRA to check. I think you vastly underestimate that task. Try coming up with watertight definitions of "for profit" and "non-profit". For bonus points, get these definitions to stand up across the NCC's service region: national variations in company law, legal entities, governance models, etc. I strongly dislike the notion of sub-typing within these special case allocations to IXPs. It adds complexity and there don't seem to be any benefits from doing so. Let's just have a policy which makes space available to IXPs and be done with it. That's already one special case too many IMO. From nick at inex.ie Fri Oct 28 15:37:27 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 28 Oct 2011 14:37:27 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: <20111028122851.GP72014@Space.Net> References: <4EAA7BB1.7040902@inex.ie> <20111028122851.GP72014@Space.Net> Message-ID: <4EAAB017.1090907@inex.ie> On 28/10/2011 13:28, Gert Doering wrote: > (And no, we don't have 37000 ASNs with 1.4 ipv6 prefixes each yet - if > we had, I would start celebrating, and then go on turning off IPv4) eh, sorry. I worded what I said rather badly. I meant that at the time I looked, there were 37,000 ASNs active on the internet. Separate to that, there had been a ratio of 1.4 ipv6 prefixes originated by each ASN that originated an ipv6 prefix, and that this ratio had been relatively consistent over the previous couple of years. Hope this clarifies. Definitely not 37000*1.4 = 51000 ipv6 prefixes. Nick From ot at cisco.com Fri Oct 28 15:41:19 2011 From: ot at cisco.com (Ole Troan) Date: Fri, 28 Oct 2011 15:41:19 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: <4EAAB017.1090907@inex.ie> References: <4EAA7BB1.7040902@inex.ie> <20111028122851.GP72014@Space.Net> <4EAAB017.1090907@inex.ie> Message-ID: >> (And no, we don't have 37000 ASNs with 1.4 ipv6 prefixes each yet - if >> we had, I would start celebrating, and then go on turning off IPv4) > > eh, sorry. I worded what I said rather badly. I meant that at the time I > looked, there were 37,000 ASNs active on the internet. Separate to that, > there had been a ratio of 1.4 ipv6 prefixes originated by each ASN that > originated an ipv6 prefix, and that this ratio had been relatively > consistent over the previous couple of years. Hope this clarifies. > > Definitely not 37000*1.4 = 51000 ipv6 prefixes. my point was to give an estimate of the number of possible 6rd users, compared to the number of /29s available. it is obviously far less than the total number of ASNs in use. cheers, Ole From david at sargasso.net Fri Oct 28 15:53:30 2011 From: david at sargasso.net (David Croft) Date: Fri, 28 Oct 2011 14:53:30 +0100 Subject: [address-policy-wg] [policy-announce] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20111025095147.DFBEC295D536@barracuda1.mail.comtec.net.uk> References: <20111025095147.DFBEC295D536@barracuda1.mail.comtec.net.uk> Message-ID: On 25 October 2011 10:51, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. I support this proposal as written. Regards, David Croft From jan at go6.si Fri Oct 28 16:57:27 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 28 Oct 2011 16:57:27 +0200 Subject: [address-policy-wg] 2011-05 and profit/non-profit IXPs In-Reply-To: References: <4EAA7AC2.8090608@portfast.co.uk> <00af01cc9567$f27b9fe0$d772dfa0$@com> Message-ID: <4EAAC2D7.9090506@go6.si> On 10/28/11 3:20 PM, Jim Reid wrote: > Let's just have a policy which makes space available to IXPs and be done > with it. That's already one special case too many IMO. +1 Support the proposal. /jan From cfriacas at fccn.pt Fri Oct 28 17:06:59 2011 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 28 Oct 2011 16:06:59 +0100 (WEST) Subject: [address-policy-wg] 2011-05 and profit/non-profit IXPs In-Reply-To: <4EAAC2D7.9090506@go6.si> References: <4EAA7AC2.8090608@portfast.co.uk> <00af01cc9567$f27b9fe0$d772dfa0$@com> <4EAAC2D7.9090506@go6.si> Message-ID: I also support this proposal. Regards, Carlos On Fri, 28 Oct 2011, Jan Zorz @ go6.si wrote: > On 10/28/11 3:20 PM, Jim Reid wrote: >> Let's just have a policy which makes space available to IXPs and be done >> with it. That's already one special case too many IMO. > > +1 > > Support the proposal. > > /jan > From rogerj at gmail.com Fri Oct 28 17:52:44 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Fri, 28 Oct 2011 17:52:44 +0200 Subject: [address-policy-wg] 2011-04 New Policy Proposal In-Reply-To: References: Message-ID: On Fri, Oct 28, 2011 at 11:30 AM, Ole Troan wrote: > finite => there are 67 million /29s. and there is what < 15000 ISPs in the world? > given that we only use 1/8 of the IPv6 address space for this model of addressing. do we get it wrong, we have 7 more tries. > the biggest hurdle we have now is to get IPv6 deployed; if we don't succeed in that it doesn't much matter that we have conserved address space that no-one uses... ;-) +1 :-) -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From gert at space.net Fri Oct 28 19:16:38 2011 From: gert at space.net (Gert Doering) Date: Fri, 28 Oct 2011 19:16:38 +0200 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification Message-ID: <20111028171638.GS72014@Space.Net> Hi AP WG, next week at the RIPE meeting (and by remote participation, of course) I want to continue discussing an idea that came up before, and that I brought up at RIPE 62 already - doing away with the distinction between IPv6 PA and IPv6 PI space, going for a "unified number distribution policy" (to give credits, it's not exactly my original idea, but has been brought up a couple of times by members of the community in the last years). Feedback from RIPE 62 was mostly positive, with "we need to think about many details", so Sander and I sat down and tried to write a concept document that has some answers about the details - which needs to be discussed, refined, and eventually formed into a full-featured policy proposal to go through the PDP. So far, this is to start the thought process, and to get your ideas about it - especially ideas of the sort "this is not going to work *because* ". But I'm taking "we want to keep the difference between PA and PI!" as well - but if you say so, please explain where you see the benefit of "more complicated rules". The discussion will take place on Thursday morning, in the 09:00-10:30 time slot. thanks for helping shape policy, Gert Doering -- APWG chair --------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks - Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution. Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print... Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: * base cost per year per LIR * yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks" Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/... - problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.) -- 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 millnert at gmail.com Sat Oct 29 16:56:40 2011 From: millnert at gmail.com (Martin Millnert) Date: Sat, 29 Oct 2011 16:56:40 +0200 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification In-Reply-To: <20111028171638.GS72014@Space.Net> References: <20111028171638.GS72014@Space.Net> Message-ID: <1319900200.3904.26.camel@natalie.csbnet.se> Hi Geert, thanks for taking the time, you and Sander, to get this discussion started. I will dive into just one of them with some feedback. :) On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote: > * yearly recurring cost "per block of numbers", independent of size(!), > reflecting the cost of handling the address space request, documentation, > RIPE database, etc., which increase if you need "many blocks" This was an interesting suggestion. Going straight for the details of one point, I wonder, what's the most fair way to reflect the handling cost of an address space request? A /24 telco request for a larger national / european / pan-european access network takes (on average) a much higher toll on IPRAs) than say, a (good) /48 single site allocation. Similarily, I'm not convinced that a /24 with a couple thousand more-specific objects of various kind in the database, should (or should not) have a higher "RIPE database maintenance cost share" than a single /48 with one of each. That's only the database maintenance however. So I guess I disagree with your conclusion from the arguments you iterated over. Out-of-the-box counter-proposal: IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application], Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*) registry / IPRA related costs, for example: * DB upkeep, org. * overhead for strictly registry-related org functions, *) number of LIRs at billing year end. (LIRs paying quarterly could pay Y1Q1, Y1Q2, Y1Q3, Y1Q4 by end-Y1 projections done quarterly, for a final adjustment of Y1 Y2Q1. mmmm details) This obviously does not take into account how to share RIPE NCC's costs of all its non-IP registry related undertakings. This is on purpose. Cheers, Martin From gert at space.net Sat Oct 29 22:51:43 2011 From: gert at space.net (Gert Doering) Date: Sat, 29 Oct 2011 22:51:43 +0200 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification In-Reply-To: <1319900200.3904.26.camel@natalie.csbnet.se> References: <20111028171638.GS72014@Space.Net> <1319900200.3904.26.camel@natalie.csbnet.se> Message-ID: <20111029205143.GB74658@Space.Net> Hi, On Sat, Oct 29, 2011 at 04:56:40PM +0200, Martin Millnert wrote: > On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote: > > * yearly recurring cost "per block of numbers", independent of size(!), > > reflecting the cost of handling the address space request, documentation, > > RIPE database, etc., which increase if you need "many blocks" > > > This was an interesting suggestion. > > Going straight for the details of one point, I wonder, what's the most > fair way to reflect the handling cost of an address space request? I see your point, and I'm buy no way insisting on "every block costs the same". The reason why I proposed to do it this way is to discourage large-scale ISPs from going for "we give all our customers a single /128 each, so we can run the whole country-wide network on a /48 and save lots of money!". We *want* them to give /56s (or such) to customers, and if there's a monetary penalty for doing so - is this the right message to send? (OTOH, depending on the final numbers, the per-block-per-year price might be low enough to make this all uninteresting - if it's "50 EUR per /48, 100 EUR per /32, 200 EUR for /28 or bigger", the financial incentive is not that strong). > So I guess I disagree with your conclusion from the arguments you > iterated over. What about the "encourage ISPs to give end-users a reasonably-sized network" argument? > Out-of-the-box counter-proposal: > IPRA interacting work (including address space requests) == > [IPRA hour fee] * [IPRA-time spent on application], > Infrastructure cost sharing (yearly recurring cost) == > [RIPE NCC specific registry / IPRA related costs] > ----------------------------------------- > number of LIRs at billing year end (*) I'm not sure I get that formula - are you dividing everything by number of LIRs, so everybody pays the same price? (Now that would be simple :) ). 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From randy at psg.com Sun Oct 30 12:08:26 2011 From: randy at psg.com (Randy Bush) Date: Sun, 30 Oct 2011 12:08:26 +0100 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification In-Reply-To: <1319900200.3904.26.camel@natalie.csbnet.se> References: <20111028171638.GS72014@Space.Net> <1319900200.3904.26.camel@natalie.csbnet.se> Message-ID: > A /24 telco request for a larger national / european / pan-european > access network takes (on average) a much higher toll on IPRAs) than > say, a (good) /48 single site allocation. it _could_ be the opposity o oh, dtag wants another /2, yep they eat them regularly, and we just do not have the depth to look deeply into their net design. fine o this weenie that wants a /48, who the heck are they and have they any net design randy From millnert at gmail.com Mon Oct 31 16:22:50 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 31 Oct 2011 16:22:50 +0100 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification In-Reply-To: <20111029205143.GB74658@Space.Net> References: <20111028171638.GS72014@Space.Net> <1319900200.3904.26.camel@natalie.csbnet.se> <20111029205143.GB74658@Space.Net> Message-ID: Hi Gert, On Sat, Oct 29, 2011 at 10:51 PM, Gert Doering wrote: > Hi, > > On Sat, Oct 29, 2011 at 04:56:40PM +0200, Martin Millnert wrote: >> On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote: >> > ? ? * yearly recurring cost "per block of numbers", independent of size(!), >> > ? ? ? reflecting the cost of handling the address space request, documentation, >> > ? ? ? RIPE database, etc., which increase if you need "many blocks" >> >> >> This was an interesting suggestion. >> >> Going straight for the details of one point, I wonder, what's the most >> fair way to reflect the handling cost of an address space request? > > I see your point, and I'm buy no way insisting on "every block costs the > same". Check. It looked like that (and I decided to bite). > The reason why I proposed to do it this way is to discourage large-scale > ISPs from going for "we give all our customers a single /128 each, so > we can run the whole country-wide network on a /48 and save lots of > money!". ?We *want* them to give /56s (or such) to customers, and if > there's a monetary penalty for doing so - is this the right message to > send? I'm not suggesting charge per block size either. :) > (OTOH, depending on the final numbers, the per-block-per-year price > might be low enough to make this all uninteresting - if it's "50 EUR > per /48, 100 EUR per /32, 200 EUR for /28 or bigger", the financial > incentive is not that strong). Agreed. >> So I guess I disagree with your conclusion from the arguments you >> iterated over. > > What about the "encourage ISPs to give end-users a reasonably-sized > network" argument? Good question.. Handle applications where users/customers are shown to be given /56s or larger, faster? (Ie. cheaper, according to below) >> Out-of-the-box counter-proposal: >> ? IPRA interacting work (including address space requests) == >> ? ? [IPRA hour fee] * [IPRA-time spent on application], Pay per direct load on the hostmasters. This could encourage people having more clue interacting with the RIPE NCC and so on. >> ? Infrastructure cost sharing (yearly recurring cost) == >> ? ?[RIPE NCC specific registry / IPRA related costs] >> ? ? ----------------------------------------- >> ? ? ? ?number of LIRs at billing year end (*) > > I'm not sure I get that formula - are you dividing everything by > number of LIRs, so everybody pays the same price? ?(Now that would be > simple :) ). Share *overhead* costs equally, yes. *shrug* :) Best, Martin From niels=apwg at bakker.net Mon Oct 31 16:34:27 2011 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Mon, 31 Oct 2011 16:34:27 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <8262jb27i7.fsf@mid.bfk.de> References: <82zkgp75s2.fsf@totally-fudged-out-message-id> <8262jb27i7.fsf@mid.bfk.de> Message-ID: <20111031153426.GR2336@burnout.tpb.net> * fweimer at bfk.de (Florian Weimer) [Wed 26 Oct 2011, 15:43 CEST]: >* Emilio Madaio: > >> http://www.ripe.net/ripe/policies/proposals/2011-05 > >I oppose this policy. IXPs shouldn't be special-cased. The >assumption of a single peering LAN per organization does not seem to >match the requirements of the industry. It is odd that preexisting >PI space must be returned, but not existing PA space. I assume PA space will just remain allocated but not assigned, i.e. falls under the LIR's assignment window requirements again. -- Niels. From gert at space.net Mon Oct 31 16:34:31 2011 From: gert at space.net (Gert Doering) Date: Mon, 31 Oct 2011 16:34:31 +0100 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification In-Reply-To: References: <20111028171638.GS72014@Space.Net> <1319900200.3904.26.camel@natalie.csbnet.se> <20111029205143.GB74658@Space.Net> Message-ID: <20111031153431.GL74658@Space.Net> Hi, On Mon, Oct 31, 2011 at 04:22:50PM +0100, Martin Millnert wrote: > >> Out-of-the-box counter-proposal: > > >> ? IPRA interacting work (including address space requests) == > >> ? ? [IPRA hour fee] * [IPRA-time spent on application], > > Pay per direct load on the hostmasters. This could encourage people > having more clue interacting with the RIPE NCC and so on. ... but backfires if you have a particularily fast or slow IPRA... since these are humans with differing background, your request might hit one IPRA that has very much or very little experience on the way *you* want to roll out your network... or extra curiosity adding more e-mail rounds... so I'm not sure this can be done in a way that would be considered "fair". Just throwing concerns around. > >> ? Infrastructure cost sharing (yearly recurring cost) == > >> ? ?[RIPE NCC specific registry / IPRA related costs] > >> ? ? ----------------------------------------- > >> ? ? ? ?number of LIRs at billing year end (*) > > > > I'm not sure I get that formula - are you dividing everything by > > number of LIRs, so everybody pays the same price? ?(Now that would be > > simple :) ). > > Share *overhead* costs equally, yes. *shrug* :) Ah, understood. So the yearly cost would be identically for everybody, and the initial request is billed for "the real cost caused by it". Right? 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From niels=apwg at bakker.net Mon Oct 31 16:30:40 2011 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Mon, 31 Oct 2011 16:30:40 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <50B5C73E-83F5-40F7-A5D4-1B8C61F734AF@baycix.de> References: <20111025094546.AFD572A018F@mx00.baycix.de> <50B5C73E-83F5-40F7-A5D4-1B8C61F734AF@baycix.de> Message-ID: <20111031153040.GQ2336@burnout.tpb.net> >Am 25.10.2011 um 11:51 schrieb Emilio Madaio: >> http://www.ripe.net/ripe/policies/proposals/2011-05 Chiming in to express my support, and answer Sascha's question: * slz at baycix.de (Sascha Lenz) [Wed 26 Oct 2011, 08:03 CEST]: >I am not quite sure if 180days for returning the old prefix is >really enough in a world where it's hard to reach some peering >partners and get reactions in under 360days :-) but i'm not an IXP >operator so what do i know... >I just assume it's reasonable? Yes, it is, in my experience. You want to keep the overlap period as small as possible. AMS-IX has renumbered its several peering LANs a couple of times in the past decade, and experience shows that a timeline set several months in advance with a week in which to complete the renumbering works pretty well. Smaller peering LANs that may be comprised of less active peers may take longer to reach all parties but 180 days should still suffice, and serve as a good hard deadline for the process. -- Niels. -- From millnert at gmail.com Mon Oct 31 18:44:48 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 31 Oct 2011 18:44:48 +0100 Subject: [address-policy-wg] concept document: IPv6 PA/PI unification In-Reply-To: <20111031153431.GL74658@Space.Net> References: <20111028171638.GS72014@Space.Net> <1319900200.3904.26.camel@natalie.csbnet.se> <20111029205143.GB74658@Space.Net> <20111031153431.GL74658@Space.Net> Message-ID: Gert, On Mon, Oct 31, 2011 at 4:34 PM, Gert Doering wrote: > Hi, > > On Mon, Oct 31, 2011 at 04:22:50PM +0100, Martin Millnert wrote: >> >> Out-of-the-box counter-proposal: >> >> >> ? IPRA interacting work (including address space requests) == >> >> ? ? [IPRA hour fee] * [IPRA-time spent on application], >> >> Pay per direct load on the hostmasters. ?This could encourage people >> having more clue interacting with the RIPE NCC and so on. > > ... but backfires if you have a particularily fast or slow IPRA... ?since > these are humans with differing background, your request might hit one > IPRA that has very much or very little experience on the way *you* want > to roll out your network... ?or extra curiosity adding more e-mail > rounds... ?so I'm not sure this can be done in a way that would be > considered "fair". > > Just throwing concerns around. They're fair concerns and does point to a perhaps greater issue: that variance of IPRA's can be that high that it makes a big difference. The system is right now not optimized towards per-hour billing for applications, etc, however, so it's hard to conclude what the variance would be in that situation. > >> >> ? Infrastructure cost sharing (yearly recurring cost) == >> >> ? ?[RIPE NCC specific registry / IPRA related costs] >> >> ? ? ----------------------------------------- >> >> ? ? ? ?number of LIRs at billing year end (*) >> > >> > I'm not sure I get that formula - are you dividing everything by >> > number of LIRs, so everybody pays the same price? ?(Now that would be >> > simple :) ). >> >> Share *overhead* costs equally, yes. ?*shrug* :) > > Ah, understood. ?So the yearly cost would be identically for everybody, > and the initial request is billed for "the real cost caused by it". ?Right? Well, identical for everybody using the IP registry services - yes. :) Cheers, Martin