From turchanyi.geza at gmail.com Fri Jul 1 11:54:26 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 1 Jul 2011 11:54:26 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> Message-ID: Hello Sander, Many thanks for your clarifications. However, I still think that the concept of implementing IPv6 PI address space never reached a full concensensus. Not even a rough one. We might run out of the routing tables before that IPv4 -> IPv6 transition goes above 80% -- this is a real danger! Let's accelarate the transition and come back to this issue whan it is almost complete! Thanks, G?za On Thu, Jun 30, 2011 at 11:04 PM, Sander Steffann wrote: > Hi, > > > We had this issue a few years ago over the proposal that required all PI > holders to have a contract with the NCC. Which was before the current PDP > had been finalised IIRC. The policy had reached consensus in the WG and it > was then a simple matter of implementation. Until the Board and management > realised what that entailed: hiring a small army of people to handle all the > paperwork for thousands of PI holders. The Board decided this was a Bad Idea > and asked the WG to reconsider. > > Just for the record: we had the PDP already at that point in time and the > objection was raised during last call. At no point in time has the board > asked the working group to reconsider a policy that had already reached full > consensus. The members of the board are also members of this community of > course, so they can object to a policy in the same way everybody can... > > > There is this ugly little gap in our policy making. The community which > makes policy (RIPE) is not necessarily the same as the people who pay for > that policy to be implemented (the NCC membership). The Board has to > straddle that gap somehow. OTOH, it can't "make policy" or get involved in > operational matters. On the other the Board has the usual responsibilities > to look after the interests of the organisation (the NCC) and its members. > > At some point we refined the PDP to include an impact analysis by the RIPE > NCC. Communication between the board and the WG and WG chairs has improved a > lot as well. So I feel confident that any potential problems in this area > will be openly discussed. > > Thanks, > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Jul 1 12:14:35 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 1 Jul 2011 12:14:35 +0200 (CEST) Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> Message-ID: On Fri, 1 Jul 2011, Turchanyi Geza wrote: > However, I still think that the concept of implementing IPv6 PI address > space never reached a full concensensus. Not even a rough one. Even though I oppose easy IPv6 PI, I'd still say I was in enough majority to warrant claim of at least rough consensus. > We might run out of the routing tables before that IPv4 -> IPv6 transition > goes above 80% -- this is a real danger! We're not going to run out, there is no such thing. There is only pain level to rise, it's not going to stop working. I'm sure there are vendors who'd happily sell you devices in a few years that'll do 10M routes in FIB if they thought there was market demand. -- Mikael Abrahamsson email: swmike at swm.pp.se From turchanyi.geza at gmail.com Fri Jul 1 12:46:49 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 1 Jul 2011 12:46:49 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> Message-ID: Hello, On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz wrote: > Hi, > > [...] > > > why do you expect a "sudden spike"? You know, IPv6 adoption is painfully > slow. > And actually, that's one of the points why some (most?) support the > proposal, to speed that up! > > Not the IPv4 PI address space holders create the real problems... > So, i'm a little confused now why this is bad. > > I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will > cause any problems at all, > or if bugs are trigged, no one knows. We'll have to see, or someone might > want to write a paper about it indeed :-) > > And why should THIS be a money issue? If you don't plan for 20k IPv6 > prefixes when buying new border routers nowadays, what the hell are you > doing? > And what "border-router-grade" hardware doesn't support this few prefixes? > > I'm FAR more concerned about IPv4 table growth/deaggregation after > exhaustion... > We are concerned as well! However, the two tables share the same phisical memory! > > -- > Mit freundlichen Gr??en / Kind Regards > > Sascha Lenz [SLZ-RIPE] > Senior System- & Network Architect > > G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Fri Jul 1 13:23:33 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 1 Jul 2011 13:23:33 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> Message-ID: <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Hi, > Hello, > > On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz wrote: > Hi, > > [...] > > > why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. > And actually, that's one of the points why some (most?) support the proposal, to speed that up! > > > Not the IPv4 PI address space holders create the real problems... > I beg to differ, IPv4 is the problem, completely independent of "PI" and "PA" or anything we do with IPv6, by design. > So, i'm a little confused now why this is bad. > > I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, > or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-) > > And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? > And what "border-router-grade" hardware doesn't support this few prefixes? > > I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion... > > We are concerned as well! However, the two tables share the same phisical memory! > > And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that). Are you saying that we should not deploy IPv6? Guys, really, cope with the reality. Don't be like politicians and create FUD. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From mark at townsley.net Fri Jul 1 13:24:08 2011 From: mark at townsley.net (Mark Townsley) Date: Fri, 1 Jul 2011 13:24:08 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> Message-ID: <25924B23-6918-4692-8DE5-BCB295AB64C5@townsley.net> On Jul 1, 2011, at 12:46 PM, Turchanyi Geza wrote: > Hello, > > On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz wrote: > Hi, > > [...] > > > why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. > And actually, that's one of the points why some (most?) support the proposal, to speed that up! > > > Not the IPv4 PI address space holders create the real problems... > > So, i'm a little confused now why this is bad. > > I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, > or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-) > > And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? > And what "border-router-grade" hardware doesn't support this few prefixes? > > I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion... > > We are concerned as well! However, the two tables share the same phisical memory! Not to mention all the routes in the various VRFs - a large L3VPN deployment can surpass a single instance of the global v4 and v6 table combined... ...all a pittance of course compared to the state in a big CGN. - Mark > > > -- > Mit freundlichen Gr??en / Kind Regards > > Sascha Lenz [SLZ-RIPE] > Senior System- & Network Architect > > G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Jul 1 13:41:59 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 1 Jul 2011 13:41:59 +0200 (CEST) Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Message-ID: On Fri, 1 Jul 2011, Sascha Lenz wrote: > And why do you have gear that got no problem with an exploding IPv4 > table after exhaustion, but can't cope with 20k IPv6 prefixes? I still > don't get that. Please, someone finally explain to me why 20k or even > 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year > old Ciscos and Junipers have no problems with that right now. The > default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for > example (IIRC, was some time ago i tested that). 20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem. Right now the PI administration and implementation process is a barrier for entry, but if this changes then the amount of people who will want (and will get) PI might explode. Therefore the situation needs to be monitored, because having all core routers in the world keep track of every little entity who wants to redundantly connect to the Internet isn't going to scale. The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. -- Mikael Abrahamsson email: swmike at swm.pp.se From andrei.robachevsky at gmail.com Fri Jul 1 13:51:25 2011 From: andrei.robachevsky at gmail.com (Andrei Robachevsky) Date: Fri, 01 Jul 2011 13:51:25 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <1309374260.2558.72.camel@shane-desktop> References: <1309374260.2558.72.camel@shane-desktop> Message-ID: <4E0DB4BD.90409@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shane Kerr wrote on 29/06/2011 21:04: [...] > My further understanding is that desire for PI is mostly for > non-technical reasons. I don't think anything can make this motivation > go away. Companies want it. > PI also has non-technical implications. In terms of the maintenance fee, accountability, etc. So far it has been a loophole letting you to get a chunk bigger that the minimum allocation size for a fixed Eur50 (+your friendly LIR overhead) per year. But hopefully this can be fixed outside this policy proposal. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk4NtL0ACgkQljz5tZmtij/78ACglSCfJWLmlw+BXCSmnrLe7ElS QW0AmJsPEEld+8H1iM5Zo6rzIrDMZLw= =QzBb -----END PGP SIGNATURE----- From turchanyi.geza at gmail.com Fri Jul 1 13:54:53 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 1 Jul 2011 13:54:53 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Message-ID: Hello, Yes, IPv4 only is a problem ;-)) Please, do not create more problem now! The limits of the content addressable memory on line card are problematic! Unfortunately the IPv4 address space trading will increase the memory size needed for IPv4 already. If you introduce IPv6 PI address space, who could stop to explode this space in the near future? Best, G?za On Fri, Jul 1, 2011 at 1:23 PM, Sascha Lenz wrote: > Hi, > > > > Hello, > > > > On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz wrote: > > Hi, > > > > [...] > > > > > > why do you expect a "sudden spike"? You know, IPv6 adoption is painfully > slow. > > And actually, that's one of the points why some (most?) support the > proposal, to speed that up! > > > > > > Not the IPv4 PI address space holders create the real problems... > > > > > I beg to differ, IPv4 is the problem, completely independent of "PI" and > "PA" or anything we do with IPv6, by design. > > > So, i'm a little confused now why this is bad. > > > > I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will > cause any problems at all, > > or if bugs are trigged, no one knows. We'll have to see, or someone might > want to write a paper about it indeed :-) > > > > And why should THIS be a money issue? If you don't plan for 20k IPv6 > prefixes when buying new border routers nowadays, what the hell are you > doing? > > And what "border-router-grade" hardware doesn't support this few > prefixes? > > > > I'm FAR more concerned about IPv4 table growth/deaggregation after > exhaustion... > > > > We are concerned as well! However, the two tables share the same phisical > memory! > > > > > > And why do you have gear that got no problem with an exploding IPv4 table > after exhaustion, but > can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone > finally explain to me > why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, > even my 5year old Ciscos and Junipers > have no problems with that right now. > The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for > example (IIRC, was some time ago i tested that). > > Are you saying that we should not deploy IPv6? > > Guys, really, cope with the reality. Don't be like politicians and create > FUD. > > -- > Mit freundlichen Gr??en / Kind Regards > > Sascha Lenz [SLZ-RIPE] > Senior System- & Network Architect > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Fri Jul 1 13:58:00 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 1 Jul 2011 13:58:00 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Message-ID: <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> Hi, Am 01.07.2011 um 13:41 schrieb Mikael Abrahamsson: > On Fri, 1 Jul 2011, Sascha Lenz wrote: > >> And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that). > > 20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem. > You are in the IT business and you really think about 30+ years from now? Rather sounds like a science fiction author to me :-) > Right now the PI administration and implementation process is a barrier for entry, but if this changes then the amount of people who will want (and will get) PI might explode. Therefore the situation needs to be monitored, because having all core routers in the world keep track of every little entity who wants to redundantly connect to the Internet isn't going to scale. > This wasn't a real problem in the IPv4 world, i really doubt that is an immanent problem in the IPv6 world if the policies are identical; by design, most entities will have a single prefix (or per site worst case) and stay with that for most of their days. I'm not sure why there should be a higher IPv6 "PI" usage rate than for IPv4. > The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From mohta at necom830.hpcl.titech.ac.jp Fri Jul 1 13:55:46 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 01 Jul 2011 20:55:46 +0900 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Message-ID: <4E0DB5C2.9000004@necom830.hpcl.titech.ac.jp> Mikael Abrahamsson wrote: > 20k isn't a problem, 100k isn't really a problem, potentially 5M 30 > years down the line might be a problem, 50M is most likely a problem. The problem is on prefix length over which backbone routers must take care of. 16M is not a problem if they are confined within /24. However, 5M scattered in /28 might be a problem. > The real solution is to have end systems handle session handover between > multiple addresses it has, but there seems to be pitifully little > traction for that. Yes, that is the real problem. Masataka Ohta From Jasper.Jans at espritxb.nl Fri Jul 1 13:54:33 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Fri, 1 Jul 2011 13:54:33 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039B4CE102@EXCH01.campus.local> Are we really making an issue out of things that might not fit in a DFZ 30 years from now under the restrictions current - potentially already old(er) hardware has today? Who is really expecting to run the same boxes they do today 10 years from now - let alone 30 years? Jasper -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Mikael Abrahamsson Sent: Friday, July 01, 2011 1:42 PM To: Sascha Lenz Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Source of routing table growth On Fri, 1 Jul 2011, Sascha Lenz wrote: > And why do you have gear that got no problem with an exploding IPv4 > table after exhaustion, but can't cope with 20k IPv6 prefixes? I still > don't get that. Please, someone finally explain to me why 20k or even > 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year > old Ciscos and Junipers have no problems with that right now. The > default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for > example (IIRC, was some time ago i tested that). 20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem. Right now the PI administration and implementation process is a barrier for entry, but if this changes then the amount of people who will want (and will get) PI might explode. Therefore the situation needs to be monitored, because having all core routers in the world keep track of every little entity who wants to redundantly connect to the Internet isn't going to scale. The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. -- Mikael Abrahamsson email: swmike at swm.pp.se Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From slz at baycix.de Fri Jul 1 14:16:44 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 1 Jul 2011 14:16:44 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> Message-ID: <4F4697D1-F3BA-471D-9D73-4E6C4948822C@baycix.de> Hi, > Hello, > > Yes, IPv4 only is a problem ;-)) > > Please, do not create more problem now! The limits of the content addressable memory on line card are problematic! > > Unfortunately the IPv4 address space trading will increase the memory size needed for IPv4 already. > > If you introduce IPv6 PI address space, who could stop to explode this space in the near future? i'm officially out of arguments now. We already have IPv6 PI, that's not gonna change. We're only about to level the IPv4 and IPv6 PI policies. You can either have people stay with IPv4 for a longer period as necessary, creating a faster and faster IPv4 table growth because they stick with this old legacy protocol, buying (and announcing) smaller and smaller IPv4 prefixes because they cannot migrate to IPv6 due to the policies being different, or you can allow the same rules for both worlds, give everyone their (most likely only ever) IPv6 prefix and have the v4 table stop growing earlier because people migrate faster. I think it's clear what we should chose. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From gert at space.net Fri Jul 1 14:20:50 2011 From: gert at space.net (Gert Doering) Date: Fri, 1 Jul 2011 14:20:50 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <4E0DB4BD.90409@gmail.com> References: <1309374260.2558.72.camel@shane-desktop> <4E0DB4BD.90409@gmail.com> Message-ID: <20110701122050.GZ2304@Space.Net> Hi, On Fri, Jul 01, 2011 at 01:51:25PM +0200, Andrei Robachevsky wrote: > PI also has non-technical implications. In terms of the maintenance fee, > accountability, etc. So far it has been a loophole letting you to get a > chunk bigger that the minimum allocation size for a fixed Eur50 (+your > friendly LIR overhead) per year. > > But hopefully this can be fixed outside this policy proposal. These are contractual and payment matters, and are outside the scope of this particular policy proposal. Nevertheless, it's being worked on - Jochem de Ruig (NCC finances) and the NCC board are working on a new charging scheme that should solve some of *these* problems. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From swmike at swm.pp.se Fri Jul 1 14:30:47 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 1 Jul 2011 14:30:47 +0200 (CEST) Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> Message-ID: On Fri, 1 Jul 2011, Sascha Lenz wrote: > You are in the IT business and you really think about 30+ years from > now? Rather sounds like a science fiction author to me :-) Yes, I do. I consider that a responsible approach. IPv4 lasted ~30 years before it ran into serious problems, I want IPv6 to last a lot longer. I also want it to scale so everybody can use it. > This wasn't a real problem in the IPv4 world, i really doubt that is an > immanent problem in the IPv6 world if the policies are identical; by > design, most entities will have a single prefix (or per site worst case) > and stay with that for most of their days. Yes, but the problem is if everybody (or even 1%) in the world wants to multihome, then it doesn't scale. > I'm not sure why there should be a higher IPv6 "PI" usage rate than for > IPv4. Because more and more people (and companies) are adopting Internet usage and in 20-30 years time the demand for multihoming is most likely going to substantially higher than today. -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Fri Jul 1 14:33:32 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Jul 2011 14:33:32 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> Message-ID: <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> Hi Sascha, >> The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. > > I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace > BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed. Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-) Thanks, Sander From turchanyi.geza at gmail.com Fri Jul 1 16:38:36 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Fri, 1 Jul 2011 16:38:36 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> Message-ID: Hello, On Fri, Jul 1, 2011 at 12:14 PM, Mikael Abrahamsson wrote: We're not going to run out, there is no such thing. There is only pain level > to rise, it's not going to stop working. I'm sure there are vendors who'd > happily sell you devices in a few years that'll do 10M routes in FIB if they > thought there was market demand. > > > Then ALL the routers in the backbone MUST be changed... is this a real alternative? Just for a bad decision? What about speed of convergence of there will be so many routes? Handling the limits of routes allowed today in first class backbone needs already long time, is n't it? Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Fri Jul 1 17:06:33 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 1 Jul 2011 17:06:33 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> Message-ID: <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> Hi, > > On Fri, Jul 1, 2011 at 12:14 PM, Mikael Abrahamsson wrote: > > We're not going to run out, there is no such thing. There is only pain level to rise, it's not going to stop working. I'm sure there are vendors who'd happily sell you devices in a few years that'll do 10M routes in FIB if they thought there was market demand. > > > > Then ALL the routers in the backbone MUST be changed... is this a real alternative? > Yes, all hardware will have to be replaced with new ones eventually for upgrades. That's just natural. I had to replace all the c3640s in my core 10years ago, too. And i will have to replace my current gear sooner or later. What's the big deal? > Just for a bad decision? > No, it's a bad decision to use old gear for longer than their supposed lifetime. Probably you should check your business plan if you can't keep up with upgrading your gear, especially if you're running a network oriented business. > What about speed of convergence of there will be so many routes? > > Handling the limits of routes allowed today in first class backbone needs already long time, is n't it? > Do you have any evidence about this? Would love to read about the actual numbers. (That's not a rhetorical question, i really have no clue if there's a problem, i don't see any in the networks i manage, it never came up, but that doesn't mean there isn't one.) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From slz at baycix.de Fri Jul 1 17:22:03 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 1 Jul 2011 17:22:03 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> Message-ID: <0529070D-E6DF-4CE0-B9A7-0A832ED9BFF2@baycix.de> Hi, > Hi Sascha, > >>> The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. >> >> I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace >> BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed. > > Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-) > indeed! I am not scientist, i have no clue about how this problem can be solved, and since no one came up with anything better than SHIM the last decade, i guess BGP multihoming just cannot be replaced. Though, i've always explained to my clients that there are more easy and possibly cheaper options in most cases, and everyone else should inform their clients about alternatives, too. I have a poor opinion of those PI-shop-ISPs out there, they are doing something seriously wrong. But probably that's only a money issue which might be hopefully fixed with a new charging scheme (but forgive me if i am not convinced yet, dear NCC :-) ). But in the end, if the End-user WANTS and NEEDS independent resources, and can not live with anything else, i strongly disagree with deliberately preventing them from getting a slot in the routing table, or charging insane amounts of money for that. That's not the "internet spirit" i grew up with. ==> Work with your customers, most are easily convinced that bad BGP management can break more and cost more than more simple alternatives. Best we all can do. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From sander at steffann.nl Fri Jul 1 17:45:38 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Jul 2011 17:45:38 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> Message-ID: Hi, > Do you have any evidence about this? Would love to read about the actual numbers. > (That's not a rhetorical question, i really have no clue if there's a problem, i don't see any in the networks i manage, > it never came up, but that doesn't mean there isn't one.) This is not only related to the number of prefixes but also to the frequency with which the announcements of those prefixes are updated. IIRC there was something like the 20/80 rule here, in that 20% of the prefixes cause 80% of the updates. If we look at PI prefixes: I suspect most of those updates are for TE, and because a PI /48 is difficult to split into multiple smaller announcements I suspect the PI prefixes will belong to the 80% group that only cause 20% of the updates. This is just guess-work though. If someone can point me to decent research on this I would really appreciate it! Sander From danrl.mailinglists at googlemail.com Fri Jul 1 18:14:25 2011 From: danrl.mailinglists at googlemail.com (Dan Luedtke) Date: Fri, 1 Jul 2011 18:14:25 +0200 Subject: [address-policy-wg] 2011-02 Removal of multihomed requirement for IPv6 PI Message-ID: Dear Community, I can't wait for this change to happen. As I discussed at IPv6 Kongress in Frankfurt, Germany, there are more than a handful of people wanting that change. For example, I have an IPv4 PI network and adopted early to IPv6 using an IPv6 PA network. Never did, nor will I ever understand why multihoming is required for an IPv6 PI network but not for an IPv4 PI network. I support this draft and like to thank everyone who made it happen. This is an important step awaited by me and many others, even if the community decides not to do it. best regards, Dan Luedtke -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Jul 1 19:23:59 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 1 Jul 2011 19:23:59 +0200 (CEST) Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> Message-ID: On Fri, 1 Jul 2011, Sascha Lenz wrote: > I had to replace all the c3640s in my core 10years ago, too. And i will > have to replace my current gear sooner or later. What's the big deal? The big deal is that this gear might have a few more years in them for forwarding purposes, but they now have to be changed due to FIB size reason solely. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sat Jul 2 02:27:22 2011 From: randy at psg.com (Randy Bush) Date: Sat, 02 Jul 2011 09:27:22 +0900 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> Message-ID: > This is not only related to the number of prefixes but also to the > frequency with which the announcements of those prefixes are > updated. IIRC there was something like the 20/80 rule here, in that > 20% of the prefixes cause 80% of the updates. would be interesting if someone had actually measured this :) Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush, and Keyur Patel, Route Flap Damping Made Usable, in PAM 2011, March 2011. randy From sander at steffann.nl Sat Jul 2 02:42:09 2011 From: sander at steffann.nl (Sander Steffann) Date: Sat, 2 Jul 2011 02:42:09 +0200 Subject: [address-policy-wg] Board position on 2011-02 In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <6BC53314-2958-4F9B-98D4-156A200D8AC3@rfc1035.com> <18AFE45D-A373-4EA0-A8F0-2AB2ECB8E4F7@steffann.nl> <0F8FE8D0-9BE0-4D61-9401-E7D9F6999E21@baycix.de> Message-ID: >> This is not only related to the number of prefixes but also to the >> frequency with which the announcements of those prefixes are >> updated. IIRC there was something like the 20/80 rule here, in that >> 20% of the prefixes cause 80% of the updates. > > > would be interesting if someone had actually measured this :) > > Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush, and Keyur > Patel, Route Flap Damping Made Usable, in PAM 2011, March 2011. Thanks, Sander From mohta at necom830.hpcl.titech.ac.jp Sat Jul 2 09:35:02 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 02 Jul 2011 16:35:02 +0900 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> Message-ID: <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: > Getting a good solution for this is _very_ important to limit > routing table growth. Many people/organizations probably > don't want the hassle of BGP if they can get more redundancy > and less dependencies on a single ISP (easier renumbering > will help too) in a simpler way. But this is IETF territory, > not RIPE :-) IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs. Is it time to ressurect RFC2374? Masataka Ohta From sander at steffann.nl Sat Jul 2 12:18:16 2011 From: sander at steffann.nl (Sander Steffann) Date: Sat, 2 Jul 2011 12:18:16 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> Message-ID: <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> Hi Masataka, > IETF can do nothing unless ISPs of RIPE and other RIRs accept > the restriction that only very large ISPs can have their own > global routing table entries and address spaces of other ISPs > must be delegated from those of the very large ISPs. You don't make sense. We're not talking about ISPs here, we're talking about end users. And the IETF can define standards for that. - Sander From nick at inex.ie Sat Jul 2 12:25:03 2011 From: nick at inex.ie (Nick Hilliard) Date: Sat, 02 Jul 2011 11:25:03 +0100 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> Message-ID: <4E0EF1FF.7080101@inex.ie> On 02/07/2011 08:35, Masataka Ohta wrote: > IETF can do nothing unless ISPs of RIPE and other RIRs accept > the restriction that only very large ISPs can have their own > global routing table entries and address spaces of other ISPs > must be delegated from those of the very large ISPs. Why not put forward a proposal to the APWG along these lines then? Nick From mohta at necom830.hpcl.titech.ac.jp Sat Jul 2 13:44:06 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 02 Jul 2011 20:44:06 +0900 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> Message-ID: <4E0F0486.6020204@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: >> IETF can do nothing unless ISPs of RIPE and other RIRs accept >> the restriction that only very large ISPs can have their own >> global routing table entries and address spaces of other ISPs >> must be delegated from those of the very large ISPs. > > You don't make sense. We're not talking about ISPs here, we're talking > about end users. Considering that end users won't not directly suffer from nor complain about routing table explosions, but some clever ISPs may, we should be talking about ISPs, a collection of which is RIPE. Yes, ISPs through RIRs are the source of problems. > And the IETF can define standards for that. The distance between IETF and end users is, mostly, infinite. Masataka Ohta From Woeber at CC.UniVie.ac.at Sun Jul 3 20:12:35 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Sun, 03 Jul 2011 18:12:35 +0000 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E0F0486.6020204@necom830.hpcl.titech.ac.jp> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> <4E0F0486.6020204@necom830.hpcl.titech.ac.jp> Message-ID: <4E10B113.9070805@CC.UniVie.ac.at> Masataka Ohta wrote: [...] > Yes, ISPs through RIRs are the source of problems. > >>And the IETF can define standards for that. > > The distance between IETF and end users is, mostly, infinite. > > Masataka Ohta Some of the participants in this discussion seem to forget, always now and then, that the 'net and the ISPs are not existing for the benefit of themselves, but in order to provide service(s) to the users. Most of the time, the "infinitely distant users" are the primary soure of the money that keeps the 'net, the ISPs, the RIRs (and the scientists) in business. ;-) Wilfried. From jan at go6.si Sun Jul 3 20:44:08 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 03 Jul 2011 20:44:08 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> Message-ID: <4E10B878.2090107@go6.si> On 7/2/11 9:35 AM, Masataka Ohta wrote: > Sander Steffann wrote: > >> Getting a good solution for this is _very_ important to limit >> routing table growth. Many people/organizations probably >> don't want the hassle of BGP if they can get more redundancy >> and less dependencies on a single ISP (easier renumbering >> will help too) in a simpler way. But this is IETF territory, >> not RIPE :-) > > IETF can do nothing unless ISPs of RIPE and other RIRs accept > the restriction that only very large ISPs can have their own > global routing table entries and address spaces of other ISPs > must be delegated from those of the very large ISPs. RIPE is not a place to discuss this, as RIPE is all about resources allocation and policies around that, not how resources are used. IETF is not a place to discuss that, as if we understand what IETF stands for - that's engineering body that makes protocols and standards, not how resources are used. So we need new institution for that, let's call it "Internet Routing Police". Should I start filling in the registration papers for new not-for-profit institute with that name? :) Cheers, Jan Zorz From dr at cluenet.de Sun Jul 3 22:01:04 2011 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 3 Jul 2011 22:01:04 +0200 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: <4E10B878.2090107@go6.si> References: <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <4E10B878.2090107@go6.si> Message-ID: <20110703200104.GA32733@srv03.cluenet.de> On Sun, Jul 03, 2011 at 08:44:08PM +0200, Jan Zorz @ go6.si wrote: > RIPE is not a place to discuss this, as RIPE is all about resources > allocation and policies around that, not how resources are used. RIPE has a long history of dealing with things outside of the resource allocation and policy matters. With the IPv6 equipment requirement document (RIPE-501) - authored partly by yourself - being the most "offtopic" one I'm aware of. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From swmike at swm.pp.se Sun Jul 3 22:14:41 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 3 Jul 2011 22:14:41 +0200 (CEST) Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E10B113.9070805@CC.UniVie.ac.at> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> <4E0F0486.6020204@necom830.hpcl.titech.ac.jp> <4E10B113.9070805@CC.UniVie.ac.at> Message-ID: On Sun, 3 Jul 2011, Wilfried Woeber, UniVie/ACOnet wrote: > Some of the participants in this discussion seem to forget, always now > and then, that the 'net and the ISPs are not existing for the benefit of > themselves, but in order to provide service(s) to the users. Most of the > time, the "infinitely distant users" are the primary soure of the money > that keeps the 'net, the ISPs, the RIRs (and the scientists) in > business. ;-) Correct, and most users do not have a PI and thus it's unfair to them if PI usage increase means their ISP has to swap equipment prematurely. -- Mikael Abrahamsson email: swmike at swm.pp.se From jan at go6.si Sun Jul 3 23:49:24 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 03 Jul 2011 23:49:24 +0200 Subject: [address-policy-wg] Re: Source of routing table growth In-Reply-To: <20110703200104.GA32733@srv03.cluenet.de> References: <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <4E10B878.2090107@go6.si> <20110703200104.GA32733@srv03.cluenet.de> Message-ID: <4E10E3E4.6090302@go6.si> On 7/3/11 10:01 PM, Daniel Roesen wrote: > On Sun, Jul 03, 2011 at 08:44:08PM +0200, Jan Zorz @ go6.si wrote: >> RIPE is not a place to discuss this, as RIPE is all about resources >> allocation and policies around that, not how resources are used. > > RIPE has a long history of dealing with things outside of the resource > allocation and policy matters. With the IPv6 equipment requirement > document (RIPE-501) - authored partly by yourself - being the most > "offtopic" one I'm aware of. Hi, I agree :) But there is difference between BCP and policy. If we can fix routing table growth with BCP, then let's try :) What I'm afraid here is that we need stronger means than BCP for this matter. Cheers, Jan From turchanyi.geza at gmail.com Mon Jul 4 04:50:05 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Mon, 4 Jul 2011 04:50:05 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E10B113.9070805@CC.UniVie.ac.at> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> <4E0F0486.6020204@necom830.hpcl.titech.ac.jp> <4E10B113.9070805@CC.UniVie.ac.at> Message-ID: Dear Wilfried and Masataka. Both of you were right and both of you may be pleased by the new HOMENET working group of IETF, proposed recently by Jari Arko. (I proposed earlier a similar research initiative for FP7...) Best, G?za On Sun, Jul 3, 2011 at 8:12 PM, Wilfried Woeber, UniVie/ACOnet < Woeber at cc.univie.ac.at> wrote: > Masataka Ohta wrote: > [...] > > Yes, ISPs through RIRs are the source of problems. > > > >>And the IETF can define standards for that. > > > > The distance between IETF and end users is, mostly, infinite. > > > > Masataka Ohta > > Some of the participants in this discussion seem to forget, always now and > then, > that the 'net and the ISPs are not existing for the benefit of themselves, > but > in order to provide service(s) to the users. Most of the time, the > "infinitely > distant users" are the primary soure of the money that keeps the 'net, the > ISPs, > the RIRs (and the scientists) in business. ;-) > > Wilfried. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at bfk.de Mon Jul 4 09:37:40 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 04 Jul 2011 07:37:40 +0000 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> (Sander Steffann's message of "Sat, 2 Jul 2011 12:18:16 +0200") References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> Message-ID: <8262nicx8b.fsf@mid.bfk.de> * Sander Steffann: > Hi Masataka, > >> IETF can do nothing unless ISPs of RIPE and other RIRs accept >> the restriction that only very large ISPs can have their own >> global routing table entries and address spaces of other ISPs >> must be delegated from those of the very large ISPs. > > You don't make sense. We're not talking about ISPs here, we're talking > about end users. And the IETF can define standards for that. The ISP vs end user distinction is very fuzzy. Even the RIPE policy documents don't use the terms consistently. And in most contexts, the term "ISP" includes companies mainly providing web and mail hosting services. -- 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 boggits at gmail.com Sat Jul 2 12:28:05 2011 From: boggits at gmail.com (boggits) Date: Sat, 2 Jul 2011 11:28:05 +0100 Subject: [address-policy-wg] 2011-02 Removal of multihomed requirement for IPv6 PI In-Reply-To: References: Message-ID: On 1 July 2011 17:14, Dan Luedtke wrote: > Dear Community, > I can't wait for this change to happen. As I discussed at IPv6 Kongress in > Frankfurt, Germany, there are more than a handful of people wanting that > change. For example, I have an IPv4 PI network and adopted early to IPv6 > using an IPv6 PA network. Okay, that sounds like you have a real reason for the change, can you please explain why (other than end users think they want/need it) ? > Never did, nor will I ever understand why > multihoming is required for an IPv6 PI network but not for an IPv4 PI > network. Given the choice I would quite willingly write a proposal IPv4 PI requires multihoming but that would be a return to deckchair arranging... J -- James Blessing 07989 039 476 From adrian.czapek at rybnet.pl Sat Jul 2 13:56:18 2011 From: adrian.czapek at rybnet.pl (Adrian Czapek) Date: Sat, 02 Jul 2011 13:56:18 +0200 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <4E0EF1FF.7080101@inex.ie> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <4E0EF1FF.7080101@inex.ie> Message-ID: <4E0F0762.9070406@rybnet.pl> W dniu 2011-07-02 12:25, Nick Hilliard pisze: > On 02/07/2011 08:35, Masataka Ohta wrote: >> IETF can do nothing unless ISPs of RIPE and other RIRs accept >> the restriction that only very large ISPs can have their own >> global routing table entries and address spaces of other ISPs >> must be delegated from those of the very large ISPs. > > Why not put forward a proposal to the APWG along these lines then? > Who will be the one to define "very large" ? -- Adrian From mohta at necom830.hpcl.titech.ac.jp Mon Jul 4 13:47:01 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 04 Jul 2011 20:47:01 +0900 Subject: [address-policy-wg] Source of routing table growth In-Reply-To: <8262nicx8b.fsf@mid.bfk.de> References: <1309374260.2558.72.camel@shane-desktop> <1309422136.2793.35.camel@shane-desktop> <6EBCFFCD-2F98-492E-86D7-3FC769F84657@baycix.de> <018977A2-C370-4200-BA31-FA3FCDE848B0@baycix.de> <76E01B65-C750-429D-A279-29147B0B47F3@baycix.de> <1EDEE95D-0F3D-4A6C-AE96-6E5924A05021@steffann.nl> <4E0ECA26.60503@necom830.hpcl.titech.ac.jp> <6236380D-363D-444C-9BF9-865775F665B2@steffann.nl> <8262nicx8b.fsf@mid.bfk.de> Message-ID: <4E11A835.5040404@necom830.hpcl.titech.ac.jp> Florian Weimer wrote: >>> IETF can do nothing unless ISPs of RIPE and other RIRs accept >>> the restriction that only very large ISPs can have their own >>> global routing table entries and address spaces of other ISPs >>> must be delegated from those of the very large ISPs. > The ISP vs end user distinction is very fuzzy. Even the RIPE policy > documents don't use the terms consistently. And in most contexts, the > term "ISP" includes companies mainly providing web and mail hosting > services. While I wrote "ISPs of RIPE and other RIRs", which should exclude end users, more general requirement is: only a small number of entities can have their own global routing table entries and if limited number of routing table entries are sold: only a very rich entities can have their own global routing table entries But, the first question is whether ISPs of RIPE can accept the requirement. If not, there is no point to ask other entities accept the requirement. Adrian Czapek wrote: > Who will be the one to define "very large" ? It depends on how global routing table entries are obtained. For an example, see above. Political power may also be useful. Masataka Ohta From ronak at nav6.org Tue Jul 5 04:13:50 2011 From: ronak at nav6.org (Ronak Banka) Date: Tue, 05 Jul 2011 10:13:50 +0800 Subject: [address-policy-wg] Information Regarding AS paths Message-ID: <1e5a5966e53f5a53a3422ebd7976ce84@mail.nav6.org> Dear Members, I am working on a project and I am stuck at a point where I am in need of AS paths, Is there any way to get AS path for all the AS numbers registered under RIPE RIR ?? -- Ronak Banka Internship student From shane at time-travellers.org Tue Jul 5 10:37:02 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 05 Jul 2011 10:37:02 +0200 Subject: [address-policy-wg] Information Regarding AS paths In-Reply-To: <1e5a5966e53f5a53a3422ebd7976ce84@mail.nav6.org> References: <1e5a5966e53f5a53a3422ebd7976ce84@mail.nav6.org> Message-ID: <1309855022.2677.19.camel@shane-desktop> Ronak, On Tue, 2011-07-05 at 10:13 +0800, Ronak Banka wrote: > I am working on a project and I am stuck at a point where I am in need of > AS paths, Is there any way to get AS path for all the AS numbers registered > under RIPE RIR ?? This is probably a question more for the routing working group, but I'll answer it here. There is literally no way to get all of the AS paths for all of the AS numbers. The BGP protocol generates AS paths, and it does not provide a way to get all of them other than by looking at every router on the Internet. However, the RIPE NCC runs the routing information service (RIS), which provides many ways to view routing information. This may be a good place to start: http://www.ripe.net/data-tools/stats/ris/routing-information-service -- Shane From davidm at futureinquestion.net Fri Jul 8 00:35:53 2011 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 08 Jul 2011 00:35:53 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <20110628105851.940F46A003@postboy.ripe.net> References: <20110628105851.940F46A003@postboy.ripe.net> Message-ID: <4E1634C9.1050702@futureinquestion.net> Dear address-policy-wg, On 06/28/2011 12:58 PM, Emilio Madaio wrote: > Dear Colleagues, > > The draft document for the proposal described in 2011-02 has been > published. The impact analysis that was conducted for this proposal > has also been published. > I would like to express my support for this proposal. Furthermore, I find the section 'E. RIPE NCC Executive Board' to be somewhat in bad taste; not only is it not the community's province to convince the RIPE NCC board of the merit of its ideas, the section also lacks any concrete facts, operational burden estimates or specific concerns and instead appears to do little more than attempt to tilt the opinion of the undecided against this proposal. -- Respectfully yours, David Monosov From rogerj at gmail.com Fri Jul 8 09:32:46 2011 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Fri, 8 Jul 2011 09:32:46 +0200 Subject: [address-policy-wg] 2011-01 New Draft Document Published (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA) In-Reply-To: <20110624154538.AED1F6A013@postboy.ripe.net> References: <20110624154538.AED1F6A013@postboy.ripe.net> Message-ID: On Fri, Jun 24, 2011 at 5:05 PM, Emilio Madaio wrote: > > Dear Colleagues > > The draft document for the proposal described in 2011-01 has been > published. The impact analysis that was conducted for this proposal > has also been published > > > You can find the full proposal and the impact analysis at: > > ? ?http://www.ripe.net/ripe/policies/proposals/2011-01 > > and the draft document at: > > ? ?http://www.ripe.net/ripe/policies/proposals/2011-01/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 22 July 2011. Why are you using /24 and not /23 or something bigger? ... I realize there might be huge amount of /24 in between but still, wouldn't that just hurt the "routing table" everyone are so afraid of more than it help Internet with fresh IPv4 where desperately needed? -- Roger Jorgensen? ? ? ? ?? | rogerj at gmail.com? ? ? ? ? | - IPv6 is The Key! http://www.jorgensen.no?? | roger at jorgensen.no From nigel at titley.com Fri Jul 8 15:11:58 2011 From: nigel at titley.com (Nigel Titley) Date: Fri, 08 Jul 2011 14:11:58 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <4E1634C9.1050702@futureinquestion.net> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> Message-ID: <4E17021E.5000208@titley.com> On 07/07/2011 23:35, David Monosov wrote: > > Furthermore, I find the section 'E. RIPE NCC Executive Board' to be somewhat in > bad taste; not only is it not the community's province to convince the RIPE NCC > board of the merit of its ideas, the section also lacks any concrete facts, > operational burden estimates or specific concerns and instead appears to do > little more than attempt to tilt the opinion of the undecided against this > proposal. The RIPE NCC board has a duty to remain in touch with the proposals currently being considered by the RIPE community, mainly to ensure that such proposals, if they are accepted by the community, do not raise unacceptable risks to the operations, financial and otherwise, of the RIPE NCC. In that sense the community *does* have to convince the RIPE NCC board of the merits of its ideas as the board has an ultimate responsibility (under law) to ensure that the RIPE NCC operates in a fiscally sensible manner. It also has a responsibility to its members which, although they have an extensive overlap with the RIPE community, are not the the same thing. In the RIPE region, the NCC Board operates with an extremely light touch. In other regions policy has to be signed off by the board as a final stage of acceptance and they can veto what they consider to be unacceptable policy. This does not happen in this region. Instead the board remains au fait with policy development and feeds their comments into the RIPE NCC evaluation of the policy. That is what you are seeing here, no more and no less. It is precisely because of this light touch that we have limited our comments to the fact that we feel some unease about the policy but feel that it is not our place to comment further but that we have confidence that the community will do the right thing. Further comments would be done as individuals, as usual. The community in general understands this, I believe. Best regards Nigel Titley Chairman of the RIPE NCC Board From davidm at futureinquestion.net Fri Jul 8 17:15:51 2011 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 08 Jul 2011 17:15:51 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <4E17021E.5000208@titley.com> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> Message-ID: <4E171F27.8040905@futureinquestion.net> Dear address-policy-wg, Nigel, On 07/08/2011 03:11 PM, Nigel Titley wrote: > That is what you are seeing here, no more and no less. It is precisely because > of this light touch that we have limited our comments to the fact that we feel > some unease about the policy but feel that it is not our place to comment > further but that we have confidence that the community will do the right thing. > Further comments would be done as individuals, as usual. > This is also precisely why I find this particular comment unnecessary and confusing, especially to members of the community which are not involved in the entire scope of discussion on the mailing lists, and instead evaluate policy proposals and their impact on their networks at 'face value' based on the content of the proposals themselves. If the board has specific operational or fiscal concerns, or even a formal board opinion, it would be a disservice to the policy process *not* to include them for consideration by the community. However, the board is highly regarded and respected by the community, which is exactly why I find a generic "we are not feeling it" remark to be inappropriate, and feel it should have instead been omitted completely in favor of individual comments on the mailing list, or included as a more specific and concrete set of concerns providing a constructive contribution to the community's ability to evaluate the impact of the proposal. -- Respectfully yours, David Monosov From nigel at titley.com Sat Jul 9 00:38:23 2011 From: nigel at titley.com (Nigel Titley) Date: Fri, 08 Jul 2011 23:38:23 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <4E171F27.8040905@futureinquestion.net> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> Message-ID: <4E1786DF.4040402@titley.com> On 08/07/2011 16:15, David Monosov wrote: > This is also precisely why I find this particular comment unnecessary and > confusing, especially to members of the community which are not involved in the > entire scope of discussion on the mailing lists, and instead evaluate policy > proposals and their impact on their networks at 'face value' based on the > content of the proposals themselves. > > If the board has specific operational or fiscal concerns, or even a formal board > opinion, it would be a disservice to the policy process *not* to include them > for consideration by the community. > > However, the board is highly regarded and respected by the community, which is > exactly why I find a generic "we are not feeling it" remark to be inappropriate, > and feel it should have instead been omitted completely in favor of individual > comments on the mailing list, or included as a more specific and concrete set of > concerns providing a constructive contribution to the community's ability to > evaluate the impact of the proposal. > OK, with my personal hat on and not speaking for the board in any sense. 1. As far as I can see there are no fiscal issues here apart from the usual issue of more PI's meaning more NCC work meaning more staff (potentially) and hence more costs. 2. Speaking as an engineer, if you are too small to want PA space then you are small enough to renumber if you move provider. It's not really an issue these days (at least compared with the old days when /etc/hosts had to be updated on every machine in your network). And consuming a fib slot just to save yourself a bit of pain should you want to move provider strikes me as selfish. However, I'm an official old fart, and am probably harking back to an internet that no longer exists. I leave it up to the community to decide whether this is a constructive contribution or not. Nigel PS And thanks, David, for your very kind comments on the board. From turchanyi.geza at gmail.com Sat Jul 9 09:30:39 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sat, 9 Jul 2011 09:30:39 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <4E1786DF.4040402@titley.com> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> Message-ID: Nigel, thanks for your words, espacially for your point 2. However, your point 1 should be refined > 1. As far as I can see there are no fiscal issues here apart from the usual > issue of more PI's meaning more NCC work meaning more staff (potentially) > and hence more costs. > The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows. A total upgrade beed a couple of billon dollars. Unfortunately even if this many could be spent, the slow down provoked by the bigger table size could not be avoided. Therefore if we want to avoid total collaps or total up-grade and slow down in the very near future then all the FIBs grows should be minimised. Any proposal that might provoke a sudden grows of the FIBs should be postponed until the technology would evolve enough and allow to handle fast enough tha definitely larger FIBs. > 2. Speaking as an engineer, if you are too small to want PA space then you > are small enough to renumber if you move provider. It's not really an issue > these days (at least compared with the old days when /etc/hosts had to be > updated on every machine in your network). And consuming a fib slot just to > save yourself a bit of pain should you want to move provider strikes me as > selfish. > > However, I'm an official old fart, and am probably harking back to an > internet that no longer exists. I leave it up to the community to decide > whether this is a constructive contribution or not. > > Nigel > > PS And thanks, David, for your very kind comments on the board. > Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Sat Jul 9 10:14:06 2011 From: slz at baycix.de (Sascha Lenz) Date: Sat, 9 Jul 2011 10:14:06 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> Message-ID: Hi, Am 09.07.2011 um 09:30 schrieb Turchanyi Geza: > Nigel, > > thanks for your words, espacially for your point 2. > > However, your point 1 should be refined > > > > 1. As far as I can see there are no fiscal issues here apart from the usual issue of more PI's meaning more NCC work meaning more staff (potentially) and hence more costs. > > The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows. > > A total upgrade beed a couple of billon dollars. Unfortunately even if this many could be spent, the slow down provoked by the bigger table size could not be avoided. > > Therefore if we want to avoid total collaps or total up-grade and slow down in the very near future then all the FIBs grows should be minimised. > > Any proposal that might provoke a sudden grows of the FIBs should be postponed until the technology would evolve enough and allow to handle fast enough tha definitely larger FIBs. > you still haven't provided any reasons why there should be a sudden spike and evidence suggesting that there will be. Why are you insisting on this? What is your secret agenda? Do you have any information you're not sharing? Again, and i just also repeat myself now, because mindless repetition seems to be cool in this discussion: - There already IS IPv6 PI in every RIR Region, i think you're barking up the wrong tree, we're not discussing the introduction of IPv6 PI here, you're some years late - It's highly unlikely that there will be more IPv6 PI Prefixes than IPv4 PI Prefixes any time soon in ANY way, that's BY DESIGN of IPv6 ("one prefix per entity" - usually). If your routers cannot handle that, you're doing something seriously wrong, or you have a wrong idea about the whole concept - It's highly likely that the IPv4 table WILL grow faster if PI-shops aren't able to use IPv6 without multihoming because they will literally buy smaller and smaller IPv4 prefixes and announce them to stay in business when they grow, so instead of one IPv6 PI Prefix you will provoke 10 IPv4 PI Prefixes in some cases - because THERE ALREADY IS NO MULTIHOMING REQUIREMENT for IPv4 PI If you want to do something about that, provide a counter-proposal retroactively introducing a multi-homeing requirement on IPv4 PI please and see what will happen. If it goes through and is accepted, we have the same policy for IPv4 and IPv6 PI again, and i'm also happy :-) - It's almost completely independent of this proposal as long as HE does provide free IPv6 BGP Upstream tunnels :-) So why opposing this proposal at all if it does mean nothing for clueful people who just use a HE.net Tunnel as 2nd Peer and be happy to comply with the current policy? (okok, some might not want to do BGP themselves and pay for an AS# and so on, i admit this last one is rather a fun argument :-) But it makes a point that this proposal will have almost no impact if you look closer) All this proposal does is ease up IPv6 deployment for some entities who - for whatever stupid reason - rely on PI addresses without being multi-homed themselves. And THAT is what the majority should want, more IPv6, soon. Really, i still don't get it. Especially since the only problem here is the difference in IPv4 and IPv6 policies. It's more or less a transition problem for now. Why all the fuss NOW about such a simple policy change. This all was discussed years ago during the fight over IPv6 PI introduction. Now, did the world end with IPv6 PI? No. Will the world end with IPv6 PI? Probably, but i will have bought new routers long before that happens anyways. Is there more IPv6 deployment now? Yes (see number of PI assignments). I really like the outcome. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From turchanyi.geza at gmail.com Sat Jul 9 12:35:00 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sat, 9 Jul 2011 12:35:00 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> Message-ID: H? Sascha, On Sat, Jul 9, 2011 at 10:14 AM, Sascha Lenz wrote: > > you still haven't provided any reasons why there should be a sudden spike > and evidence suggesting that there will be. > Why are you insisting on this? What is your secret agenda? Do you have any > information you're not sharing? > I think you should look into tho other end of the binoculars. If you propose something, you shold be able to think about the consequences. What might happen in two months, in one year, in 3 years and in ten years. This is your duty! The problem is that some people think that they can make policy proposals without thinking the technical and financial consequences. I you can prove that increasing the size of the routing table would not cause neither slow down nor extra cost then I will carefully listen to your arguments, as you definitely might invented something fundamentally new. However, have you read the paper mentionned by Randy Bush? Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Sat Jul 9 13:28:40 2011 From: slz at baycix.de (Sascha Lenz) Date: Sat, 9 Jul 2011 13:28:40 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> Message-ID: <1A75B2E0-F816-4269-AC31-591838EB615E@baycix.de> Hi, > > you still haven't provided any reasons why there should be a sudden spike and evidence suggesting that there will be. > Why are you insisting on this? What is your secret agenda? Do you have any information you're not sharing? > > > I think you should look into tho other end of the binoculars. > > If you propose something, you shold be able to think about the consequences. What might happen in two months, in one year, in 3 years and in ten years. > > This is your duty! > > The problem is that some people think that they can make policy proposals without thinking the technical and financial consequences. > You still just repeat your point, without actually giving any argument or counter-argument to my explanations why i don't think your point is valid and why i think we need the policy change to ensure IPv6 adoption going more smoothly and faster. (Actually, this is a long-term view on the problem, i gave the argument why restricting IPv6 access might have an even more expensive impact on the (IPv4-)DFZ, read again). As long as you're not able to actually discuss anything, the best word for what i think you're doing is "lobbying", probably because you're company told you to or something. I have no idea why else you would stick to your point without being able to support it. :-( > I you can prove that increasing the size of the routing table would not cause neither slow down nor extra cost then I will carefully listen to your arguments, as you definitely might invented something fundamentally new. > Do you even know what you're talking about? Did you even read my arguments i gave at least twice? Does your company even have some business plan? The routing tables will grow, always, they always have. Plan for it. Everyone else does. This is nothing new. It's absolutely MAD that you think routing tables won't grow if you oppose this small policy change with no real impact whatsoever. PLEASE, write up your own proposal about what you would do in the big picture to slow routing table growth and see what happens. The PDP is open to anyone! And don't forget to do that in the other RIR regions, too! > However, have you read the paper mentionned by Randy Bush? Yes, nice paper about route flap dampening. Exactly what i was asking for. As so often, good work Randy et. al.! Now, where does it say anything about the IPv6 routing table growth? Might have missed that page, i read it some days ago, can you give me the page number? Thanks. Or are you talking about another paper? -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From randy at psg.com Sat Jul 9 13:50:55 2011 From: randy at psg.com (Randy Bush) Date: Sat, 09 Jul 2011 20:50:55 +0900 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <1A75B2E0-F816-4269-AC31-591838EB615E@baycix.de> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> <1A75B2E0-F816-4269-AC31-591838EB615E@baycix.de> Message-ID: ok children. enough. From fweimer at bfk.de Mon Jul 11 09:53:25 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 11 Jul 2011 07:53:25 +0000 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: (Turchanyi Geza's message of "Sat, 9 Jul 2011 09:30:39 +0200") References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> Message-ID: <824o2tw8wa.fsf@mid.bfk.de> * Turchanyi Geza: > The potential cost of applying more staff at the RIRs like RIPE NCC is just > one issue. The more important issue is that all the line cards of the core > routers should be replaced if we can not limit the grows of the forwarding > tables (FIB)s. AND IPv4 address space trading allready might create problems > concerning the grows. The RIPE NCC is not an Internet service provider, so this aspect is not relevant to RIPE NCC operations, and it does not justify interference from the board. -- 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 nigel at titley.com Mon Jul 11 12:33:06 2011 From: nigel at titley.com (Nigel Titley) Date: Mon, 11 Jul 2011 11:33:06 +0100 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <824o2tw8wa.fsf@mid.bfk.de> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> <824o2tw8wa.fsf@mid.bfk.de> Message-ID: <4E1AD162.4050604@titley.com> On 11/07/2011 08:53, Florian Weimer wrote: > The RIPE NCC is not an Internet service provider, so this aspect is not > relevant to RIPE NCC operations, and it does not justify interference > from the board. The board neither made this point, nor did they interfere. They expressed some personal disquiet about the proposal which in this case was leaked out through the RIPE NCC impact analysis (it normally doesn't get leaked and I'll make sure it doesn't again if this is the sort of trouble it causes) Nigel From gert at space.net Mon Jul 11 14:25:32 2011 From: gert at space.net (Gert Doering) Date: Mon, 11 Jul 2011 14:25:32 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> <1A75B2E0-F816-4269-AC31-591838EB615E@baycix.de> Message-ID: <20110711122532.GA23892@Space.Net> Hi, On Sat, Jul 09, 2011 at 08:50:55PM +0900, Randy Bush wrote: > ok children. enough. Indeed. Please bring the discussion somewhat back into focus. The proposal on the table does not introduce IPv6 PI, so this is not the question we need to discuss. The proposal at hand will neither help nor harm the IPv4 routing table, so this is also *not* the question to discuss. What we do need to make up our collective minds is: - do we want to see IPv6 deployed? (some of the comments can be read as "let's not deploy IPv6, because the IPv4 routing table is already too large!" - and I'm not convinced that this line of reasoning is conclusive) - do we think that the group of networks that would get IPv6 PI under the changed policy, but can't get IPv6 PI now is... a) large enough that it makes a difference regarding IPv6 deployment? b) small enough to avoid exploding the routing table? As for "b)", the numbers given by Alex Le Heux set a certain upper boundary for the number of IPv6 PI prefixes to expect - if every user of an IPv4 PI routing table slot today (in the RIPE region) will get an IPv6 PI block, we're "in the 10.000s" of routes, but not "in the millions". So we have some numbers. What we don't have right now is the number of IPv4 PI routes that are single-homed vs. IPv4 PI routes that are multihomed ("in a way that it can be seen from the vantage points used"). Maybe the RIPE NCC can help with some more numbers here. I purposely stay *out* of the discussion "why do people want IPv6 PI?" - if there are good reasons for IPv6 PI for single-homed networks, I think this is something the proposer should try to convince the WG of, but not the WG chairs. Gert Doering, APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From poty at iiat.ru Tue Jul 12 14:45:43 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Tue, 12 Jul 2011 16:45:43 +0400 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) Message-ID: Hello, > > 1. As far as I can see there are no fiscal issues here apart from the > usual issue of more PI's meaning more NCC work meaning more staff > (potentially) and hence more costs. > > > > The potential cost of applying more staff at the RIRs like RIPE NCC > is just one issue. The more important issue is that all the line cards > of the core routers should be replaced if we can not limit the grows of > the forwarding tables (FIB)s. AND IPv4 address space trading allready > might create problems concerning the grows. > > > > A total upgrade beed a couple of billon dollars. Unfortunately even > if this many could be spent, the slow down provoked by the bigger table > size could not be avoided. > > > > Therefore if we want to avoid total collaps or total up-grade and > slow down in the very near future then all the FIBs grows should be > minimised. > > > > Any proposal that might provoke a sudden grows of the FIBs should be > postponed until the technology would evolve enough and allow to handle > fast enough tha definitely larger FIBs. > > > > you still haven't provided any reasons why there should be a sudden > spike and evidence suggesting that there will be. Why? You know - Nigel is a real representative of ISP who knows the things. He said - it'll harm his company's business if the requirement would be removed. And still you do not count it as an argument? > - It's highly unlikely that there will be more IPv6 PI Prefixes than > IPv4 PI Prefixes any time soon in ANY way, that's BY DESIGN of IPv6 > ("one prefix per entity" - usually). If your routers cannot handle > that, you're doing something seriously wrong, or you have a wrong idea > about the whole concept Why someone should ask you about how to do their business? As far as I know - the Internet is on and going without the proposal and not the least role in that duty is due to the people like Nigel. You are asking for not necessary privileges for very small end-user companies and do not hear the "business-oriented" Internet companies. > > - It's highly likely that the IPv4 table WILL grow faster if PI-shops > aren't able to use IPv6 without multihoming because they > will literally buy smaller and smaller IPv4 prefixes and announce > them to stay in business when they grow, so instead of one IPv6 PI > Prefix you will > provoke 10 IPv4 PI Prefixes in some cases - because THERE ALREADY IS > NO MULTIHOMING REQUIREMENT for IPv4 PI No, you haven't done your homework again. There are many restrictions about the length of the IPv4 prefixes. And this is the long time the restrictions will ease. So... > All this proposal does is ease up IPv6 deployment for some entities who > - for whatever stupid reason - rely on PI addresses without being > multi-homed themselves. > And THAT is what the majority should want, more IPv6, soon. IMHO you counterargument yourself here. On one hand you've said that there will be a small number of PI, on another - it will speed up IPv6 deployment. IPv6 will grow without the PI-holders definitely. And this proposal doesn't have ANY relation with that. Regards, Vladislav Potapov From poty at iiat.ru Tue Jul 12 14:59:46 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Tue, 12 Jul 2011 16:59:46 +0400 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) Message-ID: > What we do need to make up our collective minds is: > > - do we want to see IPv6 deployed? > (some of the comments can be read as "let's not deploy IPv6, because > the IPv4 routing table is already too large!" - and I'm not > convinced > that this line of reasoning is conclusive) My answer - yes. > - do we think that the group of networks that would get IPv6 PI under > the changed policy, but can't get IPv6 PI now is... > > a) large enough that it makes a difference regarding IPv6 > deployment? No. > b) small enough to avoid exploding the routing table? No. > > As for "b)", the numbers given by Alex Le Heux set a certain upper > boundary > for the number of IPv6 PI prefixes to expect - if every user of an IPv4 > PI > routing table slot today (in the RIPE region) will get an IPv6 PI > block, > we're "in the 10.000s" of routes, but not "in the millions". So we > have > some numbers. There is rather uneasy answers to this as soon as times changes. As soon as IPv6 PI would be easy to get and easy to hold - there will be a "market" for it. It would be presented as a gift, got for prestige, "future", "presence in the Internet", "cool practice" and so on. So you cannot rely on digits for rather tough IPv4 PI policy. Such "blocks" will be nothing (in terms of traffic and usefulness of the deployment), but will clog the routing table a lot, inspiring ISPs to constantly change the equipments and delaying full deployment of full-working IPv6. As soon as the first answers (a) is "No" in my opinion, it is preferable for me to postpone the easing of the requirement until IPv6 starts. Regards, Vladislav Potapov From turchanyi.geza at gmail.com Tue Jul 12 20:25:58 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 12 Jul 2011 20:25:58 +0200 Subject: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI) In-Reply-To: <824o2tw8wa.fsf@mid.bfk.de> References: <20110628105851.940F46A003@postboy.ripe.net> <4E1634C9.1050702@futureinquestion.net> <4E17021E.5000208@titley.com> <4E171F27.8040905@futureinquestion.net> <4E1786DF.4040402@titley.com> <824o2tw8wa.fsf@mid.bfk.de> Message-ID: Hello Florian, On Mon, Jul 11, 2011 at 9:53 AM, Florian Weimer wrote: > * Turchanyi Geza: > > > The potential cost of applying more staff at the RIRs like RIPE NCC is > just > > one issue. The more important issue is that all the line cards of the > core > > routers should be replaced if we can not limit the grows of the > forwarding > > tables (FIB)s. AND IPv4 address space trading allready might create > problems > > concerning the grows. > > The RIPE NCC is not an Internet service provider, so this aspect is not > relevant to RIPE NCC operations, and it does not justify interference > from the board. > > When I started to work for the Internet development in 1991 it was a slogan what caught me: Think globally, act locally! Whatever hat I would wear I would like to see a little bit longer and wider than the hat would suggest. Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Wed Jul 13 10:34:33 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 13 Jul 2011 10:34:33 +0200 Subject: [address-policy-wg] 2011-03 New Draft Document Published (Post-depletion IPv4 address recycling) Message-ID: <20110713083451.69CC06A01B@postboy.ripe.net> Dear Colleagues, The draft document for the proposal described in 2011-03 has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal and Impact Analysis at: http://www.ripe.net/ripe/policies/proposals/2011-03 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 10 August 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From jan at go6.si Wed Jul 13 11:01:09 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 13 Jul 2011 11:01:09 +0200 Subject: [address-policy-wg] 2011-03 New Draft Document Published (Post-depletion IPv4 address recycling) In-Reply-To: <20110713083451.69CC06A01B@postboy.ripe.net> References: <20110713083451.69CC06A01B@postboy.ripe.net> Message-ID: <4E1D5ED5.7090309@go6.si> On 7/13/11 10:34 AM, Emilio Madaio wrote: > Dear Colleagues, > > The draft document for the proposal described in 2011-03 has been > published. The Impact Analysis that was conducted for this proposal > has also been published. > > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2011-03 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 10 August 2011. Dear APWG, After reading the proposal I have no objections and agree with proposed change. Cheers, Jan Zorz From paul at meanie.nl Wed Jul 13 11:05:37 2011 From: paul at meanie.nl (Paul Hoogsteder) Date: Wed, 13 Jul 2011 11:05:37 +0200 Subject: [address-policy-wg] 2011-03 New Draft Document Published (Post-depletion IPv4 address recycling) In-Reply-To: <4E1D5ED5.7090309@go6.si> References: <20110713083451.69CC06A01B@postboy.ripe.net> <4E1D5ED5.7090309@go6.si> Message-ID: <4E1D5FE1.8040404@meanie.nl> On 13-07-11 11:01, Jan Zorz @ go6.si wrote: > On 7/13/11 10:34 AM, Emilio Madaio wrote: >> Dear Colleagues, >> >> The draft document for the proposal described in 2011-03 has been >> published. The Impact Analysis that was conducted for this proposal >> has also been published. >> >> You can find the full proposal and Impact Analysis at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-03 >> >> and the draft document at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-03/draft >> >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 10 August 2011. > > Dear APWG, > > After reading the proposal I have no objections and agree with > proposed change. > > Cheers, Jan Zorz > > +1 from me Paul Hoogsteder Meanie AS31019 From boggits at gmail.com Wed Jul 13 10:40:10 2011 From: boggits at gmail.com (boggits) Date: Wed, 13 Jul 2011 09:40:10 +0100 Subject: [address-policy-wg] 2011-03 New Draft Document Published (Post-depletion IPv4 address recycling) In-Reply-To: <20110713083451.69CC06A01B@postboy.ripe.net> References: <20110713083451.69CC06A01B@postboy.ripe.net> Message-ID: On 13 July 2011 09:34, Emilio Madaio wrote: > The draft document for the proposal described in 2011-03 has been > published. The Impact Analysis that was conducted for this proposal > has also been published. I support this proposal with no changes, the only caveat is whether the special resources for IXs proposal and this clash and there should be some mention of this... J -- James Blessing 07989 039 476 From slz at baycix.de Wed Jul 13 12:51:55 2011 From: slz at baycix.de (Sascha Lenz) Date: Wed, 13 Jul 2011 12:51:55 +0200 Subject: [address-policy-wg] 2011-03 New Draft Document Published (Post-depletion IPv4 address recycling) In-Reply-To: <20110713083451.69CC06A01B@postboy.ripe.net> References: <20110713083451.69CC06A01B@postboy.ripe.net> Message-ID: Hi all, > Dear Colleagues, > > The draft document for the proposal described in 2011-03 has been > published. The Impact Analysis that was conducted for this proposal > has also been published. > > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2011-03 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2011-03/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 10 August 2011. > proposal is fine, wording seems to be fine, the idea behind it was discussed already, so i support the proposal in this version. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From emadaio at ripe.net Fri Jul 15 11:19:24 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 15 Jul 2011 11:19:24 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Message-ID: <20110715091924.E043F6A027@postboy.ripe.net> Dear Colleagues, Following the feedback received, a new version of the proposal described in 2006-05 is now published. The draft policy document for the proposal has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal and Impact Analysis at: http://www.ripe.net/ripe/policies/proposals/2006-05 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2006-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 29 July 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Fri Jul 15 11:41:23 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 15 Jul 2011 10:41:23 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: On 15 July 2011 10:19, Emilio Madaio wrote: > > Dear Colleagues, > > Following the feedback received, a new version of the proposal > described in 2006-05 is now published. > > The draft policy document for the proposal has been published. The > Impact Analysis that was conducted for this proposal has also been > published. > Looks good, only comment is what is the definition of 'control' as used by the text to describe ASs? J -- James Blessing 07989 039 476 From Jasper.Jans at espritxb.nl Fri Jul 15 12:53:54 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Fri, 15 Jul 2011 12:53:54 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039B620C3C@EXCH01.campus.local> +1 on the support for this proposal -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Emilio Madaio Sent: Friday, July 15, 2011 11:19 AM To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Dear Colleagues, Following the feedback received, a new version of the proposal described in 2006-05 is now published. The draft policy document for the proposal has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal and Impact Analysis at: http://www.ripe.net/ripe/policies/proposals/2006-05 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2006-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 29 July 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From Jamie.Stallwood at imerja.com Fri Jul 15 13:07:41 2011 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Fri, 15 Jul 2011 12:07:41 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) References: <20110715091924.E043F6A027@postboy.ripe.net> <55557D0EBE9495428BFE94EF8BC5EBD201039B620C3C@EXCH01.campus.local> Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD379A@bhw-srv-dc1.imerja.com> +1 Let's do this! -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Emilio Madaio Sent: Friday, July 15, 2011 11:19 AM To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Dear Colleagues, Following the feedback received, a new version of the proposal described in 2006-05 is now published. The draft policy document for the proposal has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal and Impact Analysis at: http://www.ripe.net/ripe/policies/proposals/2006-05 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2006-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 29 July 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Fri Jul 15 13:27:21 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 15 Jul 2011 13:27:21 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <008d01cc42e2$29c63740$7d52a5c0$@com> +1 on support for this proposal. > The draft policy document for the proposal has been published. The > Impact Analysis that was conducted for this proposal has also been > published. > > > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2006-05 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2006-05/draft > Mvg, Erik Bais From slz at baycix.de Fri Jul 15 13:30:39 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 15 Jul 2011 13:30:39 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: Hi, > > Dear Colleagues, > > Following the feedback received, a new version of the proposal > described in 2006-05 is now published. > > The draft policy document for the proposal has been published. The > Impact Analysis that was conducted for this proposal has also been > published. > > > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2006-05 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2006-05/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 July 2011. i still support the proposal for the reasons mentioned in former discussions about this proposal, and they are also all mentioned in the proposal itself. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From kuenzler at init7.net Fri Jul 15 14:04:18 2011 From: kuenzler at init7.net (Fredy Kuenzler) Date: Fri, 15 Jul 2011 14:04:18 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <4E202CC2.6090509@init7.net> +1. Halleluja after all. F. Am 15.07.2011 11:19, schrieb Emilio Madaio: > Dear Colleagues, > > Following the feedback received, a new version of the proposal > described in 2006-05 is now published. > > The draft policy document for the proposal has been published. The > Impact Analysis that was conducted for this proposal has also been > published. > > > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2006-05 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2006-05/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 July 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC From david.freedman at uk.clara.net Fri Jul 15 14:15:23 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 15 Jul 2011 13:15:23 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <4E202F5B.1000001@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 On 15/07/11 10:19, Emilio Madaio wrote: > > Dear Colleagues, > > Following the feedback received, a new version of the proposal > described in 2006-05 is now published. > > The draft policy document for the proposal has been published. The > Impact Analysis that was conducted for this proposal has also been > published. > > > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2006-05 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2006-05/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 July 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > - -- David Freedman Group Network Engineering david.freedman at uk.clara.net Tel +44 (0) 20 7685 8000 Claranet Group 21 Southampton Row London - WC1B 5HA - UK http://www.claranet.com Company Registration: 3152737 - Place of registration: England All the information contained within this electronic message from Claranet Ltd is covered by the disclaimer at http://www.claranet.co.uk/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4gL1sACgkQtFWeqpgEZrJabwCfTzZ6d8lLDu42mvOCjwQijJTu zYoAoJlxaQjuU44m9Cj5vhNmpGKm5gqS =XSHP -----END PGP SIGNATURE----- From teun at bit.nl Fri Jul 15 14:20:45 2011 From: teun at bit.nl (Teun Vink) Date: Fri, 15 Jul 2011 14:20:45 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <1310732445.18927.20.camel@moridin> On Fri, 2011-07-15 at 11:19 +0200, Emilio Madaio wrote: [...] > http://www.ripe.net/ripe/policies/proposals/2006-05 [...] We support this proposal. Regards, -- Teun Vink, Network & UNIX Engineer BIT BV | teun at bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0x5A04F4E2 | RIPE: TEUN-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jan at go6.si Fri Jul 15 14:45:08 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 15 Jul 2011 14:45:08 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <4E203654.5060208@go6.si> On 7/15/11 11:19 AM, Emilio Madaio wrote: > You can find the full proposal and Impact Analysis at: > > http://www.ripe.net/ripe/policies/proposals/2006-05 +1 Finally. /jan From dr at cluenet.de Fri Jul 15 22:42:43 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 15 Jul 2011 22:42:43 +0200 Subject: [address-policy-wg] Re: 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20110715091924.E043F6A027@postboy.ripe.net> References: <20110715091924.E043F6A027@postboy.ripe.net> Message-ID: <20110715204243.GA10491@srv03.cluenet.de> On Fri, Jul 15, 2011 at 11:19:24AM +0200, Emilio Madaio wrote: > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 July 2011. I do support this proposal even if it still encourages people to lie about plans to multihome in the future (claimed intent requirement) when all they need is globally routable address space. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 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: [address-policy-wg] Re: [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: [address-policy-wg] Re: [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 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: [address-policy-wg] Re: [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 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: [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> 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 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: [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: <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: [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: <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 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 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: [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: <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: [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: <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 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: [address-policy-wg] Re: [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:50:33 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 10:50:33 +0200 Subject: [address-policy-wg] Re: [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: <4E254559.3080408@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 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: [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: <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 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: [address-policy-wg] Re: [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: [address-policy-wg] Re: [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 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: [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: <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 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: [address-policy-wg] Re: [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 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: [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> <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 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: [address-policy-wg] RE: [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:23:27 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 11:23:27 +0200 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: <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:25:34 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 19 Jul 2011 11:25:34 +0200 Subject: [address-policy-wg] RE: [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 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: [address-policy-wg] RE: [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 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: [address-policy-wg] RE: [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 boggits at gmail.com Tue Jul 19 12:35:52 2011 From: boggits at gmail.com (boggits) Date: Tue, 19 Jul 2011 11:35:52 +0100 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: On 19 July 2011 10:42, wrote: > > > 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' J -- James Blessing 07989 039 476 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 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: [address-policy-wg] Re: [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 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: [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: 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 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 jan at go6.si Tue Jul 19 20:16:18 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Jul 2011 20:16:18 +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: <4E25C9F2.3010302@go6.si> On 7/19/11 7:55 PM, 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? Well, from my source of information - yes (for legacy allocations). > 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. Again, from my source, since some months or maybe a year, RIPE-NCC allocates IPv6 on "bit-boundry" (or bisection) method, so reservation is not needed anymore. But legacy allocations made us think of /29 :) /jan 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 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: [address-policy-wg] Re: [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 immo.apwg at be.free.de Wed Jul 20 12:37:26 2011 From: immo.apwg at be.free.de (Immo 'FaUl' Wehrenberg) Date: Wed, 20 Jul 2011 12:37:26 +0200 Subject: [address-policy-wg] Re: [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: <20110720103726.GC5710@benabuFaUl.be.free.de> Hallo Jan, du schrobst: > 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. For me that sounds like this is curing symptoms snstead of the real cause. I would suggest to add a clause that a) NCC can hand out new allocations if the addressing plan for the new addresses is sound and b) that simplifying administrational causes should also be an valid reason for address need (such as wastful transition mechanisms like 6rd or assigning /36 per pop eventhough not all pops have more then 2048 /48 to be assigned but for the sake of a clear network design). We do have enough addresses and we will not get short on them any time if we don't to something incredibly stupid So lets not create artifical obstacles. IPv6 is designed to allow that. Don't give that benefit away by some IPv4-we-don't-have-enough-addresses-and-must-save-addresses-at-all-costs habbits. In IPv6 thats just not necessary anymore, there are enough addresses and making things complicated in order to save addresses is just not reasonable! regards, Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From alexlh at ripe.net Wed Jul 20 15:02:37 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 20 Jul 2011 15:02:37 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <4E25C9F2.3010302@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> <3C86EA27-CF05-48A3-922B-36874568BB37@virtualized.org> <4E25C9F2.3010302@go6.si> Message-ID: <4EA65637-B4E8-4866-8A9A-888800F93E62@ripe.net> Dear Colleagues, >> 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. > > Again, from my source, since some months or maybe a year, RIPE-NCC allocates IPv6 on "bit-boundry" (or bisection) method, so reservation is not needed anymore. But legacy allocations made us think of /29 :) For a long time, the RIPE NCC's internal IP address management system would not easily allow us to implement the binary chop algorithm and we made each IPv6 allocation inside a reservation that was three bits larger than the allocation itself, ie. a /32 allocation inside a /29 reservation. In December 2010 we deployed a new system and since then we have been allocating IPv6 using the binary chop algorithm: ripencc|DE|ipv6|2a03:4000::|32|20101202|allocated ripencc|NL|ipv6|2a03:4800::|32|20101215|allocated ripencc|DE|ipv6|2a03:5000::|32|20101207|allocated ripencc|RU|ipv6|2a03:5800::|32|20101215|allocated ripencc|NL|ipv6|2a03:6000::|32|20101202|allocated ripencc|IT|ipv6|2a03:6800::|32|20101215|allocated Eventually, the algorithm will begin allocating in the middle of these available blocks, for example 2a03:4400::/32, 2a03:4c00::/32, etc. Best regards, Alex Le Heux RIPE NCC 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:38:05 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 20 Jul 2011 18:38:05 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) In-Reply-To: <20110720103726.GC5710@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> <55557D0EBE9495428BFE94EF8BC5EBD201039FAC7947@EXCH01.campus.local> <4E2538C1.30506@go6.si> <20110720103726.GC5710@benabuFaUl.be.free.de> Message-ID: <4E27046D.2070000@go6.si> On 7/20/11 12:37 PM, Immo 'FaUl' Wehrenberg wrote: > For me that sounds like this is curing symptoms snstead of the real > cause. I would suggest to add a clause that a) NCC can hand out new > allocations if the addressing plan for the new addresses is sound and > b) that simplifying administrational causes should also be an valid > reason for address need (such as wastful transition mechanisms like 6rd > or assigning /36 per pop eventhough not all pops have more then 2048 /48 to > be assigned but for the sake of a clear network design). With rising smallest initial alloc /29 we do not "cure" this problem, we just make it a bit smaller :) But let's discuss that when we publish the policy change proposal. > > We do have enough addresses and we will not get short on them any time if we > don't to something incredibly stupid So lets not create artifical obstacles. > IPv6 is designed to allow that. Don't give that benefit away by some > IPv4-we-don't-have-enough-addresses-and-must-save-addresses-at-all-costs > habbits. In IPv6 thats just not necessary anymore, there are enough > addresses and making things complicated in order to save addresses is > just not reasonable! talking to convinced. /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 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 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 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 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 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 linkzweb at yahoo.com Sun Jul 24 19:15:22 2011 From: linkzweb at yahoo.com (Josh Nertrino) Date: Sun, 24 Jul 2011 10:15:22 -0700 (PDT) Subject: [address-policy-wg] Re: 2006-05 New Draft Document Published (PI Assignment Size) Message-ID: <1311527722.20502.YahooMailNeo@web33205.mail.mud.yahoo.com> I fully support this proposal. Finally some movement..... (this draft was submitted back in 2006!) Ps. ARIN already has this for years !!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Tue Jul 26 11:59:00 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 26 Jul 2011 11:59:00 +0200 Subject: [address-policy-wg] 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) Message-ID: <20110726095901.1A3026A051@postboy.ripe.net> Dear Colleagues, The proposal 2008-08, "Initial Certification Policy in the RIPE NCC Service Region", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals Reason for withdrawal: after carefully following the discussion in the Concluding Phase of the Policy Development Process, the proposer is of the opinion that consensus on this proposal is not possible within the RIPE community. As a consequence, the proposer has decided to withdraw the proposal. Regards Emilio Madaio Policy Development Officer RIPE NCC From nigel at titley.com Tue Jul 26 17:39:25 2011 From: nigel at titley.com (Nigel Titley) Date: Tue, 26 Jul 2011 16:39:25 +0100 Subject: [address-policy-wg] 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110726095901.1A3026A051@postboy.ripe.net> References: <20110726095901.1A3026A051@postboy.ripe.net> Message-ID: <4E2EDFAD.8030108@titley.com> On 26/07/2011 10:59, Emilio Madaio wrote: > Dear Colleagues, > > The proposal 2008-08, "Initial Certification Policy in the RIPE NCC > Service Region", has been withdrawn. > > > It is now archived and can be found at: > > http://www.ripe.net/ripe/policies/archived-policy-proposals > > > > Reason for withdrawal: after carefully following the discussion in the > Concluding Phase of the Policy Development Process, the proposer is of > the opinion that consensus on this proposal is not possible within the > RIPE community. As a consequence, the proposer has decided to withdraw > the proposal. The reason I withdrew this policy is mainly that it didn't seem to be getting anywhere. We've been debating it for close on three years. It is my considered opinion that this is one of those things that is never going to be resolved by consensus, largely because most of the arguments are based around opinion and not fact. It is very difficult at this stage in the game to have facts; these will emerge from the operational experience that this proposal was supposed to give us. The RIPE NCC will continue to issue certificates for the time being in accordance with the Activity Plan that the members have approved for the past three years. For the complete avoidance of doubt, at the next RIPE NCC AGM the members will be given the opportunity to vote on a motion to continue this activity or to shut it down. Ultimately it is their money and in the situation where the community is unable to come to consensus it seems only fair that they should have the opportunity to decide. In the meantime the RIPE NCC will be looking at ways of mitigating the risks that have been identified over the past three years. The community and the membership will be kept fully informed of progress. Best regards Nigel Titley From rhe at nosc.ja.net Tue Jul 26 18:08:00 2011 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 26 Jul 2011 17:08:00 +0100 Subject: [address-policy-wg] 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4E2EDFAD.8030108@titley.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> Message-ID: <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> Hi Nigel, Thanks for the explanation. I understand the reasoning and whilst I'm disappointed it has come to this, I think it is the right, and probably only, course for the time being. > the complete avoidance of doubt, at the next RIPE NCC AGM the members will be given the opportunity to vote on a motion to continue this activity or to shut it down. Just to completely avoid doubt: will this be as part of the activity plan, or will this be a separate motion? As it could be contentious I don't want to end up in a situation where we, to use an English colloquialism, risk throwing the baby out with the bath-water. > In the meantime the RIPE NCC will be looking at ways of mitigating the risks that have been identified over the past three years. The community and the membership will be kept fully informed of progress. I think it would be really helpful, to me at least, to have a draft outline of some of the steps and the timescales that the NCC will be using to try to achieve this. Whilst the membership does of course decide what the NCC should be spending its money on, and that includes building the infrastructure to support certification, policies are decided through the community using the Policy Development Process, and I (and I don't doubt, you too) really would like to see certification happen through an agreed policy. However (un)likely that might be. Best regards, Rob From nigel at titley.com Tue Jul 26 18:46:22 2011 From: nigel at titley.com (Nigel Titley) Date: Tue, 26 Jul 2011 17:46:22 +0100 Subject: [address-policy-wg] 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> Message-ID: <4E2EEF5E.3010203@titley.com> On 26/07/2011 17:08, Rob Evans wrote: > Hi Nigel, > > Thanks for the explanation. I understand the reasoning and whilst I'm disappointed it has come to this, I think it is the right, and probably only, course for the time being. I also am very disappointed, but after a great deal of thought and heart searching, I think it is the only way forward. >> the complete avoidance of doubt, at the next RIPE NCC AGM the members will be given the opportunity to vote on a motion to continue this activity or to shut it down. > Just to completely avoid doubt: will this be as part of the activity plan, or will this be a separate motion? As it could be contentious I don't want to end up in a situation where we, to use an English colloquialism, risk throwing the baby out with the bath-water. This will be a separate motion. I want to make it as clear as possible. >> In the meantime the RIPE NCC will be looking at ways of mitigating the risks that have been identified over the past three years. The community and the membership will be kept fully informed of progress. > I think it would be really helpful, to me at least, to have a draft outline of some of the steps and the timescales that the NCC will be using to try to achieve this. I'll see what we can come up with. I would hope that they will have some thoughts shortly. > Whilst the membership does of course decide what the NCC should be spending its money on, and that includes building the infrastructure to support certification, policies are decided through the community using the Policy Development Process, and I (and I don't doubt, you too) really would like to see certification happen through an agreed policy. However (un)likely that might be. Agreed, which is why I have stuck with the process for nigh on three years. However the consensus process only works where there is a genuine desire to reach a common goal and a general willingness to work together to achieve this goal. This debate became so polarised that I doubt that any consensus could have been achieved. With great regret, we have had to admit that the PDP has failed in this case. Nigel From malcolm at linx.net Tue Jul 26 21:20:33 2011 From: malcolm at linx.net (Malcolm Hutty) Date: Tue, 26 Jul 2011 20:20:33 +0100 Subject: [address-policy-wg] 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110726095901.1A3026A051@postboy.ripe.net> References: <20110726095901.1A3026A051@postboy.ripe.net> Message-ID: <4E2F1381.4070506@linx.net> On 26/07/2011 10:59, Emilio Madaio wrote: > The proposal 2008-08, "Initial Certification Policy in the RIPE NCC > Service Region", has been withdrawn. Obviously, speaking as someone who has been raising concerns about this proposal, I think this is the right decision, but I know a number of people will be disappointed by this. Whichever side of the debate you are on, I think we can all acknowledge that this can't have been an easy decision. We like to say that the PDP is driven by the community consensus, but to accept that lack of community consensus means you have to abandon even a policy with so much momentum behind it takes guts. Many (perhaps most) organisations would have pressed on regardless, out of pride and inertia, and to sooth the egos of the senior leadership, and then dared any dissenters to do anything about it. The RIPE PDP may not have turned up a consensus this time, but it did something else that is useful: it proved that the community consensus process is genuine. That's something to be proud of, and to defend with renewed vigour next time the Internet community's detractors come knocking (Cooperation-WG take note!). I would like to thank the proposers and the WG Chairs, for hearing out the concerns so courteously and patiently. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA From dr at cluenet.de Tue Jul 26 23:33:36 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 26 Jul 2011 23:33:36 +0200 Subject: [address-policy-wg] Re: 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4E2EEF5E.3010203@titley.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> Message-ID: <20110726213336.GB25957@srv03.cluenet.de> On Tue, Jul 26, 2011 at 05:46:22PM +0100, Nigel Titley wrote: > With great regret, we have had to admit that the PDP has failed in > this case. The PDP worked fine, it just didn't have the outcome you desired. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gert at space.net Wed Jul 27 09:02:19 2011 From: gert at space.net (Gert Doering) Date: Wed, 27 Jul 2011 09:02:19 +0200 Subject: [address-policy-wg] Re: 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110726213336.GB25957@srv03.cluenet.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> Message-ID: <20110727070219.GE72014@Space.Net> Hi, On Tue, Jul 26, 2011 at 11:33:36PM +0200, Daniel Roesen wrote: > On Tue, Jul 26, 2011 at 05:46:22PM +0100, Nigel Titley wrote: > > With great regret, we have had to admit that the PDP has failed in > > this case. > > The PDP worked fine, it just didn't have the outcome you desired. It is not that unusual for a proposal to not reach consensus. The big FAIL here was "the proposal was in the process for nearly three years, with hardly any participation(!), and in the very last stage, all the discussion broke loose". It would have been much more productive to have these discussions in the early stages of the proposal - and then either it could have been adjusted in a timely fashion, or abandoned early (which we've done before). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nigel at titley.com Wed Jul 27 13:24:10 2011 From: nigel at titley.com (Nigel Titley) Date: Wed, 27 Jul 2011 12:24:10 +0100 Subject: [address-policy-wg] Re: 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <20110726213336.GB25957@srv03.cluenet.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> Message-ID: <4E2FF55A.5010900@titley.com> On 26/07/2011 22:33, Daniel Roesen wrote: > On Tue, Jul 26, 2011 at 05:46:22PM +0100, Nigel Titley wrote: >> With great regret, we have had to admit that the PDP has failed in >> this case. > The PDP worked fine, it just didn't have the outcome you desired. The PDP did not "work fine". There is a strong demand for certification, there is an equally strong objection. If the PDP "worked fine" we would have hammered out a middle ground like we usually do on technical matters. And just to get things straight, wearing my personal hat, I have no emotional investment in this proposal. I was left holding it when the CERT-TF disbanded. I've been feeding it and changing its nappies ever since and personally I'd like to have the spare bedroom back. However I happen to believe that it is important for the RIPE community and the rest of the world that we get a strong decision on this and not just "well we couldn't be arsed to actually debate it properly". Otherwise, somewhere down the line, we are going to get serious folk knocking on the door and saying "You did what? You abandoned the technique that could have prevent the melt down of the internet that happened last week because you couldn't be bothered to have a proper debate about it". I'd much rather have a proper decision on record. If that decision was "we voted on it and decided not to do it" then I'm happy. Nigel From t.schallar at avalon.at Wed Jul 27 13:41:30 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Wed, 27 Jul 2011 13:41:30 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? Message-ID: <4E2FF96A.2000802@avalon.at> Hello! What ist the current status on the multihomed v6 PI topic? regards, Thomas From ebais at a2b-internet.com Wed Jul 27 14:45:27 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 27 Jul 2011 14:45:27 +0200 Subject: [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)? In-Reply-To: <4E2FF96A.2000802@avalon.at> References: <4E2FF96A.2000802@avalon.at> Message-ID: <008101cc4c5b$10403500$30c09f00$@com> Hi Thomas, The status on the website states : Current Phase: Review Phase: Awaiting Decision from Working Group Chair http://www.ripe.net/ripe/policies/proposals/2011-02 The purpose of the Review phase is to review the full draft RIPE Document compiled at the end of the Discussion Phase so that the final documentation the proposal will lead to and all modifications made to that document are transparent to the community. During the Review Phase, discussion of the proposal can continue, also in the light of the impact analysis that is published at the beginning of this phase, and within the context of the proposal, further modifications can still be suggested regarding the draft RIPE Document. The Review Phase should last for a maximum of four weeks. At the end of the Review Phase, the WG chair determines whether the WG has reached rough consensus. If the WG chair decides that consensus has not been reached, then the WG chair can withdraw the proposal. Alternatively, the WG chair can send the proposal back to the Discussion Phase if the proposer is willing to continue to author the proposal and make the necessary changes to the proposal according to the feedback received from the community. The WG chair can also decide to have the draft RIPE Document edited and start a new Review Phase with a new version of the proposal. More insight on the status about the various status : http://www.ripe.net/ripe/docs/ripe-500 I'll send an email to the WG chair and ask about it. Regards, Erik Bais From niels=apwg at bakker.net Wed Jul 27 23:17:20 2011 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Wed, 27 Jul 2011 23:17:20 +0200 Subject: [address-policy-wg] Re: 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4E2FF55A.5010900@titley.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> Message-ID: <20110727211720.GL2894@burnout.tpb.net> * nigel at titley.com (Nigel Titley) [Wed 27 Jul 2011, 13:25 CEST]: >And just to get things straight, wearing my personal hat, I have no >emotional investment in this proposal. I was left holding it when the >CERT-TF disbanded. I've been feeding it and changing its nappies ever >since and personally I'd like to have the spare bedroom back. However I >happen to believe that it is important for the RIPE community and the >rest of the world that we get a strong decision on this and not just >"well we couldn't be arsed to actually debate it properly". Otherwise, >somewhere down the line, we are going to get serious folk knocking on >the door and saying "You did what? You abandoned the technique that >could have prevent the melt down of the internet that happened last week >because you couldn't be bothered to have a proper debate about it". I'd >much rather have a proper decision on record. If that decision was "we >voted on it and decided not to do it" then I'm happy. There has been a proper debate. It's lasted three years. Trying to sneak it in via the back door of the AGM doesn't sound like a great strategy to me. And I don't say this merely as persona non vota, so to speak. Your fear-mongering about "serious folk" is noted, and contrary to what you seem to believe, I do consider the internet community as represented in RIPE as quite serious. -- Niels. From dr at cluenet.de Wed Jul 27 23:53:19 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 27 Jul 2011 23:53:19 +0200 Subject: [address-policy-wg] Re: Re: 2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: <4E2FF55A.5010900@titley.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> Message-ID: <20110727215319.GA28651@srv03.cluenet.de> On Wed, Jul 27, 2011 at 12:24:10PM +0100, Nigel Titley wrote: >> The PDP worked fine, it just didn't have the outcome you desired. > The PDP did not "work fine". There is a strong demand for certification, > there is an equally strong objection. If the PDP "worked fine" we would > have hammered out a middle ground like we usually do on technical matters. How could that look like? Something like "somewhat pregnant"? My imagination fails how to find middle ground on something that seems to be fundamentally incompatible goals. But I'm biased and probably too narror-minded. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jim at rfc1035.com Thu Jul 28 00:53:10 2011 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Jul 2011 23:53:10 +0100 Subject: [address-policy-wg] The PDP and consensus In-Reply-To: <20110727215319.GA28651@srv03.cluenet.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727215319.GA28651@srv03.cluenet.de> Message-ID: <6C3FDDC7-5A9E-4391-AEB8-EDEE08F2E4AB@rfc1035.com> On 27 Jul 2011, at 22:53, Daniel Roesen wrote: > My imagination fails how to find middle ground on something that seems > to be fundamentally incompatible goals. Two points: *Much* bigger and far more serious problems have been solved in the world when two fundamentally incompatible (or even mutually exclusive) positions choose to find a compromise. Second, there might have been a better chance of finding a consensus on 2008-08 if the voices of opposition engaged much earlier than they did. This is not a criticism of anyone. From jim at rfc1035.com Thu Jul 28 02:15:01 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Jul 2011 01:15:01 +0100 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: <20110727211720.GL2894@burnout.tpb.net> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> Message-ID: On 27 Jul 2011, at 22:17, niels=apwg at bakker.net wrote: > There has been a proper debate. It's lasted three years. Well IMO, any debate lasting *that* long cannot be called "proper". A more honest description might be "ivory-towered" or "defective". There is something fundamentally wrong if we can't get a policy done in 3 years(!) and then have what appeared to be a consensus come off the rails at the very last moment. We, the RIPE community, should hang our heads in shame. Imagine the derision we'd rightly heap on other policy- making bodies if they had produced this outcome. And we all know a few of them. Please note I am not criticising the people who raised those last- minute objections at all. [Though it's a pity they didn't engage much earlier.] I'm actually relieved they intervened while the opportunity was still there. This had to be more preferable than declare a consensus, implement the policy and then have serious objections emerge. Though I admit both options are unpleasant. One's just worse than the other. > Trying to sneak it in via the back door of the AGM doesn't sound > like a great strategy to me. That's grossly unfair Neils. Nigel clearly asked for a documented decision. In the absence of viable alternatives, the NCC AGM seems the obvious forum for that decision. Nigel just asked that the membership should have a vote on whether the NCC continues doing what's in the activity plan or stops. He was very careful not to say what that decision should be. Or even what the NCC membership should vote on because, strictly speaking, he hasn't proposed a resolution for May's AGM. It should be patently clear RIPE cannot take a decision about address certification any time soon, if ever. So the NCC membership seems the best (or least worst) choice as a suitable forum in our service region that could actually take a decision on this issue, whatever that may be. It's simply unacceptable to collectively shrug our shoulders at what has happened and wish the wreckage to vanish all by itself. For one thing, we have a duty to those in the community who have not followed the detail of 2008-08. They deserve an answer. So do our friends at the other RIRs. Uncertainty about address certification in our service region has an impact on them and their communities. There are also further global impacts. It would not surprise me if governments who are supportive of the RIR system and its bottom-up policy making processes take a rather dim view of what's happened too. There's a nasty question that needs resolving and soon: "how can you spend 3 years debating an important policy, letting if implode at the last minute and then just walk away?". It's these sorts of risks that have to be mitigated. The NCC will have a key role in that risk mitigation effort. So with that context in mind, what do we do now? For some definition of "we". I think Nigel's suggestion is not just sensible, it has to be the next best (or least worst) option. Feel free to make better suggestions... We'll look really dysfunctional if we let address certification continue as our very own long-running and real-world version of Schrodinger's famous thought experiment. From lists-ripe at c4inet.net Thu Jul 28 02:43:52 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 28 Jul 2011 00:43:52 +0000 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> Message-ID: <20110728004352.GA69269@cilantro.c4inet.net> On Thu, Jul 28, 2011 at 01:15:01AM +0100, Jim Reid wrote: >It should be patently clear RIPE cannot take a decision about address >certification any time soon, if ever. So the NCC membership seems the >best (or least worst) choice as a suitable forum in our service region >that could actually take a decision on this issue, whatever that may be. Why not, then, abandon the inconvenient PDP at all and make any and all decisions via a vote at AGM? Clearly, if any discussions that don't produce the desirable outcome are simply taken to a different forum, the PDP is little more than a farce and a waste of time? rgds, Sascha Luck` ` From lists-ripe at c4inet.net Thu Jul 28 02:54:49 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 28 Jul 2011 00:54:49 +0000 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> Message-ID: <20110728005448.GB69269@cilantro.c4inet.net> On Thu, Jul 28, 2011 at 01:15:01AM +0100, Jim Reid wrote: >Well IMO, any debate lasting *that* long cannot be called "proper". A >more honest description might be "ivory-towered" or "defective". There >is something fundamentally wrong if we can't get a policy done in 3 >years(!) and then have what appeared to be a consensus come off the >rails at the very last moment. We, the RIPE community, should hang our >heads in shame. Imagine the derision we'd rightly heap on other policy- >making bodies if they had produced this outcome. And we all know a few >of them. I have to agree with that but IMO it is because, with some proposals, a long time passes between any updates/any movement and people simply forget about them - after all, very few do policy development as a full-time job... Maybe it would be worthwile discussing ways to keep the PDP flowing more smoothly -unless, of course, it becomes irrelevant, cf my post above. rgds, Sascha Luck From gert at space.net Thu Jul 28 09:42:12 2011 From: gert at space.net (Gert Doering) Date: Thu, 28 Jul 2011 09:42:12 +0200 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: <20110728005448.GB69269@cilantro.c4inet.net> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728005448.GB69269@cilantro.c4inet.net> Message-ID: <20110728074212.GF72014@Space.Net> Hi, On Thu, Jul 28, 2011 at 12:54:49AM +0000, Sascha Luck wrote: > I have to agree with that but IMO it is because, with some proposals, > a long time passes between any updates/any movement and people simply > forget about them - after all, very few do policy development as a > full-time job... I have sent a number of extra reminders regarding 2008-08 to the APWG mailing list (in addition to the regular updates from Emilio), and it has been brought to the stage at five(!) RIPE meetings. Nobody who is remotely interested in following policy development can claim in earnest to have never heard about 2008-08. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From dr at cluenet.de Thu Jul 28 09:46:08 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 28 Jul 2011 09:46:08 +0200 Subject: [address-policy-wg] Re: the post-mortem on 2008-09 In-Reply-To: References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> Message-ID: <20110728074608.GA19420@srv03.cluenet.de> On Thu, Jul 28, 2011 at 01:15:01AM +0100, Jim Reid wrote: > It should be patently clear RIPE cannot take a decision about address > certification any time soon, if ever. The outcome of the PDP is that there is no consensus to implement address certification. To me, that's a decision of the RIPE community, against address certification. I'm not saying that I'm totally happy with the consequences, and I'm certainly not happy about the PDP process taking that long. > So with that context in mind, what do we do now? Accept the decision of the RIPE community, with the consequences it has, and work on ideas how to mitigate the negative ones. > For some definition of > "we". I think Nigel's suggestion is not just sensible, it has to be the > next best (or least worst) option. Feel free to make better suggestions... So the party line is "we need to push that through, via whatever channels it takes. PDP concluded in the wrong way so we ask others who are hopefully more favorable to our proposal."? Don't set precedence ignoring the PDP outcome by trying to work around it. THAT opens a whole can of worms I really don't want to see unleashed. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Thu Jul 28 09:48:52 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 28 Jul 2011 09:48:52 +0200 Subject: [address-policy-wg] Re: The PDP and consensus In-Reply-To: <6C3FDDC7-5A9E-4391-AEB8-EDEE08F2E4AB@rfc1035.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727215319.GA28651@srv03.cluenet.de> <6C3FDDC7-5A9E-4391-AEB8-EDEE08F2E4AB@rfc1035.com> Message-ID: <20110728074852.GB19420@srv03.cluenet.de> On Wed, Jul 27, 2011 at 11:53:10PM +0100, Jim Reid wrote: > On 27 Jul 2011, at 22:53, Daniel Roesen wrote: > >> My imagination fails how to find middle ground on something that seems >> to be fundamentally incompatible goals. > > Two points: > > *Much* bigger and far more serious problems have been solved in the world > when two fundamentally incompatible (or even mutually exclusive) positions > choose to find a compromise. As I said: it's just _me_ not seeing an approach to that. I don't say that there is no way. > Second, there might have been a better chance of finding a consensus on > 2008-08 if the voices of opposition engaged much earlier than they did. Agreed. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Jasper.Jans at espritxb.nl Thu Jul 28 09:53:39 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Thu, 28 Jul 2011 09:53:39 +0200 Subject: [address-policy-wg] Re: the post-mortem on 2008-09 In-Reply-To: <20110728074608.GA19420@srv03.cluenet.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728074608.GA19420@srv03.cluenet.de> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201039FDC030B@EXCH01.campus.local> +1 on everythign said below. My understanding is indeed that in order for a policy to be accepted there needs to be concensus - in the case where there is non the policy gets rejected and not pushed to some other body for a ruling. Not having consensus is *the* ruling for not implementing a proposal it is not a lack of a ruling on a proposal. Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans at espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Daniel Roesen Sent: Thursday, July 28, 2011 9:46 AM To: address-policy-wg at ripe.net Subject: [address-policy-wg] Re: the post-mortem on 2008-09 On Thu, Jul 28, 2011 at 01:15:01AM +0100, Jim Reid wrote: > It should be patently clear RIPE cannot take a decision about address > certification any time soon, if ever. The outcome of the PDP is that there is no consensus to implement address certification. To me, that's a decision of the RIPE community, against address certification. I'm not saying that I'm totally happy with the consequences, and I'm certainly not happy about the PDP process taking that long. > So with that context in mind, what do we do now? Accept the decision of the RIPE community, with the consequences it has, and work on ideas how to mitigate the negative ones. > For some definition of > "we". I think Nigel's suggestion is not just sensible, it has to be the > next best (or least worst) option. Feel free to make better suggestions... So the party line is "we need to push that through, via whatever channels it takes. PDP concluded in the wrong way so we ask others who are hopefully more favorable to our proposal."? Don't set precedence ignoring the PDP outcome by trying to work around it. THAT opens a whole can of worms I really don't want to see unleashed. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From gert at space.net Thu Jul 28 09:56:07 2011 From: gert at space.net (Gert Doering) Date: Thu, 28 Jul 2011 09:56:07 +0200 Subject: [address-policy-wg] Re: the post-mortem on 2008-09 In-Reply-To: <20110728074608.GA19420@srv03.cluenet.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728074608.GA19420@srv03.cluenet.de> Message-ID: <20110728075607.GG72014@Space.Net> Hi, On Thu, Jul 28, 2011 at 09:46:08AM +0200, Daniel Roesen wrote: > So the party line is "we need to push that through, via whatever > channels it takes. PDP concluded in the wrong way so we ask others who > are hopefully more favorable to our proposal."? This specific case is a bit more complex, given that the work on the certificate infrastructure *was* mandated by the RIPE community (some 4 or 5 years ago when the topic came up and the plenary said "well, please go ahead and build a prototype") and has been on the budget and activity plan since then. So the NCC is spending money for something that seems to be "ok" according to who is paying for it (the members, which are part of the community as well). Now some parts of the community seem to say "don't go there" (simplified). Now what? Ignore the members, who said "go, spend the money for this!", or ignore the community? We've dug us into a nice rathole, and among the possible alternatives, I can't see anything better than "asking the members for a vote on NCC activity". (Note that, strictly speaking, certificates are not purely "address policy" [aka 'who can get numbers under which conditions?'] but more "business processes", and as such, to have 2008-08 on APWG's plate was always a bit problematic) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From fearghas at gmail.com Thu Jul 28 10:11:32 2011 From: fearghas at gmail.com (Fearghas McKay) Date: Thu, 28 Jul 2011 10:11:32 +0200 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: <20110728074212.GF72014@Space.Net> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728005448.GB69269@cilantro.c4inet.net> <20110728074212.GF72014@Space.Net> Message-ID: <0CCF2466-D701-4BCB-A616-26A9D2E314E2@gmail.com> On 28 Jul 2011, at 09:42, Gert Doering wrote: > Nobody who is remotely interested in following policy development can > claim in earnest to have never heard about 2008-08. I don't think that was what Sascha was suggesting just that it slips from the top of the todo stack over time. Hopefully some of the changes in Emilio's updates, ie links to the discussion archives, will make it easier to jog the community memory and get people back up to speed quickly. f From millnert at gmail.com Thu Jul 28 10:35:19 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 28 Jul 2011 10:35:19 +0200 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> Message-ID: Jim, this message of yours explains for me that you have not really understood why or what people are having issues with, with these issues. On Thu, Jul 28, 2011 at 2:15 AM, Jim Reid wrote: > On 27 Jul 2011, at 22:17, niels=apwg at bakker.net wrote: > >> There has been a proper debate. ?It's lasted three years. > > Well IMO, any debate lasting *that* long cannot be called "proper". A more > honest description might be "ivory-towered" or "defective". There is > something fundamentally wrong if we can't get a policy done in 3 years(!) > and then have what appeared to be a consensus come off the rails at the very > last moment. We, the RIPE community, should hang our heads in shame. Imagine > the derision we'd rightly heap on other policy-making bodies if they had > produced this outcome. And we all know a few of them. > > Please note I am not criticising the people who raised those last-minute > objections at all. [Though it's a pity they didn't engage much earlier.] I'm > actually relieved they intervened while the opportunity was still there. > This had to be more preferable than declare a consensus, implement the > policy and then have serious objections emerge. Though I admit both options > are unpleasant. One's just worse than the other. > >> Trying to sneak it in via the back door of the AGM doesn't sound like a >> great strategy to me. > > That's grossly unfair Neils. Nigel clearly asked for a documented decision. The documented decision is there is no consensus on the current proposals (and beyond). If you want the RIPE NCC to cheat its policy process and "remove consensus from the table", by going for a simple majority vote instead, the RIPE NCC's policy process becomes void; a farce, and clearly a waste of time. The bottom-up decision making process of the RIR system will have failed, but not for the reasons you mention, but for a complete top-down policy overrun. Make no mistake, pushing such a (de)vast(ating) change to the Internet architecture as we know today such as resource certification/RPKI/SIDR through while completely ignoring any outcome from *any* PDP arm of the NCC, is a great failure of the PDP in that it is indeed useless. > In the absence of viable alternatives, the NCC AGM seems the obvious forum > for that decision. Nigel just asked that the membership should have a vote > on whether the NCC continues doing what's in the activity plan or stops. He > was very careful not to say what that decision should be. Or even what the > NCC membership should vote on because, ?strictly speaking, he hasn't > proposed a resolution for May's AGM. > > It should be patently clear RIPE cannot take a decision about address > certification any time soon, if ever. So the NCC membership seems the best > (or least worst) choice as a suitable forum in our service region that could > actually take a decision on this issue, whatever that may be. It is becoming increasingly apparent to me that these changes are so large that their implementations are perhaps better left to the normal democratically based law-making processes, had it not been for the complications, let's say, of the union. These architectural changes are so severe I'm starting to doubt we really have the mandate to make them, especially given how the Internet nowadays is so much "serious freedo^wbusiness". > It's simply unacceptable to collectively shrug our shoulders at what has > happened and wish the wreckage to vanish all by itself. For one thing, we > have a duty to those in the community who have not followed the detail of > 2008-08. They deserve an answer. Isn't the answer pretty simple? "The proposed address certification prototype (technology) has not passed the NCC PDP quality assurance. There are serious issues with it that have not been addressed." > So do our friends at the other RIRs. > Uncertainty about address certification in our service region has an impact > on them and their communities. There are also further global impacts. It > would not surprise me if governments who are supportive of the RIR system > and its bottom-up policy making processes take a rather dim view of what's > happened too. There's a nasty question that needs resolving and soon: "how > can you spend 3 years debating an important policy, letting if implode at > the last minute and then just walk away?". It's these sorts of risks that > have to be mitigated. The NCC will have a key role in that risk mitigation > effort. I do not see and have not seen your windmills. > So with that context in mind, what do we do now? Address the issues raised, or we happily do nothing at all? Isn't that how we normally achieve consensus? Isn't that how we have been governing ourselves, bottom-up, previously? > For some definition of > "we". I think Nigel's suggestion is not just sensible, it has to be the next > best (or least worst) option. Feel free to make better suggestions... Clearly you rank from bad to good, the "no" to "yes" of 2008-08 and beyond. So, since you repeat the same question, I will repeat the same answer: the PDP did make a decision, it said "no, no consensus can be reached on the current prototypes, come again with the issues better addressed". > We'll look really dysfunctional if we let address certification continue as > our very own long-running and real-world version of Schrodinger's famous > thought experiment. >From your biased point of view, perhaps. From my biased point of view, not so much. Instead, we're looking pretty responsible, IMVHO in the same general manner like the Norwegian government has been saying they will fight terror with more democracy and openness rather than do what the US did. Best Regards, Martin From boggits at gmail.com Thu Jul 28 10:39:33 2011 From: boggits at gmail.com (boggits) Date: Thu, 28 Jul 2011 09:39:33 +0100 Subject: [address-policy-wg] Re: the post-mortem on 2008-09 In-Reply-To: <20110728075607.GG72014@Space.Net> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728074608.GA19420@srv03.cluenet.de> <20110728075607.GG72014@Space.Net> Message-ID: On 28 July 2011 08:56, Gert Doering wrote: > Now some parts of the community seem to say "don't go there" (simplified). Er, I agree that its a simplification, but I think the major concern was not that the signing of resources was made technically possible, but that there wasn't a distributed model of authority implemented so that 'attacks' (physical or political) on the infrastructure could not remove control of routing from the network operators. The work on signing has been wasted, what is needed now is some method to take that work and build something that can be trusted by all side of the community. J -- James Blessing 07989 039 476 From jim at rfc1035.com Thu Jul 28 10:57:27 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Jul 2011 09:57:27 +0100 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: <20110728004352.GA69269@cilantro.c4inet.net> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728004352.GA69269@cilantro.c4inet.net> Message-ID: <002A367D-623E-4588-AA41-7A190841718F@rfc1035.com> On 28 Jul 2011, at 01:43, Sascha Luck wrote: > Why not, then, abandon the inconvenient PDP at all and make any and > all decisions via a vote at AGM? > Clearly, if any discussions that don't produce the desirable outcome > are > simply taken to a different forum, the PDP is little more than a > farce and a waste of time? You're jumping to very wrong conclusions and seem to have ignored what's been said. The NCC has been spending money and resources on address certification for a few years now. This has been done at the request of RIPE who asked for a prototype. So development has been under way in parallel with getting 2008-08 through the PDP. The membership have approved the production of this prototype because for a few years it's been in the activity plan that gets approved at each AGM. We're now in a situation where the PDP's been followed and 2008-08 is dead. There is no policy on address certification. However the NCC has a mandate from the membership through the activity plan to continue with the prototype and its infrastructure. We're in a paradox where the community has killed a policy on address certification while simultaneously authorising the NCC to develop such a system. [Has anybody seen Schrodinger's cat wandering around? It must in be here somewhere. :-)] There now needs to be a vote by the NCC membership to take a decision which will normalise that situation. And unlike RIPE's PDP, the AGM shouldn't take 3 years to decide. From jim at rfc1035.com Thu Jul 28 11:09:38 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Jul 2011 10:09:38 +0100 Subject: [address-policy-wg] Re: the post-mortem on 2008-09 In-Reply-To: <20110728074608.GA19420@srv03.cluenet.de> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728074608.GA19420@srv03.cluenet.de> Message-ID: <4C7BE3E7-F39F-42AD-A7EB-4F73BF21B229@rfc1035.com> On 28 Jul 2011, at 08:46, Daniel Roesen wrote: > On Thu, Jul 28, 2011 at 01:15:01AM +0100, Jim Reid wrote: >> It should be patently clear RIPE cannot take a decision about address >> certification any time soon, if ever. > > The outcome of the PDP is that there is no consensus to implement > address certification. To me, that's a decision of the RIPE community, > against address certification. Indeed. Meanwhile, the NCC's Activity Plan which was approved at the May AGM authorises the NCC to continue its work on address certification. Something needs to be done about that. Which is why Nigel suggested a vote at the AGM next year. We need a clear decision which can be understood by everyone. As I explained earlier, the implications for the current situation go beyond our service region and community. From jim at rfc1035.com Thu Jul 28 11:46:37 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Jul 2011 10:46:37 +0100 Subject: [address-policy-wg] the post-mortem on 2008-08 In-Reply-To: References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> Message-ID: <92B89B4D-335B-4654-B68D-C0B7F63D77A9@rfc1035.com> On 28 Jul 2011, at 09:35, Martin Millnert wrote: > this message of yours explains for me that you have not really > understood why or what people are having issues with, with these > issues. With respect Martin, you couldn't be more wrong. And anyway the next steps are not about what I might or might not understand or the issues raised in the last-minute objections to 2008-08. It's also not about "cheating the policy process" either. Nobody has suggested it was. It's about reconciling two (three?) mutually exclusive community decisions. We have a situation where the membership has authorised the NCC to develop an address certification system. This has been going on for years. It was the settled will of RIPE too. [Though that goes back to the days before the PDP existed.] We've all taken a punt that by the time this system was ready, there would be a consensus policy for it in place. 2008-08 is now dead. But the current mandate to the NCC is still in effect. A vote of the membership is needed to change that mandate. In my opinion, this is also the least bad way to proceed. Please note I did not say what that decision should be. Again. While you're right in theory to say we could start all over again and come up with a new address certification policy, I doubt it will work in practice. Positions seem too entrenched on all sides to find a compromise. I wonder too if consensus is now possible or if that can be reached in a reasonable amount of time. 2008-08 chugged along for 3 years and was apparently non-controversial. From emadaio at ripe.net Thu Jul 28 12:31:21 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 28 Jul 2011 12:31:21 +0200 Subject: [address-policy-wg] 2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA) Message-ID: <20110728103305.E8BA36A03C@postboy.ripe.net> Dear Colleagues, The Review Period for the proposal 2011-01 has been extended until 25 August 2011. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From millnert at gmail.com Thu Jul 28 12:31:47 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 28 Jul 2011 12:31:47 +0200 Subject: [address-policy-wg] the post-mortem on 2008-08 In-Reply-To: <92B89B4D-335B-4654-B68D-C0B7F63D77A9@rfc1035.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <92B89B4D-335B-4654-B68D-C0B7F63D77A9@rfc1035.com> Message-ID: <0D640A18-ABD8-4CF0-8257-25ED9B7C4D7C@gmail.com> Jim, thank you for your reply. On Jul 28, 2011, at 11:46, Jim Reid wrote: > On 28 Jul 2011, at 09:35, Martin Millnert wrote: > >> this message of yours explains for me that you have not really >> understood why or what people are having issues with, with these >> issues. > > With respect Martin, you couldn't be more wrong. And anyway the next steps are not about what I might or might not understand or the issues raised in the last-minute objections to 2008-08. It's also not about "cheating the policy process" either. Nobody has suggested it was. It's about reconciling two (three?) mutually exclusive community decisions. Fair enough. Your message had a bias towards "this needs to pass, obstacles go away!", that I may have misinterpreted then. > We have a situation where the membership has authorised the NCC to develop an address certification system. This has been going on for years. It was the settled will of RIPE too. [Though that goes back to the days before the PDP existed.] We've all taken a punt that by the time this system was ready, there would be a consensus policy for it in place. 2008-08 is now dead. But the current mandate to the NCC is still in effect. A vote of the membership is needed to change that mandate. In my opinion, this is also the least bad way to proceed. If the prototype development does not auto-expire when there is no supporting policy, that seems a bit like a flaw in the original design here, to me. Likewise, can the membership with a simple majority vote overrule the PDP on the matter? (or without the corresponding PDP, if the policy proposed then is different than 2008-08.) I'm not verse enough in RIPE NCC procedures to know this. It does seem strange that a simple majority vote could override a PDP decision, since the requirements on consensus in the PDP is pretty far from simple majority. That is what I mean would be cheating and would seriously undermine the authority of the policy. It does then appear sensible to me that a new policy (which it is, Gert) still has to go through the PDP, and the AGM-mandated bullet point prototype development would at some time finish (working well enough qualifies), ending that mandate. And once that mandate has ended, a new mandate can still not put it into effect before consensus can be reached in a corresponding PDP. > Please note I did not say what that decision should be. Again. > > While you're right in theory to say we could start all over again and come up with a new address certification policy, I doubt it will work in practice. Positions seem too entrenched on all sides to find a compromise. I wonder too if consensus is now possible or if that can be reached in a reasonable amount of time. 2008-08 chugged along for 3 years and was apparently non-controversial. I think Mr Blessing pointed out the core issue, yet unsolved. Until it is solved (my reading on the major difference of abusive risk tolerance), until there is a consensus, the default action is of course to not enact a new policy. Memories of the recent 2008-08 debate here ought to be fresh enough that if a new proposal comes through (say roughly in time for the next AGM), where these issues have been addressed, the debate need not restart from scratch. Best regards, Martin From pk at DENIC.DE Thu Jul 28 16:31:02 2011 From: pk at DENIC.DE (Peter Koch) Date: Thu, 28 Jul 2011 16:31:02 +0200 Subject: [address-policy-wg] the post-mortem on 2008-09 In-Reply-To: <002A367D-623E-4588-AA41-7A190841718F@rfc1035.com> References: <20110726095901.1A3026A051@postboy.ripe.net> <4E2EDFAD.8030108@titley.com> <13D9524F-53E1-4592-88DC-C5130CFA2D97@nosc.ja.net> <4E2EEF5E.3010203@titley.com> <20110726213336.GB25957@srv03.cluenet.de> <4E2FF55A.5010900@titley.com> <20110727211720.GL2894@burnout.tpb.net> <20110728004352.GA69269@cilantro.c4inet.net> <002A367D-623E-4588-AA41-7A190841718F@rfc1035.com> Message-ID: <20110728143102.GE6394@x27.adm.denic.de> On Thu, Jul 28, 2011 at 09:57:27AM +0100, Jim Reid wrote: > dead. There is no policy on address certification. However the NCC has > a mandate from the membership through the activity plan to continue > with the prototype and its infrastructure. We're in a paradox where > the community has killed a policy on address certification while > simultaneously authorising the NCC to develop such a system. [Has I believe you are drawing the wrong conclusion here. One of the problems is that 2008-08 was about the "how", not the "if". And since the latter question was probably never asked explicitly through the PDP, the discussion came up, admittedly late, during the "how" debate on 2008-08. One of the weaknesses (not failure) of the PDP is that after the proponent withdraws the proposal, we're stuck for the time being. > anybody seen Schrodinger's cat wandering around? It must in be here Dead cat walking? The difference is that the AGM can approve the budget for development and deployment, but once there is agreement the issue is subject to the PDP there is a risk that there will be no "go" for the deployment and thus the budget was wasted - which would be very undesirable. However, it's not the same community because the two bodies have distinct roles. -Peter From mueller at syr.edu Thu Jul 28 17:39:49 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Jul 2011 11:39:49 -0400 Subject: [address-policy-wg] the post-mortem on 2008-08 Message-ID: <75822E125BCB994F8446858C4B19F0D71750B1BA0A@SUEX07-MBX-04.ad.syr.edu> Jim: > -----Original Message----- > We're in a paradox where the > community has killed a policy on address certification while > simultaneously authorising the NCC to develop such a system. [snip] > There now needs to be a vote by the NCC membership to > take a decision which will normalise that situation. And unlike RIPE's > PDP, the AGM shouldn't take 3 years to decide. If the NCC membership votes to continue developing the system, how exactly does the situation get "normalized?" A vote to continue development of a system that has been rejected in the policy process continues the paradox, does it not? Only a negative vote would normalize. And I don't get the impression that you would vote no, or urge others to vote no. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org From jim at rfc1035.com Thu Jul 28 19:38:49 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 28 Jul 2011 18:38:49 +0100 Subject: [address-policy-wg] the post-mortem on 2008-08 In-Reply-To: <75822E125BCB994F8446858C4B19F0D71750B1BA0A@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D71750B1BA0A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <85D40D68-F4F5-4009-AAA3-C18A99D5A659@rfc1035.com> On 28 Jul 2011, at 16:39, Milton L Mueller wrote: > And I don't get the impression that you would vote no, or urge > others to vote no. Kindly stop misrepresenting me. I have clearly stated my neutrality twice. This is now the third time. FYI I do not represent an LIR and therefore don't attend the NCC's General Meetings or vote in them.