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

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

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" <http://en.wikipedia.org/wiki/For_Want_of_a_Nail_%28proverb%29> 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

On Tue, May 4, 2010 at 16:58, Carsten Schiefner <ripe-wgs.cs@schiefner.de> 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

On Tue, May 4, 2010 at 17:22, Gert Doering <gert@space.net> 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

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@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@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 <gert@space.net> 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

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@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@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

- 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

On Tue, May 4, 2010 at 17:43, Gert Doering <gert@space.net> 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

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

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". <wg chair hat off> 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

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

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@ripe.net] On Behalf Of Gert Doering Sent: Tuesday, May 04, 2010 10:07 PM To: address-policy-wg@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

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@imerja.com -----Original Message----- From: address-policy-wg-admin@ripe.net on behalf of michael.dillon@bt.com Sent: Wed 5/5/2010 15:00 To: address-policy-wg@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.

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