From no-reply at ripe.net Mon Jul 4 15:56:28 2011 From: no-reply at ripe.net (Paul Rendek) Date: Mon, 04 Jul 2011 15:56:28 +0200 Subject: [ipv6-wg] Global IPv6 Deployment Monitoring Survey 2011 Now Open Message-ID: <4E11C68C.2030202@ripe.net> Dear Colleagues, The Global IPv6 Deployment Monitoring Survey 2011 is now online at: http://www.surveymonkey.com/s/GlobalIPv6survey2011 This survey has been designed by GNKS Consult in collaboration with TNO and the RIPE NCC to further understand where the community stands on IPv6 and what needs be done to ensure that the Internet community is ready for the widespread adoption of IPv6. Anyone can participate in this survey and we hope that the results will establish a comprehensive view of current IPv6 penetration and future plans for IPv6 deployment. The survey comprises 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments or who have not yet deployed IPv6, there will be fewer questions. The survey will close on 31 July 2011. We thank you for your time and interest in completing this survey. If you have any questions concerning the survey, please email . For more information about the survey and links to previous year's survey results, please see: https://www.ripe.net/internet-coordination/news/industry-developments/global-ipv6-deployment-monitoring-survey-2011 Regards, Paul Rendek RIPE NCC Head of External Relations and Communication From mir at ripe.net Tue Jul 5 16:36:21 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 05 Jul 2011 16:36:21 +0200 Subject: [ipv6-wg] Measuring long-term effects of World IPv6 Day Message-ID: <4E132165.4000508@ripe.net> [apologies for duplicates] Dear colleagues, We have been looking at some more long-term effects of World IPv6 Day, held on 8 June. Please find more on RIPE Labs: http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-long-term-effects Kind Regards, Mirjam Kuehne RIPE NCC From jan at go6.si Thu Jul 14 10:39:38 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 14 Jul 2011 10:39:38 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <007301cc2fd9$95f630d0$c1e29270$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> Message-ID: <4E1EAB4A.3040109@go6.si> On 6/21/11 8:08 AM, Ivan Pepelnjak wrote: >> From the "outside" perspective, a load-balanced service implemented >> with one or more redundant load balancers _MUST_ look like an IPv4 >> _OR_ an IPv6 address (where OR is not exclusive, but AND is not >> strictly necessary) distributing sessions to IPv4 or IPv6 inside >> nodes. It _SHOULD_ be able distribute sessions arriving to an >> outside address (IPv4 or IPv6) to a mixed cluster of IPv4 _AND_ >> IPv6 addresses. Hi, OK, we need to get out to the mailinglist next revision od RIPE-501 followup document somewhere in next week. LB spec is the thing, that is not done yet, as there are N+1 opinions (N being the number of people I talk to about this matter :) ) Are there any RFCs describing the above requirements? Question is - how "deep" we need to go with the mandatory part of the spec? As far as network is concerned, LB is a host that receives connections and magically re-distributes them to end hosts. It's not a router and it breaks end2end. How to specify that? :) > > How a LB device implements its magic (L4 passthrough with NAT, L4 > termination, L7 proxy, whatever other tricks) is irrelevant (and > seems there are no "obvious" RFCs documenting it). What is MANDATORY > is that it supports connections from IPv6 clients to IPv4 and/or IPv6 > servers and from IPv4 clients to IPv4 and/or IPv6 servers (see last > sentence in the previous paragraph) to enable all possible migration > scenarios. So this looks like "host" spec could be the starting point of new spec? > > However, I would recommend that for 6-to-4 functionality, we > _RECOMMEND_ the load balancer adheres to the RFC6146 (stateful NAT64) > - we should discourage (but not forbid) vendors from doing homebrew > 6-to-4 translation when a standard exists specifying how to do it. We could put all *NAT* and L4+ stuff in optional requirements. Probably the goal is to describe IPv6 load balancer, that would work in IPv6 only environment and IPv6 only clients and servers. Am I wrong? All this "put the balancer to serve v6 clients from v4 servers" rubbish makes this task nearly impossible. > > On the IPv6 protocol side, the very minimum requirement is adherence > to IPv6 host behavior. Some LB designs work without significant > support for routing - single inside and outside /64 with RA-generated > default route on the outside - or they could support some routing > protocols. Those should (in my opinion) be made _OPTIONAL_. So, "host" with added some routing options. > > Oh, and I never claimed I know anything about load balancers, so I > might be totally wrong ;) Ivan We know you ;) Cheers, /jan From ipepelnjak at gmail.com Sat Jul 16 20:40:01 2011 From: ipepelnjak at gmail.com (Ivan Pepelnjak) Date: Sat, 16 Jul 2011 20:40:01 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4E1EAB4A.3040109@go6.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> <4E1EAB4A.3040109@go6.si> Message-ID: <014a01cc43e7$c71f37c0$555da740$@com> > Are there any RFCs describing the above requirements? Couldn't find any. I guess you're not interested in RFC 1794 ;)) [...] > So this looks like "host" spec could be the starting point of new spec? I would say LB MUST conform to "host" spec. Those load balancers that provide routing functionality MUST conform to "router" specs. > We could put all *NAT* and L4+ stuff in optional requirements. Probably > the goal is to describe IPv6 load balancer, that would work in IPv6 only > environment and IPv6 only clients and servers. Am I wrong? Load balancing between IPv6 clients and IPv6 and IPv4 servers (6-to-6 and 6-to-4) is a short-term MUST. 4-to-6 is a longer-term SHOULD. Mixed v4/v6 servers behind the same outside virtual IPv6 address is a SHOULD. Support for X-forwarded-for (or equivalent) header in HTTP is a MUST (otherwise the servers lose any visibility into who the client is). I don't think you can specify anything more than this. Ivan From jan at go6.si Mon Jul 18 10:13:34 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 18 Jul 2011 10:13:34 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <014a01cc43e7$c71f37c0$555da740$@com> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> <4E1EAB4A.3040109@go6.si> <014a01cc43e7$c71f37c0$555da740$@com> Message-ID: <4E23EB2E.5010108@go6.si> On 7/16/11 8:40 PM, Ivan Pepelnjak wrote: > I would say LB MUST conform to "host" spec. Those load balancers that > provide routing functionality MUST conform to "router" specs. Well, we can take the spec of host and tweak it - as by definition that we use "A host is a network participant that sends and receives packets but does not forward them on behalf of others." LB can't be just host :) Now we just need to see which routing protocols are commonly used in load balancers and what requirements to get from Router spec section. > >> We could put all *NAT* and L4+ stuff in optional requirements. >> Probably the goal is to describe IPv6 load balancer, that would >> work in IPv6 only environment and IPv6 only clients and servers. Am >> I wrong? > > Load balancing between IPv6 clients and IPv6 and IPv4 servers (6-to-6 > and 6-to-4) is a short-term MUST. 4-to-6 is a longer-term SHOULD. Maybe we can write this requirements as wording, not as RFC pointer... > > Mixed v4/v6 servers behind the same outside virtual IPv6 address is a > SHOULD. > > Support for X-forwarded-for (or equivalent) header in HTTP is a MUST > (otherwise the servers lose any visibility into who the client is). this is also non-RFC requirement... Let's see what I can do. /jan From dez at otenet.gr Mon Jul 18 15:02:34 2011 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Mon, 18 Jul 2011 16:02:34 +0300 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Message-ID: <4E242EEA.40009@otenet.gr> hello all, Lately we've been trying to lay out a future-proof IPv6 addressing plan (actually, to revise our initial IPv6 plan from a few years back) and we came to the conclusion that if we were to plan ahead for a few years, we would need an extra IPv6 allocation from RIPE, one more /32 (we already have one). Well, according to ripe-512 we're not eligible for a subsequent allocation yet, since we haven't met the subsequent allocation criteria (HD ratio). We'll be offering our commercial dual stack services (broadband, leased-lines VPNs) next year. This means that we'll have 1,2M potential subscribers (/56) just for the retail service. And then there's all the /48s for the VPNs and bigger customers. I'm not saying that all of our customers will migrate to IPv6 at once but we have to plan, don't we? And then there's the growth factor to be considered also... For us, this extra /32 will make the difference between an efficient and future-proof addressing plan that will last for many years and one that will have to be revised after 2-3 years (with all the readdressing etc). I thought that one of the key advantages with IPv6 was the fact that we would get rid of readdressing. What I'm trying to say is that ripe-512 is not flexible enough. In the end, should we planning ahead for many years (as per RFC6177) or not? any thoughts? cheers, Yannis From sander at steffann.nl Mon Jul 18 15:26:35 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Jul 2011 15:26:35 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E242EEA.40009@otenet.gr> References: <4E242EEA.40009@otenet.gr> Message-ID: <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> Hello Yannis, > Lately we've been trying to lay out a future-proof IPv6 addressing plan (actually, to revise our initial IPv6 plan from a few years back) and we came to the conclusion that if we were to plan ahead for a few years, we would need an extra IPv6 allocation from RIPE, one more /32 (we already have one). Well, according to ripe-512 we're not eligible for a subsequent allocation yet, since we haven't met the subsequent allocation criteria (HD ratio). > > We'll be offering our commercial dual stack services (broadband, leased-lines VPNs) next year. This means that we'll have 1,2M potential subscribers (/56) just for the retail service. And then there's all the /48s for the VPNs and bigger customers. I'm not saying that all of our customers will migrate to IPv6 at once but we have to plan, don't we? And then there's the growth factor to be considered also... > > For us, this extra /32 will make the difference between an efficient and future-proof addressing plan that will last for many years and one that will have to be revised after 2-3 years (with all the readdressing etc). I thought that one of the key advantages with IPv6 was the fact that we would get rid of readdressing. What I'm trying to say is that ripe-512 is not flexible enough. In the end, should we planning ahead for many years (as per RFC6177) or not? I am adding the address policy working group. Any changes to address policy / ripe-512 should (also) be discussed there. Thank you, Sander Steffann APWG co-chair From jan at go6.si Mon Jul 18 15:35:40 2011 From: jan at go6.si (Jan Zorz @ Go6.si) Date: Mon, 18 Jul 2011 15:35:40 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> Message-ID: <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> Trade in your /32 and get something bigger under initial alloc conditions... :) Jan Sander Steffann wrote: >Hello Yannis, > >> Lately we've been trying to lay out a future-proof IPv6 addressing >plan (actually, to revise our initial IPv6 plan from a few years back) >and we came to the conclusion that if we were to plan ahead for a few >years, we would need an extra IPv6 allocation from RIPE, one more /32 >(we already have one). Well, according to ripe-512 we're not eligible >for a subsequent allocation yet, since we haven't met the subsequent >allocation criteria (HD ratio). >> >> We'll be offering our commercial dual stack services (broadband, >leased-lines VPNs) next year. This means that we'll have 1,2M potential >subscribers (/56) just for the retail service. And then there's all the >/48s for the VPNs and bigger customers. I'm not saying that all of our >customers will migrate to IPv6 at once but we have to plan, don't we? >And then there's the growth factor to be considered also... >> >> For us, this extra /32 will make the difference between an efficient >and future-proof addressing plan that will last for many years and one >that will have to be revised after 2-3 years (with all the readdressing >etc). I thought that one of the key advantages with IPv6 was the fact >that we would get rid of readdressing. What I'm trying to say is that >ripe-512 is not flexible enough. In the end, should we planning ahead >for many years (as per RFC6177) or not? > >I am adding the address policy working group. Any changes to address >policy / ripe-512 should (also) be discussed there. > >Thank you, >Sander Steffann >APWG co-chair -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From ip at ioshints.info Mon Jul 18 17:21:24 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 18 Jul 2011 17:21:24 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> Message-ID: <004801cc455e$5d0039c0$1700ad40$@info> Let me try to understand: (A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. Was someone reading too much Kafka or The Good Soldier ?vejk lately? Ivan > -----Original Message----- > From: Jan Zorz @ Go6.si [mailto:jan at go6.si] > Sent: Monday, July 18, 2011 5:13 PM > To: Ivan Pepelnjak; 'Sander Steffann'; 'Yannis Nikolopoulos' > Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > Going to production it was said :) > > I did a long discussion with Alex Le Heux (RIPE IPRA) about the same > issue, his advice was that. > > Jan > > Ivan Pepelnjak wrote: > > >Extremely helpful advice from the ops perspective. > > > >> Trade in your /32 and get something bigger under initial alloc > >> conditions... :) > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From sander at steffann.nl Mon Jul 18 17:25:49 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Jul 2011 17:25:49 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <004801cc455e$5d0039c0$1700ad40$@info> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> Message-ID: Hi Ivan, > Let me try to understand: > > (A) We don't disagree that he might actually deserve more than /32 > (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs > (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) > (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer. After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal. Thanks, Sander From scottleibrand at gmail.com Mon Jul 18 18:57:51 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 18 Jul 2011 09:57:51 -0700 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> Message-ID: On Mon, Jul 18, 2011 at 8:25 AM, Sander Steffann wrote: > Hi Ivan, > >> Let me try to understand: >> >> (A) We don't disagree that he might actually deserve more than /32 >> (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs >> (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) >> (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. > > All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer. > > After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal. FYI, a number of folks had this same issue in the ARIN region, and as a result policy ARIN-2010-12 (https://www.arin.net/policy/proposals/2010_12.html) was proposed, adopted, and implemented to address the problem. -Scott From dr at cluenet.de Mon Jul 18 21:20:54 2011 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 18 Jul 2011 21:20:54 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> Message-ID: <20110718192054.GA18492@srv03.cluenet.de> On Mon, Jul 18, 2011 at 05:25:49PM +0200, Sander Steffann wrote: > The current policy doesn't permit the RIPE NCC to give out extra > address space for an existing allocation until the HD ratio has > been reached. And this translates to "you have to support at least ~6.2 million customers with the /32 before being eligliable for more". Unfortunately, for shops that are living in the same order of magnitude size wise, this does not really translate to pretty and future-proof addressing concepts with polished internal aggregation on site and aggregation router levels, depending on how many sites and aggregation routers you have, what's your growth you need to account for in those numbers, and what's the variance of # of customers per aggregation router (leading to DHCPv6-PD pool sizing). Changing /48 to /56 as size-of-measurement is one problem, but raising the HD ratio from 0.8 to 0.94 was the killer. For us, it's the difference between a ~/22 (former) and a /32 (now). 10 bits less to design a scaling internal addressing plan without introducing kludges and/or having to largely re-shuffle large parts every couple of years. Another theoretical advantage of IPv6 compared to IPv4 practically (in part) down the drain. Good that we saved some scarce addresses. :-/ [no, I'm not advocating senseless waste - but what's "wasting" and "making use of a technology to realize improvements in operational cost" is probably very much in the eye of the beholder] > They are allowed to give more than a /32 when someone requests a > new allocation though. "the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure." I wonder wether the HD ratio 0.94 rule will be the one this is being judged by. Abovementioned latter criteria is _very_ subjective. :-) > After reading the policies with this in mind I can only conclude > that the RIPE NCC is implementing the policy correctly. If we want > the NCC to do something else someone has to write a policy proposal. I haven't heard anyone complaining about too small allocations with HD ratio 0.8 in effect. Perhaps the truth lies somewhere between 0.8 and 0.94. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From sander at steffann.nl Mon Jul 18 23:08:11 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Jul 2011 23:08:11 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <20110718192054.GA18492@srv03.cluenet.de> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <20110718192054.GA18492@srv03.cluenet.de> Message-ID: <584675A7-310F-4C25-8E00-74B09473975B@steffann.nl> Hi, > And this translates to "you have to support at least ~6.2 million > customers with the /32 before being eligliable for more". Well, ~5.9 million if you are giving all customers a /56. But if you are giving all customers a /56 you have 16 million /56's to use. That is a 37% usage of the block. It's already a lot better than the 80% rule in IPv4-space. > Changing /48 to /56 as size-of-measurement is one problem What is the problem? If you hand out /56's to a customer you count '1 /56 assigned'. If you hand out a /48 to a customer you count '256 /56's assigned'. - Sander PS: I do agree with you that we should use the address space that IPv6 is providing From Jasper.Jans at espritxb.nl Tue Jul 19 09:38:36 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Tue, 19 Jul 2011 09:38:36 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. Jasper -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: Monday, July 18, 2011 5:26 PM To: Ivan Pepelnjak Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg at ripe.net; address-policy-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Hi Ivan, > Let me try to understand: > > (A) We don't disagree that he might actually deserve more than /32 > (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs > (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) > (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and I got the same answer. After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the NCC to do something else someone has to write a policy proposal. Thanks, Sander Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From jan at go6.si Tue Jul 19 09:56:49 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 09:56:49 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> Message-ID: <4E2538C1.30506@go6.si> On 7/19/11 9:38 AM, Jasper Jans wrote: > The RIPE currently reserves a /29 for every initial /32. > So as long as there is a policy that allows expansion of the initial > assignment based upon a sound network design there should not be > any issue to bump it up to a bigger block. Hi, As presented, discussed and suggested at RIPE62 in Amsterdam, we are currently working on policy change proposal, that would rise the minimum IPv6 allocation size to /29 and automatically made of use that "reserved" /29 space for each legacy /32 allocation (that would almost never be used otherwise). Primary reason for that proposal was wasteful transition mechanisms (like 6RD...), but this change also solves some of issues, rised in this thread. Stay tuned :) Cheers, Jan Zorz Go6 Slovenia From sander at steffann.nl Tue Jul 19 10:04:28 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 10:04:28 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <20110718220445.GF3169@benabuFaUl.be.free.de> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <20110718192054.GA18492@srv03.cluenet.de> <20110718220445.GF3169@benabuFaUl.be.free.de> Message-ID: Hi WG, Op 19 jul 2011, om 00:04 heeft Immo 'FaUl' Wehrenberg het volgende geschreven: > Daniel wrote: >> [no, I'm not advocating senseless waste - but what's "wasting" and >> "making use of a technology to realize improvements in operational cost" >> is probably very much in the eye of the beholder] > > I must agree here. If you do the math, you come up with "we do have > enough addresses, even if we give any human on earth hundreds of /48" > (and I hope nobody really wants to do). But as we are at the luxury > point where saving address space isn't really that big issue, why > shoud we make network design more difficult by introducing artificial > obstacles that possible saves some addresse? From my point of view > IPv6 address policy should focus on: > a) making IPv6 easy deployable > b) keeping the dfz table as small as possible without restrains to > IPv6 deployment > c) allowing clean network design even if that comes with the cost > of a reasonable amount of additional address space usage > > Obviously, we also should keep in mind that the IPv6 space is huge > but finite so we should make sure that we will not run low on > address space at some point. > > To sum things up, I think the HD-Ratio of .94 is not what we want as > it makes future deployment more difficult without any real reason. I think Immo has given a good summary of what I heard on this list and from some people at the last RIPE meeting. Scott also brought this to our attention: > FYI, a number of folks had this same issue in the ARIN region, and as a result policy ARIN-2010-12 (https://www.arin.net/policy/proposals/2010_12.html) was proposed, adopted, and implemented to address the problem. Considering the amount of messages here related to this subject I think we should start working towards a formal policy proposal. Jan ?or? has already started working on a related proposal (see his message a few minutes ago on this list) so I think it might be a good idea to start from there. Thanks, Sander From immo.ripe at be.free.de Tue Jul 19 00:04:45 2011 From: immo.ripe at be.free.de (Immo 'FaUl' Wehrenberg) Date: Tue, 19 Jul 2011 00:04:45 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <20110718192054.GA18492@srv03.cluenet.de> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <20110718192054.GA18492@srv03.cluenet.de> Message-ID: <20110718220445.GF3169@benabuFaUl.be.free.de> Daniel wrote: > [no, I'm not advocating senseless waste - but what's "wasting" and > "making use of a technology to realize improvements in operational cost" > is probably very much in the eye of the beholder] I must agree here. If you do the math, you come up with "we do have enough addresses, even if we give any human on earth hundreds of /48" (and I hope nobody really wants to do). But as we are at the luxury point where saving address space isn't really that big issue, why shoud we make network design more difficult by introducing artificial obstacles that possible saves some addresse? From my point of view IPv6 address policy should focus on: a) making IPv6 easy deployable b) keeping the dfz table as small as possible without restrains to IPv6 deployment c) allowing clean network design even if that comes with the cost of a reasonable amount of additional address space usage Obviously, we also should keep in mind that the IPv6 space is huge but finite so we should make sure that we will not run low on address space at some point. To sum things up, I think the HD-Ratio of .94 is not what we want as it makes future deployment more difficult without any real reason. However, a mayor issue right now, where most ISPs are in the process to design and roll out IPv6 to their end-customers real soon, is that once they started to assign networks to very few customers some time ago, they cannot apply for an additional network without either lying to the NCC (about assignments to customers that have not been made yet) or create a crude design, then start rollout, stop rollout when addressspace is used, request additional addresses and then redesign the entire network (or be stuck with your crude design you came up with to work around the 'to few addresses to do a proper design' issue). So what we really need is to allow the NCC to make assignments based on reasonable guesses if the resulting prefix size (of both, the existing prefix(es) and the newly requested prefix) will be reasonable in HD-Ratio terms. Best regards, Immo Wehrenberg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dez at otenet.gr Tue Jul 19 10:43:05 2011 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Tue, 19 Jul 2011 11:43:05 +0300 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2538C1.30506@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4E2538C1.30506@go6.si> Message-ID: <4E254399.4000200@otenet.gr> Hello again, On 07/19/2011 10:56 AM, Jan Zorz @ go6.si wrote: > On 7/19/11 9:38 AM, Jasper Jans wrote: >> The RIPE currently reserves a /29 for every initial /32. >> So as long as there is a policy that allows expansion of the initial >> assignment based upon a sound network design there should not be >> any issue to bump it up to a bigger block. > Hi, > > As presented, discussed and suggested at RIPE62 in Amsterdam, we are > currently working on policy change proposal, that would rise the > minimum IPv6 allocation size to /29 and automatically made of use that > "reserved" /29 space for each legacy /32 allocation (that would almost > never be used otherwise). > would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ? If not, it doesn't really solve the issue at hand. cheers, Yannis > Primary reason for that proposal was wasteful transition mechanisms > (like 6RD...), but this change also solves some of issues, rised in > this thread. > > Stay tuned :) > > Cheers, Jan Zorz > Go6 Slovenia > From sander at steffann.nl Tue Jul 19 10:47:04 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 10:47:04 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E254399.4000200@otenet.gr> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4E2538C1.30506@go6.si> <4E254399.4000200@otenet.gr> Message-ID: Hi, > would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ? If not, it doesn't really solve the issue at hand. That is the idea :) Sander From jan at go6.si Tue Jul 19 10:49:47 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 10:49:47 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E254399.4000200@otenet.gr> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4E2538C1.30506@go6.si> <4E254399.4000200@otenet.gr> Message-ID: <4E25452B.7070200@go6.si> On 7/19/11 10:43 AM, Yannis Nikolopoulos wrote: > would this mean that all LIRs that got an initial /32 will get > "upgraded" to a /29 ? Yes. Jan From dez at otenet.gr Tue Jul 19 10:55:34 2011 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Tue, 19 Jul 2011 11:55:34 +0300 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4E2538C1.30506@go6.si> <4E254399.4000200@otenet.gr> Message-ID: <4E254686.30903@otenet.gr> On 07/19/2011 11:47 AM, Sander Steffann wrote: > Hi, > >> would this mean that all LIRs that got an initial /32 will get "upgraded" to a /29 ? If not, it doesn't really solve the issue at hand. > That is the idea :) > Sander ok, great :) From ahmed at tamkien.com Tue Jul 19 11:16:08 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Tue, 19 Jul 2011 12:16:08 +0300 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> Message-ID: <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment. This may be too late to fix for the current block of globally routable addresses, but minimum subnet size is worth reconsidering by the IETF for the future blocks. -Ahmed -------------------------------------------------- From: "Jasper Jans" Sent: Tuesday, July 19, 2011 10:38 AM To: "Sander Steffann" ; "Ivan Pepelnjak" Cc: "'Jan Zorz @ Go6.si'" ; "'Yannis Nikolopoulos'" ; ; Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > The RIPE currently reserves a /29 for every initial /32. > So as long as there is a policy that allows expansion of the initial > assignment based upon a sound network design there should not be > any issue to bump it up to a bigger block. > > Jasper > > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Sander Steffann > Sent: Monday, July 18, 2011 5:26 PM > To: Ivan Pepelnjak > Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg at ripe.net; > address-policy-wg at ripe.net > Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > Hi Ivan, > >> Let me try to understand: >> >> (A) We don't disagree that he might actually deserve more than /32 >> (B) According to my understanding of previous discussions I had on this >> topic, RIPE might actually have already reserved extra space for his >> future needs >> (C) According to the current rules he can't get another /32 for a total >> of /31 without using most of the current /32 (and hoping his next /32 >> will be adjacent) >> (D) Someone is seriously suggesting he returns the current /32 and asks >> for a brand new /31 which he will likely get. > > All correct. The current policy doesn't permit the RIPE NCC to give out > extra address space for an existing allocation until the HD ratio has been > reached. They are allowed to give more than a /32 when someone requests a > new allocation though. I have had this same issue and I got the same > answer. > > After reading the policies with this in mind I can only conclude that the > RIPE NCC is implementing the policy correctly. If we want the NCC to do > something else someone has to write a policy proposal. > > Thanks, > Sander > > > > > > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is > op http://www.espritxb.nl/disclaimer > > From gvandeve at cisco.com Tue Jul 19 11:23:27 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 11:23:27 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> Jasper wrote: The RIPE currently reserves a /29 for every initial /32. So as long as there is a policy that allows expansion of the initial assignment based upon a sound network design there should not be any issue to bump it up to a bigger block. GV> An issue I see with this policy is that it does not support pro-active address planning for the longer term and may end up in fragmented non-summarizable address space within an organization. Mainly because the newly required address space will be different block and will as result require new address planning policy within the organization itself. G/ From gvandeve at cisco.com Tue Jul 19 11:24:15 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 11:24:15 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2538C1.30506@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4E2538C1.30506@go6.si> Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065E87@XMB-AMS-101.cisco.com> Good :-) G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: 19 July 2011 09:57 To: ipv6-wg at ripe.net; address-policy-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) On 7/19/11 9:38 AM, Jasper Jans wrote: > The RIPE currently reserves a /29 for every initial /32. > So as long as there is a policy that allows expansion of the initial > assignment based upon a sound network design there should not be > any issue to bump it up to a bigger block. Hi, As presented, discussed and suggested at RIPE62 in Amsterdam, we are currently working on policy change proposal, that would rise the minimum IPv6 allocation size to /29 and automatically made of use that "reserved" /29 space for each legacy /32 allocation (that would almost never be used otherwise). Primary reason for that proposal was wasteful transition mechanisms (like 6RD...), but this change also solves some of issues, rised in this thread. Stay tuned :) Cheers, Jan Zorz Go6 Slovenia From gvandeve at cisco.com Tue Jul 19 11:25:34 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 11:25:34 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> You want to change how IPv6 SLAAC works? And ND? G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Ahmed Abu-Abed Sent: 19 July 2011 11:16 To: RIPE IPv6 Cc: address-policy-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment. This may be too late to fix for the current block of globally routable addresses, but minimum subnet size is worth reconsidering by the IETF for the future blocks. -Ahmed -------------------------------------------------- From: "Jasper Jans" Sent: Tuesday, July 19, 2011 10:38 AM To: "Sander Steffann" ; "Ivan Pepelnjak" Cc: "'Jan Zorz @ Go6.si'" ; "'Yannis Nikolopoulos'" ; ; Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > The RIPE currently reserves a /29 for every initial /32. > So as long as there is a policy that allows expansion of the initial > assignment based upon a sound network design there should not be > any issue to bump it up to a bigger block. > > Jasper > > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Sander Steffann > Sent: Monday, July 18, 2011 5:26 PM > To: Ivan Pepelnjak > Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg at ripe.net; > address-policy-wg at ripe.net > Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > Hi Ivan, > >> Let me try to understand: >> >> (A) We don't disagree that he might actually deserve more than /32 >> (B) According to my understanding of previous discussions I had on this >> topic, RIPE might actually have already reserved extra space for his >> future needs >> (C) According to the current rules he can't get another /32 for a total >> of /31 without using most of the current /32 (and hoping his next /32 >> will be adjacent) >> (D) Someone is seriously suggesting he returns the current /32 and asks >> for a brand new /31 which he will likely get. > > All correct. The current policy doesn't permit the RIPE NCC to give out > extra address space for an existing allocation until the HD ratio has been > reached. They are allowed to give more than a /32 when someone requests a > new allocation though. I have had this same issue and I got the same > answer. > > After reading the policies with this in mind I can only conclude that the > RIPE NCC is implementing the policy correctly. If we want the NCC to do > something else someone has to write a policy proposal. > > Thanks, > Sander > > > > > > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is > op http://www.espritxb.nl/disclaimer > > From jan at go6.si Tue Jul 19 11:31:13 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 11:31:13 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> Message-ID: <4E254EE1.8080101@go6.si> On 7/19/11 11:16 AM, Ahmed Abu-Abed wrote: > I think we will keep having having these issues until the minimum subnet > assignment (outside point to point links) can be smaller than /64 which > is an astronomical waste of public addresses for a home or business > assignment. Maybe it's me, but I really don't understand what are you talking about. Can you please elaborate a bit on this? Cheers, Jan From sander at steffann.nl Tue Jul 19 11:32:39 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 11:32:39 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> Message-ID: <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> Hi Gunter, > GV> An issue I see with this policy is that it does not support > pro-active address planning for the longer term and may end up in > fragmented non-summarizable address space within an organization. Mainly > because the newly required address space will be different block and > will as result require new address planning policy within the > organization itself. I don't understand your comment. The idea of the policy proposal is to automatically grow the existing /32 to a /29. That results in a single /29 for an ISP. - Sander From jan at go6.si Tue Jul 19 11:32:47 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 11:32:47 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> Message-ID: <4E254F3F.3070209@go6.si> On 7/19/11 11:25 AM, Gunter Van de Velde (gvandeve) wrote: > You want to change how IPv6 SLAAC works? And ND? that was my first thought also, but this can't be the idea that Ahmed proposed, it's a bit too far from reality :) Cheers, Jan From gvandeve at cisco.com Tue Jul 19 11:36:30 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 11:36:30 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> Inline: GV> -----Original Message----- From: Sander Steffann [mailto:sander at steffann.nl] Sent: 19 July 2011 11:33 To: Gunter Van de Velde (gvandeve) Cc: Jasper Jans; Ivan Pepelnjak; Jan Zorz @ Go6.si; Yannis Nikolopoulos; ipv6-wg at ripe.net; address-policy-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Hi Gunter, > GV> An issue I see with this policy is that it does not support > pro-active address planning for the longer term and may end up in > fragmented non-summarizable address space within an organization. Mainly > because the newly required address space will be different block and > will as result require new address planning policy within the > organization itself. I don't understand your comment. The idea of the policy proposal is to automatically grow the existing /32 to a /29. That results in a single /29 for an ISP. GV> That would be perfect.. I was just reading the comments sequentially... and just assumed that when an ISP gets through the HD ratio stuff on his first /32, that he will gets the neighbor /32. In that case the ISP needs to make a new address plan policy, which would not be as clean as if he would have had a /31 to start off with. With the /29 there would be no issue at all on this matter. G/ From sander at steffann.nl Tue Jul 19 11:40:09 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 11:40:09 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E254EE1.8080101@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4E254EE1.8080101@go6.si> Message-ID: Hi, > On 7/19/11 11:16 AM, Ahmed Abu-Abed wrote: >> I think we will keep having having these issues until the minimum subnet >> assignment (outside point to point links) can be smaller than /64 which >> is an astronomical waste of public addresses for a home or business >> assignment. > > Maybe it's me, but I really don't understand what are you talking about. > Can you please elaborate a bit on this? Please take this off-list as this is out of scope for RIPE. Thanks :) Sander From jan at go6.si Tue Jul 19 11:42:10 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 11:42:10 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> Message-ID: <4E255172.5040408@go6.si> On 7/19/11 11:36 AM, Gunter Van de Velde (gvandeve) wrote: > GV> That would be perfect.. I was just reading the comments > sequentially... and just assumed that when an ISP gets through the HD > ratio stuff on his first /32, that he will gets the neighbor /32. In > that case the ISP needs to make a new address plan policy, which would > not be as clean as if he would have had a /31 to start off with. With > the /29 there would be no issue at all on this matter. I suspect many LIRs got their /32 just because they could get the allocation and in reality did not have a clue what they really need for deployment and are now stuck with HD ratio. Question for RIPE-NCC staff: do we have any data or estimation/approximation, how many LIRs wanted additional alloc because of this reason and got it with trade? How many are asking for it? Would /29 cover majority of this "trades"? Are there any clueless LIRs, that got /32, but today with presenting real data they would get more than /29? We need some statistics here, if possible. Cheers, Jan From rodolfo.garciapenas at telefonica.es Tue Jul 19 11:42:19 2011 From: rodolfo.garciapenas at telefonica.es (rodolfo.garciapenas at telefonica.es) Date: Tue, 19 Jul 2011 11:42:19 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> Message-ID: Some years ago... in other mail like this... "You want to change how IPv4 routing works? And RIP? http://tools.ietf.org/html/rfc4632 ;-) kix "Gunter Van de Velde (gvandeve)" Para , "RIPE Enviado por: IPv6" ipv6-wg-admin@ cc ripe.net Asunto RE: [ipv6-wg] additional IPv6 19/07/2011 allocation (ripe-512 issues) 11:29 Clasificaci?n You want to change how IPv6 SLAAC works? And ND? G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Ahmed Abu-Abed Sent: 19 July 2011 11:16 To: RIPE IPv6 Cc: address-policy-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) I think we will keep having having these issues until the minimum subnet assignment (outside point to point links) can be smaller than /64 which is an astronomical waste of public addresses for a home or business assignment. This may be too late to fix for the current block of globally routable addresses, but minimum subnet size is worth reconsidering by the IETF for the future blocks. -Ahmed -------------------------------------------------- From: "Jasper Jans" Sent: Tuesday, July 19, 2011 10:38 AM To: "Sander Steffann" ; "Ivan Pepelnjak" Cc: "'Jan Zorz @ Go6.si'" ; "'Yannis Nikolopoulos'" ; ; Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > The RIPE currently reserves a /29 for every initial /32. > So as long as there is a policy that allows expansion of the initial > assignment based upon a sound network design there should not be > any issue to bump it up to a bigger block. > > Jasper > > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Sander Steffann > Sent: Monday, July 18, 2011 5:26 PM > To: Ivan Pepelnjak > Cc: 'Jan Zorz @ Go6.si'; 'Yannis Nikolopoulos'; ipv6-wg at ripe.net; > address-policy-wg at ripe.net > Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > Hi Ivan, > >> Let me try to understand: >> >> (A) We don't disagree that he might actually deserve more than /32 >> (B) According to my understanding of previous discussions I had on this >> topic, RIPE might actually have already reserved extra space for his >> future needs >> (C) According to the current rules he can't get another /32 for a total >> of /31 without using most of the current /32 (and hoping his next /32 >> will be adjacent) >> (D) Someone is seriously suggesting he returns the current /32 and asks >> for a brand new /31 which he will likely get. > > All correct. The current policy doesn't permit the RIPE NCC to give out > extra address space for an existing allocation until the HD ratio has been > reached. They are allowed to give more than a /32 when someone requests a > new allocation though. I have had this same issue and I got the same > answer. > > After reading the policies with this in mind I can only conclude that the > RIPE NCC is implementing the policy correctly. If we want the NCC to do > something else someone has to write a policy proposal. > > Thanks, > Sander > > > > > > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is > op http://www.espritxb.nl/disclaimer > > _____________________________________________________________________ Mensaje analizado y protegido por Telefonica Grandes Clientes From shane at time-travellers.org Tue Jul 19 12:48:09 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 19 Jul 2011 12:48:09 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4E254EE1.8080101@go6.si> Message-ID: <1311072490.1985.5.camel@shane-desktop> [ address-policy-wg trimmed from Cc:] On Tue, 2011-07-19 at 11:40 +0200, Sander Steffann wrote: > > > On 7/19/11 11:16 AM, Ahmed Abu-Abed wrote: > >> I think we will keep having having these issues until the minimum subnet > >> assignment (outside point to point links) can be smaller than /64 which > >> is an astronomical waste of public addresses for a home or business > >> assignment. > > > > Maybe it's me, but I really don't understand what are you talking about. > > Can you please elaborate a bit on this? > > Please take this off-list as this is out of scope for RIPE. Actually, if people want to discuss this on the IPv6 working group list I don't mind. The IPv6 list is quite open for all IPv6-related discussions, whether they are related to RIPE or not. :) Thanks! -- Shane From ahmed at tamkien.com Tue Jul 19 13:10:14 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Tue, 19 Jul 2011 14:10:14 +0300 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E254F3F.3070209@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> Message-ID: <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> Currently the smallest network of physical devices (a home user's subnet) gets the largest block of addresses (/64 in size) from the LIR. There is a logic issue here. Thus we get the need for larger LIR IPv6 allocations. And dependencies on /64 subnets go beyond SLAAC and ND. If/when RIPE has a say on what happens beyond 2000::/3, where /64 subnets are required, then we can come up with ideas on smallest subnet size. Hardware should be sophisticated enough by then to handle such practical needs in case bit alignment is an issue. -Ahmed -------------------------------------------------- From: "Jan Zorz @ go6.si" Sent: Tuesday, July 19, 2011 12:32 PM To: Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > On 7/19/11 11:25 AM, Gunter Van de Velde (gvandeve) wrote: >> You want to change how IPv6 SLAAC works? And ND? > > that was my first thought also, but this can't be the idea that Ahmed > proposed, it's a bit too far from reality :) > > Cheers, Jan > From jan at go6.si Tue Jul 19 13:23:55 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 13:23:55 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> Message-ID: <4E25694B.1090900@go6.si> On 7/19/11 1:10 PM, Ahmed Abu-Abed wrote: > Currently the smallest network of physical devices (a home user's > subnet) gets the largest block of addresses (/64 in size) from the LIR. > There is a logic issue here. > > Thus we get the need for larger LIR IPv6 allocations. And dependencies > on /64 subnets go beyond SLAAC and ND. > > If/when RIPE has a say on what happens beyond 2000::/3, where /64 > subnets are required, then we can come up with ideas on smallest subnet > size. Hardware should be sophisticated enough by then to handle such > practical needs in case bit alignment is an issue. Please, stop here. Do not go any further. We are taking all possible measures to discourage development and deployment of devices and mechanisms that would enable use of prefixes shorter than /64 in one link-layer network. For example with initial /32 you could deploy 6RD in one 6RD domain, but would give to user only one /64. In this case sooner or later the need will emerge to develop something that magically enables you to split /64 to more subnets and actually use that. This is all about adding another layer of complexity and indirection to already messy world. That's one of reasons we are discouraging assignments of /64 to a user. Use /56 or /48 instead and avoid the pain later. Cheers, Jan From sander at steffann.nl Tue Jul 19 13:25:37 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 13:25:37 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <1311072490.1985.5.camel@shane-desktop> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4E254EE1.8080101@go6.si> <1311072490.1985.5.camel@shane-desktop> Message-ID: <72914421-0B20-469E-AD38-24508657391C@steffann.nl> Hi Shane, > Actually, if people want to discuss this on the IPv6 working group list > I don't mind. The IPv6 list is quite open for all IPv6-related > discussions, whether they are related to RIPE or not. :) Sorry, this was meant for APWG, not for IPv6-WG. My apologies! Sander From gvandeve at cisco.com Tue Jul 19 13:25:38 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 13:25:38 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065F24@XMB-AMS-101.cisco.com> I guess there is a IETF requirement that says that SLAAC only works on /64, and same for ND. It is basically an axioma for the RIR to take that into account, as otherwise things will break. Just as Jan mentioned in his main few seconds ago. G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Ahmed Abu-Abed Sent: 19 July 2011 13:10 To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Currently the smallest network of physical devices (a home user's subnet) gets the largest block of addresses (/64 in size) from the LIR. There is a logic issue here. Thus we get the need for larger LIR IPv6 allocations. And dependencies on /64 subnets go beyond SLAAC and ND. If/when RIPE has a say on what happens beyond 2000::/3, where /64 subnets are required, then we can come up with ideas on smallest subnet size. Hardware should be sophisticated enough by then to handle such practical needs in case bit alignment is an issue. -Ahmed -------------------------------------------------- From: "Jan Zorz @ go6.si" Sent: Tuesday, July 19, 2011 12:32 PM To: Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > On 7/19/11 11:25 AM, Gunter Van de Velde (gvandeve) wrote: >> You want to change how IPv6 SLAAC works? And ND? > > that was my first thought also, but this can't be the idea that Ahmed > proposed, it's a bit too far from reality :) > > Cheers, Jan > From sander at steffann.nl Tue Jul 19 13:29:09 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 13:29:09 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> Message-ID: <5146DCDC-5644-4954-AC9C-D3F16A4AE32F@steffann.nl> Hi, > GV> That would be perfect.. I was just reading the comments > sequentially... and just assumed that when an ISP gets through the HD > ratio stuff on his first /32, that he will gets the neighbor /32. In > that case the ISP needs to make a new address plan policy, which would > not be as clean as if he would have had a /31 to start off with. With > the /29 there would be no issue at all on this matter. That is what is happening now. A proposal for changing this is on the way :) Sander From sander at steffann.nl Tue Jul 19 13:30:40 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 19 Jul 2011 13:30:40 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> Message-ID: Hi, >> Some years ago... in other mail like this... "You want to change how IPv4 >> routing works? And RIP? >> >> http://tools.ietf.org/html/rfc4632 ;-) > > That's fine but thats not a function of RIPE but rather 'other places' The RIPE IPv6 WG (ipv6-wg at ripe.net) has volunteered for continuing this discussion :-) Sander From ahmed at tamkien.com Tue Jul 19 13:44:06 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Tue, 19 Jul 2011 14:44:06 +0300 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E25694B.1090900@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> <4E25694B.1090900@go6.si> Message-ID: I am not proposing a change with respect to existing RFCs; we must to live with existing /64 subnets as a minimum allocation. My comments apply for future networks beyond the current 2000::/3 range used by all RIRs. Beyond this range all options are still open. -Ahmed -------------------------------------------------- From: "Jan Zorz @ go6.si" Sent: Tuesday, July 19, 2011 2:23 PM To: Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > On 7/19/11 1:10 PM, Ahmed Abu-Abed wrote: >> Currently the smallest network of physical devices (a home user's >> subnet) gets the largest block of addresses (/64 in size) from the LIR. >> There is a logic issue here. >> >> Thus we get the need for larger LIR IPv6 allocations. And dependencies >> on /64 subnets go beyond SLAAC and ND. >> >> If/when RIPE has a say on what happens beyond 2000::/3, where /64 >> subnets are required, then we can come up with ideas on smallest subnet >> size. Hardware should be sophisticated enough by then to handle such >> practical needs in case bit alignment is an issue. > > Please, stop here. Do not go any further. > > We are taking all possible measures to discourage development and > deployment of devices and mechanisms that would enable use of prefixes > shorter than /64 in one link-layer network. > > For example with initial /32 you could deploy 6RD in one 6RD domain, but > would give to user only one /64. In this case sooner or later the need > will emerge to develop something that magically enables you to split /64 > to more subnets and actually use that. This is all about adding another > layer of complexity and indirection to already messy world. That's one of > reasons we are discouraging assignments of /64 to a user. Use /56 or /48 > instead and avoid the pain later. > > Cheers, Jan > From jan at go6.si Tue Jul 19 14:17:19 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 14:17:19 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> <4E25694B.1090900@go6.si> Message-ID: <4E2575CF.7090509@go6.si> On 7/19/11 1:44 PM, Ahmed Abu-Abed wrote: > I am not proposing a change with respect to existing RFCs; we must to > live with existing /64 subnets as a minimum allocation. > > My comments apply for future networks beyond the current 2000::/3 range > used by all RIRs. Beyond this range all options are still open. I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3 Why do you think ND and SLAAC would behave differently in 4000::/3 ? Cheers, Jan From gvandeve at cisco.com Tue Jul 19 14:25:46 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 14:25:46 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2575CF.7090509@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> <4E25694B.1090900@go6.si> <4E2575CF.7090509@go6.si> Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065F66@XMB-AMS-101.cisco.com> Why do you think ND and SLAAC would behave differently in 4000::/3 ? GV> I know just like you it is farfetched, but why not? GV> it just takes somebody to rewrite all ND, SLAAC, DHCP, etc... :-) G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: 19 July 2011 14:17 To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) On 7/19/11 1:44 PM, Ahmed Abu-Abed wrote: > I am not proposing a change with respect to existing RFCs; we must to > live with existing /64 subnets as a minimum allocation. > > My comments apply for future networks beyond the current 2000::/3 range > used by all RIRs. Beyond this range all options are still open. I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3 Why do you think ND and SLAAC would behave differently in 4000::/3 ? Cheers, Jan From marc.blanchet at viagenie.ca Tue Jul 19 14:30:09 2011 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Tue, 19 Jul 2011 08:30:09 -0400 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2575CF.7090509@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> <4E25694B.1090900@go6.si> <4E2575CF.7090509@go6.si> Message-ID: <4E2578D1.5090203@viagenie.ca> Le 11-07-19 08:17, Jan Zorz @ go6.si a ?crit : > On 7/19/11 1:44 PM, Ahmed Abu-Abed wrote: >> I am not proposing a change with respect to existing RFCs; we must to >> live with existing /64 subnets as a minimum allocation. >> >> My comments apply for future networks beyond the current 2000::/3 range >> used by all RIRs. Beyond this range all options are still open. > > I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3 > > Why do you think ND and SLAAC would behave differently in 4000::/3 ? > I think Ahmed is referring to: Future specifications may redefine one or more sub-ranges of the Global Unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as Global Unicast addresses. > Cheers, Jan -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From jan at go6.si Tue Jul 19 14:50:47 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 14:50:47 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065F66@XMB-AMS-101.cisco.com> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> <4E25694B.1090900@go6.si> <4E2575CF.7090509@go6.si> <4269EA985EACD24987D82DAE2FEC62E504065F66@XMB-AMS-101.cisco.com> Message-ID: <4E257DA7.6010905@go6.si> On 7/19/11 2:25 PM, Gunter Van de Velde (gvandeve) wrote: > Why do you think ND and SLAAC would behave differently in 4000::/3 ? > > GV> I know just like you it is farfetched, but why not? > GV> it just takes somebody to rewrite all ND, SLAAC, DHCP, etc... :-) ...and have two incompatible protocols in different parts of the same numbering space (::/0), that probably could not even talk to each other. Brilliant. :) /jan From slz at baycix.de Tue Jul 19 14:33:35 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 19 Jul 2011 14:33:35 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2575CF.7090509@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <4E254F3F.3070209@go6.si> <7971CC1F3F1541819FD31DE92CC44E91@mTOSH> <4E25694B.1090900@go6.si> <4E2575CF.7090509@go6.si> Message-ID: <0692B688-66A5-4BE1-B738-B39F75A42519@baycix.de> Hi, > >> I am not proposing a change with respect to existing RFCs; we must to >> live with existing /64 subnets as a minimum allocation. >> >> My comments apply for future networks beyond the current 2000::/3 range >> used by all RIRs. Beyond this range all options are still open. > > I don't think so. IPv6 as protocol applies over all ::/0, not only 2000::/3 > > Why do you think ND and SLAAC would behave differently in 4000::/3 ? indeed. That would be weird and cause all kinds of operational problems. But more importantly - why at all? It's not a waste of addresses, this has been discussed 68060 times on various mailinglists and at other places. The usual answer to such statements simply is "do the math!", for a reason. There are some issues with /64 default segments, like it causes some possible attack vectors on the infrastructure, but there are no issues with the size itself compared to the 128bit we have. So, "do the math!" :-) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From ip at ioshints.info Tue Jul 19 15:22:13 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 19 Jul 2011 15:22:13 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> Message-ID: <002301cc4616$e168d330$a43a7990$@info> Don't pull ND into this discussion. How do you make subnets smaller than /64 work on Ethernet links between Cisco routers? SLAAC does depend on /64. > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Gunter Van de Velde (gvandeve) > Sent: Tuesday, July 19, 2011 11:26 AM > To: Ahmed Abu-Abed; RIPE IPv6 > Cc: address-policy-wg at ripe.net > Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > You want to change how IPv6 SLAAC works? And ND? > > G/ From jan at go6.si Tue Jul 19 15:29:19 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 15:29:19 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <002301cc4616$e168d330$a43a7990$@info> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <88CAD6DE69B1436F9CA91BC0DE1CA956@mTOSH> <4269EA985EACD24987D82DAE2FEC62E504065E89@XMB-AMS-101.cisco.com> <002301cc4616$e168d330$a43a7990$@info> Message-ID: <4E2586AF.7090403@go6.si> On 7/19/11 3:22 PM, Ivan Pepelnjak wrote: > Don't pull ND into this discussion. How do you make subnets smaller > than /64 work on Ethernet links between Cisco routers? > > SLAAC does depend on /64. Discussion was end user assignments, not r2r connection segments. jan From rodolfo.garciapenas at telefonica.es Tue Jul 19 15:46:48 2011 From: rodolfo.garciapenas at telefonica.es (rodolfo.garciapenas at telefonica.es) Date: Tue, 19 Jul 2011 15:46:48 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2586AF.7090403@go6.si> Message-ID: ipv6-wg-admin at ripe.net escribi? el 19/07/2011 15:29:19: > On 7/19/11 3:22 PM, Ivan Pepelnjak wrote: > > Don't pull ND into this discussion. How do you make subnets smaller > > than /64 work on Ethernet links between Cisco routers? > > > > SLAAC does depend on /64. > > Discussion was end user assignments, not r2r connection segments. IMHO, the remote router could be the customer xDSL router. And you need a */64* for the link. http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6-for-LIRs-Training-Slides.pdf (page 65) > jan > From andrea at ripe.net Tue Jul 19 16:23:05 2011 From: andrea at ripe.net (Andrea Cima) Date: Tue, 19 Jul 2011 16:23:05 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E255172.5040408@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> Message-ID: <4E259349.1030601@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, Jan Zorz @ go6.si wrote: > On 7/19/11 11:36 AM, Gunter Van de Velde (gvandeve) wrote: >> GV> That would be perfect.. I was just reading the comments >> sequentially... and just assumed that when an ISP gets through the HD >> ratio stuff on his first /32, that he will gets the neighbor /32. In >> that case the ISP needs to make a new address plan policy, which would >> not be as clean as if he would have had a /31 to start off with. With >> the /29 there would be no issue at all on this matter. > > I suspect many LIRs got their /32 just because they could get the > allocation and in reality did not have a clue what they really need for > deployment and are now stuck with HD ratio. > > Question for RIPE-NCC staff: do we have any data or > estimation/approximation, how many LIRs wanted additional alloc because > of this reason and got it with trade? 1 LIR has been able to justify an expansion of their initial /32 (back in 2004). 15 LIRs gave back their initially requested /32 in exchange for a larger allocation. Furthermore 23 LIRs got a first allocation larger than /32. > How many are asking for it? Just a handful. > Would /29 cover majority of this "trades"? Out of the 15 cases mentioned above only 1 would have fitted in a /29. All the other allocation were much larger. > Are there any clueless LIRs, that got /32, but today with presenting > real data they would get more than /29? We can not see how many LIRs would now get a larger allocation as it depends on data that we do not have (assignment size - /48 or /64?, number of customers, growth etc). However when we receive a /32 allocation request, and it's clear that the LIR will need more than a /32 based on the information they provide, we advise the LIR about the fact that the requested amount may not be covering their current needs. I hope this helps Best regards Andrea Cima RIPE NCC > We need some statistics here, if possible. > > Cheers, Jan > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4lk0kACgkQXOgsmPkFrjPGXgCfdCviOSBkfjxWV/lFZYKpjDlf R2QAoJLHylcsqAgKqNV7EVS/TwacKlI9 =Mu0L -----END PGP SIGNATURE----- From jan at go6.si Tue Jul 19 18:49:32 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 18:49:32 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <002d01cc4633$39064390$ab12cab0$@com> References: <4E2586AF.7090403@go6.si> <002d01cc4633$39064390$ab12cab0$@com> Message-ID: <4E25B59C.2040507@go6.si> On 7/19/11 6:45 PM, Ivan Pepelnjak wrote: > No, you don't. The only protocol that needs /64 is SLAAC. > > /64 on the connection is a __BEST PRACTICE__ (allowing CPE router to use SLAAC), no more, no less. Exactly. And I see no point in changing that. To be perfectly honest, you could use link-local for CPE to core communication, but that's another discussion. What we are trying to prevent is ISPs assigning /64 as PD to customers instead of /56 or /48. /jan From brandon.daly at zeninternet.co.uk Tue Jul 19 19:07:03 2011 From: brandon.daly at zeninternet.co.uk (Brandon Daly) Date: Tue, 19 Jul 2011 17:07:03 +0000 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> Message-ID: Hi, My understanding based on conversations with RIPE NCC is slightly different. The initial allocation is made based purely on number of subscribers, and does not take HD ratio into account. (I argued this extensively when applying for our initial allocation). This is more restrictive than the policies for obtaining an additional allocation. Bran. >Hi Ivan, > >> Let me try to understand: >> >> (A) We don't disagree that he might actually deserve more than /32 >> (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space >for his future needs >> (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his >next /32 will be adjacent) >> (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. > >All correct. The current policy doesn't permit the RIPE NCC to give out extra address space for an existing allocation until the HD ratio >has been reached. They are allowed to give more than a /32 when someone requests a new allocation though. I have had this same issue and >I got the same answer. > >After reading the policies with this in mind I can only conclude that the RIPE NCC is implementing the policy correctly. If we want the >NCC to do something else someone has to write a policy proposal. > >Thanks, >Sander -- Brandon Daly Network Engineer, Zen Internet T: 0845 058 9030 F: 0845 058 9005 W: www.zen.co.uk Visit our new and improved Help & Support site - www.zen.co.uk/support A wealth of information from updating your contact details or tracking the status of your order to setting up a wireless network or configuring email accounts. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Zen Internet Limited may monitor email traffic data and also the content of email for the purposes of security. Zen Internet Limited is registered in England and Wales, Sandbrook Park, Sandbrook Way, Rochdale, OL11 1RY Company No. 03101568 VAT Reg No. 686 0495 01 From ipepelnjak at gmail.com Tue Jul 19 18:45:07 2011 From: ipepelnjak at gmail.com (Ivan Pepelnjak) Date: Tue, 19 Jul 2011 18:45:07 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: <4E2586AF.7090403@go6.si> Message-ID: <002d01cc4633$39064390$ab12cab0$@com> No, you don't. The only protocol that needs /64 is SLAAC. /64 on the connection is a __BEST PRACTICE__ (allowing CPE router to use SLAAC), no more, no less. > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > rodolfo.garciapenas at telefonica.es > > > On 7/19/11 3:22 PM, Ivan Pepelnjak wrote: > > > Don't pull ND into this discussion. How do you make subnets smaller > > > than /64 work on Ethernet links between Cisco routers? > > > > > > SLAAC does depend on /64. > > > > Discussion was end user assignments, not r2r connection segments. > > IMHO, the remote router could be the customer xDSL router. And you need a > */64* for the link. From gert at space.net Tue Jul 19 21:26:39 2011 From: gert at space.net (Gert Doering) Date: Tue, 19 Jul 2011 21:26:39 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <3C86EA27-CF05-48A3-922B-36874568BB37@virtualized.org> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <3C86EA27-CF05-48A3-922B-36874568BB37@virtualized.org> Message-ID: <20110719192639.GC2304@Space.Net> Hi, On Tue, Jul 19, 2011 at 07:55:20AM -1000, David Conrad wrote: > On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote: > > The RIPE currently reserves a /29 for every initial /32. > > Is this really true? When the RIRs and IANA were discussing the /12 > allocations, the RIRs claimed one of the reasons they needed /12s was > because they would all be using the "bisection method" of allocation to > remove the need for reservation. Well, how memories change. I seem to remember that I lobbied for /12s (or bigger) because allocations of one-/23-at-a-time were just a stupid and human life-time wasting way to handle things... ("The IPv4 Way"). gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From drc at virtualized.org Tue Jul 19 19:55:20 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Jul 2011 07:55:20 -1000 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> Message-ID: <3C86EA27-CF05-48A3-922B-36874568BB37@virtualized.org> On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote: > The RIPE currently reserves a /29 for every initial /32. Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through. Regards, -drc From rodolfo.garciapenas at telefonica.es Wed Jul 20 10:19:05 2011 From: rodolfo.garciapenas at telefonica.es (rodolfo.garciapenas at telefonica.es) Date: Wed, 20 Jul 2011 10:19:05 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <3C86EA27-CF05-48A3-922B-36874568BB37@virtualized.org> Message-ID: Download the "delegated-ripencc-extended-*" file from http://albatross.ripe.net/delegated-extended/ cat delegated-ripencc-extended-20110718 | grep ipv6 | cut -d\| -f4,5,7 | sort | more *|19392 2001:1400::|32|allocated 2001:1401::|32|available 2001:1402::|31|available 2001:1404::|30|available 2001:1408::|32|allocated 2001:1409::|32|available 2001:140a::|31|available 2001:140c::|30|available 2001:1410::|32|allocated 2001:1411::|32|available 2001:1412::|31|available 2001:1414::|30|available 2001:1418::|32|allocated 2001:1419::|32|available 2001:141a::|31|available 2001:141c::|30|available 2001:1420::|32|allocated kix David Conrad Para Enviado por: Jasper Jans ipv6-wg-admin@ ripe.net cc ipv6-wg at ripe.net, "address-policy-wg at ripe.net 20/07/2011 Working Group" 10:09 Asunto Re: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) Clasificaci?n On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote: > The RIPE currently reserves a /29 for every initial /32. Is this really true? When the RIRs and IANA were discussing the /12 allocations, the RIRs claimed one of the reasons they needed /12s was because they would all be using the "bisection method" of allocation to remove the need for reservation. It would be sad to hear RIPE still hadn't followed through. Regards, -drc _____________________________________________________________________ Mensaje analizado y protegido por Telefonica Grandes Clientes From paul at meanie.nl Wed Jul 20 10:36:23 2011 From: paul at meanie.nl (Paul Hoogsteder) Date: Wed, 20 Jul 2011 10:36:23 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: References: Message-ID: <64b6692a2f5647ece43414dcccbebff4.squirrel@webmail.prolocation.net> It looks like RIPE NCC does the same thing (assigning 1 block and "reserving" the next three) with IPv6 PI blocks: ripencc|CZ|ipv6|2001:67c:22d0::|48|20110531|assigned ripencc|EU|ipv6|2001:67c:22d4::|48|20110531|assigned ripencc|SI|ipv6|2001:67c:22d8::|48|20110601|assigned ripencc|NL|ipv6|2001:67c:22dc::|48|20110601|assigned Best regards, Paul Hoogsteder Breedband Delft/Meanie > Download the "delegated-ripencc-extended-*" file from > http://albatross.ripe.net/delegated-extended/ > > cat delegated-ripencc-extended-20110718 | grep ipv6 | cut -d\| -f4,5,7 | > sort | more > *|19392 > 2001:1400::|32|allocated > 2001:1401::|32|available > 2001:1402::|31|available > 2001:1404::|30|available > 2001:1408::|32|allocated > 2001:1409::|32|available > 2001:140a::|31|available > 2001:140c::|30|available > 2001:1410::|32|allocated > 2001:1411::|32|available > 2001:1412::|31|available > 2001:1414::|30|available > 2001:1418::|32|allocated > 2001:1419::|32|available > 2001:141a::|31|available > 2001:141c::|30|available > 2001:1420::|32|allocated > > kix > > > > > David Conrad > ed.org> Para > Enviado por: Jasper Jans > ipv6-wg-admin@ > ripe.net cc > ipv6-wg at ripe.net, > "address-policy-wg at ripe.net > 20/07/2011 Working Group" > 10:09 > Asunto > Re: [address-policy-wg] RE: > [ipv6-wg] additional IPv6 > allocation (ripe-512 issues) > Clasificaci?n > > > > > > > > > > > > On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote: >> The RIPE currently reserves a /29 for every initial /32. > > Is this really true? When the RIRs and IANA were discussing the /12 > allocations, the RIRs claimed one of the reasons they needed /12s was > because they would all be using the "bisection method" of allocation to > remove the need for reservation. It would be sad to hear RIPE still hadn't > followed through. > > Regards, > -drc > > _____________________________________________________________________ > Mensaje analizado y protegido por Telefonica Grandes Clientes > > > > From jan at go6.si Wed Jul 20 11:06:04 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 20 Jul 2011 11:06:04 +0200 Subject: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E259349.1030601@ripe.net> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> Message-ID: <4E269A7C.8010404@go6.si> On 7/19/11 4:23 PM, Andrea Cima wrote: >> Would /29 cover majority of this "trades"? > > Out of the 15 cases mentioned above only 1 would have fitted in a /29. > All the other allocation were much larger. Andrea, hi Thnx for the data. This one is interesting, but still not sure what it says to us. From my understanding, I would say that those who are really big and got /32 initial alloc goes and make an effort to trade-in /32 and "fight" for something big. It's a matter of "is it worth the effort?" decision - and get something larger than /29 Is it worth the effort for /31 or /30? Or they rather call the wizards to fit their networking plans into /32 and use HD ratio later? My question is, do we fix some/any of this guys with /29 min. alloc.? > >> Are there any clueless LIRs, that got /32, but today with presenting >> real data they would get more than /29? > > We can not see how many LIRs would now get a larger allocation as it > depends on data that we do not have (assignment size - /48 or /64?, > number of customers, growth etc). However when we receive a /32 > allocation request, and it's clear that the LIR will need more than a > /32 based on the information they provide, we advise the LIR about the > fact that the requested amount may not be covering their current needs. So, you look into IPv4 data to determine the size of LIR? Thnx for info, very usefull. Cheers, Jan Zorz From ahmed at tamkien.com Wed Jul 20 14:42:32 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Wed, 20 Jul 2011 15:42:32 +0300 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs Message-ID: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> Hello All, Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs do not support IPSEC to keep the costs down. Regards, -Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea at ripe.net Wed Jul 20 15:10:57 2011 From: andrea at ripe.net (Andrea Cima) Date: Wed, 20 Jul 2011 15:10:57 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E269A7C.8010404@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> Message-ID: <4E26D3E1.1020302@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, Jan Zorz @ go6.si wrote: > On 7/19/11 4:23 PM, Andrea Cima wrote: >>> Would /29 cover majority of this "trades"? >> >> Out of the 15 cases mentioned above only 1 would have fitted in a /29. >> All the other allocation were much larger. > > Andrea, hi > > Thnx for the data. This one is interesting, but still not sure what it > says to us. > > > From my understanding, I would say that those who are really big and got > /32 initial alloc goes and make an effort to trade-in /32 and "fight" > for something big. It's a matter of "is it worth the effort?" decision - > and get something larger than /29 > > Is it worth the effort for /31 or /30? Or they rather call the wizards > to fit their networking plans into /32 and use HD ratio later? > > > My question is, do we fix some/any of this guys with /29 min. alloc.? According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32. Best regards, Andrea Cima RIPE NCC >> >>> Are there any clueless LIRs, that got /32, but today with presenting >>> real data they would get more than /29? >> >> We can not see how many LIRs would now get a larger allocation as it >> depends on data that we do not have (assignment size - /48 or /64?, >> number of customers, growth etc). However when we receive a /32 >> allocation request, and it's clear that the LIR will need more than a >> /32 based on the information they provide, we advise the LIR about the >> fact that the requested amount may not be covering their current needs. > > So, you look into IPv4 data to determine the size of LIR? > > Thnx for info, very usefull. > > Cheers, Jan Zorz > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4m0+EACgkQXOgsmPkFrjOgswCgn/eC9fQWxWQ2izaD/jymUYyL 9ZoAniUUcCpGEJe2qE/AXodaOJnAJcDO =gdu7 -----END PGP SIGNATURE----- From jan at go6.si Wed Jul 20 18:35:34 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 20 Jul 2011 18:35:34 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> Message-ID: <4E2703D6.6010407@go6.si> On 7/20/11 2:42 PM, Ahmed Abu-Abed wrote: > Hello All, > Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are > mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs > do not support IPSEC to keep the costs down. > Regards, > -Ahmed Yes, host must support this. CPE not necessarily, that's why it's under optional requirements. Cheers, Jan From ip at ioshints.info Wed Jul 20 18:40:30 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 20 Jul 2011 18:40:30 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E2703D6.6010407@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> Message-ID: <006201cc46fb$becddd80$3c699880$@info> Don't forget that although IPsec is part of IPv6 functionality, supporting null encapsulation (whatever it's properly called ;) and no authentication or encryption protocol also makes you compliant. We might make it optional ;) Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jan Zorz @ go6.si > Sent: Wednesday, July 20, 2011 6:36 PM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE-501 and IPSEC on CPEs > > On 7/20/11 2:42 PM, Ahmed Abu-Abed wrote: > > Hello All, > > Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are > > mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs > > do not support IPSEC to keep the costs down. > > Regards, > > -Ahmed > > Yes, host must support this. CPE not necessarily, that's why it's under > optional requirements. > > Cheers, Jan From leo.vegoda at icann.org Wed Jul 20 18:30:50 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Jul 2011 09:30:50 -0700 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E26D3E1.1020302@ripe.net> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> <4E26D3E1.1020302@ripe.net> Message-ID: <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> Hi Andrea, Your wrote: > According to our experience only LIRs that needed a block much larger > than /29 found it worth the effort to return their /32. I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? Thanks, Leo Vegoda From jan at go6.si Wed Jul 20 18:49:48 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 20 Jul 2011 18:49:48 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> <4E26D3E1.1020302@ripe.net> <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> Message-ID: <4E27072C.20901@go6.si> On 7/20/11 6:30 PM, Leo Vegoda wrote: > Hi Andrea, > > Your wrote: > >> According to our experience only LIRs that needed a block much >> larger than /29 found it worth the effort to return their /32. > > I don't know how I should understand you statement. Should I take it > to mean that the policy is impeding LIRs who would otherwise qualify > for larger allocations from getting them because they will have to > renumber their whole network? Or something else? Idea... If you are LIR that had no clue and got /32 but now when you know that you need more and can justify that, you could ask RIPE-NCC IPRA to get back your original /32, start looking into your justification under initial alloc policy and if you justify for anything up to (including) /29, IPRA allocates you justified block starting exactly where "returned" /32 started. Problem solved, no need to renumber. Do we need to put this into policy (if accepted) or would BCP work (as this can be best current practice :) )? Cheers, Jan Zorz From merike at doubleshotsecurity.com Wed Jul 20 19:47:58 2011 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Wed, 20 Jul 2011 10:47:58 -0700 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <006201cc46fb$becddd80$3c699880$@info> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> Message-ID: <0A81C6EF-87F7-45D2-A523-6870EC209274@doubleshotsecurity.com> ESP-NULL.....which means that you do use an integrity crypto algorithm such as SHA-1, SHA256, MD5, etc The Node Requirements bis doc is reaching finalization in the IETF and has changed IPsec from a MUST to a SHOULD: "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently the default automated key management protocol to implement is IKEv2. As required in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST implement ESP [RFC4303] and MAY implement AH [RFC4302]." It may make sense to change IPsec to 'optional' (I can't believe I am saying this :)). - merike On Jul 20, 2011, at 9:40 AM, Ivan Pepelnjak wrote: > Don't forget that although IPsec is part of IPv6 functionality, supporting null encapsulation (whatever it's properly called ;) and no authentication or encryption protocol also makes you compliant. > > We might make it optional ;) > Ivan > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> Jan Zorz @ go6.si >> Sent: Wednesday, July 20, 2011 6:36 PM >> To: ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] RIPE-501 and IPSEC on CPEs >> >> On 7/20/11 2:42 PM, Ahmed Abu-Abed wrote: >>> Hello All, >>> Reading RIPE-501 spec for basic CPEs, I see that IPSEC & IKE are >>> mandatory under "host" equipment. Is this a necessity ? Many IPv4 CPEs >>> do not support IPSEC to keep the costs down. >>> Regards, >>> -Ahmed >> >> Yes, host must support this. CPE not necessarily, that's why it's under >> optional requirements. >> >> Cheers, Jan > > From spz at serpens.de Wed Jul 20 20:05:14 2011 From: spz at serpens.de (S.P.Zeidler) Date: Wed, 20 Jul 2011 20:05:14 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <006201cc46fb$becddd80$3c699880$@info> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> Message-ID: <20110720180513.GH9874@serpens.de> Thus wrote Ivan Pepelnjak (ip at ioshints.info): > Don't forget that although IPsec is part of IPv6 functionality, supporting null encapsulation (whatever it's properly called ;) and no authentication or encryption protocol also makes you compliant. > > We might make it optional ;) Do we -want- to make it optional? I'd call that a step backwards. The list is not so that every last ratty device someone dragged off their junk heap can fulfil it, after all. regards, spz -- spz at serpens.de (S.P.Zeidler) From jan at go6.si Wed Jul 20 20:54:17 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 20 Jul 2011 20:54:17 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <20110720180513.GH9874@serpens.de> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> Message-ID: <4E272459.5070301@go6.si> On 7/20/11 8:05 PM, S.P.Zeidler wrote: > Do we -want- to make it optional? I'd call that a step backwards. > The list is not so that every last ratty device someone dragged off their > junk heap can fulfil it, after all. I feel to agree with this statement... what percentage of CPEs we "throw out" if we make this optional? cheers, jan From merike at doubleshotsecurity.com Wed Jul 20 21:16:41 2011 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Wed, 20 Jul 2011 12:16:41 -0700 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E272459.5070301@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> Message-ID: <85EB6273-827C-4CFD-8A27-84C7BEF755BD@doubleshotsecurity.com> On Jul 20, 2011, at 11:54 AM, Jan Zorz @ go6.si wrote: > On 7/20/11 8:05 PM, S.P.Zeidler wrote: >> Do we -want- to make it optional? I'd call that a step backwards. >> The list is not so that every last ratty device someone dragged off their >> junk heap can fulfil it, after all. > > I feel to agree with this statement... > > what percentage of CPEs we "throw out" if we make this optional? You mean mandatory requirement for IPsec right? How many CPEs would not be compliant if we kept it a mandatory requirement to implement IPsec? While I am a huge proponent of IPsec, I have seen so many TLS implementations take over and more are getting standardized that I am left wondering whether mandating IPsec on paper makes sense realistically. I have zero issues with keeping IPsec as mandatory for hosts but want to play devils advocate for a minute. - merike From drc at virtualized.org Wed Jul 20 21:16:06 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 20 Jul 2011 09:16:06 -1000 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <20110719192639.GC2304@Space.Net> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <3C86EA27-CF05-48A3-922B-36874568BB37@virtualized.org> <20110719192639.GC2304@Space.Net> Message-ID: <6DDC0B40-8BC1-411E-A59A-4CE10F323248@virtualized.org> On Jul 19, 2011, at 9:26 AM, Gert Doering wrote: > On Tue, Jul 19, 2011 at 07:55:20AM -1000, David Conrad wrote: >> On Jul 18, 2011, at 9:38 PM, Jasper Jans wrote: >>> The RIPE currently reserves a /29 for every initial /32. >> >> Is this really true? When the RIRs and IANA were discussing the /12 >> allocations, the RIRs claimed one of the reasons they needed /12s was >> because they would all be using the "bisection method" of allocation to >> remove the need for reservation. > > Well, how memories change. ? > I seem to remember that I lobbied for /12s > (or bigger) because allocations of one-/23-at-a-time were just a stupid > and human life-time wasting way to handle things... ("The IPv4 Way"). "One of the reasons". Regards, -drc From jan at pragma.si Wed Jul 20 23:48:32 2011 From: jan at pragma.si (Jan Zorz) Date: Wed, 20 Jul 2011 23:48:32 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E272459.5070301@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> Message-ID: <4E274D30.3000103@pragma.si> On 7/20/11 8:54 PM, Jan Zorz @ go6.si wrote: > I feel to agree with this statement... > > what percentage of CPEs we "throw out" if we make this optional? sorry, mandatory, not optional. typo. so, what percentage of CPEs we "throw out" if we make this mandatory? cheers, Jan From jan at go6.si Thu Jul 21 10:20:12 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 21 Jul 2011 10:20:12 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E27072C.20901@go6.si> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> <4E26D3E1.1020302@ripe.net> <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> <4E27072C.20901@go6.si> Message-ID: <4E27E13C.6020203@go6.si> On 7/20/11 6:49 PM, Jan Zorz @ go6.si wrote: > Idea... > > If you are LIR that had no clue and got /32 but now when you know that > you need more and can justify that, you could ask RIPE-NCC IPRA to get > back your original /32, start looking into your justification under > initial alloc policy and if you justify for anything up to (including) > /29, IPRA allocates you justified block starting exactly where > "returned" /32 started. > > Problem solved, no need to renumber. > > Do we need to put this into policy (if accepted) or would BCP work (as > this can be best current practice :) )? ...of course if /29 minimum initial allocation policy proposal change fails... (forgot to mention). jan From ahmed at tamkien.com Thu Jul 21 12:28:03 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Thu, 21 Jul 2011 13:28:03 +0300 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E274D30.3000103@pragma.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> Message-ID: I believe implementing line rate IPSEC on a CPE requires silicon that accelerates the crypto algorithms, and this may be a good feature but is outside the budget of most consumers who don't need much beyond SSL/TLS embedded in their HTTP client. So making IPSEC optional is more practical to LIRs needing low cost CPE solutions. And to answer the question below, I know one low cost IPv6 CPE vendor on RIPE's CPE Survey who doesn't support IPSEC, but haven't checked them all. -Ahmed -------------------------------------------------- From: "Jan Zorz" Sent: Thursday, July 21, 2011 12:48 AM To: Subject: Re: [ipv6-wg] RIPE-501 and IPSEC on CPEs > On 7/20/11 8:54 PM, Jan Zorz @ go6.si wrote: >> I feel to agree with this statement... >> >> what percentage of CPEs we "throw out" if we make this optional? > sorry, mandatory, not optional. typo. > > so, what percentage of CPEs we "throw out" if we make this mandatory? > > cheers, Jan > From andrea at ripe.net Thu Jul 21 13:55:54 2011 From: andrea at ripe.net (Andrea Cima) Date: Thu, 21 Jul 2011 13:55:54 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> <4E26D3E1.1020302@ripe.net> <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> Message-ID: <4E2813CA.3060408@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Leo, Leo Vegoda wrote: > Hi Andrea, > > Your wrote: > >> According to our experience only LIRs that needed a block much larger >> than /29 found it worth the effort to return their /32. > > I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? There are a number of LIRs who received a /32 in the past who later realise that they might have qualified for a larger initial allocation. We allow these LIRs to return their /32 and then evaluate their request based on the data they submit. In the case that these LIRs do not want to return that /32, the normal IPv6 additional allocation policy applies and we will allocate them more space if and when they qualify under that policy. In practice this means that their existing /32 has to be used up to the HD-ratio. We presented this at RIPE 62 in the 'Feedback from RIPE NCC Registration Services'. http://ripe62.ripe.net/programme/meeting-plan/address-policy Best regards, Andrea Cima RIPE NCC > Thanks, > > Leo Vegoda -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4oE8oACgkQXOgsmPkFrjNhKACfW/hAMDns051ma1PQPyWnLHIF jgEAn1MFUD0I1HBPJztZ63OWDimcuwNV =+Zrx -----END PGP SIGNATURE----- From jan at go6.si Thu Jul 21 14:35:35 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 21 Jul 2011 14:35:35 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> Message-ID: <4E281D17.1000705@go6.si> On 7/21/11 12:28 PM, Ahmed Abu-Abed wrote: > I believe implementing line rate IPSEC on a CPE requires silicon that > accelerates the crypto algorithms, and this may be a good feature but > is outside the budget of most consumers who don't need much beyond > SSL/TLS embedded in their HTTP client. > > So making IPSEC optional is more practical to LIRs needing low cost > CPE solutions. > > And to answer the question below, I know one low cost IPv6 CPE vendor > on RIPE's CPE Survey who doesn't support IPSEC, but haven't checked > them all. Hmm, how to promote ipsec and security and not discriminate too many devices at same time? Should we move IPSEC and all that security stuff under mandatory and pre-pend it with "If ipsec (or whatever fits) is requested, then ...... is required. Would that work? Cheers, Jan From leo.vegoda at icann.org Thu Jul 21 18:15:51 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 21 Jul 2011 09:15:51 -0700 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E2813CA.3060408@ripe.net> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> <4E26D3E1.1020302@ripe.net> <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> <4E2813CA.3060408@ripe.net> Message-ID: <05B243F724B2284986522B6ACD0504D7010AC7A77F52@EXVPMBX100-1.exc.icann.org> Hi Andrea, [...] > >> According to our experience only LIRs that needed a block much larger > >> than /29 found it worth the effort to return their /32. > > > > I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? > > There are a number of LIRs who received a /32 in the past who later > realise that they might have qualified for a larger initial allocation. > We allow these LIRs to return their /32 and then evaluate their request > based on the data they submit. In the event that the LIR plans to qualify for an allocation that will fit inside the /29 you have reserved for them, do you allow them to receive a block from the same /29? That is, do you allow them to do the "return and new initial allocation" as a book keeping exercise or will they normally need to renumber? Thanks, Leo From jan at go6.si Fri Jul 22 10:02:12 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 22 Jul 2011 10:02:12 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 Message-ID: <4E292E84.9080204@go6.si> Hi, Please find attached document with many ideas and suggestions included, LB spec is also there. As usual, all comments warmly welcome. Cheers, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: Requirements-for-IPv6-in-ICT-equipment-v.2.pdf Type: application/pdf Size: 330593 bytes Desc: not available URL: From marcoh at marcoh.net Fri Jul 22 11:10:27 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 22 Jul 2011 11:10:27 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E292E84.9080204@go6.si> References: <4E292E84.9080204@go6.si> Message-ID: <221EA157-F2EE-4200-81C6-B4073FC1FA86@marcoh.net> On 22 jul 2011, at 10:02, Jan Zorz @ go6.si wrote: > Hi, > > Please find attached document with many ideas and suggestions included, LB spec is also there. > > As usual, all comments warmly welcome. > > Cheers, Jan > As a small request, can people please post plain text only documents to this list. Makes it much easier to track comments and feedback. Thanks, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" From andrea at ripe.net Fri Jul 22 14:20:42 2011 From: andrea at ripe.net (Andrea Cima) Date: Fri, 22 Jul 2011 14:20:42 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <05B243F724B2284986522B6ACD0504D7010AC7A77F52@EXVPMBX100-1.exc.icann.org> References: <4E242EEA.40009@otenet.gr> <0E7D664A-A160-47C4-9E72-09B455B002B4@steffann.nl> <9bb26a3b-37a0-4aff-80a6-43aba39f2a8a@email.android.com> <003f01cc4557$664d6040$32e820c0$@com> <004801cc455e$5d0039c0$1700ad40$@info> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4269EA985EACD24987D82DAE2FEC62E504065E86@XMB-AMS-101.cisco.com> <5B19D8DB-317C-4ACC-B6BB-62432A9B8B3E@steffann.nl> <4269EA985EACD24987D82DAE2FEC62E504065E98@XMB-AMS-101.cisco.com> <4E255172.5040408@go6.si> <4E259349.1030601@ripe.net> <4E269A7C.8010404@go6.si> <4E26D3E1.1020302@ripe.net> <05B243F724B2284986522B6ACD0504D7010AC7A77DBD@EXVPMBX100-1.exc.icann.org> <4E2813CA.3060408@ripe.net> <05B243F724B2284986522B6ACD0504D7010AC7A77F52@EXVPMBX100-1.exc.icann.org> Message-ID: <4E296B1A.3050306@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Leo, Leo Vegoda wrote: > Hi Andrea, > > [...] > >>>> According to our experience only LIRs that needed a block much larger >>>> than /29 found it worth the effort to return their /32. >>> I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? >> There are a number of LIRs who received a /32 in the past who later >> realise that they might have qualified for a larger initial allocation. >> We allow these LIRs to return their /32 and then evaluate their request >> based on the data they submit. > > In the event that the LIR plans to qualify for an allocation that will fit inside the /29 you have reserved for them, do you allow them to receive a block from the same /29? That is, do you allow them to do the "return and new initial allocation" as a book keeping exercise or will they normally need to renumber? We treat "return and new initial allocation" the same as a normal initial allocation request. This includes, as with all initial allocation requests, reserving space for future growth, in the past by reserving three bits and currently using the binary chop algorithm. Simply expanding an LIR's current allocation would constitute an additional allocation and would follow the established additional allocation policy and procedure and would require the LIR to demonstrate that they have utilised their current allocation up to the threshold defined by the HD-ratio. Should it turn out that an LIR who received a /32 since the implementation of the binary chop algorithm would have qualified for a larger allocation, we could consider allocating the "new" larger block overlapping with their /32. However, most of these "return and new initial allocation" cases concern relatively old /32 allocations so we do not expect to have to do this very often, if at all. Best regards, Andrea Cima RIPE NCC > Thanks, > > Leo -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4paxoACgkQXOgsmPkFrjP0BQCcDIbhGhqIr6O2UiGhpQ+tUiTs TRYAn3dWTKCkuPU6T0ORQyVg2L9LRd5L =z6MP -----END PGP SIGNATURE----- From isacco.fontana at trentinonetwork.it Fri Jul 22 15:57:08 2011 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Fri, 22 Jul 2011 15:57:08 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E292E84.9080204@go6.si> References: <4E292E84.9080204@go6.si> Message-ID: <4E2981B4.30801@trentinonetwork.it> Hi, relating on following sentence: "If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment MUST support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]" I think the Multitopology ISIS can be used also without TE ad said in RFC 5120 with IPv6: "This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. ".... Jan Zorz @ go6.si ha scritto: > Hi, > > Please find attached document with many ideas and suggestions > included, LB spec is also there. > > As usual, all comments warmly welcome. > > Cheers, Jan -- Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 18.213.248,00. i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 Questo messaggio ? indirizzato esclusivamente ai destinatari in intestazione, pu? contenere informazioni protette e riservate ai sensi della normativa vigente e ne ? vietato qualsiasi impiego diverso da quello per cui ? stato inviato. Se lo avete ricevuto per errore siete pregati di eliminarlo in ogni sua parte e di avvisare il mittente. -------------------------------------------------------------------------------------------------------------------------------- From jan at go6.si Sat Jul 23 00:11:39 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 23 Jul 2011 00:11:39 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E2981B4.30801@trentinonetwork.it> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> Message-ID: <4E29F59B.70307@go6.si> On 7/22/11 3:57 PM, Isacco Fontana wrote: > Hi, > relating on following sentence: "If MPLS Traffic Engineering is used in > combination with IS-IS routing protocol, the equipment MUST support > "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to > Intermediate Systems (IS-ISs)" [RFC 5120]" > > I think the Multitopology ISIS can be used also without TE ad said in > RFC 5120 with IPv6: "This document describes how to run, within a single > IS-IS domain, a set of independent IP topologies that we call > Multi-Topologies (MTs). This MT extension can be used for a variety of > purposes, such as an in-band management network "on top" of the original > IGP topology, maintaining separate IGP routing domains for isolated > multicast or IPv6 islands within the backbone, or forcing a subset of an > address space to follow a different topology. ".... thnx for comment. What would be suggested change in text? Let's see if Ivan "mpls-master" Pepelnjak agree on proposed change :) Cheers, Jan From spz at serpens.de Sat Jul 23 00:54:47 2011 From: spz at serpens.de (S.P.Zeidler) Date: Sat, 23 Jul 2011 00:54:47 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> Message-ID: <20110722225445.GS9874@serpens.de> Hi, Thus wrote Ahmed Abu-Abed (ahmed at tamkien.com): > I believe implementing line rate IPSEC on a CPE requires silicon > that accelerates the crypto algorithms, and this may be a good Depends on your line rate. Up to 10Mbps, with i386 family CPUs of 400Mhz or better, the CPU on its own will do fine. > So making IPSEC optional is more practical to LIRs needing low cost > CPE solutions. Another option would be for LIRs looking for ultra low cost routers to take some that don't make the requirements list. Or take CPEs that flag themselves as "fulfilling RIPE-501 except IPSEC". Just because RIPE-501 exists does not mean that devices that don't fulfil it will suddenly evaporate, right? Again, the purpose of such a list is that a device that fulfils it will cover most reasonable needs. If we strike every feature off that somebody said "oh well I think I can do without that" about, it will become a useless "remotely resembling functional" description. Arguing that practically nobody would want their CPE to do IPSEC because everybody does host based IPSEC would be a better approach, but I would offer that that's going to be patently untrue if you look at company users and not private-person-residential users. regards, spz -- spz at serpens.de (S.P.Zeidler) From ip at ioshints.info Sat Jul 23 09:37:00 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sat, 23 Jul 2011 09:37:00 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E29F59B.70307@go6.si> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> Message-ID: <009101cc490b$506f2170$f14d6450$@info> IS-IS MT is highly desirable in most circumstances anyway, but we haven't considered that a good-enough reason to make it MANDATORY. However, if you run MPLS TE without MT, you get black hole routing the moment the first autoroute MPLS TE tunnel is established; thus we've made IS-IS MT MANDATORY for networks running MPLS TE. Details here: http://blog.ioshints.info/2010/03/is-ismpls-tenative-ipv6fail.html However, I'm perfectly happy if the WG decides to make IS-IS MT mandatory in all cases (would make sense anyway). Cheers, Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jan Zorz @ go6.si > Sent: Saturday, July 23, 2011 12:12 AM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] next version of RIPE-501, v.2 > > On 7/22/11 3:57 PM, Isacco Fontana wrote: > > Hi, > > relating on following sentence: "If MPLS Traffic Engineering is used in > > combination with IS-IS routing protocol, the equipment MUST support > > "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to > > Intermediate Systems (IS-ISs)" [RFC 5120]" > > > > I think the Multitopology ISIS can be used also without TE ad said in > > RFC 5120 with IPv6: "This document describes how to run, within a single > > IS-IS domain, a set of independent IP topologies that we call > > Multi-Topologies (MTs). This MT extension can be used for a variety of > > purposes, such as an in-band management network "on top" of the original > > IGP topology, maintaining separate IGP routing domains for isolated > > multicast or IPv6 islands within the backbone, or forcing a subset of an > > address space to follow a different topology. ".... > > thnx for comment. > > What would be suggested change in text? > > Let's see if Ivan "mpls-master" Pepelnjak agree on proposed change :) > > Cheers, Jan From ahmed at tamkien.com Sat Jul 23 10:46:44 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Sat, 23 Jul 2011 11:46:44 +0300 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <20110722225445.GS9874@serpens.de> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> Message-ID: Hello, On July 23rd S.P.Zeidler wrote: > Hi, > > Thus wrote Ahmed Abu-Abed (ahmed at tamkien.com): > >> I believe implementing line rate IPSEC on a CPE requires silicon >> that accelerates the crypto algorithms, and this may be a good > > Depends on your line rate. Up to 10Mbps, with i386 family CPUs of 400Mhz > or better, the CPU on its own will do fine. 100Mbps (or even 1Gbps) is also needed with GPON and ADSL2+ CPE offerings. And CPE vendors stay away from x86 processors due to heat dissipation issues. >> So making IPSEC optional is more practical to LIRs needing low cost >> CPE solutions. > > Another option would be for LIRs looking for ultra low cost routers to > take some that don't make the requirements list. Or take CPEs that flag > themselves as "fulfilling RIPE-501 except IPSEC". One of the main objectives of RIPE-501 is specifying IPv6 CPE requirements. CPEs are consumer devices, and LIRs need a spec that take practical issues, like cost, into consideration. > Just because RIPE-501 exists does not mean that devices that don't fulfil > it will suddenly evaporate, right? Shipping volume wise, IPv6 consumer CPEs are the most to utilize the RIPE-501 spec. So why not make such devices a priority when it comes to the mandatory requirements ? > Again, the purpose of such a list is that a device that fulfils it will > cover most reasonable needs. IPSEC on a low price consumer device may not be a reasonable need with current hardware offerings for CPEs. Making it optional is the best approach. > If we strike every feature off that somebody said "oh well I think I can > do without that" about, it will become a useless "remotely resembling > functional" description. > > Arguing that practically nobody would want their CPE to do IPSEC because > everybody does host based IPSEC would be a better approach, but I would > offer that that's going to be patently untrue if you look at company users > and not private-person-residential users. Many company users have a VPN client setup on their PC which should not need IPSEC on the CPE to work. We didn't say nobody wants it on their CPE, but IPSEC should not be on the mandatory list. Regards, -Ahmed From spz at serpens.de Sat Jul 23 12:29:13 2011 From: spz at serpens.de (S.P.Zeidler) Date: Sat, 23 Jul 2011 12:29:13 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> Message-ID: <20110723102912.GU9874@serpens.de> Hi, Thus wrote Ahmed Abu-Abed (ahmed at tamkien.com): > >Arguing that practically nobody would want their CPE to do IPSEC because > >everybody does host based IPSEC would be a better approach, but I would > >offer that that's going to be patently untrue if you look at company users > >and not private-person-residential users. > > Many company users have a VPN client setup on their PC which should > not need IPSEC on the CPE to work. So a company with two locations solves "the people at one location need to be able to access resources at the other location" by having the single PCs open a VPN connection .. where to exactly? So a company with several hundred locations with a local LAN each has several dozen PCs from each location open VPNs to a concentrator (instead of having the CPE open one connection for the entire LAN) and no useful way to get from location A to location B, nor even a useful way for central IT to get at the machines in the single locations? Neither of these scenarios is even remotely rare. The very first sentence of RIPE-501 v2 is: "To ensure the smooth and cost-efficient uptake of IPv6 across their networks, it is important that governments and large enterprises specify requirements for IPv6 compatibility when seeking tenders for Information and Communication Technology (ICT) equipment and support." "governments and large enterprises" not "John&Mary Smith, private residence" Throwing out a bog standard requirement for companies of almost any size because a family household will likely not need it in their CPE strikes me as missing the point. By a mile. regards, spz -- spz at serpens.de (S.P.Zeidler) From jan at go6.si Sun Jul 24 10:40:18 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 24 Jul 2011 10:40:18 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <009101cc490b$506f2170$f14d6450$@info> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> Message-ID: <4E2BDA72.4000308@go6.si> On 7/23/11 9:37 AM, Ivan Pepelnjak wrote: > IS-IS MT is highly desirable in most circumstances anyway, but we > haven't considered that a good-enough reason to make it MANDATORY. > > However, if you run MPLS TE without MT, you get black hole routing > the moment the first autoroute MPLS TE tunnel is established; thus > we've made IS-IS MT MANDATORY for networks running MPLS TE. > > Details here: > http://blog.ioshints.info/2010/03/is-ismpls-tenative-ipv6fail.html > > However, I'm perfectly happy if the WG decides to make IS-IS MT > mandatory in all cases (would make sense anyway). Currently, this is mandatory only "If MPLS Traffic Engineering is used in combination with IS-IS routing protocol" What percentage of equipment we exclude as routers if we make this unconditionally mandatory? I know for at least Mikrotik routers are excluded, as they do not support IS-IS at all (and they are quite used in small/medium companies environment). Opinions? Cheers, Jan From jan at go6.si Sun Jul 24 10:50:39 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 24 Jul 2011 10:50:39 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <20110722225445.GS9874@serpens.de> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> Message-ID: <4E2BDCDF.1060608@go6.si> On 7/23/11 12:54 AM, S.P.Zeidler wrote: > Another option would be for LIRs looking for ultra low cost routers to > take some that don't make the requirements list. Or take CPEs that flag > themselves as "fulfilling RIPE-501 except IPSEC". :) > > Just because RIPE-501 exists does not mean that devices that don't fulfil > it will suddenly evaporate, right? > > Again, the purpose of such a list is that a device that fulfils it will > cover most reasonable needs. agree. > > If we strike every feature off that somebody said "oh well I think I can > do without that" about, it will become a useless "remotely resembling > functional" description. > > Arguing that practically nobody would want their CPE to do IPSEC because > everybody does host based IPSEC would be a better approach, but I would > offer that that's going to be patently untrue if you look at company users > and not private-person-residential users. Business CPE must support it, residential should. But, please, have in mind that feedback from this list goes to Ole Troan, editor of RFC6204. He suggested to include only RFC6204 as mandatory (and that was also response from this community), so in case of different ideas RFC6204 might be changed. Ole, are you in the game? :) My suggestion would be to add (in addition to RFC6204 in mandatory): "If this specification is used for business class CPE, then IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to RFC6204 requirements" Suggestions, opinions? Cheers, Jan Cheers, Jan From ip at ioshints.info Sun Jul 24 12:32:03 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sun, 24 Jul 2011 12:32:03 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E2BDA72.4000308@go6.si> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> Message-ID: <00eb01cc49ec$ef67f9a0$ce37ece0$@info> If the equipment doesn't support IS-IS, then you can't expect it to support IS-IS MT ;) Anyway, making IS-IS mandatory makes absolutely no sense; it's rarely used in Enterprise environments. What we could do is to change the current requirement into "If the equipment supports IS-IS routing protocol, it MUST support IS-IS MT ..." (don?t cut/paste, use the wording from the document ;) Ivan > Currently, this is mandatory only "If MPLS Traffic Engineering is used > in combination with IS-IS routing protocol" > > What percentage of equipment we exclude as routers if we make this > unconditionally mandatory? > > I know for at least Mikrotik routers are excluded, as they do not > support IS-IS at all (and they are quite used in small/medium companies > environment). > > Opinions? > > Cheers, Jan From sander at steffann.nl Sun Jul 24 16:12:13 2011 From: sander at steffann.nl (Sander Steffann) Date: Sun, 24 Jul 2011 16:12:13 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <00eb01cc49ec$ef67f9a0$ce37ece0$@info> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> Message-ID: <2F7DF64F-A08A-46A6-B36B-E992268F6F85@steffann.nl> Hi, > If the equipment doesn't support IS-IS, then you can't expect it to support IS-IS MT ;) > > Anyway, making IS-IS mandatory makes absolutely no sense; it's rarely used in Enterprise environments. > > What we could do is to change the current requirement into "If the equipment supports IS-IS routing protocol, it MUST support IS-IS MT ..." (don?t cut/paste, use the wording from the document ;) Sounds like good advise :) Thanks, Sander From isacco.fontana at trentinonetwork.it Sun Jul 24 16:18:20 2011 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Sun, 24 Jul 2011 16:18:20 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <009101cc490b$506f2170$f14d6450$@info> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> Message-ID: I agree. I think the use of MT-ISIS when we have ipv6 is always desirable not only when we have TE. Isacco Inviato da iPad Il giorno 23/lug/2011, alle ore 09:37, "Ivan Pepelnjak" ha scritto: > IS-IS MT is highly desirable in most circumstances anyway, but we haven't considered that a good-enough reason to make it MANDATORY. > > However, if you run MPLS TE without MT, you get black hole routing the moment the first autoroute MPLS TE tunnel is established; thus we've made IS-IS MT MANDATORY for networks running MPLS TE. > > Details here: http://blog.ioshints.info/2010/03/is-ismpls-tenative-ipv6fail.html > > However, I'm perfectly happy if the WG decides to make IS-IS MT mandatory in all cases (would make sense anyway). > > Cheers, > Ivan > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> Jan Zorz @ go6.si >> Sent: Saturday, July 23, 2011 12:12 AM >> To: ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] next version of RIPE-501, v.2 >> >> On 7/22/11 3:57 PM, Isacco Fontana wrote: >>> Hi, >>> relating on following sentence: "If MPLS Traffic Engineering is used in >>> combination with IS-IS routing protocol, the equipment MUST support >>> "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to >>> Intermediate Systems (IS-ISs)" [RFC 5120]" >>> >>> I think the Multitopology ISIS can be used also without TE ad said in >>> RFC 5120 with IPv6: "This document describes how to run, within a single >>> IS-IS domain, a set of independent IP topologies that we call >>> Multi-Topologies (MTs). This MT extension can be used for a variety of >>> purposes, such as an in-band management network "on top" of the original >>> IGP topology, maintaining separate IGP routing domains for isolated >>> multicast or IPv6 islands within the backbone, or forcing a subset of an >>> address space to follow a different topology. ".... >> >> thnx for comment. >> >> What would be suggested change in text? >> >> Let's see if Ivan "mpls-master" Pepelnjak agree on proposed change :) >> >> Cheers, Jan > From isacco.fontana at trentinonetwork.it Sun Jul 24 18:00:57 2011 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Sun, 24 Jul 2011 18:00:57 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <2F7DF64F-A08A-46A6-B36B-E992268F6F85@steffann.nl> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> <2F7DF64F-A08A-46A6-B36B-E992268F6F85@steffann.nl> Message-ID: <7AFCEDFC-0471-4E2E-AD8E-A54F3510C976@trentinonetwork.it> I agree ... Isacco Inviato da iPad Il giorno 24/lug/2011, alle ore 16:12, Sander Steffann ha scritto: > Hi, > >> If the equipment doesn't support IS-IS, then you can't expect it to support IS-IS MT ;) >> >> Anyway, making IS-IS mandatory makes absolutely no sense; it's rarely used in Enterprise environments. >> >> What we could do is to change the current requirement into "If the equipment supports IS-IS routing protocol, it MUST support IS-IS MT ..." (don?t cut/paste, use the wording from the document ;) > > Sounds like good advise :) > > Thanks, > > Sander > From jan at go6.si Sun Jul 24 18:23:11 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 24 Jul 2011 18:23:11 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <00eb01cc49ec$ef67f9a0$ce37ece0$@info> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> Message-ID: <4E2C46EF.4080908@go6.si> On 7/24/11 12:32 PM, Ivan Pepelnjak wrote: > If the equipment doesn't support IS-IS, then you can't expect it to > support IS-IS MT ;) ;) > > Anyway, making IS-IS mandatory makes absolutely no sense; it's rarely > used in Enterprise environments. > > What we could do is to change the current requirement into "If the > equipment supports IS-IS routing protocol, it MUST support IS-IS MT > ..." (don?t cut/paste, use the wording from the document ;) hmm... I think we should not say "If equipment supports", as *we* are writing document defining what equipment must and should support. ;) Probably it would be a good thing to say something like: "If IS-IS [RFC5308] is requested, then IS-IS MT must be supported" or maybe we just move from optional to mandatory this section: "When IS-IS routing protocol is requested, the equipment SHOULD support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] (highly recommended)" ...change the first word "When" to "If" and remove "(highly recommended)" :) What do you guys think? /jan From sander at steffann.nl Sun Jul 24 22:03:40 2011 From: sander at steffann.nl (Sander Steffann) Date: Sun, 24 Jul 2011 22:03:40 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E2C46EF.4080908@go6.si> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> <4E2C46EF.4080908@go6.si> Message-ID: <51A9C8B4-9C11-4920-A994-3DD004D3D5F7@steffann.nl> Hi, > "When IS-IS routing protocol is requested, the equipment SHOULD support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] (highly recommended)" > What do you guys think? I would put this in 'mandatory': - If the IS-IS routing protocol is requested the equipment MUST support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] Met vriendelijke groet, Sander Steffann From jan at go6.si Mon Jul 25 01:15:07 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 25 Jul 2011 01:15:07 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <51A9C8B4-9C11-4920-A994-3DD004D3D5F7@steffann.nl> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> <4E2C46EF.4080908@go6.si> <51A9C8B4-9C11-4920-A994-3DD004D3D5F7@steffann.nl> Message-ID: <4E2CA77B.1060702@go6.si> On 7/24/11 10:03 PM, Sander Steffann wrote: > I would put this in 'mandatory': > > - If the IS-IS routing protocol is requested the equipment MUST > support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System > to Intermediate Systems (IS-ISs)" [RFC 5120] ok, I see you already updated the draft on Gdocs. One question, should we use "MUST" with capital letters or we use normal "must" in this "if" sentences? Currently we use mix :) Cheers, Jan From sander at steffann.nl Mon Jul 25 01:21:12 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 25 Jul 2011 01:21:12 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E2CA77B.1060702@go6.si> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> <4E2C46EF.4080908@go6.si> <51A9C8B4-9C11-4920-A994-3DD004D3D5F7@steffann.nl> <4E2CA77B.1060702@go6.si> Message-ID: Hi, >> I would put this in 'mandatory': >> >> - If the IS-IS routing protocol is requested the equipment MUST >> support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System >> to Intermediate Systems (IS-ISs)" [RFC 5120] > > ok, I see you already updated the draft on Gdocs. I didn't put this change in yet though :) > One question, should we use "MUST" with capital letters or we use normal "must" in this "if" sentences? We are not writing an RFC so I think we should use lowercase. Met vriendelijke groet, Sander Steffann From jan at go6.si Mon Jul 25 01:30:38 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 25 Jul 2011 01:30:38 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> <4E2C46EF.4080908@go6.si> <51A9C8B4-9C11-4920-A994-3DD004D3D5F7@steffann.nl> <4E2CA77B.1060702@go6.si> Message-ID: <4E2CAB1E.1030404@go6.si> On 7/25/11 1:21 AM, Sander Steffann wrote: > Hi, > >>> I would put this in 'mandatory': >>> >>> - If the IS-IS routing protocol is requested the equipment MUST >>> support "M-ISIS: Multi-Topology (MT) Routing in Intermediate >>> System to Intermediate Systems (IS-ISs)" [RFC 5120] >> >> ok, I see you already updated the draft on Gdocs. > > I didn't put this change in yet though :) ah, ok, my mistake. Done, changed. > >> One question, should we use "MUST" with capital letters or we use >> normal "must" in this "if" sentences? > > > We are not writing an RFC so I think we should use lowercase. corrected. Cheers, Jan From sander at steffann.nl Mon Jul 25 01:32:23 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 25 Jul 2011 01:32:23 +0200 Subject: [ipv6-wg] next version of RIPE-501, v.2 In-Reply-To: <4E2CAB1E.1030404@go6.si> References: <4E292E84.9080204@go6.si> <4E2981B4.30801@trentinonetwork.it> <4E29F59B.70307@go6.si> <009101cc490b$506f2170$f14d6450$@info> <4E2BDA72.4000308@go6.si> <00eb01cc49ec$ef67f9a0$ce37ece0$@info> <4E2C46EF.4080908@go6.si> <51A9C8B4-9C11-4920-A994-3DD004D3D5F7@steffann.nl> <4E2CA77B.1060702@go6.si> <4E2CAB1E.1030404@go6.si> Message-ID: <2EE593D2-6A30-4E4F-A3AD-5296E69B3033@steffann.nl> >> I didn't put this change in yet though :) > > ah, ok, my mistake. Done, changed. > >> We are not writing an RFC so I think we should use lowercase. > > corrected. Fast! Thanks :) Met vriendelijke groet, Sander Steffann From chris at in-berlin.de Mon Jul 25 08:48:56 2011 From: chris at in-berlin.de (Christian Seitz) Date: Mon, 25 Jul 2011 08:48:56 +0200 (CEST) Subject: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD Message-ID: Hello, we had an IPv6 path MTU discovery issue last week and I would like to discuss possible solutions here. The problem is a combination of not announcing IXP IPv6 peering prefixes in the global BGP table and activating loose uRPF at the border of a network. I made the following traceroutes and pings after deactivating loose uRPF at the border. Before this I did not see any packet from the LINX peering lan address 2001:7f8:4::d1c:1, because it is not announced to the global BGP table and therefore not routable. The traceroute ended after 2001:450:2001:800e::2 before. chris at router> traceroute 2a01:e0c:1:1599::1 source 2001:x:x:x::2 traceroute6 to 2a01:e0c:1:1599::1 (2a01:e0c:1:1599::1) from 2001:x:x:x::2, 64 hops max, 12 byte packets [...] 2 2001:450:2001:800e::2 (2001:450:2001:800e::2) 0.793 ms 0.611 ms 0.604 ms 3 2001:7f8:4::d1c:1 (2001:7f8:4::d1c:1) 25.692 ms 227.307 ms 18.160 ms 4 2001:1900:5:2::12e (2001:1900:5:2::12e) 26.565 ms 26.310 ms 26.248 ms 5 2a01:e00:2:9::1 (2a01:e00:2:9::1) 26.746 ms 28.774 ms 40.343 ms [...] An ICMP echo request packet with more than 1410 bytes (1450 byte incl. header) shows that there is a smaller MTU between two routers in the backbone of Level3: PING www.free.fr(www.free.fr) 1403 data bytes >From 2001:7f8:4::d1c:1 icmp_seq=86 Packet too big: mtu=1450 1411 bytes from www.free.fr: icmp_seq=87 ttl=53 time=41.5 ms [...] 2001:7f8:4::d1c:1 seems to be a router of Level3 at LINX. The next router 2001:1900:5:2::12e also has an IP address from the Level3 IPv6 allocation. There seems to be an MTU of 1450 bytes between those two routers. The router at LINX sends out an ICMP "Packet too big" with the source address of the interface where he sees the route to the source address. This is the LINX peering lan, which is currently not announced in BGP. We use loose uRPF at the border to drop all packets from source addresses that are not globally routed. The ICMP "Packet too big" gets lost and path MTU discovery is broken. Communication with big packets is not possible. Some IXPs decided not to announce their peering lan prefixes for some reasons, but in combination with loose uRPF this leads to problems like this one. I would like to discuss the best current practise and possible solutions here. Possible solutions from my point of view: 1) Do not activate loose uRPF at the border of any network. 2) Any network where loose uRPF is configured at the border has to configure static routes for the IXP ranges of every RIR and redistribute them in the IGP so there is a valid route for loose uRPF checks. 3) IXPs announce their peering lan prefixes in the global BGP table and make loose uRPF work for the rest of the world. Members of the IXPs should possibly filter BGP announcements of the IXP peering lan prefixes from external peers when they do not use "next-hop-self" in iBGP within their network. 4) Remove tunnels, use native IPv6. There will always be links with an MTU lower than 1500 byte (access), so this is possibly not the best solution. 5) ? Regards from Berlin, Chris From sander at steffann.nl Mon Jul 25 11:37:05 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 25 Jul 2011 11:37:05 +0200 Subject: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: References: Message-ID: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> Hi, > 5) ? Adapt uRPF so that it does't filter ICMP error messages. Whether this is useful depends on how much ICMP error messages with unreachable source addresses we expect to see? When people/organizations start to use ULA addresses it might be more than we see now. - Sander From gert at space.net Mon Jul 25 11:43:12 2011 From: gert at space.net (Gert Doering) Date: Mon, 25 Jul 2011 11:43:12 +0200 Subject: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> Message-ID: <20110725094312.GJ72014@Space.Net> Hi, On Mon, Jul 25, 2011 at 11:37:05AM +0200, Sander Steffann wrote: > > 5) ? > > Adapt uRPF so that it does't filter ICMP error messages. Whether > this is useful depends on how much ICMP error messages with unreachable > source addresses we expect to see? When people/organizations start > to use ULA addresses it might be more than we see now. Indeed this sounds like a good "option #5". Christian, can your gear do IPv6-uRPF-with-permit-ACLs in Hardware? (My gear can only do IPv6-uRPF in software, no matter what options I use, so we currently filter by ACL) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From no-reply at ripe.net Mon Jul 25 12:06:31 2011 From: no-reply at ripe.net (Paul Rendek) Date: Mon, 25 Jul 2011 12:06:31 +0200 Subject: [ipv6-wg] Reminder: Global IPv6 Deployment Monitoring Survey 2011 Message-ID: <4E2D4027.2090009@ripe.net> [Apologies for duplicate mails] Dear Colleagues, There's just one week left to complete the Global IPv6 Deployment Monitoring Survey 2011. Take part online now at: http://www.surveymonkey.com/s/GlobalIPv6survey2011 This survey has been designed by GNKS Consult in collaboration with TNO and the RIPE NCC to further understand where the community stands on IPv6 and what needs be done to ensure that the Internet community is ready for the widespread adoption of IPv6. Anyone can participate in this survey and we hope that the results will establish a comprehensive view of current IPv6 penetration and future plans for IPv6 deployment. The survey comprises 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments or who have not yet deployed IPv6, there will be fewer questions. The survey will close on 31 July 2011. We thank you for your time and interest in completing this survey. If you have any questions concerning the survey, please email . For more information about the survey and links to previous year's survey results, please see: https://www.ripe.net/internet-coordination/news/industry-developments/global-ipv6-deployment-monitoring-survey-2011 Regards, Paul Rendek RIPE NCC Head of External Relations and Communication From fweimer at bfk.de Mon Jul 25 12:44:53 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 25 Jul 2011 10:44:53 +0000 Subject: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: (Christian Seitz's message of "Mon, 25 Jul 2011 08:48:56 +0200 (CEST)") References: Message-ID: <82aac2ej16.fsf@mid.bfk.de> * Christian Seitz: > 5) ? Send those ICMP messages from a globally reachable IP address. The source address doesn't matter, after all. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From evyncke at cisco.com Mon Jul 25 17:24:10 2011 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Mon, 25 Jul 2011 17:24:10 +0200 Subject: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <20110725094312.GJ72014@Space.Net> References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> <20110725094312.GJ72014@Space.Net> Message-ID: <317616CE96204D49B5A1811098BA895004FF5E7D@XMB-AMS-110.cisco.com> 5) easier said than done as uRPF checks are done solely at layer-3 and nobody wants to send rejected packets to the route processor, don't we? > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Gert Doering > Sent: lundi 25 juillet 2011 05:43 > To: Sander Steffann > Cc: Christian Seitz; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global > BGP table possibly breaks PMTUD > > Hi, > > On Mon, Jul 25, 2011 at 11:37:05AM +0200, Sander Steffann wrote: > > > 5) ? > > > > Adapt uRPF so that it does't filter ICMP error messages. Whether > > this is useful depends on how much ICMP error messages with unreachable > > source addresses we expect to see? When people/organizations start > > to use ULA addresses it might be more than we see now. > > Indeed this sounds like a good "option #5". > > Christian, can your gear do IPv6-uRPF-with-permit-ACLs in Hardware? > > (My gear can only do IPv6-uRPF in software, no matter what options I use, > so we currently filter by ACL) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Mon Jul 25 17:46:13 2011 From: gert at space.net (Gert Doering) Date: Mon, 25 Jul 2011 17:46:13 +0200 Subject: [ipv6-wg] not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <317616CE96204D49B5A1811098BA895004FF5E7D@XMB-AMS-110.cisco.com> References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> <20110725094312.GJ72014@Space.Net> <317616CE96204D49B5A1811098BA895004FF5E7D@XMB-AMS-110.cisco.com> Message-ID: <20110725154613.GW72014@Space.Net> Hi, On Mon, Jul 25, 2011 at 05:24:10PM +0200, Eric Vyncke (evyncke) wrote: > 5) easier said than done as uRPF checks are done solely at layer-3 and > nobody wants to send rejected packets to the route processor, don't we? Well, that completely depends on the hardware capabilities. Maybe some vendors can do IPv6 uRPF-checks plus uRPF-exception-ACLs in hardware now... Gert Doering -- 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 chris at in-berlin.de Tue Jul 26 09:01:31 2011 From: chris at in-berlin.de (Christian Seitz) Date: Tue, 26 Jul 2011 09:01:31 +0200 (CEST) Subject: [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <20110725094312.GJ72014@Space.Net> References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> <20110725094312.GJ72014@Space.Net> Message-ID: Hi Gert, On Mon, 25 Jul 2011, Gert Doering wrote: > On Mon, Jul 25, 2011 at 11:37:05AM +0200, Sander Steffann wrote: >>> 5) ? >> >> Adapt uRPF so that it does't filter ICMP error messages. Whether this >> is useful depends on how much ICMP error messages with unreachable >> source addresses we expect to see? When people/organizations start to >> use ULA addresses it might be more than we see now. > > Indeed this sounds like a good "option #5". > > Christian, can your gear do IPv6-uRPF-with-permit-ACLs in Hardware? > > (My gear can only do IPv6-uRPF in software, no matter what options I > use, so we currently filter by ACL) both Juniper MX960 and Cisco CRS-1 are able to do IPv6 uRPF incl. permit ACL (Cisco) and fail-filter (Juniper) in hardware so we would like to use it as for IPv4. Regards, Chris From chris at in-berlin.de Tue Jul 26 09:05:25 2011 From: chris at in-berlin.de (Christian Seitz) Date: Tue, 26 Jul 2011 09:05:25 +0200 (CEST) Subject: [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <82aac2ej16.fsf@mid.bfk.de> References: <82aac2ej16.fsf@mid.bfk.de> Message-ID: Hello Florian, On Mon, 25 Jul 2011, Florian Weimer wrote: > * Christian Seitz: > >> 5) ? > > Send those ICMP messages from a globally reachable IP address. The > source address doesn't matter, after all. so Level3 should fix the problem in this case? I notified them about the problem last week, but since today nothing happened. I still see >From 2001:7f8:4::d1c:1 icmp_seq=1 Packet too big: mtu=1450 when sending big packets. free.fr still has many IPv6 customers online and I hope that more and more access providers will enable IPv6. These issues have to be fixed in the own network first. Waiting for the big carriers to do anything can take some time... :-/ Regards, Chris From chris at in-berlin.de Tue Jul 26 09:13:39 2011 From: chris at in-berlin.de (Christian Seitz) Date: Tue, 26 Jul 2011 09:13:39 +0200 (CEST) Subject: [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> Message-ID: Hello, On Mon, 25 Jul 2011, Sander Steffann wrote: >> 5) ? > > Adapt uRPF so that it does't filter ICMP error messages. Whether this is > useful depends on how much ICMP error messages with unreachable source > addresses we expect to see? When people/organizations start to use ULA > addresses it might be more than we see now. do you really want to disable filtering all ICMP packets from non-routed addresses? I do not like to have an ICMP DoS from unroutable addresses in my network. ICMP is important for IPv6 communication to work, yes, but only from routable addresses. ULA could be the next problem. Not only loose uRPF may be the problem in this case, but also infrastructure ACLs which deny ULA addresses from outside. RFC4193 4.3 says that packets from ULA addresses should be filtered at the border. If somebody sends ICMP "Packet too big" with an address from the ULA range as the source address it is expected that it will be dropped somewhere (at the border of the own network, at the border of the destination network or somewhere in a backbone between those two networks). Regards, Chris From jan at go6.si Tue Jul 26 09:43:16 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 26 Jul 2011 09:43:16 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E2BDCDF.1060608@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> <4E2BDCDF.1060608@go6.si> Message-ID: <4E2E7014.7040403@go6.si> On 7/24/11 10:50 AM, Jan Zorz @ go6.si wrote: > My suggestion would be to add (in addition to RFC6204 in mandatory): > > "If this specification is used for business class CPE, then IPsec-v2 > [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] > and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to > RFC6204 requirements" Any opinions from the WG on this? Otherwise I would add this to the spec. Ole? Cheers, Jan From gert at space.net Tue Jul 26 09:45:00 2011 From: gert at space.net (Gert Doering) Date: Tue, 26 Jul 2011 09:45:00 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E2E7014.7040403@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> <4E2BDCDF.1060608@go6.si> <4E2E7014.7040403@go6.si> Message-ID: <20110726074500.GY72014@Space.Net> Hi, On Tue, Jul 26, 2011 at 09:43:16AM +0200, Jan Zorz @ go6.si wrote: > On 7/24/11 10:50 AM, Jan Zorz @ go6.si wrote: > > > My suggestion would be to add (in addition to RFC6204 in mandatory): > > > > "If this specification is used for business class CPE, then IPsec-v2 > > [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] > > and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to > > RFC6204 requirements" > > Any opinions from the WG on this? Otherwise I would add this to the spec. I like this version. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Tue Jul 26 09:56:35 2011 From: gert at space.net (Gert Doering) Date: Tue, 26 Jul 2011 09:56:35 +0200 Subject: [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> Message-ID: <20110726075635.GZ72014@Space.Net> Hi, On Tue, Jul 26, 2011 at 09:13:39AM +0200, Christian Seitz wrote: > On Mon, 25 Jul 2011, Sander Steffann wrote: > > >> 5) ? > > > > Adapt uRPF so that it does't filter ICMP error messages. Whether this is > > useful depends on how much ICMP error messages with unreachable source > > addresses we expect to see? When people/organizations start to use ULA > > addresses it might be more than we see now. > > do you really want to disable filtering all ICMP packets from non-routed > addresses? I do not like to have an ICMP DoS from unroutable addresses in > my network. ICMP is important for IPv6 communication to work, yes, but > only from routable addresses. Uh, I don't think that point is valid. Regarding DoS possibilities, for ICMP *error* messages (which are not replied to) there's no difference between "coming from routed space" and "coming from non-routed space". If you're worried about DoS-by-ICMP, you need rate-limits. uRPF won't help, as it's easy for a moderate-sized botnet to send you enough traffic from legitimate sources without needing to spoof source addresses... > ULA could be the next problem. Not only loose uRPF may be the problem in > this case, but also infrastructure ACLs which deny ULA addresses from > outside. RFC4193 4.3 says that packets from ULA addresses should be > filtered at the border. If somebody sends ICMP "Packet too big" with an > address from the ULA range as the source address it is expected that it > will be dropped somewhere (at the border of the own network, at the border > of the destination network or somewhere in a backbone between those two > networks). Now that's a different can of worms. If someone numbers their transit network with ULAs and sends ICMP errors from ULA space, they deserve what you can think up for them. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From dr at cluenet.de Tue Jul 26 10:29:39 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 26 Jul 2011 10:29:39 +0200 Subject: [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: References: <82aac2ej16.fsf@mid.bfk.de> Message-ID: <20110726082939.GA25076@srv03.cluenet.de> On Tue, Jul 26, 2011 at 09:05:25AM +0200, Christian Seitz wrote: >> Send those ICMP messages from a globally reachable IP address. The source >> address doesn't matter, after all. > > so Level3 should fix the problem in this case? Surely not. There is nothing to fix, they don't do anything wrong. The problem is indeed that the IXP prefix is not advertised, which is inherently incompatible with any uRPF (and exactly the reason why you see e.g. 2001:7f8:2c::/48 in the DFZ since 2004 :-)). >> From 2001:7f8:4::d1c:1 icmp_seq=1 Packet too big: mtu=1450 Die Adresse ist korrekt. Siehe RFC4443: =================================================================== 2.2. Message Source Address Determination A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows: (a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address. (b) If the message is a response to a message sent to any other address, such as - a multicast group address, - an anycast address implemented by the node, or - a unicast address that does not belong to the node the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet. =================================================================== And the address which would be selected as "source address for any other packet originated by the node, given the destination address of the packet" is quite usually the interface IP of the egress interface towards the ICMP packet destination. Asking L3 to change that (if they could at all) is unreasonable IMHO. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ip at ioshints.info Tue Jul 26 10:49:59 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 26 Jul 2011 10:49:59 +0200 Subject: [ipv6-wg] Re: not announcing IXP IPv6 peering lan prefixes in global BGP table possibly breaks PMTUD In-Reply-To: <20110726075635.GZ72014@Space.Net> References: <7E65A247-D565-463B-B40C-6DFA144170B0@steffann.nl> <20110726075635.GZ72014@Space.Net> Message-ID: <004f01cc4b71$0201ecd0$0605c670$@info> > > ULA could be the next problem. Not only loose uRPF may be the problem in > > this case, but also infrastructure ACLs which deny ULA addresses from > > outside. RFC4193 4.3 says that packets from ULA addresses should be > > filtered at the border. If somebody sends ICMP "Packet too big" with an > > address from the ULA range as the source address it is expected that it > > will be dropped somewhere (at the border of the own network, at the > border > > of the destination network or somewhere in a backbone between those two > > networks). > > Now that's a different can of worms. If someone numbers their transit > network with ULAs and sends ICMP errors from ULA space, they deserve what > you can think up for them. Enterprise IPv6 networks using PA space will (to avoid renumbering after an ISP change) and you'll see ICMP errors coming from them when the inbound IPv6 packets transit VPN tunnels. Ivan From ot at cisco.com Tue Jul 26 15:44:08 2011 From: ot at cisco.com (Ole Troan) Date: Tue, 26 Jul 2011 09:44:08 -0400 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E2E7014.7040403@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> <4E2BDCDF.1060608@go6.si> <4E2E7014.7040403@go6.si> Message-ID: <61F4B230-65BA-4350-959D-91EFDB8F22D3@cisco.com> >> My suggestion would be to add (in addition to RFC6204 in mandatory): >> >> "If this specification is used for business class CPE, then IPsec-v2 >> [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] >> and ISAKMP [RFC2407, RFC2408, RFC2409] must be supported in addition to >> RFC6204 requirements" > > Any opinions from the WG on this? Otherwise I would add this to the spec. > > Ole? on the fence, but if I had to fall down on one side I think its OK. perhaps a should? it really depends on the deployment. not all business deployments require VPNs. which presume is what is the underlaying reason for requiring this? cheers, Ole From jan at go6.si Tue Jul 26 18:04:31 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 26 Jul 2011 18:04:31 +0200 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <61F4B230-65BA-4350-959D-91EFDB8F22D3@cisco.com> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> <4E2BDCDF.1060608@go6.si> <4E2E7014.7040403@go6.si> <61F4B230-65BA-4350-959D-91EFDB8F22D3@cisco.com> Message-ID: <4E2EE58F.7050206@go6.si> On 7/26/11 3:44 PM, Ole Troan wrote: >>> My suggestion would be to add (in addition to RFC6204 in >>> mandatory): >>> >>> "If this specification is used for business class CPE, then >>> IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) >>> [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be >>> supported in addition to RFC6204 requirements" >> >> Any opinions from the WG on this? Otherwise I would add this to the >> spec. >> >> Ole? > > on the fence, but if I had to fall down on one side I think its OK. > perhaps a should? it really depends on the deployment. not all > business deployments require VPNs. which presume is what is the > underlaying reason for requiring this? Ole, thnx for kicking in... So, did you mean something like this in Optional section: "If this specification is used for business class CPE, then it is highly recommended, that IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] are unconditionally required in addition to RFC6204 requirements" Would that work? What others think? Cheers, Jan From merike at doubleshotsecurity.com Tue Jul 26 19:24:42 2011 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Tue, 26 Jul 2011 10:24:42 -0700 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E2EE58F.7050206@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> <4E2BDCDF.1060608@go6.si> <4E2E7014.7040403@go6.si> <61F4B230-65BA-4350-959D-91EFDB8F22D3@cisco.com> <4E2EE58F.7050206@go6.si> Message-ID: <84D0C93A-2B9A-4045-98C1-33D12E29CAD5@doubleshotsecurity.com> On Jul 26, 2011, at 9:04 AM, Jan Zorz @ go6.si wrote: > On 7/26/11 3:44 PM, Ole Troan wrote: >>>> My suggestion would be to add (in addition to RFC6204 in >>>> mandatory): >>>> >>>> "If this specification is used for business class CPE, then >>>> IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) >>>> [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] must be >>>> supported in addition to RFC6204 requirements" >>> >>> Any opinions from the WG on this? Otherwise I would add this to the >>> spec. >>> >>> Ole? >> >> on the fence, but if I had to fall down on one side I think its OK. >> perhaps a should? it really depends on the deployment. not all >> business deployments require VPNs. which presume is what is the >> underlaying reason for requiring this? > > Ole, thnx for kicking in... > > So, did you mean something like this in Optional section: > > "If this specification is used for business class CPE, then it is highly recommended, that IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] are unconditionally required in addition to RFC6204 requirements" > > Would that work? > > What others think? The document lists mandatory and optional requirements. I think we should stick to this model. I like this new wording for the optional section here since it does stipulate that IPsec is strongly recommended but does not mandate it. - merike From ot at cisco.com Tue Jul 26 21:46:03 2011 From: ot at cisco.com (Ole Troan) Date: Tue, 26 Jul 2011 15:46:03 -0400 Subject: [ipv6-wg] RIPE-501 and IPSEC on CPEs In-Reply-To: <4E2EE58F.7050206@go6.si> References: <2A7B9F1FDCA74659B20B9284DAB7C308@mTOSH> <4E2703D6.6010407@go6.si> <006201cc46fb$becddd80$3c699880$@info> <20110720180513.GH9874@serpens.de> <4E272459.5070301@go6.si> <4E274D30.3000103@pragma.si> <20110722225445.GS9874@serpens.de> <4E2BDCDF.1060608@go6.si> <4E2E7014.7040403@go6.si> <61F4B230-65BA-4350-959D-91EFDB8F22D3@cisco.com> <4E2EE58F.7050206@go6.si> Message-ID: > So, did you mean something like this in Optional section: > > "If this specification is used for business class CPE, then it is highly recommended, that IPsec-v2 [RFC2401, RFC2406, RFC2402], IKE version 2 (IKEv2) [RFC4306, RFC4718] and ISAKMP [RFC2407, RFC2408, RFC2409] are unconditionally required in addition to RFC6204 requirements" > > Would that work? ack. cheers, Ole From aurelio.diazpereira at gmail.com Wed Jul 27 08:19:30 2011 From: aurelio.diazpereira at gmail.com (Aurelio Diaz Pereira) Date: Wed, 27 Jul 2011 08:19:30 +0200 Subject: [ipv6-wg] Re: is ok Message-ID: confirm 764810 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jul 27 15:02:14 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jul 2011 09:02:14 -0400 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers Message-ID: Hi all, I will like to know, from those deploying IPv6 services to residential customers, if you are planning to provide static or dynamic IPv6 prefixes. Just to be clear, I'm for static prefix delegation to residential customers, however I heard that some ISPs are doing dynamic delegations, the same way as is common today with IPv4. I don't thin it make sense, as the main reason for doing so in IPv4 was address exhaustion and legacy oversubscription models such as PPP/dial-up. Regards, Jordi PS: I've sent this question to NANOG, got very few answers, so trying here ... ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From riccardo at e4a.it Wed Jul 27 15:13:19 2011 From: riccardo at e4a.it (Riccardo Losselli) Date: Wed, 27 Jul 2011 15:13:19 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <4E300EEF.3060808@e4a.it> Sorry, /56 planned to the customer not /48 Cheers, Ricky From riccardo at e4a.it Wed Jul 27 15:10:30 2011 From: riccardo at e4a.it (Riccardo Losselli) Date: Wed, 27 Jul 2011 15:10:30 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <4E300E46.2030807@e4a.it> Il 27/07/2011 15:02, JORDI PALET MARTINEZ ha scritto: > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. Static, /64 at the moment but /48 planned Cheers, Ricky From ip at ioshints.info Wed Jul 27 15:45:05 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 27 Jul 2011 15:45:05 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <004101cc4c63$65e5bd10$31b13730$@info> Unfortunately you have to do static prefix delegation because it's impossible to renumber the customer's inside LAN within a reasonable time interval with today's state of IPv6 SLAAC. However, static delegations might cause IPv6 routing table explosion unless you're very careful (with dynamic IPv4 address allocation you could define address pool on BRAS and advertise just the pool prefix into the rest of the network). Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > JORDI PALET MARTINEZ > Sent: Wednesday, July 27, 2011 3:02 PM > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential > customers > > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. > > Just to be clear, I'm for static prefix delegation to residential > customers, however I heard that some ISPs are doing dynamic delegations, > the same way as is common today with IPv4. > > I don't thin it make sense, as the main reason for doing so in IPv4 was > address exhaustion and legacy oversubscription models such as PPP/dial-up. > > Regards, > Jordi > > PS: I've sent this question to NANOG, got very few answers, so trying here > ... > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > From jordi.palet at consulintel.es Wed Jul 27 16:00:02 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jul 2011 10:00:02 -0400 Subject: AW: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: Message-ID: However I think this is an educational problem of those agencies ? you can't offer dynamic and stable services to access the home, and privacy goes beyond a stable address. So miss-protecting privacy actually is against user services. Regarding the routing table, my guess is that you should aggregate all the customer prefixes, in a small number of prefixes for each BRAS, PoP, etc., so no difference here with IPv4. Regards, Jordi -----Mensaje original----- De: Responder a: Fecha: Wed, 27 Jul 2011 15:49:27 +0200 Para: , Jordi Palet Martinez Asunto: AW: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers >Regarding Jordis question I've to add that regulatory agencies in some >countries are not voting for static/permanent prefix delegation to >customers, because of privacy reasons. > >Kind regards >Olaf > >> -----Urspr?ngliche Nachricht----- >> Von: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] >> Im Auftrag von Ivan Pepelnjak >> Gesendet: Mittwoch, 27. Juli 2011 09:45 >> An: jordi.palet at consulintel.es; ipv6-wg at ripe.net >> Betreff: RE: [ipv6-wg] dynamic or static IPv6 prefixes to >> residential customers >> >> Unfortunately you have to do static prefix delegation because >> it's impossible to renumber the customer's inside LAN within >> a reasonable time interval with today's state of IPv6 SLAAC. >> >> However, static delegations might cause IPv6 routing table >> explosion unless you're very careful (with dynamic IPv4 >> address allocation you could define address pool on BRAS and >> advertise just the pool prefix into the rest of the network). >> >> Ivan >> >> > -----Original Message----- >> > From: ipv6-wg-admin at ripe.net >> [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> > JORDI PALET MARTINEZ >> > Sent: Wednesday, July 27, 2011 3:02 PM >> > To: ipv6-wg at ripe.net >> > Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential >> > customers >> > >> > Hi all, >> > >> > I will like to know, from those deploying IPv6 services to >> residential >> > customers, if you are planning to provide static or dynamic >> IPv6 prefixes. >> > >> > Just to be clear, I'm for static prefix delegation to residential >> > customers, however I heard that some ISPs are doing dynamic >> delegations, >> > the same way as is common today with IPv4. >> > >> > I don't thin it make sense, as the main reason for doing so >> in IPv4 was >> > address exhaustion and legacy oversubscription models such >> as PPP/dial-up. >> > >> > Regards, >> > Jordi >> > >> > PS: I've sent this question to NANOG, got very few answers, >> so trying here >> > ... >> > >> > >> > >> > ********************************************** >> > IPv4 is over >> > Are you ready for the new Internet ? >> > http://www.consulintel.es >> > The IPv6 Company >> > >> > This electronic message contains information which may be >> privileged or >> > confidential. The information is intended to be for the use of the >> > individual(s) named above. If you are not the intended >> recipient be aware >> > that any disclosure, copying, distribution or use of the >> contents of this >> > information, including attached files, is prohibited. >> > >> >> >> ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From tjc at ecs.soton.ac.uk Wed Jul 27 16:08:25 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 27 Jul 2011 15:08:25 +0100 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: <004101cc4c63$65e5bd10$31b13730$@info> References: <004101cc4c63$65e5bd10$31b13730$@info> <35A38C28-8B21-4253-9ECE-83B0048A488D@ecs.soton.ac.uk> Message-ID: On 27 Jul 2011, at 14:45, Ivan Pepelnjak wrote: > Unfortunately you have to do static prefix delegation because it's impossible to renumber the customer's inside LAN within a reasonable time interval with today's state of IPv6 SLAAC. Why impossible? Tim From ip at ioshints.info Wed Jul 27 16:26:20 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 27 Jul 2011 16:26:20 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <004101cc4c63$65e5bd10$31b13730$@info> <35A38C28-8B21-4253-9ECE-83B0048A488D@ecs.soton.ac.uk> Message-ID: <004a01cc4c69$2952a1a0$7bf7e4e0$@info> There's a minimum timeout of 2 hours hard-coded in the SLAAC RFC to prevent DoS attacks. Some details here: http://blog.ioshints.info/2010/12/small-site-multihoming-in-ipv6-mission.html Then there's the failure to detect PPPoE session loss: http://blog.ioshints.info/2010/10/dhcpv6-over-pppoe-total-disaster.html Last but definitely not least, CPEs tend to copy lease time from DHCPv6 PD to SLAAC prefix validity time (and I found no way to change that behavior in Cisco IOS), so you either overload your DHCPv6 server by using short leases or risk having delegated prefixes that will stay in the customer's CPEs for a long time. Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Tim Chown > Sent: Wednesday, July 27, 2011 4:08 PM > To: ipv6-wg > Subject: Re: [ipv6-wg] dynamic or static IPv6 prefixes to residential > customers > > > On 27 Jul 2011, at 14:45, Ivan Pepelnjak wrote: > > > Unfortunately you have to do static prefix delegation because it's > impossible to renumber the customer's inside LAN within a reasonable time > interval with today's state of IPv6 SLAAC. > > Why impossible? > > Tim From evyncke at cisco.com Wed Jul 27 17:07:59 2011 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 27 Jul 2011 17:07:59 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: <004a01cc4c69$2952a1a0$7bf7e4e0$@info> References: <004101cc4c63$65e5bd10$31b13730$@info> <35A38C28-8B21-4253-9ECE-83B0048A488D@ecs.soton.ac.uk> <004a01cc4c69$2952a1a0$7bf7e4e0$@info> Message-ID: <317616CE96204D49B5A1811098BA895005092D2F@XMB-AMS-110.cisco.com> Ivan My understanding is that while a previous prefix cannot be removed by setting the lifetime to 0 (for the reason you cited) it can be deprecated instantly by setting the preferred timer to 0. Which has the same net effect of using the new prefix. -?ric > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Ivan Pepelnjak > Sent: mercredi 27 juillet 2011 10:26 > To: 'Tim Chown' > Cc: ipv6-wg at ripe.net > Subject: RE: [ipv6-wg] dynamic or static IPv6 prefixes to residential > customers > > There's a minimum timeout of 2 hours hard-coded in the SLAAC RFC to prevent > DoS attacks. Some details here: > > http://blog.ioshints.info/2010/12/small-site-multihoming-in-ipv6-mission.html > > Then there's the failure to detect PPPoE session loss: > > http://blog.ioshints.info/2010/10/dhcpv6-over-pppoe-total-disaster.html > > Last but definitely not least, CPEs tend to copy lease time from DHCPv6 PD to > SLAAC prefix validity time (and I found no way to change that behavior in > Cisco IOS), so you either overload your DHCPv6 server by using short leases > or risk having delegated prefixes that will stay in the customer's CPEs for a > long time. > > Ivan > > > -----Original Message----- > > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > > Tim Chown > > Sent: Wednesday, July 27, 2011 4:08 PM > > To: ipv6-wg > > Subject: Re: [ipv6-wg] dynamic or static IPv6 prefixes to residential > > customers > > > > > > On 27 Jul 2011, at 14:45, Ivan Pepelnjak wrote: > > > > > Unfortunately you have to do static prefix delegation because it's > > impossible to renumber the customer's inside LAN within a reasonable time > > interval with today's state of IPv6 SLAAC. > > > > Why impossible? > > > > Tim From tjc at ecs.soton.ac.uk Wed Jul 27 17:11:58 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 27 Jul 2011 16:11:58 +0100 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: <317616CE96204D49B5A1811098BA895005092D2F@XMB-AMS-110.cisco.com> References: <004101cc4c63$65e5bd10$31b13730$@info> <35A38C28-8B21-4253-9ECE-83B0048A488D@ecs.soton.ac.uk> <004a01cc4c69$2952a1a0$7bf7e4e0$@info> <317616CE96204D49B5A1811098BA895005092D2F@XMB-AMS-110.cisco.com> Message-ID: Yes, that's the RFC4192 method, which we have used for an enterprise (partial) renumber. I think Ivan's question is more about the CPE behaviour if there's a no-flag-day renumbering event? If the renumbering is planned, it ought to be possible to introduce the new prefix, turn down the preferred timer on the old one, run with both for a while, then remove the old prefix. If there's something the implementation or standards stopping that,what is it, and how do we fix it? I think something similar is supported in IOS if you use 6to4 and your CPE's IPv4 address changes - maybe Eric can comment on that. Not that I'd suggest using 6to4 any more ;) Tim On 27 Jul 2011, at 16:07, Eric Vyncke (evyncke) wrote: > Ivan > > My understanding is that while a previous prefix cannot be removed by setting the lifetime to 0 (for the reason you cited) it can be deprecated instantly by setting the preferred timer to 0. Which has the same net effect of using the new prefix. > > -?ric > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> Ivan Pepelnjak >> Sent: mercredi 27 juillet 2011 10:26 >> To: 'Tim Chown' >> Cc: ipv6-wg at ripe.net >> Subject: RE: [ipv6-wg] dynamic or static IPv6 prefixes to residential >> customers >> >> There's a minimum timeout of 2 hours hard-coded in the SLAAC RFC to prevent >> DoS attacks. Some details here: >> >> http://blog.ioshints.info/2010/12/small-site-multihoming-in-ipv6-mission.html >> >> Then there's the failure to detect PPPoE session loss: >> >> http://blog.ioshints.info/2010/10/dhcpv6-over-pppoe-total-disaster.html >> >> Last but definitely not least, CPEs tend to copy lease time from DHCPv6 PD to >> SLAAC prefix validity time (and I found no way to change that behavior in >> Cisco IOS), so you either overload your DHCPv6 server by using short leases >> or risk having delegated prefixes that will stay in the customer's CPEs for a >> long time. >> >> Ivan >> >>> -----Original Message----- >>> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >>> Tim Chown >>> Sent: Wednesday, July 27, 2011 4:08 PM >>> To: ipv6-wg >>> Subject: Re: [ipv6-wg] dynamic or static IPv6 prefixes to residential >>> customers >>> >>> >>> On 27 Jul 2011, at 14:45, Ivan Pepelnjak wrote: >>> >>>> Unfortunately you have to do static prefix delegation because it's >>> impossible to renumber the customer's inside LAN within a reasonable time >>> interval with today's state of IPv6 SLAAC. >>> >>> Why impossible? >>> >>> Tim > From evyncke at cisco.com Wed Jul 27 17:27:01 2011 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 27 Jul 2011 17:27:01 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <004101cc4c63$65e5bd10$31b13730$@info> <35A38C28-8B21-4253-9ECE-83B0048A488D@ecs.soton.ac.uk> <004a01cc4c69$2952a1a0$7bf7e4e0$@info> <317616CE96204D49B5A1811098BA895005092D2F@XMB-AMS-110.cisco.com> Message-ID: <317616CE96204D49B5A1811098BA895005092D5B@XMB-AMS-110.cisco.com> > > I think something similar is supported in IOS if you use 6to4 and your CPE's > IPv4 address changes - maybe Eric can comment on that. Not that I'd suggest > using 6to4 any more ;) Me neither (about using 6to4)... The advertized prefix in 'inside LAN' RA will change when the 'external WAN' IPv4 address change. But, I have no clue whether it will include the previous prefix with a preferred set to 0. Could be done by TCL & EEM. -?ric From D.Kalogeras at noc.ntua.gr Wed Jul 27 17:39:05 2011 From: D.Kalogeras at noc.ntua.gr (Dimitris Kalogeras) Date: Wed, 27 Jul 2011 18:39:05 +0300 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: <004a01cc4c69$2952a1a0$7bf7e4e0$@info> References: <004101cc4c63$65e5bd10$31b13730$@info> <35A38C28-8B21-4253-9ECE-83B0048A488D@ecs.soton.ac.uk> <004a01cc4c69$2952a1a0$7bf7e4e0$@info> Message-ID: <4E303119.7080305@noc.ntua.gr> Hi Ivan /et. al/, On top of these problems add the incorrect RFC behavior of MS (i.e. Win 7) clients when dealing prefixes whose lifetime is set to 0) and you end up puzzled. Should I deploy IPv6 on on top of PPPoE ? or directly on ethernet ifces ? should I ask my CPE vendors to break the strict RFC behavior ( for MS clients)? Cheers, Dimitris On 27/7/2011 5:26 ??, Ivan Pepelnjak wrote: > There's a minimum timeout of 2 hours hard-coded in the SLAAC RFC to prevent DoS attacks. Some details here: > > http://blog.ioshints.info/2010/12/small-site-multihoming-in-ipv6-mission.html > > Then there's the failure to detect PPPoE session loss: > > http://blog.ioshints.info/2010/10/dhcpv6-over-pppoe-total-disaster.html > > Last but definitely not least, CPEs tend to copy lease time from DHCPv6 PD to SLAAC prefix validity time (and I found no way to change that behavior in Cisco IOS), so you either overload your DHCPv6 server by using short leases or risk having delegated prefixes that will stay in the customer's CPEs for a long time. > > Ivan > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> Tim Chown >> Sent: Wednesday, July 27, 2011 4:08 PM >> To: ipv6-wg >> Subject: Re: [ipv6-wg] dynamic or static IPv6 prefixes to residential >> customers >> >> >> On 27 Jul 2011, at 14:45, Ivan Pepelnjak wrote: >> >>> Unfortunately you have to do static prefix delegation because it's >> impossible to renumber the customer's inside LAN within a reasonable time >> interval with today's state of IPv6 SLAAC. >> >> Why impossible? >> >> Tim -- ------------------------ Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Engineer Netmode NTUA Lab _____________________________________ skype: aweboy voice: +30-210-772 1448 fax: +30-210-772 1866 e-mail: D.Kalogeras at noc.ntua.gr -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at orlandi.com Wed Jul 27 18:47:19 2011 From: daniele at orlandi.com (Daniele Orlandi) Date: Wed, 27 Jul 2011 18:47:19 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: <004101cc4c63$65e5bd10$31b13730$@info> References: <004101cc4c63$65e5bd10$31b13730$@info> Message-ID: <201107271847.19517.daniele@orlandi.com> On Wednesday 27 July 2011 15:45:05 Ivan Pepelnjak wrote: > Unfortunately you have to do static prefix delegation because it's > impossible to renumber the customer's inside LAN within a reasonable time > interval with today's state of IPv6 SLAAC. > > However, static delegations might cause IPv6 routing table explosion unless Hi, My policy is to give semi-static prefixes, that is, prefixes that are statically associated to the customer for what concerns radius & such but have NO written GUARANTEE to remain permamently assigned to the user. So, if I need to renumber I can do it with little worries, maybe a notice to the user if I'm really good. The customer knows that he has to consider the prefix as not assigned to him, thus, if he wants to run a service on those addresses he has to be prepared to use a dynamic DNS service or such. Bye, From jan at go6.si Wed Jul 27 21:01:52 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 27 Jul 2011 21:01:52 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <4E3060A0.4020105@go6.si> On 7/27/11 3:02 PM, JORDI PALET MARTINEZ wrote: > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. static. no questions asked :) people should stop thinking with IPv4 minds, specially when designing big IPv6 networks (in multiple wrong and horrible IPv4 ways) Cheers, Jan From daniele at orlandi.com Wed Jul 27 21:46:02 2011 From: daniele at orlandi.com (Daniele Orlandi) Date: Wed, 27 Jul 2011 21:46:02 +0200 Subject: [ipv6-wg] dynamic or static IPv6 prefixes to residential customers In-Reply-To: <201107271847.19517.daniele@orlandi.com> References: <004101cc4c63$65e5bd10$31b13730$@info> <201107271847.19517.daniele@orlandi.com> Message-ID: <201107272146.02121.daniele@orlandi.com> On Wednesday 27 July 2011 18:47:19 Daniele Orlandi wrote: > > My policy is to give semi-static prefixes, that is, prefixes that are > statically associated to the customer for what concerns radius & such but > have NO written GUARANTEE to remain permamently assigned to the user. I forgot to add that if the customer wants such guarantee he may obtain it by paying an extra fee. Bye, -- Daniele "Vihai" Orlandi Bieco Illuminista #184213