From alh-ietf at tndh.net Mon May 3 14:56:51 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 3 May 2010 05:56:51 -0700 Subject: [address-policy-wg] RE: [ipv6-wg] "IPv6 Ripeness" measurements on RIPE Labs In-Reply-To: <4BD85494.60604@ripe.net> References: <4BD85494.60604@ripe.net> Message-ID: <0e0b01caeac0$19537240$4bfa56c0$@net> How about getting RIPE-NCC to read it.... ;) The remote feed page for the RIPE60 plenary has an embedded IPv4 address rather than the fqdn. // netConnectionUrl defines where the streams are found netConnectionUrl: 'rtmp://193.0.0.162/live' Putting the IPv6 literal into VLC shows that the streamer is not even listening on the IPv6 address of that machine because it just fails the connect, where VLC crashes when trying to take the stream from the IPv4 literal. > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of Mirjam Kuehne > Sent: Wednesday, April 28, 2010 8:30 AM > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] "IPv6 Ripeness" measurements on RIPE Labs > > Dear colleagues, > > We looked at the "IPv6 ripeness" of all LIRs in the RIPE NCC service > region. This was initially created to adjust our IPv6 training course > depending on the country we are in. However, we felt this might also be > valuable in a bigger context. > > Please find the results and methodology on RIPE Labs: > > http://labs.ripe.net/content/ipv6-ripeness > > We would be interested to hear what you think about this idea in > general > and if you have any suggestions on how to modify or improve this. > > Kind Regards, > Mirjam K?hne > RIPE NCC From sander at steffann.nl Tue May 4 12:12:42 2010 From: sander at steffann.nl (Sander Steffann) Date: Tue, 4 May 2010 12:12:42 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> Message-ID: <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> Hello working group, A document was distributed today at the RIPE 60 meeting in Prague. The document highlights the differences between IPv4 PI and IPv6 PI and the trends that have been observed. The document provides food for thought, and there will be a discussion in the second slot (11:00 - 12:30) of the Address Policy Working Group session tomorrow. Facilities for remote participation are available at http://www.ripe.net/ripe/meetings/ripe-60/index.php?home=remote. This discussion will of course be followed up on this mailing list. Sander Steffann APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: discrepancy_article.pdf Type: application/pdf Size: 92015 bytes Desc: not available URL: -------------- next part -------------- From richih.mailinglist at gmail.com Tue May 4 14:51:42 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 4 May 2010 14:51:42 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> Message-ID: On Tue, May 4, 2010 at 12:12, Sander Steffann wrote: > This discussion will of course be followed up on this mailing list. My 2 cents (Gert made me post this): 1) While the problem of IPv4 will, hopefully, solve itself within the next few years, it's still import to keep it in mind, especially as the resources become more and more scarce. 2) Policies for IPv4 and IPv6 should be the same. Obviously, there are differences of technical nature and in sheer abundance, but these do not matter in the specific topic at hand. 3) Although I am in the comfortable position of being able to use PA space exclusively, if the usage of PI space has indeed changed over time, there seem to be three possible solutions: a) Force the users of said PI space to become LIRs and use PA space. b) Introduce a concept of "lesser LIRs" which is allowed to use PI space for sub-assignments. c) Continue the existing practice of accepting that there is a new, valid use for PI space and accommodate a real-world need which exists, apparently. Personally, I feel that updating the wording in the IPv4 policy to allow these sub-assignments explicitly, and not merely implicitly, makes sense. This wording could then be used for IPv6, as well. Richard From sander at steffann.nl Tue May 4 16:29:50 2010 From: sander at steffann.nl (Sander Steffann) Date: Tue, 4 May 2010 16:29:50 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> Message-ID: <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> Hello Richard, > Personally, I feel that updating the wording in the IPv4 policy to allow > these sub-assignments explicitly, and not merely implicitly, makes > sense. This wording could then be used for IPv6, as well. What would then be the difference between PI and PA addresses? Do you think we should get rid of that distinction completely, or is this not what you mean? I heard people talk about the distinction here at the RIPE meeting in Prague, so it seems to be a topic of discussion. Thanks, Sander From richih.mailinglist at gmail.com Tue May 4 17:07:28 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 4 May 2010 17:07:28 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> Message-ID: Hi Sander, > What would then be the difference between PI and PA addresses? Do you think we should get rid of that distinction completely, or is this not what you mean? I heard people talk about the distinction here at the RIPE meeting in Prague, so it seems to be a topic of discussion. No hard need for an AS number, no right to vote, no need to make payments for resources to RIPE directly, others I am possibly not thinking of, right now. Still, you raise a very important point and I am not sure I have a good answer to your question at this point. Let me mull the question for a bit. FWIW, personally, I would always go for PA space in any scenario involving sub-assignments. But then, I am aware of RIPE's policies; many people are not. Maybe a questions like "are you sure PA space would not be better for your needs" with links to relevant documentation in the PI space request form would make sense. Richard From sander at steffann.nl Tue May 4 17:10:19 2010 From: sander at steffann.nl (Sander Steffann) Date: Tue, 4 May 2010 17:10:19 +0200 Subject: [address-policy-wg] Final Agenda for upcoming APWG meeting at RIPE 60 Message-ID: <67098CE0-54DF-4174-A745-1EB600F37D30@steffann.nl> Hi APWG folks, Hi RIPE meeting folks, below you can find the final RIPE address policy WG meeting's agenda, which will take place in Prague in the following three time slots: Wednesday, May 5, 09:00 - 10:30 Wednesday, May 5, 11:00 - 12:30 Thursday, May 6, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". regards, Sander Steffann, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-03 [run out fairly] - accepted 2008-06 Use of final /8 - withdrawn 2009-04 IPv4 Allocation and Assignments to Facilitate - withdrawn IPv6 Deployment - common policy topics in all regions (end of IPv4, transfers, ...) C. New Proposals since RIPE 59 -> Discussion of open policy proposals, Part 1 (new proposals) 2010-01 Temporary Internet Number Assignment Policy (Nick Hilliard) 2010-02 Allocations from the last /8 (new combined proposal from Philip Smith and Alain Bidron) This proposal replaces 2008-06 (Philip Smith) and 2009-04 (Alain Bidron). Warning: The previous version of the agenda mentioned that this will be discussed on Thursday. The discussion has been moved back here. 2010-03 Global Policy State in RIPE PDP (Dave Wilson) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- K. Document Cosmetic Surgeries Project - Filiz Yilmaz - feedback received on the first set of changes - how to go forward? L. "Authorship of RIPE Policy Documents" - Filiz Yilmaz This presentation seeks to reach community agreement on how to document and acknowledge the role of people that propose changes to RIPE Internet Resource Allocation and Assignment policies. M. "Update what's happening with ITU and the RIRs" - Axel Pawlik This presentation has been moved to the Cooperation Working Group. N. Differences between IPv4 PI and IPv6 PI (open discussion, based on Alex Le Heux' report at RIPE59) - try to come up with consensus on what we think "IPv6 PI" should be used for, and should not be used for, and then start a PDP proposal to adjust the policy according to it (if needed) - data-center operators and their customers - the "IPv4 loophole" -> customer access links considered infra (and thus, single-address customers with NAT can be numbered from IPv4 PI, but not from IPv6 PI) O. The need for a Registration Policy - Rob Blokzijl ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- T. Discussion of open policy proposals (old proposals) ---- old policy proposals ---- 2006-05 PI Assignment Size (dead, up for grabs) 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF - update what happened since RIPE 59) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team, represented by Axel Pawlik (?)) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) The following subjects have already been raised: - Wording Cleanup regarding 80% rule for PA allocations - Gert Doering - Impact of the 80% rule - Remco van Mook Z. AOB -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Tue May 4 17:11:08 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 4 May 2010 17:11:08 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <4BE0362C.1070908@schiefner.de> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> Message-ID: On Tue, May 4, 2010 at 16:58, Carsten Schiefner wrote: > I indeed think that convincing those PI space users to become LIRs after all > bears quite some merits: "It regulatively makes sense to treat user groups > the same way that are (almost) indistinguishable" is only one of them. > > Yet, I am not entirely sure what could be the convincing arguments (or in > the absence thereof: the mild pressure) that should be applied to those PI > space users. I am not convinced mild pressure would suffice. AFAIU, any entity using PI space would need to renumber once they migrate to PA space. As we are already pre-selected on entities doing sub-assignments, there is additional pain involved. The perceived benefit by the entity which was allocated PI space of now being in compliance might not quite outweigh said pain. Richard From ripe-wgs.cs at schiefner.de Tue May 4 16:58:52 2010 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 04 May 2010 16:58:52 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> Message-ID: <4BE0362C.1070908@schiefner.de> Richard, all - Richard Hartmann wrote: >> This discussion will of course be followed up on this mailing list. > > 3) Although I am in the comfortable position of being able to use PA > space exclusively, if the usage of PI space has indeed changed over > time, there seem to be three possible solutions: > > a) Force the users of said PI space to become LIRs and use PA space. I indeed think that convincing those PI space users to become LIRs after all bears quite some merits: "It regulatively makes sense to treat user groups the same way that are (almost) indistinguishable" is only one of them. Yet, I am not entirely sure what could be the convincing arguments (or in the absence thereof: the mild pressure) that should be applied to those PI space users. Oh, and yes: I am in favour of a v4/v6 harmonisation, too. Best, Carsten From gert at space.net Tue May 4 17:22:43 2010 From: gert at space.net (Gert Doering) Date: Tue, 4 May 2010 17:22:43 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <4BE0362C.1070908@schiefner.de> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> Message-ID: <20100504152243.GO60850@Space.Net> Hi, On Tue, May 04, 2010 at 04:58:52PM +0200, Carsten Schiefner wrote: > Oh, and yes: I am in favour of a v4/v6 harmonisation, too. Why? (Half of it is because it's easier to judge the outcome of a discussion if there are specific arguments for or against something - and the other half of it is because I'm playing the devil's advocate, and claim that we might not want IPv6 to be the same as IPv4... e.g. as in "if people can use PI to give single IPv6 addresses to their end customers, we might see DSL deployments with single address + NAT, and this not something I want to see"...) Gert -- Total number of prefixes smaller than registry allocations: 150584 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 richih.mailinglist at gmail.com Tue May 4 17:34:50 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 4 May 2010 17:34:50 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504152243.GO60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> Message-ID: On Tue, May 4, 2010 at 17:22, Gert Doering wrote: > "if people can use PI to give single IPv6 addresses to their end > customers, we might see DSL deployments with single address + NAT, > and this not something I want to see"...) What provisions are in place that would stop anyone from doing the same with PA space? What stops anyone from implementing them for both IPv6 PA & PI? Regards, Richard From gert at space.net Tue May 4 17:43:12 2010 From: gert at space.net (Gert Doering) Date: Tue, 4 May 2010 17:43:12 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> Message-ID: <20100504154312.GS60850@Space.Net> Hi, On Tue, May 04, 2010 at 05:34:50PM +0200, Richard Hartmann wrote: > On Tue, May 4, 2010 at 17:22, Gert Doering wrote: > > "if people can use PI to give single IPv6 addresses to their end > > customers, we might see DSL deployments with single address + NAT, > > and this not something I want to see"...) > > What provisions are in place that would stop anyone from doing the > same with PA space? What stops anyone from implementing them for both > IPv6 PA & PI? There is no real incentive to do so, as you can get a huuuuuge block of addresses fairly easily. The incentive to do this with PI is "save on the costs" - and then, since the PI policy doesn't permit you to give address blocks from the PI space to your access customers, the consequence would be "if you can only give a single IPv6 address to the customers, that's all the customer is going to get" (and the blame will be pointed to the RIPE NCC). There be dragons - consider well what your message to the "large-scale access providers" is supposed to be, and what the implications might be. (There's more dragons, and babies & bathwater as well - make sure that a policy that takes into account the large-scale access providers doesn't break things for web hosting shops... and these seem to be more our problem right now) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Tue May 4 18:16:10 2010 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 04 May 2010 18:16:10 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504152243.GO60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> Message-ID: <4BE0484A.2080909@schiefner.de> Hi Gert, Gert Doering wrote: > On Tue, May 04, 2010 at 04:58:52PM +0200, Carsten Schiefner wrote: >> Oh, and yes: I am in favour of a v4/v6 harmonisation, too. > > Why? all right, fair question :-) - for the reason that has been voiced here already: v4 and v6 are of course different - but should not be treated differently in the way PI space is being managed. Not even if I consider your devil's advocate argument below. > (Half of it is because it's easier to judge the outcome of a discussion > if there are specific arguments for or against something - and the > other half of it is because I'm playing the devil's advocate, and claim > that we might not want IPv6 to be the same as IPv4... e.g. as in > "if people can use PI to give single IPv6 addresses to their end > customers, we might see DSL deployments with single address + NAT, > and this not something I want to see"...) Best, Carsten From slz at baycix.de Tue May 4 18:38:28 2010 From: slz at baycix.de (Sascha Lenz) Date: Tue, 04 May 2010 18:38:28 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504152243.GO60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> Message-ID: <4BE04D84.7070006@baycix.de> Hay, Am 04.05.2010 17:22, schrieb Gert Doering: > Hi, > > On Tue, May 04, 2010 at 04:58:52PM +0200, Carsten Schiefner wrote: >> Oh, and yes: I am in favour of a v4/v6 harmonisation, too. > > Why? well, if we like it or not, there always will be the point about "if we can't do exactly the same thing with IPv6 as we do now with IPv4, we don't care about IPv6 anytime soon". So from this p.o.v. it should be clear that both policies should be harmoni[s|z]ed. But is that what we want? > > (Half of it is because it's easier to judge the outcome of a discussion > if there are specific arguments for or against something - and the > other half of it is because I'm playing the devil's advocate, and claim > that we might not want IPv6 to be the same as IPv4... e.g. as in > "if people can use PI to give single IPv6 addresses to their end > customers, we might see DSL deployments with single address + NAT, > and this not something I want to see"...) That's the difference between good intentions and good in general. It just might not work that way, at least not anytime soon. For the actual question: I have no real meaning about it; i see the problems but don't know what the best solution might be. So i would opt for the simplest answer to the question: We tell the RIPE NCC that this is all intended as it is now, no change needed - and see what happens next (e.g. someone coming up with a formal PDP proposal, stating that his company (or so) desperately needs a change here) Reasoning: For now it seems it is rather a problem for the NCC, what they should tell the requesting parties, not so much a community problem since no company/person came up with a formal PDP proposal to change anything here. I'm happy to rethink my position though if this discussion is going somewhere smelling like a consensus. -- ===================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ===================================================================== From mark at streamservice.nl Tue May 4 18:52:41 2010 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 4 May 2010 18:52:41 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504154312.GS60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> <20100504154312.GS60850@Space.Net> Message-ID: <0d6e01caebaa$391278c0$ab376a40$@nl> > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Gert Doering > Sent: Tuesday, May 04, 2010 5:43 PM > To: Richard Hartmann > Cc: Gert Doering; Carsten Schiefner; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > Hi, > > On Tue, May 04, 2010 at 05:34:50PM +0200, Richard Hartmann wrote: > > On Tue, May 4, 2010 at 17:22, Gert Doering wrote: > > > "if people can use PI to give single IPv6 addresses to their end > > > customers, we might see DSL deployments with single address + NAT, > > > and this not something I want to see"...) > > > > What provisions are in place that would stop anyone from doing the > > same with PA space? What stops anyone from implementing them for both > > IPv6 PA & PI? > > There is no real incentive to do so, as you can get a huuuuuge block of > addresses fairly easily. > > The incentive to do this with PI is "save on the costs" - and then, > since the PI policy doesn't permit you to give address blocks from the > PI space to your access customers, the consequence would be "if you can > only give a single IPv6 address to the customers, that's all the > customer is going to get" (and the blame will be pointed to the RIPE > NCC). > > There be dragons - consider well what your message to the "large-scale > access providers" is supposed to be, and what the implications might > be. > > (There's more dragons, and babies & bathwater as well - make sure that > a policy that takes into account the large-scale access providers > doesn't break things for web hosting shops... and these seem to be > more our problem right now) The current options we have to implement IPv6 prevent us from implementing it. There are multiple problems we see currently: - We probably won't get PI IPv6 space (and renumbering if we move to another network will be a lot of work, this is a problem for us) - With IPv6 we would like to offer a client (collocation) at least a /112 (with PI this isn't allowed if I'm correctly informed) - PA IPv6 address space is currently not available for us (this also prevents us to implement IPv6) We also know some networks (with AS number) that currently use IPv4 PI and don't are a LIR (and don't use IPv4 PA). They also need a solution for the mentioned problems before they could implement IPv6. How do you look to this problem? Regards, Mark > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 150584 > > 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 ripe at c4inet.net Tue May 4 18:35:07 2010 From: ripe at c4inet.net (Sascha Luck) Date: Tue, 4 May 2010 16:35:07 +0000 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504152243.GO60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> Message-ID: <20100504163507.GB97690@cilantro.c4inet.net> Hi, On Tue, May 04, 2010 at 05:22:43PM +0200, Gert Doering wrote: > "if people can use PI to give single IPv6 addresses to their end > customers, we might see DSL deployments with single address + NAT, > and this not something I want to see"...) Me neither. Maybe change the policy to require assigning min /64 in conjunction with making it assignable? > Gert rgds, Sascha Luck From ripe at c4inet.net Tue May 4 18:31:08 2010 From: ripe at c4inet.net (Sascha Luck) Date: Tue, 4 May 2010 16:31:08 +0000 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> Message-ID: <20100504163108.GA97690@cilantro.c4inet.net> Hi Sander, all, On Tue, May 04, 2010 at 04:29:50PM +0200, Sander Steffann wrote: > What would then be the difference between PI and PA addresses? Do you > think we should get rid of that distinction completely, or is this not > what you mean? I heard people talk about the distinction here at the > RIPE meeting in Prague, so it seems to be a topic of discussion. I would be in favour of abandoning the distinction altogether for ipv6. 1) In ipv4, even now, many "LIRs" use PA space as "PI space", simply because it was deemed easier to just become a LIR than go through the PI "mill". Conversely, as mentioned, a lot of PI space is used as "PA lite", this usually because it is cheaper and: 2) Many orgs have no staff trained in LIR procedures (and no time/money to change that) and would gladly hand the bureaucracy off to their friendly local LIR. 3) If address space were, simply, that, LIR functions could be handled by "qualified" orgs and their customers (be they end-users or SPs) can get routable and assignable address space; everyone wins. 4) Conceivably, if every "assignee" would have to become a member, membership fees for everyone should fall significantly; again everyone wins. It would also fulfil the requirements of 2007-01. Most small SPs and end-users wouldn't mind becoming members if cost-effective. What they don't want is the hassle of learning LIR procedures. rgds, Sascha Luck > > Thanks, > Sander > From mark at streamservice.nl Tue May 4 19:22:29 2010 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 4 May 2010 19:22:29 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504163108.GA97690@cilantro.c4inet.net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> <20100504163108.GA97690@cilantro.c4inet.net> Message-ID: <0da101caebae$61cdbaf0$256930d0$@nl> > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Sascha Luck > Sent: Tuesday, May 04, 2010 6:31 PM > To: Sander Steffann > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > Hi Sander, all, > > On Tue, May 04, 2010 at 04:29:50PM +0200, Sander Steffann wrote: > > What would then be the difference between PI and PA addresses? Do you > > think we should get rid of that distinction completely, or is this > not > > what you mean? I heard people talk about the distinction here at the > > RIPE meeting in Prague, so it seems to be a topic of discussion. > > I would be in favour of abandoning the distinction altogether for ipv6. > > 1) In ipv4, even now, many "LIRs" use PA space as "PI space", simply > because it was deemed easier to just become a LIR than go through > the PI "mill". Conversely, as mentioned, a lot of PI space is used as > "PA lite", this usually because it is cheaper and: > > 2) Many orgs have no staff trained in LIR procedures (and no time/money > to change that) and would gladly hand the bureaucracy off to their > friendly local LIR. > > 3) If address space were, simply, that, LIR functions could be handled > by "qualified" orgs and their customers (be they end-users or SPs) can > get routable and assignable address space; everyone wins. > > 4) Conceivably, if every "assignee" would have to become a member, > membership fees for everyone should fall significantly; again everyone > wins. It would also fulfil the requirements of 2007-01. Most small > SPs and end-users wouldn't mind becoming members if cost-effective. > What they don't want is the hassle of learning LIR procedures. I couldn't think for better words, I totally agree with points 1 to 4! Regards, Mark > > > rgds, > Sascha Luck > > > > > > Thanks, > > Sander > > From michael.dillon at bt.com Tue May 4 19:53:09 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 4 May 2010 18:53:09 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <804207D0-3390-4B64-AD96-1AB18E98F9E9@steffann.nl> Message-ID: <28E139F46D45AF49A31950F88C49745805F70AE3@E03MVZ2-UKDY.domain1.systemhost.net> > What would then be the difference between PI and PA > addresses? Do you think we should get rid of that distinction > completely, or is this not what you mean? I heard people talk > about the distinction here at the RIPE meeting in Prague, so > it seems to be a topic of discussion. The difference has nothing to do with the English words provider, aggregatable, and independent. They are meaningless. The difference has nothing to do with LIRs, votings rights, fees, etc. It has nothing to do with ASNs or Autonomous Systems. This is all meanlingless jargon unless you are initiated into the secret society of the RIR (Respublica Iconoscentorum Regurgitentorum). It is simple. A PA block is used to carve out smaller blocks which are delegated to other organizations, who then manage those smaller blocks. A PI block is managed by the recipient of the RIPE allocation. A PA block goes to an organization whose core business is about GROWING the network by connecting other autonomous networks. They delegate blocks to those networks and provide connectivity to them. That is all. A PI block goes to an organization who manages a network which can also contain portions that are not owned by the organization, but which are managed on behalf of other organizations. The typical example is the data centre operator who rents a room to someone who rents a rack to someone who rents a server to someone who rents a VPS to someone who rents a website (or ecommerce storefront) to someone. That is 6 steps removed from the RIPE relationship, but the PI recipient still manages all the IP addressing for all of these layers of organizations. And there might be only one layer too. For RIPE, the main thing is that companies whose core business concerns network growth, want to be involved in IP addressing policy because they understand how important it is to their business. There is an old story, which I first heard in a Japanese version, but here is a link to a short English rhyming poem called "For the want of a nail" IP networks are very much like that because you can invest huge sums of money running fibre to another country, buying a building, fitting it with racks and power and air conditioning, buying and installing routers. But when it comes time to turn it on and start moving packets, if you haven't got one of those free IP addresses to use on the devices, your entire investment could be lost. I'm sure that many of you have run into situations where you were called in to help with a customer problem that was escalated to a high executive level, and the root cause of the problem was that people were not paying attention to IP address supply, and never looked for an address until the last minute. Then, when they discovered that the spreadsheet they had been using for the last two years had no spare addresses, they were lost because nobody could remember how to get more adresses to replenish the spreadsheet. I've had this experience in more than one company. The IP address supply chain is of great interest to people with PA blocks, because they struggle to manage it internally, and need to know that there is some stability of supply. They want to maintain relationshops with all the other large consumers of addresses and keep tabs on them. But organizations with PI blocks have it relatively simple, partly because they are smaller businesses, partly because they don't grow as quickly and have more control over the speed of growth. A PI organization is generally satisfied with the two-party relationship that they have with RIPE. In a sense, the PI recipient is rather like one of those organizations that receives an IP address delegation from a PA recipient. But they want to maintain separate suppliers for their network access supply chain and their IP addressing supply chain. --Michael Dillon From gert at space.net Tue May 4 21:46:58 2010 From: gert at space.net (Gert Doering) Date: Tue, 4 May 2010 21:46:58 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <4BE04D84.7070006@baycix.de> <20100504163507.GB97690@cilantro.c4inet.net> Message-ID: <20100504194658.GX60850@Space.Net> Hi, On Tue, May 04, 2010 at 04:35:07PM +0000, Sascha Luck wrote: > On Tue, May 04, 2010 at 05:22:43PM +0200, Gert Doering wrote: > > "if people can use PI to give single IPv6 addresses to their end > > customers, we might see DSL deployments with single address + NAT, > > and this not something I want to see"...) > > Me neither. Maybe change the policy to require assigning > min /64 in conjunction with making it assignable? "Why bother making a very complicated PI policy while having a fairly simple PA policy"? On Tue, May 04, 2010 at 06:38:28PM +0200, Sascha Lenz wrote: > well, if we like it or not, there always will be the point about "if we > can't do exactly the same thing with IPv6 as we do now with IPv4, we > don't care about IPv6 anytime soon". > > So from this p.o.v. it should be clear that both policies should be > harmoni[s|z]ed. > But is that what we want? So we should have very restrictive IPv6 polices that demand that you justify every single address used? That would be "fully harmonized". I'd say that this is the wrong direction to go. IPv6 deserves better. [..] > So i would opt for the simplest answer to the question: > We tell the RIPE NCC that this is all intended as it is now, no change > needed - and see what happens next (e.g. someone coming up with a formal > PDP proposal, stating that his company (or so) desperately needs a > change here) > > Reasoning: For now it seems it is rather a problem for the NCC, what > they should tell the requesting parties, not so much a community problem > since no company/person came up with a formal PDP proposal to change > anything here. > I'm happy to rethink my position though if this discussion is going > somewhere smelling like a consensus. This is one possible result of the discussion - "the community is aware of the issue, but decides not to change anything". I think the NCC would be fine with that response, they just want to be sure we've considered our options :-) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Tue May 4 21:50:23 2010 From: gert at space.net (Gert Doering) Date: Tue, 4 May 2010 21:50:23 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <0d6e01caebaa$391278c0$ab376a40$@nl> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> <20100504154312.GS60850@Space.Net> <0d6e01caebaa$391278c0$ab376a40$@nl> Message-ID: <20100504195023.GY60850@Space.Net> Hi, On Tue, May 04, 2010 at 06:52:41PM +0200, Mark Scholten wrote: > The current options we have to implement IPv6 prevent us from implementing > it. There are multiple problems we see currently: > - We probably won't get PI IPv6 space Where do you see the hurdle? > - With IPv6 we would like to offer a client (collocation) at least a /112 > (with PI this isn't allowed if I'm correctly informed) This is the "datacenter" / "hosting shop" case I mentioned, and this definitely needs clarification what the community views as useful here. (Note that you can't do this with IPv4 PI either, giving customers in your colocation space a, say, /29 from your IPv4 PI range) > - PA IPv6 address space is currently not available for us (this also > prevents us to implement IPv6) You *could* become a LIR... which would make IPv6 PA space available very easily. > We also know some networks (with AS number) that currently use IPv4 PI and > don't are a LIR (and don't use IPv4 PA). They also need a solution for the > mentioned problems before they could implement IPv6. I'm not sure I understand why they wouldn't be able to use IPv6 PI...? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Tue May 4 22:06:40 2010 From: gert at space.net (Gert Doering) Date: Tue, 4 May 2010 22:06:40 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504152243.GO60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> Message-ID: <20100504200640.GA64742@Space.Net> Hi, this discussion feels somewhat familiar, especially the part "we should remove the distinction PA/PI". So I checked my archives, and found someting I wrote at the last round, in July 2009, in the context of "our web hosting shop cannot get IPv6 PI addresses!"... -------------------------- quote -------------------------------------------- I think one of the focal points here is the question on whether 'giving a hosted web server an IP address' is 'assigning address space to end users'. The boundary cases ("the customer has a virtual web presence and not even a dedicated IP address" and "the customer is running their own web farm and the ISP routes a /24 towards their firewall") are pretty clear - but there is lots of space for different way to do web server hosting in between (managed servers, rented servers, real servers, vmware entities, vserver/jailed virtual servers, ...) [...] People have argued to remove the PA/PI distinction. I don't think that this is the right way (due to the fact that PA allocations necessarily need to be more liberal than PI assignments), but maybe we need to loosen up PI rules a bit, as in: "Using addresses from a PI block to number other parties' devices is permitted as long as these devices are connected to the same network, documentation about the usage can be presented to the RIPE NCC, and full responsibility for the addresses (abuse handling etc) is done by the PI holder". (After all, one of the reasons why we document end user assignments in a public database is to be able to contact a person feeling responsible for troubleshooting and abuse handling) "same network" is important to make it crystal clear that "get a chunk of PI and sell off smaller bits to 3rd parties connecting at random to other ISPs" is not the desired intention. -------------------------- quote -------------------------------------------- At that time, there was one voice agreeing with me, a few more comments, and then the thread sort of died. Looking at the text today, I think it fits the "hosting provider issue" quite well. It does allow loopholes for "large-scale end user access" ISPs (those that use IPv4 PI for single-address-end-user connections today), so we might need to think a bit more about the concept and the goals, before agreeing on specific wording. Some food for tomorrow's discussion. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 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 mark at streamservice.nl Wed May 5 00:39:02 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 5 May 2010 00:39:02 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504200640.GA64742@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> <20100504200640.GA64742@Space.Net> Message-ID: <0dc901caebda$98690de0$c93b29a0$@nl> > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Gert Doering > Sent: Tuesday, May 04, 2010 10:07 PM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > Hi, > > this discussion feels somewhat familiar, especially the part "we should > remove the distinction PA/PI". So I checked my archives, and found > someting I wrote at the last round, in July 2009, in the context of > "our web hosting shop cannot get IPv6 PI addresses!"... > > -------------------------- quote -------------------------------------- > ------ > I think one of the focal points here is the question on whether 'giving > a hosted web server an IP address' is 'assigning address space to end > users'. > > The boundary cases ("the customer has a virtual web presence and not > even a dedicated IP address" and "the customer is running their own web > farm and the ISP routes a /24 towards their firewall") are pretty clear > - but there is lots of space for different way to do web server hosting > in between (managed servers, rented servers, real servers, vmware > entities, vserver/jailed virtual servers, ...) > > [...] > > People have argued to remove the PA/PI distinction. I don't think that > this is the right way (due to the fact that PA allocations necessarily > need > to be more liberal than PI assignments), but maybe we need to loosen up > PI rules a bit, as in: > > "Using addresses from a PI block to number other parties' devices is > permitted as long as these devices are connected to the same network, > documentation about the usage can be presented to the RIPE NCC, and > full responsibility for the addresses (abuse handling etc) is done by > the PI holder". > > > (After all, one of the reasons why we document end user assignments in > a > public database is to be able to contact a person feeling responsible > for > troubleshooting and abuse handling) > > "same network" is important to make it crystal clear that "get a chunk > of PI and sell off smaller bits to 3rd parties connecting at random to > other ISPs" is not the desired intention. > -------------------------- quote -------------------------------------- > ------ > > At that time, there was one voice agreeing with me, a few more > comments, > and then the thread sort of died. > > Looking at the text today, I think it fits the "hosting provider issue" > quite well. It does allow loopholes for "large-scale end user access" > ISPs (those that use IPv4 PI for single-address-end-user connections > today), so we might need to think a bit more about the concept and the > goals, before agreeing on specific wording. I agree with this idea (as I think this is a great solution for the mentioned problem and I don't see problems with this idea). Regards, Mark > > Some food for tomorrow's discussion. > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 150584 > > 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 mark at streamservice.nl Wed May 5 00:39:02 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 5 May 2010 00:39:02 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504195023.GY60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> <20100504154312.GS60850@Space.Net> <0d6e01caebaa$391278c0$ab376a40$@nl> <20100504195023.GY60850@Space.Net> Message-ID: <0dca01caebda$98c314c0$ca493e40$@nl> > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Gert Doering > Sent: Tuesday, May 04, 2010 9:50 PM > To: Mark Scholten > Cc: 'Gert Doering'; 'Richard Hartmann'; 'Carsten Schiefner'; address- > policy-wg at ripe.net > Subject: Re: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > Hi, > > On Tue, May 04, 2010 at 06:52:41PM +0200, Mark Scholten wrote: > > The current options we have to implement IPv6 prevent us from > > implementing it. There are multiple problems we see currently: > > - We probably won't get PI IPv6 space > > Where do you see the hurdle? See my point below (co location for customers). > > > - With IPv6 we would like to offer a client (collocation) at least a > > /112 (with PI this isn't allowed if I'm correctly informed) > > This is the "datacenter" / "hosting shop" case I mentioned, and this > definitely needs clarification what the community views as useful here. > > (Note that you can't do this with IPv4 PI either, giving customers in > your colocation space a, say, /29 from your IPv4 PI range) With IPv4 customers "accept"/"understand" that IP space is limited and giving 1 IP/server is accepted by the customers we have, with IPv6 a few of our clients won't accept it. They will probably at least require/use 20 IP addresses (so they don't need to run services on "strange" ports). > > > - PA IPv6 address space is currently not available for us (this also > > prevents us to implement IPv6) > > You *could* become a LIR... which would make IPv6 PA space available > very easily. Becoming a LIR would also mean doing the paperwork that comes with it and we now have another organization doing that for us (and we don't really have the time for it to do it). > > > We also know some networks (with AS number) that currently use IPv4 > PI > > and don't are a LIR (and don't use IPv4 PA). They also need a > solution > > for the mentioned problems before they could implement IPv6. > > I'm not sure I understand why they wouldn't be able to use IPv6 PI...? Some of them have also co location clients that now have 1 IP (acceptable under current IPv4 PI rules) that will require multiple IPv6 addresses. Regards, Mark > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 150584 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jim at rfc1035.com Wed May 5 09:06:11 2010 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 May 2010 08:06:11 +0100 Subject: [address-policy-wg] PA & PI space for v4/6 In-Reply-To: <20100504194658.GX60850@Space.Net> References: <20100504194658.GX60850@Space.Net> Message-ID: <759707C0-20D2-48F0-85B2-9C8BEC024FAC@rfc1035.com> On 4 May 2010, at 20:46, Gert Doering wrote: > "Why bother making a very complicated PI policy while having a fairly > simple PA policy"? To give a less than subtle hint that people should get their own PA space and not bother with PI? :-) From gert at space.net Wed May 5 09:24:43 2010 From: gert at space.net (Gert Doering) Date: Wed, 5 May 2010 09:24:43 +0200 Subject: [address-policy-wg] PA & PI space for v4/6 In-Reply-To: <759707C0-20D2-48F0-85B2-9C8BEC024FAC@rfc1035.com> References: <20100504194658.GX60850@Space.Net> <759707C0-20D2-48F0-85B2-9C8BEC024FAC@rfc1035.com> Message-ID: <20100505072443.GA60850@Space.Net> Hi Jim, On Wed, May 05, 2010 at 08:06:11AM +0100, Jim Reid wrote: > On 4 May 2010, at 20:46, Gert Doering wrote: > > > "Why bother making a very complicated PI policy while having a fairly > > simple PA policy"? > > To give a less than subtle hint that people should get their own PA > space and not bother with PI? :-) Well, that's what we have now - a PI policy that just doesn't permit use of PI for certain things. The suggestion was to loosen that up, and add complicated rules to define what exactly we want... So "not changing anything" would certainly be a strong hint "use PA!" :-) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From richih.mailinglist at gmail.com Wed May 5 10:22:23 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 5 May 2010 10:22:23 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504154312.GS60850@Space.Net> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> <20100504152243.GO60850@Space.Net> <20100504154312.GS60850@Space.Net> Message-ID: On Tue, May 4, 2010 at 17:43, Gert Doering wrote: > There is no real incentive to do so, as you can get a huuuuuge block of > addresses fairly easily. No incentive and no sane reason never stopped people from doing weird stuff ;) > The incentive to do this with PI is "save on the costs" - and then, since > the PI policy doesn't permit you to give address blocks from the PI space > to your access customers, the consequence would be "if you can only give > a single IPv6 address to the customers, that's all the customer is going > to get" (and the blame will be pointed to the RIPE NCC). Unless I am mistaken, a /64 PI has the same cost as a /32 PI. That being said, I initially assumed that "differences of technical nature and in sheer abundance" do not matter which was wrong, plain and simple. My natural assumption was that no sub-allocation would ever be smaller than /64, but of course this needs to be put into text. Richard From k13 at nikhef.nl Wed May 5 10:15:36 2010 From: k13 at nikhef.nl (Rob Blokzijl) Date: Wed, 5 May 2010 10:15:36 +0200 (MET DST) Subject: [address-policy-wg] Registry - not a policy proposal Message-ID: [apologies for duplicate mails] Dear RIPE, soon there will be no more IPv4. However, we still have a registry of these addresses. Daniel Karrenberg and myself have produced a document (attached to this mail) which describes what we think the role of this registry should be after the runout of the unallocated IPv4 address space. We will present this document in the Address Policy WG, and would like to invite you to let us know your thoughts. The place for further discussion will be . Thank you for your attention, Rob Blokzijl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: registry.txt URL: From irtf at tonistoev.info Wed May 5 12:02:31 2010 From: irtf at tonistoev.info (Toni Stoev) Date: Wed, 5 May 2010 13:02:31 +0300 Subject: [address-policy-wg] Registry - not a policy proposal In-Reply-To: References: Message-ID: <201005051302.31495.irtf@tonistoev.info> On Wednesday 05 May 2010 at 11:15:36 Rob Blokzijl sent: > > [apologies for duplicate mails] > > Dear RIPE, > > soon there will be no more IPv4. However, we still have a registry > of these addresses. Perhaps you mean "no more unallocated IPv4 addresses". > > Daniel Karrenberg and myself have produced a document (attached to > this mail) which describes what we think the role of this registry > should be after the runout of the unallocated IPv4 address space. > > We will present this document in the Address Policy WG, and would > like to invite you to let us know your thoughts. The place for > further discussion will be . > > Thank you for your attention, > > Rob Blokzijl From entity at tonistoev.info Wed May 5 12:07:16 2010 From: entity at tonistoev.info (Toni Stoev) Date: Wed, 5 May 2010 13:07:16 +0300 Subject: [address-policy-wg] Registry - not a policy proposal Message-ID: <201005051307.17076.entity@tonistoev.info> On Wednesday 05 May 2010 at 11:15:36 Rob Blokzijl sent: > > [apologies for duplicate mails] > > Dear RIPE, > > soon there will be no more IPv4. However, we still have a registry > of these addresses. Perhaps you mean "no more unallocated IPv4 addresses". > > Daniel Karrenberg and myself have produced a document (attached to > this mail) which describes what we think the role of this registry > should be after the runout of the unallocated IPv4 address space. > > We will present this document in the Address Policy WG, and would > like to invite you to let us know your thoughts. The place for > further discussion will be . > > Thank you for your attention, > > Rob Blokzijl From bmanning at vacation.karoshi.com Wed May 5 13:41:28 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 5 May 2010 11:41:28 +0000 Subject: [address-policy-wg] Registry - not a policy proposal In-Reply-To: <201005051302.31495.irtf@tonistoev.info> References: <201005051302.31495.irtf@tonistoev.info> Message-ID: <20100505114128.GA773@vacation.karoshi.com.> On Wed, May 05, 2010 at 01:02:31PM +0300, Toni Stoev wrote: > On Wednesday 05 May 2010 at 11:15:36 Rob Blokzijl sent: > > > > [apologies for duplicate mails] > > > > Dear RIPE, > > > > soon there will be no more IPv4. However, we still have a registry > > of these addresses. > > Perhaps you mean "no more unallocated IPv4 addresses". actualy, its all been allocated and has been for years its just likely that some of the pool holders may be dorment for a while (the IANA, the RIRs) > > > > > Daniel Karrenberg and myself have produced a document (attached to > > this mail) which describes what we think the role of this registry > > should be after the runout of the unallocated IPv4 address space. > > > > We will present this document in the Address Policy WG, and would > > like to invite you to let us know your thoughts. The place for > > further discussion will be . > > > > Thank you for your attention, > > > > Rob Blokzijl From michael.dillon at bt.com Wed May 5 14:47:00 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 May 2010 13:47:00 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <0d6e01caebaa$391278c0$ab376a40$@nl> Message-ID: <28E139F46D45AF49A31950F88C49745805F70FFF@E03MVZ2-UKDY.domain1.systemhost.net> > - With IPv6 we would like to offer a client (collocation) at > least a /112 (with PI this isn't allowed if I'm correctly informed) This points out a material difference between IPv6 and IPv4. IPv6 is classful. Normally, ISPs get a /32 class allocation and give their customers /48 class assignments. Currently the PI policy comes from wanting to allow organizations to get a /48 class assignment from RIPE directly. But if the organization is involved in the hosting business, it is conceivable that customers will expect to receive a /48 class block from the data centre operator. Forget whether this is allowed or not because that is irrelevant. The point is that in the IPv6 world there is the expectation that no network will ever get less than a /64. In a data centre environment one would expect that people renting a server or even a rack, would be satisfied with a /64. But people renting a room, or a row of racks, might justifiably demand a /48 for their own internal subnetting and routing, even if much of it happens on virtual routers and switches. With the increasing number of cores per chip, even an organization renting a full rack might need more than a /64 because they need to have a network hierarchy within their rack. The problem is that /48 class blocks can't be stretched. In IPv4, there are no classes and everyone allocates according to strict needs now and in the very near future. But IPv6 has classes and allocates so that 99% of allocations can be permanent and never have to be expanded. We would not want organizations asking for a /40 PI allocation this year, then returning next year for another /40, and the year after that. The only way out that I can see is to treat a data centre like an ISP and offer organizations one /32 for each data centre that they operate. This would not apply to WAN operators since they can ask RIPE for a /30 or a /28 to cover all of their WAN and all data centres, then allocate internally at whatever bit boundary is appropriate. One thing that RIPE should never accept is any plan that assigns less than /64 to a network. If such a plan is submitted, it should be returned and the applicant should be requested to expand any longer prefixes to a full /64, then resubmit. In other words, if you ask for too few addresses, RIPE should deny the request, because it is not in line with IPv6 architecture. --Michael Dillon From michael.dillon at bt.com Wed May 5 15:26:32 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 May 2010 14:26:32 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504195023.GY60850@Space.Net> Message-ID: <28E139F46D45AF49A31950F88C49745805F7107E@E03MVZ2-UKDY.domain1.systemhost.net> > > - With IPv6 we would like to offer a client (collocation) > at least a > > /112 (with PI this isn't allowed if I'm correctly informed) > (Note that you can't do this with IPv4 PI either, giving > customers in your colocation space a, say, /29 from your IPv4 > PI range) Sure you can. People do this all the time. "Give" just means that the PI recipient allows their customer to use a /29. There is no transfer of ownership because there is no ownership. RIPE rules only cover "assignment" of addresses to customers, not "giving", "using", "delegating" or any other term. The only people who really understand the distinctions between assignments and allocations, are the people who deal directly with RIPE. For everyone else, the world is many shades of grey. --Michael Dillon From michael.dillon at bt.com Wed May 5 16:00:42 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 May 2010 15:00:42 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <20100504200640.GA64742@Space.Net> Message-ID: <28E139F46D45AF49A31950F88C49745805F7110F@E03MVZ2-UKDY.domain1.systemhost.net> > "Using addresses from a PI block to number other parties' devices is > permitted as long as these devices are connected to the > same network, > documentation about the usage can be presented to the RIPE NCC, and > full responsibility for the addresses (abuse handling etc) > is done by > the PI holder". Such a long explanation! Right now it says this: The PI assignment cannot be further assigned to other organisations. How about changing it like this: The PI assignment cannot be further assigned to other organisations unless their network infrastructure is wholly contained within the same building as the applicant for a PI assignment. If the word "wholly" seems to old-fashioned, replace it with "completely". Or you could say The PI assignment can be used for any devices connected to the network on the PI applicant's premises such as a data centre, regardless of who owns and controls those devices. --Michael Dillon From Jamie.Stallwood at imerja.com Wed May 5 17:08:49 2010 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Wed, 5 May 2010 16:08:49 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space References: <28E139F46D45AF49A31950F88C49745805F7110F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD3283@bhw-srv-dc1.imerja.com> Hello, [de-lurk] Are split-location delegations any different / more evil than TE'd or distinct-routed subnets? I can't see where this is going. Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood at imerja.com -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of michael.dillon at bt.com Sent: Wed 5/5/2010 15:00 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > "Using addresses from a PI block to number other parties' devices is > permitted as long as these devices are connected to the > same network, > documentation about the usage can be presented to the RIPE NCC, and > full responsibility for the addresses (abuse handling etc) > is done by > the PI holder". Such a long explanation! Right now it says this: The PI assignment cannot be further assigned to other organisations. How about changing it like this: The PI assignment cannot be further assigned to other organisations unless their network infrastructure is wholly contained within the same building as the applicant for a PI assignment. If the word "wholly" seems to old-fashioned, replace it with "completely". Or you could say The PI assignment can be used for any devices connected to the network on the PI applicant's premises such as a data centre, regardless of who owns and controls those devices. --Michael Dillon -- 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 richih.mailinglist at gmail.com Wed May 5 17:43:35 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 5 May 2010 17:43:35 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <7B640CC73C18D94F83479A1D0B9A140402AD3283@bhw-srv-dc1.imerja.com> References: <28E139F46D45AF49A31950F88C49745805F7110F@E03MVZ2-UKDY.domain1.systemhost.net> <7B640CC73C18D94F83479A1D0B9A140402AD3283@bhw-srv-dc1.imerja.com> Message-ID: (HTML email is evil) On Wed, May 5, 2010 at 17:08, Jamie Stallwood wrote: > [de-lurk] Are split-location delegations any different / more evil than TE'd > or distinct-routed subnets? I can't see where this is going. I can't see why a geographical distinction would make sense, either. At the very least, you are excluding anyone who is split into two buildings for redundancy and I did not think about this for more than a few seconds. RIchard From mark at streamservice.nl Wed May 5 19:28:05 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 5 May 2010 19:28:05 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <28E139F46D45AF49A31950F88C49745805F70FFF@E03MVZ2-UKDY.domain1.systemhost.net> References: <0d6e01caebaa$391278c0$ab376a40$@nl> <28E139F46D45AF49A31950F88C49745805F70FFF@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0ea701caec78$526323a0$f7296ae0$@nl> > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of michael.dillon at bt.com > Sent: Wednesday, May 05, 2010 2:47 PM > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > > > - With IPv6 we would like to offer a client (collocation) at > > least a /112 (with PI this isn't allowed if I'm correctly informed) > > This points out a material difference between IPv6 and IPv4. > > IPv6 is classful. Normally, ISPs get a /32 class allocation and > give their customers /48 class assignments. Currently the PI policy > comes from wanting to allow organizations to get a /48 class > assignment from RIPE directly. But if the organization is involved > in the hosting business, it is conceivable that customers will > expect to receive a /48 class block from the data centre operator. > > Forget whether this is allowed or not because that is irrelevant. > The point is that in the IPv6 world there is the expectation that > no network will ever get less than a /64. In a data centre environment > one would expect that people renting a server or even a rack, would > be satisfied with a /64. But people renting a room, or a row of racks, > might justifiably demand a /48 for their own internal subnetting and > routing, even if much of it happens on virtual routers and switches. > With the increasing number of cores per chip, even an organization > renting a full rack might need more than a /64 because they need > to have a network hierarchy within their rack. > > The problem is that /48 class blocks can't be stretched. In IPv4, > there are no classes and everyone allocates according to strict needs > now and in the very near future. But IPv6 has classes and allocates > so that 99% of allocations can be permanent and never have to be > expanded. > > We would not want organizations asking for a /40 PI allocation this > year, then returning next year for another /40, and the year after > that. > > The only way out that I can see is to treat a data centre like an ISP > and offer organizations one /32 for each data centre that they operate. > This would not apply to WAN operators since they can ask RIPE for a /30 > or a /28 to cover all of their WAN and all data centres, then allocate > internally at whatever bit boundary is appropriate. > > One thing that RIPE should never accept is any plan that assigns less > than > /64 to a network. If such a plan is submitted, it should be returned > and > the applicant should be requested to expand any longer prefixes to a > full > /64, then resubmit. In other words, if you ask for too few addresses, > RIPE > should deny the request, because it is not in line with IPv6 > architecture. Note my mentioning of the words "at least" if a /64 is confirming to the "rules" allowed to give in use of a client then we would be giving them a /64 (as long as it is a VPS/colo/dedi/etc.). With the option to "use" the IP space we mean that they can use it for their servers as long as they are our clients. When they move they will need to renumber (or they need to have PI space). > > > --Michael Dillon From Jamie.Stallwood at imerja.com Thu May 6 00:08:35 2010 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Wed, 5 May 2010 23:08:35 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8) References: Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD3286@bhw-srv-dc1.imerja.com> Hi RIPE, In this proposal, to ensure the correct timing of this implementation, perhaps the following change on para. 1, from: On application for IPv4 resources when the RIPE NCC is holding the equivalent of a /8 or less of IPv4 address space, LIRs will receive IPv4 addresses according to the following: etc. to On application for IPv4 resources when the RIPE NCC is holding the equivalent of a /8 or less of IPv4 address space and the IANA free pool contains no available /8 blocks, LIRs will receive IPv4 addresses according to the following: Since the trigger conditions are stated only in the preamble and not the text itself. The conditions in the statement imply that if RIPE receives or retrieves addresses that bring its store back over 2^24, the allocation method reverts to "status quo". I think this is probably a good thing as you never know if the pool is suddenly revived again! Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood at imerja.com -- 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 Jamie.Stallwood at imerja.com Thu May 6 00:32:08 2010 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Wed, 5 May 2010 23:32:08 +0100 Subject: [address-policy-wg] RE: 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD3287@bhw-srv-dc1.imerja.com> Hi RIPE, Today's discussion was interesting and concern was raised about commercials being able to get all or most of the address space set aside in the proposal, and about unfair commercial advantage. My thoughts as a paragraph, which I know is rushed and woolly and only intended as a discussion point: 3.5 Use by Commercial Organizations Temporary address space will not be assigned by the RIPE NCC to any commercial organization where such an allocation: * Is not shown to be for a research, development or testing project relevant to an operational business of that organization * Does not seek to provide a "benefit", e.g. through published work in academic or industrial journals, or * Is unable to demonstrate a fair inclusion policy for other commercial organizations to contribute to, or benefit from, the project. [Address allocation is at the RIPE NCC?s discretion, but subject to the RIPE NCC Conflict Arbitration Procedure.] Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood at imerja.com -- 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 Marcus.Gerdon at versatel.de Thu May 6 08:42:49 2010 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Thu, 6 May 2010 08:42:49 +0200 Subject: AW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space Message-ID: <227142482560EF458FF1F7E784E26AB802577E92@FLBVEXCH01.versatel.local> In the scenario described here I'd tend to think the colocation/housing provider imho is going for ISP bussiness. Handing out chunks of address space to customers, which are supposedly going to be single-homed, documenting them etc. sounds like LIR business. Multi-homing these chunks independent of wether they are PI or PA gets to the 'sub-allocation' topic - which isn't supposed to be done using parts of a PI space *assigned* to another party. Who's going to handle abuse and what ever else might come from the address usage? My opinion I'm led to by this scenario is that there's someone who wants to circumvent the administrative tasks and save a few $$$ by doing ISP/LIR bussiness within PI space. Accordingly I think the policy should be kept at (noted at a quick) - single address for connecting a customers server => PI - prefix routed onto customers server => *no* PI - go for LIR - prefix/range further distributed by customer himself => *no* PI - go for LIR - contained /64 (!) segment (i.e. dedicated vlan for a customers rack) => I think somewhat of a border case, but tend to *no* PI Surely everyone wanting to can become a LIR, and everyone wanting to hand out chunks of address space to other parties is able to request an allocation, or did I miss something? @Mark: >>PA IPv6 address space is currently not available for us Why's that? Sorry for asking a possibly obvisous question, but going over the PA policies now I'm simply to lazy. :) I can remember that there's been a discussion quite some time ago where someone stated he's not able/allowed the LIR contracts with RIPE due to regulatory/legal issue or something like that. In case something like this is the underlying reason why PI is used for ISP/LIR bussiness then imho RIPE/NCC should look into solving this 'organizational' problem directly instead of bending policies around making PI into PA lite. Just my 2c. regards, Marcus ----------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Gesch?ftsf?hrer: Dr. Hai Cheng, Joachim Bellinghoven ----------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 / AS29610 | MG3031-RIPE ----------------------------------------------------------------------------------------- > -----Urspr?ngliche Nachricht----- > Von: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von > michael.dillon at bt.com > Gesendet: Mittwoch, 5. Mai 2010 14:47 > An: address-policy-wg at ripe.net > Betreff: RE: [address-policy-wg] Discrepancy Between RIPE > Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > > > > - With IPv6 we would like to offer a client (collocation) at > > least a /112 (with PI this isn't allowed if I'm correctly informed) > > This points out a material difference between IPv6 and IPv4. > > IPv6 is classful. Normally, ISPs get a /32 class allocation and > give their customers /48 class assignments. Currently the PI policy > comes from wanting to allow organizations to get a /48 class > assignment from RIPE directly. But if the organization is involved > in the hosting business, it is conceivable that customers will > expect to receive a /48 class block from the data centre operator. > > Forget whether this is allowed or not because that is irrelevant. > The point is that in the IPv6 world there is the expectation that > no network will ever get less than a /64. In a data centre environment > one would expect that people renting a server or even a rack, would > be satisfied with a /64. But people renting a room, or a row of racks, > might justifiably demand a /48 for their own internal subnetting and > routing, even if much of it happens on virtual routers and switches. > With the increasing number of cores per chip, even an organization > renting a full rack might need more than a /64 because they need > to have a network hierarchy within their rack. > > The problem is that /48 class blocks can't be stretched. In IPv4, > there are no classes and everyone allocates according to strict needs > now and in the very near future. But IPv6 has classes and allocates > so that 99% of allocations can be permanent and never have to be > expanded. > > We would not want organizations asking for a /40 PI allocation this > year, then returning next year for another /40, and the year > after that. > > The only way out that I can see is to treat a data centre like an ISP > and offer organizations one /32 for each data centre that > they operate. > This would not apply to WAN operators since they can ask RIPE > for a /30 > or a /28 to cover all of their WAN and all data centres, then allocate > internally at whatever bit boundary is appropriate. > > One thing that RIPE should never accept is any plan that assigns less > than > /64 to a network. If such a plan is submitted, it should be > returned and > the applicant should be requested to expand any longer prefixes to a > full > /64, then resubmit. In other words, if you ask for too few addresses, > RIPE > should deny the request, because it is not in line with IPv6 > architecture. > > > --Michael Dillon > > From richih.mailinglist at gmail.com Thu May 6 10:50:29 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 6 May 2010 10:50:29 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <227142482560EF458FF1F7E784E26AB802577E92@FLBVEXCH01.versatel.local> References: <227142482560EF458FF1F7E784E26AB802577E92@FLBVEXCH01.versatel.local> Message-ID: On Thu, May 6, 2010 at 08:42, Marcus.Gerdon wrote: > - single address for connecting a customers server > ? ? ? ?=> PI > - contained /64 (!) segment (i.e. dedicated vlan for a customers rack) > ? ? ? ?=> I think somewhat of a border case, but tend to *no* PI A /64 in IPv6 is what a single address is for IPv4. This is obviously a _very_ reduced view for the sake of my argument, but I think doing this is valid, in this case. Richard From mark at streamservice.nl Thu May 6 11:21:03 2010 From: mark at streamservice.nl (Mark Scholten) Date: Thu, 6 May 2010 11:21:03 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <227142482560EF458FF1F7E784E26AB802577E92@FLBVEXCH01.versatel.local> References: <227142482560EF458FF1F7E784E26AB802577E92@FLBVEXCH01.versatel.local> Message-ID: <0f6101caecfd$730b4580$5921d080$@nl> > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Marcus.Gerdon > Sent: Thursday, May 06, 2010 8:43 AM > To: address-policy-wg at ripe.net > Subject: AW: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > In the scenario described here I'd tend to think the colocation/housing > provider imho is going for ISP bussiness. > > Handing out chunks of address space to customers, which are supposedly > going to be single-homed, documenting them etc. sounds like LIR > business. Multi-homing these chunks independent of wether they are PI > or PA gets to the 'sub-allocation' topic - which isn't supposed to be > done using parts of a PI space *assigned* to another party. Who's going > to handle abuse and what ever else might come from the address usage? > > My opinion I'm led to by this scenario is that there's someone who > wants to circumvent the administrative tasks and save a few $$$ by > doing ISP/LIR bussiness within PI space. > > Accordingly I think the policy should be kept at (noted at a quick) > > - single address for connecting a customers server > => PI > - prefix routed onto customers server > => *no* PI - go for LIR > - prefix/range further distributed by customer himself > => *no* PI - go for LIR > - contained /64 (!) segment (i.e. dedicated vlan for a customers rack) > => I think somewhat of a border case, but tend to *no* PI > > Surely everyone wanting to can become a LIR, and everyone wanting to > hand out chunks of address space to other parties is able to request an > allocation, or did I miss something? > > @Mark: > >>PA IPv6 address space is currently not available for us > Why's that? Sorry for asking a possibly obvisous question, but going > over the PA policies now I'm simply to lazy. :) Becoming a LIR is from a business economics view not good for us and the network we use doesn't offer IPv6 PA, so the only option left without moving to another network is to use IPv6 PI. But if we are required to be a LIR we will also require more IPv4 IP space so we have enough for the future. Is it a target by preventing us to use IPv6 PI to use the last IPv4 IPs as fast as possible? We currently not even use a /22 IPv4 space, but when we need to become a LIR we will look for ways to get more IPv4 space. Regards, Mark > > I can remember that there's been a discussion quite some time ago where > someone stated he's not able/allowed the LIR contracts with RIPE due to > regulatory/legal issue or something like that. In case something like > this is the underlying reason why PI is used for ISP/LIR bussiness then > imho RIPE/NCC should look into solving this 'organizational' problem > directly instead of bending policies around making PI into PA lite. > > Just my 2c. > > regards, > > Marcus > > ----------------------------------------------------------------------- > ------------------ > Engineering IP Services > > Versatel West GmbH > Unterste-Wilms-Strasse 29 > D-44143 Dortmund > > Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 > marcus.gerdon at versatel.de | www.versatel.de > > Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 > Gesch?ftsf?hrer: Dr. Hai Cheng, Joachim Bellinghoven > ----------------------------------------------------------------------- > ------------------ > AS8881 / AS8638 / AS13270 / AS29610 | MG3031-RIPE > ----------------------------------------------------------------------- > ------------------ > > > > -----Urspr?ngliche Nachricht----- > > Von: address-policy-wg-admin at ripe.net > > [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von > > michael.dillon at bt.com > > Gesendet: Mittwoch, 5. Mai 2010 14:47 > > An: address-policy-wg at ripe.net > > Betreff: RE: [address-policy-wg] Discrepancy Between RIPE > > Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > > > > > > > - With IPv6 we would like to offer a client (collocation) at > > > least a /112 (with PI this isn't allowed if I'm correctly informed) > > > > This points out a material difference between IPv6 and IPv4. > > > > IPv6 is classful. Normally, ISPs get a /32 class allocation and > > give their customers /48 class assignments. Currently the PI policy > > comes from wanting to allow organizations to get a /48 class > > assignment from RIPE directly. But if the organization is involved > > in the hosting business, it is conceivable that customers will > > expect to receive a /48 class block from the data centre operator. > > > > Forget whether this is allowed or not because that is irrelevant. > > The point is that in the IPv6 world there is the expectation that > > no network will ever get less than a /64. In a data centre > environment > > one would expect that people renting a server or even a rack, would > > be satisfied with a /64. But people renting a room, or a row of > racks, > > might justifiably demand a /48 for their own internal subnetting and > > routing, even if much of it happens on virtual routers and switches. > > With the increasing number of cores per chip, even an organization > > renting a full rack might need more than a /64 because they need > > to have a network hierarchy within their rack. > > > > The problem is that /48 class blocks can't be stretched. In IPv4, > > there are no classes and everyone allocates according to strict needs > > now and in the very near future. But IPv6 has classes and allocates > > so that 99% of allocations can be permanent and never have to be > > expanded. > > > > We would not want organizations asking for a /40 PI allocation this > > year, then returning next year for another /40, and the year > > after that. > > > > The only way out that I can see is to treat a data centre like an ISP > > and offer organizations one /32 for each data centre that > > they operate. > > This would not apply to WAN operators since they can ask RIPE > > for a /30 > > or a /28 to cover all of their WAN and all data centres, then > allocate > > internally at whatever bit boundary is appropriate. > > > > One thing that RIPE should never accept is any plan that assigns less > > than > > /64 to a network. If such a plan is submitted, it should be > > returned and > > the applicant should be requested to expand any longer prefixes to a > > full > > /64, then resubmit. In other words, if you ask for too few addresses, > > RIPE > > should deny the request, because it is not in line with IPv6 > > architecture. > > > > > > --Michael Dillon > > > > From Marcus.Gerdon at versatel.de Thu May 6 11:51:13 2010 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Thu, 6 May 2010 11:51:13 +0200 Subject: AW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space Message-ID: <227142482560EF458FF1F7E784E26AB8025780BB@FLBVEXCH01.versatel.local> Richard, > A /64 in IPv6 is what a single address is for IPv4. I don't agree on this when talking about connecting servers. Place a server in a segment and assign it's interface an IPv4 address 192.168.0.1/24 and an IPv6 address FC00::1/64. Will you (be able to) address another server in the same segment using addresses within those prefixes? Can you get that server connected in IPv4 deploying 192.168.0.0/32 onto its interface? The relevant part here what I meant by 'single address' is the number of addresses configured onto those customers server. Indepent of doing v4 oder v6 you'll configured 'a single address' at the server to get it connected. I agree with you when talking i.e. about DSL lines. Instead of the typical /32 assigned for IPv4 you'll put a /64 on the line. But that's another topic talking about lines instead of servers. As said this were quickly noted items that came to my mind. For the last case of a /64 segment dedicated to one customer I'm not sure but might agree with you that as this would be the equivalent to the DSL line's example. As long as you don't route another /64 (or whatever size) onto customer equipment addressed in this segment. But it's definitely hard to tell where to draw the line. regards, Marcus ----------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Gesch?ftsf?hrer: Dr. Hai Cheng, Joachim Bellinghoven ----------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 / AS29610 | MG3031-RIPE ----------------------------------------------------------------------------------------- > -----Urspr?ngliche Nachricht----- > Von: Richard Hartmann [mailto:richih.mailinglist at gmail.com] > Gesendet: Donnerstag, 6. Mai 2010 10:50 > An: Marcus.Gerdon > Cc: address-policy-wg at ripe.net > Betreff: Re: [address-policy-wg] Discrepancy Between RIPE > Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > > On Thu, May 6, 2010 at 08:42, Marcus.Gerdon > wrote: > > > - single address for connecting a customers server > > ? ? ? ?=> PI > > - contained /64 (!) segment (i.e. dedicated vlan for a > customers rack) > > ? ? ? ?=> I think somewhat of a border case, but tend to *no* PI > > A /64 in IPv6 is what a single address is for IPv4. > This is obviously a _very_ reduced view for the sake of my > argument, but > I think doing this is valid, in this case. > > > Richard > From info at streamservice.nl Thu May 6 12:14:30 2010 From: info at streamservice.nl (Stream Service) Date: Thu, 6 May 2010 12:14:30 +0200 Subject: FW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space Message-ID: <0f6801caed04$eabf0600$c03d1200$@nl> -----Original Message----- From: Mark Scholten [mailto:mark at streamservice.nl] Sent: Thursday, May 06, 2010 11:21 AM To: 'Marcus.Gerdon'; 'address-policy-wg at ripe.net' Subject: RE: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Marcus.Gerdon > Sent: Thursday, May 06, 2010 8:43 AM > To: address-policy-wg at ripe.net > Subject: AW: [address-policy-wg] Discrepancy Between RIPE Policies on > IPv4 and IPv6 Provider Independent (PI) Address Space > > In the scenario described here I'd tend to think the colocation/housing > provider imho is going for ISP bussiness. > > Handing out chunks of address space to customers, which are supposedly > going to be single-homed, documenting them etc. sounds like LIR > business. Multi-homing these chunks independent of wether they are PI > or PA gets to the 'sub-allocation' topic - which isn't supposed to be > done using parts of a PI space *assigned* to another party. Who's going > to handle abuse and what ever else might come from the address usage? > > My opinion I'm led to by this scenario is that there's someone who > wants to circumvent the administrative tasks and save a few $$$ by > doing ISP/LIR bussiness within PI space. > > Accordingly I think the policy should be kept at (noted at a quick) > > - single address for connecting a customers server > => PI > - prefix routed onto customers server > => *no* PI - go for LIR > - prefix/range further distributed by customer himself > => *no* PI - go for LIR > - contained /64 (!) segment (i.e. dedicated vlan for a customers rack) > => I think somewhat of a border case, but tend to *no* PI > > Surely everyone wanting to can become a LIR, and everyone wanting to > hand out chunks of address space to other parties is able to request an > allocation, or did I miss something? > > @Mark: > >>PA IPv6 address space is currently not available for us > Why's that? Sorry for asking a possibly obvisous question, but going > over the PA policies now I'm simply to lazy. :) Becoming a LIR is from a business economics view not good for us and the network we use doesn't offer IPv6 PA, so the only option left without moving to another network is to use IPv6 PI. But if we are required to be a LIR we will also require more IPv4 IP space so we have enough for the future. Is it a target by preventing us to use IPv6 PI to use the last IPv4 IPs as fast as possible? We currently not even use a /22 IPv4 space, but when we need to become a LIR we will look for ways to get more IPv4 space. Regards, Mark > > I can remember that there's been a discussion quite some time ago where > someone stated he's not able/allowed the LIR contracts with RIPE due to > regulatory/legal issue or something like that. In case something like > this is the underlying reason why PI is used for ISP/LIR bussiness then > imho RIPE/NCC should look into solving this 'organizational' problem > directly instead of bending policies around making PI into PA lite. > > Just my 2c. > > regards, > > Marcus > > ----------------------------------------------------------------------- > ------------------ > Engineering IP Services > > Versatel West GmbH > Unterste-Wilms-Strasse 29 > D-44143 Dortmund > > Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 > marcus.gerdon at versatel.de | www.versatel.de > > Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 > Gesch?ftsf?hrer: Dr. Hai Cheng, Joachim Bellinghoven > ----------------------------------------------------------------------- > ------------------ > AS8881 / AS8638 / AS13270 / AS29610 | MG3031-RIPE > ----------------------------------------------------------------------- > ------------------ > > > > -----Urspr?ngliche Nachricht----- > > Von: address-policy-wg-admin at ripe.net > > [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von > > michael.dillon at bt.com > > Gesendet: Mittwoch, 5. Mai 2010 14:47 > > An: address-policy-wg at ripe.net > > Betreff: RE: [address-policy-wg] Discrepancy Between RIPE > > Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > > > > > > > - With IPv6 we would like to offer a client (collocation) at > > > least a /112 (with PI this isn't allowed if I'm correctly informed) > > > > This points out a material difference between IPv6 and IPv4. > > > > IPv6 is classful. Normally, ISPs get a /32 class allocation and > > give their customers /48 class assignments. Currently the PI policy > > comes from wanting to allow organizations to get a /48 class > > assignment from RIPE directly. But if the organization is involved > > in the hosting business, it is conceivable that customers will > > expect to receive a /48 class block from the data centre operator. > > > > Forget whether this is allowed or not because that is irrelevant. > > The point is that in the IPv6 world there is the expectation that > > no network will ever get less than a /64. In a data centre > environment > > one would expect that people renting a server or even a rack, would > > be satisfied with a /64. But people renting a room, or a row of > racks, > > might justifiably demand a /48 for their own internal subnetting and > > routing, even if much of it happens on virtual routers and switches. > > With the increasing number of cores per chip, even an organization > > renting a full rack might need more than a /64 because they need > > to have a network hierarchy within their rack. > > > > The problem is that /48 class blocks can't be stretched. In IPv4, > > there are no classes and everyone allocates according to strict needs > > now and in the very near future. But IPv6 has classes and allocates > > so that 99% of allocations can be permanent and never have to be > > expanded. > > > > We would not want organizations asking for a /40 PI allocation this > > year, then returning next year for another /40, and the year > > after that. > > > > The only way out that I can see is to treat a data centre like an ISP > > and offer organizations one /32 for each data centre that > > they operate. > > This would not apply to WAN operators since they can ask RIPE > > for a /30 > > or a /28 to cover all of their WAN and all data centres, then > allocate > > internally at whatever bit boundary is appropriate. > > > > One thing that RIPE should never accept is any plan that assigns less > > than > > /64 to a network. If such a plan is submitted, it should be > > returned and > > the applicant should be requested to expand any longer prefixes to a > > full > > /64, then resubmit. In other words, if you ask for too few addresses, > > RIPE > > should deny the request, because it is not in line with IPv6 > > architecture. > > > > > > --Michael Dillon > > > > From richih.mailinglist at gmail.com Thu May 6 13:54:53 2010 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 6 May 2010 13:54:53 +0200 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <227142482560EF458FF1F7E784E26AB8025780BB@FLBVEXCH01.versatel.local> References: <227142482560EF458FF1F7E784E26AB8025780BB@FLBVEXCH01.versatel.local> Message-ID: On Thu, May 6, 2010 at 11:51, Marcus.Gerdon wrote: > I don't agree on this when talking about connecting servers. As I said, I reduced the example extremely for the sake of argument. While there are many valid reasons why a single machine could have more than one IP (virtualization, SSL, etc) with both IPv4 and IPv6, IPv6 certainly makes using up IPs easier as there are so many. The be explicit: A customer with a single server who is assigned a /32 with IPv4 would and should still receive a full /64 with IPv6. Even when he really only needs one address, now or ever. This would not be allowed with PI space with the scheme you propose. I am not sure if it _should_ be allowed with PI space in the first place, but if it is, a full /64, not a /128, should be assigned. Richard From fw at deneb.enyo.de Thu May 6 15:32:13 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 06 May 2010 15:32:13 +0200 Subject: AW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <227142482560EF458FF1F7E784E26AB8025780BB@FLBVEXCH01.versatel.local> (Marcus Gerdon's message of "Thu, 6 May 2010 11:51:13 +0200") References: <227142482560EF458FF1F7E784E26AB8025780BB@FLBVEXCH01.versatel.local> Message-ID: <87y6fxxijm.fsf@mid.deneb.enyo.de> * Marcus Gerdon: > Richard, > >> A /64 in IPv6 is what a single address is for IPv4. > > I don't agree on this when talking about connecting servers. But it's arguably true if you want to separate those servers at the IP layer. Then you have to use separate subnets, and the IETF says that subnets have to be /64s (or larger). Some implementations even enforce that. From nick at inex.ie Thu May 6 16:46:01 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 06 May 2010 16:46:01 +0200 Subject: [address-policy-wg] RE: 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <7B640CC73C18D94F83479A1D0B9A140402AD3287@bhw-srv-dc1.imerja.com> References: <7B640CC73C18D94F83479A1D0B9A140402AD3287@bhw-srv-dc1.imerja.com> Message-ID: <4BE2D629.2020508@inex.ie> On 06/05/2010 00:32, Jamie Stallwood wrote: > Today's discussion was interesting and concern was raised about > commercials being able to get all or most of the address space set aside > in the proposal, and about unfair commercial advantage. My thoughts as a > paragraph, which I know is rushed and woolly and only intended as a > discussion point: > > 3.5 Use by Commercial Organizations > Temporary address space will not be assigned by the RIPE NCC to any > commercial organization where such an allocation: > * Is not shown to be for a research, development or testing project > relevant to an operational business of that organization > * Does not seek to provide a "benefit", e.g. through published work in > academic or industrial journals, or > * Is unable to demonstrate a fair inclusion policy for other commercial > organizations to contribute to, or benefit from, the project. The original point about unfair advantage was purely that any organisation (whether commercial or not) could hog all the address space in a temporary assignment pool managed by the NCC, and that this would discriminate against all other potential end users. In the case of commercial end users, this discrimination could be interpreted as a commercial advantage / disadvantage situation. Can you explain why you're suggesting that commercial end users be discriminated against in any future temporary assignment policy? Nick From Jamie.Stallwood at imerja.com Thu May 6 17:06:47 2010 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Thu, 6 May 2010 16:06:47 +0100 Subject: [address-policy-wg] RE: 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) References: <7B640CC73C18D94F83479A1D0B9A140402AD3287@bhw-srv-dc1.imerja.com> <4BE2D629.2020508@inex.ie> Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD3288@bhw-srv-dc1.imerja.com> Hi Nick and all, You could well be right that "unfairness" could be exhibited by non-commercial organizations, in which case maybe removing the word "commercial" from the argument would be a good thing. Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood at imerja.com -----Original Message----- From: Nick Hilliard [mailto:nick at inex.ie] Sent: Thu 5/6/2010 15:46 To: Jamie Stallwood Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] RE: 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) On 06/05/2010 00:32, Jamie Stallwood wrote: > Today's discussion was interesting and concern was raised about > commercials being able to get all or most of the address space set aside > in the proposal, and about unfair commercial advantage. My thoughts as a > paragraph, which I know is rushed and woolly and only intended as a > discussion point: > > 3.5 Use by Commercial Organizations > Temporary address space will not be assigned by the RIPE NCC to any > commercial organization where such an allocation: > * Is not shown to be for a research, development or testing project > relevant to an operational business of that organization > * Does not seek to provide a "benefit", e.g. through published work in > academic or industrial journals, or > * Is unable to demonstrate a fair inclusion policy for other commercial > organizations to contribute to, or benefit from, the project. The original point about unfair advantage was purely that any organisation (whether commercial or not) could hog all the address space in a temporary assignment pool managed by the NCC, and that this would discriminate against all other potential end users. In the case of commercial end users, this discrimination could be interpreted as a commercial advantage / disadvantage situation. Can you explain why you're suggesting that commercial end users be discriminated against in any future temporary assignment policy? Nick -- 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 jim at rfc1035.com Thu May 6 17:20:32 2010 From: jim at rfc1035.com (Jim Reid) Date: Thu, 6 May 2010 16:20:32 +0100 Subject: [address-policy-wg] definitions for 2010-01 In-Reply-To: <4BE2D629.2020508@inex.ie> References: <7B640CC73C18D94F83479A1D0B9A140402AD3287@bhw-srv-dc1.imerja.com> <4BE2D629.2020508@inex.ie> Message-ID: <6CC8F4EF-FB4E-434A-A901-6E90D341EB8C@rfc1035.com> On 6 May 2010, at 15:46, Nick Hilliard wrote: > Can you explain why you're suggesting that commercial end users be > discriminated against in any future temporary assignment policy? A workable definition of "commercial end user" would be nice too. If such a thing exists. From nick at inex.ie Thu May 6 17:32:45 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 06 May 2010 17:32:45 +0200 Subject: [address-policy-wg] definitions for 2010-01 In-Reply-To: <6CC8F4EF-FB4E-434A-A901-6E90D341EB8C@rfc1035.com> References: <7B640CC73C18D94F83479A1D0B9A140402AD3287@bhw-srv-dc1.imerja.com> <4BE2D629.2020508@inex.ie> <6CC8F4EF-FB4E-434A-A901-6E90D341EB8C@rfc1035.com> Message-ID: <4BE2E11D.6020306@inex.ie> On 06/05/2010 17:20, Jim Reid wrote: > A workable definition of "commercial end user" would be nice too. If > such a thing exists. Jim, We should probably start with an agreed working definition of "End User". You shoot first. Nick From michael.dillon at bt.com Thu May 6 17:54:55 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 6 May 2010 16:54:55 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <227142482560EF458FF1F7E784E26AB8025780BB@FLBVEXCH01.versatel.local> Message-ID: <28E139F46D45AF49A31950F88C49745805FE3981@E03MVZ2-UKDY.domain1.systemhost.net> > > A /64 in IPv6 is what a single address is for IPv4. > > I don't agree on this when talking about connecting servers. What is a server? It is not unusual to see a 1U rackmount device called a "server" in hosting data centres. These server things have 4 CPU chips each with 4 cores, and 64G of RAM. Each of the 16 cores can run at least 3 average virtual machines giving you 48 vms in the device, and it is common enough to see people running as many as 7 or 8 VMs per core so you could easily have 112 VMs. In addition to the 112 virtual servers, each needing a /128 for every one of their virtual network interfaces, it is common to find people implementing virtual networks with virtual routers and switches, including a virtual DMZ/firewall setup. Clearly it is not unusual to find a so-called server device that actually does require more than a /64 allocation in order to remain aligned with IPv6 architecture and not start subnetting /64 blocks. --Michael Dillon From andrea at ripe.net Tue May 11 11:45:56 2010 From: andrea at ripe.net (Andrea Cima) Date: Tue, 11 May 2010 11:45:56 +0200 Subject: [address-policy-wg] New IPv4 blocks allocated to RIPE NCC Message-ID: <4BE92754.7070902@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 31/8 and 176/8 from the IANA in May 2010. We will begin allocating from these ranges in the near future. The minimum allocation size for these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: Additionally, please note that three "pilot" prefixes will be announced from each /8. The prefixes are: 31.0.0.0/16 31.1.0.0/21 31.1.24.0/24 176.0.0.0/16 176.1.0.0/21 176.1.24.0/24 They all originate in AS12654. More information on this "pilot" activity is available in the draft document "De-Bogonising New Address Blocks" which can be found at: Kind regards, Andrea Cima Registration Services Manager RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvpJ1QACgkQXOgsmPkFrjMChQCgxw7pxH6OgI0nQuwdhdOIWRp7 ig4An0QaM80yGTPN603EvW7dXkrUNQ/g =4M3X -----END PGP SIGNATURE----- From andy at nosignal.org Tue May 11 15:06:59 2010 From: andy at nosignal.org (Andy Davidson) Date: Tue, 11 May 2010 14:06:59 +0100 Subject: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space In-Reply-To: <4BE0362C.1070908@schiefner.de> References: <3CC4ADEE-FCCA-4D1B-B3AF-24C43221A56F@steffann.nl> <223EF1F9-447A-433F-B74C-6E343F4FFC6D@steffann.nl> <4BE0362C.1070908@schiefner.de> Message-ID: On 4 May 2010, at 15:58, Carsten Schiefner wrote: > Oh, and yes: I am in favour of a v4/v6 harmonisation, too. Hi, If we are collecting community feelings on this topic, I think that the policies should be identical in spirit -- EXCEPT we should pay special attention not to repeat some of our, err, learning experiences in v4 (the swamp, exhaustion, legacy assignments, mass deaggregation, ....) Best wishes Andy