From basile.bluntschli at swissix.ch Tue Nov 1 08:45:32 2011 From: basile.bluntschli at swissix.ch (Basile Bluntschli) Date: Tue, 1 Nov 2011 08:45:32 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: +1 i support the proposal -- s w i s s i x - Swiss Internet Exchange Basile Bluntschli Board Member From rolf.schaerer at netspring.ch Tue Nov 1 15:30:33 2011 From: rolf.schaerer at netspring.ch (=?iso-8859-1?Q?Rolf_Sch=E4rer?=) Date: Tue, 1 Nov 2011 15:30:33 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <7DC91849-8A04-4B0D-8259-4BDF727ACEFF@netspring.ch> +1 I support the proposal Cheers, Rolf ------------------------------------------------------------------------------- netspring gmbh rolf sch?rer, ccie #17218 alte gasse 4 rolf.schaerer at netspring.ch 8610 uster, switzerland Tel: +41 44 500 79 70 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4241 bytes Desc: not available URL: From dan.holme at gmail.com Tue Nov 1 16:15:53 2011 From: dan.holme at gmail.com (Daniel Holme) Date: Tue, 1 Nov 2011 16:15:53 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <4ea686bc.8e340e0a.7b8b.fffffc38SMTPIN_ADDED@mx.google.com> References: <4ea686bc.8e340e0a.7b8b.fffffc38SMTPIN_ADDED@mx.google.com> Message-ID: On 25 October 2011 11: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. > ? ?http://www.ripe.net/ripe/policies/proposals/2011-05 Hi I support this proposal. -- Daniel Holme Kcom From maildanrl at googlemail.com Tue Nov 1 17:32:01 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Tue, 1 Nov 2011 17:32:01 +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> Message-ID: On Sun, Oct 30, 2011 at 12:08 PM, Randy Bush wrote: > ?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 That's how I felt like it is now, so it cannot get worse. The most important point for me is, that larger blocks will be more expensive than the small (/48) ones. If the costs are shared equally, the "weenies" pay the org overhead for LIRs. Gerts 50/100/200 EUR plan is the way to go. just my 2 cents. regards, danrl -- regards. ?danrl -- Dan Luedtke http://www.danrl.de From kjetil.olsen at usit.uio.no Wed Nov 2 01:20:24 2011 From: kjetil.olsen at usit.uio.no (Kjetil Otter Olsen) Date: Wed, 02 Nov 2011 01:20:24 +0100 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) Message-ID: <4EB08CC8.8010000@usit.uio.no> We (Norwegian Internet eXchange) support this proposal. Best regards, Kjetil Otter Olsen, NIX.no From lists-ripe at c4inet.net Wed Nov 2 11:39:19 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 2 Nov 2011 10:39:19 +0000 Subject: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space) In-Reply-To: <20111025095212.AAAC510ABC8@mail.c4inet.net> References: <20111025095212.AAAC510ABC8@mail.c4inet.net> Message-ID: <20111102103919.GA72261@cilantro.c4inet.net> On Tue, Oct 25, 2011 at 11:51:26AM +0200, Emilio Madaio wrote: > > http://www.ripe.net/ripe/policies/proposals/2011-05 > I, too, support this proposal (Disclosure: We operate an IXP) Kind Regards, Sascha Luck From Ragnar.Anfinsen at altibox.no Wed Nov 2 11:49:27 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Wed, 2 Nov 2011 10:49:27 +0000 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA80ECE.1000600@netcologne.de> Message-ID: On 26.10.11 15:44, "Michael Adams" wrote: >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. +1. Our network model is based on a core network that is owned and operated by Altibox, and several partners networks that is operated by Altibox and owned by the partner. 6RD is a method we are considering for IPv6 deployment, mostly because our partners might not have the budgets to upgrade their infrastructure in thread with our IPv6 deployment. Having many prefixes, a multi-domain 6RD setup will be a hassle, both for prefix management at traffic management. However, this is not our prime reason to support this. We support this policy change mostly because it gives us the address space to needed to do good address aggregation in our partners networks. With a /32, we need to break down the allocations to smaller prefixes, hence making aggregation more difficult. The size of each partner vary greatly in number of end customers, and a larger prefix will help us keep the aggregations simple and unified. Best Regards Ragnar Anfinsen Senior Architect CPE Netinfrastructure Technology and Innovation Altibox AS Phone: +47 51 90 80 00 Phone direct: +47 51 90 82 35 Mobile +47 93 48 82 35 E-mail: ragnar.anfinsen at altibox.no Video phone: ragnar.anfinsen.altibox at video.altibox.net Skype: ragnar_anfinsen www.altibox.no From dan.holme at gmail.com Wed Nov 2 12:28:18 2011 From: dan.holme at gmail.com (Daniel Holme) Date: Wed, 2 Nov 2011 12:28:18 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4ea14d46.455e0e0a.2982.2b19SMTPIN_ADDED@mx.google.com> References: <4ea14d46.455e0e0a.2982.2b19SMTPIN_ADDED@mx.google.com> Message-ID: On 21 October 2011 12:44, Emilio Madaio wrote: > ? ?www.ripe.net/ripe/policies/proposals/2011-04 > > We encourage you to review this proposal and send your comments to > before 18 November 2011. Hi On the premises that there are no protocol specific comments in the policy then I support this proposal too. This should be a matter of address assignment policy only. Based on a mixture of /56 and /48 assignments to users it's easily possible for a medium to large ISP to need more than a /32. Also, increasing allocation sizes can only do good things for the IPv6 DFZ. -- Daniel Holme From dr at cluenet.de Sat Nov 5 03:37:09 2011 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 5 Nov 2011 03:37:09 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <4EA80ECE.1000600@netcologne.de> References: <20111021114200.GB72014@Space.Net> <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> <4EA7E559.2070407@go6.si> <1319630101.3501.12.camel@natalie.csbnet.se> <4EA80ECE.1000600@netcologne.de> Message-ID: <20111105023709.GA2907@srv03.cluenet.de> On Wed, Oct 26, 2011 at 03:44:46PM +0200, Michael Adams wrote: > 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. I feel your pain, I share it totally. Even if the first alloc will be sufficient - we all would get problems with HD-ratio later. I was recently told that IPRAs are supposed to judge initial alloc requests on a 2-3 year outlook, max, ONLY. Not 5-10yrs or so as it SHOULD be to make any real sense. So, you request a "larger than /32" block for 2-3 yrs numbers and then have a problem to get more later: To make the addressing plan "nice and scalable", and be done with "single prefix pool per aggregation router, period", one really needs quite some bits. Simple example, with two levels of hierarchy (site, aggregation router within a site): up to 128 aggregation sites => 7 bits up to 16 aggregation routers per site => 4 bits up to 65k subscribers per aggregation router => 16 bits /56 per subscriber (DHCP-PD) Those are absolutely realistic numbers (note the "up to"!) for a 5-10yr outlook for certain outfits. Sum: 56-16-4-7 => /29, nice and shiny "one size fits all" approach. But hell opens up widely when site 129 gets built. Then, you'll better have already more than 43.67 million customers, otherwise you won't get your additional bit for sites 129-256. Raising the HD-ratio so much (from 0.8 to 0.94) was a clear mistake in my opinion. Even if you have every(!) german citizen as customer, you would never qualify for more than a /28. That's ridiculous. The 128 bit IPv6 addr width had the promise to provide enough bits for internal hierarchy for "nice" (read: cheap to manage, easy to deal with in general and specifically operations) addressing plans. For large/mid-scale residential ISPs of certain topologies and access infrastructures, the current "ruleset" of "consider only 2-3yrs plans for initial alloc" in combination with HD-ratio 0.94 requirement for getting more bits, is a real problem. We're back to slice-and-dice-on-demand - no proper hierarchical structure anymore. Otherwise, HD-ratio 0.94 WILL bite sooner or later. Best regards, Daniel (pulling teeth on an addressing concept but having no joy) -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gert at space.net Sat Nov 5 12:16:29 2011 From: gert at space.net (Gert Doering) Date: Sat, 5 Nov 2011 12:16:29 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111105023709.GA2907@srv03.cluenet.de> References: <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> <4EA7E559.2070407@go6.si> <1319630101.3501.12.camel@natalie.csbnet.se> <4EA80ECE.1000600@netcologne.de> <20111105023709.GA2907@srv03.cluenet.de> Message-ID: <20111105111629.GY71280@Space.Net> Hi, On Sat, Nov 05, 2011 at 03:37:09AM +0100, Daniel Roesen wrote: > Raising the HD-ratio so much (from 0.8 to 0.94) was a clear mistake > in my opinion. Even if you have every(!) german citizen as customer, > you would never qualify for more than a /28. That's ridiculous. Indeed it is, as your statement is missing one important bit to be useful - the size of the prefix you intend to give your customers. If you give out /64s, you have 4 billion of those in a /32, so you don't need more to number roughly 80 million customers. If you give out /56s, indeed, ripe-523/appendix A shows that you qualify for a /28 - which contains 268 million /56s, so whether this is sufficient or not depends on the internal network structure, and it might be a bit tight if you have multiple levels of aggregation, yes. If you hand out /48s to your customers, (roughly) 80 million customers would be counted as 256*80 million = 20 billion /56s - and appendix A permits allocation of a /19 in that case. > The 128 bit IPv6 addr width had the promise to provide enough bits for > internal hierarchy for "nice" (read: cheap to manage, easy to deal with in > general and specifically operations) addressing plans. For large/mid-scale > residential ISPs of certain topologies and access infrastructures, the > current "ruleset" of "consider only 2-3yrs plans for initial alloc" > in combination with HD-ratio 0.94 requirement for getting more bits, is > a real problem. We're back to slice-and-dice-on-demand - no proper > hierarchical structure anymore. Otherwise, HD-ratio 0.94 WILL bite > sooner or later. I think I mentioned this a few times before: if you think the HD ratio is using the wrong number, or if you think the HD formula is completely wrong to start with, please submit a policy proposal to change this to whatever you think would work better. But this is somewhat out of scope for the discussion of 2011-04 and should not be discussed in *this* thread. 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 jan at go6.si Sat Nov 5 12:26:17 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 05 Nov 2011 12:26:17 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111105111629.GY71280@Space.Net> References: <4EA65C03.50903@go6.si> <4EA7C33B.1040005@go6.si> <4EA7E559.2070407@go6.si> <1319630101.3501.12.camel@natalie.csbnet.se> <4EA80ECE.1000600@netcologne.de> <20111105023709.GA2907@srv03.cluenet.de> <20111105111629.GY71280@Space.Net> Message-ID: <4EB51D59.2040308@go6.si> On 11/5/11 12:16 PM, Gert Doering wrote: > I think I mentioned this a few times before: if you think the HD ratio > is using the wrong number, or if you think the HD formula is completely > wrong to start with, please submit a policy proposal to change this to > whatever you think would work better. > > But this is somewhat out of scope for the discussion of 2011-04 and > should not be discussed in *this* thread. +1 Jan From Remco.vanMook at eu.equinix.com Sat Nov 5 12:34:53 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Sat, 5 Nov 2011 11:34:53 +0000 Subject: [address-policy-wg] HD-ratio (was: 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)) In-Reply-To: <20111105111629.GY71280@Space.Net> Message-ID: On 05-11-11 12:16, "Gert Doering" wrote: > >I think I mentioned this a few times before: if you think the HD ratio >is using the wrong number, or if you think the HD formula is completely >wrong to start with, please submit a policy proposal to change this to >whatever you think would work better. > >But this is somewhat out of scope for the discussion of 2011-04 and >should not be discussed in *this* thread. > +1 from my side as well. In addition, I consider it rather a feature of the current HD-ratio that using transition technologies such as 6RD can get you in trouble for subsequent allocations if you don't clean up at some point. Best, Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From jan at go6.si Sat Nov 5 12:37:53 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 05 Nov 2011 12:37:53 +0100 Subject: [address-policy-wg] 6rd as technology that might have an impact to HD ratio Message-ID: <4EB52011.8050600@go6.si> Hi, During last week the question was risen "what do we do, if we get /29, assign /30 for 6rd, use /30 for native part of deployment, then we fill it up and need additional allocation? Is 6RD /30 assignment valid as a whole in HD ratio game?" Well, my thoughts on this are: 1. If you filled up the whole /30, then you should probably not be running 6RD anymore, get rid of it and use that space for native 2. If you filled up /30 and can't get rid of 6RD, evaluate again you addressing plan sanity :) 3. If nothing of the above does apply, you are probably so big you should get more than /29 as initial allocation anyway 4. What else can possibly go wrong? So, 6RD should not be treated as anything special, as it is not a part of modified text in the policy, therefore if you are running 6RD, you still need to show the number of sites that you are covering with IPv6 PD and this has really nothing to do with 2011-04 proposal (but I can see new HD ratio discussion in the horizon :) ) I was specifically asked to put this question forward on this mailinglist in order to provide some further guidance for IPRAs, if 2011-04 reaches consensus (hope so :) ) Cheers, Jan From gert at space.net Sat Nov 5 12:47:03 2011 From: gert at space.net (Gert Doering) Date: Sat, 5 Nov 2011 12:47:03 +0100 Subject: [address-policy-wg] HD-ratio (was: 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)) In-Reply-To: References: <20111105111629.GY71280@Space.Net> Message-ID: <20111105114703.GA71280@Space.Net> Hi, thanks for changing the Subject: accordingly. On Sat, Nov 05, 2011 at 11:34:53AM +0000, Remco Van Mook wrote: > On 05-11-11 12:16, "Gert Doering" wrote: > > > > >I think I mentioned this a few times before: if you think the HD ratio > >is using the wrong number, or if you think the HD formula is completely > >wrong to start with, please submit a policy proposal to change this to > >whatever you think would work better. > > > >But this is somewhat out of scope for the discussion of 2011-04 and > >should not be discussed in *this* thread. > > +1 from my side as well. In addition, I consider it rather a feature of > the current HD-ratio that using transition technologies such as 6RD can > get you in trouble for subsequent allocations if you don't clean up at > some point. Indeed, but we shouldn't mix 6rd (which is a huge waster of "assignment densitiy" if used with full 32 bits) and large-scale access networks with multiple levels of aggregation - and for these, there is some meat to Daniel's argument about "the current HD ratio is too strict". So I'll welcome a discussion on HD ratio in general or different a HD ratio value, backed with numbers to make the problem clear to the AP community (without numbers that explain the problem without people having to wrap their heads on logarithms, it will be hard to convince the community). 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 Ragnar.Anfinsen at altibox.no Sat Nov 5 14:35:45 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Sat, 5 Nov 2011 13:35:45 +0000 Subject: [address-policy-wg] 6rd as technology that might have an impact to HD ratio In-Reply-To: <4EB52011.8050600@go6.si> Message-ID: On 05.11.11 12:37, "Jan Zorz @ go6.si" wrote: >1. If you filled up the whole /30, then you should probably not be >running 6RD anymore, get rid of it and use that space for native >2. If you filled up /30 and can't get rid of 6RD, evaluate again you >addressing plan sanity :) >3. If nothing of the above does apply, you are probably so big you >should get more than /29 as initial allocation anyway >4. What else can possibly go wrong? +1 >So, 6RD should not be treated as anything special, as it is not a part >of modified text in the policy, therefore if you are running 6RD, you >still need to show the number of sites that you are covering with IPv6 >PD and this has really nothing to do with 2011-04 proposal (but I can >see new HD ratio discussion in the horizon :) ) Agreed, one must just follow the already existing policies with regards to assignment-size in the object, so this will not change anything in that respect either. I cannot see any reason for this proposal not to move forward. AFAIK, there are no other policies that needs to be changes. Regards Ragnar From maildanrl at googlemail.com Mon Nov 7 08:30:55 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 7 Nov 2011 08:30:55 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Message-ID: Any news on if there were a decision about that in Vienna? -- Dan Luedtke http://www.danrl.de From turchanyi.geza at gmail.com Mon Nov 7 10:02:43 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Mon, 7 Nov 2011 10:02:43 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Message-ID: Hi Dan, nothing stops th IPv4 PI owners to use IPv6 PA.... Good luck, G?za On Mon, Sep 19, 2011 at 12:30 PM, Dan Luedtke wrote: > > Nudge received :-) We are still going through the whole mailing list > archive to see which concerns were raised and how they were addressed. > Quite a lot of messages were sent about this proposal over the last months! > We're working on it. > > Good to hear that. I (as many other IPv4 PI "owners") can't wait to > geht my IPv6 PI. > > regards, > > Dan > > -- > danrl / Dan Luedtke > http://www.danrl.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.schallar at avalon.at Mon Nov 7 11:10:31 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Mon, 07 Nov 2011 11:10:31 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Message-ID: <4EB7AE97.3070903@avalon.at> Hello! Turchanyi Geza schrieb am 07.11.2011 10:02: > nothing stops th IPv4 PI owners to use IPv6 PA.... Nothing stops anybody of using PA, neither in IPv4 nor in v6. That's not the question. But any reasons, why somebody wants/needs IPv4 PI space will usually fully apply to IPv6 also. It would seem stupid to me, to have IPv4 ("the past") as PI but IPv6 ("the future") as PA. That won't make sense. What changed between my v4 PI application and my v6 PI application? If I won't need PI on v6 any more, I probably won't need it on v4 any longer. Siple question: do I need my machines to have provider independend IP addresses or not? If yes, then I need _ANY_ address (IPv4, IPv6, IPvSomething) to be PI and not PA. So, if somebody already has IPv4 PI space, he/she should more or less automatically receive v6 PI under the same conditions as for v4. He/she just has to reason, why some default /48 won't be enough. Thats my opinion. regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From turchanyi.geza at gmail.com Mon Nov 7 15:51:22 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Mon, 7 Nov 2011 15:51:22 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4EB7AE97.3070903@avalon.at> References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> <4EB7AE97.3070903@avalon.at> Message-ID: Hello, I do see it differently. PI address space is easy to use, however, this allocation mechanism does not scale. Therefore was invented CIDR and PA allocation, if you do remember... I do not want to say that there is no room for exceptional cases and PI allocations. However, these must be limited in numbers (of allocations) and perhaps even in time. (you might receive it just for a couple of years.) PI allocation is not a privilage which will be inherited in time... When I checked the RIPE website and learned that all the working group chairs will decide weather the 2011-02 policy proposal got concensus I was happy. I still think that it would be dangerous to "release the djin" from the bottle, without any capability to control "the djin" in the future. I also recommend to study http://www.ietf.org/rfc/rfc4984.txt. I do not object to allow a few exceptional PI allocations, however, a well defined and understandable safeguarding limit should be implemented immediately. Later it could be too late. My proposal was and is to include immediately in 2011-2: If the number of allocated IPv6 PI slots reaches the number of LIRs in the region then the PI allocation should be stopped and the PI allocation policy must be reviewed. The number of LIRs is a sociological-political term and not a technical one, but at least clearly understandable by politicians and managers, and it is reasonably not too high not too low. AND this way the same rule could be applied in all RIRs. Applying the same rule everywhere I consider as a very important aspect. The other RIRs could easily accept the same. Anyhow, the number of entries in the global routing tables is just a global issue. Any related policy should be made at global level, and a faire manner. Best, G?za . On Mon, Nov 7, 2011 at 11:10 AM, DI. Thomas Schallar wrote: > ** > Hello! > > Turchanyi Geza schrieb am 07.11.2011 10:02: > > nothing stops th IPv4 PI owners to use IPv6 PA.... > > > Nothing stops anybody of using PA, neither in IPv4 nor in v6. That's not > the question. > > But any reasons, why somebody wants/needs IPv4 PI space will usually fully > apply to IPv6 also. It would seem stupid to me, to have IPv4 ("the past") > as PI but IPv6 ("the future") as PA. That won't make sense. What changed > between my v4 PI application and my v6 PI application? If I won't need PI > on v6 any more, I probably won't need it on v4 any longer. > > Siple question: do I need my machines to have provider independend IP > addresses or not? If yes, then I need *ANY* address (IPv4, IPv6, > IPvSomething) to be PI and not PA. > > So, if somebody already has IPv4 PI space, he/she should more or less > automatically receive v6 PI under the same conditions as for v4. He/she > just has to reason, why some default /48 won't be enough. Thats my opinion. > > regards, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ragnar.Anfinsen at altibox.no Tue Nov 8 11:02:23 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Tue, 8 Nov 2011 10:02:23 +0000 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: <20111021104522.84BBD9C004@asav8.lyse.net> References: <20111021104522.84BBD9C004@asav8.lyse.net> Message-ID: Late, but anyway. We support this proposal. MVH/Regards Ragnar > -----Opprinnelig melding----- > Fra: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] P? vegne av Emilio Madaio > Sendt: 21. oktober 2011 12:45 > Til: policy-announce at ripe.net > Kopi: address-policy-wg at ripe.net > Emne: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the > Minimum Size for IPv6 Initial Allocation) > > > 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 turchanyi.geza at gmail.com Tue Nov 8 13:13:39 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 8 Nov 2011 13:13:39 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <20111021104522.84BBD9C004@asav8.lyse.net> Message-ID: Hello, Apologize, once again, however, I disagree. My first question is: if we know the address allocation rules then is it possible to make a transition scenario wich keeps these rules? The answer is yes, however, 6RD developers not made any effort to deal with these rules. This should be they problems, not ours. Second question: tha 6RD concept and its conflict with address allocation rules was hiden? The answer is NO. J?nos Moh?csi and me wrote a lenghty paper on this topic, submitted it to the Networks2008 conference, AND gave a copy of it to R?mi Depr?s at the IETF meeting in Ireland in 2008 August. Third question: if we would like to adopt ourself to 6RD, then should we change our rules this way? The answer is: definitely not. 6RD is just a transition method which should not be use for long time. So if somebody think about exeptional looseng of rules, then I would suggest to think about allocating temporaly a block off address for 6RD, which MUST be returned within 3-5 years!! Best, G?za On Tue, Nov 8, 2011 at 11:02 AM, Anfinsen, Ragnar < Ragnar.Anfinsen at altibox.no> wrote: > Late, but anyway. > > We support this proposal. > > MVH/Regards > Ragnar > > > > -----Opprinnelig melding----- > > Fra: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > > bounces at ripe.net] P? vegne av Emilio Madaio > > Sendt: 21. oktober 2011 12:45 > > Til: policy-announce at ripe.net > > Kopi: address-policy-wg at ripe.net > > Emne: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the > > Minimum Size for IPv6 Initial Allocation) > > > > > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert at mediacaster.nl Tue Nov 8 14:00:34 2011 From: albert at mediacaster.nl (Albert Siersema) Date: Tue, 8 Nov 2011 14:00:34 +0100 (CET) Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? Message-ID: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> Geza, > I do see it differently. PI address space is easy to use, however, this > allocation mechanism does not scale. Therefore was invented CIDR and PA > allocation, if you do remember... Could you eleborate on "does not scale" ? When deploying IPv6 one should set aside an IPv4 mindset. The same goes for the whole rehashing of the "does not scale" issue. You can't expect early 90's routing hardware to do the job of current BGP Internet routing. And when everyone will be running IPv6 (not tomorrow), the current limits for hardware won't apply. Let's not go into a discussion on asics / 64-core cpu's, but I'm pretty certain that hardware including tcams etc will keep up if the market demands it. Maybe you're referring to something altogether different, that's why I ask. I fully concur with Thomas on this point: for all the IPv4 PI allocations out there it should be possible to get an IPv6 allocation as well. Indeed nothing has changed with regard to the reasons for applying and being granted PI space. The current policy kind of suggests that everyone with IPv4 PI space should just quit their business and hand it over to the LIR as they are the only ones getting PI space for customer traffic. Regards, Albert > Turchanyi Geza schrieb am 07.11.2011 10:02: > nothing stops th IPv4 PI owners to use IPv6 PA.... > > > Nothing stops anybody of using PA, neither in IPv4 nor in v6. That's not > the question. > > But any reasons, why somebody wants/needs IPv4 PI space will usually fully > apply to IPv6 also. It would seem stupid to me, to have IPv4 ("the past") > as PI but IPv6 ("the future") as PA. That won't make sense. What changed > between my v4 PI application and my v6 PI application? If I won't need PI > on v6 any more, I probably won't need it on v4 any longer. > > Siple question: do I need my machines to have provider independend IP > addresses or not? If yes, then I need *ANY* address (IPv4, IPv6, > IPvSomething) to be PI and not PA. > > So, if somebody already has IPv4 PI space, he/she should more or less > automatically receive v6 PI under the same conditions as for v4. He/she > just has to reason, why some default /48 won't be enough. Thats my opinion. > > regards, > Thomas From jan at go6.si Tue Nov 8 15:03:13 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 08 Nov 2011 15:03:13 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <20111021104522.84BBD9C004@asav8.lyse.net> Message-ID: <4EB936A1.6010006@go6.si> On 11/8/11 1:13 PM, Turchanyi Geza wrote: > Hello, > > Apologize, once again, however, I disagree. > > My first question is: if we know the address allocation rules then is > it possible to make a transition scenario wich keeps these rules? > > The answer is yes, however, 6RD developers not made any effort to > deal with these rules. > > This should be they problems, not ours. Dear Turchanyi, We are not protocol police, for this discussion there is IETF. 6RD is being deployed on the field and this proposal only removes the speed-bumps without inserting new troubles. And we want IPv6 deployed, do we? > > Second question: tha 6RD concept and its conflict with address > allocation rules was hiden? > > The answer is NO. J?nos Moh?csi and me wrote a lenghty paper on this > topic, submitted it to the Networks2008 conference, AND gave a copy > of it to R?mi Depr?s at the IETF meeting in Ireland in 2008 August. Good. So you talked to IETF folks :) > > Third question: if we would like to adopt ourself to 6RD, then should > we change our rules this way? > > The answer is: definitely not. > > 6RD is just a transition method which should not be use for long > time. So if somebody think about exeptional looseng of rules, then I > would suggest to think about allocating temporaly a block off address > for 6RD, which MUST be returned within 3-5 years!! We've already been through this discussion, I believe it's in the archives. Majority of community feedback went into a way, that 6RD is nothing special and we are not happy to spend additional resources for recollecting the "special" allocations later on. We need to start thinking how to remove obstacles for IPv6 deployment and not how to put them in there (like we had to do it for IPv4 in order to slow-down depletion). Regards, Jan ?or? From he at uninett.no Tue Nov 8 16:32:18 2011 From: he at uninett.no (Havard Eidnes) Date: Tue, 08 Nov 2011 16:32:18 +0100 (CET) Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> Message-ID: <20111108.163218.219750236.he@uninett.no> > Let's not go into a discussion on asics / 64-core cpu's, but I'm > pretty certain that hardware including tcams etc will keep up if > the market demands it. Oh, do let me briefly touch on this tangent; I think your statement glosses over the worry which has been expressed. The problem is this: so far "hardware scaling" of core routers has been riding on the coattails of general advances in electronics, driven by other and larger forces (PCs etc.). However, there is apparently no general market demand for "much, Much bigger TCAMs". This means that such components will be costly at best, maybe more costly than any of us would like to think of, and/or that they may not arrive as quicly as when we have the assistance of other market forces which pull in the same direction. I tell you, widespread PI adoption is poison for the network. Just saying. So that I can tell you "told you so!" Regards, - H?vard, in a pessmistic mood From albert at mediacaster.nl Tue Nov 8 17:13:32 2011 From: albert at mediacaster.nl (Albert Siersema) Date: Tue, 8 Nov 2011 17:13:32 +0100 (CET) Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <20111108.163218.219750236.he@uninett.no> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> Message-ID: <57671.193.173.12.30.1320768812.squirrel@www.friendly.net> Havard, > The problem is this: so far "hardware scaling" of core routers has been > riding on the coattails of general advances in electronics, > driven by other and larger forces (PCs etc.). However, there is > apparently no general market demand for "much, Much bigger TCAMs". This > means that such components will be costly at best, maybe more costly I fully agree with that angle and the sentiments expressed in rfc4984. However, although of course I'm not a router vendor, if big data (tm) and scalability is a problem that can be solved on other planes we should be able to attack the routing problems as well. Maybe the current solutions don't fit the problems anymore. It would probably mean departing from the current router architectures and looking at much more parallel modular architectures all highly parallel and using where possible a lot of off-the-shelf components, e.g. where one engine does the control plane work and only does updating, policing, flow tagging/labeling and a data plane engine only forwards traffic. Of course this is hugely over simplified, we're getting very close to OT here as it is already :-) (don't forget in the high volume hardware market we've reached some kind of limit on speed as well, it'll be more about parallel processing now & next) > I tell you, widespread PI adoption is poison for the network. Maybe, maybe not. If I read things correctly, the suggestion is to take the business side of things into account as well. It's kind of curious that this should stop at the (core) infrastructure side. The businesses and people that are actually using the Internet are equally if not more important. Since 2007 a lot of things have changed once again or maybe evolved further; people and businesses have grown even more dependant on Internet connectivity as could only have been expected. PI is a necessity for a lot of businesses, large _and_ small(er). I get a feeling the whole discussion is still only a technical one as itpasses by the actual Internet users (companies). If there is an element of the business, most of the people involved only argue on behalf of the (big) ISP side. Regards, Albert From drc at virtualized.org Tue Nov 8 17:49:06 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 8 Nov 2011 08:49:06 -0800 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <57671.193.173.12.30.1320768812.squirrel@www.friendly.net> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> <57671.193.173.12.30.1320768812.squirrel@www.friendly.net> Message-ID: <777435EA-7100-402E-A62D-4CEF54AFB11A@virtualized.org> On Nov 8, 2011, at 8:13 AM, Albert Siersema wrote: > Maybe the current solutions don't fit the problems anymore. Maybe the IAB should have a workshop exploring this problem. >> I tell you, widespread PI adoption is poison for the network. > Maybe, maybe not. No, really, it is. Given IPv6 uses the exact same routing technology as IPv4, the same problems apply. We couldn't flat route 32 bits so the IPv6 solution is to flat route 48 bits? > If there is an element of the business, most of the people involved only argue on behalf of the (big) ISP side. I think you have it backwards. Who do you think will be able to afford the multi-tens of millions of euros necessary to purchase the routers that will have sufficient TCAM space to deal with PI-for-everyone? However, you are correct that perfectly understandable business concerns are driving this issue. The likely (inevitable?) end result will (again) be prefix length filters and accusations of money grubbing evil greedy bastard ISPs. Been there, done that, still have a few t-shirts left. I wonder who is going to play Sean Doran this time around... Regards, -drc From ot at cisco.com Tue Nov 8 19:19:31 2011 From: ot at cisco.com (Ole Troan) Date: Tue, 8 Nov 2011 19:19:31 +0100 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: References: <20111021104522.84BBD9C004@asav8.lyse.net> Message-ID: <9FD35457-E2FD-4358-A96D-21DB3AD3F05B@cisco.com> Geza, [...] > The answer is yes, however, 6RD developers not made any effort to deal with these rules. > > This should be they problems, not ours. > > Second question: tha 6RD concept and its conflict with address allocation rules was hiden? > > The answer is NO. J?nos Moh?csi and me wrote a lenghty paper on this topic, submitted it to the Networks2008 conference, AND gave a copy of it to R?mi Depr?s at the IETF meeting in Ireland in 2008 August. OK, I'll take the bait. are you referring to "Scoped IPv4 addresses"? looking at the proposal, I don't understand how that solves the problem at hand? - "how to encode multiple IPv4 subnets of varying sizes into an IPv6 prefix" assuming no renumbering of existing CPEs. 6rd already supports more efficient coding in the case where CPEs are numbered out of 1918, by e.g. masking out the first 8 bits in an 10/8. the understanding I got from the room, was that moving to an initial /29 allocation on request, was a good and useful change for _native_ IPv6 deployments. sure, 6rd deployments would benefit from it too, but I wouldn't say that shortcomings in 6rd is driving this policy change any longer. cheers, Ole From ebais at a2b-internet.com Tue Nov 8 19:39:49 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 8 Nov 2011 19:39:49 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <777435EA-7100-402E-A62D-4CEF54AFB11A@virtualized.org> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> <57671.193.173.12.30.1320768812.squirrel@www.friendly.net> <777435EA-7100-402E-A62D-4CEF54AFB11A@virtualized.org> Message-ID: <008a01cc9e45$cbcaa850$635ff8f0$@com> > >> I tell you, widespread PI adoption is poison for the network. > > Maybe, maybe not. > > No, really, it is. This policy has been discussed in detail in the past 6 months and we keep circling back on the same topics. And sorry to burst your bubble, but you are wrong and the information (read as: the facts and not as gut feelings) from the other RIR's show (from those that have a similar policy in place) that the number of v6 PI prefixes is not taking the steep jump. The policy has come to the end of the last call and in the RIPE minutes on Wednesday it was specified that : "The APWG co-Chairs announced their intention to declare consensus on proposal 2011-02, "Removal of multihomed requirement for IPv6 PI". " Having said this, this policy will help us all in the so much required v6 adoption across the board and it is still possible to propose a change in the v6 PI policy if the take-up is moving out of hand. On the other hand, this discussion will probably be revisited or become unneeded if and when PI and PA are all going to be treated as equal in the future. Regards, Erik Bais From nick at inex.ie Tue Nov 8 19:58:43 2011 From: nick at inex.ie (Nick Hilliard) Date: Tue, 08 Nov 2011 18:58:43 +0000 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <008a01cc9e45$cbcaa850$635ff8f0$@com> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> <57671.193.173.12.30.1320768812.squirrel@www.friendly.net> <777435EA-7100-402E-A62D-4CEF54AFB11A@virtualized.org> <008a01cc9e45$cbcaa850$635ff8f0$@com> Message-ID: <4EB97BE3.9030507@inex.ie> On 08/11/2011 18:39, Erik Bais wrote: > And sorry to burst your bubble, but you are wrong [...] "Whoever passes through life with the most and then dies agreeably is the one who, in my opinion, O King, deserves to bear this name. It is necessary to see how the end of every affair turns out, for the god promises fortune to many people and then utterly ruins them." - Herodotus, The Histories. Nick From drc at virtualized.org Tue Nov 8 20:28:38 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 8 Nov 2011 11:28:38 -0800 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <008a01cc9e45$cbcaa850$635ff8f0$@com> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> <57671.193.173.12.30.1320768812.squirrel@www.friendly.net> <777435EA-7100-402E-A62D-4CEF54AFB11A@virtualized.org> <008a01cc9e45$cbcaa850$635ff8f0$@com> Message-ID: <553CBAF3-FA08-4948-A471-A6E668CE2D21@virtualized.org> On Nov 8, 2011, at 10:39 AM, Erik Bais wrote: >>>> I tell you, widespread PI adoption is poison for the network. >>> Maybe, maybe not. >> No, really, it is. > And sorry to burst your bubble, but you are wrong and the information (read > as: the facts and not as gut feelings) from the other RIR's show (from those > that have a similar policy in place) that the number of v6 PI prefixes is > not taking the steep jump. :-) 'An optimist is someone who jumps off a tall building and after 50 floors says, "So far, so good."' Regards, -drc From lists-ripe at c4inet.net Tue Nov 8 23:24:26 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 8 Nov 2011 22:24:26 +0000 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <20111108.163218.219750236.he@uninett.no> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> Message-ID: <20111108222426.GA97093@cilantro.c4inet.net> On Tue, Nov 08, 2011 at 04:32:18PM +0100, Havard Eidnes wrote: >I tell you, widespread PI adoption is poison for the network. >Just saying. So that I can tell you "told you so!" > >Regards, > >- Havard, in a pessmistic mood For a pessimistic outlook on what will be poison for the network, try: http://ripe63.ripe.net/presentations/205-2011-10-31-exhaustion.pdf on the alternatives to widespread, rapid IPv6 deployment. Successful transition to IPv6 is by no means a sure thing. The only advantage IPv6 has going for it right now is that it offers virtually unlimited, easily available address space. If we keep creating artificial scarcity by way of arbitrary rules and restrictions, IPv6 deployment *will not happen*. For the consequences, refer to the above. Regards, Sascha Luck From Ragnar.Anfinsen at altibox.no Wed Nov 9 00:07:43 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Tue, 8 Nov 2011 23:07:43 +0000 Subject: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) In-Reply-To: Message-ID: On 08.11.11 13:13, "Turchanyi Geza" > wrote: Hello, Apologize, once again, however, I disagree. My first question is: if we know the address allocation rules then is it possible to make a transition scenario wich keeps these rules? The answer is yes, however, 6RD developers not made any effort to deal with these rules. This should be they problems, not ours. Second question: tha 6RD concept and its conflict with address allocation rules was hiden? The answer is NO. J?nos Moh?csi and me wrote a lenghty paper on this topic, submitted it to the Networks2008 conference, AND gave a copy of it to R?mi Depr?s at the IETF meeting in Ireland in 2008 August. Third question: if we would like to adopt ourself to 6RD, then should we change our rules this way? The answer is: definitely not. 6RD is just a transition method which should not be use for long time. So if somebody think about exeptional looseng of rules, then I would suggest to think about allocating temporaly a block off address for 6RD, which MUST be returned within 3-5 years!! Best, G?za The question here is; how can we deploy IPv6 quicker? Well, 6rd is one of the technologies that can be used. I will not go into discussions about whether 6RD is good or bad, address policy wise. However, for our sake, the interesting part of this policy is getting a /29 without the need to justify it. It would for us be more easily to make a good address plan if more bits where available from the start. 2011-04 will enable that. MVH/Regards Ragnar From maildanrl at googlemail.com Wed Nov 9 08:55:27 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Wed, 9 Nov 2011 08:55:27 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: <20111108222426.GA97093@cilantro.c4inet.net> References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> <20111108222426.GA97093@cilantro.c4inet.net> Message-ID: On Tue, Nov 8, 2011 at 7:39 PM, Erik Bais wrote: > Having said this, this policy will help us all in the so much required v6 > adoption across the board and it is still possible to propose a change in > the v6 PI policy if the take-up is moving out of hand. Exactly. Btw, the net is already poisoned. It all began with the wide deployment of NAT-Routers as CPE. This internet currently is not the "network of all networks", in fact, it hasn't been the past years. We now have the ability to provide every customer[1] with a network, and we fail to give them addresses. Seriously? Whats wrong? Again: A PIv4 holder cannot get his hands on a PIv6 if he is not multihomed. This leads to a) PIv4 holders not deploying IPv6; b) PIv4 holders mixing PI and PA space, which requires renumbering if the provider changes. Guess what makes more sense in a business-plan to the financial departement? I cannot believe this discussion is still on... Drop it if you are unsure, so I can say "told you so" later on. ;) regards, Dan [1] customer, a: the one who pays my bills. From maildanrl at googlemail.com Wed Nov 9 09:05:43 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Wed, 9 Nov 2011 09:05:43 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Message-ID: On Mon, Nov 7, 2011 at 10:02 AM, Turchanyi Geza wrote: > nothing stops th IPv4 PI owners to use IPv6 PA.... - except that one has to renumber the whole network when finally (if ever) receiving PIv6 - which leads to about double costs In fact, I have a mixed network (PIv4, PAv6) at the moment, but I am still wondering why I cannot get assigned PIv6. What changed? regards, Dan -- Dan Luedtke http://www.danrl.de From turchanyi.geza at gmail.com Wed Nov 9 11:03:02 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 9 Nov 2011 11:03:02 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: References: <4E2FF96A.2000802@avalon.at> <4E574955.2040505@avalon.at> <4E6733D9.1050708@avalon.at> <002401cc6d46$01862a90$04927fb0$@com> <0E1DD8A8-C246-48AF-9ABC-826EF16789A3@steffann.nl> Message-ID: Dan, On Wed, Nov 9, 2011 at 9:05 AM, Dan Luedtke wrote: > On Mon, Nov 7, 2011 at 10:02 AM, Turchanyi Geza > wrote: > > nothing stops th IPv4 PI owners to use IPv6 PA.... > - except that one has to renumber the whole network when finally (if > ever) receiving PIv6 > - which leads to about double costs > I am happy to hear that you made the transition and you are using IPv6 PA. > In fact, I have a mixed network (PIv4, PAv6) at the moment, but I am > still wondering why I cannot get assigned PIv6. What changed? > PI does not scale! We regret this, however, we can not forget this! There is only one way to keep the routing table in a handable status: massive PA use. I hope, you will be glad with your current provider and do not need to renumber in the near future. Anyhow, renumbering is not so hard if your network was designed with the requirement of renumbering in mind... Best, G?za > > regards, > Dan > > -- > Dan Luedtke > http://www.danrl.de > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maildanrl at googlemail.com Thu Nov 10 08:05:49 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Thu, 10 Nov 2011 08:05:49 +0100 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)? In-Reply-To: References: <29387.193.173.12.30.1320757234.squirrel@www.friendly.net> <20111108.163218.219750236.he@uninett.no> <20111108222426.GA97093@cilantro.c4inet.net> Message-ID: On Wed, Nov 9, 2011 at 10:28 AM, Turchanyi Geza wrote: > 1, Most of the content must be accessible on IPv6 stack as well; > 2, Broadband users must be supported. Never questioned that. But, that is no reason to stay in the way of those who *want* to deploy IPv6 but cannot get their hands on addresses. It is just not ok, that a RIPE policy is preventing deployment in some networks while we are pushing large ISP to deploy it. We should push *all* parties to deploy it. It's not only the ISPs internet, although they are a/the force of it. As I understood, the other RIRs have not encountered a pollution problem when allowing PI assignments without multihome-requirement. But I may be wrong on this, as I have no numbers were I am right now. regards, Dan -- Dan Luedtke http://www.danrl.de From james.blessing at despres.co.uk Mon Nov 14 11:13:28 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Mon, 14 Nov 2011 10:13:28 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" Message-ID: Hi all, It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following: == 5.1.x Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor. == The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here) J -- James Blessing 07989 039 476 From turchanyi.geza at gmail.com Mon Nov 14 12:15:40 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Mon, 14 Nov 2011 12:15:40 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: Hello James, Speeking about concensus is definitely wrong. I'll send a longer critical aanlyses later, Best, G?za On Mon, Nov 14, 2011 at 11:13 AM, James Blessing < james.blessing at despres.co.uk> wrote: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > > -- > > James Blessing > 07989 039 476 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Remco.vanMook at eu.equinix.com Mon Nov 14 12:24:50 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 14 Nov 2011 11:24:50 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: Message-ID: +1 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 14-11-11 11:13, "James Blessing" wrote: >Hi all, > >It seems that the consensus is that up to a /29 is the right amount of >space for the majority of networks, if that is the case I've think we >should add the following: > >== > >5.1.x > >Organisations that have already received their initial allocations are >able to request additional address space up to a /29 without supplying >of further documentation as if they were a first time requestor. > >== > >The logic being that this solves the problem for networks who deployed >before this change and avoids the issues with HD ratio (which I think >needs some looking at, but not here) > >J > >-- > >James Blessing >07989 039 476 > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From Jasper.Jans at espritxb.nl Mon Nov 14 12:28:11 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 14 Nov 2011 12:28:11 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD2010468A96243@EXCH01.campus.local> +1 Jasper -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of James Blessing Sent: Monday, November 14, 2011 11:13 AM To: Address Policy Working Group Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" Hi all, It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following: == 5.1.x Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor. == The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here) J -- James Blessing 07989 039 476 Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From david.freedman at uk.clara.net Mon Nov 14 14:27:25 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 14 Nov 2011 13:27:25 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <1D29C7A8-A975-450C-B868-4A74CAEDA0BF@uk.clara.net> +1 On 14 Nov 2011, at 10:14, "James Blessing" wrote: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > > -- > > James Blessing > 07989 039 476 > From madams at netcologne.de Mon Nov 14 16:07:12 2011 From: madams at netcologne.de (Michael Adams) Date: Mon, 14 Nov 2011 16:07:12 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <4EC12EA0.2030608@netcologne.de> Sounds good for me. Michael Am 14.11.2011 11:13, schrieb James Blessing: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > -- 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 Nov 14 16:13:18 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 14 Nov 2011 16:13:18 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <4EC1300E.2070103@go6.si> On 11/14/11 11:13 AM, James Blessing wrote: > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == +1 Jan From job at instituut.net Mon Nov 14 16:15:13 2011 From: job at instituut.net (Job Snijders) Date: Mon, 14 Nov 2011 16:15:13 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <2EC65F94-DFC3-4B1C-8CF5-2C29E3A50C71@instituut.net> I agree. On 14 nov. 2011, at 11:13, James Blessing wrote: > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) Sound reasoning! Kind regards, Job From Ragnar.Anfinsen at altibox.no Mon Nov 14 16:23:34 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Mon, 14 Nov 2011 15:23:34 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: +1 MVH/Regards Ragnar > -----Opprinnelig melding----- > Fra: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] P? vegne av James Blessing > Sendt: 14. november 2011 11:13 > Til: Address Policy Working Group > Emne: [address-policy-wg] 2011-04, "Extension of the Minimum Size for > IPv6 Initial Allocation" > > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > > -- > > James Blessing > 07989 039 476 From rps at cheater.ru Mon Nov 14 15:22:38 2011 From: rps at cheater.ru (Roman Sokolov) Date: Mon, 14 Nov 2011 18:22:38 +0400 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <4EC1242E.60200@cheater.ru> +1 James Blessing wrote: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > -- wbr, Roman Sokolov mailto:rps at cheater.ru From Tero.Toikkanen at nebula.fi Mon Nov 14 16:23:46 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Mon, 14 Nov 2011 15:23:46 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC1300E.2070103@go6.si> References: <4EC1300E.2070103@go6.si> Message-ID: > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. +1 ____________________________________ Tero Toikkanen Nebula Oy From tom at someaddress.net Mon Nov 14 17:18:41 2011 From: tom at someaddress.net (Tom Hodgson) Date: Mon, 14 Nov 2011 16:18:41 +0000 (GMT) Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: On Mon, 14 Nov 2011, James Blessing wrote: > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > I agree with this, and also with the general theme of the proposal of extending the initial allocation size. I do not feel that it is sensible to tie this into a specific transition mechanism so am happy with the more generic proposal that has been put together that will also allow better scalability in long term addressing plans. One thing that I do wonder is whether the (limited) overhead of the NCC processing these requests mean it is more desirable to limit this "re-request" to a single shot per-LIR (which will likely push people to request the whole /29), or whether permitting multiple requests grabbing a /32 at a time (up to the /29) is desirable. Personally I assume that most networks using this policy extension would go for the /29 straight off, but then there maybe further interaction with the charging scheme which dissuades this. -- Tom Hodgson tom at someaddress.net From james.blessing at despres.co.uk Mon Nov 14 17:27:04 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Mon, 14 Nov 2011 16:27:04 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: On 14 November 2011 16:18, Tom Hodgson wrote: > One thing that I do wonder is whether the (limited) overhead of the NCC > processing these requests mean it is more desirable to limit this > "re-request" to a single shot per-LIR (which will likely push people to > request the whole /29), or whether permitting multiple requests grabbing a > /32 at a time (up to the /29) is desirable. Personally I assume that most > networks using this policy extension would go for the /29 straight off, but > then there maybe further interaction with the charging scheme which > dissuades this. The logic was to try and remove the guesswork from the process. For someone adjudicating the request its a fairly simple binary logic (in fact its almost programable) and therefore (I assume) a limited amount of impact. It also gets round the "oh bugger" moment where someone who could have gone for a /29 but only went for a /30 because their maths was wrong can't get the space, even though its effectively reserved for their future use, due to the HD rule. As I said if we can deal with the HD rule then I think we can maybe revisit this J -- James Blessing 07989 039 476 From wilhelm at boeddinghaus.de Mon Nov 14 17:20:27 2011 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Mon, 14 Nov 2011 17:20:27 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <4EC13FCB.4000605@boeddinghaus.de> +1 Wilhelm Am 14.11.2011 11:13, schrieb James Blessing: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > From lists-ripe at c4inet.net Mon Nov 14 19:39:56 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 14 Nov 2011 18:39:56 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <20111114183956.GA20412@cilantro.c4inet.net> On Mon, Nov 14, 2011 at 10:13:28AM +0000, James Blessing wrote: >It seems that the consensus is that up to a /29 is the right amount of >space for the majority of networks, if that is the case I've think we +1 rgds, Sascha From flo at degnet.de Mon Nov 14 19:43:19 2011 From: flo at degnet.de (Florian Fuessl) Date: Mon, 14 Nov 2011 19:43:19 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <01b601cca2fd$48396b90$d8ac42b0$@de> +1 -Florian James Blessing wrote Monday, November 14, 2011 11:13 AM > > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > > -- > > James Blessing > 07989 039 476 From rinse.kloek at isp.solcon.nl Mon Nov 14 19:22:25 2011 From: rinse.kloek at isp.solcon.nl (Rinse Kloek) Date: Mon, 14 Nov 2011 19:22:25 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <4EC15C61.1040201@isp.solcon.nl> +1 Op 14-11-2011 11:13, James Blessing schreef: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've think we > should add the following: > > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) > > J > -- met vriendelijke groet, Rinse Kloek System and Network Engineer - Solcon Internetdiensten BV Het Spaarne 11 - 8253 PE Dronten - The Netherlands T: +31 88 0032222 - F: +31 88 0032223 - W: www.solcon.nl From rogerj at gmail.com Mon Nov 14 21:29:32 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 14 Nov 2011 21:29:32 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: On Mon, Nov 14, 2011 at 11:13 AM, James Blessing wrote: > Hi all, > > It seems that the consensus is that up to a /29 is the right amount of > space for the majority of networks, if that is the case I've ?think we > should add the following: It is not that I disagree on that /29 is a good size... but, just to repeat myself and some others. Why are we doing this step by step all over again? Last we went from /35 to /32, now we go from /32 to /29. I guess the next time we'll be talking about this topic is around 2015-2017... Why not do it properly this time around? Like a /26 or so? We got plenty of address space to burn really.... > == > > 5.1.x > > Organisations that have already received their initial allocations are > able to request additional address space up to a /29 without supplying > of further documentation as if they were a first time requestor. > > == > > The logic being that this solves the problem for networks who deployed > before this change and avoids the issues with HD ratio (which I think > needs some looking at, but not here) ... but if no one want to use time this time around for making it a /26 or so, the text above get my support to. -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From leo.vegoda at icann.org Mon Nov 14 22:55:26 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 14 Nov 2011 13:55:26 -0800 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> Hi Roger, Roger J?rgensen wrote: [...] > It is not that I disagree on that /29 is a good size... but, just to > repeat myself and some others. > > Why are we doing this step by step all over again? Last we went from > /35 to /32, now we go from /32 to /29. > I guess the next time we'll be talking about this topic is around 2015-2017... > Why not do it properly this time around? Like a /26 or so? We got > plenty of address space to burn really.... Where does the /26 come from? Or to put it another way, assuming the basis for allocation policy is justified need, what need is considered so universal that no justification is required? Regards, Leo Vegoda From nick at inex.ie Mon Nov 14 23:52:43 2011 From: nick at inex.ie (Nick Hilliard) Date: Mon, 14 Nov 2011 22:52:43 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> Message-ID: <4EC19BBB.5010504@inex.ie> On 14/11/2011 21:55, Leo Vegoda wrote: > Where does the /26 come from? Or to put it another way, assuming the > basis for allocation policy is justified need, what need is considered > so universal that no justification is required? apparently 6rd. Or the latest transition mechanism, except that it's such a good address justification mechanism that you don't even need to mention which transition mechanism you're planning to use, or even if you are planning to use a transition mechanism at all. I'm struggling to understand how this proposal meets the Conservation section of the RIPE IPv6 allocation policy: "Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided." It hardly takes much effort to mention to the RIPE NCC that your LIR is applying for a /29 instead of a /32 because it intends to implement 6rd, does it? While I don't have a major problem with giving 3 extra bits of space to implement 6rd, I do have a major problem with: 1. making this the default configuration, even for those LIRs who have no intention of ever deploying 6rd or any other equivalent transition mechanism, 2. removal of the requirement to specify 6rd/other mechanism to justify the extra space, and 3. allocating /26 by default. 102 bits of address space is obscenely wasteful because it is very significantly more than most LIRs will ever require in the lifetime of the universe (yes, I have worked out the scales here). Look, I don't mean to sound like a party pooper, but let's not lose the run of ourselves here. 6rd has very limited deployment at present, and while it shows a lot of promise as a potentially useful transition mechanism, it's not yet at the stage where we should feel tempted to shower LIRs with ridiculous quantities of address bits just because we're feeling a bit inadequate about current ipv6 uptake. I'd like to suggest that 2011-04 be changed so that LIRs can expand their default /32 to a /29 iff they document a requirement for providing 6rd / {another specified ipv6 transition mechanism which requires similar bits of address space} to end-users. Otherwise, a /32 will be assigned by default, and the RIPE NCC can continue on with their current binary chop allocation strategy. Nick From jan at go6.si Tue Nov 15 08:37:16 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 15 Nov 2011 08:37:16 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <4EC216AC.6040103@go6.si> On 11/14/11 9:29 PM, Roger J?rgensen wrote: > It is not that I disagree on that /29 is a good size... but, just to > repeat myself and some others. > > Why are we doing this step by step all over again? Last we went from > /35 to /32, now we go from /32 to /29. > I guess the next time we'll be talking about this topic is around 2015-2017... > Why not do it properly this time around? Like a /26 or so? We got > plenty of address space to burn really.... Dear Roger, /29 was chosen for "fairness" factor - every legacy /32 can be expanded to /29 without renumbering, as that is exactly the amount of space "reserved" for every /32. If we decide to go to /26, then only new allocations gets /26, legacy ones need to renumber if expanded. It's a tradeoff in favor of fairness. Cheers, Jan From jan at go6.si Tue Nov 15 08:59:35 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 15 Nov 2011 08:59:35 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC19BBB.5010504@inex.ie> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> Message-ID: <4EC21BE7.30404@go6.si> On 11/14/11 11:52 PM, Nick Hilliard wrote: > On 14/11/2011 21:55, Leo Vegoda wrote: >> Where does the /26 come from? Or to put it another way, assuming the >> basis for allocation policy is justified need, what need is considered >> so universal that no justification is required? > > apparently 6rd. Or the latest transition mechanism, except that it's such > a good address justification mechanism that you don't even need to mention > which transition mechanism you're planning to use, or even if you are > planning to use a transition mechanism at all. Dear Nick, Yes, exactly. Many "early" adopters knew no better and got their /32 in order to start testing IPv6 and today they would need much more to take advantage of some addressing ways that IPv6 can offer - and we had some of them expressing this thought at RIPE62, RIPE63 and here on list. I know I'm repeating myself, but probably we should try to "unlearn" all the speed-bumps we put into IPv4 addressing policy in order to slow down depletion and start distributing IPv6 space as needed, adapting the defaults to the feedback from operational environment and community. > > I'm struggling to understand how this proposal meets the Conservation > section of the RIPE IPv6 allocation policy: > > "Although IPv6 provides an extremely large pool of address space, address > policies should avoid unnecessarily wasteful practices. Requests for > address space should be supported by appropriate documentation and > stockpiling of unused addresses should be avoided." I would understand this as "do not give /20 to a LIR with 10 users." Note the word "should", therefore this must be taken just as a guidance, not a must. > > It hardly takes much effort to mention to the RIPE NCC that your LIR is > applying for a /29 instead of a /32 because it intends to implement 6rd, > does it? Then everybody can mention that they are about to deploy 6RD ;) We thought of this, but this just introduces unnecessary cycle in the process. > While I don't have a major problem with giving 3 extra bits of > space to implement 6rd, I do have a major problem with: > > 1. making this the default configuration, even for those LIRs who have no > intention of ever deploying 6rd or any other equivalent transition mechanism, /29 for legacy allocations is reserved. Some LIRs would lower operational costs if they could use it (as nobody else could use that space). For latest allocations on binary chops, large quantities of space are in between allocations and likely in our lifetime we will not come to less than /24 or /25 in between the allocations. Fail to see the problem giving LIRs more space by default. > > 2. removal of the requirement to specify 6rd/other mechanism to justify the > extra space, and Yes, removing extra cycle... > > 3. allocating /26 by default. 102 bits of address space is obscenely > wasteful because it is very significantly more than most LIRs will ever > require in the lifetime of the universe (yes, I have worked out the scales > here). Agree. > > Look, I don't mean to sound like a party pooper, but let's not lose the run > of ourselves here. 6rd has very limited deployment at present, and while > it shows a lot of promise as a potentially useful transition mechanism, > it's not yet at the stage where we should feel tempted to shower LIRs with > ridiculous quantities of address bits just because we're feeling a bit > inadequate about current ipv6 uptake. Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW accelerated. Major vendors are offering 6RD core boxes and many operators are testing them. Let's do that properly, if it's unavoidable. 6RD is not the best mechanism ever invented, but making it more complicated and expensive with multiple-6rd-domains because of lack of IPv6 space makes operational life even more complicated. > > I'd like to suggest that 2011-04 be changed so that LIRs can expand their > default /32 to a /29 iff they document a requirement for providing 6rd / > {another specified ipv6 transition mechanism which requires similar bits of > address space} to end-users. Otherwise, a /32 will be assigned by default, > and the RIPE NCC can continue on with their current binary chop allocation > strategy. Again, so everybody can write into their request "we'll deploy 6RD". This is not solving anything. Please, start unthinking IPv4... RIPE-NCC can continue with exactly the same binary chop even if 2011-04 gets implemented. Cheers, Jan From dr at cluenet.de Tue Nov 15 10:49:09 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 15 Nov 2011 10:49:09 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC21BE7.30404@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> Message-ID: <20111115094909.GA28813@srv03.cluenet.de> On Tue, Nov 15, 2011 at 08:59:35AM +0100, Jan Zorz @ go6.si wrote: > Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW > accelerated. Major vendors are offering 6RD core boxes and many operators > are testing them. Let's do that properly, if it's unavoidable. 6RD is not > the best mechanism ever invented, but making it more complicated and > expensive with multiple-6rd-domains because of lack of IPv6 space makes > operational life even more complicated. "properly" as in "easy to deploy" would be to have an extra, eventually temporary, separate /24 for 6RD. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jan at go6.si Tue Nov 15 11:25:11 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 15 Nov 2011 11:25:11 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <20111115094909.GA28813@srv03.cluenet.de> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <20111115094909.GA28813@srv03.cluenet.de> Message-ID: <4EC23E07.1090703@go6.si> On 11/15/11 10:49 AM, Daniel Roesen wrote: > On Tue, Nov 15, 2011 at 08:59:35AM +0100, Jan Zorz @ go6.si wrote: >> Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW >> accelerated. Major vendors are offering 6RD core boxes and many operators >> are testing them. Let's do that properly, if it's unavoidable. 6RD is not >> the best mechanism ever invented, but making it more complicated and >> expensive with multiple-6rd-domains because of lack of IPv6 space makes >> operational life even more complicated. > > "properly" as in "easy to deploy" would be to have an extra, eventually > temporary, separate /24 for 6RD. Maybe yes (as this was also my idea initially), but we already went through this discussion and message from community was clear. Cheers, Jan From emadaio at ripe.net Tue Nov 15 11:55:24 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 15 Nov 2011 11:55:24 +0100 Subject: [address-policy-wg] Update in the Policy Proposal Archive for Proposal 2009-01, "Global Policy for Allocation of IPv4 blocks to Regional Internet Registries" Message-ID: <4EC2451C.3020508@ripe.net> Dear colleagues, As announced at RIPE 63, we will add an explanatory note to the status of policy proposal 2009-01 "Global Policy for Allocation of IPv4 blocks to Regional Internet Registries", as approved by the RIPE community in August 2010. The note reads: "In October 2010, ICANN announced that the NRO deemed the global policy proposal abandoned due to differences in the global proposal texts among the RIRs. This proposal, although regionally accepted, will never be globally implemented." The ICANN announcement is available at: http://www.icann.org/en/announcements/announcement-12may09-en.htm An archive of all RIPE policy proposals is available at: http://www.ripe.net/ripe/policies/archived-policy-proposals Kind regards, Emilio Madaio Policy Development Officer RIPE NCC From nick at inex.ie Tue Nov 15 13:16:25 2011 From: nick at inex.ie (Nick Hilliard) Date: Tue, 15 Nov 2011 12:16:25 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC21BE7.30404@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> Message-ID: <4EC25819.1080700@inex.ie> On 15/11/2011 07:59, Jan Zorz @ go6.si wrote: > I know I'm repeating myself, but probably we should try to "unlearn" all > the speed-bumps we put into IPv4 addressing policy in order to slow down > depletion and start distributing IPv6 space as needed, adapting the > defaults to the feedback from operational environment and community. I'm not particularly proposing slowing down depletion (there are still lots of /29s in 2000::/3). I'm proposing that if a service provider wants or needs additional space above a /32 for 6rd (or any other transition mechanism), that they state this explicitly in their application. And if they don't, they get a /32. And if it turns out later that they need the /29, the current allocation mechanism will allow them to expand easily without address fragmentation. > Then everybody can mention that they are about to deploy 6RD ;) We thought > of this, but this just introduces unnecessary cycle in the process. Yes, they could state that - but why bother? /32 is way more address space than most LIRs would ever use. Putting a single line of text into an application form hardly strikes me as being an excessive burden. Additionally, it provides the RIPE NCC with information on projected usage, which contributes to good stewardship. Here's what it would require: -- Foo ISP is requesting a /29 because it intends to deploy 6rd. -- Are you genuinely saying that it's too much work to put this into an application form? Nick From chrish at consol.net Tue Nov 15 13:26:38 2011 From: chrish at consol.net (chrish at consol.net) Date: Tue, 15 Nov 2011 13:26:38 +0100 Subject: [address-policy-wg] proposal 2011-04, proposal 2011-05, concept document: IPv6 PA/PI unification, intransparent ip-eaters Message-ID: <4EC25A7E.4030708@consol.net> Hi! I see there's broad support for the 2011-05 proposal - by an overwhelming majority of IXP people... There also seems to be broad support for the 2011-04 proposal - I can't really say for sure, but probably by an overwhelming majority of 6RD people... So my 2 cent as some non-IXP non-6RD guy: - I think IXPs should get the IPs they need. That is, just like everyone else. No special treatment. So in 2011-05's sense: 'no'. - I think people who want to use 6RD should get the IPs they need (that includes space for a reasonable 'decent setup' not just the 'minimum space to make it work'). That is, just like everyone else. No special treatment. As 2011-04 doesn't treat 6RD special, that would be ok in this sense - but also superfluous. If $organisation submits documentation reasonably justifying the need for a /29 (like "we do 6RD"), I don't see where the current version of 5.1.2 doesn't already allow what 2011-04 wants to achieve. That's why I'd say 'no' to 2011-04 while at the same time I'd appreciate giving /29 to people who need it for their 6RD setup. Also, I believe 5.2 already allows the same (/29 for 6RD), and I see no need to add a specific paragraph under 5.1 (while I think there might be potential (but not necessarily a need, imho) to make 5.2 more defined and concise). - I am totally a fan of KISS (errm - and btw I expand that to "...small and simple", not "...simple, stupid" ;), and this explicitly and specifically includes policies. I'd therefore generally abstain from putting more specific cases or redundancy than absolutely necessary into policy. In the thread up to now, I didn't see anything that made it clear to me why making IXPs (and/or 6RD) special cases is necessary (or even legitimate). There have been arguments as to lots of IXPs are noncommercial, commercial and noncommercial IXPs cannot be distinguished from each other, and they're all 'good', so they all should be special. I think that's wrong in every way: most IXPs are commercial, it's easy to identify whether an IXP is commercial or noncommercial (on the given examples to illustrate how difficult it is: these three were clearly all commercial), and 'IXPs are good for everybody' is not much different to saying 'starting work at 6am is good for everybody'. Let's not start making some things more equal than others. Well and in case somebody wants to fill up the 'Arguments opposing' paragraph - wouldn't be wrong, I'd say... Following the same rationale, on Gert's concept on "IPs are IPs, IP users are IP users.": while true; do echo -n +; done I really like this! (Except maybe for the 'special case' range - I'd suggest to just skip that, too. Better let's just say "Every IP is special."... There was an example mentioned like $usual_suspect wants another /2, as they do regularly, and as $rir hasn't got sufficient insight into their net design, they just get it. This might be a bit exaggerated ;) - but I think it describes a major existing problem, which really needs to be addressed. In the end it reads to me: The request isn't sufficiently justified. It just shouldn't be approved, in this case - until justified. A huge part of the address space (v4) obviously suffered this kind of problem since ages - and on the so called IPv4-depletion: just by 'cleaning up' some of the existing insane allocations, the 'problem' would disintegrate into thin air (and it might be used as another means to promote v6, btw). I even consider this a moral obligation for anything assuming the role of coordinating the IP commons. I believe we have a really pressing issue here. Regards, Chris From jan at go6.si Tue Nov 15 15:26:00 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 15 Nov 2011 15:26:00 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC25819.1080700@inex.ie> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> Message-ID: <4EC27678.3060507@go6.si> On 11/15/11 1:16 PM, Nick Hilliard wrote: > Here's what it would require: > > -- > Foo ISP is requesting a /29 because it intends to deploy 6rd. > -- Should we put this as optional or suggestion? Cheers, Jan From tjc at ecs.soton.ac.uk Wed Nov 16 03:49:24 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 16 Nov 2011 02:49:24 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC25819.1080700@inex.ie> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <7803DBA2-6908-41D2-9186-FBCE009C4B48@ecs.soton.ac.uk> Message-ID: On 15 Nov 2011, at 12:16, Nick Hilliard wrote: > Here's what it would require: > > -- > Foo ISP is requesting a /29 because it intends to deploy 6rd. > -- > > Are you genuinely saying that it's too much work to put this into an > application form? Seems pretty sensible and practical. Tim From alexlh at ripe.net Wed Nov 16 09:32:01 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 16 Nov 2011 09:32:01 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: Message-ID: <3F31B950-14E8-48F2-9815-C08F768C1A05@ripe.net> Dear Tom, > I agree with this, and also with the general theme of the proposal of extending the initial allocation size. I do not feel that it is sensible to tie this into a specific transition mechanism so am happy with the more generic proposal that has been put together that will also allow better scalability in long term addressing plans. > > One thing that I do wonder is whether the (limited) overhead of the NCC processing these requests mean it is more desirable to limit this "re-request" to a single shot per-LIR (which will likely push people to request the whole /29), or whether permitting multiple requests grabbing a /32 at a time (up to the /29) is desirable. Personally I assume that most networks using this policy extension would go for the /29 straight off, but then there maybe further interaction with the charging scheme which dissuades this. Assuming that the central point of this proposal stays intact, no additional documentation required for expansion up to a /29, the overhead of evaluating and processing these requests for the RIPE NCC would be minimal. Allowing LIRs to request expansion a /32 at a time would not significantly impact our work load. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From slz at baycix.de Wed Nov 16 10:03:06 2011 From: slz at baycix.de (Sascha Lenz) Date: Wed, 16 Nov 2011 10:03:06 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <7803DBA2-6908-41D2-9186-FBCE009C4B48@ecs.soton.ac.uk> Message-ID: Hi, > >> Here's what it would require: >> >> -- >> Foo ISP is requesting a /29 because it intends to deploy 6rd. >> -- >> >> Are you genuinely saying that it's too much work to put this into an >> application form? > > Seems pretty sensible and practical. > > Tim > not quite sure i understand the intention, but... if that's all one would need to write into the application form, what's the point of putting it there in the first place if no one verifies the claim? This actually renders the whole thing irrelevant because everyone will just put that in their template or so. (*dejavue* i think someone already mentioned that within the thread) But maybe i lost the context within the thread... I usually stop following threads in deep when they start going in circles at some point :-) Shame on me in that case and please ignore my comment then. I'm still all for the proposal, not being tied to any specific reason or any jumping through hoops. If someone needs even more, the usual documentation needs to be handed in, be it for 6rd or whatever. Don't make policies too complicated for no reason. We're not (yet?) politicians here. One default, not two, or three, or four, or whatever. /29 seems fine for that due to the historical reservations for early allocations. Then we're done, that's the default in the current /3, fullstop. That's what this proposal is about in the first place (my interpretation?) - just mentioning 6RD as ONE possible feature that would benefit from it. The proposal also mentions more bits for proper subnetting/routing design for example. Why is everyone focussing on the 6RD part? -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From tjc at ecs.soton.ac.uk Wed Nov 16 10:19:58 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 16 Nov 2011 09:19:58 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <7803DBA2-6908-41D2-9186-FBCE009C4B48@ecs.soton.ac.uk> Message-ID: On 16 Nov 2011, at 09:03, Sascha Lenz wrote: > > Why is everyone focussing on the 6RD part? Perhaps in part due to it being the one technology that has been used to date to enable a significant IPv6 deployment (1.5m users, 18Gbit/s traffic for free.fr, reportedly). Of course 6rd should only have a limited lifetime, but it's reality now. Tim From jan at go6.si Wed Nov 16 12:01:48 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 16 Nov 2011 12:01:48 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <7803DBA2-6908-41D2-9186-FBCE009C4B48@ecs.soton.ac.uk> Message-ID: <4EC3981C.7030005@go6.si> On 11/16/11 10:03 AM, Sascha Lenz wrote: > That's what this proposal is about in the first place (my interpretation?) - just mentioning 6RD > as ONE possible feature that would benefit from it. The proposal also mentions more bits for proper > subnetting/routing design for example. +1 > Why is everyone focussing on the 6RD part? No idea. Just one of incentives (initial one). Cheers, Jan From madams at netcologne.de Wed Nov 16 14:01:01 2011 From: madams at netcologne.de (Michael Adams) Date: Wed, 16 Nov 2011 14:01:01 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC3981C.7030005@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <7803DBA2-6908-41D2-9186-FBCE009C4B48@ecs.soton.ac.uk> <4EC3981C.7030005@go6.si> Message-ID: <4EC3B40D.9000501@netcologne.de> Am 16.11.2011 12:01, schrieb Jan Zorz @ go6.si: > On 11/16/11 10:03 AM, Sascha Lenz wrote: >> That's what this proposal is about in the first place (my interpretation?) - just mentioning 6RD >> as ONE possible feature that would benefit from it. The proposal also mentions more bits for proper >> subnetting/routing design for example. > > +1 +1 >> Why is everyone focussing on the 6RD part? > > No idea. Just one of incentives (initial one). +1 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 nick at inex.ie Fri Nov 18 14:57:33 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 18 Nov 2011 13:57:33 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC27678.3060507@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> Message-ID: <4EC6644D.508@inex.ie> On 15/11/2011 14:26, Jan Zorz @ go6.si wrote: > Should we put this as optional or suggestion? All RIRs operate on the basis of stated need for their LIR's addressing requirements. 2011-04 suggests increasing the initial allocation from /32 to /29 on the basis that LIRs are going to need to deploy 6rd to their end-users. As an aside, let's stop beating around the bush here: everyone is focussing on 6rd because if it weren't for 6rd, there would be no requirement for 2011-04 - simply because there are no other likely migration mechanisms on the table which a) require lots of extra IP address space and b) look like they might work. Nick From nick at inex.ie Fri Nov 18 14:58:18 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 18 Nov 2011 13:58:18 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC3981C.7030005@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <7803DBA2-6908-41D2-9186-FBCE009C4B48@ecs.soton.ac.uk> <4EC3981C.7030005@go6.si> Message-ID: <4EC6647A.5050001@inex.ie> On 16/11/2011 11:01, Jan Zorz @ go6.si wrote: > On 11/16/11 10:03 AM, Sascha Lenz wrote: >> Why is everyone focussing on the 6RD part? > > No idea. Just one of incentives (initial one). Let's stop beating around the bush: everyone is focussing on 6rd because if it weren't for 6rd, there would be no requirement for 2011-04 - simply because there are no other ipv6 migration mechanisms around which a) require vast amounts of extra v6 address space and b) look like they might actually work. As a separate issue, the policy should not be worded to mention 6rd. However, we need to acknowledge that the primary motivation for this proposal is all about enabling 6rd. Nick From nick at inex.ie Fri Nov 18 15:04:46 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 18 Nov 2011 14:04:46 +0000 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC6644D.508@inex.ie> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> <4EC6644D.508@inex.ie> Message-ID: <4EC665FE.5070306@inex.ie> On 18/11/2011 13:57, Nick Hilliard wrote: > On 15/11/2011 14:26, Jan Zorz @ go6.si wrote: >> Should we put this as optional or suggestion? > > All RIRs operate on the basis of stated need for their LIR's addressing > requirements. > > 2011-04 suggests increasing the initial allocation from /32 to /29 on the > basis that LIRs are going to need to deploy 6rd to their end-users. Damn, clicked on the wrong email #doh Continuing on the thread of thought in this email: -- Not every LIR is going to require an additional allocation for 6rd, simply because not every LIR is going to implement 6rd or any other transition technology. Therefore if 2011-04 is passed as it is, these LIRs are going to get an extra 3 bits of ipv6 address space for no reason. This violates the basis of RIR->LIR allocation policy. You get something for nothing which you frankly don't need and will never use. I'd like to suggest that the default allocation should continue to be /32, but if the LIR makes a claim that they are going to implement 6rd (or another equivalent transition technology which requires lots of address space), then they can receive up to a /29. If AP-WG doesn't want to do this, then we need to change the basic policy of allocation based on stated need to, well, something else. Not quite sure what. Nick /one day, i'll get the hang of this email thing From jan at go6.si Fri Nov 18 18:41:57 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 18 Nov 2011 18:41:57 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC665FE.5070306@inex.ie> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> <4EC6644D.508@inex.ie> <4EC665FE.5070306@inex.ie> Message-ID: <4EC698E5.7080509@go6.si> On 11/18/11 3:04 PM, Nick Hilliard wrote: > I'd like to suggest that the default allocation should continue to be /32, > but if the LIR makes a claim that they are going to implement 6rd (or > another equivalent transition technology which requires lots of address > space), then they can receive up to a /29. Well done :) This is also Remco's suggestion, /32 as default, up to /29 only if LIR asks - and this is going to new version of 2011-04, that will be posted to your favorite mailinglist shortly :) Cheers, Jan From danny at danysek.cz Fri Nov 18 22:28:15 2011 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 18 Nov 2011 22:28:15 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC698E5.7080509@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> <4EC6644D.508@inex.ie> <4EC665FE.5070306@inex.ie> <4EC698E5.7080509@go6.si> Message-ID: <4EC6CDEF.5080403@danysek.cz> On 11/18/2011 06:41 PM, Jan Zorz @ go6.si wrote: >> I'd like to suggest that the default allocation should continue to be >> /32, >> but if the LIR makes a claim that they are going to implement 6rd (or >> another equivalent transition technology which requires lots of address >> space), then they can receive up to a /29. > This is also Remco's suggestion, /32 as default, up to /29 only if LIR > asks I support this. There's no reason to allocate more than /32 for LIR by default. In special cases, there's no reason to block that allocation, but someone has provide some arguments to support his requirement.... From danny at danysek.cz Fri Nov 18 22:44:33 2011 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 18 Nov 2011 22:44:33 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC698E5.7080509@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> <4EC6644D.508@inex.ie> <4EC665FE.5070306@inex.ie> <4EC698E5.7080509@go6.si> Message-ID: <4EC6D1C1.2040009@danysek.cz> On 11/18/2011 06:41 PM, Jan Zorz @ go6.si wrote: >> I'd like to suggest that the default allocation should continue to be >> /32, >> but if the LIR makes a claim that they are going to implement 6rd (or >> another equivalent transition technology which requires lots of address >> space), then they can receive up to a /29. > This is also Remco's suggestion, /32 as default, up to /29 only if LIR > asks I support this. There's no reason to allocate more than /32 for LIR by default. In special cases, there's no reason to block that allocation, but someone has provide some arguments to support his requirement.... From jan at go6.si Sat Nov 19 12:23:19 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 19 Nov 2011 12:23:19 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC6D1C1.2040009@danysek.cz> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> <4EC6644D.508@inex.ie> <4EC665FE.5070306@inex.ie> <4EC698E5.7080509@go6.si> <4EC6D1C1.2040009@danysek.cz> Message-ID: <4EC791A7.7090007@go6.si> On 11/18/11 10:44 PM, Daniel Suchy wrote: > I support this. There's no reason to allocate more than /32 for LIR by > default. In special cases, there's no reason to block that allocation, > but someone has provide some arguments to support his requirement.... We thought of putting suggestion to mention what LIR will use the space for if request is bigger than /32, but we figured out, that this is too technical requirement to put it into policy. IPRA can always politely ask, what is intended space usage (for documentary reasons, not justification). We could put this in policy proposal as what happens if this reaches consensus, but not in the policy itself. Cheers, Jan From maildanrl at googlemail.com Mon Nov 21 08:19:36 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 21 Nov 2011 08:19:36 +0100 Subject: [address-policy-wg] 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation" In-Reply-To: <4EC791A7.7090007@go6.si> References: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D50EA@EXVPMBX100-1.exc.icann.org> <4EC19BBB.5010504@inex.ie> <4EC21BE7.30404@go6.si> <4EC25819.1080700@inex.ie> <4EC27678.3060507@go6.si> <4EC6644D.508@inex.ie> <4EC665FE.5070306@inex.ie> <4EC698E5.7080509@go6.si> <4EC6D1C1.2040009@danysek.cz> <4EC791A7.7090007@go6.si> Message-ID: Hallo *, here is an alternative phrasing for this issue. I wrote a while ago in the 6RD discussion, but since I am not affected by this I did not push it trough the policy process. Feel free to update and use it, if it fits your purpose. -- 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 interms of the number of sites in units of /56 assignments. The HD-Ratio[RFC 3194] is used to determine the utilisation thresholds thatjustify the allocation of additional address as described below; b) qualifies in accordance with the criteria for an initial allocation of /29. -- snap -- regards, Dan -- Dan Luedtke http://www.danrl.de From rramphul at ripe.net Wed Nov 30 09:59:56 2011 From: rramphul at ripe.net (Radha Ramphul) Date: Wed, 30 Nov 2011 09:59:56 +0100 Subject: [address-policy-wg] Policy Proposal 2010-01 "Temporary Internet Number Assignment Policies" implemented Message-ID: <4ED5F08C.3040503@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that RIPE Policy Proposal 2010-01,"Temporary Internet Number Assignment Policies", has been implemented. The RIPE NCC is now ready to accept requests for Temporary Internet Number Assignments under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2010-01 The new policy "Temporary Internet Number Assignment Policies" is available at: https://www.ripe.net/ripe/docs/ripe-526 The following documents now appear online as part of this policy implementation. 1. A new contract template has been formulated which can be used as the agreement between LIRs and End-users. It can be downloaded at: http://ripe.net/lir-services/resource-management/temp-assign-agreement 2. A new request template (currently in text format only) is now available. The LIR portal version will be coming soon. http://www.ripe.net/ripe/docs/ripe-536 3. Supporting notes explaining the various sections of the form and how to complete them have been added as well. http://www.ripe.net/ripe/docs/ripe-535 4. A new FAQ page can be accessed at: https://www.ripe.net/lir-services/resource-management/number-resources/temporary-internet-number-assignment/faq The following resources have been reserved for this purpose: IPv4: 151.216.0.0/13 16-bit ASN: AS58352-AS58367 No reservations have been made for IPv6 and 32-bit ASN. Regards Radha Ramphul RIPE NCC Registration Services From emadaio at ripe.net Wed Nov 30 16:53:36 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 30 Nov 2011 16:53:36 +0100 Subject: [address-policy-wg] Final minutes from RIPE 62 Message-ID: <4ED65180.5040904@ripe.net> Dear colleagues, The minutes from the Address Policy Working Group session from RIPE 62 were approved during RIPE 63. The minutes are available here: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-62 Best Regards, Emilio Madaio Policy Development Officer RIPE NCC