On 30 Mar 2011, at 10:43, Pierre-Yves Maunier wrote:

On Wed, Mar 30, 2011 at 10:25:27AM +0200, Jan Tuomi wrote:

...

So what should I do? What are my options?

// Janne

If you wand multihomed IPv6 and assign blocks to your customers, become a LIR and get a /32.

.... I helped some of them to become LIR, they got their /21 PA IPv4 and their /32 PA IPv6.

this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation). Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot"). If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both. Would it be time to revisit the coherency of this whole thing as a whole? Joao

Hi, On Wed, Mar 30, 2011 at 11:08:06AM +0200, Joao Damas wrote:

this is really strange and weird. I have always thought that RIPE policies aimed at good address stewardship (so far this has been linked to conservation, under IPv4) and some consideration to route table size contention (promote aggregation).

Conservation is not one of the primary goals for IPv6. Routing table size (=aggregation) *is* - which is why the consensus of this group, some years ago, was "be restrictive on PI". Now, this particular problem ("datacenter business") has been showing up a few times in the last 1.5 years, and in the end, it boils down to a number of considerations that are NOT easily solved. - the distinction between PA and PI is, conceptually, "PA is for ISPs that want to number (their) customers" "PI is for customers that want to number their own(!) network in an independent way" --> and this is why the chunk size is much bigger for PA, because it's meant to give an ISP a chunk that is so large that they will not need to come back for more space in the near future (-> which is good for routing aggregation), even taking lots of customers with a /48-each into account. PI is a /48, because "that's enough for one customer". - PI has been positioned as "cheap", so it's not a major hurdle for small "non-isp" companies that want/need independent address space - PA is "expensive", because it's only given to LIRs, and all the LIRs around share the expense of having the RIPE NCC do their job --> so, if a large number of ISPs change to run their IPv6 business on PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* (the NCC's expenses pretty much stay the same, and get distributed to less paying members). So from a fairness point of view, there's good reason to ask everybody who is running an ISP-like business to become a LIR, and pay their share, staggered by "ISP size". - there's another twist to it: we want to encourage access providers (DSL, cable, ...) to give their customers a /56 or /48 - which the current PA policy permits just fine. Now if they could get a PI block to number their 5 million DSL users, these customers would end up with single-IPv6-assignments and IPv6 NAT... (We see this in IPv4 today, access ISPs that run all of their DSL network on PI space, as the IPv4 policy has a clause that permits doing so [transit networks to the customer are considered "part of the PI", and if all you give the customer is a single IP for their router...]) ... so, given this, "just open PI space and give everbody who asks their /48" is not without risks and costs - talking about good stewardship, and such :-)

Responses like this over the last weeks seem to indicate that RIPE NCC's business practices seem to taking over as a more important consideration ("you can't get a /48 if that's all you need and it makes sense, but if you pay the RIPE NCC you can get a /32 and some scarce IPv4 bundled in to boot").

You don't get the IPv4 space unless you demonstrate need. It's not like the IPv4 PA allocation is automatic.

If I were a regulator not intimately involved in RIPE's doings, I sure would be raising an eyebrow, or both.

Well - the PI policies are *exactly* what the community(!) made them...

Would it be time to revisit the coherency of this whole thing as a whole?

Definitely. There's a "change the PI policy" proposal coming up, and Sander and I are trying to come up with good ideas to get the whole complex better "balanced out". Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi, On Wed, Mar 30, 2011 at 12:21:54PM +0200, Jan Tuomi wrote:

...

Conservation is not one of the primary goals for IPv6.

Routing table size (=aggregation) *is* - which is why the consensus of this group, some years ago, was "be restrictive on PI".

What is the difference in allocating one /48 PI-block or one /32 PA-block from a routing table size view? there still is one route in both cases because I need multihoming....

Sure, and the PI policy requires "multihoming" for that reason - to permit PI for the cases that were clearly understood at that time: if someone wants/needs to do BGP-based multihoming, they will consume a routing table slot anyway. Now *this* discussion didn't start with "the multihoming requirement" but with "what can I use PI for" - which is a different restriction, and I tried to explain that these are interconnected and it is not that easy to untangle things in a way that the end result is better than what we have now.

...

Now, this particular problem ("datacenter business") has been showing up a few times in the last 1.5 years, and in the end, it boils down to a number of considerations that are NOT easily solved.

- the distinction between PA and PI is, conceptually,

"PA is for ISPs that want to number (their) customers"

"PI is for customers that want to number their own(!) network in an independent way"

Should I consider myself as an ISP? I am not selling internet access to my customers locations, the customers is running their servers in my facility, in my rack, on my switches, firewalls and routers, they dont have physical access without me or someone from my staff being present. From my point of view, it is MY OWN network, not theirs.

Sounds like you're providing "Internet Services" to your customers - you make sure that their web presence can be reached from "the Internet". As I have tried to explain - this is where the distinction PA/PI came from, and indeed, you seem to match a loose definition of "ISP" quite well - an ISP isn't only "runs DSL lines to folks". We know that datacenter is problematic, as the boundaries between "this is MY NETWORK and MY SERVERS" and "this is MY NETWORK and THEIR servers" and "this is MY NETWORK connecting to THEIR firewall, and THEIR network behind the firewall" is floating.

...

- PI has been positioned as "cheap", so it's not a major hurdle for small "non-isp" companies that want/need independent address space

- PA is "expensive", because it's only given to LIRs, and all the LIRs around share the expense of having the RIPE NCC do their job

--> so, if a large number of ISPs change to run their IPv6 business on PI space, and stop paying LIR fees, all *other* LIRs have to pay *more* (the NCC's expenses pretty much stay the same, and get distributed to less paying members). So from a fairness point of view, there's good reason to ask everybody who is running an ISP-like business to become a LIR, and pay their share, staggered by "ISP size".

But the price is the same... EXTRA SMALL, LIR: Sign-up Fee (? 2000) + Service Fee (? 1,300) EXTRA SMALL, Direct Assignment User: Administration Fee (? 2000) + Service Fee (? 1,300)

PI costs 50 EUR/year per assignment if you go through a sponsoring LIR (which is the recommended way of doing it) in RIPE fees, plus some extra that the sponsoring LIR is usually adding as a handling fee. If you intend on becoming a Direct Assignment User, go for "LIR", and stop worrying on PA vs. PI and sub-assignments.

Is it about that? Did I make the wrong choice in not becoming a DUA directly against RIPE?

Well, if you're a hosting provider, and the question is "DUA or LIR", go for LIR. If the question is "PI via a local LIR" vs. "become a LIR yourself", there's a larger monetary difference, and some argue that this is too expensive and will drive them out of business. We *are* listening to that, but have no easy answer yet. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

W dniu 2011-03-30 10:58, Tero Toikkanen pisze:

Hi,

As far as I’m concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I’m having a hard time finding such terms.

http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider Most important is the last sentence: The PI assignment cannot be further assigned to other organisations. And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. Regards -- Adrian

...

And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.

With that interpretation, isn't it impossible to use IPv6 PI space to provide addresses to personal computers?

But seriously---does the working group think that IPv6 PI space should not be used for hosting customer web sites, and that the current policy does not allow this?

http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space "PI space cannot be re-assigned or further assigned to other parties." The text is the same for IPv4 PI and IPv6 PI, but you still can't get both for the same use. Why not? In my opinion the policy is the same for both, but it seems it's not interpreted in the same way. ____________________________________ Tero Toikkanen Nebula Oy

Hi, On Wed, Mar 30, 2011 at 09:17:31AM +0000, Tero Toikkanen wrote:

http://www.ripe.net/ripe/docs/ripe-509#----pa-vs--pi-address-space

"PI space cannot be re-assigned or further assigned to other parties."

The text is the same for IPv4 PI and IPv6 PI, but you still can't get both for the same use. Why not? In my opinion the policy is the same for both, but it seems it's not interpreted in the same way.

Actually, there's a significant difference and that has been pointed out a number of times on the list and at the last RIPE meetings. The IPv4 policy has this sentence: http://www.ripe.net/ripe/docs/ripe-509#----network-infrastructure-and-end-us... 6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. ... and this specific clause is not in the IPv6 policy, so "networks used to number end customers" are considered "part of the assignment to this end customer". (Which makes sense for DSL and cable etc. networks, where you really want to assign a /56 or /48 anyway, and not start tricking around with single-address-assignment from PI blocks) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi, On Wed, Mar 30, 2011 at 10:28:19AM +0000, Tero Toikkanen wrote:

Also, policy interpretation within RIPE NCC should be sorted out (unless it already is), as I distinctly remember getting IPv6 PI for a customer for hosting purposes a year ago.

Nothing wrong with "I run my own datacenter and host my own servers there, and want to number them with my own IPv6 PI space". The bit where you provide services "to other parties" is where things get problematic, when the policy has a "no sub-allocations / sub-assignments to 3rd parties" clause. (No need to enumerate the large amount of different possible ways to run "a hosting business" here) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi Jan, If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don't provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP's, that is acceptable for PI is my experience with the IPRA's. If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn't multi-homed (I assume) and that is (still) another requirement for IPv6 PI. I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. Regards, Erik Bais From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? On 30 mar 2011, at 11.08, Adrian Czapek wrote:

W dniu 2011-03-30 10:58, Tero Toikkanen pisze:

...

Hi,

As far as I'm concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time finding such terms.

http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider

Most important is the last sentence: The PI assignment cannot be further assigned to other organisations.

And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.

Regards -- Adrian

So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11

Hi Jan, I come across customers who want to get into IPv6 and have their own IP addresses. However they don't want to multi-home (yet), they want to have the flexibility to change providers if needed without having to re-number their complete infrastructure / vpn devices / dns servers etc etc The only way for those customers to help them currently is to tell them to: A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR's who are not multi-homed or just have some other company run their IP space under another AS. B: Request PI IPv6, invest in multi-homing equipment and knowledge, connect to a competitor and proceed. As LIR's don't have the requirement to multihome their IP space, means that the community is in agreement that this PI IPv6 space required a hurdle in order to stop a wild-growth on the IPv6 routing table growth, however if someone pays their way into the community (become a LIR), nobody cares anymore about the routing table growth and we gladly take your money and proceed. Having said that, this is a financial decision and not a technical routing table growth mediation rule. And it should be treated as such. The proposal change I've done is to remove the multi-homing requirement, and ask the GM meeting to increase the cost for PI IPv6 from 50 euro to 250 euro to keep all things equal. That would still allow customers who want their own PI IPv6 to be able to request it for their own infrastructure, without having them to force them into my competitors arms or having them to shell-out 3300 euro to become a LIR, if they don't want to become a LIR for their specific reasons. There is no difference for those kind of customers in the routing table if you would receive a /32 (new LIR) or a /48 (new PI IPv6 without multi-homing). On the part of colocation services as what you are doing / describing (your customer financially OWNS their servers), that is against the intention of PI (both IPv4 and IPv6) space. And as such your request got denied is my guess. Regards, Erik Bais From: Jan Tuomi [mailto:tuomi@ventiro.se] Sent: Wednesday, March 30, 2011 1:02 PM To: Erik Bais Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? Hi Erik, Why remove the multi-homing requirement? if you are not multihomed you could go with the PA-space you get from your single upstream provider? My problem is that I actually am multi-homed, therefor I need IPv6-PI.... And if my customers have their servers in my facility they also are multihomed? So they could request for their own PI? that really doesnt make sensee, that would really clog down the routing tables.... The hosting network is today set up so each customer get their own IPv4 /29 of Private addresses, then I NAT a public IP on a first come-first served basis. The reason they have an own IPv4 Net on the inside is to gain some security between servers in the facility... With IPv6 I obviously dont want to use NAT, so I will set up a small IPv6 Network for each server, just as i do with IPv4, but without the NAT-part.. So instead of setting up a singe IP to the server I set up a network, but basically its the same... so the change request about removing multi-homing requirement doesnt make sense in my case.... I think the requirement is a good thing because i dont see ANy reason to get PI-space if you are not multihomed. // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 On 30 mar 2011, at 12.32, Erik Bais wrote: Hi Jan, If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don't provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP's, that is acceptable for PI is my experience with the IPRA's. If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn't multi-homed (I assume) and that is (still) another requirement for IPv6 PI. I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. Regards, Erik Bais From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why? On 30 mar 2011, at 11.08, Adrian Czapek wrote:

W dniu 2011-03-30 10:58, Tero Toikkanen pisze:

...

Hi,

As far as I'm concerned, there seems to be a strange discrepancy between IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained IPv4 PI and has now requested IPv6 PI, declaring the same intended use. Could someone please point out where in the policy documents it says one can use IPv4 PI for hosting, but not IPv6 PI? I'm having a hard time finding such terms.

http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider

Most important is the last sentence: The PI assignment cannot be further assigned to other organisations.

And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose.

Regards -- Adrian

So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 _____ No virus found in this message. Checked by AVG - www.avg.com <http://www.avg.com/> Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11

Hi,

A: become a LIR, pay 3300 euro sign-up and yearly cost for the first year. And nobody will ask if you are going to multi-home or not. There are plenty of LIR’s who are not multi-homed or just have some other company run their IP space under another AS.

They do have to provide IPv6 services to other organizations though: "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years." - Sander

Hi Leo,

...

They do have to provide IPv6 services to other organizations though: "... have a plan for making sub-allocations to other organisations and/or End Site assignments within two years."

A plan isn a plan and not a commitment, though.

No-one's going to take the LIR's space away if they miss the target. On that basis, we know that this requirements is purely a form of words and has no real value.

I don't agree with you here. If you run a grocery store (or other non ISP business) it might be hard to show believable plan for making sub-allocations or assignments... And there is no target anymore, so there is nothing to miss ;-) - Sander

Hi, On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote:

So what this means is that if a customer puts their server in my facility I am sub-allocating?

Yes.

To sub-allocate I have to be an LIR and request an own PA-space?

Yes. As the definition of PI is "this is for you, and for you alone". (See the other long mail I've sent why this is not such a trivial matter)

For each customer I have to assign their own /64 and register it in the ripe-database?

You have to document it in a way that you can show the documentation to the RIPE IPRAs, but it does not have to be in the RIPE-DB (for IPv6). Whether you assign a /64 or a /60 (think "customer with a firewall and a load balancer and a backend network for the database") is a matter of local taste. If you run multiple customers in a shared network, you can of course give every customer just a single IPv6 address (not going into technicalities on cross-customer protection here).

Setting up an SSL-webhost is also sub-allocating?

This is very grey area. Technically, it's "giving an address to a 3rd party", but personally I'd see this is as "it's still the same machine under *your* control". But we already know that datacenter has all the range from "very obviously *not* sub-allocation" to "very obviously this *is* sub-allocation", and as such, distinction between "what is OK" and "what is not" is tricky at best. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi, On Wed, Mar 30, 2011 at 7:14 AM, Gert Doering <gert@space.net> wrote:

On Wed, Mar 30, 2011 at 11:54:55AM +0200, Jan Tuomi wrote:

...

Setting up an SSL-webhost is also sub-allocating?

This is very grey area.  Technically, it's "giving an address to a 3rd party", but personally I'd see this is as "it's still the same machine under *your* control".

Right. I want to take this further by revisiting some core networking principles with a touch of v6: Control of usage of addresses, even in times of /64 v6 SLAAC-enabled LANs, remains with the party that switches and routes them, normally but not necessarily, to and on the Internet. This is the reality. Consider this for a while. APWG is fooling itself in thinking that it can control what addresses anyone configures on a host. Influence (in only a small way), yes. Control, no. The core registry function of RIPE *is* to facilitate Internetworking by avoiding addressing collisions. Put different, RIPE concerns itself primarily with assisting in organizing addressing, allowing networks to communicate, *not* specific hosts. The networks concern themselves with making hosts communicate. A host can have any address configured, free of consequence, until it is connected to a network. Much of the pain from APWGs policies comes, IMO, from the distance of the disconnect a policy has with reality. The further the disconnect, the greater the resulting pain and lies. Close the gap, reduce the pain and lies. PIv6 has a very big disconnect with reality right now IMO, which lately has become very evident. Tieing the "user" of addresses (in RIR sense) closer to the party that routes and switches them(*), ie the network, and away from the ones who configures them on a host stack, is 100% in line with RIPE's role as a registry. In IPv6 with SLAAC, this is particularly true. * For administrative reasons, it becomes at some point very burdensome to track usage (in RIR sense) at the RIR level of individual end-users (ie, home users) which is why a lower threshold of "allocations" in IPv4 of /30 was established long time ago. I believe the equivalent value in IPv6 is /48, which in itself probably is subject to considerations w.r.t BCP157 now. Conceptually, each organizational level in the addressing hierarchy should (for abuse- and law-enforcement purposes, I suppose..) be able to provide a pointer, a next-hop to the next entity in charge of something. In theory, RIPE's only pointer to resources delegated to a LIR could be to the LIR itself (who of course is free to keep its record in a public database such as RIPE's).

But we already know that datacenter has all the range from "very obviously *not* sub-allocation" to "very obviously this *is* sub-allocation", and as such, distinction between "what is OK" and "what is not" is tricky at best.

So let's substitute it for something that is clear, logical and consequential. :) Regards, Martin

Adrian, see the RIPE-510 document. You probably will have a connectivity problem. Wednesday, March 30, 2011, 10:59:58 AM, you wrote:

...

So what should I do? What are my options? AC> Best option: take /48 from your LIR and deaggregate it (announce to the AC> world under your ASN)

-- Sergey