Hello, At the risk of sounding naïve, I have a question regarding the legitimate usage of PA address space. That is, what *type* of network or End User can it be assigned to. "LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7 To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation. Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR? Regards, James
On 07/07/2015 13:31, Kennedy, James wrote:
At the risk of sounding naïve, I have a question regarding the legitimate usage of PA address space. That is, what *type* of network or End User can it be assigned to.
"LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7
To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation.
Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR?
From an end user point of view, it's a pretty damned stupid thing to do because if the end user terminates their business relationship with LIR1,
There are two separate things going on here. 1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was accepted. 2. if an end user receives a PA block from LIR1 and then attempts to route it out through a different network who operates LIR2, that's an issue for the end user, LIR1 and LIR2 to resolve. The RIPE NCC is not the routing police and has no policy basis to intervene. Situation #2 is relatively common and becoming more so. then they terminate any rights to use the address space they received from LIR1. This puts the them in the situation where their business continuity depends on a contractual relationship with a single supplier. Not clever.
From the point of view of LIR1, some LIRs run with this as a business model in order to prevent customers moving away.
From the point of view of LIR2, this often ends up causing problems between them, the end user and LIR1.
Nick
I thing he understand "end user" as a residential customer user. But a residential customer user is not recieving the PA space, is the ISP of the customer who recieve it. LIR is not ISP. You can be a LIR and not an ISP and vice versa. El 07/07/2015 a las 14:55, Nick Hilliard escribió:
On 07/07/2015 13:31, Kennedy, James wrote:
At the risk of sounding naïve, I have a question regarding the legitimate usage of PA address space. That is, what *type* of network or End User can it be assigned to.
"LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7
To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation.
Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR?
There are two separate things going on here.
1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was accepted.
2. if an end user receives a PA block from LIR1 and then attempts to route it out through a different network who operates LIR2, that's an issue for the end user, LIR1 and LIR2 to resolve. The RIPE NCC is not the routing police and has no policy basis to intervene.
Situation #2 is relatively common and becoming more so.
From an end user point of view, it's a pretty damned stupid thing to do because if the end user terminates their business relationship with LIR1, then they terminate any rights to use the address space they received from LIR1. This puts the them in the situation where their business continuity depends on a contractual relationship with a single supplier. Not clever.
From the point of view of LIR1, some LIRs run with this as a business model in order to prevent customers moving away.
From the point of view of LIR2, this often ends up causing problems between them, the end user and LIR1.
Nick
Hi Nick, El 07/07/2015 a las 14:55, Nick Hilliard escribió:
1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was accepted.
Well, the policy specifically states PA is to be sub-allocated or assigned to *downstream networks* of the LIR. https://www.ripe.net/publications/docs/ripe-643#7 Doesn't this mean transit via the allocation holding LIR's network is a requirement? PI (though no longer distributed) space was/is for LIR independent routing, not PA.
From the point of view of LIR1, some LIRs run with this as a business model in order to prevent customers moving away. Not only to prevent customers moving away, but also to attain mountains of IPv4 PA allocations from the NCC (albeit before RIPE depletion) that are autonomous to the LIR's network - if the LIR even has a network!
Daniel, Not talking about residential end users. Focusing on LIRs that assigns a PA block to a company from their allocation, but doesn't actually provide any service to that company. Is this breaking the aforementioned policy statement? Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Daniel Baeza (Red y Sistemas TVT) Sent: 07 July 2015 14:59 To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PA policy I thing he understand "end user" as a residential customer user. But a residential customer user is not recieving the PA space, is the ISP of the customer who recieve it. LIR is not ISP. You can be a LIR and not an ISP and vice versa. El 07/07/2015 a las 14:55, Nick Hilliard escribió:
On 07/07/2015 13:31, Kennedy, James wrote:
At the risk of sounding naïve, I have a question regarding the legitimate usage of PA address space. That is, what *type* of network or End User can it be assigned to.
"LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7
To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation.
Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR?
There are two separate things going on here.
1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was accepted.
2. if an end user receives a PA block from LIR1 and then attempts to route it out through a different network who operates LIR2, that's an issue for the end user, LIR1 and LIR2 to resolve. The RIPE NCC is not the routing police and has no policy basis to intervene.
Situation #2 is relatively common and becoming more so.
From an end user point of view, it's a pretty damned stupid thing to do because if the end user terminates their business relationship with LIR1, then they terminate any rights to use the address space they received from LIR1. This puts the them in the situation where their business continuity depends on a contractual relationship with a single supplier. Not clever.
From the point of view of LIR1, some LIRs run with this as a business model in order to prevent customers moving away.
From the point of view of LIR2, this often ends up causing problems between them, the end user and LIR1.
Nick
Just for the benefit of those having come to the Internet Scene a tad later than I did ;-) and having the facts written down: On 2015-07-07 14:59, Daniel Baeza (Red y Sistemas TVT) wrote: [...]
But a residential customer user is not recieving the PA space, [it] is the ISP of the customer who recieve it.
Even that is not necessarily true: a residential customer can have a (small?) network and receive an assignment from the ISP's PA block. Incidentally, I am one of those examples :-) FWIW, Wilfried
Hi Wilfried, I think your case is not usual, as a residential customer usually recieve only 1 IP address (By DHCP or Static) but not a prefix. Of course, Im always talking about IPv4. IPv6 is another thing. How you recieve the prefix? BGP, OSPF, Static Route...?? Im just curious. Regards, El 08/07/2015 a las 12:00, Wilfried Woeber escribió:
Just for the benefit of those having come to the Internet Scene a tad later than I did ;-) and having the facts written down:
On 2015-07-07 14:59, Daniel Baeza (Red y Sistemas TVT) wrote: [...]
But a residential customer user is not recieving the PA space, [it] is the ISP of the customer who recieve it.
Even that is not necessarily true: a residential customer can have a (small?) network and receive an assignment from the ISP's PA block.
Incidentally, I am one of those examples :-)
FWIW, Wilfried
Hi Daniel! On 2015-07-08 12:07, Daniel Baeza (Red y Sistemas TVT) wrote:
Hi Wilfried,
I think your case is not usual, as a residential customer usually recieve only 1 IP address (By DHCP or Static) but not a prefix.
Sure, the majority of "residential customers" (definition?) receive just 1 v4 address (and have to live with the mess of NAT), and sometimes even different ones when they disconnect/reconnect. But there are quite a few products out there, offered by ISPs which do understand and respect the needs of customers for more than 1 IPv4 address (and ask for more money ;-) )
Of course, Im always talking about IPv4.
Same here :-)
IPv6 is another thing.
Yes...
How you recieve the prefix? BGP, OSPF, Static Route...?? Im just curious.
Statically configured in my CPE and aggregated by ISP. DHCP internally by CPE (a small router, owned and managed by the ISP) Wilfried
Regards,
El 08/07/2015 a las 12:00, Wilfried Woeber escribió:
Just for the benefit of those having come to the Internet Scene a tad later than I did ;-) and having the facts written down:
On 2015-07-07 14:59, Daniel Baeza (Red y Sistemas TVT) wrote: [...]
But a residential customer user is not recieving the PA space, [it] is the ISP of the customer who recieve it.
Even that is not necessarily true: a residential customer can have a (small?) network and receive an assignment from the ISP's PA block.
Incidentally, I am one of those examples :-)
FWIW, Wilfried
Hi James, * Kennedy, James
"LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7
To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation.
I understand "downstream" to refer to the hierarchical internet number registry system here, not BGP routing topology. Otherwise, we'd all have to buy our IP-transit from the RIPE NCC, who'd in turn have to buy it from the IANA....
Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR?
That's how the policy has been implemented so far, yes. Note that the RIPE database gladly allow ASSIGNED PA inet(6)nums to get their own completely independent route(6) objects. Tore
Hi Tore, True. If indeed the "downstream" in this policy statement is in relation to the hierarchical registry system rather than in BGP transit terms, then yes PA customer assignments that are routed separately to the LIR are valid. I raised the question as I've heard several community members complain, validly IMO, about some LIRs that have accumulated vast v4 PA allocations that are technically autonomous to the LIR. Seems strange to have been allowed, especially considering the market value on these resources now. James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Tore Anderson Sent: 07 July 2015 16:41 To: Kennedy, James Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PA policy Hi James, * Kennedy, James
"LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7
To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation.
I understand "downstream" to refer to the hierarchical internet number registry system here, not BGP routing topology. Otherwise, we'd all have to buy our IP-transit from the RIPE NCC, who'd in turn have to buy it from the IANA....
Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR?
That's how the policy has been implemented so far, yes. Note that the RIPE database gladly allow ASSIGNED PA inet(6)nums to get their own completely independent route(6) objects. Tore
On Tue, Jul 07, 2015 at 04:17:23PM +0000, Kennedy, James wrote:
True. If indeed the "downstream" in this policy statement is in relation to the hierarchical registry system rather than in BGP transit terms, then yes PA customer assignments that are routed separately to the LIR are valid.
Actually, even assignments which are *not at all* connected to the Internet are valid. In practice, the vast majority of assignments will be downstream of the assigning LIR due to the routing issues mentioned earlier in the thread.
I raised the question as I've heard several community members complain, validly IMO, about some LIRs that have accumulated vast v4 PA allocations that are technically autonomous to the LIR. Seems strange to have been allowed, especially considering the market value on these resources now.
It is allowed because the intention of the policy was never to impose a hierarchy on the structure of the Internet, merely to have a distributed registry, rather than one huge juggernaut. And yeah, the phrasing is sufficiently ambiguous for this to have come up on the list before... rgds, Sascha Luck
* Kennedy, James
I raised the question as I've heard several community members complain, validly IMO, about some LIRs that have accumulated vast v4 PA allocations that are technically autonomous to the LIR. Seems strange to have been allowed, especially considering the market value on these resources now.
Consider the following use case: A government (national, regional, local - doesn't matter) sets up an LIR in order to provide addresses to its various branches, offices, schools, whatever. The goverment doesn't run an ISP of their own (they probably used to run a telco at some point, but that was privatised), so the LIR does not provide any connectivity to anyone - so that's up to the branches, offices, schools to put out public tenders for and obtain from a local or national ISP. The reason for having the government LIR in the first place, is to prevent the use of ISP-owned addresses and the lock-in effect that results in (on the local level, the techies might not be knowledgeable enough to avoid that from the beginning, and certainly asking every school to run their own LIR would be a non-starter). Finally, having the entire government in one (or a few) nicely aggregated block gives significant technical benefits. The government LIR might also charge a fee to its downstream clients, just to aid a little with garbage collection and ensure the LIR hostmaster(s) get paid. Or mentally replace "government" with some kind of large and distributed enterprise or group of companies. The umbrella corporation could provide LIR services to a number of sub-companies. That's a valid use-case we'd like to make sure is allowed, agreed? And it has been been allowed since before I got involved in this WG at least. However, if you look at it, it's not very easy to distinguish between my example government LIR and the "IP leasing LIR" you think it's strange that has been allowed. Technically, they're doing exactly the same thing. So both are allowed. Anyway. The vultures will fight over IPv4's carcass. That's natural, and unavoidable - just let them. I for one am glad that this community hasn't succumbed to the temptation to create more and more draconian and restrictive policies, all in the name of wringing some extra short term life span out of IPv4. Had we done so, I believe we'd be causing ourselves more long term damage than short term benefit - such policies would inevitably get in the way of regular folks running their business in a regular way, the (participating member of) RIPE community and its policies end up losing legitimacy for the larger community we're supposed to serve. Tore
* Kennedy, James
I raised the question as I've heard several community members complain, validly IMO, about some LIRs that have accumulated vast v4 PA allocations that are technically autonomous to the LIR. Seems strange to have been allowed, especially considering the market value on these resources now.
The allocation of large PA blocks from the ancient (or not so ancient) past is what one might call "water under the bridge". What's done in this area is done, and can not easily be undone. With that said: If I've understood correctly, the "P" in "PA" (and "PI") is meant to be more or less synonymous with ISP, not with a provider of LIR services only. This was so that the ISP could announce the whole covering address space as a single route, thereby reducing the amount of entropy we collectively have to carry on our backs as ISPs. If the ISP / PA block holder insists, and you as a customer and current sub-PA-block holder wish to cancel the service with the ISP, the ISP can insist that you cease using the PA addresses you were assigned as a customer. The converse is not true: if the PA-holding LIR lets you take your sub-block with you, they can allow it, and I beleive that's what you said as well, Tore. I'm not sure that is the typical case, though(?) Your example with a government or large organization which holds one or more large PA block and which out of administrative convenience ("renumbering is so hard, even if I just have client hosts!") or for other reasons doles out address blocks to widely distributed sub- organizations, and where each sub-organization is free to choose its own ISP to use will result in injection of more entropy into the global routing system, as each individual sub-organization's route will need to be carried globally, and there's no possibility for route aggregation. I'm hesitating a little to find an appropriate characterization of what would happen if such pratices became very widespread, but I'm sure it certainly isn't positive for the sustainability of the network. Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along. BTW, this argument is address-family independent... Regards, - Håvard
On Tue, Jul 07, 2015 at 08:10:20PM +0200, Havard Eidnes wrote:
global routing system, as each individual sub-organization's route will need to be carried globally, and there's no possibility for route aggregation. I'm hesitating a little to find an appropriate characterization of what would happen if such pratices became very widespread, but I'm sure it certainly isn't positive for the sustainability of the network.
Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along.
In the context of global IPv4 expiration, RIPE policy can't prevent de-aggregation down to /24 (or longer) any more than King Knut was able to order the tide back out.
BTW, this argument is address-family independent...
ripe-641 strongly discourages ipv6 de-aggregation (and there is no good argument for it either) but the sheer potential size of the routing table will become a problem at some stage. That will have to be solved eventually but that is not likely to be on this ML.. ;) rgds, Sascha Luck
On Tue, Jul 07, 2015 at 08:10:20PM +0200, Havard Eidnes wrote:
global routing system, as each individual sub-organization's route will need to be carried globally, and there's no possibility for route aggregation. I'm hesitating a little to find an appropriate characterization of what would happen if such pratices became very widespread, but I'm sure it certainly isn't positive for the sustainability of the network.
Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along.
In the context of global IPv4 expiration, RIPE policy can't prevent de-aggregation down to /24 (or longer) any more than King Knut was able to order the tide back out.
I know, but the perspective needed to be put forward.
BTW, this argument is address-family independent...
ripe-641 strongly discourages ipv6 de-aggregation (and there is no good argument for it either) but the sheer potential size of the routing table will become a problem at some stage. That will have to be solved eventually but that is not likely to be on this ML.. ;)
Yup. Regards, - Håvard
* Tore Anderson Totally appreciate and agree with the government use case, or other such orgs with multiple dispersed branches or end sites needing their own ISP connectivity, especially for orgs that are not an ISP. But these are all of the one entity, or legal affiliates within an umbrella company. Unfortunately policy that rightfully allowed these also permitted some opportunistic rogue LIRs to receive copious v4 space for End User networks that were/are completely unrelated to the LIR but for the subletting of internet number resources. I know of such LIRs now forcing unsuspecting long-term assignment End Users to return the space in order for the LIR to sell the parent allocation. While it was for these End User network requirements that the NCC originally approved the IPv4 resources to the LIR in the first place! Very ugly. End user's fault for not requesting PI or becoming an LIR, I know. Still ugly. Regarding aggregation Vs multiple routing entries for allocation usage efficiently, well it's a bit late for that argument. Nice King Knut reference Sascha ;) Btw fear not, the goal of this thread wasn't to initiate strict policy proposal to regurgitate potentially misused v4 allocations. That ship has sailed, RIPE depleted years ago. Important such topical discussions be aired though, as I know many out there have questions these days. Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Havard Eidnes Sent: 07 July 2015 21:06 To: apwg@c4inet.net Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PA policy
On Tue, Jul 07, 2015 at 08:10:20PM +0200, Havard Eidnes wrote:
global routing system, as each individual sub-organization's route will need to be carried globally, and there's no possibility for route aggregation. I'm hesitating a little to find an appropriate characterization of what would happen if such pratices became very widespread, but I'm sure it certainly isn't positive for the sustainability of the network.
Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along.
In the context of global IPv4 expiration, RIPE policy can't prevent de-aggregation down to /24 (or longer) any more than King Knut was able to order the tide back out.
I know, but the perspective needed to be put forward.
BTW, this argument is address-family independent...
ripe-641 strongly discourages ipv6 de-aggregation (and there is no good argument for it either) but the sheer potential size of the routing table will become a problem at some stage. That will have to be solved eventually but that is not likely to be on this ML.. ;)
Yup. Regards, - Håvard
On Tue, Jul 7, 2015, at 22:22, Kennedy, James wrote:
Unfortunately policy that rightfully allowed these also permitted some opportunistic rogue LIRs to receive copious v4 space for End User networks that were/are completely unrelated to the LIR but for the subletting of internet number resources.
For at least 10 years, some of those companies played the unofficial role of "national internet registries", with pricing better adapted to the local economical situation.
I know of such LIRs now forcing unsuspecting long-term assignment End Users to return the space in order for the LIR to sell the parent
"Take the money and run". They played the NIR, but they were just private companies offering a service in exchange of money. Please note however that at least 2 such LIRs have heavily fragmented their allocations before kicking out users.
End user's fault for not requesting PI or becoming an LIR, I know. Still ugly.
We agree, some of those users don't. Not everybody in RIPE region is RIPE NCC-friendly. Even among LIRs, some just consider RIPE NCC as a regular commercial services supplier. -- R-A.F.
* Havard Eidnes
If I've understood correctly, the "P" in "PA" (and "PI") is meant to be more or less synonymous with ISP, not with a provider of LIR services only. This was so that the ISP could announce the whole covering address space as a single route, thereby reducing the amount of entropy we collectively have to carry on our backs as ISPs. If the ISP / PA block holder insists, and you as a customer and current sub-PA-block holder wish to cancel the service with the ISP, the ISP can insist that you cease using the PA addresses you were assigned as a customer.
The converse is not true: if the PA-holding LIR lets you take your sub-block with you, they can allow it, and I beleive that's what you said as well, Tore. I'm not sure that is the typical case, though(?)
It's not the common case, no. Usually, ISP = LIR. But even though it might be a corner case, it's still a case we do (and should) cater for.
Your example with a government or large organization which holds one or more large PA block and which out of administrative convenience ("renumbering is so hard, even if I just have client hosts!") or for other reasons doles out address blocks to widely distributed sub- organizations, and where each sub-organization is free to choose its own ISP to use will result in injection of more entropy into the global routing system, as each individual sub-organization's route will need to be carried globally, and there's no possibility for route aggregation. I'm hesitating a little to find an appropriate characterization of what would happen if such pratices became very widespread, but I'm sure it certainly isn't positive for the sustainability of the network.
Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along.
BTW, this argument is address-family independent...
Indeed. But, the reason why such non-ISP LIRs might become more prevalent nowadays is IPv4 depletion. We already know that IPv4 isn't going to be sustainable though, so I don't think it is anything we need to worry about or attempt to "fix" or "prevent" through implementing restrictive policies. In the longer term, in the IPv6 world, such non-ISP LIRs will again be just a corner case that exists in limited numbers, and probably only where there's actually a good reason for doing it that way. Allowing for them to exist thus won't cause significant harm to the routing table. (Also keep in mind that the preferred alternative for many of them would be to use IPv6 PI instead, which would be worse as a bunch of PI blocks cannot be re-aggregated at a later point in time.) Tore
Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along.
BTW, this argument is address-family independent...
Indeed. But, the reason why such non-ISP LIRs might become more prevalent nowadays is IPv4 depletion. We already know that IPv4 isn't going to be sustainable though, so I don't think it is anything we need to worry about or attempt to "fix" or "prevent" through implementing restrictive policies.
True, but that doesn't mean that everyone needs to think this is just A-OK. I'm doing my bit by frowning my nose and muttering here (for all the good that will do).
In the longer term, in the IPv6 world, such non-ISP LIRs will again be just a corner case that exists in limited numbers, and probably only where there's actually a good reason for doing it that way. Allowing for them to exist thus won't cause significant harm to the routing table.
Maybe for the IPv6 allocations, yes, but at present IPv4 and IPv6 is served by the same network infrastructure, so whatever silliness happens in the IPv4 world will affect the infrastructure we use for IPv6 as well. (Yes, that's another argument than what I started with above.) Regards, - Håvard
participants (8)
-
Daniel Baeza (Red y Sistemas TVT) -
Havard Eidnes -
Kennedy, James -
Nick Hilliard -
Radu-Adrian FEURDEAN -
Sascha Luck [ml] -
Tore Anderson -
Wilfried Woeber